path: root/4a/48a85337bb2d5d845a263fb743d3c8bcc1f25a

Return-Path: <jl2012@xbt.hk>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 8EB9D1173;
	Fri, 22 Mar 2019 04:23:45 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from sender-of-o51.zoho.com (sender-of-o51.zoho.com [135.84.80.216])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 98F5ED3;
	Fri, 22 Mar 2019 04:23:44 +0000 (UTC)
ARC-Seal: i=1; a=rsa-sha256; t=1553228614; cv=none; d=zoho.com; s=zohoarc; 
	b=aufqaOBcPLfMtMl6IMnZQGKjRC0keb1nnumdQpxSgFH1mhRMWiY5EJyhLPNMSGrobADHBQi6bdko66dtWtsLbTpK3NMa5mbFmQMBgzzAyrJHoExTzXUhSuJqMoSmxoBv59cdbj3ZcrKNQ5ZS4HM9Xq42BO+zg9F+2U9iqrDP/3k=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zoho.com;
	s=zohoarc; t=1553228614;
	h=Content-Type:Cc:Date:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:To:ARC-Authentication-Results;
	bh=L4Vo2t2dkWB6cqeojg6uKqJ7eik52eViBHwWp/BGZhM=; 
	b=Q/K0impnkB9MlT7QTnSehbgI/tcQklxO+b4g+JG1uDas7ynHJtY8zY//EPXeXsgRxO31aI4cs2fS7NLVFyjV/+8BtJoG40S4m1HddHAbeJYaxVO308jInha+OeP8WqoqrjEzBSMbKJhm2iDclcKbTHeGwJ50mYJ1HNmAC278ZzY=
ARC-Authentication-Results: i=1; mx.zoho.com; dkim=pass  header.i=xbt.hk;
	spf=pass  smtp.mailfrom=jl2012@xbt.hk;
	dmarc=pass header.from=<jl2012@xbt.hk> header.from=<jl2012@xbt.hk>
Received: from [192.168.1.2] (n219079143054.netvigator.com [219.79.143.54]) by
	mx.zohomail.com with SMTPS id 1553228612753394.14938167280593;
	Thu, 21 Mar 2019 21:23:32 -0700 (PDT)
From: Johnson Lau <jl2012@xbt.hk>
Message-Id: <F2238063-59EA-482A-B402-B9D0DB76D603@xbt.hk>
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_90A49671-B8A5-4E7F-80A1-896FD0E838B1"
Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\))
Date: Fri, 22 Mar 2019 12:23:28 +0800
In-Reply-To: <ITq8Tl8XaPXWzqs0F7yY3POHtysci93evnyLteDL9bYRxjjgJbTV_d-xCn_j5AZApGqCIBQ0p6UH8S-bD_n8hm1IMYS98ukpJkO4PGDXsuQ=@protonmail.com>
To: ZmnSCPxj <ZmnSCPxj@protonmail.com>,
	bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>
References: <20190313014143.ifffshwdux2jt7w5@erisian.com.au>
	<87k1gubdjm.fsf@rustcorp.com.au> <87woku9q3g.fsf@rustcorp.com.au>
	<UOdt33VfD8o6NfeDKMSip0hUmy1_jyo65-ihunuMRRg8IfXEOq-W60-TPoINm5HErPqnY_-yd1x_VnnVihrvtXRA2OHkjeROZheZ_QV0Zvo=@protonmail.com>
	<isp2OcX23r-Tfl-WSbybuKnppjVlZV52AM1GGEaQd8uHlkliikUBvK49WOnzgaxOjDuOCNdu6CsmHt6kfK0z_FRrOgYAYWrWaDniZA3EEZQ=@protonmail.com>
	<20190321090614.7ir64g2ehn3pz2cb@erisian.com.au>
	<5v4CPrMXyoMw0i1WtYYuIa_rMgkpq5NpnDhTNqTTZtfKKnFtwrbEGJnTD8ul71EM-MNpuo1R4znv4tPpwwm3Ys3m2Dbm3xsOGi96NYE9qfU=@protonmail.com>
	<20190321115522.lf7z6xb224lqqfla@erisian.com.au>
	<ITq8Tl8XaPXWzqs0F7yY3POHtysci93evnyLteDL9bYRxjjgJbTV_d-xCn_j5AZApGqCIBQ0p6UH8S-bD_n8hm1IMYS98ukpJkO4PGDXsuQ=@protonmail.com>
X-Mailer: Apple Mail (2.3445.102.3)
X-ZohoMailClient: External
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,HTML_MESSAGE,
	RCVD_IN_DNSWL_NONE autolearn=ham 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, 22 Mar 2019 13:40:55 +0000
Cc: "lightning-dev@lists.linuxfoundation.org"
	<lightning-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] [Lightning-dev] More thoughts on NOINPUT safety
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, 22 Mar 2019 04:23:45 -0000


