{"type":"rich","version":"1.0","author_name":"npub1mlpmsc5sm93tw2fp2dhhuwmxcqm59wz6hjg5g3afq5rucfll3f9sh4yf8d","author_url":"https://nostr.ae/npub1mlpmsc5sm93tw2fp2dhhuwmxcqm59wz6hjg5g3afq5rucfll3f9sh4yf8d","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2017-11-11\n📝 Original message:OK, so nForkId 0 is exactly the \"valid on all chains\" specifier I was\nasking about, cool.  And your LN example (and nLockTime txs in general)\nillustrate why it's preferable to implement a generic replay protection\nscheme like yours *in advance*, rather than before each fork: all ad hoc RP\nschemes I know of break old txs on one of the chains, even when that's not\ndesirable - ie, they offer no wildcard like nForkId 0.\n\nOne comment on your LN example: users would have to take note that nForkId\n0 txs would be valid not only on future forks, but on *past* forks too.\nEg, if BCH had been deployed with nForkId 2, then a user setting up BTC LN\ntxs now with nForkId 0 would have to be aware that those txs would be valid\nfor BCH too.  Of course the user could avoid this by funding from a\nBTC-only address, but it is a potential minor pitfall of nForkId 0.  (Which\nI don't see any clean way around.)\n\n\nOn Fri, Nov 10, 2017 at 6:28 AM, Mats Jerratsch \u003cmats at blockchain.com\u003e wrote:\n\n\u003e I guess I wasn't clear on the wildcard, `nForkId=0`\n\u003e\n\u003e This proposal puts Bitcoin at `nForkId=1`, with the purpose of having\n\u003e `nForkId=0` valid on *all* future forks. This means you can create a\n\u003e `nLockTime` transaction, delete the private key and still be assured to not\n\u003e lose potential future tokens.\n\u003e\n\u003e In theory `nForkId=0` could be used for an address too, the sending wallet\n\u003e should display a warning message about unknown side effects though. This\n\u003e address would be future-safe, and you can put it into a safe-deposit box\n\u003e (even though I see little reason to back up an _address_. You would always\n\u003e back up a _private key_, which translates into funds on any fork.)\n\u003e\n\u003e Furthermore, `nForkId=0` can be used for L2 applications. Let's say Alice\n\u003e and Bob open a payment channel. One week later, project X decides to fork\n\u003e the network into a new token, implementing a custom way of providing strong\n\u003e two-way replay protection. The protocol Alice and Bob use for the payment\n\u003e channel has not implemented this new form of replay protection. Alice and\n\u003e Bob now have to make a choice:\n\u003e\n\u003e (1) Ignore this new token. This comes with an evaluation of how much this\n\u003e new token could be worth in the future. They will continue normal channel\n\u003e operation, knowing that their funds on the other branch will be locked up\n\u003e until eternity. When they close their payment channel, the closing\n\u003e transaction will get rejected from the other network, because it's not\n\u003e following the format for replay protected transactions.\n\u003e\n\u003e (2) Close the payment channel before the fork. The transaction, which\n\u003e closes the payment channel has to be mined before the fork, potentially\n\u003e paying a higher-than-normal fee.\n\u003e\n\u003e With this proposal implemented, there are two additional choices\n\u003e\n\u003e (3) Create the commitment transactions with `nForkId=0`. This ensures that\n\u003e when the channel gets closed, funds on other chains are released\n\u003e accordingly. This also means that after the fork, payments on the channel\n\u003e move both, the original token and the new token. Potentially, Alice and Bob\n\u003e want to wait before further transacting on the channel, to see if the token\n\u003e has substantial value. If it has, they can *then* close the channel and\n\u003e open a new channel again. (Note: The funding transaction can use a specific\n\u003e `nForkId`, preventing you from locking up multiple coins when funding the\n\u003e channel, but you can choose to settle with `nForkId=0` to not lock up\n\u003e future coins)\n\u003e\n\u003e (4) Make the protocol aware of different `nForkId`. After the fork, the\n\u003e participants can chose to *only* close the payment channel on the new\n\u003e token, making the payment channel Bitcoin-only again. This is the preferred\n\u003e option, as it means no disruption to the original network.\n\u003e\n\u003e \u003e I like the idea of specifying the fork in bech32 [0]. On the other hand,\n\u003e the standard already has a human readable part. Perhaps the human readable\n\u003e part can be used as the fork id?\n\u003e\n\u003e I was considering this too. On the other hand, it's only _human readable_\n\u003e because thy bytes used currently encode 'bc'. For future forks, this would\n\u003e just be two random letters than, but potentially acceptable.\n\u003e\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20171111/9fb7d5ba/attachment-0001.html\u003e"}