From bcf0ea37840d9feba5fd6c16285e034f9a8e2688 Mon Sep 17 00:00:00 2001 From: Luke Dashjr Date: Tue, 19 Jan 2016 01:37:57 +0000 Subject: Assign BIP 131 --- README.mediawiki | 6 +++ bip-0131.mediawiki | 82 +++++++++++++++++++++++++++++++++++++++++ bip-coalesce-wildcard.mediawiki | 82 ----------------------------------------- 3 files changed, 88 insertions(+), 82 deletions(-) create mode 100644 bip-0131.mediawiki delete mode 100644 bip-coalesce-wildcard.mediawiki diff --git a/README.mediawiki b/README.mediawiki index 1ce3a76..7584102 100644 --- a/README.mediawiki +++ b/README.mediawiki @@ -410,6 +410,12 @@ Those proposing changes should consider that ultimately consent may rest with th | Standard | Draft |- +| [[bip-0131.mediawiki|131]] +| "Coalescing Transaction" Specification (wildcard inputs) +| Chris Priest +| Standard +| Draft +|- | [[bip-0140.mediawiki|140]] | Normalized TXID | Christian Decker diff --git a/bip-0131.mediawiki b/bip-0131.mediawiki new file mode 100644 index 0000000..c30ef54 --- /dev/null +++ b/bip-0131.mediawiki @@ -0,0 +1,82 @@ +
+  BIP: 131
+  Title: "Coalescing Transaction" Specification (wildcard inputs)
+  Author: Chris Priest 
+  Status: Draft
+  Type: Standards Track
+  Created: 2015-11-30
+
+ +==Abstract== + +This specification defines a new type of transaction that supplements (not replaces) +normal "non coalescing" bitcoin transactions. + +==Motivation== + +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 +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. + +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 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== + +=== Redefinition of Transaction version === + +First, this BIP 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". + +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 Coalescing Transactions. + +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 +with the same scriptPubKey. If this value is greater than or equal to the +amount of all outputs, then that coalescing transaction is valid and can be propagated. + +2. Full Node Non-Coalescing validation - When a non-coalescing transaction comes in, the code needs to be modified +to check if each input has not been spent by a coalescing transaction. If there exist any +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. + +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 coalescing transaction. Wallets should not simply replace non-coalescing transactions +with coalescing transactions in all instances. + +==Copyright== + +This document is placed in the public domain. diff --git a/bip-coalesce-wildcard.mediawiki b/bip-coalesce-wildcard.mediawiki deleted file mode 100644 index 4c3a557..0000000 --- a/bip-coalesce-wildcard.mediawiki +++ /dev/null @@ -1,82 +0,0 @@ -
-  BIP: (no number)
-  Title: "Coalescing Transaction" Specification (wildcard inputs)
-  Author: Chris Priest 
-  Status: Draft
-  Type: Standards Track
-  Created: 2015-11-30
-
- -==Abstract== - -This specification defines a new type of transaction that supplements (not replaces) -normal "non coalescing" bitcoin transactions. - -==Motivation== - -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 -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. - -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 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== - -=== Redefinition of Transaction version === - -First, this BIP 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". - -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 Coalescing Transactions. - -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 -with the same scriptPubKey. If this value is greater than or equal to the -amount of all outputs, then that coalescing transaction is valid and can be propagated. - -2. Full Node Non-Coalescing validation - When a non-coalescing transaction comes in, the code needs to be modified -to check if each input has not been spent by a coalescing transaction. If there exist any -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. - -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 coalescing transaction. Wallets should not simply replace non-coalescing transactions -with coalescing transactions in all instances. - -==Copyright== - -This document is placed in the public domain. -- cgit v1.2.3