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