You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
@@ -29,7 +29,7 @@ in future. Soft fork upgrades will become much easier and cleaner this
29
29
way.
30
30
31
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
32
+
reuse existing fields and do them in a better to maintain and easier
33
33
to parse system. It creates the building blocks to allow new features to be
34
34
added much cleaner in the future.
35
35
@@ -39,14 +39,29 @@ history. Tests show that this can reduce space usage to about 75%.
39
39
40
40
==Motivation==
41
41
42
+
After 8 years of using essentially the same transaction version and layout
43
+
Bitcoin is in need of an upgrade and lessons learned in that time are
44
+
taking into account when designing it. The most important detail is that
45
+
we have seen a need for more flexibility. For instance when the 'sequence'
46
+
fields were introduced in the old transaction format, and later deprecated
47
+
again, the end result was that all transactions still were forced to keep
48
+
those fields and grow the blockchain while they all were set to the default
49
+
value.
50
+
51
+
The way towards that flexibility is to use a generic concept made popular
52
+
various decades ago with the XML format. The idea is that we give each
53
+
field a name and this means that new fields can be added or optional fields
54
+
can be omitted from individual transactions. Some other ideas are the
55
+
standardization of data-formats (like integer and string encoding) so
56
+
we create a more consistent system.
57
+
One thing we shall not inherit from XML is its text-based format. Instead
58
+
we use the [https://github.com/bitcoinclassic/documentation/blob/master/spec/compactmessageformat.md Compact Message Format]
59
+
(CMF) which is optimized to keep the size small and fast to parse.
60
+
42
61
Token based file-formats are not new, systems like XML and HTMl use a
43
62
similar system to allow future growth and they have been quite successful
44
63
for decades in part because of this property.
45
64
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
65
Next to that this protocol upgrade will re-order the data-fields which
51
66
allows us to cleanly fix the malleability issue which means that future
52
67
technologies like Lightning Network will depend on this BIP being deployed.
@@ -55,6 +70,19 @@ At the same time, due to this re-ordering of data fields, it becomes very
55
70
easy to remove signatures from a transaction without breaking its tx-id,
56
71
which is great for future pruning features.
57
72
73
+
=== Features ===
74
+
75
+
* Fixes malleability
76
+
* Linear scaling of signature checking
77
+
* Very flexible future extensibility
78
+
* Makes transactions smaller
79
+
* Supports the Lightning Network
80
+
81
+
Additionally, in the v4 (flextrans) format we add the support for the
82
+
following proofs;
83
+
* input amount. Including the amount means we sign this transaction only if the amount we are spending is the one provided. Wallets that do not have the full UTXO DB can safely sign knowing that if they were lied to about the amount being spent, their signature is useless.
84
+
* scriptBase is the combined script of input and output, without signatures naturally. Providing this to a hardware wallet means it knows what output it is spending and can respond properly. Including it in the hash means its signature would be broken if we lied..
85
+
* Double spent-proof. Should a node detect a double spent he can notify his peers about this fact. Instead of sending the entire transactions, instead he sends only a proof. The node needs to send two pairs of info that proves that in both transactions the CTxIn are identical.
58
86
59
87
=== Tokens ===
60
88
@@ -63,7 +91,8 @@ define how these tokens are named, where they can be placed and which are
63
91
optional. To refer to XML, this specification would be the schema of
64
92
a transaction.
65
93
66
-
CMF tokens are triplets of name, format (like PositiveInteger) and value.
|TxRelativeBlockLock|| 7 ||Integer || Optional ||Part of the input stating the amount of blocks (max 0XFFFF) after that input was mined, it can be mined
91
120
|-
92
-
|ScriptVersion || 8 ||Integer || 2 ||Defines script version for outputs following
121
+
|TxRelativeTimeLock || 8 ||Integer || Optional ||Part of the input stating the amount of time (max 0XFFFF) after that input was mined, it can be mined. 1 Unit is 512 seconds
122
+
|-
123
+
|CoinbaseMessage || 9 ||ByteArray|| Optional ||A message and some data for a coinbase transaction. Can't be used in combination with any TxIn\* tags
124
+
|-
125
+
|NOP_1x || 1x || || Optional ||Values that will be ignored by anyone parsing the transaction
93
126
|-
94
-
|NOP_1x || 1x || . || Optional ||Values that will be ignored by anyone parsing the transaction
95
127
|}
96
128
97
129
98
130
=== Scripting changes ===
99
131
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.
132
+
In Bitcoin transactions version 1, checking of signatures is performed by
133
+
various opcodes. The OP_CHECKSIG, OP_CHECKMULTISIG and their equivalents
134
+
that immediately VERIFY. These are used to validate the cryptographic
135
+
proofs that users have to provide in order to spend outputs.
136
+
137
+
We additionally have some hashing-types in like SIGHASH_SINGLE that all
138
+
specify slightly different subsections of what part of a transaction will
139
+
be hashed in order to be signed.
140
+
141
+
For transactions with version 4 we calculate a sha256 hash for signing an
142
+
individual input based on the following content;
143
+
144
+
# If the hash-type is 0 or 1 we hash the tx-id of the transaction. For other hash types we selectively ignore parts of the transaction exactly like it has always worked. With the caveat that we never serialize any signatures.
145
+
# the TxId of the transaction we are spending in this input.
146
+
# the index of output of the transaction we are spending in this input.
147
+
# the input script we are signing (without the signature, naturally).
148
+
# the amount, as a var-int.
149
+
# the hash-type as a var-int.
103
150
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
151
111
152
=== Serialization order===
112
153
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
154
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.
155
+
To keep in line with the name Flexible Transactions, there is very little
156
+
requirement to have a specific order. The only exception is cases where
157
+
there are optional values and reordering would make unclear what is meant.
124
158
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
-
|}
159
+
For this reason the TxInPrevHash always has to be the first token to start
160
+
a new input. This is because the TxPrevIndex is optional. The tokens
161
+
TxRelativeTimeLock and TxRelativeBlockLock are part of the input and
162
+
similarly have to be set after the TxInPrevHash they belong to.
138
163
139
-
The TxId is calculated by taking the serialized transaction without the
140
-
Signatures and the TxEnd and hashing that.
164
+
Similarly, the TxInputStackItem always has to be the first and can be
165
+
followed by a number of TxInputStackItemContinued items.
141
166
167
+
At a larger scope we define 3 sections of a transaction.
142
168
143
169
{| class="wikitable"
144
170
!Segment !! Tags !! Description
145
171
|-
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
172
+
|Transaction||all not elsewhere used||This section is used to make the TxId
151
173
|-
152
-
|Signatures||TxInScript||Exactly the same amount as there are inputs
The TxId is calculated by taking the serialized transaction without the
180
+
Signatures and the TxEnd and hashing that.
181
+
157
182
TxEnd is there to allow a parser to know when one transaction in a stream
158
183
has ended, allowing the next to be parsed.
159
184
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 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
185
=== Block-malleability ===
177
186
178
187
The effect of leaving the signatures out of the calculation of the
179
188
transaction-id implies that the signatures are also not used for the
180
189
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.
190
+
would not be detectable and open an attack vector.
184
191
185
192
For this reason the merkle tree is extended to include (append) the hash of
186
193
the v4 transactions. The markle tree will continue to have all the
187
194
transactions' tx-ids but appended to that are the v4 hashes that include the
188
195
signatures as well. Specifically the hash is taken over a data-blob that
189
196
is built up from:
190
197
191
-
1. the tx-id
192
-
2. the CMF-tokens 'TxInScript'
193
-
198
+
# the tx-id
199
+
# The entire bytearray that makes up all of the transactions signatures. This is a serialization of all of the signature tokens, so the TxInputStackItem and TxInputStackItemContinued in the order based on the inputs they are associated with.
194
200
195
201
=== Future extensibility ===
196
202
@@ -207,9 +213,18 @@ trivially use these tokens for their own usage without cooperation and
207
213
communication with the rest of the Bitcoin ecosystem as miners certainly
208
214
have the option to reject transactions that use unknown-to-them tokens.
209
215
216
+
The amount of tokens that can be added after number 19 is practically
217
+
unlimited and they are currently specified to not be allowed in any
218
+
transaction and the transaction will be rejected if they are present.
219
+
In the future a protocol upgrade may chance that and specify meaning for
220
+
any token not yet specified here. Future upgrades should thus be quite a
221
+
lot smoother because there is no change in concepts or in format. Just new
222
+
data.
223
+
210
224
==Backwards compatibility ==
211
225
212
-
Fully validating older clients are not compatible with this change.
226
+
Fully validating older clients will not be able to understand or validate
227
+
version 4 transactions and will need to be updated to restore that ability.
213
228
214
229
SPV (simple payment validation) wallets need to be updated to receive or
215
230
create the new transaction type.
@@ -220,11 +235,12 @@ backwards compatible for any existing data or parsing-code.
220
235
221
236
==Reference Implementation==
222
237
223
-
Bitcoin Classic includes this in its beta releases and a reference
0 commit comments