path: root/12/d6ccebbe2d7acefd32f28ab48ae162b462bab4

Return-Path: <spartacusrex99@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 446BCC0D
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon, 13 Nov 2017 17:02:11 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wr0-f178.google.com (mail-wr0-f178.google.com
	[209.85.128.178])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 19D9F4F5
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon, 13 Nov 2017 17:02:10 +0000 (UTC)
Received: by mail-wr0-f178.google.com with SMTP id y42so15050968wrd.3
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon, 13 Nov 2017 09:02:09 -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=sDPy7svUOn4Ql8Y7PJG+QXdM72HsBtUlpRbWktYq56w=;
	b=LBMMDLOci4wFT+aINPYr0VTBDOUuCC4fZbrU0wHjywEqJtakJc5C4bRh6rg7NsYWdg
	ewjFsDP8jKXg/wA/9UofDiXVlmBxJsvhddC14hpKYuPW+OuGdZg6hRMhSrrnVWDgi7Wu
	flOlKPRRq9hsjRP2NVyJLl0GEVbgPAwxgJ/Hc4bZAKcMvBl7XriTGNipxtU3NsZ/Wmuh
	c7eJ/7UQSzd+fJ5flyw/B95QthfYbPvSpC0LyR99qt2xmeqbT5Nv+CIm6F8bdoxNXaI1
	vxtVmvITdJIjvPiNeBBJDMejLoNkdVlW/cF5StRFGQobW8YaM2lwgnOcHw84Mm8UVrr6
	v/Kw==
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=sDPy7svUOn4Ql8Y7PJG+QXdM72HsBtUlpRbWktYq56w=;
	b=IpIodNHg/snKx7SLP53CXeGG2GA9+AHbesDaoF13IPIkMyWy2yPE62u2u33EOGlq9M
	wDQBgQ8WTvPRJ3+IWMmcmgN8xsYtCNYe5Wra7jY+Jy4l+y1CMlwHlFYgkBsOH+Sl9hN9
	chEvO9R7y12l6DorRSM18zfcAZ3MdXgOSDf3u39Z5vhvfMrGmD0xeWr5AJ+Bf/RWqB8u
	RBYOa8rUHCOZw7zz8ciQGEjpMfkx70Z7QfsHTFnsT3bGuHaSoTO86WDZANHlXXpuxLxM
	3rsAcma46p0ur5TlaldO6oj/K+zsUJQYTH1dhw/YO4a9rNQxRk/BFKysW9NLqXMK5pxM
	DdWw==
X-Gm-Message-State: AJaThX6X23gdugHXpxnr1Hwkw0QPKziEdWlPPwSv0gD2b6xn6EFVJOfv
	v1wF5NJU8rf8+9scGJGuQaGy0UpevMHAvdTDjms=
X-Google-Smtp-Source: AGs4zMYhUEW+jNCm92ZqidIagqorFxVFTDacnRs0TIorA6lOLseZHqLcUShfD/wSnBH9ARV3Jf5Don/sftTtEGK3wco=
X-Received: by 10.223.157.204 with SMTP id q12mr8096952wre.241.1510592528727; 
	Mon, 13 Nov 2017 09:02:08 -0800 (PST)
MIME-Version: 1.0
Received: by 10.28.28.5 with HTTP; Mon, 13 Nov 2017 09:02:07 -0800 (PST)
Received: by 10.28.28.5 with HTTP; Mon, 13 Nov 2017 09:02:07 -0800 (PST)
In-Reply-To: <CAAUaCygjVDuqmVPS-1thnEbKgKYM9LW-7CsuAAnn7vqntMnWxA@mail.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>
	<24A6C651-272B-4452-8A81-31651D9A2694@blockchain.com>
	<CAAUaCygjVDuqmVPS-1thnEbKgKYM9LW-7CsuAAnn7vqntMnWxA@mail.gmail.com>
From: Spartacus Rex <spartacusrex99@gmail.com>
Date: Mon, 13 Nov 2017 17:02:07 +0000
Message-ID: <CA+Cf5AZT6KtRXmt3X6UiF0tP_hCtbUiUsS3XMXDdoaa0T1tepQ@mail.gmail.com>
To: Jacob Eliosoff <jacob.eliosoff@gmail.com>, 
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="f403043a296413425a055de03b93"
X-Spam-Status: No, score=0.2 required=5.0 tests=DKIM_SIGNED,DKIM_VALID,
	DKIM_VALID_AU,FREEMAIL_ENVFROM_END_DIGIT,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 02:42:42 +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: Mon, 13 Nov 2017 17:02:11 -0000

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

Totally agree something like this required..

I've been burned.

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 ?


