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
|
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <decker.christian@gmail.com>) id 1Ysqty-0001X6-Os
for bitcoin-development@lists.sourceforge.net;
Thu, 14 May 2015 11:02:06 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.215.48 as permitted sender)
client-ip=209.85.215.48;
envelope-from=decker.christian@gmail.com;
helo=mail-la0-f48.google.com;
Received: from mail-la0-f48.google.com ([209.85.215.48])
by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1Ysqtw-0000zf-2I
for bitcoin-development@lists.sourceforge.net;
Thu, 14 May 2015 11:02:06 +0000
Received: by labbd9 with SMTP id bd9so62062932lab.2
for <bitcoin-development@lists.sourceforge.net>;
Thu, 14 May 2015 04:01:57 -0700 (PDT)
X-Received: by 10.112.131.104 with SMTP id ol8mr2818207lbb.58.1431601317726;
Thu, 14 May 2015 04:01:57 -0700 (PDT)
MIME-Version: 1.0
References: <CALxbBHUnt7ToVK9reH6W6uT4HV=7NbxGHyNWWa-OEHg+Z1+qOg@mail.gmail.com>
<CAPg+sBggj382me1ATDx4SS9KHVfvX5KH7ZhLHN6B+2_a+Emw1Q@mail.gmail.com>
<CAE-z3OV1WEDEV+X7gNVx+qBMt4jpSHFKXm3dxUrUyBEJrCNDSQ@mail.gmail.com>
<CAE-z3OU-fdTrKRkni4xmmY5uBVWS0KJ_2NVh6k1tcMSGTPp+4Q@mail.gmail.com>
<CAPg+sBixpKQfsazHyhiF60HYTk9_U0aBAqU=4P+R+HDMA2jWKg@mail.gmail.com>
<CAE-z3OU7nCJSGk-Mx_2gmpUjQ1gXeSNDiWfhPe-5rj5bG5ArWQ@mail.gmail.com>
<CAPg+sBjiaqsLEMz8Qskz1iWOf3VBgAnX2749uHzeyFf_seLEHQ@mail.gmail.com>
In-Reply-To: <CAPg+sBjiaqsLEMz8Qskz1iWOf3VBgAnX2749uHzeyFf_seLEHQ@mail.gmail.com>
From: Christian Decker <decker.christian@gmail.com>
Date: Thu, 14 May 2015 11:01:56 +0000
Message-ID: <CALxbBHV_2NHAvS5GXCsqBR0gO9zZe55kz52geMhG+8=EkKN2KA@mail.gmail.com>
To: Pieter Wuille <pieter.wuille@gmail.com>, Tier Nolan <tier.nolan@gmail.com>
Content-Type: multipart/alternative; boundary=047d7b3a86d600d2d2051608a857
X-Spam-Score: -0.6 (/)
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
(decker.christian[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
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
X-Headers-End: 1Ysqtw-0000zf-2I
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
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: Thu, 14 May 2015 11:02:06 -0000
--047d7b3a86d600d2d2051608a857
Content-Type: text/plain; charset=UTF-8
Ok, I think I got the OP_CHECKAWESOMESIG proposal, transactions keep
referencing using hashes of complete transactions (including signatures),
while the OP_CHECKAWESOMESIG looks up the previous transaction (which we
already need to do anyway in order to insert the prevOut pubkeyScript),
normalizes the prevout and calculates its normalized transaction ID. It
then inserts the normalized transaction IDs in the OutPoint before
calculating its own hash which is then signed. Is that correct so far?
Let me try to summarize the discussion so far:
I think we have consensus that transaction malleability needs to be
addressed, and normalized transaction IDs seem to be the way to go forward.
The discussion now is how to use normalized transaction IDs and we have two
approaches to implement them:
- OP_CHECKAWESOMESIG which continues to use the current hashes to
reference a specific signed instance of a class of semantically identical
transactions. Internally only the semantic class is enforced. Transactions
can be fixed to reference the correct signed instance if the transaction
has been changed along the way.is a softfork using the "if I don't know
this opcode the TX is automatically valid" trick
On Thu, May 14, 2015 at 2:40 AM Pieter Wuille <pieter.wuille@gmail.com>
wrote:
> On Wed, May 13, 2015 at 1:32 PM, Tier Nolan <tier.nolan@gmail.com> wrote:
>
>>
>> On Wed, May 13, 2015 at 9:31 PM, Pieter Wuille <pieter.wuille@gmail.com>
>> wrote:
>>
>>>
>>> This was what I was suggesting all along, sorry if I wasn't clear.
>>>
>>> That's great. So, basically the multi-level refund problem is solved by
>> this?
>>
>
> Yes. So to be clear, I think there are 2 desirable end-goal proposals
> (ignoring difficulty of changing things for a minute):
>
> * Transactions and blocks keep referring to other transactions by full
> txid, but signature hashes are computed off normalized txids (which are
> recursively defined to use normalized txids all the way back to coinbases).
> Is this what you are suggesting now as well?
>
> * Blocks commit to full transaction data, but transactions and signature
> hashes use normalized txids.
>
> The benefit of the latter solution is that it doesn't need "fixing up"
> transactions whose inputs have been malleated, but comes at the cost of
> doing a very invasive hard fork.
>
> --
> Pieter
>
>
> ------------------------------------------------------------------------------
> One dashboard for servers and applications across Physical-Virtual-Cloud
> Widest out-of-the-box monitoring support with 50+ applications
> Performance metrics, stats and reports that give you Actionable Insights
> Deep dive visibility with transaction tracing using APM Insight.
> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
--047d7b3a86d600d2d2051608a857
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Ok, I think I got the OP_CHECKAWESOMESIG proposal, transac=
tions keep referencing using hashes of complete transactions (including sig=
natures), while the OP_CHECKAWESOMESIG looks up the previous transaction (w=
hich we already need to do anyway in order to insert the prevOut pubkeyScri=
pt), normalizes the prevout and calculates its normalized transaction ID. I=
t then inserts the normalized transaction IDs in the OutPoint before calcul=
ating its own hash which is then signed. Is that correct so far?<div><br></=
div><div>Let me try to summarize the discussion so far:</div><div><br></div=
><div>I think we have consensus that transaction malleability needs to be a=
ddressed, and normalized transaction IDs seem to be the way to go forward.<=
/div><div><br></div><div>The discussion now is how to use normalized transa=
ction IDs and we have two approaches to implement them:</div><div><ul><li>O=
P_CHECKAWESOMESIG which continues to use the current hashes to reference a =
specific signed instance of a class of semantically identical transactions.=
Internally only the semantic class is enforced. Transactions can be fixed =
to reference the correct signed instance if the transaction has been change=
d along the <a href=3D"http://way.is">way.is</a> a softfork using the "=
;if I don't know this opcode the TX is automatically valid" trick<=
/li></ul></div><div><br><div class=3D"gmail_quote">On Thu, May 14, 2015 at =
2:40 AM Pieter Wuille <<a href=3D"mailto:pieter.wuille@gmail.com">pieter=
.wuille@gmail.com</a>> wrote:<br><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=
=3D"ltr">On Wed, May 13, 2015 at 1:32 PM, Tier Nolan <span dir=3D"ltr"><=
<a href=3D"mailto:tier.nolan@gmail.com" target=3D"_blank">tier.nolan@gmail.=
com</a>></span> wrote:<br></div><div dir=3D"ltr"><div class=3D"gmail_ext=
ra"><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"m=
argin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"l=
tr"><div class=3D"gmail_extra"><br><div class=3D"gmail_quote"><span>On Wed,=
May 13, 2015 at 9:31 PM, Pieter Wuille <span dir=3D"ltr"><<a href=3D"ma=
ilto:pieter.wuille@gmail.com" target=3D"_blank">pieter.wuille@gmail.com</a>=
></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0=
0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><span=
></span><div class=3D"gmail_extra"><span></span><br><div class=3D"gmail_quo=
te"><div>This was what I was suggesting all along, sorry if I wasn't cl=
ear.<span><font color=3D"#888888"><br></font></span><br></div></div></div><=
/div></blockquote></span><div>That's great.=C2=A0 So, basically the mul=
ti-level refund problem is solved by this?<br></div></div></div></div></blo=
ckquote><div><br></div></div></div></div><div dir=3D"ltr"><div class=3D"gma=
il_extra"><div class=3D"gmail_quote"><div>Yes. So to be clear, I think ther=
e are 2 desirable end-goal proposals (ignoring difficulty of changing thing=
s for a minute):<br><br></div><div>* Transactions and blocks keep referring=
to other transactions by full txid, but signature hashes are computed off =
normalized txids (which are recursively defined to use normalized txids all=
the way back to coinbases). Is this what you are suggesting now as well?<b=
r><br></div><div>* Blocks commit to full transaction data, but transactions=
and signature hashes use normalized txids.<br><br></div><div>The benefit o=
f the latter solution is that it doesn't need "fixing up" tra=
nsactions whose inputs have been malleated, but comes at the cost of doing =
a very invasive hard fork.<br><br>-- <br></div></div></div></div><div dir=
=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><div>Pieter<=
br><br></div></div></div></div>
---------------------------------------------------------------------------=
---<br>
One dashboard for servers and applications across Physical-Virtual-Cloud<br=
>
Widest out-of-the-box monitoring support with 50+ applications<br>
Performance metrics, stats and reports that give you Actionable Insights<br=
>
Deep dive visibility with transaction tracing using APM Insight.<br>
<a href=3D"http://ad.doubleclick.net/ddm/clk/290420510;117567292;y" target=
=3D"_blank" style=3D"display:none!important">http://ad.doubleclick.net/ddm/=
clk/290420510;117567292;y</a>______________________________________________=
_<br>
Bitcoin-development mailing list<br>
<a href=3D"mailto:Bitcoin-development@lists.sourceforge.net" target=3D"_bla=
nk">Bitcoin-development@lists.sourceforge.net</a><br>
<a href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-development=
" target=3D"_blank">https://lists.sourceforge.net/lists/listinfo/bitcoin-de=
velopment</a><br>
</blockquote></div></div></div>
--047d7b3a86d600d2d2051608a857--
|
