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
|
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 A1E031BB
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 21 Oct 2015 08:45:05 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wi0-f177.google.com (mail-wi0-f177.google.com
[209.85.212.177])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id AAB54E4
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 21 Oct 2015 08:45:04 +0000 (UTC)
Received: by wikq8 with SMTP id q8so82473645wik.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 21 Oct 2015 01:45:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=mime-version:references:in-reply-to:from:date:message-id:subject:to
:cc:content-type;
bh=7Rz1MfQxdiK1hEnf4obOZhS6VVV3c2MSFKaM7T2yWxA=;
b=oJBjF1sU+utZWCUfPX8He+XeFVeJzBP/agYh/lfJX+HyOvCMZHGdDuC0Oqb6P4Ojz0
tNatoDirc3uDHtSoiktg7bclEGbzj1wKOhRjr9OH/I0eTTIW0hPdcvEMygPe8DVMveFR
k5haQD/eEFkouVsXK4paMRNourKG8aQb+J+0KPdbzKYk9+VSTaprmZmSo3M4AWVf3u+w
9TtBBM/y1e41SdvPQHChRByzkCr13VicAaDiMOq0lxkctA5e+n/LH/hjuo+c0U2mUxX9
p+d2wqwwb36k2XsH+R+6pFubOBwR2+jmpBk7ALS3cTP+UgDLohs+8/bIQm9TIgILs/Yt
8l0w==
X-Received: by 10.194.111.198 with SMTP id ik6mr10158556wjb.96.1445417103136;
Wed, 21 Oct 2015 01:45:03 -0700 (PDT)
MIME-Version: 1.0
References: <CALxbBHU+kdEAh_4+B663vknAAr8OKZpUzVTACORPZi47E=Ehkw@mail.gmail.com>
<201510210752.17527.luke@dashjr.org>
<CALxbBHVnb-bLx47RcST0ZP2pg2YPzC5TvCDjL1qXqEQLN2qSGA@mail.gmail.com>
<201510210839.42420.luke@dashjr.org>
In-Reply-To: <201510210839.42420.luke@dashjr.org>
From: Christian Decker <decker.christian@gmail.com>
Date: Wed, 21 Oct 2015 08:44:53 +0000
Message-ID: <CALxbBHWOp9Q67bqSd4h=2+28PT_2stWzMBQ=nSvxPqKocx_xtQ@mail.gmail.com>
To: Luke Dashjr <luke@dashjr.org>
Content-Type: multipart/alternative; boundary=001a1130cfa2fc3903052299648c
X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,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
Cc: bitcoin-dev@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] [BIP] Normalized transaction IDs
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Development 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, 21 Oct 2015 08:45:05 -0000
--001a1130cfa2fc3903052299648c
Content-Type: text/plain; charset=UTF-8
Hm, that is true as long as the signer is the only signer of the
transaction, otherwise he'd be invalidating the signatures of the other
signers. That can however be fixed by having a canonical ordering of Inputs
and Outputs, which has been discussed before in order to decrease
information that can be gained about the spender. Maybe we can defer to
that effort?
On Wed, Oct 21, 2015 at 10:41 AM Luke Dashjr <luke@dashjr.org> wrote:
> On Wednesday, October 21, 2015 8:31:42 AM Christian Decker wrote:
> > On Wed, Oct 21, 2015 at 9:52 AM Luke Dashjr <luke@dashjr.org> wrote:
> > > On Wednesday, October 21, 2015 7:39:45 AM Christian Decker wrote:
> > > > On Wed, Oct 21, 2015 at 8:19 AM Luke Dashjr <luke@dashjr.org> wrote:
> > > > > This doesn't completely close malleability (which should be
> > > > > documented
> > >
> > > in
> > >
> > > > > the BIP), so I'm not sure it's worth the cost, especially if
> closing
> > > > > malleability later on would need more. How about specifying flags
> > >
> > > upfront
> > >
> > > > > in the UTXO-creating transaction specifying which parts the
> signature
> > > > > will cover? This would allow implementation of fully
> > > > > malleability-proof wallets.
> > > >
> > > > As far as I see it the only remaining venues for malleability are the
> > > > use of sighash flags that are not SIGHASH_ALL, as mentioned in the
> > > > BIP. Any
> > >
> > > use
> > >
> > > > of non-sighash_all flags is already an explicit permission to modify
> > > > the transactions, by adding and removing inputs and outputs, so I
> > > > don't see
> > >
> > > how
> > >
> > > > these can be made non-malleable. Am I missing something?
> > >
> > > Signer malleability is still a notable concern needing consideration.
> > > Ideally,
> > > wallets should be trying to actively CoinJoin, bump fees on, etc any
> > > pending
> > > transactions in the background. These forms of malleability affect
> nearly
> > > as
> > > many real use cases as third-party malleability.
> > >
> > > Luke
> >
> > How is signer malleability still a problem if we remove the signatures
> from
> > the transaction ID of the transaction and all preceding transactions? The
> > signer can re-sign a transaction but it won't change the transaction ID.
>
> The signer can also change the order of the inputs, the inputs themselves,
> add/remove outputs, etc... all which should be possible without becoming a
> different logical transaction. The only unique property of the logical
> transaction is the scriptPubKey/address.
>
> Luke
>
--001a1130cfa2fc3903052299648c
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Hm, that is true as long as the signer is the only signer =
of the transaction, otherwise he'd be invalidating the signatures of th=
e other signers. That can however be fixed by having a canonical ordering o=
f Inputs and Outputs, which has been discussed before in order to decrease =
information that can be gained about the spender. Maybe we can defer to tha=
t effort?</div><br><div class=3D"gmail_quote"><div dir=3D"ltr">On Wed, Oct =
21, 2015 at 10:41 AM Luke Dashjr <<a href=3D"mailto:luke@dashjr.org">luk=
e@dashjr.org</a>> wrote:<br></div><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Wedn=
esday, October 21, 2015 8:31:42 AM Christian Decker wrote:<br>
> On Wed, Oct 21, 2015 at 9:52 AM Luke Dashjr <<a href=3D"mailto:luke=
@dashjr.org" target=3D"_blank">luke@dashjr.org</a>> wrote:<br>
> > On Wednesday, October 21, 2015 7:39:45 AM Christian Decker wrote:=
<br>
> > > On Wed, Oct 21, 2015 at 8:19 AM Luke Dashjr <<a href=3D"m=
ailto:luke@dashjr.org" target=3D"_blank">luke@dashjr.org</a>> wrote:<br>
> > > > This doesn't completely close malleability (which s=
hould be<br>
> > > > documented<br>
> ><br>
> > in<br>
> ><br>
> > > > the BIP), so I'm not sure it's worth the cost, =
especially if closing<br>
> > > > malleability later on would need more. How about specif=
ying flags<br>
> ><br>
> > upfront<br>
> ><br>
> > > > in the UTXO-creating transaction specifying which parts=
the signature<br>
> > > > will cover? This would allow implementation of fully<br=
>
> > > > malleability-proof wallets.<br>
> > ><br>
> > > As far as I see it the only remaining venues for malleabilit=
y are the<br>
> > > use of sighash flags that are not SIGHASH_ALL, as mentioned =
in the<br>
> > > BIP. Any<br>
> ><br>
> > use<br>
> ><br>
> > > of non-sighash_all flags is already an explicit permission t=
o modify<br>
> > > the transactions, by adding and removing inputs and outputs,=
so I<br>
> > > don't see<br>
> ><br>
> > how<br>
> ><br>
> > > these can be made non-malleable. Am I missing something?<br>
> ><br>
> > Signer malleability is still a notable concern needing considerat=
ion.<br>
> > Ideally,<br>
> > wallets should be trying to actively CoinJoin, bump fees on, etc =
any<br>
> > pending<br>
> > transactions in the background. These forms of malleability affec=
t nearly<br>
> > as<br>
> > many real use cases as third-party malleability.<br>
> ><br>
> > Luke<br>
><br>
> How is signer malleability still a problem if we remove the signatures=
from<br>
> the transaction ID of the transaction and all preceding transactions? =
The<br>
> signer can re-sign a transaction but it won't change the transacti=
on ID.<br>
<br>
The signer can also change the order of the inputs, the inputs themselves,<=
br>
add/remove outputs, etc... all which should be possible without becoming a<=
br>
different logical transaction. The only unique property of the logical<br>
transaction is the scriptPubKey/address.<br>
<br>
Luke<br>
</blockquote></div>
--001a1130cfa2fc3903052299648c--
|
