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? If that's the case we just doubled our storage and communication requirements for very little gain. 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. _______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
