Skip to content

Commit b11eca4

Browse files
luke-jrluke-jr
authored
Merge pull request bitcoin#445 from zander/FlexTrans
BIP 134: Flexible Transactions
2 parents 8f8ac4f + b365408 commit b11eca4

File tree

2 files changed

+250
-0
lines changed

2 files changed

+250
-0
lines changed

‎README.mediawiki

Lines changed: 6 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -476,6 +476,12 @@ Those proposing changes should consider that ultimately consent may rest with th
476476
| Standard
477477
| Draft
478478
|-
479+
| [[bip-0134.mediawiki|134]]
480+
| Flexible Transactions
481+
| Tom Zander
482+
| Standard
483+
| Draft
484+
|-
479485
| [[bip-0140.mediawiki|140]]
480486
| Normalized TXID
481487
| Christian Decker

‎bip-0134.mediawiki

Lines changed: 244 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,244 @@
1+
<pre>
2+
BIP: 134
3+
Title: Flexible Transactions
4+
Author: Tom Zander <[email protected]>
5+
Status: Draft
6+
Type: Standards Track
7+
Created: 2016-07-27
8+
</pre>
9+
10+
==Abstract==
11+
12+
This BIP describes the next step in making Bitcoin's most basic element,
13+
the transaction, more flexible and easier to extend. At the same time this
14+
fixes all known cases of malleability and resolves significant amounts of
15+
technical debt.
16+
17+
==Summary==
18+
19+
Flexible Transactions uses the fact that the first 4 bytes in a transaction
20+
determine the version and that the majority of the clients use a
21+
non-consensus rule (a policy) to not accept transaction version numbers
22+
other than those specifically defined by Bitcoin.
23+
This BIP chooses a new version number, 4, and defines that the data
24+
following the bytes for the version is in a format called Compact Message
25+
Format (CMF). CMF is a flexible, token based format where each token is a
26+
combination of a name, a format and a value. Because the name is added we
27+
can skip unused tokens and we can freely add new tokens in a simple manner
28+
in future. Soft fork upgrades will become much easier and cleaner this
29+
way.
30+
31+
This protocol upgrade cleans up past soft fork changes like BIP68 which
32+
reuse existing fields and do them in a much better to maintain and easier
33+
to parse system. It creates the building blocks to allow new features to be
34+
added much cleaner in the future.
35+
36+
It also shows to be possible to remove signatures from transactions with
37+
minimal upgrades of software and still maintain a coherent transaction
38+
history. Tests show that this can reduce space usage to about 75%.
39+
40+
==Motivation==
41+
42+
Token based file-formats are not new, systems like XML and HTMl use a
43+
similar system to allow future growth and they have been quite successful
44+
for decades in part because of this property.
45+
46+
Bitcoin needs a similar way of making the transaction future-proof because
47+
re-purposing not used fields for new features is not good for creating
48+
maintainable code.
49+
50+
Next to that this protocol upgrade will re-order the data-fields which
51+
allows us to cleanly fix the malleability issue which means that future
52+
technologies like Lightning Network will depend on this BIP being deployed.
53+
54+
At the same time, due to this re-ordering of data fields, it becomes very
55+
easy to remove signatures from a transaction without breaking its tx-id,
56+
which is great for future pruning features.
57+
58+
59+
=== Tokens ===
60+
61+
In the compact message format we define tokens and in this specification we
62+
define how these tokens are named, where they can be placed and which are
63+
optional. To refer to XML, this specification would be the schema of
64+
a transaction.
65+
66+
CMF tokens are triplets of name, format (like PositiveInteger) and value.
67+
Names in this scope are defined much like an enumeration where the actual
68+
integer value (id, below) is equally important to the written name.
69+
If any token found that is not covered in the next table will make the
70+
transaction that contains it invalid.
71+
72+
{| class="wikitable"
73+
|-
74+
! Name !! id !! Format !! Default Value !! Description
75+
|-
76+
|TxEnd || 0 ||BoolTrue || Required ||A marker that is end of the transaction.
77+
|-
78+
|TxInPrevHash || 1 ||ByteArray|| Required ||TxId we are spending
79+
|-
80+
|TxPrevIndex || 2 ||Integer || 0 ||Index in prev tx we are spending (applied to previous TxInPrevHash)
81+
|-
82+
|TxInScript || 3 ||ByteArray|| Required ||The 'input' part of the script
83+
|-
84+
|TxOutValue || 4 ||Integer || Required ||Amount of satoshi to transfer
85+
|-
86+
|TxOutScript || 5 ||ByteArray|| Required ||The 'output' part of the script
87+
|-
88+
|LockByBlock || 6 ||Integer || Optional ||BIP68 replacement
89+
|-
90+
|LockByTime || 7 ||Integer || Optional ||BIP68 replacement
91+
|-
92+
|ScriptVersion || 8 ||Integer || 2 ||Defines script version for outputs following
93+
|-
94+
|NOP_1x || 1x || . || Optional ||Values that will be ignored by anyone parsing the transaction
95+
|}
96+
97+
98+
=== Scripting changes ===
99+
100+
In the current version of Bitcoin-script, version 1, there are various
101+
opcodes that are used to validate the cryptographic proofs that users have
102+
to provide in order to spend outputs.
103+
104+
The OP_CHECKSIG is the most well known and, as its name implies, it
105+
validates a signature.
106+
In the new version of 'script' (version 2) the data that is signed is
107+
changed to be equivalent to the transaction-id. This is a massive
108+
simplification and also the only change between version 1 and version 2 of
109+
script.
110+
111+
=== Serialization order===
112+
113+
The tokens defined above shall be serialized in a certain order for the
114+
transaction to be valid. Not serializing transactions in the
115+
order specified would allow multiple interpretations of the data which
116+
can't be allowed.
117+
There is still some flexibility and for that reason it is important for
118+
implementors to remember that the actual serialized data is used for the
119+
calculation of the transaction-id. Reading and writing it may give you a
120+
different output and when the txid changes, the signatures will break.
121+
122+
At a macro-level the transaction has these segments. The order of the
123+
segments can not be changed, but you can skip segments.
124+
125+
{| class="wikitable"
126+
!Segment !! Description
127+
|-
128+
| Inputs || Details about inputs.
129+
|-
130+
| Outputs || Details and scripts for outputs
131+
|-
132+
| Additional || For future expansion
133+
|-
134+
| Signatures || The scripts for the inputs
135+
|-
136+
| TxEnd || End of the transaction
137+
|}
138+
139+
The TxId is calculated by taking the serialized transaction without the
140+
Signatures and the TxEnd and hashing that.
141+
142+
143+
{| class="wikitable"
144+
!Segment !! Tags !! Description
145+
|-
146+
|Inputs||TxInPrevHash and TxInPrevIndex||Index can be skipped, but in any input the PrevHash always has to come first
147+
|-
148+
|Outputs||TxOutScript, TxOutValue||Order is not relevant
149+
|-
150+
|Additional||LockByBlock LockByTime NOP_1x
151+
|-
152+
|Signatures||TxInScript||Exactly the same amount as there are inputs
153+
|-
154+
|TxEnd||TxEnd
155+
|}
156+
157+
TxEnd is there to allow a parser to know when one transaction in a stream
158+
has ended, allowing the next to be parsed.
159+
160+
Notice that the token ScriptVersion is currently not allowed because we
161+
don't have any valid value to give it. But if we introduce a new script
162+
version it would be placed in the outputs segment.
163+
164+
=== Script v2 ===
165+
166+
The default value of ScriptVersion is number 2, as opposed to the version 1
167+
of script that the is in use today. The version 2 is mostly identical
168+
to version one, including upgrades made to it over the years and in the
169+
future. The only exception is that the OP_CHECKSIG is made dramatically
170+
simpler. The input-type for OP_CHECKSIG is now no longer configurable, it is
171+
always '1' and the content that will be signed is the txid.
172+
173+
TODO: does check-multisig need its own mention?
174+
175+
176+
=== Block-malleability ===
177+
178+
The effect of leaving the signatures out of the calculation of the
179+
transaction-id implies that the signatures are also not used for the
180+
calculation of the merkle tree. This means that changes in signatures
181+
would not be detectable. Except naturally by the fact that missing or
182+
broken signatures breaks full validation. But it is important to detect
183+
modifications to such signatures outside of validating all transactions.
184+
185+
For this reason the merkle tree is extended to include (append) the hash of
186+
the v4 transactions. The markle tree will continue to have all the
187+
transactions' tx-ids but appended to that are the v4 hahes that include the
188+
signatures as well. Specifically the hash is taken over a data-blob that
189+
is build up from:
190+
191+
1. the tx-id
192+
2. the CMF-tokens 'TxInScript'
193+
194+
195+
=== Future extensibility ===
196+
197+
The NOP_1x wildcard used in the table explaining tokens is actually a list
198+
of 10 values that currently are specified as NOP (no-operation) tags.
199+
200+
Any implementation that supports the v4 transaction format should ignore
201+
this field in a transaction. Interpreting and using the transaction as if
202+
that field was not present at all.
203+
204+
Future software may use these fields to decorate a transaction with
205+
additional data or features. Transaction generating software should not
206+
trivially use these tokens for their own usage without cooperation and
207+
communication with the rest of the Bitcoin ecosystem as miners certainly
208+
have the option to reject transactions that use unknown-to-them tokens.
209+
210+
==Backwards compatibility ==
211+
212+
Fully validating older clients are not compatible with this change.
213+
214+
SPV (simple payment validation) wallets need to be updated to receive or
215+
create the new transaction type.
216+
217+
This BIP introduces a new transaction format without changing or
218+
deprecating the existing one or any of its practices. Therefor it is
219+
backwards compatible for any existing data or parsing-code.
220+
221+
==Reference Implementation==
222+
223+
Bitcoin Classic includes this in its beta releases and a reference
224+
implementation can be found at;
225+
226+
https://github.com/bitcoinclassic/bitcoinclassic/pull/186
227+
228+
229+
==Deployment==
230+
231+
To be determined
232+
233+
==References==
234+
235+
[https://github.com/bitcoinclassic/documentation/blob/master/spec/compactmessageformat.md] CMF
236+
237+
==Copyright==
238+
239+
Copyright (c) 2016 Tom Zander <[email protected]>
240+
241+
This document is licensed under the Open Publication License v1.0
242+
243+
Distribution of substantively modified versions of this document is prohibited without the explicit permission of the copyright holder.
244+
Distribution of the work or derivative of the work in any standard (paper) book form is prohibited unless prior permission is obtained from the copyright holder.

0 commit comments

Comments
 (0)