{"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-09\n📝 Original message:OK, I see.  On the whole this is the best replay protection solution I've\nseen.  In particular, I hope developers of Bech32 and other new address\nformats will take a close look at incorporating a fork ID this way.\n\nAs I understand you, a private key in cold storage would (of course) remain\nvalid across HFs, but an *address* would be valid only for the nForkId it\nwas generated for.  There may be cold-storage-type cases where it's\nimportant for an address to be valid across all chains, ie, to\nintentionally allow replay?  But I guess this could just be a special\nnForkId value, say -1?\n\n\nOn Nov 8, 2017 9:45 AM, \"Mats Jerratsch\" \u003cmats at blockchain.com\u003e wrote:\n\n\u003e Hey Jacob!\n\u003e\n\u003e \u003e Take the specific and common case of non-upgraded wallet software.\n\u003e Suppose a HF happens, and becomes the network used by 90% of users.  Will\n\u003e old wallets still default to the old nForkId (10% legacy chain)?  If so,\n\u003e I'd expect a lot of accidental mis-sends on that chain.\n\u003e\n\u003e With this proposal implemented, a 'mis-send' is fundamentally impossible.\n\u003e The address contains the identifier of the token that should be sent.\n\u003e\n\u003e If anything, it's possible to 'mis-receive'.\n\u003e That is, the receiving wallet was not aware of a newer chain, and the\n\u003e receiver actually wanted to receive the newer token, but instead his wallet\n\u003e created an address for the old token. It is the responsibility of the\n\u003e receiver to write a correct invoice. This is the case everywhere else in\n\u003e the world too, so this seems like a reasonable trade-off.\n\u003e\n\u003e I would even argue that this should hold in a legal case, where the\n\u003e receiver cannot claim that he was expecting a payment in another token\n\u003e (contrary to how it is today, like when users send BTC to a BCH address,\n\u003e losing their funds with potentially no legal right for reimbursement). If I\n\u003e sent someone an invoice over 100€, I cannot later proclaim that I actually\n\u003e expected $100.\n\u003e\n\u003e With this proposal, wallets are finally able to distinguish between\n\u003e different tokens. With this ability, I expect to see different\n\u003e implementations, some wallets which advertise staying conservative,\n\u003e following a strict ruleset, and other wallets being more experimental,\n\u003e following hashing rate or other metrics.\n\u003e\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20171109/b20d9108/attachment.html\u003e"}