From 451260d6d906a8372675d39cd36e9a97aec089ce Mon Sep 17 00:00:00 2001 From: Chris Priest Date: Fri, 16 Oct 2015 20:10:54 -0700 Subject: [PATCH 01/19] added bip122 --- bip-0122.mediawiki | 47 ++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 47 insertions(+) create mode 100644 bip-0122.mediawiki diff --git a/bip-0122.mediawiki b/bip-0122.mediawiki new file mode 100644 index 00000000..dc1c6d7b --- /dev/null +++ b/bip-0122.mediawiki @@ -0,0 +1,47 @@ +
+  BIP: 122
+  Title: Creation of new testnet for scaling experiments
+  Author: Chris Priest 
+  Status: Draft
+  Type: Standards Track
+  Created: 2015-10-16
+
+ +==Abstract== + +This BIP defines the creation of a new parallel text network called "ScaleNet", +which will be used to test the effects of massive scale upon the bitcoin +consensus protocol. + +==Motivation== + +Bitcoin was originally designed to be an experiment. With the increase in the market +cap, this experimental nature is decreased. There is considerable doubt whether +the Bitcoin consensus protocol can handle transaction rates orders of magnitude +higher than the network sees today. + +==Specification== + +The code for ScaleNet will resemble the current Bitcoin testnet code in every way possible. +The only difference will be the elimination of the blocksize limit. + +ScaleNet coins will have 0 monetary value, just like TestNet coins. + +There will also be a ScaleNet faucet that wil be used to automatically get free ScaleNet coins. + +==ScaleNet spammer== + +Along with the creation of the ScaleNet client, there will also be a piece of software +called the "ScaleNet Spammer Client". The purpose of this software is to simply send large amounts +of transactions to the network. This software works very much like how software used to "stress test" +the main Bitcoin network. + +==Lessons Hopefully learned== + +* What happens when the blockchain get too large to fit entirely onto a consumer grade hard drive? +* How will it be possible to run a full node when there are hundreds of GB of unconfirmed transactions in the mempool? +* What kind of special attention needs to go into mining gigantic blocks (>100MB) without through the roof orphan tares. + +Each of these questions will be answered by ScaleNet. At some point in time +bitcoin will need to face these problems. Hopefully the insights learned +from ScaleNet will help drive a more data-driven approach to Bitcoin Development. From 029bd7d178fb3f163de17cd1a1b16286190ec696 Mon Sep 17 00:00:00 2001 From: Chris Priest Date: Fri, 16 Oct 2015 20:11:56 -0700 Subject: [PATCH 02/19] typos --- bip-0122.mediawiki | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/bip-0122.mediawiki b/bip-0122.mediawiki index dc1c6d7b..b1576e7b 100644 --- a/bip-0122.mediawiki +++ b/bip-0122.mediawiki @@ -40,7 +40,7 @@ the main Bitcoin network. * What happens when the blockchain get too large to fit entirely onto a consumer grade hard drive? * How will it be possible to run a full node when there are hundreds of GB of unconfirmed transactions in the mempool? -* What kind of special attention needs to go into mining gigantic blocks (>100MB) without through the roof orphan tares. +* What kind of special attention needs to go into mining gigantic blocks (>100MB) without through the roof orphan rates? Each of these questions will be answered by ScaleNet. At some point in time bitcoin will need to face these problems. Hopefully the insights learned From 6447c8df9e25df04e0e1b233a2fc69d61bb9fb4f Mon Sep 17 00:00:00 2001 From: Chris Priest Date: Fri, 16 Oct 2015 20:14:09 -0700 Subject: [PATCH 03/19] more typos --- bip-0122.mediawiki | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/bip-0122.mediawiki b/bip-0122.mediawiki index b1576e7b..ea9c903c 100644 --- a/bip-0122.mediawiki +++ b/bip-0122.mediawiki @@ -22,12 +22,12 @@ higher than the network sees today. ==Specification== -The code for ScaleNet will resemble the current Bitcoin testnet code in every way possible. +The code for ScaleNet will resemble the current Bitcoin TestNet code in every way possible. The only difference will be the elimination of the blocksize limit. ScaleNet coins will have 0 monetary value, just like TestNet coins. -There will also be a ScaleNet faucet that wil be used to automatically get free ScaleNet coins. +There will also be a ScaleNet faucet that will be used to automatically get free ScaleNet coins. ==ScaleNet spammer== From 478c14dc171a448bc5f216d34b4a39e3ad6ac1ed Mon Sep 17 00:00:00 2001 From: Chris Priest Date: Fri, 16 Oct 2015 20:14:57 -0700 Subject: [PATCH 04/19] more typos --- bip-0122.mediawiki | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/bip-0122.mediawiki b/bip-0122.mediawiki index ea9c903c..7dceb073 100644 --- a/bip-0122.mediawiki +++ b/bip-0122.mediawiki @@ -29,14 +29,14 @@ ScaleNet coins will have 0 monetary value, just like TestNet coins. There will also be a ScaleNet faucet that will be used to automatically get free ScaleNet coins. -==ScaleNet spammer== +==ScaleNet Spammer== Along with the creation of the ScaleNet client, there will also be a piece of software called the "ScaleNet Spammer Client". The purpose of this software is to simply send large amounts of transactions to the network. This software works very much like how software used to "stress test" the main Bitcoin network. -==Lessons Hopefully learned== +==Lessons Hopefully Learned== * What happens when the blockchain get too large to fit entirely onto a consumer grade hard drive? * How will it be possible to run a full node when there are hundreds of GB of unconfirmed transactions in the mempool? From bd5e1ead70eed7aa3cb9398be73e761e96b36678 Mon Sep 17 00:00:00 2001 From: Chris Priest Date: Mon, 30 Nov 2015 16:40:31 -0800 Subject: [PATCH 05/19] added txver2 --- bip-tx-ver2.mediawiki | 32 ++++++++++++++++++++++++++++++++ 1 file changed, 32 insertions(+) create mode 100644 bip-tx-ver2.mediawiki diff --git a/bip-tx-ver2.mediawiki b/bip-tx-ver2.mediawiki new file mode 100644 index 00000000..10517232 --- /dev/null +++ b/bip-tx-ver2.mediawiki @@ -0,0 +1,32 @@ +
+  BIP: 122
+  Title: Transaction Version 2 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) +version 1 transactions. + +==Motivation== + +Version 1 Bitcoin Transactions have one large inefficiency: When you want to spend +from multiple inputs with the exact same scriptPubKey, you have to list the same +signature multiple times. 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. + +==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 scriptPubKey +in a block lower or equal to the block the wildcard input is confirmed into. From a5093f1c4ab36a396644e4a12b64c344a9b95998 Mon Sep 17 00:00:00 2001 From: Chris Priest Date: Tue, 1 Dec 2015 13:14:55 -0800 Subject: [PATCH 06/19] added more stuff --- bip-tx-ver2.mediawiki | 11 +++++++---- 1 file changed, 7 insertions(+), 4 deletions(-) diff --git a/bip-tx-ver2.mediawiki b/bip-tx-ver2.mediawiki index 10517232..71cfa692 100644 --- a/bip-tx-ver2.mediawiki +++ b/bip-tx-ver2.mediawiki @@ -15,18 +15,21 @@ version 1 transactions. ==Motivation== Version 1 Bitcoin Transactions have one large inefficiency: When you want to spend -from multiple inputs with the exact same scriptPubKey, you have to list the same -signature multiple times. This bloats the transaction size and makes it expensive to spend -from small value inputs. +from multiple inputs with the exact same scriptSig, 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. 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. + ==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 scriptPubKey +A wildcard input beings the value of all inputs with the exact same scriptSig in a block lower or equal to the block the wildcard input is confirmed into. From bec0d9e8f64d0194eccca8a38f7a7aba7af913f2 Mon Sep 17 00:00:00 2001 From: Chris Priest Date: Wed, 2 Dec 2015 14:44:26 -0800 Subject: [PATCH 07/19] added 'needed to implement' section --- bip-tx-ver2.mediawiki | 29 ++++++++++++++++++++++++----- 1 file changed, 24 insertions(+), 5 deletions(-) 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 Priest 
   Status: 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.

