Add support for taproot zero-fee commitment format #3285
Draft
Add support for taproot zero-fee commitment format #3285
Conversation
We add support for the zero-fee commitment format specified in lightning/bolts#1228. Channels using this commitment format benefit from better protection against pinning attacks (thanks to TRUC/v3 transactions), don't need the `update_fee` mechanism, have less dust exposure risk, and use an overall simpler state machine. In this commit, we simply introduce the commitment format and create the corresponding transactions.
It isn't delayed anymore for v3 transactions. We could use static wallet public key, but in most cases it wouldn't work and adds extra complexity so we don't do it. We add a comment in the documentation of this class to explain why we're always making a 2nd-stage transaction.
We apply slightly different validation for zero-fee commitments: - the commit feerate must be `0 sat/byte` - the max number of accepted HTLCs must be at most 114 - `update_fee` cannot be used We verify those requirements during channel creation and add tests for normal channel operation.
We add support for force-close zero-fee channels. When publishing the local commit, this works mostly the same way as other channel types. The only difference is that we don't even attempt to publish the commit tx individually: we always bundle it with the anchor transaction. When we detect the remote commit though, we're able to introduce some new behavior: - if we have a large enough main output, we use that to pay the fees of the remote commit tx (unless it is already confirmed), which avoids using a wallet input - otherwise, we spend the anchor output, which competes with the remote peer package Since we're only using the anchor transaction or our main output to spend the ephemeral anchor, we cannot publish HTLC txs until the commit tx is confirmed. We will in the future make *all* transactions go through the `ReplaceableTxPublisher`, and at the point we'll be able to simplify this, but it's too early for this refactoring, so for now we simply wait for the commit tx to be confirmed before publishing HTLC txs.
When using zero-fee commitments, we don't force-close when receiving an `error` from our peer: if they want to force-close the channel, they can publish their commitment instead of forcing us to publish ours. It is especially true when the commit tx doesn't pay any fees, because the publisher will pay the entire fees for the force-close. Note that for wallet peers, we could introduce a mechanism where they send us their signed commit tx in the error message if they don't have any wallet input to pay the fees, and we could be nice and publish it while paying the fees from our main output (which isn't delayed since it is the remote commit from our point of view).
We add support for the zero-fee commitment format specified in lightning/bolts#1330. Channels using this commitment format benefit from better protection against pinning attacks (thanks to TRUC/v3 transactions), don't need the `update_fee` mechanism, have less dust exposure risk, and use an overall simpler state machine, while benefiting from the privacy improvements of taproot channels.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
We add support for the zero-fee commitment format specified in lightning/bolts#1330.
Channels using this commitment format benefit from better protection against pinning attacks (thanks to TRUC/v3 transactions), don't need the
update_feemechanism, have less dust exposure risk, and use an overall simpler state machine, while benefiting from the privacy improvements of taproot channels.Builds on top of #3192