diff --git a/bip-tx-ver2.mediawiki b/bip-tx-ver2.mediawiki index 71cfa692..14789221 100644 --- a/bip-tx-ver2.mediawiki +++ b/bip-tx-ver2.mediawiki @@ -1,5 +1,5 @@
- BIP: 122 + BIP: (no number) Title: Transaction Version 2 Specification (wildcard inputs) Author: Chris PriestStatus: Draft @@ -15,7 +15,7 @@ version 1 transactions. ==Motivation== Version 1 Bitcoin Transactions have one large inefficiency: When you want to spend -from multiple inputs with the exact same scriptSig, 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. This bloats the transaction size and makes it expensive to spend from small value inputs. @@ -23,13 +23,32 @@ Because small value inputs are expensive to send, they remain in the UTXO pool which full nodes have to keep around. It is believed that long term increase of the UTXO set can have negative scaling consequences on the network. -If maximum blocksize is made to increase *slower* than the actual number of transactins bitcoin users are sending -to the network, this problem is projected to get worse. +If maximum blocksize is made to increase *slower* than the actual number of transactions bitcoin users are sending +to the network, this problem is projected to get worse. In other words, as transaction +fees increase, the minimum economical value of a spending a UTXO will increase. ==Specification== A version 2 transaction is formulated the exact same way as a version 1 transaction with one exception: each input is treated as a "wildcard input". -A wildcard input beings the value of all inputs with the exact same scriptSig +A wildcard input beings the value of all inputs with the exact same scriptPubKey in a block lower or equal to the block the wildcard input is confirmed into. + +== Changes needed to implement == + +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 + 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 + amount of all outputs, then that V2 transaction is valid and can be propagated. + +2. **Full Node V1 validation** - When a V1 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 + V2 transaction in the blockchain with the same scriptPubKey *after* that input, + then the UTXO has been spent and the transaction is invalid. + +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 + a V2 transaction. Wallets should not simply replace V1 transactions with V2 transactions.