diff options
| -rw-r--r-- | README.mediawiki | 6 | ||||
| -rw-r--r-- | bip-0102.mediawiki | 23 | ||||
| -rw-r--r-- | bip-0131.mediawiki | 82 | ||||
| -rw-r--r-- | bip-0144.mediawiki | 2 |
4 files changed, 101 insertions, 12 deletions
diff --git a/README.mediawiki b/README.mediawiki index fb6e8a3..87e6117 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-0132.mediawiki|132]] | Committee-based BIP Acceptance Process | Andy Chase diff --git a/bip-0102.mediawiki b/bip-0102.mediawiki index b75f798..fc909f7 100644 --- a/bip-0102.mediawiki +++ b/bip-0102.mediawiki @@ -13,28 +13,29 @@ Simple, one-time increase in total amount of transaction data permitted in a blo ==Motivation== -# Enable network growth. -# Continue current economic policy of low fee pressure on average. -# Exercise network upgrade procedure. +# Continue current economic policy. +# Exercise hard fork network upgrade. ==Specification== -# Maximum block size permitted to be valid is 1MB. -# Increase this maximum to 2MB as soon as 75% of the last 1,000 blocks have signaled support. +# MAX_BLOCK_SIZE increased to 2,000,000 bytes at trigger point. # Increase maximum block sigops by similar factor, preserving SIZE/50 formula. +# Trigger: (1) Block time 00:00:00 on flag day, AND (2) 95% of the last 1,000 blocks have signaled support. ==Backward compatibility== -Older clients are not compatible with this change. The first block exceeding 1,000,000 bytes will partition older clients off the new network. +Fully validating older clients are not compatible with this change. +The first block exceeding 1,000,000 bytes will partition older clients +off the new network. ==Discussion== -In the short term, an increase is needed to continue to facilitate -network growth, and buy time for more comprehensive solutions to be -developed. This continues the current economic policies with regards to -fees, matching market expectations and preventing market disruption. +In the short term, an increase is needed to continue to current +economic policies with regards to fees and block space, matching +market expectations and preventing market disruption. -In the long term, continued direct management of this limit is a moral hazard that clouds free market input and prevents a healthy fee market from developing. This area of code should be transitioned away from direct management. +In the long term, this limit should focus on reflecting the maximum +network engineering limit. ==Implementation== 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 @@ +<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. diff --git a/bip-0144.mediawiki b/bip-0144.mediawiki index 736fadd..5503044 100644 --- a/bip-0144.mediawiki +++ b/bip-0144.mediawiki @@ -73,7 +73,7 @@ The serialization has the following structure: | The block number or timestamp until which the transaction is locked |} -Parsers supporting this BIP will be able to distinguish between the old serialization format (without the witness) and this one. The marker byte is set to zero so that this structure will never parse as a valid transaction in a parser that does not support this BIP. If parsing were to succeeded, such a transaction would contain no inputs and a single output. +Parsers supporting this BIP will be able to distinguish between the old serialization format (without the witness) and this one. The marker byte is set to zero so that this structure will never parse as a valid transaction in a parser that does not support this BIP. If parsing were to succeed, such a transaction would contain no inputs and a single output. If the witness is empty, the old serialization format should be used. |