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
|
Return-Path: <decker.christian@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 6462A486
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 19 Oct 2015 14:01:17 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com
[209.85.212.178])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 953B2EB
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 19 Oct 2015 14:01:16 +0000 (UTC)
Received: by wikq8 with SMTP id q8so7366774wik.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 19 Oct 2015 07:01:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=mime-version:from:date:message-id:subject:to:content-type;
bh=fR0+sI7IUkPq0YsgTOgLdcinujLtTEQViid9rQ5D4W8=;
b=aFLFzfTE0OH0GZ5rvtOgLPqNgCHjt30rp0iHjc3xgxoW5x+UxDfWphXRYucHbMuRp1
uInqUG+TyG8m6YrUV7zRhf/lIJKcQCzZ9FKflYWr/7XyObcFY9kkMp9/jqXY2nSb1S6Y
SJ0tomp0E75OKFuyTXk1b4dlcWbvPGDOcrtTlXGYTaraN/P1NXLF7UoKC3NG5qT+vObb
csQIifuKHrjPoYF1/wthyVJqNgSJMsJzQqgOp1F9KiznQA2BNPBoXtDzXmN0qf7g1iq0
9W9aPhC6h1dTtkiMFlFnNN2qjLoTBW+TK179Ub8GGFbEcrmjARy01YgIwglGHvhLQ4qG
RwBQ==
X-Received: by 10.194.239.230 with SMTP id vv6mr32423761wjc.21.1445263274303;
Mon, 19 Oct 2015 07:01:14 -0700 (PDT)
MIME-Version: 1.0
From: Christian Decker <decker.christian@gmail.com>
Date: Mon, 19 Oct 2015 14:01:04 +0000
Message-ID: <CALxbBHU+kdEAh_4+B663vknAAr8OKZpUzVTACORPZi47E=Ehkw@mail.gmail.com>
To: Bitcoin development mailing list <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary=089e0141a3d6127fd7052275940a
X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_LOW
autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
Subject: [bitcoin-dev] [BIP] Normalized transaction IDs
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Development Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Mon, 19 Oct 2015 14:01:17 -0000
--089e0141a3d6127fd7052275940a
Content-Type: text/plain; charset=UTF-8
After spending some more time on the normalized transaction ID proposal and
reworking it to be a soft-fork (thanks sipa for helping me figuring out
how), I'd like to propose the BIP again.
As with the previous version, which was using a hard-fork, the normalized
transaction ID is computed only considering the non-malleable parts of a
transaction, i.e., stripping the signatures before computing the hash of
the transaction. This ensures that if a transaction is modified, either by
a third party fishing transactions from the network and re-injecting
modified versions or by one of the signers re-signing it, any transaction
that builds on top of it still remains valid. Furthermore it allows the use
of template transactions, unsigned transactions upon which further
transaction can be built before signing the template transaction and
locking the contract.
Unlike the previous proposal, this is a softfork proposal that redefines
OP_NOP4 with an extensible and parameterized version of the signature
checking opcodes, called OP_CHECKSIGEX. Among other things the parameters
allow to specify that an output with an OP_CHECKSIGEX is to be referenced
by the normalized transaction ID that created it, instead of the instance
transaction ID containing malleable signatures. This BIP uses the
normalized transaction IDs exclusively while signing or checking
signatures, they are not used in any network level message as the previous
version would have done, hence there is no change at network level and old
clients should be able to exchange transactions as before and blocks still
reference the transaction instances.
The proposal is implemented (see below), by computing the normalized
transaction ID when adding them to the UTXO and storing them along with the
coin state. OP_CHECKSIGEX mostly duplicates OP_CHECKSIG and
OP_CHECKMULTISIG, but I'm hoping somebody can give me some pointers into
how to best refactor the common functionality into reusable blocks. And the
annotating incoming transactions with their normalized inputs is a bit
cumbersome, maye somebody has some pointers here as well?
BIP Pull request: https://github.com/bitcoin/bips/pull/224
Implementation: https://github.com/cdecker/bitcoin/commits/normtx
I think in the discussion of my previous proposal, most of you welcomed the
introduction of normalized transaction IDs, were it not for the hardfork. I
hope this proposal adresses the previous concerns and that we can move
forward in adding the normalized transaction IDs to the bitcoin protocol.
That being said, I'm always open to suggestions :-)
Regards,
Christian
--089e0141a3d6127fd7052275940a
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">After spending some more time on the normalized transactio=
n ID proposal and reworking it to be a soft-fork (thanks sipa for helping m=
e figuring out how), I'd like to propose the BIP again.<div><br></div><=
div>As with the previous version, which was using a hard-fork, the normaliz=
ed transaction ID is computed only considering the non-malleable parts of a=
transaction, i.e., stripping the signatures before computing the hash of t=
he transaction. This ensures that if a transaction is modified, either by a=
third party fishing transactions from the network and re-injecting modifie=
d versions or by one of the signers re-signing it, any transaction that bui=
lds on top of it still remains valid. Furthermore it allows the use of temp=
late transactions, unsigned transactions upon which further transaction can=
be built before signing the template transaction and locking the contract.=
</div><div><br></div><div>Unlike the previous proposal, this is a softfork =
proposal that redefines OP_NOP4 with an extensible and parameterized versio=
n of the signature checking opcodes, called OP_CHECKSIGEX. Among other thin=
gs the parameters allow to specify that an output with an OP_CHECKSIGEX is =
to be referenced by the normalized transaction ID that created it, instead =
of the instance transaction ID containing malleable signatures. This BIP us=
es the normalized transaction IDs exclusively while signing or checking sig=
natures, they are not used in any network level message as the previous ver=
sion would have done, hence there is no change at network level and old cli=
ents should be able to exchange transactions as before and blocks still ref=
erence the transaction instances.</div><div><br></div><div>The proposal is =
implemented (see below), by computing the normalized transaction ID when ad=
ding them to the UTXO and storing them along with the coin state. OP_CHECKS=
IGEX mostly duplicates OP_CHECKSIG and OP_CHECKMULTISIG, but I'm hoping=
somebody can give me some pointers into how to best refactor the common fu=
nctionality into reusable blocks. And the annotating incoming transactions =
with their normalized inputs is a bit cumbersome, maye somebody has some po=
inters here as well?</div><div><br></div><div>BIP Pull request: <a href=3D"=
https://github.com/bitcoin/bips/pull/224">https://github.com/bitcoin/bips/p=
ull/224</a></div><div>Implementation:=C2=A0<a href=3D"https://github.com/cd=
ecker/bitcoin/commits/normtx">https://github.com/cdecker/bitcoin/commits/no=
rmtx</a></div><div><br></div><div>I think in the discussion of my previous =
proposal, most of you welcomed the introduction of normalized transaction I=
Ds, were it not for the hardfork. I hope this proposal adresses the previou=
s concerns and that we can move forward in adding the normalized transactio=
n IDs to the bitcoin protocol. That being said, I'm always open to sugg=
estions :-)</div><div><br></div><div>Regards,</div><div>Christian</div></di=
v>
--089e0141a3d6127fd7052275940a--
|
