path: root/5d/4b8ea1f27cdfd3a44cbf44b644d55e63b08f44

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 266956C
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 15 Nov 2017 05:02:52 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-lf0-f48.google.com (mail-lf0-f48.google.com
	[209.85.215.48])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 08A52FD
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 15 Nov 2017 05:02:50 +0000 (UTC)
Received: by mail-lf0-f48.google.com with SMTP id e143so24776972lfg.12
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue, 14 Nov 2017 21:02:50 -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=SrPJjw1Pa6iOqE07RCuExg8LOefkccLA0i79uFq2DDQ=;
	b=e2c9UbJhKpV0QjYTa0j+NkbQPL8zHCD/xAUtK8z5KyuoIUBDPgJeR4gIv22GlX+G36
	9dA2wgv1Ymm+WaNCtRPZu5zFYBv/+CkaCRMbnx5udjWF0HpPqtDQmxowpbxCU0L9EVzz
	3SM4uMpTUZb3KiCwUYo/VIijl7jkfRHhsnF/lxkrFiuzaitwp1KmDofFWWhrnqoq+O7V
	FcjPfkSQs+khRZzkUKD+AIIaJsjtrR51W5egXCqircp7Gd76TxV0MOW3LqV51NLAPdgI
	dNTib5Th3OCBy/Hn/5sNOj8UWxfdykgVN3N6v9ovIGb0oTbYZJXqcP4ys6cj03yVh3xe
	YTbA==
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=SrPJjw1Pa6iOqE07RCuExg8LOefkccLA0i79uFq2DDQ=;
	b=kcWavNROkUNaG3KouaDvDvdoG5u5m+9tPV4g4DYgdD8qXLu6/SWWsreAX1MdvFBal0
	PIYqus541fgHKlVLSxiIMiO1JFPeLl4YqZtYtDjSIMlOwZJqY9r1qKTM5H3qwJTa3CYt
	KIAUBwU3+4Dea7alRoJoV9D8MxxYS1I+H1pr3Awtpe85Kp8KK3MdfLv4Bb/TEYETSfnl
	rlmdVgfVOCaJ7rAWNKzoF5WUcE+MM2dZK3XrdM8C4qcvs5Q5cziwP1/akL52v7rdtUN2
	Ro+45w5MT+VUpzp28qoBa3sD87zKYrzjaX8r1ZgXHapvgh7E+YOSE+fj/HvSMOd+514R
	FemA==
X-Gm-Message-State: AJaThX4USAK5BwDszp7Fy+e+gkJ+lcKeU2Uj7sXX7lCjdAt7Xy9dLHAb
	S/tZulIb8qCrmIp60HZmvw1cVvkxdBEdKc1iZw8=
X-Google-Smtp-Source: AGs4zMaVNL1goiKp+DIgPfxM9v1PVGa94aUcVTIo4pPWzyvijIR8EM2S98oDtPwiocA0eTF+xA3QDWnfkvT6p3Y7N2A=
X-Received: by 10.46.29.207 with SMTP id w76mr63388lje.171.1510722169295; Tue,
	14 Nov 2017 21:02:49 -0800 (PST)
MIME-Version: 1.0
Received: by 10.25.215.19 with HTTP; Tue, 14 Nov 2017 21:02:48 -0800 (PST)
In-Reply-To: <71A64D11-DE57-4AA2-A635-F2AA4DC04909@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>
	<CAAUaCyg70uUnUp1Q0a6kEoQ1Js68VFLgthyfwyMQaaEqO8R-UQ@mail.gmail.com>
	<24A6C651-272B-4452-8A81-31651D9A2694@blockchain.com>
	<CAAUaCygjVDuqmVPS-1thnEbKgKYM9LW-7CsuAAnn7vqntMnWxA@mail.gmail.com>
	<CA+Cf5AZT6KtRXmt3X6UiF0tP_hCtbUiUsS3XMXDdoaa0T1tepQ@mail.gmail.com>
	<71A64D11-DE57-4AA2-A635-F2AA4DC04909@blockchain.com>
From: Jacob Eliosoff <jacob.eliosoff@gmail.com>
Date: Wed, 15 Nov 2017 00:02:48 -0500
Message-ID: <CAAUaCyjpH0hAxS7pUzZihft3KDtgB3nkZdT_6JUhmE9hJ7T4sA@mail.gmail.com>
To: Mats Jerratsch <mats@blockchain.com>
Content-Type: multipart/alternative; boundary="94eb2c1a64324156d4055dfe6af8"
X-Spam-Status: No, score=-0.1 required=5.0 tests=DKIM_SIGNED,DKIM_VALID,
	DKIM_VALID_AU,FREEMAIL_FROM,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: Wed, 15 Nov 2017 11:16:06 +0000
Cc: Bitcoin Protocol Discussion <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: Wed, 15 Nov 2017 05:02:52 -0000

--94eb2c1a64324156d4055dfe6af8
Content-Type: text/plain; charset="UTF-8"

