From: Mats Jerratsch <mats@blockchain.com>
Message-Id: <3FBEE883-A15E-425C-8BF1-F7792FA63961@blockchain.com>
Content-Type: multipart/signed;
	boundary="Apple-Mail=_09F87902-A8BC-478C-9D30-E6FC273B2C66";
	protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Date: Fri, 10 Nov 2017 11:28:06 +0000
In-Reply-To: <CAAUaCyibOEHqw1J5O8yEp8v=j8t9sovn2vn=S8bZPZCzCY-gRw@mail.gmail.com>
To: Jacob Eliosoff <jacob.eliosoff@gmail.com>,
	Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
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>
Subject: Re: [bitcoin-dev] Generalised Replay Protection for Future Hard
	Forks
Precedence: list


--Apple-Mail=_09F87902-A8BC-478C-9D30-E6FC273B2C66
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_E20B3D60-FE82-454C-ACB8-FAB724075543"


--Apple-Mail=_E20B3D60-FE82-454C-ACB8-FAB724075543
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

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 the 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 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=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 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=3D0`. 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=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 =
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.


--Apple-Mail=_E20B3D60-FE82-454C-ACB8-FAB724075543
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html =
charset=3Dus-ascii"></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" =
class=3D""><span style=3D"font-size: 15px;" class=3D"">I guess I wasn't =
clear on the wildcard, `nForkId=3D0`</span><div style=3D"font-size: =
15px;" class=3D""><br class=3D""></div><div style=3D"font-size: 15px;" =
class=3D"">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 the private key and still be =
assured to not lose potential future tokens.</div><div style=3D"font-size:=
 15px;" class=3D""><br class=3D""></div><div style=3D"font-size: 15px;" =
class=3D"">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 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.)</div><div style=3D"font-size: 15px;" =
class=3D""><br class=3D""></div><div style=3D"font-size: 15px;" =
class=3D"">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 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:</div><div =
style=3D"font-size: 15px;" class=3D""><br class=3D""></div><div =
style=3D"font-size: 15px;" class=3D"">(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.</div><div style=3D"font-size: 15px;" =
class=3D""><br class=3D""></div><div style=3D"font-size: 15px;" =
class=3D"">(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.</div><div =
style=3D"font-size: 15px;" class=3D""><br class=3D""></div><div =
style=3D"font-size: 15px;" class=3D"">With this proposal implemented, =
there are two additional choices</div><div style=3D"font-size: 15px;" =
class=3D""><br class=3D""></div><div style=3D"font-size: 15px;" =
class=3D"">(3) Create the commitment transactions with `nForkId=3D0`. =
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=3D0` to not lock up future coins)</div><div =
style=3D"font-size: 15px;" class=3D""><br class=3D""></div><div =
style=3D"font-size: 15px;" class=3D"">(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><div style=3D"font-size: 15px;" =
class=3D""><br class=3D""></div><div style=3D"font-size: 15px;" =
class=3D"">&gt; 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?</div><div =
style=3D"font-size: 15px;" class=3D""><br class=3D""></div><div =
style=3D"font-size: 15px;" class=3D"">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.&nbsp;</div><div style=3D"font-size: =
15px;" class=3D""><br class=3D""></div></body></html>=

--Apple-Mail=_E20B3D60-FE82-454C-ACB8-FAB724075543--

--Apple-Mail=_09F87902-A8BC-478C-9D30-E6FC273B2C66
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - https://gpgtools.org

iQIcBAEBCgAGBQJaBY1HAAoJEAYZmwZ/PsbKcFsQAM1O0c2lrlCqaTrUug05ZKZr
KeLla73/NMBPbMgVnIriwKGijQBJ/UW76/TAWVGLOYx6C4TxtUnf75r/LsRUCEcF
lX4GtMVurzHWQNOjUNjYXh1vzAGedlN+G34wUI6VbBmdr8eco//KBJqWNCNV/F29
GHFiPtoI5x43LvJa8AeFO7htaiQAhyu3PfTNFZk9BO3xNUUK8nDN5cPvd/1cWEYl
asumhh8FZOKyAmbduuoMlReAWxfdtRHVIHT49wkooUN5kjqohtjry9lePYm/UHfk
yEYQ4YAyY1key0Q5u8DnLUR/8l1hHLWttEoOayg/+m+HPsJsOG36cORzDfdsihDP
XjMfyS1ze5xfDOusrxI5EOSQ51ikNqud2Mp52vFaO8zWL+q/y6S7UjA+fXT72WAS
9TPSYzrD4cct03pW7zEKTwVr9EtjJk4B9kl39a2EapXzQm9Onqybyw9ulm1oNWoz
TaEsfmRfs4RPfFCEcuPpgtlH8azYGbomQ+0ZBfd3Wa1iMhqMYABNX7JJ1ZaWz9zY
uGk5gEDiyNO1xJrJVuPVEpEInwUJqslq1dsIiib4MqZTdhFJ3biX32dre47Yrtpk
ltuIoA1ai5qdY6vuYsVpTnsGjmE3QSOzDAVWWN4vEf4iqUB882XpaiFUymccD+fQ
Wy+G9+SFc12Ndy6K5ATG
=pIiO
-----END PGP SIGNATURE-----

--Apple-Mail=_09F87902-A8BC-478C-9D30-E6FC273B2C66--