mirror of https://github.com/ACINQ/eclair.git synced 2025-03-01 00:58:59 +01:00

Bastien Teinturier 6d7b0fae57

Remove max-funding-satoshis config (#2624 )

* Remove `max-funding-satoshis` config

This configuration parameter doesn't provide any meaningful guarantees
since there are no limits on the number of channels remote peers can open
to us. It's better to remove this check from eclair and let plugins decide
whether to accept channels or not, based on whatever metric makes sense
for their usecase.

* Remove wumbo from permanent channel features

We've never been really convinced that this feature made sense to keep in
the channel features. It becomes especially weird with splicing, since a
channel may initially be larger than the wumbo size, but could then shrink
and become smaller than that threshold. Similarly, a channel that is
initially below the wumbo size may exceed the wumbo size after a splice-in.

2023-04-05 14:52:39 +02:00

6.7 KiB

Raw Blame History

Eclair vnext

Major changes

Offers

Paying offers

$ ./eclair-cli payoffer --offer=<offer-to-pay> --amountMsat=<amountToPay>

If the offer supports it, you can also specify --quantity to buy more than one at a time. All the parameters from payinvoice are also supported.

Eclair will request an invoice and pay it (assuming it matches our request) without further interaction.

Offers are still experimental and some details could still change before they are widely supported.

Receiving payments for offers

To be able to receive payments for offers, you will need to use a plugin. The plugin needs to create the offer and register a handler that will accept or reject the invoice requests and the payments. Eclair will check that these satisfy all the protocol requirements and the handler only needs to consider whether the item on offer can be delivered or not.

Invoices generated for offers are not stored in the database to prevent a DoS vector. Instead, all the relevant data (offer id, preimage, amount, quantity, creation date and payer id) is included in the blinded route that will be used for payment. The handler can also add its own data. All this data is signed and encrypted so that it can not be read or forged by the payer.

API changes

audit now accepts --count and --skip parameters to limit the number of retrieved items (#2474, #2487)
sendtoroute removes the --trampolineNodes argument and implicitly uses a single trampoline hop (#2480)
payinvoice always returns the payment result when used with --blocking, even when using MPP (#2525)
node returns high-level information about a remote node (#2568)
channel-created is a new websocket event that is published when a channel's funding transaction has been broadcast (#2567)
channel-opened websocket event was updated to contain the final channel_id and be published when a channel is ready to process payments (#2567)
getsentinfo can now be used with --offer to list payments sent to a specific offer.
listreceivedpayments lists payments received by your node (#2607)

Miscellaneous improvements and bug fixes

Strategies to handle locked utxos at start-up (#2278)

If some utxos are locked when eclair starts, it is likely because eclair was previously stopped in the middle of funding a transaction. While this doesn't create any risk of loss of funds, these utxos will stay locked for no good reason and won't be used to fund future transactions. Eclair offers three strategies to handle that scenario, that node operators can configure by setting eclair.bitcoind.startup-locked-utxos-behavior in their eclair.conf:

stop: eclair won't start until the corresponding utxos are unlocked by the node operator
unlock: eclair will automatically unlock the corresponding utxos
ignore: eclair will leave these utxos locked and start

Add plugin support for channel open interception (#2552)

Eclair now supports plugins that intercept channel open requests and decide whether to accept or reject them. This is useful for example to enforce custom policies on who can open channels with you.

An example plugin that demonstrates this functionality can be found in the eclair-plugins repository.

Configurable channel open rate limits (#2552)

We have added parameters to eclair.conf to allow nodes to manage the number of channel open requests from peers that are pending on-chain confirmation. A limit exists for each public peer node individually and for all private peer nodes in aggregate.

The new configuration options and defaults are as follows:

// a list of public keys; we will ignore limits on pending channels from these peers
eclair.channel.channel-open-limits.channel-opener-whitelist = [] 

// maximum number of pending channels we will accept from a given peer
eclair.channel.channel-open-limits.max-pending-channels-per-peer = 3 

// maximum number of pending channels we will accept from all private nodes
eclair.channel.channel-open-limits.max-total-pending-channels-private-nodes = 99

Configurable limit on incoming connections (#2601)

We have added a parameter to eclair.conf to allow nodes to track the number of incoming connections they maintain from peers they do not have existing channels with. Once the limit is reached, Eclair will disconnect from the oldest tracked peers first.

Outgoing connections and peers on the sync-whitelist are exempt from and do not count towards the limit.

The new configuration option and default is as follows:

// maximum number of incoming connections from peers that do not have any channels with us
eclair.peer-connection.max-no-channels = 250

Removed funding limits when Wumbo is enabled (#2624)

We removed the eclair.channel.max-funding-satoshis configuration field. If node operators wish to limit the size of channels opened to them, there are two options.

The first option is to disable large channels support by adding the following line to eclair.conf:

eclair.features.option_support_large_channel = disabled

But that option won't limit the number of inbound channels, so it isn't a guarantee that the node will "stay small".

The second option is to leverage the new plugin support for channel open interception: node operators can reject channel open requests based on any metric that they see fit.

Verifying signatures

You will need gpg and our release signing key 7A73FE77DE2C4027. Note that you can get it:

from our website: https://acinq.co/pgp/drouinf.asc
from github user @sstone, a committer on eclair: https://api.github.com/users/sstone/gpg_keys

To import our signing key:

$ gpg --import drouinf.asc

To verify the release file checksums and signatures:

$ gpg -d SHA256SUMS.asc > SHA256SUMS.stripped
$ sha256sum -c SHA256SUMS.stripped

Building

Eclair builds are deterministic. To reproduce our builds, please use the following environment (*):

Ubuntu 20.04
AdoptOpenJDK 11.0.6
Maven 3.8.1

Use the following command to generate the eclair-node package:

mvn clean install -DskipTests

That should generate eclair-node/target/eclair-node-<version>-XXXXXXX-bin.zip with sha256 checksums that match the one we provide and sign in SHA256SUMS.asc

(*) You may be able to build the exact same artefacts with other operating systems or versions of JDK 11, we have not tried everything.

Upgrading

This release is fully compatible with previous eclair versions. You don't need to close your channels, just stop eclair, upgrade and restart.

Changelog

6.7 KiB Raw Blame History