The `Peer` actor can now directly be queried for the list of its channels.
This makes this feature more reusable than the previous actor that was
customized for the peer-ready scenario.
The spec says that we must return an error if:
- cltv_expiry < outgoing_cltv_value
- cltv_expiry < current_block_height + min_final_cltv_expiry_delta
For the second check, we actually tested if:
- cltv_expiry < max(outgoing_cltv_value, current_block_height) + min_final_cltv_expiry_delta
But that check should only verify that our `min_final_expiry_delta`
requirement is fulfilled, which is unrelated to the `outgoing_cltv_value`.
It was redundant with the first check, which already guarantees that
intermediate nodes inside the blinded path cannot cheat by using a higher
`cltv_expiry_delta` than what the recipient intended.
In cluster mode, outgoing connections are initiated by frontend nodes.
If there are no frontend node available, we fail the connection attempt
with a dedicated error.
The `initial-random-reconnect-delay` should be configured to allow
enough time for the front nodes to bootstrap at reconnection.
When initializing the DB, we potentially run some data migration that
cannot be reverted. We want to this last, after we've checked every other
start-up requirement, such as the bitcoind version.
Fixes#2609
LND and CLN already use 2016 blocks. The network is generally raising the
values of `cltv_expiry_delta` to account for high on-chain fees, so we'll
need to allow longer maximum deltas to avoid rejecting payments.
When we want to add new types of inputs/outputs that contain specific
tlvs, we will need to store them alongside standard inputs/outputs.
We will use traits and case classes inside `InteractiveTxBuilder`, and
need to thus add a discriminator when encoding them.
This RPC allows to access the historic channel data without
relying on third party services like LN explorers.
Note that when the `remoteNodeId` filter is not provided, this
query may be expensive on nodes with a lot of closed channels.
In theory we don't have to store their commit_sig here, as they
would re-send it if we disconnect, but it is more consistent with
the case where we send our tx_signatures first.
Previous implementation had the advantage of being all in one place, but it left holes:
- `last_connected_timestamp` was only set after the first disconnection
- in some corner cases the `closed_timestamp` was never set (nothing at stake, funding tx timeout, post-restart)
If we force-close with HTLCs that have just been signed by our peer but
for which we haven't received their revocation, we should ignore them.
We have not relayed those HTLCs so they can't be fulfilled. It is our
peer's responsibility to claim them on-chain (using their HTLC-timeout),
but if for some reason they don't claim it, we don't want the channel to
be stuck in the closing state.
Fixes#2669
The on-chain feerate can be arbitrarily high, but it wouldn't make sense
to pay more fees than the amount we have at risk and need to claim
on-chain.
We compute an upper bound on the fees we'll pay and make sure we don't
exceed it, even when trying to RBF htlc transactions that get close to
their deadline.
When performing a mutual close, we initially rejected fees that were
higher to the commit tx fees. This was removed from the specification
for anchor output channels, and doesn't make a lot of sense for standard
channels either: even at a higher fee, it makes sense to do a mutual
close to avoid waiting for relative delays on our outputs.
Fixes#2646
Bolt 2 requires the receiver of an HTLC to pay able to pay the commit tx
fee while maintaining its channel balance. This is an issue because it
can lead to a situation where the peer that has most of the channel's
funds is unable to send outgoing payments: the channel is stuck.
From the receiver's point of view, it's ok to dip into the channel reserve
as long as we're able to pay the commit tx fee, so we should accept those
HTLCs. Moreover, if those HTLCs are failed, we'll go back above our
channel reserve, and if those HTLCs are fulfilled, that will increase our
balance which guarantees we're above our channel reserve.
According to the spec, option_onion_messages signals that the node can forward onion messages which is different from being able to send or receive them (there is no feature bit for that).
We now allow nodes with this feature disabled to still receive messages and remove the NoRelay relay policy as it is redundant.
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 https://github.com/lightningnetwork/lnd/issues/7657 for example.
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`.
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. ** wildcard indicates all the files in the current folder and all the files in the subfolders of the current folder.
Fixes#1645
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>
* 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.
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>
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.
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.
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.
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>
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>
* 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-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.
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.
