From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: 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= header.from= 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 Message-Id: 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: To: ZmnSCPxj , bitcoin-dev References: <20190313014143.ifffshwdux2jt7w5@erisian.com.au> <87k1gubdjm.fsf@rustcorp.com.au> <87woku9q3g.fsf@rustcorp.com.au> <20190321090614.7ir64g2ehn3pz2cb@erisian.com.au> <5v4CPrMXyoMw0i1WtYYuIa_rMgkpq5NpnDhTNqTTZtfKKnFtwrbEGJnTD8ul71EM-MNpuo1R4znv4tPpwwm3Ys3m2Dbm3xsOGi96NYE9qfU=@protonmail.com> <20190321115522.lf7z6xb224lqqfla@erisian.com.au> 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" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 = 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 >> OP_CHECKDLSVERIFY 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 = OP_CSV (BIP112) is not needed. Only BIP68 relative-time is needed. With this script: OP_CHECKLOCKTIMEVERIFY OP_DROP OP_CHECKSIGVERIFY = 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: OP_CHECKLOCKTIMEVERIFY OP_DROP OP_CHECKSIGVERIFY = 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

On 22 Mar 2019, at 9:59 AM, ZmnSCPxj via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:

Good = morning aj,

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.

Also, I cannot = understand `OP_CODESEPARATOR`, please no.

If codeseparator is too scary, you could probably also just = always
require the locktime (ie for settlmenet txs as well = as update txs), ie:

OP_CHECKLOCKTIMEVERIFY = OP_DROP
<muSig(A_u,B_u)> OP_CHECKDLSVERIFY <Q> = OP_CHECKDLS

and have update txs set their = timelock; and settlement txs set a absolute
timelock, = relative timelock via sequence, and commit to the script code.

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

I think the issue I have here is = the lack of `OP_CSV` in the settlement branch.

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.

The `OP_CSV` in the settlement branch of the update = transaction outputs exists to allow later update transactions have = higher priority over settlement transactions.

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.

Regards,
ZmnSCPxj
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev<= /a>









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