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 --- bip-0131.mediawiki | 82 ++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 82 insertions(+) create mode 100644 bip-0131.mediawiki (limited to 'bip-0131.mediawiki') 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. -- cgit v1.2.3