path: root/c1/3205d4a3993992150d21613d696bbe7b093c29

Return-Path: <jacob.eliosoff@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id C9F99408
	for <bitcoin-dev@lists.linuxfoundation.org>;
	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 <bitcoin-dev@lists.linuxfoundation.org>;
	Sat, 11 Nov 2017 05:18:13 +0000 (UTC)
Received: by mail-lf0-f42.google.com with SMTP id l23so13177399lfk.10
	for <bitcoin-dev@lists.linuxfoundation.org>;
	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>
	<CAAUaCyii2U5VBLS+Va+F3h4Hka0OWDnFFmjtsvyaaD4TKVzV3Q@mail.gmail.com>
	<CAAUaCyiZ0bmWZLZc-yDvVHupzbdRR=Kdq4P8VkWqpU1L3G-u3A@mail.gmail.com>
	<C9A47922-5777-44AC-871A-6C27A22054AC@blockchain.com>
	<CAAUaCyjVxJbPrbBUdb9irK5CNnuqUSnzSjywpozhLqONcb_m_w@mail.gmail.com>
	<45C2D68B-BA8E-47DE-BFA5-643922395B2A@sprovoost.nl>
	<CAAUaCygeOxAK=EpzfWndx6uVvVO9B+=YTs1m-jHa3BFp82jA4w@mail.gmail.com>
	<95ECB451-56AE-45E5-AAE6-10058C4B7FD7@sprovoost.nl>
	<CAAUaCyg_PGT0F=RHfX89T54j-vuyz5wcbXaYoikJv95WKgsNPg@mail.gmail.com>
	<55467A01-A8B2-4E73-8331-38C0A7CD90EF@sprovoost.nl>
	<CAAUaCyhncyCt_ao9i0=33LswDOkCf6o-+36zrGxKWD+WranmZw@mail.gmail.com>
	<46E317DF-C97C-4797-B989-594298BC6030@sprovoost.nl>
	<CAAUaCyibOEHqw1J5O8yEp8v=j8t9sovn2vn=S8bZPZCzCY-gRw@mail.gmail.com>
	<3FBEE883-A15E-425C-8BF1-F7792FA63961@blockchain.com>
From: Jacob Eliosoff <jacob.eliosoff@gmail.com>
Date: Sat, 11 Nov 2017 00:18:11 -0500
Message-ID: <CAAUaCyg70uUnUp1Q0a6kEoQ1Js68VFLgthyfwyMQaaEqO8R-UQ@mail.gmail.com>
To: Mats Jerratsch <mats@blockchain.com>
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 <bitcoin-dev@lists.linuxfoundation.org>
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 <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=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 <mats@blockchain.com> 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

<div dir=3D"ltr">OK, so nForkId 0 is exactly the &quot;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&#39;s preferable to implement a g=
eneric replay protection scheme like yours <i>in advance</i>, 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&#39;s not desirable - ie, they offer no wildcard l=
ike nForkId 0.<div><br></div><div>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 <i>past</i> 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&#39;t see any clean wa=
y around.)</div><div><br></div></div><div class=3D"gmail_extra"><br><div cl=
ass=3D"gmail_quote">On Fri, Nov 10, 2017 at 6:28 AM, Mats Jerratsch <span d=
ir=3D"ltr">&lt;<a href=3D"mailto:mats@blockchain.com" target=3D"_blank">mat=
s@blockchain.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote"=
 style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><d=
iv style=3D"word-wrap:break-word"><span style=3D"font-size:15px">I guess I =
wasn&#39;t clear on the wildcard, `nForkId=3D0`</span><div style=3D"font-si=
ze:15px"><br></div><div style=3D"font-size:15px">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.</d=
iv><div style=3D"font-size:15px"><br></div><div style=3D"font-size:15px">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.)</div><div st=
yle=3D"font-size:15px"><br></div><div style=3D"font-size:15px">Furthermore,=
 `nForkId=3D0` can be used for L2 applications. Let&#39;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:</div><div style=3D"font-size:15px"><br></div><div sty=
le=3D"font-size:15px">(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=
&#39;s not following the format for replay protected transactions.</div><di=
v style=3D"font-size:15px"><br></div><div style=3D"font-size:15px">(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.</div><div style=3D"font-size:15px"><br></div><div style=3D=
"font-size:15px">With this proposal implemented, there are two additional c=
hoices</div><div style=3D"font-size:15px"><br></div><div style=3D"font-size=
:15px">(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)</div><div style=3D"font-size:15px"><br></div><div style=3D"font-siz=
e:15px">(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.</div><span clas=
s=3D""><div style=3D"font-size:15px"><br></div><div style=3D"font-size:15px=
">&gt; 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?</div><div style=3D"font-size:15px"><b=
r></div></span><div style=3D"font-size:15px">I was considering this too. On=
 the other hand, it&#39;s only _human readable_ because thy bytes used curr=
ently encode &#39;bc&#39;. For future forks, this would just be two random =
letters than, but potentially acceptable.=C2=A0</div><div style=3D"font-siz=
e:15px"><br></div></div></blockquote></div><br></div>

--f403045ea286e26e5b055dae299a--