path: root/18/38b79c6854f44db2c9c8112c70c8773b748bce

Return-Path: <mats@blockchain.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 9019F989
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri, 10 Nov 2017 11:28:12 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wr0-f170.google.com (mail-wr0-f170.google.com
	[209.85.128.170])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 996988A
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri, 10 Nov 2017 11:28:11 +0000 (UTC)
Received: by mail-wr0-f170.google.com with SMTP id o88so8302425wrb.6
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri, 10 Nov 2017 03:28:11 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=blockchain.com; s=google;
	h=from:message-id:mime-version:subject:date:in-reply-to:cc:to
	:references; bh=iTsKMG06N9stZ8xn+MRaSyP8Mj+UDutLjCqj1aixa2Q=;
	b=BjCIxp4IQf62XS9WrA7GPt16ShNFLKc9f4X3syMLOhypo22t7PhmQSlAq3yJs7HS8B
	i/oSxaNLDGWo4gk+ScCm9a2Mrm0dcBdvkjDpuW+nLdRo3SCOw2qBOXTr0KEC1Dm4MqJE
	tm9T93CgDtp4zlDsScx30ReV+mL2gGBOCA9Ks=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20161025;
	h=x-gm-message-state:from:message-id:mime-version:subject:date
	:in-reply-to:cc:to:references;
	bh=iTsKMG06N9stZ8xn+MRaSyP8Mj+UDutLjCqj1aixa2Q=;
	b=kORUHW57m9p91LIM8+2ioU+Uw28PoqjfNtDRjo3Lq0V8YS9kLL3Uwldv/06AvkgD0B
	ZfObp/V0za4rJrllBVZw10OInDRFAlk2q9poUEBuKQhBvhitHUhzG3N3bVN+oC8Ml7q/
	Y1U3j3K8JWRBt1z/nHFWc5x/M1B+wBSXHPjZ36llav54fsaSMvlt0xTZoSJdYaCUAm9x
	7pygPxZWqgrrjcgqaJgA0sk/sSwP9qZft47K+CK5TPw1P4ogVhh2wW1zmMDOBJK1O9eV
	yQP8dr0OPNcRrYnv9FpN3290zWHcGpwzCP3vluKHJwzhR/aA1ukA2QiXWjatSIFsLmsD
	OFvQ==
X-Gm-Message-State: AJaThX4qN/IboksB+973RYmZAcAJEeDHW4IJeWZrAsXBfsHC1jHtWr6j
	Cs/VMYnhSjNhicxnkcRiQN2jBQ==
X-Google-Smtp-Source: ABhQp+TglJDieVoott1dRZu+nPWTnCzkmCadP32TWGBnSKHkBMfn+9T8fQZYtttSxgYm9fEt5fVK0Q==
X-Received: by 10.223.165.67 with SMTP id j3mr2927945wrb.271.1510313290103;
	Fri, 10 Nov 2017 03:28:10 -0800 (PST)
Received: from [10.2.1.168] ([212.161.45.230])
	by smtp.gmail.com with ESMTPSA id
	o8sm24795483wrc.10.2017.11.10.03.28.08
	(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Fri, 10 Nov 2017 03:28:08 -0800 (PST)
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>
X-Mailer: Apple Mail (2.3273)
X-Spam-Status: No, score=-0.1 required=5.0 tests=DKIM_SIGNED,DKIM_VALID,
	DKIM_VALID_AU, 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: Fri, 10 Nov 2017 23:42:47 +0000
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: Fri, 10 Nov 2017 11:28:12 -0000


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