[Lightning-dev] More thoughts on NOINPUT safety

Christian Decker decker.christian at gmail.com
Thu Mar 14 12:00:56 UTC 2019


Anthony Towns <aj at 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.


More information about the Lightning-dev mailing list