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
|
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 1YsW57-00027m-N0
for bitcoin-development@lists.sourceforge.net;
Wed, 13 May 2015 12:48:13 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.217.169 as permitted sender)
client-ip=209.85.217.169;
envelope-from=decker.christian@gmail.com;
helo=mail-lb0-f169.google.com;
Received: from mail-lb0-f169.google.com ([209.85.217.169])
by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1YsW55-0006HT-NH
for bitcoin-development@lists.sourceforge.net;
Wed, 13 May 2015 12:48:13 +0000
Received: by lbbqq2 with SMTP id qq2so28558500lbb.3
for <bitcoin-development@lists.sourceforge.net>;
Wed, 13 May 2015 05:48:05 -0700 (PDT)
X-Received: by 10.152.164.233 with SMTP id yt9mr12065541lab.58.1431521285340;
Wed, 13 May 2015 05:48:05 -0700 (PDT)
MIME-Version: 1.0
From: Christian Decker <decker.christian@gmail.com>
Date: Wed, 13 May 2015 12:48:04 +0000
Message-ID: <CALxbBHUnt7ToVK9reH6W6uT4HV=7NbxGHyNWWa-OEHg+Z1+qOg@mail.gmail.com>
To: Bitcoin Development <bitcoin-development@lists.sourceforge.net>
Content-Type: multipart/alternative; boundary=001a1133b066b3846d0515f60523
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: 1YsW55-0006HT-NH
Subject: [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 12:48:13 -0000
--001a1133b066b3846d0515f60523
Content-Type: text/plain; charset=UTF-8
Hi All,
I'd like to propose a BIP to normalize transaction IDs in order to address
transaction malleability and facilitate higher level protocols.
The normalized transaction ID is an alias used in parallel to the current
(legacy) transaction IDs to address outputs in transactions. It is
calculated by removing (zeroing) the scriptSig before computing the hash,
which ensures that only data whose integrity is also guaranteed by the
signatures influences the hash. Thus if anything causes the normalized ID
to change it automatically invalidates the signature. When validating a
client supporting this BIP would use both the normalized tx ID as well as
the legacy tx ID when validating transactions.
The detailed writeup can be found here:
https://github.com/cdecker/bips/blob/normalized-txid/bip-00nn.mediawiki.
@gmaxwell: I'd like to request a BIP number, unless there is something
really wrong with the proposal.
In addition to being a simple alternative that solves transaction
malleability it also hugely simplifies higher level protocols. We can now
use template transactions upon which sequences of transactions can be built
before signing them.
I hesitated quite a while to propose it since it does require a hardfork
(old clients would not find the prevTx identified by the normalized
transaction ID and deem the spending transaction invalid), but it seems
that hardforks are no longer the dreaded boogeyman nobody talks about.
I left out the details of how the hardfork is to be done, as it does not
really matter and we may have a good mechanism to apply a bunch of
hardforks concurrently in the future.
I'm sure it'll take time to implement and upgrade, but I think it would be
a nice addition to the functionality and would solve a long standing
problem :-)
Please let me know what you think, the proposal is definitely not set in
stone at this point and I'm sure we can improve it further.
Regards,
Christian
--001a1133b066b3846d0515f60523
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>Hi All,</div><div><br></div>I'd like to propose a=
BIP to normalize transaction IDs in order to address transaction malleabil=
ity and facilitate higher level protocols.<div><br></div><div>The normalize=
d transaction ID is an alias used in parallel to the current (legacy) trans=
action IDs to address outputs in transactions. It is calculated by removing=
(zeroing) the scriptSig before computing the hash, which ensures that only=
data whose integrity is also guaranteed by the signatures influences the h=
ash. Thus if anything causes the normalized ID to change it automatically i=
nvalidates the signature. When validating a client supporting this BIP woul=
d use both the normalized tx ID as well as the legacy tx ID when validating=
transactions.</div><div><br></div><div>The detailed writeup can be found h=
ere:=C2=A0<a href=3D"https://github.com/cdecker/bips/blob/normalized-txid/b=
ip-00nn.mediawiki">https://github.com/cdecker/bips/blob/normalized-txid/bip=
-00nn.mediawiki</a>.</div><div><br></div><div>@gmaxwell: I'd like to re=
quest a BIP number, unless there is something really wrong with the proposa=
l.</div><div><br></div><div>In addition to being a simple alternative that =
solves transaction malleability it also hugely simplifies higher level prot=
ocols. We can now use template transactions upon which sequences of transac=
tions can be built before signing them.</div><div><br></div><div>I hesitate=
d quite a while to propose it since it does require a hardfork (old clients=
would not find the prevTx identified by the normalized transaction ID and =
deem the spending transaction invalid), but it seems that hardforks are no =
longer the dreaded boogeyman nobody talks about.</div><div>I left out the d=
etails of how the hardfork is to be done, as it does not really matter and =
we may have a good mechanism to apply a bunch of hardforks concurrently in =
the future.</div><div><br></div><div>I'm sure it'll take time to im=
plement and upgrade, but I think it would be a nice addition to the functio=
nality and would solve a long standing problem :-)</div><div><br></div><div=
>Please let me know what you think, the proposal is definitely not set in s=
tone at this point and I'm sure we can improve it further.</div><div><b=
r></div><div>Regards,</div><div>Christian</div></div>
--001a1133b066b3846d0515f60523--
|
