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-4.v43.ch3.sourceforge.com ([172.29.43.194]
helo=mx.sourceforge.net)
by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <tier.nolan@gmail.com>) id 1YudaW-0007Ap-Rc
for bitcoin-development@lists.sourceforge.net;
Tue, 19 May 2015 09:13:24 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.216.169 as permitted sender)
client-ip=209.85.216.169; envelope-from=tier.nolan@gmail.com;
helo=mail-qc0-f169.google.com;
Received: from mail-qc0-f169.google.com ([209.85.216.169])
by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1YudaV-0001tY-1F
for bitcoin-development@lists.sourceforge.net;
Tue, 19 May 2015 09:13:24 +0000
Received: by qceb3 with SMTP id b3so2471415qce.2
for <bitcoin-development@lists.sourceforge.net>;
Tue, 19 May 2015 02:13:17 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.140.202.130 with SMTP id x124mr772835qha.9.1432026797524;
Tue, 19 May 2015 02:13:17 -0700 (PDT)
Received: by 10.140.85.241 with HTTP; Tue, 19 May 2015 02:13:17 -0700 (PDT)
In-Reply-To: <CALxbBHXC=jc+7Vj-3-VT7kj-+V6ORdeJPr_G9ymOcJyFZ3hy=A@mail.gmail.com>
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>
Date: Tue, 19 May 2015 10:13:17 +0100
Message-ID: <CAE-z3OXC-uCYQmhGJd2ZVfLrEbAZVhEz0ejkbwmcRgK3kbjSrg@mail.gmail.com>
From: Tier Nolan <tier.nolan@gmail.com>
Cc: Bitcoin Development <bitcoin-development@lists.sourceforge.net>
Content-Type: multipart/alternative; boundary=001a11432f14934b4505166bb898
X-Spam-Score: 3.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
2.7 MALFORMED_FREEMAIL Bad headers on message from free email service
X-Headers-End: 1YudaV-0001tY-1F
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 09:13:24 -0000
--001a11432f14934b4505166bb898
Content-Type: text/plain; charset=UTF-8
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.
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.
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.
--001a11432f14934b4505166bb898
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On T=
ue, May 19, 2015 at 9:28 AM, Christian Decker <span dir=3D"ltr"><<a href=
=3D"mailto:decker.christian@gmail.com" target=3D"_blank">decker.christian@g=
mail.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 style=3D"font-size:13.1999998092651px;line-height:19.7999992=
370605px">Thanks Stephen, I hadn't thought about BIP 34 and we need to =
address this in both proposals.=C2=A0</span><span style=3D"font-size:13.199=
9998092651px;line-height:19.7999992370605px">If we can avoid it I'd lik=
e not to have one transaction hashed one way and other transactions in anot=
her way.</span></div></blockquote><div><br></div><div>The normalized TXID c=
annot depend on height for other transactions.=C2=A0 Otherwise, it gets mut=
ated when been added to the chain, depending on height.<br><br></div><div>A=
n option would be that the height is included in the scriptSig for all tran=
sactions, but for non-coinbase transctions, the height used is zero.<br><br=
></div><div>I think if height has to be an input into the normalized txid f=
unction, the specifics of inclusion don't matter.<br></div><div><br></d=
iv><div>The previous txid for coinbases are required to be all zeros, so th=
e normalized txid could be to add the height to the txids of all inputs.=C2=
=A0 Again, non-coinbase transactions would have heights of zero.<br></div><=
div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8e=
x;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><span =
style=3D"font-size:13.1999998092651px;line-height:19.7999992370605px">Is th=
ere a specific reason why that was not chosen at the time?<br></span></div>=
</div></blockquote><div><br></div><div>I assumed that since the scriptSig i=
n the coinbase is specifically intended to be "random" bytes/extr=
a nonce, so putting a restriction on it was guaranteed to be backward compa=
tible.<br></div><div>=C2=A0</div></div></div></div>
--001a11432f14934b4505166bb898--
|
