On Thu, Mar 14, 2019 at 01:00:56PM +0100, Christian Decker wrote: > Anthony Towns <a...@erisian.com.au> writes: > > 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. > I might be missing something here, but how do you bind update 3 to the > funding tx output, when that output is not tagged? Do we keep each > update in multiple separate states, one bound to the funding tx output > and another signed with noinput?
I don't know that "separate states" is a great description -- until it hits the blockchain "update N" is a template that can be filled out in a variety of ways -- in the above the ways are: - with a NOINPUT sig and a previous "update" tx as its input - or with a SINGLE|ANYONECANPAY sig and the funding tx as input The important thing is that approach means two sigs for each update tx. The above also has two sigs for each settlement tx (and likewise two sigs for each HTLC claim if using scriptless scripts) -- one using NOINPUT in case multiple update tx's make it to the blockchain, and one assuming everything works as expected that can just use direct key path spending. I think you can do SINGLE,ANYCANPAY and combine multiple channel closures if you're directly spending the funding tx, but can't do that if you're using a NOINPUT sig, because the NOINPUT sig would commit to the tx's locktime and different channel's states will generally have different locktimes. You still probably want SINGLE,ANYCANPAY in that case so you can bump fees though. > If that's the case we just doubled our > storage and communication requirements for very little gain. There's three potential gains: * it lets us make a safer version of NOINPUT * it makes the common paths give fewer hints that you're using eltoo * it puts less data/computation load on the blockchain With tagged outputs your update tx already indicates you're maybe going to use NOINPUT, so that probably already gives away that you're using eltoo, so, at least with output tagging, the second benefit probably doesn't exist. Using a key path spend (without a script) is probably going to be cheaper on the blockchain though. But while I think output tagging is probably better than nothing, requiring a non-NOINPUT signature seems a better approach to me. With that one, having a dedicated sig for the normal "publish the latest state spending the funding tx" case, reduces a unilateral close to only being special due to the settlement tx having a relative timelock, and the various tx's using SINGLE|ANYCANPAY, which seems like a win. In that scenario, just using a single sig is much cheaper than revealing a taproot point, a pubkey or two, and using two sigs and a CLTV check of course. It does goes from 1+n signatures per update today to 4+n signatures, if you're using scriptless scripts. If you don't mind revealing the HTLCs are HTLCs, and could do them with actual scripts, that reduces to 4 signatures. You could reduce it to 2 signatures by also always posting "funding tx -> update 0 -> update N -> settlement N", or you could reduce it to 2+2/k signatures by only doing the non-NOINPUT sigs for every k'th state (or no more often than every t seconds or similar). > An > alternative is to add a trigger transaction that needs to be published > in a unilateral case, but that'd increase our on-chain footprint. (The above essentially uses update tx's as optional trigger tx's) Also, I'd expect the extra latency introduced by the interactive signing protocol for muSig would be more of a hit (share the nonce hash, share the nonce, calculate the sig). Particularly if you're doing multiparty channels with many participants, rather than just two. Cheers, aj _______________________________________________ Lightning-dev mailing list Lightningfirstname.lastname@example.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev