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 C5AD68EE for ; Fri, 21 Dec 2018 11:15:45 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-ed1-f44.google.com (mail-ed1-f44.google.com [209.85.208.44]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id D213484F for ; Fri, 21 Dec 2018 11:15:44 +0000 (UTC) Received: by mail-ed1-f44.google.com with SMTP id y20so4349777edw.9 for ; Fri, 21 Dec 2018 03:15:44 -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=wB4Ur8W3s+DSDy3eBvVhWgPGnSZZaze+n0zWMNO72ZE=; b=KGKZddYh4tLOr31115Y4P4ry0goVy9UeIjeHuPZUF33Lm/qDV3OQLFUiM4xXSs1Adc KxrKzZJSELk2ocyHz6IgdUzZre/bqrnkbBPsb9OMqfSzDEBJqBnjUrLPmfVmGsYQjo8E /7W3GoT03qbeZJL1rsWbdt0VdRKl8huT6V0PaH2TsawoMB/09HIBORxytNMRr3MlkoFG UTwFjKWZNxqkXyAr2Med7yfpN9OVtr6TxQmTPE4XRKtal+QxQN6LikEvsEzxMpdTK+Xg e4+/SVsRbuEWyUuYQcNP7blfr9BmzAt5swPkvMbnBq+x+17NW05BuCJMCBrXih5XxrZl n6fg== 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=wB4Ur8W3s+DSDy3eBvVhWgPGnSZZaze+n0zWMNO72ZE=; b=VN7mGLxUOakdcCI03RReBVBqNDH2PHen2QWgGCGGqzegMIpWvSweGHgo6SJXp4vVvr ycgeMo5e9MpEtGua+dXy3kk9Yhk39CoInSUNTvEG2WYw6W2xi3o/8L/GjW/29xTRLQh8 Oq+jELBHrH9OuwnQ7hYoxjf34ARtag0iOafgWEDujOJFjIQStgFVR7eTlzvfnINPN0jC KGX3RaGyrKeDIhXolM7OpY9M7ROFHv7XIFAwRGGEq3OkpAARV0lA/A43IVYWLX++ppg1 iRtd+M1zXN4xm5WSFMrRjMZgx/MB+lEMiqoUyQCMtwqKTc/Nvf+JBNyEtX2aJU408UfE +GfA== X-Gm-Message-State: AA+aEWYWXj0NeyEdsTWrzkkInKv4dxBGjTl1/7mJvOStp6/tjAeszY/o 3ts9BPar1j1AzIpe/tvRFp8= X-Google-Smtp-Source: AFSGD/WzPIPuk8CbRVBbXMGwwSYt2X/0lrqvwKcRIPO05AH97Qkvzwb5TvkXaDOz1ZcjzNFPAjkLMQ== X-Received: by 2002:a17:906:590a:: with SMTP id h10-v6mr1858111ejq.102.1545390943305; Fri, 21 Dec 2018 03:15:43 -0800 (PST) Received: from localhost ([2a02:aa16:1102:5480:b8c8:56f0:43e2:f1fe]) by smtp.gmail.com with ESMTPSA id z9sm6958835edr.61.2018.12.21.03.15.41 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Fri, 21 Dec 2018 03:15:42 -0800 (PST) From: Christian Decker To: Johnson Lau In-Reply-To: <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> <34A8F2C4-4732-4BE7-84F5-699B8D709D06@xbt.hk> Date: Fri, 21 Dec 2018 12:15:37 +0100 Message-ID: <87woo3uo4m.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: Fri, 21 Dec 2018 23:29:30 +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: Fri, 21 Dec 2018 11:15:45 -0000 Johnson Lau writes: >> 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. Correct, we're using the CLTV here as a weird "compare two numbers that are committed to in the signatures" operation, by using locktimes in the past as you correctly point out. > 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 I keep forgetting about BIP68, but you're right, that should be sufficient for our use-case and would safe us a few bytes. >> 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. I seem to keep mentally mixing different variants of the protocol in my head. You are of course correct that the trigger and the update can be considered the same, hence the 3 txs limit is right. Sorry for the confusion :-(