-
Notifications
You must be signed in to change notification settings - Fork 266
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Use final spec values for splicing #2887
base: master
Are you sure you want to change the base?
Conversation
7d1c23e
to
33482ec
Compare
33482ec
to
fa51c31
Compare
We replace our experimental version of `splice_init`, `splice_ack` and `splice_locked` by their official version. If our peer is using the experimental feature bit, we convert our outgoing messages to use the experimental encoding and incoming messages to the official messages. We also change the TLV fields added to `tx_add_input`, `tx_signatures` and `splice_locked` to match the spec version. We always write both the official and experimental TLV to updated nodes (because the experimental one is odd and will be ignored) but we drop the official TLV if our peer is using the experimental feature, because it won't understand the even TLV field. This guarantees backwards-compatibility with peers who only support the experimental feature.
We initially supported splicing with a poor man's quiescence, where we allowed splice messages if the commitments were already quiescent. We've shipped support for quiescence since then, which means that new even nodes relying on experimental splicing should support quiescence. We can thus remove support for the non-quiescent version.
If the latest splice transaction doesn't confirm, we allow exchanging `tx_init_rbf` and `tx_ack_rbf` to create another splice transaction to replace it. We use the same funding contribution as the previous splice. We disallow creating another splice transaction using `splice_init` if we have several RBF attempts for the latest splice: we cannot know which one of them will confirm and should be spent by the new splice.
fa51c31
to
2d350e5
Compare
This is an observation that occurred to me while reviewing this PR that might be relevant for a future PR .. There will be times when using This seems to be technically possible in the protocol because CMD_BUMP_FUNDING_FEE uses the interactive tx protocol and can change the funding contribution with the Perhaps the biggest downside I can see (beside complexity) is that if your pending splice or rbf confirms before a rbf-splice, then you would need to renegotiate it as a new splice. Am I missing something here wrt fee savings? Do you think it would be worth considering this situation now rather than later? |
Yes, the main reason we're not providing this yet (even though this is in theory possible) is to manage complexity. It can get really complex very quickly once you start going down that road, because if each splice "part" maps to a specific action (e.g. an on-the-fly funding), it can be a huge mess to reconcile which parts where actually done and which parts need to be replayed if a previous RBF attempt confirms. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good - the refactor for RBF makes it easier to read/understand.
I found a few nits but main issues to take a look at are related to adding logic to reject an TxInitRbf or SpliceInit when the parent splice is unconfirmed.
eclair-core/src/main/scala/fr/acinq/eclair/channel/fund/InteractiveTxFunder.scala
Show resolved
Hide resolved
eclair-core/src/main/scala/fr/acinq/eclair/wire/internal/channel/version4/ChannelCodecs4.scala
Show resolved
Hide resolved
eclair-core/src/main/scala/fr/acinq/eclair/channel/fsm/ChannelOpenDualFunded.scala
Outdated
Show resolved
Hide resolved
When 0-conf isn't used, we reject `splice_init` while the previous splice transaction hasn't confirmed. Our peer should either use RBF instead of creating a new splice, or they should wait for our node to receive the block that confirmed the previous transaction. This protects against chains of unconfirmed transactions.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Changes to tests to disallow sequences of unconfirmed splices looks good. I only had a few minor nits/questions.
eclair-core/src/test/scala/fr/acinq/eclair/channel/states/e/NormalSplicesStateSpec.scala
Show resolved
Hide resolved
watchConfirmedCommit2.replyTo ! WatchTxConfirmedTriggered(BlockHeight(400000), 42, commitTx2) | ||
// claim-main-delayed tx confirms | ||
watchConfirmedClaimMainDelayed2.replyTo ! WatchTxConfirmedTriggered(BlockHeight(400000), 42, claimMainDelayed2) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: is it important to pass WatchTxConfirmedTriggered
to watchConfirmedCommit2.replyTo
instead of just passing to alice
as you do elsewhere?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No, it was really useless, I'd rather keep it simple and easier to read by referring to alice
and bob
everywhere.
We replace our experimental version of
splice_init
,splice_ack
andsplice_locked
by their official version (see lightning/bolts#1160). If our peer is using the experimental feature bit, we convert our outgoing messages to use the experimental encoding and incoming messages to the official messages.We also change the TLV fields added to
tx_add_input
,tx_signatures
andsplice_locked
to match the spec version. We always write both the official and experimental TLV to updated nodes (because the experimental one is odd and will be ignored) but we drop the official TLV if our peer is using the experimental feature, because it won't understand the even TLV field.This guarantees backwards-compatibility with peers who only support the experimental feature.
We also implement RBF support for splice transactions in the last commit: that's the part of this PR that really needs a thorough review. I can probably port some parts of this commit to
master
as preparatory steps if that makes it easier to review.@ddustin you should be able to start cross-compat tests based on this branch. Note that we currently only support unannounced channels (we haven't implemented the gossip part yet).
Fixes #2781