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)
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
Precedence: list

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