{"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-06\n📝 Original message:Thanks Mats, this proposal makes sense to me (especially the idea of\nfork-specific addresses).  It prevents replay across forks, and makes it\neasy for client software, and thus potentially users, to specify which fork\na tx is for.  But, like other (rougher) past proposals I've seen, it does\nlittle to prevent users from accidentally sending on the wrong fork.\n\nTake the specific and common case of non-upgraded wallet software.  Suppose\na HF happens, and becomes the network used by 90% of users.  Will old\nwallets still default to the old nForkId (10% legacy chain)?  If so, I'd\nexpect a lot of accidental mis-sends on that chain.\n\nThis is just a gap in your proposal, not a flaw, but it's worth thinking\nabout less hazard-prone ways wallets could default nForkId.  Perhaps they\ncould listen to all forks, and default to the one whose last (recent) block\nhad the highest difficulty?  Or just check those blocks to see if multiple\nforks are (nontrivially) active, and if so warn the user and force them to\nconfirm?  Something like that.\n\n\nOn Nov 6, 2017 7:05 AM, \"Mats Jerratsch via bitcoin-dev\" \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\nPresented is a generalised way of providing replay protection for future\nhard forks. On top of replay protection, this schema also allows for\nfork-distinct addresses and potentially a way to opt-out of replay\nprotection of any fork, where deemed necessary (can be beneficial for some\nL2 applications).\n\n## Rationale\n\nCurrently when a hard fork happens, there is ad-hoc replay protection built\nwithin days with little review at best, or no replay protection at all.\nOften this is either resource problem, where not enough time and developers\nare available to sufficiently address replay protection, or the idea that\nnot breaking compatibility is favourable. Furthermore, this is potentially\na recurring problem with no generally accepted solution yet. Services that\nwant to deal in multiple forks are expected to closely follow all projects.\nSince there is no standard, the solutions differ for each project,\nrequiring custom code for every fork. By integrating replay protection into\nthe protocol, we advocate the notion of non-hostile forks.\n\nUsers are protected against accidentally sending coins on the wrong chain\nthrough the introduction of a fork-specific incompatible address space. The\ncoin/token type is encoded in the address itself, removing some of the\nimportance around the question _What is Bitcoin?_. By giving someone an\naddress, it is explicitly stated _I will only honour a payment of token X_,\nenforcing the idea of validating the payment under the rules chosen by the\npayee.\n\n## Iterative Forks\n\nIn this schema, any hard fork is given an incremented id, `nForkId`.\n`nForkId` starts at `1`, with `0` being reserved as a wildcard. When\nproject X decides to make an incompatible change to the protocol, it will\nget assigned a new unique `nForkId` for this fork. A similar approach like\nfor BIP43 can be taken here. Potentially `nForkId` can be reused if a\nproject has not gained any amount of traction.\n\nWhen preparing the transaction for signing or validation, `nForkId` is\nappended to the final template as a 4B integer (similar to [1]). Amending\nBIP143, this would result in\n\n```\nDouble SHA256 of the serialization of:\n    1. nVersion of the transaction (4-byte little endian)\n    2. hashPrevouts (32-byte hash)\n    3. hashSequence (32-byte hash)\n    4. outpoint (32-byte hash + 4-byte little endian)\n    5. scriptCode of the input (serialized as scripts inside CTxOuts)\n    6. value of the output spent by this input (8-byte little endian)\n    7. nSequence of the input (4-byte little endian)\n    8. hashOutputs (32-byte hash)\n    9. nLocktime of the transaction (4-byte little endian)\n   10. sighash type of the signature (4-byte little endian)\n   11. nForkId (4-byte little endian)\n```\n\n\nFor `nForkId=0` this step is ommitted. This will immediately invalidate\nsignatures for any other branch of the blockchain than this specific fork.\nTo distinguish between `nForkId=0` and `nForkId` hardcoded into the\nsoftware, another bit has to be set in the 1B SigHashId present at the end\nof signatures.\n\nTo make this approach more generic, payment addresses will contain the fork\nid, depending on which tokens a payee expects payments in. This would\nrequire a change on bech32 addresses, maybe to use a similar format used in\nlightning-rfc [2]. A wallet will parse the address, it will extract\n`nForkId`, and it displays which token the user is about to spend. When\nsigning the transaction, it will use `nForkId`, such that the transaction\nis only valid for this specific token. This can be generalised in software\nto the point where replay protection *and* a new address space can be\nintroduced for forks without breaking existing clients.\n\nFor light clients, this can be extended by enforcing the coinbase/block\nheader to contain the `nForkId` of the block. Then the client can\ndistinguish between different chains and tokens it received on each.\nAlternatively, a new P2P message type for sending transactions could be\nintroduced, where prevOut and `nForkId` is transmitted, such that the lite\nclient can check for himself, which token he received.\n\nAllowing signatures with `nForkId=1` can be achieved with a soft fork by\nincrementing the script version of SegWit, making this a fully backwards\ncompatible change.\n\n[1]\nhttps://lists.linuxfoundation.org/pipermail/bitcoin-dev/\n2017-February/013542.html\n\n[2]\nhttps://github.com/lightningnetwork/lightning-rfc/blob/master/11-payment-\nencoding.md\n\n_______________________________________________\nbitcoin-dev mailing list\nbitcoin-dev at lists.linuxfoundation.org\nhttps://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20171106/91e3799f/attachment.html\u003e"}