Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id CB58CA55 for ; Thu, 20 Dec 2018 11:01:03 +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 401AC7FB for ; Thu, 20 Dec 2018 11:01:02 +0000 (UTC) ARC-Seal: i=1; a=rsa-sha256; t=1545303660; cv=none; d=zoho.com; s=zohoarc; b=SzD24AmFuZd/NbODlmAWOp/7hcLbE23iSYO3FiD4K6zq0m7C90KYjGwOn0ierH2MFNvZ1+WB4TELPrWoqE39yAxeoCTiRJkq6Hev+r3wBPWqJNY3BQmgvx1gVyv+QaexA2OvamoWt2Gj5qwdVfpMQjAdbCc+N/ugPE7ND/BkQFE= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zoho.com; s=zohoarc; t=1545303660; h=Content-Type:Cc:Date:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:To:ARC-Authentication-Results; bh=kz6xu2IgvwBAZWHMyZhePXCz7VXBGIDuPPJ/aH7S+L4=; b=kQ8VtqE8nZLcLp/ajZeAktmdsHFG2ngxQ5+1rcdMwj4C0OduqGiHHRJouaHIEUEK4fyYsCcGjrz6tVS1ttLP2wcToiFgLu/hub1dbFEeJWZ1/rTzucf71bxRdqDZEYsUGuqiczdv1hhzkAaajjyFQCVdtOjus6VqNmU7cWmI678= 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 1545303659095616.3726838002292; Thu, 20 Dec 2018 03:00:59 -0800 (PST) From: Johnson Lau Message-Id: <195B4583-CE97-4C3A-9582-3C0C013CC1E9@xbt.hk> Content-Type: multipart/alternative; boundary="Apple-Mail=_6E06BF54-DDDC-4F3A-972B-6F1E49FFD9AA" Mime-Version: 1.0 (Mac OS X Mail 12.0 \(3445.100.39\)) Date: Thu, 20 Dec 2018 19:00:53 +0800 In-Reply-To: <87efadp3rl.fsf@gmail.com> To: Christian Decker References: <9F8C0789-48E9-448A-A239-DB4AFB902A00@xbt.hk> <87efadp3rl.fsf@gmail.com> X-Mailer: Apple Mail (2.3445.100.39) 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: 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 11:01:03 -0000 --Apple-Mail=_6E06BF54-DDDC-4F3A-972B-6F1E49FFD9AA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 20 Dec 2018, at 6:09 AM, Christian Decker = wrote: >=20 > Ruben Somsen via bitcoin-dev > > writes: >=20 >> Hi Johnson, >>=20 >> The design considerations here seem similar to the ML discussion of >> whether Graftroot should be optional [1]. >>=20 >>> While this seems fully compatible with eltoo, is there any other = proposals require NOINPUT, and is adversely affected by either way of = tagging? >>=20 >> As far as I can tell it should be compatible with Statechains [2], >> since it pretty much mirrors Eltoo in setup. >>=20 >> My understanding is somewhat lacking, so perhaps I am missing the >> mark, but it is not completely clear to me how this affects >> fungibility if taproot gets added and the setup and trigger tx for >> Eltoo get combined into a single transaction. Would the NOINPUT >> spending condition be hidden inside the taproot commitment? >=20 > I'm not aware of a way to combine the setup and trigger transaction. = The > trigger transaction was introduced in order to delay the start of the > timeouts until a later time, to avoid having an absolute lifetime = limit > and having really huge timeout. If we were to combine the trigger > transaction with the setup transaction (which is broadcast during > channel creation), all of those timeouts would start counting down > immediately, and we could just skip the trigger transaction > altogether. It'd be more interesting to combine update and trigger > transactions in a sort of cut-through combination, but that doesn't = seem > possible outside of Mimblewimble. >=20 > Cheers, > Christian 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 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 4. They create the settlement tx 0, spending the update-0 output with = As0 and Bs0 using BIP68 relative-locktime, with 2 settlement outputs 5. They sign the setup tx and let it confirm 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 7. To close the channel, broadcast update tx 1. Wait for several = confirmations. And broadcast settlement-tx-1 --Apple-Mail=_6E06BF54-DDDC-4F3A-972B-6F1E49FFD9AA Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On 20 Dec 2018, at 6:09 AM, Christian Decker <decker.christian@gmail.com> wrote:

Ruben Somsen via bitcoin-dev = <bitcoin-dev@lists.linuxfoundation.org>
writes:

Hi = Johnson,

The design considerations here = seem similar to the ML discussion of
whether Graftroot = should be optional [1].

While this seems fully compatible with eltoo, = is there any other proposals require NOINPUT, and is adversely affected = by either way of tagging?

As = far as I can tell it should be compatible with Statechains [2],
since it pretty much mirrors Eltoo in setup.

My understanding is somewhat lacking, so perhaps I am missing = the
mark, but it is not completely clear to me how this = affects
fungibility if taproot gets added and the setup = and trigger tx for
Eltoo get combined into a single = transaction. Would the NOINPUT
spending condition be = hidden inside the taproot commitment?

I'm not aware of a way to = combine the setup and trigger transaction. The
trigger transaction was = introduced in order to delay the start of the
timeouts until a later time, to = avoid having an absolute lifetime limit
and having really huge timeout. If we were to combine the = trigger
transaction = with the setup transaction (which is broadcast during
channel creation), all of those = timeouts would start counting down
immediately, and we could just skip the trigger = transaction
altogether. = It'd be more interesting to combine update and trigger
transactions in a sort of = cut-through combination, but that doesn't seem
possible outside of = Mimblewimble.

Cheers,
Christian


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: <s> CLTV = DROP 2 Au Bu 2 CHECKMULTISIG. Do not sign

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 <s+1> CLTV DROP 2 Au Bu 2 CHECKMULTISIG = ENDIF

4. They = create the settlement tx 0, spending the update-0 output with As0 and = Bs0 using BIP68 relative-locktime, with 2 settlement outputs

5. They sign the setup = tx and let it confirm

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 <s+2> 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

7. To close the channel, broadcast update tx 1. Wait for = several confirmations. And broadcast settlement-tx-1


= --Apple-Mail=_6E06BF54-DDDC-4F3A-972B-6F1E49FFD9AA--