--Apple-Mail=_90A49671-B8A5-4E7F-80A1-896FD0E838B1
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8



> On 22 Mar 2019, at 9:59 AM, ZmnSCPxj via bitcoin-dev =
<bitcoin-dev@lists.linuxfoundation.org> wrote:
>=20
> Good morning aj,
>>=20
>> If you are committing to the script code, though, then each =
settlement
>> sig is already only usable with the corresponding update tx, so you
>> don't need to roll the keys. But you do need to make it so that the
>> update sig requires the CLTV; one way to do that is using =
codeseparator
>> to distinguish between the two cases.
>>=20
>>> Also, I cannot understand `OP_CODESEPARATOR`, please no.
>>=20
>> If codeseparator is too scary, you could probably also just always
>> require the locktime (ie for settlmenet txs as well as update txs), =
ie:
>>=20
>> OP_CHECKLOCKTIMEVERIFY OP_DROP
>> <muSig(A_u,B_u)> OP_CHECKDLSVERIFY <Q> OP_CHECKDLS
>>=20
>> and have update txs set their timelock; and settlement txs set a =
absolute
>> timelock, relative timelock via sequence, and commit to the script =
code.
>>=20
>> (Note that both those approaches (with and without codesep) assume =
there's
>> some flag that allows you to commit to the scriptcode even though =
you're
>> not committing to your input tx (and possibly not committing to the
>> scriptpubkey). BIP118 doesn't have that flexibility, so the A_s_i and
>> B_s_i key rolling is necessary)
>=20
> I think the issue I have here is the lack of `OP_CSV` in the =
settlement branch.
>=20
> Consider a channel with offchain transactions update-1, settlement-1, =
update-2, and settlement-2.
> If update-1 is placed onchain, update-1 is also immediately spendable =
by settlement-1.
> But settlement-1 cannot be spent by update-2 and thus the invalidation =
of older state fails.
>=20
> The `OP_CSV` in the settlement branch of the update transaction =
outputs exists to allow later update transactions have higher priority =
over settlement transactions.
>=20
> To ensure that a settlement signature can only take the settlement =
branch, we need a distinct public key for the branch, so at least `A_s` =
and `B_s` without rolling them for each `i`, if we use `nLockTime` on =
the settlement transactions and enforce it with =
`OP_CHECKLOCKTIMEVERIFY`.
> It might be possible to do this with `OP_CODESEPARATOR`, but we do =
need the `OP_CSV` in the settlement branch.
>=20
> Regards,
> ZmnSCPxj
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev =
<https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>

OP_CSV (BIP112) is not needed. Only BIP68 relative-time is needed.

With this script:

<t> OP_CHECKLOCKTIMEVERIFY OP_DROP <muSig(A,B)> OP_CHECKSIGVERIFY <Q> =
OP_CHECKSIG

For update purpose, A and B will co-sign the muSig with nLockTime =3D t, =
not committing to the scriptCode, and no BIP68 lock time

For settlement purpose, A and B will co-sign the muSig with nLockTime =3D =
t, committing to the scriptCode, and with an agreed BIP68 locktime

Without committing to the scriptCode and BIP68 lock time, the update sig =
could be bind to any previous update tx immediately.

OTOH, the settlement sig will only bind to a specific update tx (thought =
scriptCode), and only after the relative locktime is passed.

The eltoo paper is wrong about using OP_CSV. That=E2=80=99s a common =
mistake even for experienced bitcoin developer. OP_CSV is needed only if =
one party could single handedly decide the relative-lock-time. However, =
this is not the case here as it is a muSig.

(With some risks of distracting the discussion, please note that even =
this script: <t> OP_CHECKLOCKTIMEVERIFY OP_DROP <A> OP_CHECKSIGVERIFY =
<B> OP_CHECKSIG doesn=E2=80=99t need OP_CSV, despite not using muSig. It =
is because the 2 sigs must use the same relative locktime, or the tx is =
invalid.)=

