1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
|
Return-Path: <ZmnSCPxj@protonmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id F07A13E2E
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 20 Mar 2019 07:38:31 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mail-40136.protonmail.ch (mail-40136.protonmail.ch
[185.70.40.136])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 054C4148
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 20 Mar 2019 07:38:30 +0000 (UTC)
Date: Wed, 20 Mar 2019 07:38:22 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
s=default; t=1553067508;
bh=VGxP+PK2YghyEcCj/T5Ki8wKzr9D/ICL1VBo+qy1jdE=;
h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:
Feedback-ID:From;
b=xORsYMsWQ8fQz45+8/H+uM1lffMDdIkpqbLfJnUIY246zwdRVdYvICQy1ee1EIqB0
qVkgjyuMh5btupuY85hWrPUaq+jgGZuReVRpXyzNZb7BJQYyvKy0c0G7aGNMbAQB89
XFJFPVhtOwQ0+USgwzrYYzJUzdKLH9eK/pteUl7w=
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
X-Spam-Status: No, score=-2.2 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, FROM_LOCAL_NOVOWEL,
RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
X-Mailman-Approved-At: Wed, 20 Mar 2019 21:04:42 +0000
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
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Wed, 20 Mar 2019 07:38:32 -0000
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
|
