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
|
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
helo=mx.sourceforge.net)
by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <pieter.wuille@gmail.com>) id 1Ysh9d-0006sh-0H
for bitcoin-development@lists.sourceforge.net;
Thu, 14 May 2015 00:37:37 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.214.178 as permitted sender)
client-ip=209.85.214.178; envelope-from=pieter.wuille@gmail.com;
helo=mail-ob0-f178.google.com;
Received: from mail-ob0-f178.google.com ([209.85.214.178])
by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1Ysh9c-0004vb-3J
for bitcoin-development@lists.sourceforge.net;
Thu, 14 May 2015 00:37:36 +0000
Received: by obblk2 with SMTP id lk2so42609100obb.0
for <bitcoin-development@lists.sourceforge.net>;
Wed, 13 May 2015 17:37:30 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.60.23.70 with SMTP id k6mr1315942oef.20.1431563850718; Wed,
13 May 2015 17:37:30 -0700 (PDT)
Received: by 10.60.94.36 with HTTP; Wed, 13 May 2015 17:37:30 -0700 (PDT)
In-Reply-To: <CAE-z3OU7nCJSGk-Mx_2gmpUjQ1gXeSNDiWfhPe-5rj5bG5ArWQ@mail.gmail.com>
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>
Date: Wed, 13 May 2015 17:37:30 -0700
Message-ID: <CAPg+sBjiaqsLEMz8Qskz1iWOf3VBgAnX2749uHzeyFf_seLEHQ@mail.gmail.com>
From: Pieter Wuille <pieter.wuille@gmail.com>
To: Tier Nolan <tier.nolan@gmail.com>
Content-Type: multipart/alternative; boundary=047d7b33d4f6cba38c0515ffeeaa
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
(pieter.wuille[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: 1Ysh9c-0004vb-3J
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 00:37:37 -0000
--047d7b33d4f6cba38c0515ffeeaa
Content-Type: text/plain; charset=ISO-8859-1
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
--047d7b33d4f6cba38c0515ffeeaa
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Wed, May 13, 2015 at 1:32 PM, Tier Nolan <span dir=3D"l=
tr"><<a href=3D"mailto:tier.nolan@gmail.com" target=3D"_blank">tier.nola=
n@gmail.com</a>></span> wrote:<br><div class=3D"gmail_extra"><div class=
=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8=
ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=
=3D"gmail_extra"><br><div class=3D"gmail_quote"><span class=3D"">On Wed, Ma=
y 13, 2015 at 9:31 PM, Pieter Wuille <span dir=3D"ltr"><<a href=3D"mailt=
o: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_quote"=
><div>This was what I was suggesting all along, sorry if I wasn't clear=
.<span><font color=3D"#888888"><br></font></span><br></div></div></div></di=
v></blockquote></span><div>That's great.=A0 So, basically the multi-lev=
el refund problem is solved by this?<br></div></div></div></div></blockquot=
e><div><br></div><div>Yes. So to be clear, I think there are 2 desirable en=
d-goal proposals (ignoring difficulty of changing things for a minute):<br>=
<br></div><div>* Transactions and blocks keep referring to other transactio=
ns by full txid, but signature hashes are computed off normalized txids (wh=
ich are recursively defined to use normalized txids all the way back to coi=
nbases). Is this what you are suggesting now as well?<br><br></div><div>* B=
locks commit to full transaction data, but transactions and signature hashe=
s use normalized txids.<br><br></div><div>The benefit of the latter solutio=
n is that it doesn't need "fixing up" transactions whose inpu=
ts have been malleated, but comes at the cost of doing a very invasive hard=
fork.<br><br>-- <br></div><div>Pieter<br><br></div></div></div></div>
--047d7b33d4f6cba38c0515ffeeaa--
|
