> > This is actually incorrect. There are two transactions involved in LN. The > funding transaction, which opens a payment channel, and a commitment > transaction, which closes the channel when broadcasted to the network (the > cooperative closing transaction can be considered a commitment transaction > in a loose sense). > > Now you want to protect the funding transaction, as otherwise you would be > subject to a replay-attack on all *past* forks. So you will set > `nForkId>=1` for the funding transaction, making this payment channel > non-existent on any *past* forks. However, if during the lifetime of the > payment channel another fork happens, the payment channel exists for both > tokens. So for the commitment transaction, you will have `nForkId=0`, > making it valid on both of these chains. While this `nForkId` is valid on > all chains, the parent transaction it tries to spend (the funding > transaction) does only exist on two chains, the original one you created > the channel for and the one that forked away. >
Thanks for the clarification. How would a tx specify a constraint like "nForkId>=1"? I was thinking of it just as a number set on the tx. Also note that since forks form a partial order, but IDs (numbers) form a total order, ">=" will miss some cases. Eg, suppose BCH had forked with nForkId 2, and then you set up a LN funding tx on BCH with nForkId>=2, and then Segwit2x forked (from BTC!) with nForkId 3. The BCH funding tx would be valid on Segwit2x. This is more of a fundamental problem than a bug - to avoid it you'd have to get into stuff like making each fork reference its parent-fork's first block or something, someone has written about this... On Mon, Nov 13, 2017 at 5:03 AM, Mats Jerratsch <m...@blockchain.com> wrote: > > OK, so nForkId 0 is exactly the "valid on all chains" specifier I was > asking about, cool. And your LN example (and nLockTime txs in general) > illustrate why it's preferable to implement a generic replay protection > scheme like yours *in advance*, rather than before each fork: all ad hoc > RP schemes I know of break old txs on one of the chains, even when that's > not desirable - ie, they offer no wildcard like nForkId 0. > > > Exactly! > > One comment on your LN example: users would have to take note that nForkId > 0 txs would be valid not only on future forks, but on *past* forks too. > Eg, if BCH had been deployed with nForkId 2, then a user setting up BTC LN > txs now with nForkId 0 would have to be aware that those txs would be valid > for BCH too. Of course the user could avoid this by funding from a > BTC-only address, but it is a potential minor pitfall of nForkId 0. (Which > I don't see any clean way around.) > > > This is actually incorrect. There are two transactions involved in LN. The > funding transaction, which opens a payment channel, and a commitment > transaction, which closes the channel when broadcasted to the network (the > cooperative closing transaction can be considered a commitment transaction > in a loose sense). > > Now you want to protect the funding transaction, as otherwise you would be > subject to a replay-attack on all *past* forks. So you will set > `nForkId>=1` for the funding transaction, making this payment channel > non-existent on any *past* forks. However, if during the lifetime of the > payment channel another fork happens, the payment channel exists for both > tokens. So for the commitment transaction, you will have `nForkId=0`, > making it valid on both of these chains. While this `nForkId` is valid on > all chains, the parent transaction it tries to spend (the funding > transaction) does only exist on two chains, the original one you created > the channel for and the one that forked away. >
_______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
