MIME-Version: 1.0
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"
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Generalised Replay Protection for Future Hard
	Forks
Precedence: list

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