fixup: include specifier for how elements -> witness_data #17
Conversation
This file contains 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
This commit adds the interactive transaction construction protcol, as well as the first practical example of using it, v2 of channel establishment. Note that for v2 we also update the channel_id, which now uses the hash of the revocation_basepoints. We move away from using the funding transaction id, as the introduction of RBF* makes it such that a single channel may have many funding transaction id's over the course of its lifetime. *Later, also splicing
Requested-by: @t-bast
If both peers contribute an equal amount to a interactive tx, peer with "lower" pubkey sends first
This commit contains many (small) changes to address most of the pending comments: - removed feature dependency on anchor outputs - the "zerod_channel_id" created confusion, we instead explicitly detail the open and accept cases - "fail the negotiation" was unclear in interactive-tx - clarified field names in `tx_signatures` - many nits from PR comments Thanks to @morehouse, @ariard and @antonilol for the helpful comments.
Repeat the second commit point in the initial openchannel2 message. Suggested-By: @pm47
Prior versions of the v2 dual-funding protocol assumed a 'minimum fee' payment for any witness stack of any input, as a way to simplify fee checks. The suggested min feerate didn't make sense for taproot spend paths etc; instead we remove this check entirely.
This lets any side of the protocol require the other side to use confirmed inputs, to avoid paying the fees of a low feerate unconfirmed ancestor.
This allows us to filter messages until we know the peer has ack'd our abort, allowing us to return to "prior" negotiation state w/o fear of encountering stale messages in the queue. Suggested-by: @ddustin
Same argument as for including it in open_channel2
This issue is non-trivial and worth mentioning, otherwise implementations may forget to handle this which would result in an easy way of attacking node's on-chain liquidity, creating a large opportunity cost.
If we only store state when sending `tx_signatures`, there are cases where we cannot reconcile states if a disconnection occurs during the signing steps: one side will have sent `tx_signatures` and thus must wait for the transaction to be spent or double-spent, while the other side has already forgotten that channel because they haven't sent `tx_signatures`. This is fixed by storing state when sending `commitment_signed`, and adding a `next_funding_txid` field to `channel_reestablish` to ask our peer to retransmit signatures that we haven't received.
While dual funding only needs unsigned funding amounts, other protocols that leverage interactive-tx may use signed funding amounts, for example to take funds out of an existing channel (splice-out). It is thus more future-proof to use signed amounts in `tx_init_rbf` and `tx_ack_rbf`.
Clarify how witness data gets packed for plebs like me
niftynei
force-pushed
the
nifty/clarify-witness-data
branch
from
3efee3c to
e299850
Compare
niftynei
force-pushed
the
nifty/dual-fund
branch
from
091397f to
c33cdc8
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Clarify how witness data gets packed for plebs like me.
I do find it kind of odd that we also strip off the count bits but we end up having to "re-hydrate" this struct back into CompactSize-less scripts in order to jam it into our own wallet/struct stuff so honestly let's maybe not go there.