>
> Sorry, I was careless with the use of `>=` there. You are correct, forks
> form a tree. For this proposal, every leaf must be assigned a unique
> `nForkId`. The relationship between `nForkId` is irrelevant (e.g. which
> number is bigger), as long as they are unique. Transactions are only valid
> IFF `nForkId` matches exactly the `nForkId` of the software validating it.
> As described above, the transaction doesn't even contain `nForkId`, and the
> node surely is not starting to guess which one it could be.
>

OK, but then it seems to me you have a dilemma for, eg, your LN commitment
tx.  You either give it the specific nForkId of the fork it's created on -
making it invalid on *all* other forks (eg, any future "non-contentious
upgrade" HF that replaces that fork).  Or you give it nForkId 0 - which has
the "BCH tx valid on Segwit2x (& vice versa)" flaw.

It may make sense to revise your proposal to incorporate Luke's
OP_CHECKBLOCKATHEIGHT
<https://github.com/bitcoin/bips/blob/master/bip-0115.mediawiki>, and make
the fork ID a (block height, hash) pair rather than just a number.  But I
still think the idea of fork-specific addresses is a keeper!


On Tue, Nov 14, 2017 at 8:49 AM, Mats Jerratsch <mats@blockchain.com> wrote:

>
> But I like the 'old' idea of putting the hash of a block that MUST be on
> the chain that this txn can eventually be added to. If the hash is not a
> valid block on the chain, the txn can't be added.
>
> It means you can choose exactly which forks you want to allow your txn on,
> pre-fork for both, post-fork for only one, and gets round the issue of who
> gets to decide the nForkid value.. since you don't need one. Also, all the
> old outputs work fine, and LN not an issue.
>
> I'm missing why this scheme would be better ?
>
>
> I do agree that solutions like `SIGHASH_BLOCKCOMMIT` are superior in the
> sense that they are very difficult to circumvent. However, a fork could
> also follow the original chain in SPV mode and allow transactions protected
> with these mechanism. Since it's fundamentally impossible to disallow
> transactions in future projects, the goal shouldn't be to make this overly
> complicated.
>
> Furthermore, this schema is not just adding replay protection. It makes
> transacting safer overall (due to a dedicated address format per fork) and
> allows light clients to differentiate between multiple forks. In the past
> three months, at least $600k has been lost by users sending BCH to a BTC
> address [1].
>
> Thanks for the clarification.  How would a tx specify a constraint like
>> "nForkId>=1"?  I was thinking of it just as a number set on the tx.
>>
>
> Whether the transaction is replay protected or not is specified by setting
> a bit in the `SigHashId`. If this bit is set, then the signature *preimage*
> MUST have `nForkId` appended. `nForkId` is not part of the final
> transaction, someone who wants to verify the transaction must know which
> `nForkId` it was created with.
>
> If the bit isn't set, it means `nForkId=0`, which allows other forks to
> validate the signature.
>
> Also note that since forks form a partial order, but IDs (numbers) form a
>> total order, ">=" will miss some cases.  Eg, suppose BCH had forked with
>> nForkId 2, and then you set up a LN funding tx on BCH with nForkId>=2, and
>> then Segwit2x forked (from BTC!) with nForkId 3.  The BCH funding tx would
>> be valid on Segwit2x.  This is more of a fundamental problem than a bug -
>> to avoid it you'd have to get into stuff like making each fork reference
>> its parent-fork's first block or something, someone has written about
>> this...
>>
>
> Sorry, I was careless with the use of `>=` there. You are correct, forks
> form a tree. For this proposal, every leaf must be assigned a unique
> `nForkId`. The relationship between `nForkId` is irrelevant (e.g. which
> number is bigger), as long as they are unique. Transactions are only valid
> IFF `nForkId` matches exactly the `nForkId` of the software validating it.
> As described above, the transaction doesn't even contain `nForkId`, and the
> node surely is not starting to guess which one it could be.
>
> [1]
> https://twitter.com/khannib/status/930223617744437253
>

--94eb2c1a64324156d4055dfe6af8
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div><div class=3D"gmail_quote"><blockquote class=3D"gmail=
_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204=
,204);padding-left:1ex"><div style=3D"word-wrap:break-word"><div>Sorry, I w=
as careless with the use of `&gt;=3D` there. You are correct, forks form a =
tree. For this proposal, every leaf must be assigned a unique `nForkId`. Th=
e relationship between `nForkId` is irrelevant (e.g. which number is bigger=
), as long as they are unique. Transactions are only valid IFF `nForkId` ma=
tches exactly the `nForkId` of the software validating it. As described abo=
ve, the transaction doesn&#39;t even contain `nForkId`, and the node surely=
 is not starting to guess which one it could be.=C2=A0</div></div></blockqu=
