> But I like the 'old' idea of putting the hash of a block that MUST be on the > chain that this txn can eventually be added to. If the hash is not a valid > block on the chain, the txn can't be added. > > It means you can choose exactly which forks you want to allow your txn on, > pre-fork for both, post-fork for only one, and gets round the issue of who > gets to decide the nForkid value.. since you don't need one. Also, all the > old outputs work fine, and LN not an issue. > > I'm missing why this scheme would be better ?
I do agree that solutions like `SIGHASH_BLOCKCOMMIT` are superior in the sense that they are very difficult to circumvent. However, a fork could also follow the original chain in SPV mode and allow transactions protected with these mechanism. Since it's fundamentally impossible to disallow transactions in future projects, the goal shouldn't be to make this overly complicated. Furthermore, this schema is not just adding replay protection. It makes transacting safer overall (due to a dedicated address format per fork) and allows light clients to differentiate between multiple forks. In the past three months, at least $600k has been lost by users sending BCH to a BTC address [1]. > 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. Whether the transaction is replay protected or not is specified by setting a bit in the `SigHashId`. If this bit is set, then the signature *preimage* MUST have `nForkId` appended. `nForkId` is not part of the final transaction, someone who wants to verify the transaction must know which `nForkId` it was created with. If the bit isn't set, it means `nForkId=0`, which allows other forks to validate the signature. > 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... Sorry, I was careless with the use of `>=` there. You are correct, forks form a tree. For this proposal, every leaf must be assigned a unique `nForkId`. The relationship between `nForkId` is irrelevant (e.g. which number is bigger), as long as they are unique. Transactions are only valid IFF `nForkId` matches exactly the `nForkId` of the software validating it. As described above, the transaction doesn't even contain `nForkId`, and the node surely is not starting to guess which one it could be. [1] https://twitter.com/khannib/status/930223617744437253 <https://twitter.com/khannib/status/930223617744437253>
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