From 3ff75f1ad20ecea54d2db998a9f3218d7baf311e Mon Sep 17 00:00:00 2001
From: Chris Priest 
Date: Fri, 4 Dec 2015 14:32:24 -0800
Subject: [PATCH 08/19] added part about version field

---
 bip-tx-ver2.mediawiki | 46 ++++++++++++++++++++++++++++++++-----------
 1 file changed, 35 insertions(+), 11 deletions(-)

diff --git a/bip-tx-ver2.mediawiki b/bip-tx-ver2.mediawiki
index 14789221..f0a68116 100644
--- a/bip-tx-ver2.mediawiki
+++ b/bip-tx-ver2.mediawiki
@@ -1,6 +1,6 @@
 
   BIP: (no number)
-  Title: Transaction Version 2 Specification (wildcard inputs)
+  Title: "Coalescing Transaction" Specification (wildcard inputs)
   Author: Chris Priest 
   Status: Draft
   Type: Standards Track
@@ -10,13 +10,13 @@
 ==Abstract==
 
 This specification defines a new type of transaction that supplements (not replaces)
-version 1 transactions.
+normal "non coalescing" bitcoin transactions.
 
 ==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
-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.
 
 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==
 
-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".
 
 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.
 
-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
    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
-   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,
+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 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.

