diff options
34 files changed, 401 insertions, 154 deletions
diff --git a/README.mediawiki b/README.mediawiki index 045fd28..8067fae 100644 --- a/README.mediawiki +++ b/README.mediawiki @@ -24,13 +24,13 @@ Those proposing changes should consider that ultimately consent may rest with th | Pieter Wuille, Peter Todd, Greg Maxwell, Rusty Russell | Informational | Draft -|- +|- style="background-color: #ffcfcf" | [[bip-0010.mediawiki|10]] | Multi-Sig Transaction Distribution | Alan Reiner | Informational | Withdrawn -|- style="background-color: #cfffcf" +|- style="background-color: #ffffcf" | [[bip-0011.mediawiki|11]] | M-of-N Standard Transactions | Gavin Andresen @@ -48,13 +48,13 @@ Those proposing changes should consider that ultimately consent may rest with th | Gavin Andresen | Standard | Final -|- style="background-color: #cfffcf" +|- style="background-color: #ffffcf" | [[bip-0014.mediawiki|14]] | Protocol Version and User Agent | Amir Taaki, Patrick Strateman | Standard | Accepted -|- style="background-color: #ffcfcf" +|- | [[bip-0015.mediawiki|15]] | Aliases | Amir Taaki @@ -62,7 +62,7 @@ Those proposing changes should consider that ultimately consent may rest with th | Deferred |- style="background-color: #cfffcf" | [[bip-0016.mediawiki|16]] -| Pay To Script Hash +| Pay to Script Hash | Gavin Andresen | Standard | Final @@ -90,19 +90,19 @@ Those proposing changes should consider that ultimately consent may rest with th | Luke Dashjr | Standard | Replaced -|- style="background-color: #cfffcf" +|- style="background-color: #ffffcf" | [[bip-0021.mediawiki|21]] | URI Scheme | Nils Schneider, Matt Corallo | Standard | Accepted -|- style="background-color: #cfffcf" +|- style="background-color: #ffffcf" | [[bip-0022.mediawiki|22]] | getblocktemplate - Fundamentals | Luke Dashjr | Standard | Accepted -|- style="background-color: #cfffcf" +|- style="background-color: #ffffcf" | [[bip-0023.mediawiki|23]] | getblocktemplate - Pooled Mining | Luke Dashjr @@ -114,13 +114,13 @@ Those proposing changes should consider that ultimately consent may rest with th | Pieter Wuille | Standard | Final -|- style="background-color: #cfffcf" +|- style="background-color: #ffffcf" | [[bip-0031.mediawiki|31]] | Pong message | Mike Hearn | Standard | Accepted -|- style="background-color: #cfffcf" +|- style="background-color: #ffffcf" | [[bip-0032.mediawiki|32]] | Hierarchical Deterministic Wallets | Pieter Wuille @@ -132,13 +132,13 @@ Those proposing changes should consider that ultimately consent may rest with th | Amir Taaki | Standard | Draft -|- style="background-color: #cfffcf" +|- style="background-color: #ffffcf" | [[bip-0034.mediawiki|34]] -| Block v2, Height in coinbase +| Block v2, Height in Coinbase | Gavin Andresen | Standard | Accepted -|- style="background-color: #cfffcf" +|- style="background-color: #ffffcf" | [[bip-0035.mediawiki|35]] | mempool message | Jeff Garzik @@ -150,34 +150,34 @@ Those proposing changes should consider that ultimately consent may rest with th | Stefan Thomas | Standard | Draft -|- style="background-color: #cfffcf" +|- style="background-color: #ffffcf" | [[bip-0037.mediawiki|37]] -| Bloom filtering +| Connection Bloom filtering | Mike Hearn, Matt Corallo | Standard | Accepted |- | [[bip-0038.mediawiki|38]] | Passphrase-protected private key -| Mike Caldwell +| Mike Caldwell, Aaron Voisine | Standard | Draft |- | [[bip-0039.mediawiki|39]] | Mnemonic code for generating deterministic keys -| Slush +| Marek Palatinus, Pavol Rusnak, Aaron Voisine, Sean Bowe | Standard | Draft |- | 40 | Stratum wire protocol -| Slush +| Marek Palatinus | Standard | BIP number allocated |- | 41 | Stratum mining protocol -| Slush +| Marek Palatinus | Standard | BIP number allocated |- @@ -189,19 +189,19 @@ Those proposing changes should consider that ultimately consent may rest with th |- | [[bip-0043.mediawiki|43]] | Purpose Field for Deterministic Wallets -| Slush +| Marek Palatinus, Pavol Rusnak | Standard | Draft |- | [[bip-0044.mediawiki|44]] | Multi-Account Hierarchy for Deterministic Wallets -| Slush +| Marek Palatinus, Pavol Rusnak | Standard | Draft |- | [[bip-0045.mediawiki|45]] | Structure for Deterministic P2SH Multisignature Wallets -| Manuel Araoz +| Manuel Araoz, Ryan X. Charles, Matias Alejo Garcia | Standard | Draft |- @@ -223,13 +223,13 @@ Those proposing changes should consider that ultimately consent may rest with th | Amir Taaki | Standard | Draft -|- +|- style="background-color: #cfffcf" | [[bip-0061.mediawiki|61]] -| "reject" P2P message +| Reject P2P message | Gavin Andresen | Standard | Final -|- +|- style="background-color: #ffcfcf" | [[bip-0062.mediawiki|62]] | Dealing with malleability | Pieter Wuille @@ -243,74 +243,80 @@ Those proposing changes should consider that ultimately consent may rest with th | BIP number allocated |- | [[bip-0064.mediawiki|64]] -| getutxos message +| getutxo message | Mike Hearn | Standard | Draft -|- +|- style="background-color: #ffffcf" | [[bip-0065.mediawiki|65]] | OP_CHECKLOCKTIMEVERIFY | Peter Todd | Standard | Accepted -|- +|- style="background-color: #cfffcf" | [[bip-0066.mediawiki|66]] | Strict DER signatures | Pieter Wuille | Standard -| Draft +| Final |- | [[bip-0067.mediawiki|67]] -| Deterministic P2SH multi-signature addresses -| Thomas Kerin +| Deterministic Pay-to-script-hash multi-signature addresses through public key sorting +| Thomas Kerin, Jean-Pierre Rupp, Ruben de Vries | Standard | Draft |- | [[bip-0068.mediawiki|68]] -| Relative lock-time through consensus-enforced sequence numbers -| Mark Friedenbach, BtcDrak, Nicolas Dorier +| Relative lock-time using consensus-enforced sequence numbers +| Mark Friedenbach, BtcDrak, Nicolas Dorier, kinoshitajona | Standard | Draft |- | [[bip-0069.mediawiki|69]] | Lexicographical Indexing of Transaction Inputs and Outputs | Kristov Atlas -| Standard +| Informational | Draft -|- +|- style="background-color: #cfffcf" | [[bip-0070.mediawiki|70]] -| Payment protocol -| Gavin Andresen +| Payment Protocol +| Gavin Andresen, Mike Hearn | Standard | Final -|- +|- style="background-color: #cfffcf" | [[bip-0071.mediawiki|71]] -| Payment protocol MIME types +| Payment Protocol MIME types | Gavin Andresen | Standard | Final -|- +|- style="background-color: #cfffcf" | [[bip-0072.mediawiki|72]] -| Payment protocol URIs +| bitcoin: uri extensions for Payment Protocol | Gavin Andresen | Standard | Final |- | [[bip-0073.mediawiki|73]] -| Use "Accept" header with Payment Request URLs +| Use "Accept" header for response type negotiation with Payment Request URLs | Stephen Pair | Standard | Draft |- +| [[bip-0074.mediawiki|74]] +| Allow zero value OP_RETURN in Payment Protocol +| Toby Padilla +| Standard +| Draft +|- | [[bip-0080.mediawiki|80]] | Hierarchy for Non-Colored Voting Pool Deterministic Multisig Wallets -| Monetas +| Justus Ranvier, Jimmy Song | Informational | Draft |- | [[bip-0081.mediawiki|81]] | Hierarchy for Colored Voting Pool Deterministic Multisig Wallets -| Monetas +| Justus Ranvier, Jimmy Song | Informational | Draft |- @@ -323,7 +329,7 @@ Those proposing changes should consider that ultimately consent may rest with th | [[bip-0099.mediawiki|99]] | Motivation and deployment of consensus rule changes ([soft/hard]forks) | Jorge Timón -| Informational / Process +| Informational | Draft |- | [[bip-0101.mediawiki|101]] @@ -370,7 +376,7 @@ Those proposing changes should consider that ultimately consent may rest with th |- | [[bip-0112.mediawiki|112]] | CHECKSEQUENCEVERIFY -| BtcDrak, Mark Friedenbach +| BtcDrak, Mark Friedenbach, Eric Lombrozo | Standard | Draft |- @@ -401,7 +407,7 @@ Those proposing changes should consider that ultimately consent may rest with th | [[bip-0123.mediawiki|123]] | BIP Classification | Eric Lombrozo -| Informational +| Process | Draft |- | [[bip-0124.mediawiki|124]] @@ -412,7 +418,7 @@ Those proposing changes should consider that ultimately consent may rest with th |- | [[bip-0125.mediawiki|125]] | Opt-in Full Replace-by-Fee Signaling -| David Harding, Peter Todd +| David A. Harding, Peter Todd | Standard | Draft |- diff --git a/bip-0001.mediawiki b/bip-0001.mediawiki index e1abadd..4f91a39 100644 --- a/bip-0001.mediawiki +++ b/bip-0001.mediawiki @@ -1,6 +1,7 @@ <pre> BIP: 1 Title: BIP Purpose and Guidelines + Author: Amir Taaki <genjix@riseup.net> Status: Active Type: Process Created: 2011-08-19 diff --git a/bip-0009.mediawiki b/bip-0009.mediawiki index b160810..78298f0 100644 --- a/bip-0009.mediawiki +++ b/bip-0009.mediawiki @@ -1,9 +1,12 @@ <pre> BIP: 9 Title: Version bits with timeout and delay - Author: Pieter Wuille <pieter.wuille@gmail.com>, Peter Todd <pete@petertodd.org>, Greg Maxwell <greg@xiph.org>, Rusty Russell <rusty@rustcorp.com.au> + Author: Pieter Wuille <pieter.wuille@gmail.com> + Peter Todd <pete@petertodd.org> + Greg Maxwell <greg@xiph.org> + Rusty Russell <rusty@rustcorp.com.au> Status: Draft - Type: Informational Track + Type: Informational Created: 2015-10-04 </pre> diff --git a/bip-0010.mediawiki b/bip-0010.mediawiki index 4307f3e..d15cd77 100644 --- a/bip-0010.mediawiki +++ b/bip-0010.mediawiki @@ -1,8 +1,8 @@ <pre> BIP: 10 Title: Multi-Sig Transaction Distribution - Author: Alan Reiner - Status: Withdrawn + Author: Alan Reiner <etotheipi@gmail.com> + Status: Withdrawn Type: Informational Created: 2011-10-28 </pre> diff --git a/bip-0014.mediawiki b/bip-0014.mediawiki index 111eb78..2cfb327 100644 --- a/bip-0014.mediawiki +++ b/bip-0014.mediawiki @@ -1,6 +1,6 @@ <pre> BIP: 14 - Title: BIP Protocol Version and User Agent + Title: Protocol Version and User Agent Author: Amir Taaki <genjix@riseup.net> Patrick Strateman <bitcoin-bips@covertinferno.org> Status: Accepted diff --git a/bip-0015.mediawiki b/bip-0015.mediawiki index c08498f..b90539d 100644 --- a/bip-0015.mediawiki +++ b/bip-0015.mediawiki @@ -1,6 +1,6 @@ <pre> BIP: 15 - Title: BIP Aliases + Title: Aliases Author: Amir Taaki <genjix@riseup.net> Status: Deferred Type: Standards Track diff --git a/bip-0021.mediawiki b/bip-0021.mediawiki index 2706926..00d9a53 100644 --- a/bip-0021.mediawiki +++ b/bip-0021.mediawiki @@ -56,7 +56,6 @@ The scheme component ("bitcoin:") is case-insensitive, and implementations must *address: bitcoin address *message: message that describes the transaction to the user ([[#Examples|see examples below]]) *size: amount of base bitcoin units ([[#Transfer amount/size|see below]]) -*paycode: payment code (BIP-47) *(others): optional, for future extensions ==== Transfer amount/size ==== @@ -68,11 +67,6 @@ I.e. amount=50.00 or amount=50 is treated as 50 BTC, and amount=50,000.00 is inv Bitcoin clients MAY display the amount in any format that is not intended to deceive the user. They SHOULD choose a format that is foremost least confusing, and only after that most reasonable given the amount requested. For example, so long as the majority of users work in BTC units, values should always be displayed in BTC by default, even if mBTC or TBC would otherwise be a more logical interpretation of the amount. - -==== Payment code ==== - -If a URI provides a payment code, and if the client supports BIP-47, then the resulting transaction SHOULD construct a transaction per BIP-47 instead of using the address provided in the URI. - == Rationale == ===Payment identifiers, not person identifiers=== @@ -128,6 +122,3 @@ Characters must be URI encoded properly. === Bitcoin clients === * Bitcoin-Qt supports the old version of Bitcoin URIs (ie without the req- prefix), with Windows and KDE integration as of commit 70f55355e29c8e45b607e782c5d76609d23cc858. -==References== - -* [[bip-0047.mediawiki|BIP47 - Reusable Payment Codes for Hierarchical Deterministic Wallets]] diff --git a/bip-0032.mediawiki b/bip-0032.mediawiki index ac0ed99..ec5ddf4 100644 --- a/bip-0032.mediawiki +++ b/bip-0032.mediawiki @@ -7,7 +7,7 @@ RECENT CHANGES: <pre> BIP: 32 Title: Hierarchical Deterministic Wallets - Author: Pieter Wuille + Author: Pieter Wuille <pieter.wuille@gmail.com> Status: Accepted Type: Informational Created: 2012-02-11 diff --git a/bip-0037.mediawiki b/bip-0037.mediawiki index 77b917b..224fef5 100644 --- a/bip-0037.mediawiki +++ b/bip-0037.mediawiki @@ -1,7 +1,8 @@ <pre> BIP: 37 Title: Connection Bloom filtering - Author: Mike Hearn <hearn@google.com>, Matt Corallo <bip@bluematt.me> + Author: Mike Hearn <hearn@google.com> + Matt Corallo <bip@bluematt.me> Status: Accepted Type: Standards Track Created: 2012-10-24 diff --git a/bip-0038.mediawiki b/bip-0038.mediawiki index 4fc3207..6107e0a 100644 --- a/bip-0038.mediawiki +++ b/bip-0038.mediawiki @@ -1,8 +1,8 @@ <pre> BIP: 38 Title: Passphrase-protected private key - Authors: Mike Caldwell - Aaron Voisine <voisine@gmail.com> + Author: Mike Caldwell <mcaldwell@swipeclock.com> + Aaron Voisine <voisine@gmail.com> Status: Draft (Some confusion applies: The announcements for this never made it to the list, so it hasn't had public discussion) Type: Standards Track Created: 2012-11-20 diff --git a/bip-0039.mediawiki b/bip-0039.mediawiki index da59124..c44ad3e 100644 --- a/bip-0039.mediawiki +++ b/bip-0039.mediawiki @@ -1,12 +1,12 @@ <pre> - BIP: BIP-0039 - Title: Mnemonic code for generating deterministic keys - Authors: Marek Palatinus <slush@satoshilabs.com> - Pavol Rusnak <stick@satoshilabs.com> - Aaron Voisine <voisine@gmail.com> - Sean Bowe <ewillbefull@gmail.com> - Status: Draft - Type: Standards Track + BIP: 39 + Title: Mnemonic code for generating deterministic keys + Author: Marek Palatinus <slush@satoshilabs.com> + Pavol Rusnak <stick@satoshilabs.com> + Aaron Voisine <voisine@gmail.com> + Sean Bowe <ewillbefull@gmail.com> + Status: Draft + Type: Standards Track Created: 2013-09-10 </pre> diff --git a/bip-0043.mediawiki b/bip-0043.mediawiki index 8f20fc8..4c57935 100644 --- a/bip-0043.mediawiki +++ b/bip-0043.mediawiki @@ -1,10 +1,10 @@ <pre> - BIP: BIP-0043 - Title: Purpose Field for Deterministic Wallets - Authors: Marek Palatinus <slush@satoshilabs.com> - Pavol Rusnak <stick@satoshilabs.com> - Status: Draft - Type: Standards Track + BIP: 43 + Title: Purpose Field for Deterministic Wallets + Author: Marek Palatinus <slush@satoshilabs.com> + Pavol Rusnak <stick@satoshilabs.com> + Status: Draft + Type: Standards Track Created: 2014-04-24 </pre> diff --git a/bip-0044.mediawiki b/bip-0044.mediawiki index f9d1254..6012ff5 100644 --- a/bip-0044.mediawiki +++ b/bip-0044.mediawiki @@ -1,10 +1,10 @@ <pre> - BIP: BIP-0044 - Title: Multi-Account Hierarchy for Deterministic Wallets - Authors: Marek Palatinus <slush@satoshilabs.com> - Pavol Rusnak <stick@satoshilabs.com> - Status: Draft - Type: Standards Track + BIP: 44 + Title: Multi-Account Hierarchy for Deterministic Wallets + Author: Marek Palatinus <slush@satoshilabs.com> + Pavol Rusnak <stick@satoshilabs.com> + Status: Draft + Type: Standards Track Created: 2014-04-24 </pre> @@ -149,10 +149,10 @@ All these constants are used as hardened derivation. This BIP is not a central directory for the registered coin types, please visit SatoshiLabs that maintains the full list: -[[http://doc.satoshilabs.com/slips/slip-0044.html|SLIP-0044 : Registered coin types for BIP-0044]] +[[https://github.com/satoshilabs/slips/blob/master/slip-0044.md|SLIP-0044 : Registered coin types for BIP-0044]] To register a new coin type, an existing wallet that implements the standard -is required. This can be done [[https://github.com/satoshilabs/docs/blob/master/slips/slip-0044.rst|here]]. +is required and a pull request to the above file should be created. ==Examples== diff --git a/bip-0045.mediawiki b/bip-0045.mediawiki index f93319d..1550467 100644 --- a/bip-0045.mediawiki +++ b/bip-0045.mediawiki @@ -1,11 +1,11 @@ <pre> - BIP: BIP-0045 - Title: Structure for Deterministic P2SH Multisignature Wallets - Authors: Manuel Araoz <manu@bitpay.com> - Ryan X. Charles <ryan@bitpay.com> - Matias Alejo Garcia <matias@bitpay.com> - Status: Draft - Type: Standards Track + BIP: 45 + Title: Structure for Deterministic P2SH Multisignature Wallets + Author: Manuel Araoz <manu@bitpay.com> + Ryan X. Charles <ryan@bitpay.com> + Matias Alejo Garcia <matias@bitpay.com> + Status: Draft + Type: Standards Track Created: 2014-04-25 </pre> diff --git a/bip-0047.mediawiki b/bip-0047.mediawiki index c3c5058..1a05730 100644 --- a/bip-0047.mediawiki +++ b/bip-0047.mediawiki @@ -1,17 +1,14 @@ RECENT CHANGES: - * (18 Dec 2015) Update explanations to resolve FAQs - * (12 Oct 2015) Revise blinding method for notification transactions - * (21 Sep 2015) Correct base58check version byte <pre> - BIP: 47 - Title: Reusable Payment Codes for Hierarchical Deterministic Wallets - Authors: Justus Ranvier <justus@openbitcoinprivacyproject.org> - Status: Draft - Type: Informational + BIP: 47 + Title: Reusable Payment Codes for Hierarchical Deterministic Wallets + Author: Justus Ranvier <justus@openbitcoinprivacyproject.org> + Status: Draft + Type: Informational Created: 2015-04-24 </pre> diff --git a/bip-0067.mediawiki b/bip-0067.mediawiki index 8be5c9b..d26df9c 100644 --- a/bip-0067.mediawiki +++ b/bip-0067.mediawiki @@ -1,8 +1,9 @@ - <pre> BIP: 67 Title: Deterministic Pay-to-script-hash multi-signature addresses through public key sorting - Author: Thomas Kerin, Jean-Pierre Rupp, Ruben de Vries + Author: Thomas Kerin <thomas@ribbit.me> + Jean-Pierre Rupp <root@haskoin.com> + Ruben de Vries <ruben@rubensayshi.com> Status: Draft Type: Standards Track Created: 2015-02-08 diff --git a/bip-0069.mediawiki b/bip-0069.mediawiki index e23ff04..0eca369 100644 --- a/bip-0069.mediawiki +++ b/bip-0069.mediawiki @@ -1,10 +1,10 @@ <pre> - BIP: BIP: 69 - Title: Lexicographical Indexing of Transaction Inputs and Outputs - Authors: Kristov Atlas <kristov@openbitcoinprivacyproject.org> - Editors: Daniel Cousens <bips@dcousens.com> - Status: Draft - Type: Informational + BIP: 69 + Title: Lexicographical Indexing of Transaction Inputs and Outputs + Author: Kristov Atlas <kristov@openbitcoinprivacyproject.org> + Editor: Daniel Cousens <bips@dcousens.com> + Status: Draft + Type: Informational Created: 2015-06-12 </pre> diff --git a/bip-0070.mediawiki b/bip-0070.mediawiki index 3642784..e3c17cf 100644 --- a/bip-0070.mediawiki +++ b/bip-0070.mediawiki @@ -1,7 +1,8 @@ <pre> BIP: 70 Title: Payment Protocol - Authors: Gavin Andresen <gavinandresen@gmail.com>, Mike Hearn <mhearn@bitcoinfoundation.org> + Author: Gavin Andresen <gavinandresen@gmail.com> + Mike Hearn <mhearn@bitcoinfoundation.org> Status: Final Type: Standards Track Created: 2013-07-29 diff --git a/bip-0074.mediawiki b/bip-0074.mediawiki new file mode 100644 index 0000000..a860b38 --- /dev/null +++ b/bip-0074.mediawiki @@ -0,0 +1,62 @@ +<pre> + BIP: 74 + Title: Allow zero value OP_RETURN in Payment Protocol + Author: Toby Padilla <tobypadilla@gmail.com> + Status: Draft + Type: Standards Track + Created: 2016-01-29 +</pre> + +==Abstract== + +This BIP alters the Payment Protocol to allow for zero value OP_RETURN outputs in serialized PaymentRequests. + +==Motivation== + +The Payment Protocol (defined in BIP70) gives merchants a way to build sophisticated transactions by serializing one or more outputs in the form of a PaymentRequest. The PaymentRequest is then served over http/https to a customer's wallet where the serialized transaction can be executed. + +While the Payment Protocol allows for any valid script in its outputs, it also ignores outputs with zero value. This means BIP70 implementations can encode an OP_RETURN script but must provide a greater than dust value for that output. The end result is a successful PaymentRequest transaction with an OP_RETURN but the value assigned to that output is lost forever. + +This BIP allows for zero value OP_RETURN outputs in serialized PaymentRequests. The change means that OP_RETURN scripts will work as they were originally intended from within PaymentRequests without permanently destroying Bitcoin value. Zero value non-OP_RETURN scripts should continue to be ignored. + +In addition to fixing the issue of destroyed value, this change opens up new use cases that were previously impossible. + +While storing data on the blockchain is controversial, when used responsibly OP_RETURN provides a powerful mechanism for attaching metadata to a transaction. This BIP effectively decouples the creation of transactions containing OP_RETURN data from the execution of those transactions. The result are positive benefits for both merchants and wallets/customers. + +By supporting this BIP, wallets can participate in current and future, unforeseen use cases that benefit from metadata stored in OP_RETURN. Until now OP_RETURN transactions have typically been created and submitted by custom software. If a wallet can process a PaymentRequest with OP_RETURN data as proposed by this BIP, it will support potentially sophisticated Bitcoin applications without the wallet developer having to have prior knowledge of that application. + +An example might be a merchant that adds the hash of a plain text invoice to the checkout transaction. The merchant could construct the PaymentRequest with the invoice hash in an OP_RETURN and pass it to the customer's wallet. The wallet could then submit the transaction, including the invoice hash from the PaymentRequest. The wallet will have encoded a proof of purchase to the blockchain without the wallet developer having to coordinate with the merchant software or add features beyond this BIP. + +Merchants and Bitcoin application developers benefit from this BIP because they can now construct transactions that include OP_RETURN data in a keyless environment. Again, prior to this BIP, transactions that used OP_RETURN (with zero value) needed to be constructed and executed in the same software. By separating the two concerns, this BIP allows merchant software to create transactions with OP_RETURN metadata on a server without storing public or private Bitcoin keys. This greatly enhances security where OP_RETURN applications currently need access to a private key to sign transactions. + +==Specification== + +The specification for this BIP is straightforward. BIP70 should be fully implemented with the following changes: + +* Outputs where the script is an OP_RETURN and the value is zero should be accepted by the wallet. + +BIP70 has special handling for the case with multiple zero value outputs: + +<blockquote> +If the sum of outputs.amount is zero, the customer will be asked how much to pay, and the bitcoin client may choose any or all of the Outputs (if there are more than one) for payment. If the sum of outputs.amount is non-zero, then the customer will be asked to pay the sum, and the payment shall be split among the Outputs with non-zero amounts (if there are more than one; Outputs with zero amounts shall be ignored). +</blockquote> + +This behavior should be retained with the exception of OP_RETURN handling. In the case of a multiple output transaction where the sum of the output values is zero, the user should be prompted for a value and that value should be distributed over any or all outputs ''except'' the OP_RETURN output. In the case where the sum of outputs.amount is non-zero then any OP_RETURN outputs should not be ignored but no value should be assigned to them. + +Payment requests also must contain at least one payable output (i.e. no payment requests with ''just'' an OP_RETURN). + +==Rationale== + +As with the discussion around vanilla OP_RETURN, the practice of storing data on the blockchain is controversial. While blockchain and network bloat is an undeniable issue, the benefits that come from attaching metadata to transactions has proven to be too powerful to dismiss entirely. In the absence of OP_RETURN support the Bitcoin ecosystem has seen alternative, less elegant and more wasteful methods employed for Blockchain data storage. + +As it exists today, BIP70 allows for OP_RETURN data storage at the expense of permanently destroyed Bitcoin. Even fully removing support for OP_RETURN values in the Payment Protocol would still leave the door open to suboptimal data encoding via burning a larger than dust value to an output with a false address designed to encode data. + +This BIP offers all of the same benefits that come from the OP_RETURN compromise. Mainly that OP_RETURN scripts are provably unspendable and thus can be pruned from the UTXO pool. Without supporting this BIP, wallets that support BIP70 will allow for wasteful data storage. + +==Compatibility== + +Since this BIP still supports OP_RETURN statements with a greater than zero value, it should be fully backwards compatible with any existing implementations. + +==Copyright== + +This document is placed in the public domain. diff --git a/bip-0080.mediawiki b/bip-0080.mediawiki index f28bb70..7c13a6e 100644 --- a/bip-0080.mediawiki +++ b/bip-0080.mediawiki @@ -1,10 +1,10 @@ <pre> - BIP: 80 - Title: Hierarchy for Non-Colored Voting Pool Deterministic Multisig Wallets - Authors: Justus Ranvier <justus@monetas.net> - Jimmy Song <jimmy@monetas.net> - Status: Draft - Type: Informational + BIP: 80 + Title: Hierarchy for Non-Colored Voting Pool Deterministic Multisig Wallets + Author: Justus Ranvier <justus@monetas.net> + Jimmy Song <jimmy@monetas.net> + Status: Draft + Type: Informational Created: 2014-08-11 </pre> diff --git a/bip-0081.mediawiki b/bip-0081.mediawiki index 5157c09..774166e 100644 --- a/bip-0081.mediawiki +++ b/bip-0081.mediawiki @@ -1,10 +1,10 @@ <pre> - BIP: 81 - Title: Hierarchy for Colored Voting Pool Deterministic Multisig Wallets - Authors: Justus Ranvier <justus@monetas.net> - Jimmy Song <jimmy@monetas.net> - Status: Draft - Type: Informational + BIP: 81 + Title: Hierarchy for Colored Voting Pool Deterministic Multisig Wallets + Author: Justus Ranvier <justus@monetas.net> + Jimmy Song <jimmy@monetas.net> + Status: Draft + Type: Informational Created: 2014-08-11 </pre> diff --git a/bip-0083.mediawiki b/bip-0083.mediawiki index d1da645..f6aa8e7 100644 --- a/bip-0083.mediawiki +++ b/bip-0083.mediawiki @@ -1,9 +1,9 @@ <pre> - BIP: BIP-83 - Title: Dynamic Hierarchical Deterministic Key Trees - Author: Eric Lombrozo <eric@ciphrex.com> - Status: Draft - Type: Standard + BIP: 83 + Title: Dynamic Hierarchical Deterministic Key Trees + Author: Eric Lombrozo <eric@ciphrex.com> + Status: Draft + Type: Standards Track Created: 2015-11-16 </pre> diff --git a/bip-0099.mediawiki b/bip-0099.mediawiki index b416e68..3e0a43a 100644 --- a/bip-0099.mediawiki +++ b/bip-0099.mediawiki @@ -3,7 +3,7 @@ Title: Motivation and deployment of consensus rule changes ([soft/hard]forks) Author: Jorge Timón <jtimon@jtimon.cc> Status: Draft - Type: Informational / Process + Type: Informational Created: 2015-06-20 Post-History: http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-June/008936.html </pre> diff --git a/bip-0107.mediawiki b/bip-0107.mediawiki index 4e96173..86edd99 100644 --- a/bip-0107.mediawiki +++ b/bip-0107.mediawiki @@ -1,7 +1,7 @@ <pre> BIP: 107 Title: Dynamic limit on the block size - Author: Dr Washington Y. Sanchez <washington.sanchez@gmail.com> + Author: Washington Y. Sanchez <washington.sanchez@gmail.com> Status: Draft Type: Standards Track Created: 2015-09-11 diff --git a/bip-0111.mediawiki b/bip-0111.mediawiki index d3bd630..e0ae9e8 100644 --- a/bip-0111.mediawiki +++ b/bip-0111.mediawiki @@ -1,7 +1,8 @@ <pre> BIP: 111 Title: NODE_BLOOM service bit - Author: Matt Corallo <bip@bluematt.me>, Peter Todd <pete@petertodd.org> + Author: Matt Corallo <bip@bluematt.me> + Peter Todd <pete@petertodd.org> Status: Draft Type: Standards Track Created: 2015-08-20 diff --git a/bip-0112.mediawiki b/bip-0112.mediawiki index 643c617..9c2d199 100644 --- a/bip-0112.mediawiki +++ b/bip-0112.mediawiki @@ -1,9 +1,9 @@ <pre> BIP: 112 Title: CHECKSEQUENCEVERIFY - Authors: BtcDrak <btcdrak@gmail.com> - Mark Friedenbach <mark@friedenbach.org> - Eric Lombrozo <elombrozo@gmail.com> + Author: BtcDrak <btcdrak@gmail.com> + Mark Friedenbach <mark@friedenbach.org> + Eric Lombrozo <elombrozo@gmail.com> Status: Draft Type: Standards Track Created: 2015-08-10 diff --git a/bip-0113.mediawiki b/bip-0113.mediawiki index 190fb4c..15fa4f3 100644 --- a/bip-0113.mediawiki +++ b/bip-0113.mediawiki @@ -2,7 +2,7 @@ BIP: 113 Title: Median time-past as endpoint for lock-time calculations Author: Thomas Kerin <me@thomaskerin.io> - Mark Friedenbach <mark@friedenbach.org> + Mark Friedenbach <mark@friedenbach.org> Status: Draft Type: Standards Track Created: 2015-08-10 diff --git a/bip-0122.mediawiki b/bip-0122.mediawiki index 17003aa..5386dd2 100644 --- a/bip-0122.mediawiki +++ b/bip-0122.mediawiki @@ -4,7 +4,7 @@ Author: Marco Pontello <marcopon@gmail.com> Status: Draft Type: Standards Track - Created: 29 August 2015 + Created: 2015-08-29 Post-History: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/010712.html </pre> diff --git a/bip-0123.mediawiki b/bip-0123.mediawiki index 776529a..3d40326 100644 --- a/bip-0123.mediawiki +++ b/bip-0123.mediawiki @@ -2,7 +2,7 @@ BIP: 123 Layer: Process Title: BIP Classification - Author: Eric Lombrozo + Author: Eric Lombrozo <elombrozo@gmail.com> Status: Draft Type: Process Created: 2015-08-26 @@ -82,6 +82,13 @@ The applications layer specifies high level structures, abstractions, and conven | Standard | Active |- +| [[bip-0009.mediawiki|9]] +| Consensus (soft fork) +| Version bits with timeout and delay +| Pieter Wuille, Peter Todd, Greg Maxwell, Rusty Russell +| Informational +| Draft +|- | [[bip-0010.mediawiki|10]] | Applications | Multi-Sig Transaction Distribution @@ -391,11 +398,186 @@ The applications layer specifies high level structures, abstractions, and conven | Standard | Draft |- +| [[bip-0080.mediawiki|80]] +| Applications +| Hierarchy for Non-Colored Voting Pool Deterministic Multisig Wallets +| Monetas +| Informational +| Draft +|- +| [[bip-0083.mediawiki|83]] +| Applications +| Dynamic Hierarchical Deterministic Key Trees +| Eric Lombrozo +| Standard +| Draft +|- +| [[bip-0099.mediawiki|99]] +| Informational +| Motivation and deployment of consensus rule changes ([soft/hard]forks) +| Jorge Timón +| Informational / Process +| Draft +|- | [[bip-0101.mediawiki|101]] | Consensus (hard fork) | Increase maximum block size | Gavin Andresen | Standard | Draft +|- +| [[bip-0102.mediawiki|102]] +| Consensus (hard fork) +| Block size increase to 2MB +| Jeff Garzik +| Standard +| Draft +|- +| [[bip-0103.mediawiki|103]] +| Consensus (hard fork) +| Block size following technological growth +| Pieter Wuille +| Standard +| Draft +|- +| [[bip-0105.mediawiki|105]] +| Consensus (hard fork) +| Consensus based block size retargetting algorithm +| BtcDrak +| Standard +| Draft +|- +| [[bip-0106.mediawiki|106]] +| Consensus (hard fork) +| Dynamically Controlled Bitcoin Block Size Max Cap +| Upal Chakraborty +| Standard +| Draft +|- +| [[bip-0107.mediawiki|107]] +| Consensus (hard fork) +| Dynamic limit on the block size +| Washington Y. Sanchez +| Standard +| Draft +|- +| [[bip-0111.mediawiki|111]] +| Peer Services +| NODE_BLOOM service bit +| Matt Corallo, Peter Todd +| Standard +| Draft +|- +| [[bip-0112.mediawiki|112]] +| Consensus (soft fork) +| CHECKSEQUENCEVERIFY +| BtcDrak, Mark Friedenbach, Eric Lombrozo +| Standard +| Draft +|- +| [[bip-0113.mediawiki|113]] +| Consensus (soft fork) +| Median time-past as endpoint for locktime calculations +| Thomas Kerin, Mark Friedenbach +| Standard +| Draft +|- +| [[bip-0120.mediawiki|120]] +| Applications +| Proof of Payment +| Kalle Rosenbaum +| Standard +| Draft +|- +| [[bip-0121.mediawiki|121]] +| Applications +| Proof of Payment URI scheme +| Kalle Rosenbaum +| Standard +| Draft +|- +| [[bip-0122.mediawiki|122]] +| Applications +| URI scheme for Blockchain references / exploration +| Marco Pontello +| Standard +| Draft +|- +| [[bip-0123.mediawiki|123]] +| Process +| BIP Classification +| Eric Lombrozo +| Standard +| Draft +|- +| [[bip-0124.mediawiki|124]] +| Applications +| Hierarchical Deterministic Script Templates +| Eric Lombrozo, William Swanson +| Standard +| Draft +|- +| [[bip-0125.mediawiki|125]] +| Peer Services +| Opt-in Full Replace-by-Fee Signaling +| David Harding, Peter Todd +| Standard +| Draft +|- +| [[bip-0130.mediawiki|130]] +| Peer Services +| sendheaders message +| Suhas Daftuar +| Standard +| Draft +|- +| [[bip-0131.mediawiki|131]] +| Consensus (hard fork) +| "Coalescing Transaction" Specification (wildcard inputs) +| Chris Priest +| Standard +| Draft +|- +| [[bip-0132.mediawiki|132]] +| Process +| Committee-based BIP Acceptance Process +| Andy Chase +| Process +| Draft +|- +| [[bip-0140.mediawiki|140]] +| Consensus (soft fork) +| Normalized TXID +| Christian Decker +| Standard +| Draft +|- +| [[bip-0141.mediawiki|141]] +| Consensus (soft fork) +| Segregated Witness (Consensus layer) +| Eric Lombrozo, Johnson Lau, Pieter Wuille +| Standard +| Draft +|- +| [[bip-0142.mediawiki|142]] +| Applications +| Address Format for Segregated Witness +| Johnson Lau +| Standard +| Draft +|- +| [[bip-0143.mediawiki|143]] +| Consensus (soft fork) +| Transaction Signature Verification for Version 0 Witness Program +| Johnson Lau, Pieter Wuille +| Standard +| Draft +|- +| [[bip-0144.mediawiki|144]] +| Peer Services +| Segregated Witness (Peer Services) +| Eric Lombrozo, Pieter Wuille +| Standard +| Draft |} diff --git a/bip-0124.mediawiki b/bip-0124.mediawiki index 1c98db8..2f9f4ad 100644 --- a/bip-0124.mediawiki +++ b/bip-0124.mediawiki @@ -1,11 +1,11 @@ <pre> - BIP: BIP-124 - Title: Hierarchical Deterministic Script Templates - Authors: Eric Lombrozo <eric@ciphrex.com>, William Swanson - Status: Draft - Type: Informational + BIP: 124 + Title: Hierarchical Deterministic Script Templates + Author: Eric Lombrozo <eric@ciphrex.com> + William Swanson <swansontec@gmail.com> + Status: Draft + Type: Informational Created: 2015-11-20 - Post-History: http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-November/011795.html </pre> diff --git a/bip-0125.mediawiki b/bip-0125.mediawiki index 63788e9..7d88469 100644 --- a/bip-0125.mediawiki +++ b/bip-0125.mediawiki @@ -1,7 +1,8 @@ <pre> BIP: 125 Title: Opt-in Full Replace-by-Fee Signaling - Author: David A. Harding <dave@dtrt.org>, Peter Todd <pete@petertodd.org> + Author: David A. Harding <dave@dtrt.org> + Peter Todd <pete@petertodd.org> Status: Draft Type: Standards Track Created: 2015-12-04 diff --git a/bip-0132.mediawiki b/bip-0132.mediawiki index 814e20a..90c09b1 100644 --- a/bip-0132.mediawiki +++ b/bip-0132.mediawiki @@ -1,7 +1,7 @@ <pre> BIP: 132 Title: Committee-based BIP Acceptance Process - Author: Andy Chase + Author: Andy Chase <theandychase@gmail.com> Status: Draft Type: Process Created: 2015-08-31 diff --git a/bip-0141.mediawiki b/bip-0141.mediawiki index b62d54d..a73cf35 100644 --- a/bip-0141.mediawiki +++ b/bip-0141.mediawiki @@ -52,7 +52,7 @@ The <code>marker</code> MUST be <code>0x00</code>. The <code>flag</code> MUST be a 1-byte non-zero value. Currently, <code>0x01</code> MUST be used. -The <code>witness</code> is a serialization of all witness data of the transaction. Each txin is associated with a witness field. A witness field starts with a <code>var_int</code> to indicate the number of stack items for the txin. It is followed by stack items, with each item starts with a <code>var_int</code> to indicate the length. Witness data is NOT script and is not restricted by the 520-byte push limit. +The <code>witness</code> is a serialization of all witness data of the transaction. Each txin is associated with a witness field. A witness field starts with a <code>var_int</code> to indicate the number of stack items for the txin. It is followed by stack items, with each item starts with a <code>var_int</code> to indicate the length. Witness data is NOT script. A non-witness program (defined hereinafter) txin MUST be associated with an empty witness field, represented by a <code>0x00</code>. If all txins are not witness program, a transaction's <code>wtxid</code> is equal to its <code>txid</code>. @@ -85,20 +85,20 @@ There are two cases in which witness validation logic are triggered. Each case d If the version byte is 0, and the witness program is 20 bytes: * It is interpreted as a pay-to-witness-public-key-hash (P2WPKH) program. -* The witness must consist of exactly 2 items. The first one a signature, and the second one a public key. +* The witness must consist of exactly 2 items (≤ 520 bytes each). The first one a signature, and the second one a public key. * The HASH160 of the public key must match the 20-byte witness program. * After normal script evaluation, the signature is verified against the public key with CHECKSIG operation. The verification must result in a single TRUE on the stack. If the version byte is 0, and the witness program is 32 bytes: * It is interpreted as a pay-to-witness-script-hash (P2WSH) program. * The witness must consist of an input stack to feed to the script, followed by a serialized script ("witnessScript"). -* The witnessScript is popped off the initial witness stack. SHA256 of the witnessScript must match the 32-byte witness program. -* The witnessScript is deserialized, and executed after normal script evaluation with the remaining witness stack. +* The witnessScript (≤ 10,000 bytes) is popped off the initial witness stack. SHA256 of the witnessScript must match the 32-byte witness program. +* The witnessScript is deserialized, and executed after normal script evaluation with the remaining witness stack (≤ 520 bytes for each stack item). * The script must not fail, and result in exactly a single TRUE on the stack. If the version byte is 0, but the witness program is neither 20 nor 32 bytes, the script must fail. -If the version byte is 1 to 16, no further interpretation of the witness program or witness happens. +If the version byte is 1 to 16, no further interpretation of the witness program or witness happens, and there is no size restriction for the witness. These versions are reserved for future extensions. === Other consensus critical limits === @@ -114,7 +114,7 @@ The new rule is total ''block cost'' ≤ 4,000,000. Sigops per block is currently limited to 20,000. We change this restriction as follows: -''Sigop cost'' is defined. The cost of a sigop in traditoinal script is 4, while the cost of a sigop in witness program is 1. +''Sigop cost'' is defined. The cost of a sigop in traditional script is 4, while the cost of a sigop in witness program is 1. The new rule is total ''sigop cost'' ≤ 80,000. diff --git a/bip-0144.mediawiki b/bip-0144.mediawiki index 9b2422b..2da222c 100644 --- a/bip-0144.mediawiki +++ b/bip-0144.mediawiki @@ -5,7 +5,7 @@ Pieter Wuille <pieter.wuille@gmail.com> Status: Draft Type: Standards Track - Created: 2015-12 + Created: 2016-01-08 </pre> ==Abstract== |