bitcoin/bips
1
0
Fork 0
mirror of https://github.com/bitcoin/bips.git synced 2025-06-30 12:42:43 +00:00
Code Issues Releases Wiki Activity

added part about version field

Browse Source
This commit is contained in:
Chris Priest 2015-12-04 14:32:24 -08:00
parent bec0d9e8f6
commit 3ff75f1ad2
1 changed files with 35 additions and 11 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

46
bip-tx-ver2.mediawiki
View File

@ -1,6 +1,6 @@
<pre> <pre>
BIP: (no number) BIP: (no number)
Title: Transaction Version 2 Specification (wildcard inputs) Title: "Coalescing Transaction" Specification (wildcard inputs)
Author: Chris Priest <cp368202@ohiou.edu> Author: Chris Priest <cp368202@ohiou.edu>
Status: Draft Status: Draft
Type: Standards Track Type: Standards Track
@ -10,13 +10,13 @@
==Abstract== ==Abstract==
This specification defines a new type of transaction that supplements (not replaces) This specification defines a new type of transaction that supplements (not replaces)
version 1 transactions. normal "non coalescing" bitcoin transactions.
==Motivation== ==Motivation==
Version 1 Bitcoin Transactions have one large inefficiency: When you want to spend Normal "non-coalescing" Bitcoin Transactions have one large inefficiency: When you want to spend
from multiple inputs with the exact same scriptPubKey, you have to list each from multiple inputs with the exact same scriptPubKey, you have to list each
input separately, along with the same signature multiple times. input separately, along with the same signature multiple times, even though the signature expresses the same information.
This bloats the transaction size and makes it expensive to spend from small value inputs. This bloats the transaction size and makes it expensive to spend from small value inputs.
Because small value inputs are expensive to send, they remain in the UTXO pool Because small value inputs are expensive to send, they remain in the UTXO pool
@ -29,7 +29,30 @@ fees increase, the minimum economical value of a spending a UTXO will increase.
==Specification== ==Specification==
A version 2 transaction is formulated the exact same way as a version 1 transaction === Redefinition of Transaction version ===
First, this bips redefines the version field on transactions. The first four bytes
are defined as the version number, while the last four bytes are defined as the
transaction type. Type "0000" denotes normal transactions, and "0001" defines
coalescing transaction.
Examples:
version 1 transaction with normal inputs:
`version: 10000000`
version 2 transaction with normal inputs:
`version: 20000000`
version 2 transaction with coalescing inputs:
`version: 20000001`
Essentially the last bit in the version field is set to 1 to enable wildcard inputs for all
inputs present in the transaction.
=== Wildcard inputs ====
A coalescing transaction is formulated the exact same way as a version 1 transaction
with one exception: each input is treated as a "wildcard input". with one exception: each input is treated as a "wildcard input".
A wildcard input beings the value of all inputs with the exact same scriptPubKey A wildcard input beings the value of all inputs with the exact same scriptPubKey
@ -39,16 +62,17 @@ in a block lower or equal to the block the wildcard input is confirmed into.
The bitcoin code needs to be modified in three places in order to handle Version 2 Transactions. The bitcoin code needs to be modified in three places in order to handle Version 2 Transactions.
1. **Full Node V2 validation** - When a full node receives a V2 transaction, it has to 1. **Full Node Coalescing validation** - When a full node receives a coalescing transaction, it has to
aggregate the value of all the UTXOs in the blockchain older than the input aggregate the value of all the UTXOs in the blockchain older than the input
with the same scriptPubKey. If this value is greater than or equal to the with the same scriptPubKey. If this value is greater than or equal to the
amount of all outputs, then that V2 transaction is valid and can be propagated. amount of all outputs, then that coalescing transaction is valid and can be propagated.
2. **Full Node V1 validation** - When a V1 transaction comes in, the code needs to be modified 2. **Full Node Non-Coalescing validation** - When a non-coalescing transaction comes in, the code needs to be modified
to check if each inut has not been spent by a V2 transaction. If there exist any to check if each input has not been spent by a coalescing transaction. If there exist any
V2 transaction in the blockchain with the same scriptPubKey *after* that input, coalescing transaction in the blockchain with the same scriptPubKey found in a block *after* that input,
then the UTXO has been spent and the transaction is invalid. then the UTXO has been spent and the transaction is invalid.
3. **Wallet** - The user facing wallet portion of the reference client should notify 3. **Wallet** - The user facing wallet portion of the reference client should notify
the user when their wallet contains many UTXOs that qualify it to benefit from the user when their wallet contains many UTXOs that qualify it to benefit from
a V2 transaction. Wallets should not simply replace V1 transactions with V2 transactions. a coalescing transaction. Wallets should not simply replace non-coalescing transactions
with coalescing transactions in all instances.