From 632bf072521efd394106ff6cb9a13e2210077611 Mon Sep 17 00:00:00 2001
From: Chris Priest 
Date: Fri, 4 Dec 2015 14:34:53 -0800
Subject: [PATCH 09/19] typo

---
 bip-tx-ver2.mediawiki | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/bip-tx-ver2.mediawiki b/bip-tx-ver2.mediawiki
index f0a68116..101842d3 100644
--- a/bip-tx-ver2.mediawiki
+++ b/bip-tx-ver2.mediawiki
@@ -31,7 +31,7 @@ fees increase, the minimum economical value of a spending a UTXO will increase.
 
 === Redefinition of Transaction version ===
 
-First, this bips redefines the version field on transactions. The first four bytes
+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.

From d982c11f87bfd5fa97b8456c9f98d9c7909a9c00 Mon Sep 17 00:00:00 2001
From: Chris Priest 
Date: Fri, 4 Dec 2015 14:37:51 -0800
Subject: [PATCH 10/19] fixed formatting

---
 bip-tx-ver2.mediawiki | 18 +++++++++---------
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/bip-tx-ver2.mediawiki b/bip-tx-ver2.mediawiki
index 101842d3..b0339547 100644
--- a/bip-tx-ver2.mediawiki
+++ b/bip-tx-ver2.mediawiki
@@ -63,16 +63,16 @@ 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.
 
 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.
+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.
+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.
+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.

From e97833688dc31c747ff0c3a9105fece26fbfa6e9 Mon Sep 17 00:00:00 2001
From: Chris Priest 
Date: Fri, 4 Dec 2015 14:40:01 -0800
Subject: [PATCH 11/19] removed reference to version 2

---
 bip-tx-ver2.mediawiki | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/bip-tx-ver2.mediawiki b/bip-tx-ver2.mediawiki
index b0339547..f7b59429 100644
--- a/bip-tx-ver2.mediawiki
+++ b/bip-tx-ver2.mediawiki
@@ -60,7 +60,7 @@ 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.
+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

From a07c8b62b30d501efcfee147bf1e69d4619b698d Mon Sep 17 00:00:00 2001
From: Chris Priest 
Date: Fri, 4 Dec 2015 14:40:38 -0800
Subject: [PATCH 12/19] formatting changes

---
 bip-tx-ver2.mediawiki | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/bip-tx-ver2.mediawiki b/bip-tx-ver2.mediawiki
