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
|
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 1Yuf00-0008IE-Pt
for bitcoin-development@lists.sourceforge.net;
Tue, 19 May 2015 10:43:48 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.215.42 as permitted sender)
client-ip=209.85.215.42;
envelope-from=decker.christian@gmail.com;
helo=mail-la0-f42.google.com;
Received: from mail-la0-f42.google.com ([209.85.215.42])
by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1Yuezz-0004oy-Be
for bitcoin-development@lists.sourceforge.net;
Tue, 19 May 2015 10:43:48 +0000
Received: by laat2 with SMTP id t2so16845353laa.1
for <bitcoin-development@lists.sourceforge.net>;
Tue, 19 May 2015 03:43:41 -0700 (PDT)
X-Received: by 10.112.147.73 with SMTP id ti9mr21127143lbb.108.1432032220915;
Tue, 19 May 2015 03:43:40 -0700 (PDT)
MIME-Version: 1.0
References: <CALxbBHUnt7ToVK9reH6W6uT4HV=7NbxGHyNWWa-OEHg+Z1+qOg@mail.gmail.com>
<5555C26F.7080706@sky-ip.org>
<AC0B3BAC-0934-46A3-B29A-F74238616F72@gmail.com>
<CALxbBHXC=jc+7Vj-3-VT7kj-+V6ORdeJPr_G9ymOcJyFZ3hy=A@mail.gmail.com>
<CAE-z3OXC-uCYQmhGJd2ZVfLrEbAZVhEz0ejkbwmcRgK3kbjSrg@mail.gmail.com>
In-Reply-To: <CAE-z3OXC-uCYQmhGJd2ZVfLrEbAZVhEz0ejkbwmcRgK3kbjSrg@mail.gmail.com>
From: Christian Decker <decker.christian@gmail.com>
Date: Tue, 19 May 2015 10:43:39 +0000
Message-ID: <CALxbBHUvtoc25Eyh1KF=bmG8SbZd_UpO1QeUVLbicNqJQPHBLQ@mail.gmail.com>
To: Tier Nolan <tier.nolan@gmail.com>
Content-Type: multipart/alternative; boundary=047d7b3a88acd5ad3805166cfbab
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: 1Yuezz-0004oy-Be
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: Tue, 19 May 2015 10:43:48 -0000
--047d7b3a88acd5ad3805166cfbab
Content-Type: text/plain; charset=UTF-8
On Tue, May 19, 2015 at 11:16 AM Tier Nolan <tier.nolan@gmail.com> wrote:
> On Tue, May 19, 2015 at 9:28 AM, Christian Decker <
> decker.christian@gmail.com> wrote:
>
>> Thanks Stephen, I hadn't thought about BIP 34 and we need to address this
>> in both proposals. If we can avoid it I'd like not to have one
>> transaction hashed one way and other transactions in another way.
>>
>
> The normalized TXID cannot depend on height for other transactions.
> Otherwise, it gets mutated when been added to the chain, depending on
> height.
>
Well in the case of coinbase transactions we want them to be dependent on
the height they are included in, which is not a problem since they are only
valid in conjunction with the block that mined them.
>
> An option would be that the height is included in the scriptSig for all
> transactions, but for non-coinbase transctions, the height used is zero.
>
No need to add an extra field to the transaction just to include the
height. We can just add a rule that the height specified in the scriptSig
in coinbase transactions (and only coinbase transactions) is copied into
the locktime of the transaction before computing the normalized transaction
ID and leave the locktime untouched for all normal transactions
>
> I think if height has to be an input into the normalized txid function,
> the specifics of inclusion don't matter.
>
> The previous txid for coinbases are required to be all zeros, so the
> normalized txid could be to add the height to the txids of all inputs.
> Again, non-coinbase transactions would have heights of zero.
>
>
>> Is there a specific reason why that was not chosen at the time?
>>
>
> I assumed that since the scriptSig in the coinbase is specifically
> intended to be "random" bytes/extra nonce, so putting a restriction on it
> was guaranteed to be backward compatible.
>
Sounds reasonable :-)
>
>
> ------------------------------------------------------------------------------
> 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
>
--047d7b3a88acd5ad3805166cfbab
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_quote">On Tue, May 19, 2015 at 11:16 A=
M Tier Nolan <<a href=3D"mailto:tier.nolan@gmail.com">tier.nolan@gmail.c=
om</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"><div c=
lass=3D"gmail_extra"><div class=3D"gmail_quote">On Tue, May 19, 2015 at 9:2=
8 AM, Christian Decker <span dir=3D"ltr"><<a href=3D"mailto:decker.chris=
tian@gmail.com" target=3D"_blank">decker.christian@gmail.com</a>></span>=
wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bor=
der-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><span style=3D"f=
ont-size:13.1999998092651px;line-height:19.7999992370605px">Thanks Stephen,=
I hadn't thought about BIP 34 and we need to address this in both prop=
osals.=C2=A0</span><span style=3D"font-size:13.1999998092651px;line-height:=
19.7999992370605px">If we can avoid it I'd like not to have one transac=
tion hashed one way and other transactions in another way.</span></div></bl=
ockquote><div><br></div></div></div></div><div dir=3D"ltr"><div class=3D"gm=
ail_extra"><div class=3D"gmail_quote"><div>The normalized TXID cannot depen=
d on height for other transactions.=C2=A0 Otherwise, it gets mutated when b=
een added to the chain, depending on height.<br></div></div></div></div></b=
lockquote><div>Well in the case of coinbase transactions we want them to be=
dependent on the height they are included in, which is not a problem since=
they are only valid in conjunction with the block that mined them.=C2=A0</=
div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-lef=
t:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_ext=
ra"><div class=3D"gmail_quote"><div><br></div><div>An option would be that =
the height is included in the scriptSig for all transactions, but for non-c=
oinbase transctions, the height used is zero.<br></div></div></div></div></=
blockquote><div>No need to add an extra field to the transaction just to in=
clude the height. We can just add a rule that the height specified in the s=
criptSig in coinbase transactions (and only coinbase transactions) is copie=
d into the locktime of the transaction before computing the normalized tran=
saction ID and leave the locktime untouched for all normal transactions</di=
v><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:=
1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra=
"><div class=3D"gmail_quote"><div><br></div><div>I think if height has to b=
e an input into the normalized txid function, the specifics of inclusion do=
n't matter.<br></div><div><br></div><div>The previous txid for coinbase=
s are required to be all zeros, so the normalized txid could be to add the =
height to the txids of all inputs.=C2=A0 Again, non-coinbase transactions w=
ould have heights of zero.<br></div></div></div></div><div dir=3D"ltr"><div=
class=3D"gmail_extra"><div class=3D"gmail_quote"><div>=C2=A0</div><blockqu=
ote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc s=
olid;padding-left:1ex"><div dir=3D"ltr"><div><span style=3D"font-size:13.19=
99998092651px;line-height:19.7999992370605px">Is there a specific reason wh=
y that was not chosen at the time?<br></span></div></div></blockquote><div>=
<br></div></div></div></div><div dir=3D"ltr"><div class=3D"gmail_extra"><di=
v class=3D"gmail_quote"><div>I assumed that since the scriptSig in the coin=
base is specifically intended to be "random" bytes/extra nonce, s=
o putting a restriction on it was guaranteed to be backward compatible.<br>=
</div></div></div></div></blockquote><div>Sounds reasonable :-)=C2=A0</div>=
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra">=
<div class=3D"gmail_quote"><div></div><div>=C2=A0</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">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>
--047d7b3a88acd5ad3805166cfbab--
|
