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
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <tier.nolan@gmail.com>) id 1YtD7E-0005o6-Cr
for bitcoin-development@lists.sourceforge.net;
Fri, 15 May 2015 10:45:16 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.192.53 as permitted sender)
client-ip=209.85.192.53; envelope-from=tier.nolan@gmail.com;
helo=mail-qg0-f53.google.com;
Received: from mail-qg0-f53.google.com ([209.85.192.53])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1YtD79-0003dx-2m
for bitcoin-development@lists.sourceforge.net;
Fri, 15 May 2015 10:45:16 +0000
Received: by qgf2 with SMTP id 2so9186596qgf.0
for <bitcoin-development@lists.sourceforge.net>;
Fri, 15 May 2015 03:45:05 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.55.56.201 with SMTP id f192mr18518263qka.88.1431686705626;
Fri, 15 May 2015 03:45:05 -0700 (PDT)
Received: by 10.140.85.241 with HTTP; Fri, 15 May 2015 03:45:05 -0700 (PDT)
In-Reply-To: <5555C26F.7080706@sky-ip.org>
References: <CALxbBHUnt7ToVK9reH6W6uT4HV=7NbxGHyNWWa-OEHg+Z1+qOg@mail.gmail.com>
<5555C26F.7080706@sky-ip.org>
Date: Fri, 15 May 2015 11:45:05 +0100
Message-ID: <CAE-z3OXwRArVnB13t+-S6EdxJkDx3EKbTN4dh2b-uJ05+6rqXw@mail.gmail.com>
From: Tier Nolan <tier.nolan@gmail.com>
Cc: Bitcoin Development <bitcoin-development@lists.sourceforge.net>
Content-Type: multipart/alternative; boundary=001a1145923884c4c405161c8988
X-Spam-Score: 2.3 (++)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
sender-domain
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
(tier.nolan[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
1.2 MISSING_HEADERS Missing To: header
1.0 HTML_MESSAGE BODY: HTML included in message
-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
author's domain
0.1 DKIM_SIGNED Message has a DKIM or DK signature,
not necessarily valid
-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
1.9 MALFORMED_FREEMAIL Bad headers on message from free email service
-0.1 AWL AWL: Adjusted score from AWL reputation of From: address
X-Headers-End: 1YtD79-0003dx-2m
Subject: Re: [Bitcoin-development] [BIP] Normalized Transaction IDs
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Fri, 15 May 2015 10:45:16 -0000
--001a1145923884c4c405161c8988
Content-Type: text/plain; charset=UTF-8
On Fri, May 15, 2015 at 10:54 AM, s7r <s7r@sky-ip.org> wrote:
> Hello,
>
> How will this exactly be safe against:
> a) the malleability of the parent tx (2nd level malleability)
>
The signature signs everything except the signature itself. The normalized
txid doesn't include that signature, so mutations of the signature don't
cause the normalized txid to change.
If the refund transaction refers to the parent using the normalised txid,
then it doesn't matter if the parent has a mutated signature. The
normalized transaction ignores the mutation.
If the parent is mutated, then the refund doesn't even have to be modified,
it still refers to it.
If you want a multi-level refund transaction, then all refund transactions
must use the normalized txids to refer to their parents. The "root"
transaction is submitted to the blockchain and locked down.
> b) replays
>
If there are 2 transactions which are mutations of each other, then only
one can be added to the block chain, since the other is a double spend.
The normalized txid refers to all of them, rather than a specific
transaction.
> If you strip just the scriptSig of the input(s), the txid(s) can still
> be mutated (with higher probability before it gets confirmed).
>
Mutation is only a problem if it occurs after signing. The signature signs
everything except the signature itself.
> If you strip both the scriptSig of the parent and the txid, nothing can
> any longer be mutated but this is not safe against replays.
Correct, but normalized txids are safe against replays, so are better.
I think the new signature opcode fixes things too. The question is hard
fork but clean solution vs a soft fork but a little more hassle.
--001a1145923884c4c405161c8988
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On Fri, May 15, 2015 at 10:54 AM, s7r <span dir=3D"ltr"><<a href=3D"=
mailto:s7r@sky-ip.org" target=3D"_blank">s7r@sky-ip.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">Hello,<br>
<br>
How will this exactly be safe against:<br>
a) the malleability of the parent tx (2nd level malleability)<br></blockquo=
te><div><br></div><div>The signature signs everything except the signature =
itself.=C2=A0 The normalized txid doesn't include that signature, so mu=
tations of the signature don't cause the normalized txid to change.<br>=
<br></div><div>If the refund transaction refers to the parent using the nor=
malised txid, then it doesn't matter if the parent has a mutated signat=
ure.=C2=A0 The normalized transaction ignores the mutation.<br><br></div><d=
iv>If the parent is mutated, then the refund doesn't even have to be mo=
dified, it still refers to it.<br><br></div><div>If you want a multi-level =
refund transaction, then all refund transactions must use the normalized tx=
ids to refer to their parents.=C2=A0 The "root" transaction is su=
bmitted to the blockchain and locked down.<br></div><div>=C2=A0</div><block=
quote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc=
solid;padding-left:1ex">
b) replays<br></blockquote><div><br></div><div>If there are 2 transactions =
which are mutations of each other, then only one can be added to the block =
chain, since the other is a double spend.<br><br></div><div>The normalized =
txid refers to all of them, rather than a specific transaction.<br></div><d=
iv>=C2=A0<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 =
.8ex;border-left:1px #ccc solid;padding-left:1ex">
If you strip just the scriptSig of the input(s), the txid(s) can still<br>
be mutated (with higher probability before it gets confirmed).<br></blockqu=
ote><div><br></div><div>Mutation is only a problem if it occurs after signi=
ng.=C2=A0 The signature signs everything except the signature itself.<br></=
div><div>=C2=A0<br></div><blockquote class=3D"gmail_quote" style=3D"margin:=
0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
If you strip both the scriptSig of the parent and the txid, nothing can<br>
any longer be mutated but this is not safe against replays.</blockquote><di=
v><br></div><div>Correct, but normalized txids are safe against replays, so=
are better.<br></div><br></div><div class=3D"gmail_quote">I think the new =
signature opcode fixes things too.=C2=A0 The question is hard fork but clea=
n solution vs a soft fork but a little more hassle.<br></div></div></div>
--001a1145923884c4c405161c8988--
|
