From: Mats Jerratsch <mats@blockchain.com>
Message-Id: <24A6C651-272B-4452-8A81-31651D9A2694@blockchain.com>
Content-Type: multipart/signed;
	boundary="Apple-Mail=_2457BA2C-F57A-434A-A52D-A5B22CBDE230";
	protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Date: Mon, 13 Nov 2017 10:03:04 +0000
In-Reply-To: <CAAUaCyg70uUnUp1Q0a6kEoQ1Js68VFLgthyfwyMQaaEqO8R-UQ@mail.gmail.com>
To: Jacob Eliosoff <jacob.eliosoff@gmail.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>
	<CAAUaCyg70uUnUp1Q0a6kEoQ1Js68VFLgthyfwyMQaaEqO8R-UQ@mail.gmail.com>
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Generalised Replay Protection for Future Hard
	Forks
Precedence: list


--Apple-Mail=_2457BA2C-F57A-434A-A52D-A5B22CBDE230
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_6FFDF190-74D2-4956-87E6-F1C1C5352C56"


--Apple-Mail=_6FFDF190-74D2-4956-87E6-F1C1C5352C56
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii


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

Exactly!

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

This is actually incorrect. There are two transactions involved in LN. =
The funding transaction, which opens a payment channel, and a commitment =
transaction, which closes the channel when broadcasted to the network =
(the cooperative closing transaction can be considered a commitment =
transaction in a loose sense).

Now you want to protect the funding transaction, as otherwise you would =
be subject to a replay-attack on all *past* forks. So you will set =
`nForkId>=3D1` for the funding transaction, making this payment channel =
non-existent on any *past* forks. However, if during the lifetime of the =
payment channel another fork happens, the payment channel exists for =
both tokens. So for the commitment transaction, you will have =
`nForkId=3D0`, making it valid on both of these chains. While this =
`nForkId` is valid on all chains, the parent transaction it tries to =
spend (the funding transaction) does only exist on two chains, the =
original one you created the channel for and the one that forked away.

--Apple-Mail=_6FFDF190-74D2-4956-87E6-F1C1C5352C56
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""><div><br class=3D""><blockquote type=3D"cite" class=3D""><div =
class=3D""><div dir=3D"ltr" class=3D"">OK, so nForkId 0 is exactly the =
"valid on all chains" specifier I was asking about, cool.&nbsp; And your =
LN example (and nLockTime txs in general) illustrate why it's preferable =
to implement a generic replay protection scheme like yours <i =
class=3D"">in advance</i>, 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.</div></div></blockquote><div><br =
class=3D""></div><div>Exactly!</div><div><br class=3D""></div><blockquote =
type=3D"cite" class=3D""><div class=3D""><div dir=3D"ltr" class=3D""><div =
class=3D"">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 <i =
class=3D"">past</i> forks too.&nbsp; 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.&nbsp; Of =
course the user could avoid this by funding from a BTC-only address, but =
it is a potential minor pitfall of nForkId 0.&nbsp; (Which I don't see =
any clean way around.)</div></div>
</div></blockquote></div><br class=3D""><div class=3D"">This is actually =
incorrect. There are two transactions involved in LN. The funding =
transaction, which opens a payment channel, and a commitment =
transaction, which closes the channel when broadcasted to the network =
(the cooperative closing transaction can be considered a commitment =
transaction in a loose sense).&nbsp;</div><div class=3D""><br =
class=3D""></div><div class=3D"">Now you want to protect the funding =
transaction, as otherwise you would be subject to a replay-attack on all =
*past* forks. So you will set `nForkId&gt;=3D1` for the funding =
transaction, making this payment channel non-existent on any *past* =
forks. However, if during the lifetime of the payment channel another =
fork happens, the payment channel exists for both tokens. So for the =
commitment transaction, you will have `nForkId=3D0`, making it valid on =
both of these chains. While this `nForkId` is valid on all chains, the =
parent transaction it tries to spend (the funding transaction) does only =
exist on two chains, the original one you created the channel for and =
the one that forked away.&nbsp;</div></body></html>=

--Apple-Mail=_6FFDF190-74D2-4956-87E6-F1C1C5352C56--

--Apple-Mail=_2457BA2C-F57A-434A-A52D-A5B22CBDE230
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

iQIcBAEBCgAGBQJaCW3ZAAoJEAYZmwZ/PsbKmQ4P/RwgMvqhJKjID7qt+q1TELZZ
bqvoym9dzIdo37lT0DUmS8TNRxAU3liBkgCdBLUQXd9ktVIHGUsGr/rPZnQfD9pk
yHK9AdhBO14QPH2wHqzDb5W3YTUAsMWb4K/YCsMqZX2miAvdRCw8fLnITrnHxe2c
nWj2t4SAAPplDRTuhMljJ843KzR0CCdOQo7YPE5KM9VWihil56+wrGHGFNvVl789
cgJhPvgpt3WeMlIF95tYJhew0af3xtHmo1Z8KJYF/8zJb4BpnrAh6aKxyKxws4ut
E0bRNUtUB1hj17w1Rv82vM6KW5hKj0JmtSdcOJqe0gasAnqS81hCiEQQC4B8vMab
jtaF/fKS6wAEPc0RRRTEzvkwv6BQIJ6lNuohR7YEiwBUGcrtZVQ5ZVtdINrNSei1
r4B5/PGaQDYKqyoVoSLb/6NbzEiPdfJt/1tnMEI77HQSbFoibl25rDhBRHKlKjSl
8wdun06teL0wniOPNkoStrNqywTLGspw7PZZeWWsgocD9mAPPNsAeA1QPyKxphs5
AaDLPzC43+/IBpCwGCMrLbWRwdxb2FizAX/peKzXbCLmrFw24Yxo95+KR10vMBu3
YIWodo1nFd9XrWbHTmvl6Kfrlg76UN3MeclyclaTUXBAIkN7GjKDC+wv8a8z46AZ
YzfAUC9jJ8pf/yvoitdv
=84BJ
-----END PGP SIGNATURE-----

--Apple-Mail=_2457BA2C-F57A-434A-A52D-A5B22CBDE230--