Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id C9F99408 for ; Sat, 11 Nov 2017 05:18:14 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-lf0-f42.google.com (mail-lf0-f42.google.com [209.85.215.42]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 994B61CE for ; Sat, 11 Nov 2017 05:18:13 +0000 (UTC) Received: by mail-lf0-f42.google.com with SMTP id l23so13177399lfk.10 for ; Fri, 10 Nov 2017 21:18:13 -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=VEAF8oBVhHA63nhGKw9vmVXcKE9KAeSQDpl7ThC5QOg=; b=ck9FMY09Q3yUmZdhxIFErIqwRdOn2r4qCvyPoiP1p1VlTcUM5j1nvPn17mLtHI6vHk eezS0QUoUpSWcPCv2BOuj5tq3QMtz6+RYBxMtULtpr//6Mt1D81gO0I9GrvNOABlY6c0 qHPNNf6BPABF3emd2RF8PClfdY/3I1KochocSt5dfpR/l3NMBntXOFsm1HMWx24KLZvi Jo1u3eAZDt0lm8WhAMOo6L/+eJYBHdi2jlzKqCHKYLOT8mD4mI9ypd7PQ7JEPbN756FL tuuo2ZUX/r0hq3HE1hsie+UWTWdVyMrSCfVYUp+aKWcCcnogSU0wxeHqx1zczVLbPI21 w3IQ== 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=VEAF8oBVhHA63nhGKw9vmVXcKE9KAeSQDpl7ThC5QOg=; b=cxTKHdCBS5fRGyOFp7VVGxJSVidkbqSP4LG55C5tetIoTW2PKfdsQ7NamMnMz1om++ /UlEV1SqTW5hsod9/gZtOrO/HI0HvwH5Cj16kSEX9CfAIiH38rYxH0lduXfEMa9/AcC1 6VDLAH3dhKFV7v79WGgyChgc5KRt2huS4DH36+c3k2gH9DAp63ny5/y4QCcWbmalZaV/ pcWh9Hz9N557VOCCBkE5TApFGilBRJN355o3CUEGyBeyTq8z+t8HZjgoXkr/c1MRemRd cR1LXDzMTQ9xXM65yFQwXjpfJwiaXuQilggnvRuyG4ZmGB8tTtd5KsyY5/Un1DyLn3u8 wENg== X-Gm-Message-State: AJaThX6wJewYSOxHKYAO1eGYKD7GqC1QpwqV+9OW9ZCRffGoqtcWkxtG lI4TSIQcw2kC4y4jc8GPCBTmWBk6fcfZ7umIUGM= X-Google-Smtp-Source: AGs4zMZU7X3hACRQCh+1hgfQrEYxjXN1Nw/p+ce8Fs96eIwy+fL9EGBrBKUENqZ0UfA/pqNgR2tJWFfACYooLtZTaKQ= X-Received: by 10.46.75.26 with SMTP id y26mr966024lja.113.1510377491949; Fri, 10 Nov 2017 21:18:11 -0800 (PST) MIME-Version: 1.0 Received: by 10.25.168.7 with HTTP; Fri, 10 Nov 2017 21:18:11 -0800 (PST) In-Reply-To: <3FBEE883-A15E-425C-8BF1-F7792FA63961@blockchain.com> References: <7601C2CD-8544-4501-80CE-CAEB402A72D2@blockchain.com> <45C2D68B-BA8E-47DE-BFA5-643922395B2A@sprovoost.nl> <95ECB451-56AE-45E5-AAE6-10058C4B7FD7@sprovoost.nl> <55467A01-A8B2-4E73-8331-38C0A7CD90EF@sprovoost.nl> <46E317DF-C97C-4797-B989-594298BC6030@sprovoost.nl> <3FBEE883-A15E-425C-8BF1-F7792FA63961@blockchain.com> From: Jacob Eliosoff Date: Sat, 11 Nov 2017 00:18:11 -0500 Message-ID: To: Mats Jerratsch Content-Type: multipart/alternative; boundary="f403045ea286e26e5b055dae299a" X-Spam-Status: No, score=0.4 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_NONE, RCVD_IN_SORBS_SPAM 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: Sat, 11 Nov 2017 14:51:43 +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: Sat, 11 Nov 2017 05:18:14 -0000 --f403045ea286e26e5b055dae299a Content-Type: text/plain; charset="UTF-8" OK, so nForkId 0 is exactly the "valid on all chains" specifier I was asking about, cool. And your LN example (and nLockTime txs in general) illustrate why it's preferable to implement a generic replay protection scheme like yours *in advance*, rather than before each fork: all ad hoc RP schemes I know of break old txs on one of the chains, even when that's not desirable - ie, they offer no wildcard like nForkId 0. One comment on your LN example: users would have to take note that nForkId 0 txs would be valid not only on future forks, but on *past* forks too. Eg, if BCH had been deployed with nForkId 2, then a user setting up BTC LN txs now with nForkId 0 would have to be aware that those txs would be valid for BCH too. Of course the user could avoid this by funding from a BTC-only address, but it is a potential minor pitfall of nForkId 0. (Which I don't see any clean way around.) On Fri, Nov 10, 2017 at 6:28 AM, Mats Jerratsch wrote: > I guess I wasn't clear on the wildcard, `nForkId=0` > > This proposal puts Bitcoin at `nForkId=1`, with the purpose of having > `nForkId=0` valid on *all* future forks. This means you can create a > `nLockTime` transaction, delete the private key and still be assured to not > lose potential future tokens. > > In theory `nForkId=0` could be used for an address too, the sending wallet > should display a warning message about unknown side effects though. This > address would be future-safe, and you can put it into a safe-deposit box > (even though I see little reason to back up an _address_. You would always > back up a _private key_, which translates into funds on any fork.) > > Furthermore, `nForkId=0` can be used for L2 applications. Let's say Alice > and Bob open a payment channel. One week later, project X decides to fork > the network into a new token, implementing a custom way of providing strong > two-way replay protection. The protocol Alice and Bob use for the payment > channel has not implemented this new form of replay protection. Alice and > Bob now have to make a choice: > > (1) Ignore this new token. This comes with an evaluation of how much this > new token could be worth in the future. They will continue normal channel > operation, knowing that their funds on the other branch will be locked up > until eternity. When they close their payment channel, the closing > transaction will get rejected from the other network, because it's not > following the format for replay protected transactions. > > (2) Close the payment channel before the fork. The transaction, which > closes the payment channel has to be mined before the fork, potentially > paying a higher-than-normal fee. > > With this proposal implemented, there are two additional choices > > (3) Create the commitment transactions with `nForkId=0`. This ensures that > when the channel gets closed, funds on other chains are released > accordingly. This also means that after the fork, payments on the channel > move both, the original token and the new token. Potentially, Alice and Bob > want to wait before further transacting on the channel, to see if the token > has substantial value. If it has, they can *then* close the channel and > open a new channel again. (Note: The funding transaction can use a specific > `nForkId`, preventing you from locking up multiple coins when funding the > channel, but you can choose to settle with `nForkId=0` to not lock up > future coins) > > (4) Make the protocol aware of different `nForkId`. After the fork, the > participants can chose to *only* close the payment channel on the new > token, making the payment channel Bitcoin-only again. This is the preferred > option, as it means no disruption to the original network. > > > I like the idea of specifying the fork in bech32 [0]. On the other hand, > the standard already has a human readable part. Perhaps the human readable > part can be used as the fork id? > > I was considering this too. On the other hand, it's only _human readable_ > because thy bytes used currently encode 'bc'. For future forks, this would > just be two random letters than, but potentially acceptable. > > --f403045ea286e26e5b055dae299a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
OK, so nForkId 0 is exactly the "valid on all chains&= quot; specifier I was asking about, cool.=C2=A0 And your LN example (and nL= ockTime txs in general) illustrate why it's preferable to implement a g= eneric replay protection scheme like yours in advance, rather than b= efore each fork: all ad hoc RP schemes I know of break old txs on one of th= e chains, even when that's not desirable - ie, they offer no wildcard l= ike nForkId 0.

One comment on your LN example: users wou= ld have to take note that nForkId 0 txs would be valid not only on future f= orks, but on past forks too.=C2=A0 Eg, if BCH had been deployed with= nForkId 2, then a user setting up BTC LN txs now with nForkId 0 would have= to be aware that those txs would be valid for BCH too.=C2=A0 Of course the= user could avoid this by funding from a BTC-only address, but it is a pote= ntial minor pitfall of nForkId 0.=C2=A0 (Which I don't see any clean wa= y around.)


On Fri, Nov 10, 2017 at 6:28 AM, Mats Jerratsch <mat= s@blockchain.com> wrote:
I guess I = wasn't clear on the wildcard, `nForkId=3D0`

This proposal puts Bitcoin= at `nForkId=3D1`, with the purpose of having `nForkId=3D0` valid on *all* = future forks. This means you can create a `nLockTime` transaction, delete t= he private key and still be assured to not lose potential future tokens.

In= theory `nForkId=3D0` could be used for an address too, the sending wallet = should display a warning message about unknown side effects though. This ad= dress would be future-safe, and you can put it into a safe-deposit box (eve= n though I see little reason to back up an _address_. You would always back= up a _private key_, which translates into funds on any fork.)

Furthermore,= `nForkId=3D0` can be used for L2 applications. Let's say Alice and Bob= open a payment channel. One week later, project X decides to fork the netw= ork into a new token, implementing a custom way of providing strong two-way= replay protection. The protocol Alice and Bob use for the payment channel = has not implemented this new form of replay protection. Alice and Bob now h= ave to make a choice:

(1) Ignore this new token. This comes with an evaluat= ion of how much this new token could be worth in the future. They will cont= inue normal channel operation, knowing that their funds on the other branch= will be locked up until eternity. When they close their payment channel, t= he closing transaction will get rejected from the other network, because it= 's not following the format for replay protected transactions.

(2) Clos= e the payment channel before the fork. The transaction, which closes the pa= yment channel has to be mined before the fork, potentially paying a higher-= than-normal fee.

With this proposal implemented, there are two additional c= hoices

(3) Create the commitment transactions with `nForkId=3D0`. This ensu= res that when the channel gets closed, funds on other chains are released a= ccordingly. This also means that after the fork, payments on the channel mo= ve both, the original token and the new token. Potentially, Alice and Bob w= ant to wait before further transacting on the channel, to see if the token = has substantial value. If it has, they can *then* close the channel and ope= n a new channel again. (Note: The funding transaction can use a specific `n= ForkId`, preventing you from locking up multiple coins when funding the cha= nnel, but you can choose to settle with `nForkId=3D0` to not lock up future= coins)

(4) Make the protocol aware of different `nForkId`. After the fork,= the participants can chose to *only* close the payment channel on the new = token, making the payment channel Bitcoin-only again. This is the preferred= option, as it means no disruption to the original network.

> I like the idea of specifying the fork in bech32 [0]. On the other h= and, the standard already has a human readable part. Perhaps the human read= able part can be used as the fork id?
I was considering this too. On= the other hand, it's only _human readable_ because thy bytes used curr= ently encode 'bc'. For future forks, this would just be two random = letters than, but potentially acceptable.=C2=A0


--f403045ea286e26e5b055dae299a--