diff options
Diffstat (limited to 'bip-0134.mediawiki')
| -rw-r--r-- | bip-0134.mediawiki | 244 |
1 files changed, 244 insertions, 0 deletions
diff --git a/bip-0134.mediawiki b/bip-0134.mediawiki new file mode 100644 index 0000000..280103f --- /dev/null +++ b/bip-0134.mediawiki @@ -0,0 +1,244 @@ +<pre> + BIP: 134 + Title: Flexible Transactions + Author: Tom Zander <tomz@freedommail.ch> + Status: Draft + Type: Standards Track + Created: 2016-07-27 +</pre> + +==Abstract== + +This BIP describes the next step in making Bitcoin's most basic element, +the transaction, more flexible and easier to extend. At the same time this +fixes all known cases of malleability and resolves significant amounts of +technical debt. + +==Summary== + +Flexible Transactions uses the fact that the first 4 bytes in a transaction +determine the version and that the majority of the clients use a +non-consensus rule (a policy) to not accept transaction version numbers +other than those specifically defined by Bitcoin. +This BIP chooses a new version number, 4, and defines that the data +following the bytes for the version is in a format called Compact Message +Format (CMF). CMF is a flexible, token based format where each token is a +combination of a name, a format and a value. Because the name is added we +can skip unused tokens and we can freely add new tokens in a simple manner +in future. Soft fork upgrades will become much easier and cleaner this +way. + +This protocol upgrade cleans up past soft fork changes like BIP68 which +reuse existing fields and do them in a much better to maintain and easier +to parse system. It creates the building blocks to allow new features to be +added much cleaner in the future. + +It also shows to be possible to remove signatures from transactions with +minimal upgrades of software and still maintain a coherent transaction +history. Tests show that this can reduce space usage to about 75%. + +==Motivation== + +Token based file-formats are not new, systems like XML and HTMl use a +similar system to allow future growth and they have been quite successful +for decades in part because of this property. + +Bitcoin needs a similar way of making the transaction future-proof because +re-purposing not used fields for new features is not good for creating +maintainable code. + +Next to that this protocol upgrade will re-order the data-fields which +allows us to cleanly fix the malleability issue which means that future +technologies like Lightning Network will depend on this BIP being deployed. + +At the same time, due to this re-ordering of data fields, it becomes very +easy to remove signatures from a transaction without breaking its tx-id, +which is great for future pruning features. + + +=== Tokens === + +In the compact message format we define tokens and in this specification we +define how these tokens are named, where they can be placed and which are +optional. To refer to XML, this specification would be the schema of +a transaction. + +CMF tokens are triplets of name, format (like PositiveInteger) and value. +Names in this scope are defined much like an enumeration where the actual +integer value (id, below) is equally important to the written name. +If any token found that is not covered in the next table will make the +transaction that contains it invalid. + +{| class="wikitable" +|- +! Name !! id !! Format !! Default Value !! Description +|- +|TxEnd || 0 ||BoolTrue || Required ||A marker that is end of the transaction. +|- +|TxInPrevHash || 1 ||ByteArray|| Required ||TxId we are spending +|- +|TxPrevIndex || 2 ||Integer || 0 ||Index in prev tx we are spending (applied to previous TxInPrevHash) +|- +|TxInScript || 3 ||ByteArray|| Required ||The 'input' part of the script +|- +|TxOutValue || 4 ||Integer || Required ||Amount of satoshi to transfer +|- +|TxOutScript || 5 ||ByteArray|| Required ||The 'output' part of the script +|- +|LockByBlock || 6 ||Integer || Optional ||BIP68 replacement +|- +|LockByTime || 7 ||Integer || Optional ||BIP68 replacement +|- +|ScriptVersion || 8 ||Integer || 2 ||Defines script version for outputs following +|- +|NOP_1x || 1x || . || Optional ||Values that will be ignored by anyone parsing the transaction +|} + + +=== Scripting changes === + +In the current version of Bitcoin-script, version 1, there are various +opcodes that are used to validate the cryptographic proofs that users have +to provide in order to spend outputs. + +The OP_CHECKSIG is the most well known and, as its name implies, it +validates a signature. +In the new version of 'script' (version 2) the data that is signed is +changed to be equivalent to the transaction-id. This is a massive +simplification and also the only change between version 1 and version 2 of +script. + +=== Serialization order=== + +The tokens defined above shall be serialized in a certain order for the +transaction to be valid. Not serializing transactions in the +order specified would allow multiple interpretations of the data which +can't be allowed. +There is still some flexibility and for that reason it is important for +implementors to remember that the actual serialized data is used for the +calculation of the transaction-id. Reading and writing it may give you a +different output and when the txid changes, the signatures will break. + +At a macro-level the transaction has these segments. The order of the +segments can not be changed, but you can skip segments. + +{| class="wikitable" +!Segment !! Description +|- +| Inputs || Details about inputs. +|- +| Outputs || Details and scripts for outputs +|- +| Additional || For future expansion +|- +| Signatures || The scripts for the inputs +|- +| TxEnd || End of the transaction +|} + +The TxId is calculated by taking the serialized transaction without the +Signatures and the TxEnd and hashing that. + + +{| class="wikitable" +!Segment !! Tags !! Description +|- +|Inputs||TxInPrevHash and TxInPrevIndex||Index can be skipped, but in any input the PrevHash always has to come first +|- +|Outputs||TxOutScript, TxOutValue||Order is not relevant +|- +|Additional||LockByBlock LockByTime NOP_1x +|- +|Signatures||TxInScript||Exactly the same amount as there are inputs +|- +|TxEnd||TxEnd +|} + +TxEnd is there to allow a parser to know when one transaction in a stream +has ended, allowing the next to be parsed. + +Notice that the token ScriptVersion is currently not allowed because we +don't have any valid value to give it. But if we introduce a new script +version it would be placed in the outputs segment. + +=== Script v2 === + +The default value of ScriptVersion is number 2, as opposed to the version 1 +of script that the is in use today. The version 2 is mostly identical +to version one, including upgrades made to it over the years and in the +future. The only exception is that the OP_CHECKSIG is made dramatically +simpler. The input-type for OP_CHECKSIG is now no longer configurable, it is +always '1' and the content that will be signed is the txid. + +TODO: does check-multisig need its own mention? + + +=== Block-malleability === + +The effect of leaving the signatures out of the calculation of the +transaction-id implies that the signatures are also not used for the +calculation of the merkle tree. This means that changes in signatures +would not be detectable. Except naturally by the fact that missing or +broken signatures breaks full validation. But it is important to detect +modifications to such signatures outside of validating all transactions. + +For this reason the merkle tree is extended to include (append) the hash of +the v4 transactions. The markle tree will continue to have all the +transactions' tx-ids but appended to that are the v4 hahes that include the +signatures as well. Specifically the hash is taken over a data-blob that +is build up from: + +1. the tx-id +2. the CMF-tokens 'TxInScript' + + +=== Future extensibility === + +The NOP_1x wildcard used in the table explaining tokens is actually a list +of 10 values that currently are specified as NOP (no-operation) tags. + +Any implementation that supports the v4 transaction format should ignore +this field in a transaction. Interpreting and using the transaction as if +that field was not present at all. + +Future software may use these fields to decorate a transaction with +additional data or features. Transaction generating software should not +trivially use these tokens for their own usage without cooperation and +communication with the rest of the Bitcoin ecosystem as miners certainly +have the option to reject transactions that use unknown-to-them tokens. + +==Backwards compatibility == + +Fully validating older clients are not compatible with this change. + +SPV (simple payment validation) wallets need to be updated to receive or +create the new transaction type. + +This BIP introduces a new transaction format without changing or +deprecating the existing one or any of its practices. Therefor it is +backwards compatible for any existing data or parsing-code. + +==Reference Implementation== + +Bitcoin Classic includes this in its beta releases and a reference +implementation can be found at; + +https://github.com/bitcoinclassic/bitcoinclassic/pull/186 + + +==Deployment== + +To be determined + +==References== + +[https://github.com/bitcoinclassic/documentation/blob/master/spec/compactmessageformat.md] CMF + +==Copyright== + +Copyright (c) 2016 Tom Zander <tomz@freedommail.ch> + +This document is licensed under the Open Publication License v1.0 + +Distribution of substantively modified versions of this document is prohibited without the explicit permission of the copyright holder. +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. |