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 CB63ED1D for ; Thu, 20 Dec 2018 17:21:05 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-ed1-f52.google.com (mail-ed1-f52.google.com [209.85.208.52]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id D6F30889 for ; Thu, 20 Dec 2018 17:21:04 +0000 (UTC) Received: by mail-ed1-f52.google.com with SMTP id h15so2412350edb.4 for ; Thu, 20 Dec 2018 09:21:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:in-reply-to:references:date:message-id :mime-version:content-transfer-encoding; bh=YrbuWJH3lDqy9BXSQLEMVk8nXk+76qHo5fIPRrr5lEU=; b=oWsfQhjuUNbbuuBRQqL5ap7iJIKTL9IVxF9qCaQKSJnOjycXD8Mye+IV6lmCP+0yYd apU1/NB5DodxiAadk8mDkDwhtAsp+yznGLmBH0g/6Hy9iDCLIdnQ0GoWMx3qPc0bTfsG 8wfKpWDRf9HNzVWa8qqed6bZCYl0sWqcoNxK417idWQjAeN/5x9PDw2Y6HrznopTrgGA pHq0N6sLsbtrVrrostze4pepe3IkBUhGOKB4xgXmkzvpCeWi/4AP4I1b9MS8CtgYi1Yc y33HdsJO1fO6pWgfV1te7oC3e40OaLCnJ0QKvPY61rQb03orpoYPppX8rIa94JFmGyNY CK2A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:in-reply-to:references:date :message-id:mime-version:content-transfer-encoding; bh=YrbuWJH3lDqy9BXSQLEMVk8nXk+76qHo5fIPRrr5lEU=; b=OfMUVuxDpaHPuqBjBFTAgjH3TMGEyUUFjTMBJg/qw/BLEEFa8M6iNThrh18xx00Jpy sv94kni0DSKZxd4nY8xlHI9NDJUXTlKw+QVajiS5KWrG+7jwFLxiWUGJXwie9ifMVnLs lRQPd70HvsNXtVnysSyMIQT2waFNpkSm19yINQCM4yDVnUxKITdAmNT6ZPJz0ASJsUGn j7J60Ito8xQgAVw/e7S/PzJ8GgBUv9SRyBG412OPcRmJmMh3ngZ597by65bLgSVoFv2t hZdHxGUCJLUWLySuJL1gqPlXxQ26Yt1GqZVvJcT0PYy9p31trj3SqiECATnZotIu+xKP HsQg== X-Gm-Message-State: AA+aEWZawLN/l1TbC6211BRbXzylS8Kl6l77VHupHz8fN/0qqA+512r6 l9JGOg50tk7c0siOWZTxo+I= X-Google-Smtp-Source: AFSGD/W6sh0l/Z+j6rb6jEnL/W+ca+gLgWWbOEDxUnQkJ8Jh3DXsczMcMaq5wyupQh65QnnICpyoPw== X-Received: by 2002:a50:a086:: with SMTP id 6mr11925631edo.88.1545326463308; Thu, 20 Dec 2018 09:21:03 -0800 (PST) Received: from localhost ([2a02:aa16:1102:5480:b8c8:56f0:43e2:f1fe]) by smtp.gmail.com with ESMTPSA id v43sm6456574edc.18.2018.12.20.09.21.00 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Thu, 20 Dec 2018 09:21:01 -0800 (PST) From: Christian Decker To: Johnson Lau In-Reply-To: <195B4583-CE97-4C3A-9582-3C0C013CC1E9@xbt.hk> References: <9F8C0789-48E9-448A-A239-DB4AFB902A00@xbt.hk> <87efadp3rl.fsf@gmail.com> <195B4583-CE97-4C3A-9582-3C0C013CC1E9@xbt.hk> Date: Thu, 20 Dec 2018 18:20:54 +0100 Message-ID: <871s6cw1vt.fsf@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, 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 17:21:05 -0000 Johnson Lau writes: > Correct me if I=E2=80=99m wrong. > > 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. > > 1. A and B are going to setup a channel. > > 2. They create one setup tx, with a setup output of the following > script: CLTV DROP 2 Au Bu 2 CHECKMULTISIG. Do not sign 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. > 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 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). 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. The CLTV looks correct to me and ensures that we can only attach any state >=3D s+1. So just to show the output script for state `i` how I think they are correct: ``` OP_IF OP_CSV 2 2 OP_CHECKMULTISIG OP_ELSE OP_CLTV OP_DROP 2 2 OP_CHECKMULTISIG=20 ``` And the input scripts for the update tx and the settlement tx respectively would be: ``` OP_FALSE ``` and ``` OP_TRUE ``` > 4. They create the settlement tx 0, spending the update-0 output with > As0 and Bs0 using BIP68 relative-locktime, with 2 settlement outputs 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 :-) > 5. They sign the setup tx and let it confirm 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. > 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 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). > 7. To close the channel, broadcast update tx 1. Wait for several > confirmations. And broadcast settlement-tx-1 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. 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. 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 :-)