+Return-Path: <aj@erisian.com.au>

+Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org

+ [172.17.192.35])

+ by mail.linuxfoundation.org (Postfix) with ESMTPS id 5D391FF7;

+ Thu, 14 Mar 2019 07:25:06 +0000 (UTC)

+X-Greylist: from auto-whitelisted by SQLgrey-1.7.6

+X-Greylist: from auto-whitelisted by SQLgrey-1.7.6

+Received: from azure.erisian.com.au (cerulean.erisian.com.au [139.162.42.226])

+ by smtp1.linuxfoundation.org (Postfix) with ESMTPS id C4BD282B;

+ Thu, 14 Mar 2019 07:25:05 +0000 (UTC)

+Received: from aj@azure.erisian.com.au (helo=sapphire.erisian.com.au)

+ by azure.erisian.com.au with esmtpsa (Exim 4.89 #1 (Debian))

+ id 1h4Kjc-00070B-Rd; Thu, 14 Mar 2019 17:25:02 +1000

+Received: by sapphire.erisian.com.au (sSMTP sendmail emulation);

+ Thu, 14 Mar 2019 17:24:56 +1000

+Date: Thu, 14 Mar 2019 17:24:56 +1000

+From: Anthony Towns <aj@erisian.com.au>

+To: ZmnSCPxj <ZmnSCPxj@protonmail.com>

+Message-ID: <20190314072456.br2leoiae6zs2jv2@erisian.com.au>

+References: <20190313014143.ifffshwdux2jt7w5@erisian.com.au>

+ <gs0Aizmvb8U11-Uz4RUqrEwgu00deU3JRhwHWbPjn8g1lZV3iaydqoYP3tldfrflHRC2HHJEZtAOVeYdaOW-chMcRdPVSiNYmqT6jSPnL1c=@protonmail.com>

+ <20190313111050.qj3s6utpl2x34sam@erisian.com.au>

+ <Au1N1itlfJk5MRV-KoKfmL9BgOGBW1Pdq9vRr-PBVVJfpRngTmpuTmbF5wCAkBSsUvMt3maA3e-VVr-WDDdwh2-XVeCOLjxVsOxABm7cfpU=@protonmail.com>

+MIME-Version: 1.0

+Content-Type: text/plain; charset=us-ascii

+Content-Disposition: inline

+In-Reply-To: <Au1N1itlfJk5MRV-KoKfmL9BgOGBW1Pdq9vRr-PBVVJfpRngTmpuTmbF5wCAkBSsUvMt3maA3e-VVr-WDDdwh2-XVeCOLjxVsOxABm7cfpU=@protonmail.com>

+User-Agent: NeoMutt/20170113 (1.7.2)

+X-Spam-Score: -1.9

+X-Spam-Score-int: -18

+X-Spam-Bar: -

+X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,UNPARSEABLE_RELAY

+ 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, 14 Mar 2019 07:29:59 +0000

+Cc: "bitcoin-dev@lists.linuxfoundation.org"

+ <bitcoin-dev@lists.linuxfoundation.org>,

+ "lightning-dev@lists.linuxfoundation.org"

+ <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 <bitcoin-dev.lists.linuxfoundation.org>

+List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,

+ <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>

+List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>

+List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>

+List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>

+List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,

+ <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>

+X-List-Received-Date: Thu, 14 Mar 2019 07:25:06 -0000

+

+On Thu, Mar 14, 2019 at 05:22:59AM +0000, ZmnSCPxj via Lightning-dev wrote:

+> When reading through your original post I saw you mentioned something about output tagging somehow conflicting with Taproot, so I assumed Taproot is not useable in this case.

+

+I'm thinking of tagged outputs as "taproot plus" (ie, plus noinput),

+so if you used a tagged output, you could do everything normal taproot

+address could, but also do noinput sigs for them.

+

+So you might have:

+

+ funding tx -> cooperative claim

+

+ funding tx -> update 3 [TAGGED] -> settlement 3 -> claim

+

+ funding tx -> update 3 [TAGGED] ->

+ update 4 [TAGGED,NOINPUT] ->

+ settlement 4 [TAGGED,NOINPUT] ->

+ claim [NOINPUT]

+

+In the cooperative case, no output tagging needed.

+

+For the unilateral case, you need to tag all the update tx's, because

+they *could* be spend by a later update with a NOINPUT sig, and if

+that actually happens, then the settlement tx also needs to use a

+NOINPUT sig, and if you're using scriptless scripts to resolve HTLCs,

+claiming/refunding the HTLCs needs a partially-pre-signed tx which also

+needs to be a NOINPUT sig, meaning the settlement tx also needs to be

+tagged in that case.

+

+You'd only need the script path for the last case where there actually

+are multiple updates, but because you have to have a tagged output in the

+second case anyway, maybe you've already lost privacy and always using

+NOINPUT and the script path for update and settlement tx's would be fine.

+

+> However, it is probably more likely that I simply misunderstood what you said, so if you can definitively say that it would be possible to hide the clause "or a NOINPUT sig from A with a non-NOINPUT sig from B" behind a Taproot then I am fine.

+

+Yeah, that's my thinking.

+

+> Minor pointless reactions:

+> > 5. if you're using scriptless scripts to do HTLCs, you'll need to

+> > allow for NOINPUT sigs when claiming funds as well (and update

+> > the partial signatures for the non-NOINPUT cases if you want to

+> > maximise privacy), which is a bit fiddly

+> If I remember accurately, we do not allow bilateral/cooperative close when HTLC is in-flight.

+> However, I notice that later you point out that a non-cheating unilateral close does not need NOINPUT, so I suppose. the above thought applies to that case.

+

+Yeah, exactly.

+

+Trying to maximise privacy there has the disadvantage that you have to

+do a new signature for every in-flight HTLC every time you update the

+state, which could be a lot of signatures for very active channels.

+

+Cheers,

+aj

+

+