From: Christian Decker <decker.christian@gmail.com>
To: Anthony Towns <aj@erisian.com.au>, ZmnSCPxj <ZmnSCPxj@protonmail.com>
In-Reply-To: <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>
	<20190314072456.br2leoiae6zs2jv2@erisian.com.au>
Date: Thu, 14 Mar 2019 13:00:56 +0100
Message-ID: <87mulx3bt3.fsf@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain
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

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