Alternative proposal for dual-funding tx_signatures ordering
#9
Conversation
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
So that it knows what open_channel2 is responding to. Spotted-By: @rustyrussell
…x protocol Suggested-By: Antoine Riard @ariard
Remove the fee_step in favor of using an explicit bump feerate, with the constraint that it must be at least 1/64th greater than the last sent rate. Suggested-By: @rustyrussell
As @t-bast points out, we define 'point' in 01, which covers the encoding.
"Failing the channel" may not be the right action in all cases where the interactive construction protocol is used (e.g. closes), so we move reference to it as a mitigation technique specifically to the usage of the interactive protocol in the v2 open sequence. Suggested-By: @t-bast
For open_channel2 + accept_channel2 we use the opener's basepoint and a zeroed out point for the accepter. This is because we don't know what the accepter's basepoint is yet. (It's transmitted in accept_channel2) Pointed-Out-By: @t-bast
Suggested-By: @t-bast
P2SH-wrapped inputs are segwit inputs and should be eligible for spending, however the spec as written didn't permit them Reported-by: @SomberNight
P2SH outputs have larger dust requirements than native SegWit (and Taproot) scripts; we disallow the creation of them on funding txs as a they're problematic for relay when allowing dust limits below 546 sats (see lightning#894) Suggested-by: @t-bast
Requested-by: @t-bast
input_count of 1 times min witness weight of 110, is 110. not 107 the sum of 612 is correct, however. Reported-By: @SimonVrouwe
* Move RBF inside the interactive-tx protocol * Use same tlvs as open_channel / accept_channel * Require native segwit * Fix a few typos and whitespaces issues (thanks markdown linter)
And add `channel_type` tlv.
We use 1/24 instead of 1/64 to produce larger steps in fee-bumping.
Add signature data, remove wrapped segwit inputs, update calculations to be more explicit about how to figure fee
If both peers contribute an equal amount to a interactive tx, peer with "lower" pubkey sends first
The weight of a witness stack for a p2wpkh low-r signature is 107 bytes.
Don't show up in the CLN generator w/o this
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.
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.
|
I think I've come around to being ok with a flag for "peer must be first" flag. The griefing usecase for a large LSP is a "real and present" danger as you've pointed out. While we might be able to mitigate this in the future with PODLEs, right now it's a good thing to have so we should add it. I would suggest that we leave the "biggest amount goes last" as the default (as this nominally helps with batched/multiparty opens... even though I haven't coded it up yet, currently we send sigs as soon as we have them). What do you think @t-bast ? Also apologies for moving the discussion, I can't figure out where the last comments ended up... |
Just to make sure I understand this correctly, instead of "opener goes first but can request the other peer to start", you would like to have:
I believe this is worse than "opener goes first but can request the other peer to start", because in practice what will happen is that liquidity providers (accepters) will always set
Why does it help though? If you're batching you just have to signal
That's what happens when your PRs are too popular, too many people are interested and make great comments on it 😆 |
The peer that sends `tx_signatures` first is taking a risk when they are contributing to the channel funding: the other peer may never send their `tx_signatures`, and the signer will need to double-spend themselves to ensure that their funds are not locked. The accepting node is more at risk here, as they don't choose who tries to open channels to them, whereas an opening node who detects a malicious accepting node can just go somewhere else to open a channel. Thus by default, the opener should send their `tx_signatures` first, unless they explicitly request the accepting node to go first because they are trying to coordinate multiparty tx construction.
t-bast
force-pushed
the
tx-signatures-ordering
branch
from
3f3b512 to
1e03d44
Compare
Leaving the naive dual-funding user open to DoS seems like a poor default. I agree with @t-bast, and regardless of the "default" in the spec, for LND I intend to implement |
|
I don't think this change is useful anymore, as I think the strategy outlined here gets rid of the griefing attack entirely with close to no downside. I'll close this PR soon unless we find an issue with the anti-griefing strategy. |
niftynei
force-pushed
the
nifty/dual-fund
branch
from
663a45b to
e63afb3
Compare
The peer that sends
tx_signaturesfirst is taking a risk when they are contributing to the channel funding: the other peer may never send theirtx_signatures, and the signer will need to double-spend themselves to ensure that their funds are not locked.The accepting node is more at risk here, as they don't choose who tries to open channels to them, whereas an opening node who detects a malicious accepting node can just go somewhere else to open a channel.
Thus by default, the opener should send their
tx_signaturesfirst, unless they explicitly request the accepting node to go first because they are trying to coordinate multiparty tx construction.In my opinion, there are only two cases where the accepting node would contribute to a channel being opened to them:
Credits to @morehouse who laid this out in lightning#851 (comment)
@morehouse @niftynei let me know what you think. I'm not convinced that this is the right way, but at least it's an alternative to consider.
NB: this builds on top of #7, please only look at the last commit