From decker.christian at gmail.com Thu Mar 14 12:00:56 2019 From: decker.christian at gmail.com (Christian Decker) Date: Thu, 14 Mar 2019 13:00:56 +0100 Subject: [Lightning-dev] More thoughts on NOINPUT safety In-Reply-To: <20190314072456.br2leoiae6zs2jv2@erisian.com.au> References: <20190313014143.ifffshwdux2jt7w5@erisian.com.au> <20190313111050.qj3s6utpl2x34sam@erisian.com.au> <20190314072456.br2leoiae6zs2jv2@erisian.com.au> Message-ID: <87mulx3bt3.fsf@gmail.com> Anthony Towns 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.