index f7b59429..ca4cf900 100644
--- a/bip-tx-ver2.mediawiki
+++ b/bip-tx-ver2.mediawiki
@@ -39,18 +39,18 @@ coalescing transaction.
 Examples:
 
 version 1 transaction with normal inputs:
-`version: 10000000`
+``version: 10000000``
 
 version 2 transaction with normal inputs:
-`version: 20000000`
+``version: 20000000``
 
 version 2 transaction with coalescing inputs:
-`version: 20000001`
+``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 ====
+=== 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".

From f9d64e782b6ec5b8a8cfed4556791e7dbabf83d5 Mon Sep 17 00:00:00 2001
From: Chris Priest 
Date: Fri, 4 Dec 2015 14:41:46 -0800
Subject: [PATCH 13/19] formatting changes

---
 bip-tx-ver2.mediawiki | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/bip-tx-ver2.mediawiki b/bip-tx-ver2.mediawiki
index ca4cf900..b4ca8e81 100644
--- a/bip-tx-ver2.mediawiki
+++ b/bip-tx-ver2.mediawiki
@@ -39,13 +39,13 @@ coalescing transaction.
 Examples:
 
 version 1 transaction with normal inputs:
-``version: 10000000``
+    version: 10000000
 
 version 2 transaction with normal inputs:
-``version: 20000000``
+    version: 20000000
 
 version 2 transaction with coalescing inputs:
-``version: 20000001``
+    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.

From bdd7c9ff76405b265af1f1822736cc95b0a44228 Mon Sep 17 00:00:00 2001
From: Chris Priest 
Date: Fri, 4 Dec 2015 15:48:37 -0800
Subject: [PATCH 14/19] renamed file

---
 bip-tx-ver2.mediawiki => bip-coalesc-wildcard.mediawiki | 0
 1 file changed, 0 insertions(+), 0 deletions(-)
 rename bip-tx-ver2.mediawiki => bip-coalesc-wildcard.mediawiki (100%)

diff --git a/bip-tx-ver2.mediawiki b/bip-coalesc-wildcard.mediawiki
similarity index 100%
rename from bip-tx-ver2.mediawiki
rename to bip-coalesc-wildcard.mediawiki

From e994fa264a7a9a854b4450d3e84f03a7858598c6 Mon Sep 17 00:00:00 2001
From: Chris Priest 
Date: Mon, 7 Dec 2015 15:55:42 -0800
Subject: [PATCH 15/19] fixed bolding

---
 bip-coalesc-wildcard.mediawiki | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/bip-coalesc-wildcard.mediawiki b/bip-coalesc-wildcard.mediawiki
index b4ca8e81..c729d069 100644
--- a/bip-coalesc-wildcard.mediawiki
+++ b/bip-coalesc-wildcard.mediawiki
@@ -62,17 +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 Coalescing Transactions.
 
-1. **Full Node Coalescing validation** - When a full node receives a coalescing 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
 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
+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
+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.

From e36fba6978b72c4541a7288570ed623cf945294e Mon Sep 17 00:00:00 2001
From: Chris Priest 
Date: Wed, 30 Dec 2015 15:51:11 -0800
Subject: [PATCH 16/19] added coalesce bip to new branch

---
 bip-coalesc-wildcard.mediawiki => bip-coalesce-wildcard.mediawiki | 0
 1 file changed, 0 insertions(+), 0 deletions(-)
 rename bip-coalesc-wildcard.mediawiki => bip-coalesce-wildcard.mediawiki (100%)

diff --git a/bip-coalesc-wildcard.mediawiki b/bip-coalesce-wildcard.mediawiki
similarity index 100%
rename from bip-coalesc-wildcard.mediawiki
rename to bip-coalesce-wildcard.mediawiki

From 3a41325f81e50c4d90cc04c5dec4c6f8b9ac6233 Mon Sep 17 00:00:00 2001
From: Chris Priest 
Date: Wed, 30 Dec 2015 15:54:33 -0800
Subject: [PATCH 17/19] removed old bip

---
 bip-0122.mediawiki | 47 ----------------------------------------------
 1 file changed, 47 deletions(-)
 delete mode 100644 bip-0122.mediawiki