On Nov 13, 2017 15:35, "Jacob Eliosoff via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> 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>=1` 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=0`,
>> 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.
>>
>
> 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.
>
> 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...
>
>
> On Mon, Nov 13, 2017 at 5:03 AM, Mats Jerratsch <mats@blockchain.com>
> wrote:
>
>>
>> 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>=1` 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=0`,
>> 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.
>>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>

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

<div dir=3D"auto"><div dir=3D"auto">Totally agree something like this requi=
red..</div><div dir=3D"auto"><br></div><div dir=3D"auto">I&#39;ve been burn=
ed.</div><div dir=3D"auto"><br></div><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 not a valid block on t=
he 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 a=
llow 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&#39;t ne=
ed 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 missing why this scheme w=
ould be better ?<br></div><div dir=3D"auto"><br></div></div><div class=3D"g=
mail_extra"><br><div class=3D"gmail_quote">On Nov 13, 2017 15:35, &quot;Jac=
ob Eliosoff via bitcoin-dev&quot; &lt;<a href=3D"mailto:bitcoin-dev@lists.l=
inuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br=
 type=3D"attribution"><blockquote class=3D"gmail_quote" style=3D"margin:0 0=
 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>=
<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:b=
reak-word"><div>This is actually incorrect. There are two transactions invo=
lved in LN. The funding transaction, which opens a payment channel, and a c=
ommitment transaction, which closes the channel when broadcasted to the net=
work (the cooperative closing transaction can be considered a commitment tr=
ansaction in a loose sense).=C2=A0</div><div><br></div><div>Now you want to=
 protect the funding transaction, as otherwise you would be subject to a re=
play-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 transactio=
n 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=
.=C2=A0</div></div></blockquote></div><div><br></div>Thanks for the clarifi=
cation.=C2=A0 How would a tx specify a constraint like &quot;nForkId&gt;=3D=
1&quot;?=C2=A0 I was thinking of it just as a number set on the tx.<div><br=
></div><div>Also note that since forks form a partial order, but IDs (numbe=
rs) 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 nFo=
rkId 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 ge=
t into stuff like making each fork reference its parent-fork&#39;s first bl=
ock or something, someone has written about this...<br><div><div><br><div c=
lass=3D"gmail_extra"><br><div class=3D"gmail_quote">On Mon, Nov 13, 2017 at=
 5:03 AM, Mats Jerratsch <span dir=3D"ltr">&lt;<a href=3D"mailto:mats@block=
chain.com" target=3D"_blank">mats@blockchain.com</a>&gt;</span> wrote:<br><=
blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l=
eft:1px solid rgb(204,204,204);padding-left:1ex"><div style=3D"word-wrap:br=
eak-word"><div><span class=3D"m_8209364487259859034gmail-"><br><blockquote =
type=3D"cite"><div><div dir=3D"ltr">OK, so nForkId 0 is exactly the &quot;v=
alid on all chains&quot; specifier I was asking about, cool.=C2=A0 And your=
 LN example (and nLockTime txs in general) illustrate why it&#39;s preferab=
le to implement a generic replay protection scheme like yours <i>in advance=
</i>, rather than before each fork: all ad hoc RP schemes I know of break o=
ld txs on one of the chains, even when that&#39;s not desirable - ie, they =
offer no wildcard like nForkId 0.</div></div></blockquote><div><br></div></=
span><div>Exactly!</div><span class=3D"m_8209364487259859034gmail-"><div><b=
r></div><blockquote type=3D"cite"><div><div dir=3D"ltr"><div>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>past</i> forks too.=C2=A0 Eg, if=
 BCH had been deployed with nForkId 2, then a user setting up BTC LN txs no=
w with nForkId 0 would have to be aware that those txs would be valid for B=
CH too.=C2=A0 Of course the user could avoid this by funding from a BTC-onl=
y address, but it is a potential minor pitfall of nForkId 0.=C2=A0 (Which I=
 don&#39;t see any clean way around.)</div></div>
</div></blockquote></span></div><br><div>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 wh=
en broadcasted to the network (the cooperative closing transaction can be c=
onsidered a commitment transaction in a loose sense).=C2=A0</div><div><br><=
/div><div>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 n=
on-existent on any *past* forks. However, if during the lifetime of the pay=
ment channel another fork happens, the payment channel exists for both toke=
ns. 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 chai=
ns, 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.=C2=A0</div></div></blockquote></div><br></div></=
div></div></div></div>
<br>______________________________<wbr>_________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.=
<wbr>linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.<wbr>org=
/mailman/listinfo/bitcoin-<wbr>dev</a><br>
<br></blockquote></div></div>

--f403043a296413425a055de03b93--