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
|
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 5824790
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 3 Nov 2015 20:37:57 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wm0-f53.google.com (mail-wm0-f53.google.com [74.125.82.53])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 52913FE
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 3 Nov 2015 20:37:56 +0000 (UTC)
Received: by wmeg8 with SMTP id g8so94576465wme.0
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 03 Nov 2015 12:37:55 -0800 (PST)
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=g0OljsqJ6SA/jcnKky5lRj/+Vhx+CFb3KIr2+WIXmwk=;
b=ehYgons0HzXBL9WlbUTsGRR68mpwzSCpWgSC/FgfVuzujdIGTMJbdcatS6RgJpsp1r
fqCD1F834fa2Jx9kBvICg5ogR85UQT4rJx6NfJ5/tT/x11LWnax4yvjGUEjd9+nricrM
Tx7X28S3RzNmXYILol84eGdnHr1862+5pUJ7mD0aS4Ppp+IHA4nRZHWK03yUEOI8HGeG
z2GysxwUvuzvliYo5x1BRVGaCI5K4wRQFvbcYtsK3dJOT1HNoc9H+Vnx9fG0uG2Ugddl
su4YLj2kwr/X95pPIa2qu+VXRmDAM7PKuDt2AZMFs4U0QiZ4X6BLyFBuetey56nLmo1H
98CA==
X-Received: by 10.28.23.211 with SMTP id 202mr20795332wmx.81.1446583074749;
Tue, 03 Nov 2015 12:37:54 -0800 (PST)
MIME-Version: 1.0
References: <CALxbBHU+kdEAh_4+B663vknAAr8OKZpUzVTACORPZi47E=Ehkw@mail.gmail.com>
<201510212320.31052.luke@dashjr.org>
<CALxbBHUK_na0qKEBrkCzV2oAUc90wpL4z=7h6Zuu4XzaKEazrA@mail.gmail.com>
<201510220905.27124.luke@dashjr.org>
In-Reply-To: <201510220905.27124.luke@dashjr.org>
From: Christian Decker <decker.christian@gmail.com>
Date: Tue, 03 Nov 2015 20:37:44 +0000
Message-ID: <CALxbBHV4JU7TG8QutkX7m9V4n_ANgKAgWO8ZA2KxQk8jP=kF0g@mail.gmail.com>
To: Luke Dashjr <luke@dashjr.org>
Content-Type: multipart/alternative; boundary=001a1147181a4f05570523a8de9c
X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE 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 <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: Tue, 03 Nov 2015 20:37:57 -0000
--001a1147181a4f05570523a8de9c
Content-Type: text/plain; charset=UTF-8
Ok, getting the ball rolling again after some downtime. I amended the
proposal to use a simple version number instead of the binary flags, added
the normalization of inputs before computing the signaturehash and added
Schnorr signatures as requested.
The BIP has also been assigned number 130 :-)
I am still very much intrigued by Luke's idea of having empty scriptsigs
and ship the signatures in external scripts, however the proposal uses the
on-the-fly normalization because we have no good way of relaying the
external scripts. Since we are still in the drafting phase I am open to
suggestions and if there is a good/working solution I can amend/withdraw
the proposal.
As for open venues for malleability, I'm not sure we can fix them at all,
after all the ability of a single signer to doublespend by
appending/replacing inputs/outputs in an arbitrary fashion is not fixable
IMHO and will cause any future transaction building on its outputs to be
orphaned. What would the perfect properties for such a fix be?
Regards,
Christian
On Thu, Oct 22, 2015 at 11:05 AM Luke Dashjr <luke@dashjr.org> wrote:
> On Thursday, October 22, 2015 8:26:58 AM Christian Decker wrote:
> > I think the scenario of the single signer re-ordering the outputs and
> > inputs and then re-signing the transaction is in the same category of
> > simple double-spends. The signer could just as well sign a completely
> > different transaction spending the same coins to somewhere else, so I
> don't
> > think there is a lot we can do about it even if we instate a canonical
> > ordering. Even if we order the inputs and outputs the signer can just
> add a
> > new input and output and we would have a different transaction.
> >
> > Normalized transaction IDs do help in the case that the single signer
> wants
> > to immediately follow up its transaction with another transaction
> spending
> > the first one's change output, and it prevents any modification in the
> > multi-signer scenario.
>
> Except that unlike malicious double spending, adding more outputs to
> unconfirmed transactions is what wallets *should ideally be doing every
> time
> they send another transaction*. Spending unconfirmed change is the wrong
> approach. So half-fixing malleability as this PR would, encourages
> inefficient behaviour in multiple ways (first, by not making it
> malleability-
> safe; second, by encouraging spending unconfirmed change).
>
> Luke
>
--001a1147181a4f05570523a8de9c
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Ok, getting the ball rolling again after some downtime. I =
amended the proposal to use a simple version number instead of the binary f=
lags, added the normalization of inputs before computing the signaturehash =
and added Schnorr signatures as requested.<div><br></div><div>The BIP has a=
lso been assigned number 130 :-)</div><div><br></div><div>I am still very m=
uch intrigued by Luke's idea of having empty scriptsigs and ship the si=
gnatures in external scripts, however the proposal uses the on-the-fly norm=
alization because we have no good way of relaying the external scripts. Sin=
ce we are still in the drafting phase I am open to suggestions and if there=
is a good/working solution I can amend/withdraw the proposal.</div><div><b=
r></div><div>As for open venues for malleability, I'm not sure we can f=
ix them at all, after all the ability of a single signer to doublespend by =
appending/replacing inputs/outputs in an arbitrary fashion is not fixable I=
MHO and will cause any future transaction building on its outputs to be orp=
haned. What would the perfect properties for such a fix be?</div><div><br><=
/div><div>Regards,</div><div>Christian<br><br><div class=3D"gmail_quote"><d=
iv dir=3D"ltr">On Thu, Oct 22, 2015 at 11:05 AM Luke Dashjr <<a href=3D"=
mailto:luke@dashjr.org">luke@dashjr.org</a>> wrote:<br></div><blockquote=
class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc soli=
d;padding-left:1ex">On Thursday, October 22, 2015 8:26:58 AM Christian Deck=
er wrote:<br>
> I think the scenario of the single signer re-ordering the outputs and<=
br>
> inputs and then re-signing the transaction is in the same category of<=
br>
> simple double-spends. The signer could just as well sign a completely<=
br>
> different transaction spending the same coins to somewhere else, so I =
don't<br>
> think there is a lot we can do about it even if we instate a canonical=
<br>
> ordering. Even if we order the inputs and outputs the signer can just =
add a<br>
> new input and output and we would have a different transaction.<br>
><br>
> Normalized transaction IDs do help in the case that the single signer =
wants<br>
> to immediately follow up its transaction with another transaction spen=
ding<br>
> the first one's change output, and it prevents any modification in=
the<br>
> multi-signer scenario.<br>
<br>
Except that unlike malicious double spending, adding more outputs to<br>
unconfirmed transactions is what wallets *should ideally be doing every tim=
e<br>
they send another transaction*. Spending unconfirmed change is the wrong<br=
>
approach. So half-fixing malleability as this PR would, encourages<br>
inefficient behaviour in multiple ways (first, by not making it malleabilit=
y-<br>
safe; second, by encouraging spending unconfirmed change).<br>
<br>
Luke<br>
</blockquote></div></div></div>
--001a1147181a4f05570523a8de9c--
|
