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
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
|
Return-Path: <fred_savage2003@hotmail.co.uk>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id B689EC50
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 13 Jul 2018 09:50:50 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from EUR03-AM5-obe.outbound.protection.outlook.com
(mail-oln040092070019.outbound.protection.outlook.com [40.92.70.19])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id C32A66D6
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 13 Jul 2018 09:50:49 +0000 (UTC)
Received: from DB5EUR03FT033.eop-EUR03.prod.protection.outlook.com
(10.152.20.55) by DB5EUR03HT140.eop-EUR03.prod.protection.outlook.com
(10.152.21.173) with Microsoft SMTP Server (version=TLS1_2,
cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.930.16;
Fri, 13 Jul 2018 09:50:47 +0000
Received: from VI1PR1001MB1309.EURPRD10.PROD.OUTLOOK.COM (10.152.20.56) by
DB5EUR03FT033.mail.protection.outlook.com (10.152.20.76) with Microsoft
SMTP Server (version=TLS1_2,
cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id
15.20.952.17 via Frontend Transport; Fri, 13 Jul 2018 09:50:47 +0000
Received: from VI1PR1001MB1309.EURPRD10.PROD.OUTLOOK.COM
([fe80::a1c9:4137:6b7b:d60e]) by
VI1PR1001MB1309.EURPRD10.PROD.OUTLOOK.COM
([fe80::a1c9:4137:6b7b:d60e%8]) with mapi id 15.20.0952.017;
Fri, 13 Jul 2018 09:50:47 +0000
From: fred savage <fred_savage2003@hotmail.co.uk>
To: Rusty Russell <rusty@rustcorp.com.au>, Bitcoin Protocol Discussion
<bitcoin-dev@lists.linuxfoundation.org>
Thread-Topic: [bitcoin-dev] [Lightning-dev] BIP sighash_noinput
Thread-Index: AQHUEselD0WWJh1tD0mLalZbedKWy6SMVRiEgACfV6Y=
Date: Fri, 13 Jul 2018 09:50:47 +0000
Message-ID: <VI1PR1001MB1309AFFE2838D85CBCB77C66DE580@VI1PR1001MB1309.EURPRD10.PROD.OUTLOOK.COM>
References: <871sewirni.fsf@gmail.com>
<CAAS2fgS-_D7aBcDf_nAbuREBxv65zYMr60-1YqCnx-esvRVfEg@mail.gmail.com>
<201807031213.51127.luke@dashjr.org>
<CAK_c0Xo0G9-YiOGZK_8WsYNkzjQRaH+u7XOUAozKosggXeXTNg@mail.gmail.com>,
<878t6gxapt.fsf@rustcorp.com.au>
In-Reply-To: <878t6gxapt.fsf@rustcorp.com.au>
Accept-Language: en-GB, en-US
Content-Language: en-GB
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-incomingtopheadermarker: OriginalChecksum:E5BAAF79FA61BE7B98E33982F3A3ADF4A9324E8010A637A41C98070AA9A4C570;
UpperCasedChecksum:5D6647B47C895E9AF947B78A060912530F3B27C833ACCAD7D9989689A137CDAF;
SizeAsReceived:7454; Count:46
x-ms-exchange-messagesentrepresentingtype: 1
x-tmn: [qnHOiYbs5t9So78s8xCQ328bdlcySGOUPfwqgOGNk7bJeS+qJQuPiqu8PrH3xOEX]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; DB5EUR03HT140;
7:iIfJkORvEx4UczE3DtY9QLKo0JipoaZbesdVY+fthaxgbdDpsmIbB0RiO8CWcB9syOYiN0HyWwLFjS/KsjyLwlDGhffSY+fUQwWxSZhtOyYsx+rbul6Oz2uVF5xY8e8pQfBIN3yo8lj6bFvwQhralGj7LDyS3v2DeFo0rS0PHlTHjz2aCLFN8V229rjP14Fx0Xpoq/oMyyodXbb6Jwr3X7z2JsQiMK7Y5lj03kC8VKTlUZPfZ/2nNSCaSIHHQ7J2
x-incomingheadercount: 46
x-eopattributedmessage: 0
x-microsoft-antispam: UriScan:; BCL:0; PCL:0;
RULEID:(7020095)(201702061078)(5061506573)(5061507331)(1603103135)(2017031320274)(2017031324274)(2017031323274)(2017031322404)(1601125500)(1603101448)(1701031045);
SRVR:DB5EUR03HT140;
x-ms-traffictypediagnostic: DB5EUR03HT140:
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(82015058);
SRVR:DB5EUR03HT140; BCL:0; PCL:0; RULEID:; SRVR:DB5EUR03HT140;
x-forefront-prvs: 07326CFBC4
x-forefront-antispam-report: SFV:NSPM;
SFS:(7070007)(189003)(199004)(606006)(6606003)(104016004)(8936002)(97736004)(105586002)(476003)(6506007)(551934003)(6346003)(106356001)(486006)(76176011)(73972006)(99286004)(102836004)(56003)(74316002)(93886005)(74482002)(81156014)(8676002)(256004)(14444005)(33656002)(5660300001)(86362001)(82202002)(2900100001)(46003)(6246003)(9686003)(19627405001)(5250100002)(229853002)(54896002)(55016002)(6306002)(86152003)(6436002)(236005)(110136005)(68736007)(14454004)(446003)(11346002)(7696005)(966005)(25786009)(46252003);
DIR:OUT; SFP:1901; SCL:1; SRVR:DB5EUR03HT140;
H:VI1PR1001MB1309.EURPRD10.PROD.OUTLOOK.COM; FPR:; SPF:None;
PTR:InfoNoRecords; MX:1; A:1; LANG:;
received-spf: None (protection.outlook.com: hotmail.co.uk does not designate
permitted sender hosts)
authentication-results: spf=none (sender IP is )
smtp.mailfrom=fred_savage2003@hotmail.co.uk;
x-microsoft-antispam-message-info: Hc070ARbzCcaOVPd1kPAbeZz9jvGKGyOLCoLgLILpS95hzjL36wwe8fBpQ7aPX8bakP04iM5d+0UUpIZMFMElSeyBAFHYkXafu2LZhSxbyB4/IkeOTVwa42Ug/FVN47+hTT206cqwm1s2Nfi+JtAW0sCs478k+xDzglRymc+3NlRdbPaQwswGVBcgRBowSRqxf5bT6j/OLwf3W1daxux+a8Mk8H/DM77s+fS/Az5enE=
Content-Type: multipart/alternative;
boundary="_000_VI1PR1001MB1309AFFE2838D85CBCB77C66DE580VI1PR1001MB1309_"
MIME-Version: 1.0
X-OriginatorOrg: outlook.com
X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 54485d23-c432-40fe-8436-6091d627118c
X-MS-Exchange-CrossTenant-Network-Message-Id: dadc8f9c-2f77-473e-1229-08d5e8a61c00
X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 54485d23-c432-40fe-8436-6091d627118c
X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Jul 2018 09:50:47.3837 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Internet
X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB5EUR03HT140
X-Spam-Status: No, score=-1.6 required=5.0 tests=BAYES_00,
FREEMAIL_ENVFROM_END_DIGIT, FREEMAIL_FROM, HTML_MESSAGE,
RCVD_IN_DNSWL_NONE autolearn=no version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
X-Mailman-Approved-At: Fri, 13 Jul 2018 10:17:01 +0000
Subject: Re: [bitcoin-dev] [Lightning-dev] BIP sighash_noinput
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: Fri, 13 Jul 2018 09:50:50 -0000
--_000_VI1PR1001MB1309AFFE2838D85CBCB77C66DE580VI1PR1001MB1309_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
the issues with sighash_noinput is this
1. you cannot prevent address-reuse. because bitcoin is a PUSH payment. =
meaning other people can send funds to one address without the owner of the=
key approval/refusal. thus luke cannot control address reuse if many peopl=
e start spamming him donations.
2. for average users who would just 'autopilot' LN and only see the GUI.=
they will have no clue what transaction types and technicals are happening=
under the hood. also with LN being not validated by the community. a user =
creating a channel could tweak their own LN node to make their counterparty=
sign a sighash-noinput as a term/condition of the channel
this is also a risk for the under the hood raw tx risks where a tx can be s=
igned but then allow the out's to alter value(using a different opcode). ..=
you know the premiss of allowing a counterpart to alter the outs value to =
vary so that they can control the broadcast fee at the time of broadcast to=
cover being acceptd onchain.. which can be abused by a counter party just =
editing it so A gets nothing and B gets it all..
3. by allowing certain things to change after signing. is infact bringin=
g back malleability for those that use a TXID to identify a tx has been con=
firmed. as a TXID would change if values change.. just like how malleation =
abused old transactions by editing a tx without needing to re-sign a tx
________________________________
From: bitcoin-dev-bounces@lists.linuxfoundation.org <bitcoin-dev-bounces@li=
sts.linuxfoundation.org> on behalf of Rusty Russell via bitcoin-dev <bitcoi=
n-dev@lists.linuxfoundation.org>
Sent: 13 July 2018 00:04:14
To: DING FENG; Luke Dashjr
Cc: Bitcoin Protocol Discussion; lightning-dev@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] [Lightning-dev] BIP sighash_noinput
DING FENG <dingfeng12345@gmail.com> writes:
> Hi,
>
> I'm a junior developer and a bitcoin user.
> And I have read this thread carefully.
>
> I'm very worried about "SIGHASH_NOINPUT".
>
> Because "SIGHASH_NOINPUT" looks will be widely used, and it makes reuse
> address more dangerous.
No.
A wallet should *never* create a SIGHASH_NOINPUT to spend its own UTXOs.
SIGHASH_NOINPUT is useful for smart contracts which have unique
conditions, such as a pair of peers rotating keys according to an agreed
schedule (eg. lightning).
Cheers,
Rusty.
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
--_000_VI1PR1001MB1309AFFE2838D85CBCB77C66DE580VI1PR1001MB1309_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
<html>
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"=
>
<style type=3D"text/css" style=3D"display:none;"><!-- P {margin-top:0;margi=
n-bottom:0;} --></style>
</head>
<body dir=3D"ltr">
<div id=3D"divtagdefaultwrapper" style=3D"font-size:12pt;color:#000000;font=
-family:Calibri,Helvetica,sans-serif;" dir=3D"ltr">
<p style=3D"margin-top:0;margin-bottom:0">the issues with sighash_noinput i=
s this<br>
</p>
<ol style=3D"margin-bottom: 0px; margin-top: 0px;">
<li>you cannot prevent address-reuse. because bitcoin is a PUSH payment. me=
aning other people can send funds to one address without the owner of the k=
ey approval/refusal. thus luke cannot control address reuse if many people =
start spamming him donations.</li><li>for average users who would just 'aut=
opilot' LN and only see the GUI. they will have no clue what transaction ty=
pes and technicals are happening under the hood. also with LN being not val=
idated by the community. a user creating a channel could tweak their
own LN node to make their counterparty sign a sighash-noinput as a term/co=
ndition of the channel<br>
this is also a risk for the under the hood raw tx risks where a tx can be s=
igned but then allow the out's to alter value(using a different opcode). ..=
you know the premiss of allowing a counterpart to alter the outs value to =
vary so that they can control the
broadcast fee at the time of broadcast to cover being acceptd onchain.. wh=
ich can be abused by a counter party just editing it so A gets nothing and =
B gets it all..</li><li>by allowing certain things to change after signing.=
is infact bringing back malleability for those that use a TXID to identify=
a tx has been confirmed. as a TXID would change if values change.. just li=
ke how malleation abused old transactions by editing
a tx without needing to re-sign a tx<br>
</li></ol>
<p style=3D"margin-top:0;margin-bottom:0"></p>
</div>
<hr style=3D"display:inline-block;width:98%" tabindex=3D"-1">
<div id=3D"divRplyFwdMsg" dir=3D"ltr"><font face=3D"Calibri, sans-serif" st=
yle=3D"font-size:11pt" color=3D"#000000"><b>From:</b> bitcoin-dev-bounces@l=
ists.linuxfoundation.org <bitcoin-dev-bounces@lists.linuxfoundation.org&=
gt; on behalf of Rusty Russell via bitcoin-dev <bitcoin-dev@lists.linuxf=
oundation.org><br>
<b>Sent:</b> 13 July 2018 00:04:14<br>
<b>To:</b> DING FENG; Luke Dashjr<br>
<b>Cc:</b> Bitcoin Protocol Discussion; lightning-dev@lists.linuxfoundation=
.org<br>
<b>Subject:</b> Re: [bitcoin-dev] [Lightning-dev] BIP sighash_noinput</font=
>
<div> </div>
</div>
<div class=3D"BodyFragment"><font size=3D"2"><span style=3D"font-size:11pt;=
">
<div class=3D"PlainText">DING FENG <dingfeng12345@gmail.com> writes:<=
br>
> Hi,<br>
><br>
> I'm a junior developer and a bitcoin user.<br>
> And I have read this thread carefully.<br>
><br>
> I'm very worried about "SIGHASH_NOINPUT".<br>
><br>
> Because "SIGHASH_NOINPUT" looks will be widely used, and it =
makes reuse<br>
> address more dangerous.<br>
<br>
No.<br>
<br>
A wallet should *never* create a SIGHASH_NOINPUT to spend its own UTXOs.<br=
>
SIGHASH_NOINPUT is useful for smart contracts which have unique<br>
conditions, such as a pair of peers rotating keys according to an agreed<br=
>
schedule (eg. lightning).<br>
<br>
Cheers,<br>
Rusty.<br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
bitcoin-dev@lists.linuxfoundation.org<br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev">=
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev</a><br>
</div>
</span></font></div>
</body>
</html>
--_000_VI1PR1001MB1309AFFE2838D85CBCB77C66DE580VI1PR1001MB1309_--
|