--Apple-Mail=_90A49671-B8A5-4E7F-80A1-896FD0E838B1
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html; =
charset=3Dutf-8"></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; line-break: after-white-space;" class=3D""><br =
class=3D""><div><br class=3D""><blockquote type=3D"cite" class=3D""><div =
class=3D"">On 22 Mar 2019, at 9:59 AM, ZmnSCPxj via bitcoin-dev &lt;<a =
href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" =
class=3D"">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:</div><br =
class=3D"Apple-interchange-newline"><div class=3D""><div class=3D"">Good =
morning aj,<br class=3D""><blockquote type=3D"cite" class=3D""><br =
class=3D"">If you are committing to the script code, though, then each =
settlement<br class=3D"">sig is already only usable with the =
corresponding update tx, so you<br class=3D"">don't need to roll the =
keys. But you do need to make it so that the<br class=3D"">update sig =
requires the CLTV; one way to do that is using codeseparator<br =
class=3D"">to distinguish between the two cases.<br class=3D""><br =
class=3D""><blockquote type=3D"cite" class=3D"">Also, I cannot =
understand `OP_CODESEPARATOR`, please no.<br class=3D""></blockquote><br =
class=3D"">If codeseparator is too scary, you could probably also just =
always<br class=3D"">require the locktime (ie for settlmenet txs as well =
as update txs), ie:<br class=3D""><br class=3D"">OP_CHECKLOCKTIMEVERIFY =
OP_DROP<br class=3D"">&lt;muSig(A_u,B_u)&gt; OP_CHECKDLSVERIFY &lt;Q&gt; =
OP_CHECKDLS<br class=3D""><br class=3D"">and have update txs set their =
timelock; and settlement txs set a absolute<br class=3D"">timelock, =
relative timelock via sequence, and commit to the script code.<br =
class=3D""><br class=3D"">(Note that both those approaches (with and =
without codesep) assume there's<br class=3D"">some flag that allows you =
to commit to the scriptcode even though you're<br class=3D"">not =
committing to your input tx (and possibly not committing to the<br =
class=3D"">scriptpubkey). BIP118 doesn't have that flexibility, so the =
A_s_i and<br class=3D"">B_s_i key rolling is necessary)<br =
class=3D""></blockquote><br class=3D"">I think the issue I have here is =
the lack of `OP_CSV` in the settlement branch.<br class=3D""><br =
class=3D"">Consider a channel with offchain transactions update-1, =
settlement-1, update-2, and settlement-2.<br class=3D"">If update-1 is =
placed onchain, update-1 is also immediately spendable by =
settlement-1.<br class=3D"">But settlement-1 cannot be spent by update-2 =
and thus the invalidation of older state fails.<br class=3D""><br =
class=3D"">The `OP_CSV` in the settlement branch of the update =
transaction outputs exists to allow later update transactions have =
higher priority over settlement transactions.<br class=3D""><br =
class=3D"">To ensure that a settlement signature can only take the =
settlement branch, we need a distinct public key for the branch, so at =
least `A_s` and `B_s` without rolling them for each `i`, if we use =
`nLockTime` on the settlement transactions and enforce it with =
`OP_CHECKLOCKTIMEVERIFY`.<br class=3D"">It might be possible to do this =
with `OP_CODESEPARATOR`, but we do need the `OP_CSV` in the settlement =
branch.<br class=3D""><br class=3D"">Regards,<br class=3D"">ZmnSCPxj<br =
class=3D"">_______________________________________________<br =
class=3D"">bitcoin-dev mailing list<br class=3D""><a =
href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" =
class=3D"">bitcoin-dev@lists.linuxfoundation.org</a><br class=3D""><a =
href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
class=3D"">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev<=
/a><br class=3D""></div></div></blockquote><br =
class=3D""></div><div>OP_CSV (BIP112) is not needed. Only BIP68 =
relative-time is needed.</div><div><br class=3D""></div><div>With this =
script:</div><div><br class=3D""></div><div>&lt;t&gt; =
OP_CHECKLOCKTIMEVERIFY OP_DROP &lt;muSig(A,B)&gt; OP_CHECKSIGVERIFY =
&lt;Q&gt; OP_CHECKSIG</div><div><br class=3D""></div><div>For update =
purpose, A and B will co-sign the muSig with nLockTime =3D t, not =
committing to the scriptCode, and no BIP68 lock time</div><div><br =
class=3D""></div><div>For settlement purpose, A and B will co-sign the =
muSig with nLockTime =3D t, committing to the scriptCode, and with an =
agreed BIP68 locktime</div><div><br class=3D""></div><div>Without =
committing to the scriptCode and BIP68 lock time, the update sig could =
be bind to any previous update tx immediately.</div><div><br =
class=3D""></div><div>OTOH, the settlement sig will only bind to a =
specific update tx (thought scriptCode), and only after the relative =
locktime is passed.</div><div><br class=3D""></div><div>The eltoo paper =
is wrong about using OP_CSV. That=E2=80=99s a common mistake even for =
experienced bitcoin developer. OP_CSV is needed only if one party =
could&nbsp;single handedly decide the relative-lock-time. However, this =
is not the case here as it is a muSig.</div><div><br =
class=3D""></div><div>(With some risks of distracting the discussion, =
please note that even this script: &lt;t&gt; OP_CHECKLOCKTIMEVERIFY =
OP_DROP &lt;A&gt; OP_CHECKSIGVERIFY &lt;B&gt; OP_CHECKSIG doesn=E2=80=99t =
need OP_CSV, despite not using muSig. It is because the 2 sigs must use =
the same relative locktime, or the tx is invalid.)</div></body></html>=

--Apple-Mail=_90A49671-B8A5-4E7F-80A1-896FD0E838B1--