diff --git a/bip-0122.mediawiki b/bip-0122.mediawiki
deleted file mode 100644
index 7dceb073..00000000
--- a/bip-0122.mediawiki
+++ /dev/null
@@ -1,47 +0,0 @@
-
-  BIP: 122
-  Title: Creation of new testnet for scaling experiments
-  Author: Chris Priest 
-  Status: Draft
-  Type: Standards Track
-  Created: 2015-10-16
-

-
-==Abstract==
-
-This BIP defines the creation of a new parallel text network called "ScaleNet",
-which will be used to test the effects of massive scale upon the bitcoin
-consensus protocol.
-
-==Motivation==
-
-Bitcoin was originally designed to be an experiment. With the increase in the market
-cap, this experimental nature is decreased. There is considerable doubt whether
-the Bitcoin consensus protocol can handle transaction rates orders of magnitude
-higher than the network sees today.
-
-==Specification==
-
-The code for ScaleNet will resemble the current Bitcoin TestNet code in every way possible.
-The only difference will be the elimination of the blocksize limit.
-
-ScaleNet coins will have 0 monetary value, just like TestNet coins.
-
-There will also be a ScaleNet faucet that will be used to automatically get free ScaleNet coins.
-
-==ScaleNet Spammer==
-
-Along with the creation of the ScaleNet client, there will also be a piece of software
-called the "ScaleNet Spammer Client". The purpose of this software is to simply send large amounts
-of transactions to the network. This software works very much like how software used to "stress test"
-the main Bitcoin network.
-
-==Lessons Hopefully Learned==
-
-* What happens when the blockchain get too large to fit entirely onto a consumer grade hard drive?
-* How will it be possible to run a full node when there are hundreds of GB of unconfirmed transactions in the mempool?
-* What kind of special attention needs to go into mining gigantic blocks (>100MB) without through the roof orphan rates?
-
-Each of these questions will be answered by ScaleNet. At some point in time
-bitcoin will need to face these problems. Hopefully the insights learned
-from ScaleNet will help drive a more data-driven approach to Bitcoin Development.

From 752e73c4205c981951df3feb7a7ed23eb3d5ef8b Mon Sep 17 00:00:00 2001
From: Chris Priest 
Date: Sat, 16 Jan 2016 08:02:18 -0800
Subject: [PATCH 18/19] added copyright

---
 bip-coalesce-wildcard.mediawiki | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/bip-coalesce-wildcard.mediawiki b/bip-coalesce-wildcard.mediawiki
index c729d069..4c3a557a 100644
--- a/bip-coalesce-wildcard.mediawiki
+++ b/bip-coalesce-wildcard.mediawiki
@@ -76,3 +76,7 @@ then the UTXO has been spent and the transaction is invalid.
 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.

From bcf0ea37840d9feba5fd6c16285e034f9a8e2688 Mon Sep 17 00:00:00 2001
From: Luke Dashjr 
Date: Tue, 19 Jan 2016 01:37:57 +0000
Subject: [PATCH 19/19] Assign BIP 131

---
 README.mediawiki                                      | 6 ++++++
 bip-coalesce-wildcard.mediawiki => bip-0131.mediawiki | 2 +-
 2 files changed, 7 insertions(+), 1 deletion(-)
 rename bip-coalesce-wildcard.mediawiki => bip-0131.mediawiki (99%)

diff --git a/README.mediawiki b/README.mediawiki
index 1ce3a76f..75841029 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-coalesce-wildcard.mediawiki b/bip-0131.mediawiki
similarity index 99%
rename from bip-coalesce-wildcard.mediawiki
rename to bip-0131.mediawiki
index 4c3a557a..c30ef54c 100644
--- a/bip-coalesce-wildcard.mediawiki
+++ b/bip-0131.mediawiki
@@ -1,5 +1,5 @@
 
-  BIP: (no number)
+  BIP: 131
   Title: "Coalescing Transaction" Specification (wildcard inputs)
   Author: Chris Priest 
   Status: Draft