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.
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
