master
Name already in use
Commits on May 17, 2023
-
Ignore lnd's internal errors (#2659)
It seems like lnd sends this error whenever something wrong happens on their side, regardless of whether the channel actually needs to be closed. We ignore it to avoid paying the cost of a channel force-close, it's up to them to broadcast their commitment if they wish. See lightningnetwork/lnd#7657 for example.
Commits on May 12, 2023
-
Reject unreasonably low splice feerate (#2657)
We let the initiator pick the feerate, but it must at least meet some sanity requirements.
Commits on May 11, 2023
-
Fix channels DB migration (#2655)
We were missing a match on `channel_id`, which means we were rewriting every row N times!
Commits on May 10, 2023
-
Fix JSON Postgres index on channel's
remote_node_id(#2649)We were creating an index on the `remote_node_id` based on the channel's JSON serialization, which isn't very robust. The data model changes for splicing have changed the JSON format and thus broken that index. We now use and explicit DB column for `remote_node_id`.
-
Define
channelReserve()methods inChannelParams(#2653)So it can be called from `InteractiveTx` for new commitments.
-
Remove restriction to regtest/testnet (#2652)
Now that the model is stable we can remove restrictions.
Commits on May 5, 2023
Commits on May 4, 2023
-
Add
cpfp-bump-feesAPI (#1783)We add a `cpfpbumpfees` API that lets node operators bump the fees of a package of unconfirmed transactions. Node operators can for example ensure their funding txs confirm before they hit the `2016` funding timeout. It's also very useful when you have a long chain of unconfirmed funding transactions and/or mutual close transactions and want to bump them all at once. NB: the node operator needs to figure out which outpoints belong to him (which should be fairly easy using existing APIs).
-
Included doc folder in the assembly zip (#2604)
Included doc folder in the assembly zip. ** wildcard indicates all the files in the current folder and all the files in the subfolders of the current folder. Fixes #1645
-
Cleanup
ChannelKeyManager(#2639)There was a confusion between `fundingKeyPath` and `channelKeyPath`. Also simplified the funding key derivation. It's not backward compatible but current version of the code doesn't run on mainnet so it's fine. --------- Co-authored-by: Bastien Teinturier <31281497+t-bast@users.noreply.github.com>
-
Minor fixes for splices (#2647)
* do not check features at all for splices It makes more sense than having to announce the feature to all peers. * check actual min_conf value in swichToZeroConf When we receive an early `channel_ready`, we may decide to not wait for confirmations even if the channel isn't formally zero-conf. However, when checking whether the channel is zero-conf, we currently only look at the `ZeroConf` feature, which is incorrect in the general case. This is normally invisible, because the race between: - local `WatchFundingTxPublished` event from the watcher - remote `ChannelReady` is normally won by `WatchFundingTxPublished`. But in tests `ChannelReady` usually wins. It causes us to go through the `swichToZeroConf` path even if the channel is already zero-conf, which then leads us to send a `splice_locked` for the initial funding tx. * check features before ignoring sig at reconnection Legacy single-funding channels may have `localFundingStatus=SingleFundedUnconfirmedFundingTx`, so we cannot just rely on the absence of `signedTx`. * fix post-migration startup of channels Legacy single-funded channels will all be restored with a `localFundingStatus=SingleFundedUnconfirmedFundingTx`, whatever the actual status of the funding confirmation. The idea is that we immediately put a `watchFundingConfirmed()` and set the correct state shortly after the first startup. However, we currently also send a `GetTxWithMeta`, which we should only do for channels that are in state `WAIT_FOR_FUNDING_CONFIRMED`, otherwise we will have loads of `unhandled event GetTxWithMetaResponse`. * ignore watcher events in CLOSED With splices, notifications from the watcher are tricky, there may be races due to dealing with multiple funding txs. When we eventually go to the `CLOSED` state, we should ignore those events, otherwise they may wrongly cause us to go back to `CLOSING`. * use correct expiry when accepting splice The non-initiator must use the `locktime` provided in the `splice_init` and not choose its own, otherwise transactions and signatures won't match if we splice around the time a block has been found.
Commits on May 3, 2023
-
Remove
minDepthfromInteractiveTxParams(#2635)We can recompute `minDepth` based on our default config, the channel capacity and our local features. The only parameter that could change is our local features, which could create issues if we enable/disable zero-conf in the middle of a funding attempt: we may accept an RBF attempt for a transaction that we previously treated as zero-conf, which will break the channel. But since activating zero-conf means we have trust in our peer, and this is an unlikely scenario, this is acceptable. Co-authored-by: Pierre-Marie Padiou <pm47@users.noreply.github.com>
-
Use tlv type 0 for next_funding_txid (#2637)
This is the official tlv type used in the dual funding specification.
-
Pass remote address to InterceptOpenChannelPlugin (#2641)
This change allows plugins to make decisions based on peers' IP addresses.
Commits on Apr 15, 2023
-
Fix test to prevent error from timeout waiting for no messages (#2640)
A peer that receives Disconnect *may* also be sent the Init message. The Init message is ignored by the two disconnect tests so these tests should occur after all of the tests that do not result in a disconnect. Otherwise the extra Init triggers an error when we expect no additional messages to be sent to the peer.
Commits on Apr 14, 2023
-
Better validation of onion message payloads (#2631)
We now reject onion message payloads that contain unexpected fields and classify final payloads as being either an invoice request, an invoice response, an error or an invalid payload. Each of these cases are mutually exclusive, it is not allowed to send both an invoice request and an invoice at the same time for instance. Invalid payloads are not dropped immediately so that if they are the response we were waiting for, we can stop waiting and return an error without retrying.
-
Add padding to blinded payment routes (#2638)
The lengths of the encrypted recipient data leak the base fees as they are encoded with a variable length, to compensate for that we always add padding.
-
Onion message test vector (#2628)
Use latest test vector from the spec for onion messages.
Commits on Apr 13, 2023
-
Dynamic funding pubkeys (#2634)
Funding pubkeys are now dynamic and change for each splice. Main changes: - `remoteFundingPubkey` has been moved from `RemoteParams` to `Commitment` - `localFundingPubkey` is computed by appending the `fundingTxIndex` to a new dedicated `fundingKeyPath`. As a nice side-effect, the resulting funding pubkey is constant across rbf attempts. Also, there is no change in the data model, since the base `fundingKeyPath` is constant and still belongs to `LocalParams`. --------- Co-authored-by: Bastien Teinturier <31281497+t-bast@users.noreply.github.com>
-
Update
tx_signaturewitness codec (#2633)We treat each witness as a blob of bytes encoded using bitcoin serialization.
-
Add support for splices (#2584)
Add support for both splice-in and splice-out in Eclair. Mixing concurrent local/remote splice-in/splice-out is wired, although not supported in the API. The implementation differs from the current wip BOLT proposal on at least the following points: - we use a poor man's _quiescence_ protocol which just rejects the splice if the channel is not idle - splice txs always _spend_ the previous funding/splice tx, even if it isn't confirmed yet and could theoretically be RBFed. This is done to be compatible with zero-conf splices - the persistence/reconnection follows the logic described in https://gist.github.com/t-bast/1ac31f4e27734a10c5b9847d06db8d86. We add a new `fundingTxIndex` to `Commitment`, which has two nice advantages: - making debug much easier compared to dealing with txid: `splice=1 is now active, removed=0 remaining=2,1` - allowing to discriminate between initial funding, splices, rbf, and combinations thereof. We closely mimick RBFing the initial funding tx (e.g. `RbfStatus` vs `SpliceStatus`). --------- Co-authored-by: Bastien Teinturier <31281497+t-bast@users.noreply.github.com>
Commits on Apr 5, 2023
-
Allow negative contributions in
InteractiveTxBuilder(#2619)* Allow negative contributions in InteractiveTxBuilder When splicing over an existing channel, it is simpler to specify the amount we will add or remove from the channel, rather than the resulting amount that takes the previous balance into account. It removes the need for truncating msat balances and trivially carries over those balances to the new commitment. * Update RBF contributions to allow negative amounts When RBF-ing a splice, we will need to be consistent with the `splice_init` and `splice_ack` messages and specify the funds we're adding or removing from the channel instead of the absolute value. We thus change the `tx_init_rbf` and `tx_ack_rbf` messages to use signed amounts.
-
Remove
max-funding-satoshisconfig (#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.
-
Store channel state after sending
commit_sig(#2614)We must store the channel state after sending our `tx_signatures`, because our peer may broadcast the transaction at that point. But it's useful to store it earlier than that, to allow resuming the signatures exchange if we get disconnected, otherwise we could end up in a state where one peer has forgotten the channel while the other has sent `tx_signatures` and must thus wait for the channel to be spent or double-spent. With that change, we can cleanly handle any disconnection: - if we get disconnected before any peer sent `commitment_signed`, the channel is forgotten by both peers - if we get disconnected after one peer send `commitment_signed` but the other peer didn't, the channel will be forgotten when reconnecting (this is safe because the peer that sent `commitment_signed` did *not* send `tx_signatures` since the other peer didn't send `commitment_signed`) - if we get disconnected after both peers sent `commitment_signed`, we simply resume the signatures exchange on reconnection We introduce a new TLV field to `channel_reestablish` that contains the `txid` of the funding transaction that is partially signed: this lets peers figure out which messages to send back on reconnection.
-
Commits on Apr 4, 2023
-
Add
listreceivedpaymentsRPC call (#2607)Add a new RPC to list payments received by the node.
Commits on Mar 31, 2023
-
Rework responses to channel open and rbf (#2608)
Main behavior changes (see commit messages for details): - channel opening errors are returned with a 200/OK status from the api - we return a success in the case of dual-funding or rbf, if the interactive tx has completed, even if the publish fails - for rbf, we send the success response later in the flow: only when the rbf flow is successful, as opposed to when we initiate it This is a prerequisite to splices, but also a first step towards reworking the channel request/response mechanism. Co-authored-by: Bastien Teinturier <31281497+t-bast@users.noreply.github.com>
Commits on Mar 27, 2023
-
Because offers are a very generic mechanism, handling them can require interacting with an inventory system (do we actually have the quantity that the payer is requesting) or other such systems which do not have their place inside eclair. For this reason offer handlers must be implemented as plugins that communicate with the offer manager. On startup, the offer handlers must register their offers with the offer manager, the offer manager will then forward the invoice requests and blinded payments to the relevant offer handler for approval.
Commits on Mar 24, 2023
Commits on Mar 23, 2023
-
Fix opportunistic zero-conf (#2616)
If we didn't plan on using zero-conf, but our peer sends us an early channel_ready, we can opportunistically switch to zero-conf. But we can only do that if we're sure that our peer cannot double-spend the funding transaction. We previously checked their contribution to the funding output, but that's not enough: they may add inputs to the funding transaction even if they don't contribute to the funding output. We were also setting duplicate `WatchPublished` in case we were already using zero-conf, which is now fixed. When our peer sends us channel_ready while we're still waiting for confirmations, we may opportunistically switch to zero-conf, in which case we have both a WatchPublished and a WatchConfirmed pending. But it may not actually be a real switch to zero-conf: maybe the transaction is confirmed, and they simply received the block slightly before us. In that case, the WatchConfirmed may trigger first, and it would be inefficient to let the WatchPublished override our funding status: it will make us set a new WatchConfirmed that will instantly trigger and rewrite the funding status again.
Commits on Mar 16, 2023
Commits on Feb 28, 2023
-
Add latest changes from lightning/bolts#1018 Add latest fixes from lightning/bolts#1056
Commits on Feb 20, 2023
-
Make
updateLocalFundingStatusmethod returnEither(#2602)After calling this method, we perform actions at several places that only make sense if the correct behavior happened. Instead of assuming things went ok, we use proper typing and make the result explicit.
Commits on Feb 17, 2023
-
Limit number of RBF attempts during dual funding (#2596)
Each RBF attempt adds more data that we need to store and process, so we want to limit our peers to a reasonable use of RBF. We send a warning to let them know that they are close to reaching the limits.