đ
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>;
Jacob Eliosoff [ARCHIVE] /
npub1mlâŚ4yf8d
2023-06-07 18:07:35
in reply to nevent1qâŚ74y4
Author Public Key
npub1mlpmsc5sm93tw2fp2dhhuwmxcqm59wz6hjg5g3afq5rucfll3f9sh4yf8dPublished at
2023-06-07 18:07:35Event JSON
{
"id": "354d8840685bfa46e242602fe31a68bc878e95a0c88610550eb645f789079086",
"pubkey": "dfc3b86290d962b72921536f7e3b66c03742b85abc914447a90507cc27ff8a4b",
"created_at": 1686161255,
"kind": 1,
"tags": [
[
"e",
"d0daeb8199b756e145149a8bfc51c2a5ebb412995a4c001676e8f12b1a7c8b95",
"",
"root"
],
[
"e",
"04bad2c1e858c8f0ee37b915af9668ee1591980fabdf972f0f347e132add1d44",
"",
"reply"
],
[
"p",
"b8a27d18150405cdfcd44c0dd8db860f5270312300248389bf57ce555c784528"
]
],
"content": "đ
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",
"sig": "51da32814583ee443c64d30dada380f4397267545a414d87253bc081ee0004a93891f1be64323983a8da977457a0d65e64f9a3be2d02dddb403c6ccc196d1c7a"
}