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
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <gavinandresen@gmail.com>) id 1YsWv4-0005aC-Sy
for bitcoin-development@lists.sourceforge.net;
Wed, 13 May 2015 13:41:54 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.215.52 as permitted sender)
client-ip=209.85.215.52; envelope-from=gavinandresen@gmail.com;
helo=mail-la0-f52.google.com;
Received: from mail-la0-f52.google.com ([209.85.215.52])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1YsWv1-0002Kw-Eg
for bitcoin-development@lists.sourceforge.net;
Wed, 13 May 2015 13:41:54 +0000
Received: by lagv1 with SMTP id v1so29583318lag.3
for <bitcoin-development@lists.sourceforge.net>;
Wed, 13 May 2015 06:41:45 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.112.166.37 with SMTP id zd5mr15793656lbb.75.1431524505048;
Wed, 13 May 2015 06:41:45 -0700 (PDT)
Received: by 10.25.90.75 with HTTP; Wed, 13 May 2015 06:41:44 -0700 (PDT)
In-Reply-To: <CAE-z3OWUGPqruBkuXggzdNkOn+L-SSg84Qd1_JZYBunmY+j=HQ@mail.gmail.com>
References: <CALxbBHUnt7ToVK9reH6W6uT4HV=7NbxGHyNWWa-OEHg+Z1+qOg@mail.gmail.com>
<CAE-z3OWUGPqruBkuXggzdNkOn+L-SSg84Qd1_JZYBunmY+j=HQ@mail.gmail.com>
Date: Wed, 13 May 2015 09:41:44 -0400
Message-ID: <CABsx9T1tPP_qrdyKPneZciwtWh2gho_d=qTCjnipo3463dJbpA@mail.gmail.com>
From: Gavin Andresen <gavinandresen@gmail.com>
To: Tier Nolan <tier.nolan@gmail.com>
Content-Type: multipart/alternative; boundary=001a11c382d09c5e250515f6c523
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
(gavinandresen[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: 1YsWv1-0002Kw-Eg
Cc: Bitcoin Development <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: Wed, 13 May 2015 13:41:54 -0000
--001a11c382d09c5e250515f6c523
Content-Type: text/plain; charset=UTF-8
I think this needs more details before it gets a BIP number; for example,
which opcodes does this affect, and how, exactly, does it affect them? Is
the merkle root in the block header computed using normalized transaction
ids or normalized ids?
I think there might actually be two or three or four BIPs here:
+ Overall "what is trying to be accomplished"
+ Changes to the OP_*SIG* opcodes
+ Changes to the bloom-filtering SPV support
+ ...eventually, hard fork rollout plan
I also think that it is a good idea to have actually implemented a proposal
before getting a BIP number. At least, I find that actually writing the
code often turns up issues I hadn't considered when thinking about the
problem at a high level. And I STRONGLY believe BIPs should be descriptive
("here is how this thing works") not proscriptive ("here's how I think we
should all do it").
Finally: I like the idea of moving to a normalized txid. But it might make
sense to bundle that change with a bigger change to OP_CHECKSIG; see Greg
Maxwell's excellent talk about his current thoughts on that topic:
https://www.youtube.com/watch?v=Gs9lJTRZCDc
On Wed, May 13, 2015 at 9:12 AM, Tier Nolan <tier.nolan@gmail.com> wrote:
> I think this is a good way to handle things, but as you say, it is a hard
> fork.
>
> CHECKLOCKTIMEVERIFY covers many of the use cases, but it would be nice to
> fix malleability once and for all.
>
> This has the effect of doubling the size of the UTXO database. At
> minimum, there needs to be a legacy txid to normalized txid map in the
> database.
>
> An addition to the BIP would eliminate the need for the 2nd index. You
> could require a SPV proof of the spending transaction to be included with
> legacy transactions. This would allow clients to verify that the
> normalized txid matched the legacy id.
>
> The OutPoint would be {LegacyId | SPV Proof to spending tx | spending tx
> | index}. This allows a legacy transaction to be upgraded. OutPoints
> which use a normalized txid don't need the SPV proof.
>
> The hard fork would be followed by a transitional period, in which both
> txids could be used. Afterwards, legacy transactions have to have the SPV
> proof added. This means that old transactions with locktimes years in the
> future can be upgraded for spending, without nodes needing to maintain two
> indexes.
>
>
> ------------------------------------------------------------------------------
> 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
>
>
--
--
Gavin Andresen
--001a11c382d09c5e250515f6c523
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">I think this needs more details before it gets a BIP numbe=
r; for example, which opcodes does this affect, and how, exactly, does it a=
ffect them? Is the merkle root in the block header computed using normalize=
d transaction ids or normalized ids?=C2=A0<div><br></div><div>I think there=
might actually be two or three or four BIPs here:</div><div><br></div><div=
>=C2=A0+ Overall "what is trying to be accomplished"</div><div>=
=C2=A0+ Changes to the OP_*SIG* opcodes</div><div>=C2=A0+ Changes to the bl=
oom-filtering SPV support</div><div>=C2=A0+ ...eventually, hard fork rollou=
t plan</div><div><br><div>I also think that it is a good idea to have actua=
lly implemented a proposal before getting a BIP number. At least, I find th=
at actually writing the code often turns up issues I hadn't considered =
when thinking about the problem at a high level. And I STRONGLY believe BIP=
s should be descriptive ("here is how this thing works") not pros=
criptive ("here's how I think we should all do it").</div></d=
iv><div><br></div><div>Finally: I like the idea of moving to a normalized t=
xid. But it might make sense to bundle that change with a bigger change to =
OP_CHECKSIG; see Greg Maxwell's excellent talk about his current though=
ts on that topic:</div><div>=C2=A0=C2=A0<a href=3D"https://www.youtube.com/=
watch?v=3DGs9lJTRZCDc">https://www.youtube.com/watch?v=3DGs9lJTRZCDc</a></d=
iv><div><br></div></div><div class=3D"gmail_extra"><br><div class=3D"gmail_=
quote">On Wed, May 13, 2015 at 9:12 AM, Tier Nolan <span dir=3D"ltr"><<a=
href=3D"mailto:tier.nolan@gmail.com" target=3D"_blank">tier.nolan@gmail.co=
m</a>></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margi=
n:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">=
<div>I think this is a good way to handle things, but as you say, it is a h=
ard fork.<br><br></div>CHECKLOCKTIMEVERIFY covers many of the use cases, bu=
t it would be nice to fix malleability once and for all.<br><div><div><br>T=
his has the effect of doubling the size of the UTXO database.=C2=A0 At mini=
mum, there needs to be a legacy txid to normalized txid map in the database=
.<br><br></div><div>An addition to the BIP would eliminate the need for the=
2nd index.=C2=A0 You could require a SPV proof of the spending transaction=
to be included with legacy transactions.=C2=A0 This would allow clients to=
verify that the normalized txid matched the legacy id.<br><br></div><div>T=
he OutPoint would be {LegacyId | SPV Proof to spending tx=C2=A0 | spending =
tx | index}.=C2=A0 This allows a legacy transaction to be upgraded.=C2=A0 O=
utPoints which use a normalized txid don't need the SPV proof.<br><br><=
/div><div>The hard fork would be followed by a transitional period, in whic=
h both txids could be used.=C2=A0 Afterwards, legacy transactions have to h=
ave the SPV proof added.=C2=A0 This means that old transactions with lockti=
mes years in the future can be upgraded for spending, without nodes needing=
to maintain two indexes.<br></div></div></div>
<br>-----------------------------------------------------------------------=
-------<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">http://ad.doubleclick.net/ddm/clk/290420510;117567292;y</a><br>=
_______________________________________________<br>
Bitcoin-development mailing list<br>
<a href=3D"mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-develo=
pment@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>
<br></blockquote></div><br><br clear=3D"all"><div><br></div>-- <br><div cla=
ss=3D"gmail_signature">--<br>Gavin Andresen<br></div>
</div>
--001a11c382d09c5e250515f6c523--
|
