Date: Wed, 20 Mar 2019 07:38:22 +0000
To: Rusty Russell <rusty@rustcorp.com.au>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <UOdt33VfD8o6NfeDKMSip0hUmy1_jyo65-ihunuMRRg8IfXEOq-W60-TPoINm5HErPqnY_-yd1x_VnnVihrvtXRA2OHkjeROZheZ_QV0Zvo=@protonmail.com>
In-Reply-To: <87woku9q3g.fsf@rustcorp.com.au>
References: <20190313014143.ifffshwdux2jt7w5@erisian.com.au>
	<87k1gubdjm.fsf@rustcorp.com.au> <87woku9q3g.fsf@rustcorp.com.au>
Feedback-ID: el4j0RWPRERue64lIQeq9Y2FP-mdB86tFqjmrJyEPR9VAtMovPEo9tvgA0CrTsSHJeeyPXqnoAu6DN-R04uJUg==:Ext:ProtonMail
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
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

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 stor=
e 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 avail=
able on the chain of transactions.

However, if one of the signatures MUST be non-`SIGHASH_NOINPUT` --- how doe=
s 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 d=
elay
> > > is chosen by the participants, the above is still a possible scenario
> > > in eltoo, though, and it means there's some risk for someone acceptin=
g
> > > 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 proble=
ms
> > > 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 nightma=
re
> > > 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 comp=
laints
> > >
> > > -   the lost funds end up costing enough that major exchanges just ou=
tright
> > >     ban sending funds to any address capable of NOINPUT, which also b=
ans
> > >     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 pri=
vacy
> > >     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