Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 510AD1149; Thu, 21 Mar 2019 08:38:13 +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 9A68FD3; Thu, 21 Mar 2019 08:38:12 +0000 (UTC) ARC-Seal: i=1; a=rsa-sha256; t=1553157481; cv=none; d=zoho.com; s=zohoarc; b=ZitP/ick5/g1dEl9L/eXu0hlPX3IGW4RrbTcRX9V9VJ2VOScAsIHn4gRQdVZDRxS5o63z7o51cMqiPxITVu0huxTMxXnVTwvDGFjYxFIJRbVUnpULr8sfiFdRkOSNjv+xilM1kFdvRA9+7g0+a3HVZv3TD7RrT/fev2ohoZ+Q1c= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zoho.com; s=zohoarc; t=1553157481; h=Content-Type:Cc:Date:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:To:ARC-Authentication-Results; bh=99raCkHwTEfJxVp19gp4NemTtr3Io9QqiJMXMHQYxQo=; b=JvNf16tWVEB3DNFqI1r1hxfMx2eIlcGNrSOMQLC+kVXq00KCokMsTzFOoDiV4QUaMFfr1ESTEJN+4sG1CID9rqT9t1KW57/nEdxhpFxEXMkKNp2txWDPwGH3FSs2gvBib++QCG/K0/yCtqEd+8Cuxdmm7lS3USl+m1IY1WrxxFw= 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 1553157478684759.1265403083509; Thu, 21 Mar 2019 01:37:58 -0700 (PDT) From: Johnson Lau Message-Id: <1D5043F6-DC7B-4D40-9B68-30125829A7F6@xbt.hk> Content-Type: multipart/alternative; boundary="Apple-Mail=_1BEAD8F9-AF34-4F09-BDF0-F25AE6715A03" Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Date: Thu, 21 Mar 2019 16:37:54 +0800 In-Reply-To: To: ZmnSCPxj , bitcoin-dev References: <20190313014143.ifffshwdux2jt7w5@erisian.com.au> <87k1gubdjm.fsf@rustcorp.com.au> <87woku9q3g.fsf@rustcorp.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: Thu, 21 Mar 2019 16:54:19 +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: Thu, 21 Mar 2019 08:38:13 -0000 --Apple-Mail=_1BEAD8F9-AF34-4F09-BDF0-F25AE6715A03 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 20 Mar 2019, at 4:07 PM, ZmnSCPxj via bitcoin-dev = wrote: >=20 > Hi aj, >=20 > Re-reading again, I think perhaps I was massively confused by this: >=20 >> - alternatively, we could require every script to have a valid = signature >> that commits to the input. In that case, you could do eltoo with a >> script like either: >>=20 >> CHECKSIGVERIFY CHECKSIG >> or

CHECKSIGVERIFY CHECKSIG >>=20 >>=20 >> where A is Alice's key and B is Bob's key, P is muSig(A,B) and Q is >> a key they both know the private key for. In the first case, Alice >> would give Bob a NOINPUT sig for the tx, and when Bob wanted to = publish >> Bob would just do a SIGHASH_ALL sig with his own key. In the second, >> Alice and Bob would share partial NOINPUT sigs of the tx with P, and >> finish that when they wanted to publish. >=20 > Do you mean that *either* of the above two scripts is OK, *or* do you = mean they are alternatives within a single MAST or `OP_IF`? >=20 It means either. If you use CHECKSIGVERIFY CHECKSIG style, A and B will exchange = the NOINPUT sig, and they will add the required non-NOINPUT sig when = needed. If you use CHECKVERIFY CHECKSIG, A and B will co-sign = the muSig(A,B) with NOINPUT. They will also share the private key of Q, = so they could produce a non-NOINPUT sig when needed. The first style is slightly easier as it doesn=E2=80=99t need muSig. But = with 3 or more parties, the second style is more efficient. However, if you use watchtower, you have to use the second style. That = means you need to share the private key for Q with the watchtower, That = also means the watchtower will have the ability to reply the NOINPU = muSig. But it is still strictly better than anyone-can-replay. --Apple-Mail=_1BEAD8F9-AF34-4F09-BDF0-F25AE6715A03 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8


On 20 Mar 2019, at 4:07 PM, ZmnSCPxj via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:

Hi aj,

Re-reading again, I think = perhaps I was massively confused by this:

- alternatively, we could require = every script to have a valid signature
that commits to the = input. In that case, you could do eltoo with a
script like = either:

<A> CHECKSIGVERIFY <B> = CHECKSIG
or <P> CHECKSIGVERIFY <Q> CHECKSIG


where A is Alice's key and B is = Bob's key, P is muSig(A,B) and Q is
a key they both know = the private key for. In the first case, Alice
would give = Bob a NOINPUT sig for the tx, and when Bob wanted to publish
Bob would just do a SIGHASH_ALL sig with his own key. In the = second,
Alice and Bob would share partial NOINPUT sigs of = the tx with P, and
finish that when they wanted to = publish.

Do you mean that *either* of the above two scripts is OK, = *or* do you mean they are alternatives within a single MAST or = `OP_IF`?


It = means either.

If you use <A> = CHECKSIGVERIFY <B> CHECKSIG style, A and B will exchange the = NOINPUT sig, and they will add the required non-NOINPUT sig when = needed.

If you use = <muSig(A,B)> CHECKVERIFY <Q> CHECKSIG, A and B will co-sign = the muSig(A,B) with NOINPUT. They will also share the private key of Q, = so they could produce a non-NOINPUT sig when needed.

The first style is slightly easier as it doesn=E2=80= =99t need muSig. But with 3 or more parties, the second style is more = efficient.

However, if you use = watchtower, you have to use the second style. That means you need to = share the private key for Q with the watchtower, That also means the = watchtower will have the ability to reply the NOINPU muSig. But it is = still strictly better than anyone-can-replay.

= --Apple-Mail=_1BEAD8F9-AF34-4F09-BDF0-F25AE6715A03--