Re: [bitcoin-dev] [Lightning-dev] More thoughts on NOINPUT safety

From: ZmnSCPxj <ZmnSCPxj@protonmail•com>
To: Rusty Russell <rusty@rustcorp•com.au>
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
Date: Wed, 20 Mar 2019 07:38:22 +0000	[thread overview]
Message-ID: <UOdt33VfD8o6NfeDKMSip0hUmy1_jyo65-ihunuMRRg8IfXEOq-W60-TPoINm5HErPqnY_-yd1x_VnnVihrvtXRA2OHkjeROZheZ_QV0Zvo=@protonmail.com> (raw)
In-Reply-To: <87woku9q3g.fsf@rustcorp.com.au>

Hi all,

> Since "must have a non-SIGHASH_NOINPUT" rule addresses the first reuse
> scenario (as well as the second), I'd be content with that proposal.

How would this work with watchtowers?

As I understand it, the current plan for eltoo watchtowers would be to store both `SIGHASH_NOINPUT` signatures from both sides in the blob sent to the watchtower.

Then the watchtower can always attach this to whatever is the tipmost available on the chain of transactions.

However, if one of the signatures MUST be non-`SIGHASH_NOINPUT` --- how does the watchtower create such a non-`SIGHASH_NOINPUT` signature?

Regards,
ZmnSCPxj

> Future segwit versions may choose to relax it.[1]
>
> Cheers,
> Rusty.
> [1] Must be consensus, not standardness; my prev suggestion was bogus.
>
> Rusty Russell rusty@rustcorp•com.au writes:
>
> > Anthony Towns aj@erisian•com.au writes:
> >
> > > If you publish to the blockchain:
> > > ...
> > > 4 can be dropped, state 5 and finish can be altered). Since the CSV delay
> > > is chosen by the participants, the above is still a possible scenario
> > > in eltoo, though, and it means there's some risk for someone accepting
> > > bitcoins that result from a non-cooperative close of an eltoo channel.
> >
> > AJ, this was a meandering random walk which shed very little light.
> > I don't find the differentiation between malicious and non-malicious
> > double-spends convincing. Even if you trust A, you already have to
> > worry about person-who-sent-the-coins-to-A. This expands that set to be
> > "miner who mined coins sent-to-A", but it's very hard to see what
> > difference that makes to how you'd handle coins from A.
> >
> > > Beyond that, I think NOINPUT has two fundamental ways to cause problems
> > > for the people doing NOINPUT sigs:
> > >
> > > 1.  your signature gets applied to a unexpectedly different
> > >     script, perhaps making it look like you've being dealing
> > >     with some blacklisted entity. OP_MASK and similar solves
> > >     this.
> > >
> >
> > ... followed by two paragraphs describing how it's not a "fundamental
> > way to cause problems" that you (or I) can see.
> >
> > > For the second case, that seems a little more concerning. The nightmare
> > > scenario is maybe something like:
> > >
> > > -   naive users do silly things with NOINPUT signatures, and end up
> > >     losing funds due to replays like the above
> > >
> >
> > As we've never seen with SIGHASH_NONE?
> >
> > > -   initial source of funds was some major exchange, who decide it's
> > >     cheaper to refund the lost funds than deal with the customer complaints
> > >
> > > -   the lost funds end up costing enough that major exchanges just outright
> > >     ban sending funds to any address capable of NOINPUT, which also bans
> > >     all taproot/schnorr addresses
> > >
> >
> > I don't find this remotely credible.
> >
> > > FWIW, I don't have a strong opinion here yet, but:
> > >
> > > -   I'm still inclined to err on the side of putting more safety
> > >     measures in for NOINPUT, rather than fewer
> > >
> >
> > In theory, sure. But not feel-good and complex "safety measures" which
> > don't actually help in practical failure scenarios.
> >
> > > -   the "must have a sig that commits to the input tx" seems like it
> > >     should be pretty safe, not too expensive, and keeps taproot's privacy
> > >     benefits in the cases where you end up needing to use NOINPUT
> > >
> >
> > If this is considered necessary, can it be a standardness rule rather
> > than consensus?
> > Thanks,
> > Rusty.
>
> Lightning-dev mailing list
> Lightning-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev