From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id AC07B504 for ; Thu, 9 Nov 2017 20:45:47 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-lf0-f51.google.com (mail-lf0-f51.google.com [209.85.215.51]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id C8DC8478 for ; Thu, 9 Nov 2017 20:45:46 +0000 (UTC) Received: by mail-lf0-f51.google.com with SMTP id n69so8724415lfn.2 for ; Thu, 09 Nov 2017 12:45:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=D8umICwEXu62SpWhXqJUftFMQPpJ0CJ8VB0y7ZnEUn8=; b=OgnXSi2GoHp0TMYl7JKQ7ii6+3XV6CUVUJ4wGDTlQsQH0FnVoLDyYqjr5au5kA95CJ xK0zZt0X61zykls0aHUsPKRA9Bxsj1PGiIGwdx7EeEKISLX1LZ/WIrSkAyddqxFGEwIe 7KwXZnFwYul+8jW4ddq42iv+DvX3jSKI5aVY2M/Gxpr67irVPUUPlM3Kr1KXbTBHsQeS kMHPXjLxeNsGhNMWunVZxTQvRdoHFq0raY27EYd+B2nHL0jLEHJPvNz29t5zALJeo0ji HqyyVHnfmWuBoBKqqaWbYa260ca4cmxCRkj7PBKo3fjeDJWYrM76rieaCUkQANvEen/m R9ZA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=D8umICwEXu62SpWhXqJUftFMQPpJ0CJ8VB0y7ZnEUn8=; b=qMIn5NnHcgvRH/w/HzvvVHDZk/8iUTBgTvK+1GBei4Ivqi4r81q3uTDj0OkxtTRRfN yQ/gUBlpiJEPfuifzRNxHwLpE7vKiN48JqSHl0dEO8pYtR6C5XiNLSgDujmlflpsRR1C FFPSnT6esFiOmrUOsyXGqI2Kq5W6p8SitCPurOoZUbOCm6lbL+jE9lMt75Sfbwyaafm9 Rq3kSBnxktjYzqm6czuCDNMNOTS/1hhFgba5lbsSSRlwDob120w1VIdg6ejlx+3GfWb+ TeVQd5hjvJ6bu2MxAtGbOpNqi6HbrVpwUkBaHLrgGKlDPZY4BVnFw33XiS/7FNbDd6ir Xl2g== X-Gm-Message-State: AJaThX73yWGlDm/n6PiCG0snnVY57ytv+larK/KHivDrKf1ZzqyNLqdo 3BQx++HyNCMXXHbwDdT5FgbttaKNImxinQ+oLDA= X-Google-Smtp-Source: AGs4zMaBZuerrvINc2hNKvs17fEquugIV7qPl546g9NsrxKFP4JJkPqYYm9REmqOtuKCiRoJzpT+iaNhV4Dr3zaFmRw= X-Received: by 10.25.217.66 with SMTP id q63mr755055lfg.176.1510260345218; Thu, 09 Nov 2017 12:45:45 -0800 (PST) MIME-Version: 1.0 Received: by 10.25.168.7 with HTTP; Thu, 9 Nov 2017 12:45:43 -0800 (PST) Received: by 10.25.168.7 with HTTP; Thu, 9 Nov 2017 12:45:43 -0800 (PST) In-Reply-To: References: <7601C2CD-8544-4501-80CE-CAEB402A72D2@blockchain.com> From: Jacob Eliosoff Date: Thu, 9 Nov 2017 15:45:43 -0500 Message-ID: To: Mats Jerratsch Content-Type: multipart/alternative; boundary="94eb2c184b14652b42055d92e3e8" X-Spam-Status: No, score=-0.1 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_NONE autolearn=disabled version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org X-Mailman-Approved-At: Thu, 09 Nov 2017 20:47:56 +0000 Cc: Bitcoin Dev Subject: Re: [bitcoin-dev] Generalised Replay Protection for Future Hard Forks X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Nov 2017 20:45:47 -0000 --94eb2c184b14652b42055d92e3e8 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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" 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 wall= et > 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=E2=82=AC, 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. > > --94eb2c184b14652b42055d92e3e8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
OK, I see.=C2=A0=C2=A0On the whole this is the best replay protection solution I've seen.= =C2=A0 In particular, I hope developers of Bech32 and other new address for= mats will take a close look at incorporating a fork ID this way.
As I u= nderstand 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 w= as generated for.=C2=A0 There may be cold-storage-type cases where it's= important for an address to be valid across all chains, ie, to intentional= ly allow replay?=C2=A0 But I guess this could just be a special nForkId val= ue, say -1?

=

On Nov 8, 2= 017 9:45 AM, "Mats Jerratsch" <mats@blockchain.com> wrote:
Hey Jacob!

> Take the specific and common case of non-upgraded wallet software.=C2= =A0 Suppose a HF happens, and becomes the network used by 90% of users.=C2= =A0 Will old wallets still default to the old nForkId (10% legacy chain)?= =C2=A0 If so, I'd expect a lot of accidental mis-sends on that chain.
With this proposal implemented, a 'mis-send' is fundamentally impos= sible. 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 recei= ver actually wanted to receive the newer token, but instead his wallet crea= ted 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 t= oo, so this seems like a reasonable trade-off.

I would even argue that this should hold in a legal case, where the receive= r cannot claim that he was expecting a payment in another token (contrary t= o 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=E2=82=AC, I cannot later proclaim that I actually expe= cted $100.

With this proposal, wallets are finally able to distinguish between differe= nt tokens. With this ability, I expect to see different implementations, so= me wallets which advertise staying conservative, following a strict ruleset= , and other wallets being more experimental, following hashing rate or othe= r metrics.

--94eb2c184b14652b42055d92e3e8--