Merge BIP 131: "Coalescing Transaction" Specification (wildcard inputs)

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

bip-0131.mediawiki

@@ -0,0 +1,82 @@
+<pre>
+  BIP: 131
+  Title: "Coalescing Transaction" Specification (wildcard inputs)
+  Author: Chris Priest <cp368202@ohiou.edu>
+  Status: Draft
+  Type: Standards Track
+  Created: 2015-11-30
+</pre>
+
+==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. <b>Full Node Coalescing validation</b> - 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. <b>Full Node Non-Coalescing validation</b> - 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. <b>Wallet</b> - 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.