ote></div></div><div><br></div><div>OK, but then it seems to me you have a =
dilemma for, eg, your LN commitment tx.=C2=A0 You either give it the specif=
ic nForkId of the fork it&#39;s created on - making it invalid on <i>all</i=
> other forks (eg, any future &quot;non-contentious upgrade&quot; HF that r=
eplaces that fork).=C2=A0 Or you give it nForkId 0 - which has the &quot;BC=
H tx valid on Segwit2x (&amp; vice versa)&quot; flaw.</div><div><br></div><=
div>It may make sense to revise your proposal to incorporate Luke&#39;s <a =
href=3D"https://github.com/bitcoin/bips/blob/master/bip-0115.mediawiki">OP_=
CHECKBLOCKATHEIGHT</a>, and make the fork ID a (block height, hash) pair ra=
ther than just a number.=C2=A0 But I still think the idea of fork-specific =
addresses is a keeper!</div><br><div class=3D"gmail_extra"><br><div class=
=3D"gmail_quote">On Tue, Nov 14, 2017 at 8:49 AM, Mats Jerratsch <span dir=
=3D"ltr">&lt;<a href=3D"mailto:mats@blockchain.com" target=3D"_blank">mats@=
blockchain.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);pad=
ding-left:1ex"><div style=3D"word-wrap:break-word"><div><span class=3D"gmai=
l-"><br><blockquote type=3D"cite"><div><div dir=3D"auto"><div dir=3D"auto">=
But I like the &#39;old&#39; idea of putting the hash of a block that MUST =
be on the chain that this txn can eventually be added to. If the hash is no=
t a valid block on the chain, the txn can&#39;t be added.<br></div><div dir=
=3D"auto"><br></div><div dir=3D"auto">It means you can choose exactly which=
 forks you want to allow your txn on, pre-fork for both, post-fork for only=
 one, and gets round the issue of who gets to decide the nForkid value.. si=
nce you don&#39;t need one. Also, all the old outputs work fine, and LN not=
 an issue.</div><div dir=3D"auto"><br></div><div dir=3D"auto">I&#39;m missi=
ng why this scheme would be better ?<br></div></div></div></blockquote><div=
><br></div></span><div>I do agree that solutions like `SIGHASH_BLOCKCOMMIT`=
 are superior in the sense that they are very difficult to circumvent. Howe=
ver, a fork could also follow the original chain in SPV mode and allow tran=
sactions protected with these mechanism. Since it&#39;s fundamentally impos=
sible to disallow transactions in future projects, the goal shouldn&#39;t b=
e to make this overly complicated.=C2=A0</div><div><br></div><div>Furthermo=
re, this schema is not just adding replay protection. It makes transacting =
safer overall (due to a dedicated address format per fork) and allows light=
 clients to differentiate between multiple forks. In the past three months,=
 at least $600k has been lost by users sending BCH to a BTC address [1].</d=
iv><span class=3D"gmail-"><div><br></div><blockquote type=3D"cite"><div cla=
ss=3D"gmail_extra"><div class=3D"gmail_quote"><blockquote class=3D"gmail_qu=
ote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,20=
4);padding-left:1ex"><div dir=3D"ltr">Thanks for the clarification.=C2=A0 H=
ow would a tx specify a constraint like &quot;nForkId&gt;=3D1&quot;?=C2=A0 =
I was thinking of it just as a number set on the tx.</div></blockquote></di=
v></div></blockquote><div><br></div></span><div>Whether the transaction is =
replay protected or not is specified by setting a bit in the `SigHashId`. I=
f this bit is set, then the signature *preimage* MUST have `nForkId` append=
ed. `nForkId` is not part of the final transaction, someone who wants to ve=
rify the transaction must know which `nForkId` it was created with.=C2=A0</=
div><div><br></div><div>If the bit isn&#39;t set, it means `nForkId=3D0`, w=
hich allows other forks to validate the signature.</div><span class=3D"gmai=
l-"><div><br></div><blockquote type=3D"cite"><div class=3D"gmail_extra"><di=
v class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0=
px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><=
div dir=3D"ltr"><div>Also note that since forks form a partial order, but I=
Ds (numbers) form a total order, &quot;&gt;=3D&quot; will miss some cases.=
=C2=A0 Eg, suppose BCH had forked with nForkId 2, and then you set up a LN =
funding tx on BCH with nForkId&gt;=3D2, and then Segwit2x forked (from BTC!=
) with nForkId 3.=C2=A0 The BCH funding tx would be valid on Segwit2x.=C2=
=A0 This is more of a fundamental problem than a bug - to avoid it you&#39;=
d have to get into stuff like making each fork reference its parent-fork&#3=
9;s first block or something, someone has written about this...<br></div></=
div></blockquote></div></div></blockquote><div><br></div></span><div>Sorry,=
 I was careless with the use of `&gt;=3D` there. You are correct, forks for=
m a tree. For this proposal, every leaf must be assigned a unique `nForkId`=
. The relationship between `nForkId` is irrelevant (e.g. which number is bi=
gger), as long as they are unique. Transactions are only valid IFF `nForkId=
` matches exactly the `nForkId` of the software validating it. As described=
 above, the transaction doesn&#39;t even contain `nForkId`, and the node su=
rely is not starting to guess which one it could be.=C2=A0</div></div><br><=
div>[1]</div><div><a href=3D"https://twitter.com/khannib/status/93022361774=
4437253" target=3D"_blank">https://twitter.com/khannib/<wbr>status/93022361=
7744437253</a></div></div></blockquote></div><br></div></div>

--94eb2c1a64324156d4055dfe6af8--