Christian Decker [ARCHIVE] on Nostr: 📅 Original date posted:2019-03-14 📝 Original message: Anthony Towns <aj at ...

📅 Original date posted:2019-03-14
📝 Original message:
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.