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 0C34172A for ; Thu, 20 Dec 2018 18:04:49 +0000 (UTC) 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 7CC747C for ; Thu, 20 Dec 2018 18:04:48 +0000 (UTC) ARC-Seal: i=1; a=rsa-sha256; t=1545329085; cv=none; d=zoho.com; s=zohoarc; b=Crx8JqCcB9SD/AHdHv9UTUFQ8inCHqDFkVmlpyTMx2inVQVhR0T75ZN5FfCa0qkm0TDEYnUiIJ5to9C4Q70/LR+4X7jErVeX77cake8ICRsHQ01jztQQcjNcOHnfVDAz1gSKS4v/0dBmkxQvXbg7b0QbS0vc1+mQhAjh22w+Hgo= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zoho.com; s=zohoarc; t=1545329085; h=Content-Type:Content-Transfer-Encoding:Cc:Date:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:To:ARC-Authentication-Results; bh=/kM76/T73x1okhC0Z2Dv9JfHfqWXlXwY+I8GDqW2arQ=; b=JDNZ5f6CahuiACEpu4Zu96EkJlaFX0VGCf0y/WDPkfs2kLSBxyIhhN11GGzBiGL15M1RX+ef5PC1bqj8QH1uzpT6F7shtc/yNfBOo1pvQXgCSo15wucov8DNPdBgz/TkoUHOgajy8Uew84wkDBIjqdB5MpN+998o81DlpN3FLhI= 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 [10.8.0.105] (n218103234118.netvigator.com [218.103.234.118]) by mx.zohomail.com with SMTPS id 1545329083533232.61925281706613; Thu, 20 Dec 2018 10:04:43 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.0 \(3445.100.39\)) From: Johnson Lau In-Reply-To: <871s6cw1vt.fsf@gmail.com> Date: Fri, 21 Dec 2018 02:04:37 +0800 Content-Transfer-Encoding: quoted-printable Message-Id: <34A8F2C4-4732-4BE7-84F5-699B8D709D06@xbt.hk> References: <9F8C0789-48E9-448A-A239-DB4AFB902A00@xbt.hk> <87efadp3rl.fsf@gmail.com> <195B4583-CE97-4C3A-9582-3C0C013CC1E9@xbt.hk> <871s6cw1vt.fsf@gmail.com> To: Christian Decker X-Mailer: Apple Mail (2.3445.100.39) X-ZohoMailClient: External X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,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: Thu, 20 Dec 2018 21:58:07 +0000 Cc: bitcoin-dev Subject: Re: [bitcoin-dev] Safer NOINPUT with output tagging 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: Thu, 20 Dec 2018 18:04:49 -0000 > On 21 Dec 2018, at 1:20 AM, Christian Decker = wrote: >=20 > Johnson Lau writes: >> Correct me if I=E2=80=99m wrong. >>=20 >> For the sake of simplicity, in the following I assume BIP118, 143, = and >> 141-P2WSH are used (i.e. no taproot). Also, I skipped all the = possible >> optimisations. >>=20 >> 1. A and B are going to setup a channel. >>=20 >> 2. They create one setup tx, with a setup output of the following >> script: CLTV DROP 2 Au Bu 2 CHECKMULTISIG. Do not sign >=20 > If we are using a trigger transaction the output of the setup > transaction would simply be `2 Au Bu 2 OP_CMS`. If we were to use a = CLTV > in there we would not have an option to later attach a collaborative > close transaction that is valid immediately. Furthermore the timeout = of > the CLTV would start ticking down the exact moment the setup = transaction > is confirmed, hence whatever effect we are trying to achieve with that > timelock is limited, and we have a limit to the total lifetime of the > channel. CLTV is absolute locktime. Only CSV will have the =E2=80=9Ctime = ticking=E2=80=9D issue, but that=E2=80=99s not used here. The required = locktime is many years in the past. To collaboratively close, you = just need to sign with SIGHASH_ALL, with a locktime s+1. >=20 >> 3. They create the update tx 0, spending the setup output with = NOINPUT >> and locktime =3D s+1, to the update-0 output with the script: IF 2 = As0 >> Bs0 2 CHECKMULTISIG ELSE CLTV DROP 2 Au Bu 2 CHECKMULTISIG = ENDIF >=20 > Update 0 is usually what I call the trigger transaction. It takes the > 2-of-2 multisig from the setup transaction and translates it into the > two-branch output that further updates or settlements can be attached > to. The settlement transaction attached to the trigger / update 0 > reflects the initial state of the channel, i.e., if A added 2 BTC and = B > added 1 BTC then settlement 0 will have 2 outputs with value 2 and 1 > respectively, with the user's keys (this can also be considered the > refund in case of one party disappearing right away). >=20 > The second branch in the script you posted is the update branch, which = is > not encumbered by a CSV, while the first branch is the one encumbered > with the CSV and is called the settlement branch since we'll be > attaching settlement txs to it. >=20 > The CLTV looks correct to me and ensures that we can only attach any > state >=3D s+1. >=20 > So just to show the output script for state `i` how I think they are > correct: >=20 > ``` > OP_IF > OP_CSV 2 2 OP_CHECKMULTISIG > OP_ELSE > OP_CLTV OP_DROP 2 2 OP_CHECKMULTISIG=20 > ``` >=20 > And the input scripts for the update tx and the settlement tx > respectively would be: >=20 > ``` > OP_FALSE > ``` >=20 > and >=20 > ``` > OP_TRUE > ``` I think the use of OP_CSV (BIP112) is not needed here (although it = doesn=E2=80=99t really harm except taking a few more bytes). All you = need is to sign the settlement tx with a BIP68 relative locktime. Since = this is a 2-of-2 branch, both parties need to agree with the relative = locktime, so it is not necessary to restrict it through OP_CSV >=20 >> 4. They create the settlement tx 0, spending the update-0 output with >> As0 and Bs0 using BIP68 relative-locktime, with 2 settlement outputs >=20 > If I'm not mistaken the CSV needs to be in the scriptPubkey (or P2WSH > equivalent) since segwit witnesses only allow pushes. Hence the script > in point 3 needs to add that :-) I believe you confused OP_CSV (BIP112) with BIP68. Relative locktime is = enforced by BIP68 (i.e. setting the nSequence). OP_CSV indirectly = enforces relative-locktime by checking the value of nSequence. BIP68 = could work standalone without OP_CSV, while OP_CSV is dependant on = BIP68. In the case of n-of-n eltoo state update, OP_CSV is not needed = because all n parties need to agree with the same nSequence value of the = settlement tx. This is enough to make sure the settlement tx has delayed = settlement. >=20 >> 5. They sign the setup tx and let it confirm >=20 > They also need to sign (but not broadcast) update_0, in order to allow > either party to initiate the closure if the counterparty become > unresponsive. The order in which settlement_0 and update_0 are signed = is > not important by the way, so we can just batch these. The important = part > is that signing the setup acts as a commitment. Sure. This is obvious. >=20 >> 6. To update, they create the update tx 1, spending the setup output >> with NOINPUT and locktime =3D s+2, to the update-1 output with the >> script: IF 2 As1 Bs1 2 CHECKMULTISIG ELSE CLTV DROP 2 Au Bu 2 >> CHECKMULTISIG ENDIF and create the settlement tx 1, spending the >> update-1 output with As1 and Bs1 using relative-locktime, with 2 >> settlement outputs >=20 > The output script of the updates are identical to the ones in the > trigger or update_0 transaction, so they'd also need a CSV (this is = why > committing to the script structure with masking still works). >=20 >> 7. To close the channel, broadcast update tx 1. Wait for several >> confirmations. And broadcast settlement-tx-1 >=20 > We have to differentiate 2 cases: collaborative close and unilateral > close. In the collaborative close we come to a mutual agreement that > we'd like to take this latest state and settle. So we create a new > transaction that spends the setup output, and add outputs according to > the state we agreed upon, and we sign it. This transaction is > immediately valid, and does not need to be signed with NOINPUT. So all > the chain sees is a setup transaction with some inputs and one = multisig > output (singlesig with Schnorr) and a collaborative close transaction > that spends the setup (also not signed with NOINPUT). About as normal = as > transactions in Bitcoin can get. Collaborative close is always simple as I explained in the beginning >=20 > In the unilateral case, one party isn't there anymore, or refuses to > sign. So we take the trigger transaction (not signed with NOINPUT) and > the latest update_n transaction (signed with NOINPUT) and broadcast > them. Then we wait for the CSV timeout to expire, and then send the > settlement transaction, which gives us the enforcement of the latest > state that we agreed on. The chain sees a setup transaction and a > trigger transaction (normal transactions for all intents and purposes, > except for the output script of the trigger, but we can hide that with > taproot), followed by two more transactions which are signed with > NOINPUT. So 4 transactions in the worst case, of which 2 are special, > and 2 transactions in the good case. >=20 >=20 > So all in all I think it's a tradeoff between having a larger on-chain > footprint (4 txs vs 3 txs in the worst case) and putting a fixed > lifetime on the channel for the refund case if one party disappears > right away. We'll probably find out what acceptable parameters are for > these and where the cutoff points are :-) If no one is cheating (i.e. only the last update is broadcast), you = always need only 3 txs. Think about this: every update tx could be a = trigger tx, and you can settle directly on a trigger tx, so effectively = you eliminate trigger tx.