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
|
Return-Path: <danny.thorpe@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 4AA2D90
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 21 Oct 2015 18:22:27 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-qg0-f52.google.com (mail-qg0-f52.google.com
[209.85.192.52])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 9204EA9
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 21 Oct 2015 18:22:26 +0000 (UTC)
Received: by qgad10 with SMTP id d10so35007744qga.3
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 21 Oct 2015 11:22:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=mime-version:in-reply-to:references:date:message-id:subject:from:to
:cc:content-type;
bh=m/36zq8DhdM5XIkcR6nzazlBqwz2MIO1KTSjzv71zWk=;
b=GGKtxF4RM0AwR1UUmqwt0lwdBGBMi1JX5P5cxEAsl1l1ILZOlfbbvbYguHOjjPcbbm
u1rSn1bi2y8KmCL9/D+mPJMCuEHvT7J8s97X4TshRLgyuVfEPf6tTgQ3sFwuBZM5+UFa
Q8ixpDy6qGNC22bj1QHdn3+kNMJHs+3h3y/UmN7rEItjyZAT1Bf3UxVy0nApZZTrO98T
125BTM2I7rY9Wo95M7goxpS0GygL4YAxiIf2Q/8hDTSDnREWgV/HqZBSmRtgqd2EG9a2
IVwUNjD1i7mfgUTYBR3SVAiALpR9uYBfHz4KYuy+jcupizpcm7MDpVtZejx8mr8xvLgT
vzPw==
MIME-Version: 1.0
X-Received: by 10.140.98.54 with SMTP id n51mr12908592qge.75.1445451745744;
Wed, 21 Oct 2015 11:22:25 -0700 (PDT)
Received: by 10.55.22.69 with HTTP; Wed, 21 Oct 2015 11:22:25 -0700 (PDT)
In-Reply-To: <201510210846.43988.luke@dashjr.org>
References: <CALxbBHU+kdEAh_4+B663vknAAr8OKZpUzVTACORPZi47E=Ehkw@mail.gmail.com>
<201510210839.42420.luke@dashjr.org>
<CALxbBHWOp9Q67bqSd4h=2+28PT_2stWzMBQ=nSvxPqKocx_xtQ@mail.gmail.com>
<201510210846.43988.luke@dashjr.org>
Date: Wed, 21 Oct 2015 11:22:25 -0700
Message-ID: <CAJN5wHXSbZPuXN7PQRyOgOMuk2Ogooiww3hW93uNipQJnfkeOg@mail.gmail.com>
From: Danny Thorpe <danny.thorpe@gmail.com>
To: Luke Dashjr <luke@dashjr.org>
Content-Type: multipart/alternative; boundary=001a113ac2aed85f300522a17595
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 <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 18:22:27 -0000
--001a113ac2aed85f300522a17595
Content-Type: text/plain; charset=UTF-8
A signer modifying the order of inputs or changing outputs when
"re-signing" a transaction (which already has dependent child transactions
spending its outputs) seems like quite a different hazard than a malicious
third party modifying a transaction in the mempool by twiddling opcodes in
the signature scripts. The former seems like more a matter of keeping your
own house in order (an internal affair) while the latter is an external
threat beyond the transaction writer's control.
While I agree that having a canonical ordering for inputs and outputs might
be useful in some cases, there are also use cases where the relative
positions of inputs and outputs are significant, where reordering would
change the semantics of the transaction. SIGHASH_SINGLE, for example,
makes an association between an input index and an output index. Open Asset
colored coins are identified by the order of inputs and outputs.
Let's keep canonical ordering separate from the normalized transaction ID
proposal. Baby steps. Normalized transaction IDs provide an immediate
benefit against the hazard of third party manipulation of transactions in
the mempool, even without canonical ordering.
-Danny
On Wed, Oct 21, 2015 at 1:46 AM, Luke Dashjr via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> On Wednesday, October 21, 2015 8:44:53 AM Christian Decker wrote:
> > 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.
>
> Or he can just have the other signers re-sign with the modified version.
> Even if it only worked with a single signer, it's still a form of
> malleability
> that your BIP does not presently solve, but would be desirable to solve...
>
> Luke
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
--001a113ac2aed85f300522a17595
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">A signer modifying the order of inputs or changing outputs=
when "re-signing" a transaction (which already has dependent chi=
ld transactions spending its outputs) seems like quite a different hazard t=
han a malicious third party modifying a transaction in the mempool by twidd=
ling opcodes in the signature scripts.=C2=A0 The former seems like more a m=
atter of keeping your own house in order (an internal affair) while the lat=
ter is an external threat beyond the transaction writer's control.<div>=
<br></div><div>While I agree that having a canonical ordering for inputs an=
d outputs might be useful in some cases, there are also use cases where the=
relative positions of inputs and outputs are significant, where reordering=
would change the semantics of the transaction.=C2=A0 SIGHASH_SINGLE, for e=
xample, makes an association between an input index and an output index. Op=
en Asset colored coins are identified by the order of inputs and outputs.</=
div><div><br></div><div>Let's keep canonical ordering separate from the=
normalized transaction ID proposal. Baby steps. Normalized transaction IDs=
provide an immediate benefit against the hazard of third party manipulatio=
n of transactions in the mempool, even without canonical ordering. =C2=A0</=
div><div><br></div><div>-Danny</div><div><br></div><div><br><div><br></div>=
<div><br></div></div></div><div class=3D"gmail_extra"><br><div class=3D"gma=
il_quote">On Wed, Oct 21, 2015 at 1:46 AM, Luke Dashjr via bitcoin-dev <spa=
n dir=3D"ltr"><<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" =
target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>></span> wrot=
e:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-l=
eft:1px #ccc solid;padding-left:1ex"><span class=3D"">On Wednesday, October=
21, 2015 8:44:53 AM Christian Decker wrote:<br>
> Hm, that is true as long as the signer is the only signer of the<br>
> transaction, otherwise he'd be invalidating the signatures of the =
other<br>
> signers.<br>
<br>
</span>Or he can just have the other signers re-sign with the modified vers=
ion.<br>
Even if it only worked with a single signer, it's still a form of malle=
ability<br>
that your BIP does not presently solve, but would be desirable to solve...<=
br>
<div class=3D"HOEnZb"><div class=3D"h5"><br>
Luke<br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.=
linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</div></div></blockquote></div><br></div>
--001a113ac2aed85f300522a17595--
|
