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
|
Return-Path: <decker.christian@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id C3EDB891
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 13 Jul 2018 11:08:01 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wr1-f52.google.com (mail-wr1-f52.google.com
[209.85.221.52])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 9DD966D6
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 13 Jul 2018 11:07:59 +0000 (UTC)
Received: by mail-wr1-f52.google.com with SMTP id c4-v6so12044258wrs.12
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 13 Jul 2018 04:07:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=from:to:subject:in-reply-to:references:date:message-id:mime-version;
bh=P+oTGaO67+OA5b2s1ZrPdSJJq6KRl0eoEaWY0mj4lZA=;
b=CPbpDsvFo1mAnL+fJaGjGEUJZINFgB52fS997kbITPyeKa1u2QV7rtwM8aaiKhh+SL
hlxVGZGRertbd2vKavj8kb/tdh14Mf9mLIB1kzxIao0YUFvk1xWbEeeaYE8Csm+pHXWf
76KbyZPnxC29X2OD/FaPBM/UUhXJbqRzBIFh7nYULYlcPv/dx7UXrptaC4Duw3L4wvNa
DlEVSPNsTcID6pKJHg7gKF/ztK7XsOeWklPMkLRRN9WLyuX4XI3zUuB4tSTd0OjscdDP
cWxc4AGjPB8vVPSBoYBG4wkQGWZ2Xb1gidvYIp93JJtZOODBIsvDAyHeoC8iC2Kx9n3k
MKTQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:from:to:subject:in-reply-to:references:date
:message-id:mime-version;
bh=P+oTGaO67+OA5b2s1ZrPdSJJq6KRl0eoEaWY0mj4lZA=;
b=lRLip0x+5uBu9dxK7ciUy6nyIR/0nLV/5IuMgROHkAAsv8oikvkwT1CN6vU72OLD5R
XWQO1M4nzMYhOLSQIKSzLQm2aPGxTR1Eca11nbHaV5NlkfeP+LU9eD2YQa9f/2N3lOat
iH7HaJIef8eCqCPj6g6FNOGc1WG+qqYmuzf6I56zzOQXpamvYNIGEdljGkH0/87O0ugZ
3/Qp3RRj5faTn6Cd/xT7CflGNaBf4VWEd5OxNxi4vqZjuW6vaU91Ufq+FIaNrv8L+ZGo
8h2pMVs8uZZBK4KxCLSbIm8zeEaVipPOZEZNDxrYYL6tCnPR3qfhje0Ii+Z9HKyFXiSg
AmtA==
X-Gm-Message-State: AOUpUlFAW6wKbRYaEFhA0+crqt1z+GgjykCJcuMyTZha8Kfv/0k4snkd
dgqwEi4DTs91DQsILv2LcNg=
X-Google-Smtp-Source: AAOMgpdVo7u/aybhgaPw3R4bM1M5hfPa8GDKoqSj8geXXkIBskPlz88J7542g0uZsatQrvcrmNfGcw==
X-Received: by 2002:adf:f585:: with SMTP id f5-v6mr978576wro.59.1531480078240;
Fri, 13 Jul 2018 04:07:58 -0700 (PDT)
Received: from localhost ([2a02:aa16:1102:5480:e99:3f63:40a2:83e9])
by smtp.gmail.com with ESMTPSA id
b18-v6sm2791004wrj.72.2018.07.13.04.07.56
(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
Fri, 13 Jul 2018 04:07:56 -0700 (PDT)
From: Christian Decker <decker.christian@gmail.com>
To: fred savage <fred_savage2003@hotmail.co.uk>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>,
Rusty Russell <rusty@rustcorp.com.au>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
In-Reply-To: <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>
<VI1PR1001MB1309AFFE2838D85CBCB77C66DE580@VI1PR1001MB1309.EURPRD10.PROD.OUTLOOK.COM>
Date: Fri, 13 Jul 2018 13:07:48 +0200
Message-ID: <87sh4n75rv.fsf@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM,
RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
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 11:08:01 -0000
fred savage via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> writes:
> 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 people start spamming him donations.
This point is pretty much moot since these are scripts, that are used in
very specialized contexts, and should not be shown to any
end-user. Sure, if you go through the blockchain looking for these
addresses, and send the exact same value to it, and create a matching
script then you could end up exposing those funds to this, however
that'd be very silly of you, and you'd have jumped through a lot of
hoops to lose money :-)
> 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 signed 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..
You cannot force the counterparty to sign with a sighash-flag that they
don't chose themselves. We are very clear in the BIP that you should
only use sighash_noinput_unsafe in the context of protocols, that need
to be designed in such a way that these issues are excluded. In
particular, eltoo uses a public key, provided by the signing party,
which they can ensure is not reused (ensuring script
uniqueness). Finally, wallets that are not part of LN or eltoo, won't
even know how to sign with sighash-noinput (try signing anything but
sighash-all on a hardware wallet for example).
The kind of editing you describe also doesn't work, since sighash-single
is used for the late fee binding, not sighash-noinput. sighash-single
makes sure that the input is only valid if the matching output is still
intact, so redirecting funds away from the desired output doesn't work.
> 3. 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 like how malleation abused old transactions by editing
> a tx without needing to re-sign a tx
Again, this is only to be used in the context of applications that
require it, which also means that they know how to deal with this
malleability (in fact this malleability is wanted here). If you squint
at it you can probably see that sighash-noinput is also a poor-man's
malleability fix, allowing you to take a transaction that is based on a
malleated output, and rebind it to re-establish the connection.
It seems people believe that we are advocating the use of
sighash-noinput-unsafe in general purpose wallets and in everyday
transactions, this couldn't be further from the truth: sighash-noinput
is a sharp tool, that should only be used in very specific situations,
to enable a bit more flexibility, and it can improve the safety of
off-chain protocols a lot, however general purpose wallets should not
even allow signing with it.
Cheers,
Christian
|
