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.
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.) On Fri, Nov 10, 2017 at 6:28 AM, Mats Jerratsch <m...@blockchain.com> wrote: > I guess I wasn't clear on the wildcard, `nForkId=0` > > This proposal puts Bitcoin at `nForkId=1`, with the purpose of having > `nForkId=0` valid on *all* future forks. This means you can create a > `nLockTime` transaction, delete the private key and still be assured to not > lose potential future tokens. > > In theory `nForkId=0` could be used for an address too, the sending wallet > should display a warning message about unknown side effects though. This > address would be future-safe, and you can put it into a safe-deposit box > (even though I see little reason to back up an _address_. You would always > back up a _private key_, which translates into funds on any fork.) > > Furthermore, `nForkId=0` can be used for L2 applications. Let's say Alice > and Bob open a payment channel. One week later, project X decides to fork > the network into a new token, implementing a custom way of providing strong > two-way replay protection. The protocol Alice and Bob use for the payment > channel has not implemented this new form of replay protection. Alice and > Bob now have to make a choice: > > (1) Ignore this new token. This comes with an evaluation of how much this > new token could be worth in the future. They will continue normal channel > operation, knowing that their funds on the other branch will be locked up > until eternity. When they close their payment channel, the closing > transaction will get rejected from the other network, because it's not > following the format for replay protected transactions. > > (2) Close the payment channel before the fork. The transaction, which > closes the payment channel has to be mined before the fork, potentially > paying a higher-than-normal fee. > > With this proposal implemented, there are two additional choices > > (3) Create the commitment transactions with `nForkId=0`. This ensures that > when the channel gets closed, funds on other chains are released > accordingly. This also means that after the fork, payments on the channel > move both, the original token and the new token. Potentially, Alice and Bob > want to wait before further transacting on the channel, to see if the token > has substantial value. If it has, they can *then* close the channel and > open a new channel again. (Note: The funding transaction can use a specific > `nForkId`, preventing you from locking up multiple coins when funding the > channel, but you can choose to settle with `nForkId=0` to not lock up > future coins) > > (4) Make the protocol aware of different `nForkId`. After the fork, the > participants can chose to *only* close the payment channel on the new > token, making the payment channel Bitcoin-only again. This is the preferred > option, as it means no disruption to the original network. > > > I like the idea of specifying the fork in bech32 [0]. On the other hand, > the standard already has a human readable part. Perhaps the human readable > part can be used as the fork id? > > I was considering this too. On the other hand, it's only _human readable_ > because thy bytes used currently encode 'bc'. For future forks, this would > just be two random letters than, but potentially acceptable. > >
_______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
