Re: [bitcoin-dev] Generalised Replay Protection for Future Hard Forks

[Jacob Eliosoff <jacob.eliosoff@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 2279 bytes --]

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@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.
>
>

[-- Attachment #2: Type: text/html, Size: 2741 bytes --]