From 451260d6d906a8372675d39cd36e9a97aec089ce Mon Sep 17 00:00:00 2001 From: Chris Priest Date: Fri, 16 Oct 2015 20:10:54 -0700 Subject: 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 0000000..dc1c6d7 --- /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. -- cgit v1.2.3 From 029bd7d178fb3f163de17cd1a1b16286190ec696 Mon Sep 17 00:00:00 2001 From: Chris Priest Date: Fri, 16 Oct 2015 20:11:56 -0700 Subject: typos --- bip-0122.mediawiki | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/bip-0122.mediawiki b/bip-0122.mediawiki index dc1c6d7..b1576e7 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 -- cgit v1.2.3 From 6447c8df9e25df04e0e1b233a2fc69d61bb9fb4f Mon Sep 17 00:00:00 2001 From: Chris Priest Date: Fri, 16 Oct 2015 20:14:09 -0700 Subject: more typos --- bip-0122.mediawiki | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/bip-0122.mediawiki b/bip-0122.mediawiki index b1576e7..ea9c903 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== -- cgit v1.2.3 From 478c14dc171a448bc5f216d34b4a39e3ad6ac1ed Mon Sep 17 00:00:00 2001 From: Chris Priest Date: Fri, 16 Oct 2015 20:14:57 -0700 Subject: more typos --- bip-0122.mediawiki | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/bip-0122.mediawiki b/bip-0122.mediawiki index ea9c903..7dceb07 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? -- cgit v1.2.3 From bd5e1ead70eed7aa3cb9398be73e761e96b36678 Mon Sep 17 00:00:00 2001 From: Chris Priest Date: Mon, 30 Nov 2015 16:40:31 -0800 Subject: 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 0000000..1051723 --- /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. -- cgit v1.2.3 From a5093f1c4ab36a396644e4a12b64c344a9b95998 Mon Sep 17 00:00:00 2001 From: Chris Priest Date: Tue, 1 Dec 2015 13:14:55 -0800 Subject: 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 1051723..71cfa69 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. -- cgit v1.2.3 From bec0d9e8f64d0194eccca8a38f7a7aba7af913f2 Mon Sep 17 00:00:00 2001 From: Chris Priest Date: Wed, 2 Dec 2015 14:44:26 -0800 Subject: 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 71cfa69..1478922 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.
-- 
cgit v1.2.3


From 3ff75f1ad20ecea54d2db998a9f3218d7baf311e Mon Sep 17 00:00:00 2001
From: Chris Priest 
Date: Fri, 4 Dec 2015 14:32:24 -0800
Subject: 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 1478922..f0a6811 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.
-- 
cgit v1.2.3


From 632bf072521efd394106ff6cb9a13e2210077611 Mon Sep 17 00:00:00 2001
From: Chris Priest 
Date: Fri, 4 Dec 2015 14:34:53 -0800
Subject: 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 f0a6811..101842d 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.
-- 
cgit v1.2.3


From d982c11f87bfd5fa97b8456c9f98d9c7909a9c00 Mon Sep 17 00:00:00 2001
From: Chris Priest 
Date: Fri, 4 Dec 2015 14:37:51 -0800
Subject: 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 101842d..b033954 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.
-- 
cgit v1.2.3


From e97833688dc31c747ff0c3a9105fece26fbfa6e9 Mon Sep 17 00:00:00 2001
From: Chris Priest 
Date: Fri, 4 Dec 2015 14:40:01 -0800
Subject: 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 b033954..f7b5942 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
-- 
cgit v1.2.3


From a07c8b62b30d501efcfee147bf1e69d4619b698d Mon Sep 17 00:00:00 2001
From: Chris Priest 
Date: Fri, 4 Dec 2015 14:40:38 -0800
Subject: 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 f7b5942..ca4cf90 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".
-- 
cgit v1.2.3


From f9d64e782b6ec5b8a8cfed4556791e7dbabf83d5 Mon Sep 17 00:00:00 2001
From: Chris Priest 
Date: Fri, 4 Dec 2015 14:41:46 -0800
Subject: 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 ca4cf90..b4ca8e8 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.
-- 
cgit v1.2.3


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

---
 bip-coalesc-wildcard.mediawiki | 78 ++++++++++++++++++++++++++++++++++++++++++
 bip-tx-ver2.mediawiki          | 78 ------------------------------------------
 2 files changed, 78 insertions(+), 78 deletions(-)
 create mode 100644 bip-coalesc-wildcard.mediawiki
 delete mode 100644 bip-tx-ver2.mediawiki

diff --git a/bip-coalesc-wildcard.mediawiki b/bip-coalesc-wildcard.mediawiki
new file mode 100644
index 0000000..b4ca8e8
--- /dev/null
+++ b/bip-coalesc-wildcard.mediawiki
@@ -0,0 +1,78 @@
+
+  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.
diff --git a/bip-tx-ver2.mediawiki b/bip-tx-ver2.mediawiki
deleted file mode 100644
index b4ca8e8..0000000
--- a/bip-tx-ver2.mediawiki
+++ /dev/null
@@ -1,78 +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.
-- 
cgit v1.2.3


From e994fa264a7a9a854b4450d3e84f03a7858598c6 Mon Sep 17 00:00:00 2001
From: Chris Priest 
Date: Mon, 7 Dec 2015 15:55:42 -0800
Subject: 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 b4ca8e8..c729d06 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.
-- 
cgit v1.2.3


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

---
 bip-coalesc-wildcard.mediawiki  | 78 -----------------------------------------
 bip-coalesce-wildcard.mediawiki | 78 +++++++++++++++++++++++++++++++++++++++++
 2 files changed, 78 insertions(+), 78 deletions(-)
 delete mode 100644 bip-coalesc-wildcard.mediawiki
 create mode 100644 bip-coalesce-wildcard.mediawiki

diff --git a/bip-coalesc-wildcard.mediawiki b/bip-coalesc-wildcard.mediawiki
deleted file mode 100644
index c729d06..0000000
--- a/bip-coalesc-wildcard.mediawiki
+++ /dev/null
@@ -1,78 +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.
diff --git a/bip-coalesce-wildcard.mediawiki b/bip-coalesce-wildcard.mediawiki
new file mode 100644
index 0000000..c729d06
--- /dev/null
+++ b/bip-coalesce-wildcard.mediawiki
@@ -0,0 +1,78 @@
+
+  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.
-- 
cgit v1.2.3


From 3a41325f81e50c4d90cc04c5dec4c6f8b9ac6233 Mon Sep 17 00:00:00 2001
From: Chris Priest 
Date: Wed, 30 Dec 2015 15:54:33 -0800
Subject: 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 7dceb07..0000000
--- 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.
-- 
cgit v1.2.3


From 752e73c4205c981951df3feb7a7ed23eb3d5ef8b Mon Sep 17 00:00:00 2001
From: Chris Priest 
Date: Sat, 16 Jan 2016 08:02:18 -0800
Subject: 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 c729d06..4c3a557 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.
-- 
cgit v1.2.3


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