š
Original date posted:2017-11-08
š Original message: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 --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20171108/eef251dc/attachment.sig>;
Mats Jerratsch [ARCHIVE] /
npub1hzā¦q5x8w
2023-06-07 18:07:35
in reply to nevent1qā¦8gvh
Author Public Key
npub1hz386xq4qszumlx5fsxa3kuxpaf8qvfrqqjg8zdl2l892hrcg55q6q5x8wPublished at
2023-06-07 18:07:35Event JSON
{
"id": "04bad2c1e858c8f0ee37b915af9668ee1591980fabdf972f0f347e132add1d44",
"pubkey": "b8a27d18150405cdfcd44c0dd8db860f5270312300248389bf57ce555c784528",
"created_at": 1686161255,
"kind": 1,
"tags": [
[
"e",
"d0daeb8199b756e145149a8bfc51c2a5ebb412995a4c001676e8f12b1a7c8b95",
"",
"root"
],
[
"e",
"853739cc0fd13c0572b033f06646196f6725d7825374090a1fd212f25a274d37",
"",
"reply"
],
[
"p",
"dfc3b86290d962b72921536f7e3b66c03742b85abc914447a90507cc27ff8a4b"
]
],
"content": "š
Original date posted:2017-11-08\nš Original message:Hey Jacob!\n\n\u003e 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.\n\nWith this proposal implemented, a 'mis-send' is fundamentally impossible. The address contains the identifier of the token that should be sent.\n\nIf anything, it's possible to 'mis-receive'.\nThat 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.\n\nI 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.\n\nWith 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.\n\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 842 bytes\nDesc: Message signed with OpenPGP\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20171108/eef251dc/attachment.sig\u003e",
"sig": "1ee26121d54bfb49275a018fee4c93cef18a08e53a6910dcea6dc3cf780e0ffd85037bc01211705bad0adf3fafb71a19efab5d7651191e57370a7b3b0aeaa4b4"
}