highperfocused/bips
1
0
Fork 0
mirror of https://github.com/bitcoin/bips.git synced 2025-03-17 21:32:50 +01:00
Code Issues Packages Projects Releases Wiki Activity

Merge branch 'master' into 20160201_status_updates_d2f

Browse Source
This commit is contained in:
Luke Dashjr 2016-02-24 05:30:41 +00:00
commit 50aa85ee73
50 changed files with 2801 additions and 190 deletions

7
.travis.yml Normal file

@ -0,0 +1,7 @@
os: linux
language: generic
sudo: false
script:
- scripts/buildtable.pl >/tmp/table.mediawiki || exit 1
- diff README.mediawiki /tmp/table.mediawiki | grep '^[<>] |' >/tmp/after.diff || true
- if git checkout HEAD^ && scripts/buildtable.pl >/tmp/table.mediawiki 2>/dev/null; then diff README.mediawiki /tmp/table.mediawiki | grep '^[<>] |' >/tmp/before.diff || true; newdiff=$(diff -s /tmp/before.diff /tmp/after.diff -u | grep '^+'); if [ -n "$newdiff" ]; then echo "$newdiff"; exit 1; fi; else echo 'Cannot build previous commit table for comparison'; fi

124
README.mediawiki

@ -19,12 +19,18 @@ Those proposing changes should consider that ultimately consent may rest with th
| Process
| Active
|-
| [[bip-0002.mediawiki|2]]
| BIP Status and Comments
| Luke Dashjr
| Process
| Draft
|-
| [[bip-0009.mediawiki|9]]
| Version bits with timeout and delay
| Pieter Wuille, Peter Todd, Greg Maxwell, Rusty Russell
| Informational
| Draft
|-
|- style="background-color: #ffcfcf"
| [[bip-0010.mediawiki|10]]
| Multi-Sig Transaction Distribution
| Alan Reiner
@ -35,7 +41,7 @@ Those proposing changes should consider that ultimately consent may rest with th
| M-of-N Standard Transactions
| Gavin Andresen
| Standard
| Accepted
| Final
|- style="background-color: #ffcfcf"
| [[bip-0012.mediawiki|12]]
| OP_EVAL
@ -53,8 +59,8 @@ Those proposing changes should consider that ultimately consent may rest with th
| Protocol Version and User Agent
| Amir Taaki, Patrick Strateman
| Standard
| Accepted
|- style="background-color: #ffcfcf"
| Final
|-
| [[bip-0015.mediawiki|15]]
| Aliases
| Amir Taaki
@ -62,7 +68,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
@ -95,19 +101,19 @@ Those proposing changes should consider that ultimately consent may rest with th
| URI Scheme
| Nils Schneider, Matt Corallo
| Standard
| Accepted
| Final
|- style="background-color: #cfffcf"
| [[bip-0022.mediawiki|22]]
| getblocktemplate - Fundamentals
| Luke Dashjr
| Standard
| Accepted
| Final
|- style="background-color: #cfffcf"
| [[bip-0023.mediawiki|23]]
| getblocktemplate - Pooled Mining
| Luke Dashjr
| Standard
| Accepted
| Final
|- style="background-color: #cfffcf"
| [[bip-0030.mediawiki|30]]
| Duplicate transactions
@ -119,13 +125,13 @@ Those proposing changes should consider that ultimately consent may rest with th
| Pong message
| Mike Hearn
| Standard
| Accepted
| Final
|- style="background-color: #cfffcf"
| [[bip-0032.mediawiki|32]]
| Hierarchical Deterministic Wallets
| Pieter Wuille
| Informational
| Accepted
| Final
|-
| [[bip-0033.mediawiki|33]]
| Stratized Nodes
@ -134,16 +140,16 @@ Those proposing changes should consider that ultimately consent may rest with th
| Draft
|- style="background-color: #cfffcf"
| [[bip-0034.mediawiki|34]]
| Block v2, Height in coinbase
| Block v2, Height in Coinbase
| Gavin Andresen
| Standard
| Accepted
| Final
|- style="background-color: #cfffcf"
| [[bip-0035.mediawiki|35]]
| mempool message
| Jeff Garzik
| Standard
| Accepted
| Final
|-
| [[bip-0036.mediawiki|36]]
| Custom Services
@ -152,32 +158,32 @@ Those proposing changes should consider that ultimately consent may rest with th
| Draft
|- style="background-color: #cfffcf"
| [[bip-0037.mediawiki|37]]
| Bloom filtering
| Connection Bloom filtering
| Mike Hearn, Matt Corallo
| Standard
| Accepted
| Final
|-
| [[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 +195,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
|-
@ -210,7 +216,7 @@ Those proposing changes should consider that ultimately consent may rest with th
| Justus Ranvier
| Informational
| Draft
|-
|- style="background-color: #cfffcf"
| [[bip-0050.mediawiki|50]]
| March 2013 Chain Fork Post-Mortem
| Gavin Andresen
@ -223,13 +229,13 @@ Those proposing changes should consider that ultimately consent may rest with th
| Amir Taaki
| Standard
| Final
|-
|- 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,17 +249,17 @@ 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
| Final
|-
|- style="background-color: #cfffcf"
| [[bip-0065.mediawiki|65]]
| OP_CHECKLOCKTIMEVERIFY
| Peter Todd
| Standard
| Accepted
|-
| Final
|- style="background-color: #cfffcf"
| [[bip-0066.mediawiki|66]]
| Strict DER signatures
| Pieter Wuille
@ -261,62 +267,62 @@ Those proposing changes should consider that ultimately consent may rest with th
| 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
|-
|- style="background-color: #cfffcf"
| [[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
| Final
|-
| [[bip-0074.mediawiki|74]]
| Support zero value OP_RETURN in Payment Requests
| 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
|-
@ -329,14 +335,14 @@ 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
|-
|- style="background-color: #ffcfcf"
| [[bip-0101.mediawiki|101]]
| Increase maximum block size
| Gavin Andresen
| Standard
| Draft
| Withdrawn
|-
| [[bip-0102.mediawiki|102]]
| Block size increase to 2MB
@ -368,6 +374,12 @@ Those proposing changes should consider that ultimately consent may rest with th
| Standard
| Draft
|-
| [[bip-0109.mediawiki|109]]
| Two million byte size limit with sigop and sighash limits
| Gavin Andresen
| Standard
| Draft
|-
| [[bip-0111.mediawiki|111]]
| NODE_BLOOM service bit
| Matt Corallo, Peter Todd
@ -376,7 +388,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
|-
@ -407,7 +419,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]]
@ -418,7 +430,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
|-
@ -469,6 +481,12 @@ Those proposing changes should consider that ultimately consent may rest with th
| Eric Lombrozo, Pieter Wuille
| Standard
| Draft
|-
| [[bip-0145.mediawiki|145]]
| getblocktemplate Updates for Segregated Witness
| Luke Dashjr
| Standard
| Draft
|}
<!-- IMPORTANT! See the instructions at the top of this page, do NOT JUST add BIPs here! -->

1
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

179
bip-0002.mediawiki Normal file

@ -0,0 +1,179 @@
<pre>
BIP: 2
Title: BIP Status and Comments
Author: Luke Dashjr <luke+bip@dashjr.org>
Status: Draft
Type: Process
Created: 2016-02-03
</pre>
==Abstract==
This BIP describes objective criteria that can be used to determine when a BIP Status should be changed, to ensure it is a reliable metric documenting actual usage of the proposal. It also adds a way for final comment on completed BIPs, by adding to them a reference to a wiki page and summary of the tone thereof. Finally, it extends the list of allowable BIP licenses to include many more popular options.
==Copyright==
This BIP is dual-licensed under the Open Publication License and BSD 2-clause license.
==BIP status field==
===Specification===
Champions of a BIP may decide on their own to change the status between Draft, Deferred, or Withdrawn.
A BIP may only change status from Draft (or Rejected) to Accepted, when the author deems it is complete, has a working implementation (where applicable), and has community plans to progress it to the Final status.
BIPs should be changed from Draft or Accepted status, to Rejected status, upon request by any person, if they have not made progress in three years. Such a BIP may be changed to Draft status if the champion provides revisions that meaningfully address public criticism of the proposal, or to Accepted status if it meets the criteria required as described in the previous paragraph.
An Accepted BIP may progress to Final only when specific criteria reflecting real-world adoption has occurred. This is different for each BIP depending on the nature of its proposed changes, which will be expanded on below. Evaluation of this status change should be objectively verifiable, and/or be discussed on the development mailing list.
When a Final BIP is no longer relevant, its status may be changed to Replaced or Obsolete (which is equivalent to Replaced). This change must also be objectively verifiable and/or discussed.
A process BIP may change status from Draft to Active when it achieves rough consensus on the mailing list. Such a proposal is said to have rough consensus if it has been open to discussion on the development mailing list for at least one month, and no person maintains any unaddressed substantiated objections to it. Addressed or obstructive objections may be ignored/overruled by general agreement that they have been sufficiently addressed, but clear reasoning must be given in such circumstances.
====Progression to Final status====
See [[bip-0123.mediawiki|BIP 123]] for definitions of the various BIP layers. Activation of this BIP implies activation of BIP 123.
A soft-fork BIP strictly requires a clear miner majority expressed by blockchain voting (eg, using BIP 9). In addition, if the economy seems willing to make a "no confidence" hard-fork (such as a change in proof-of-work algorithm), the soft-fork does not become Final for as long as such a hard-fork has potentially-majority support, or at most three months. Soft-fork BIPs may also set additional requirements for their adoption. Because of the possibility of changes to miner dynamics, especially in light of delegated voting (mining pools), it is highly recommended that a supermajority vote around 95% be required by the BIP itself, unless rationale is given for a lower threshold.
A hard-fork BIP requires adoption from the entire Bitcoin economy, particularly including those selling desirable goods and services in exchange for bitcoin payments, as well as Bitcoin holders who wish to spend or would spend their bitcoins (including selling for other currencies) differently in the event of such a hard-fork. Adoption must be expressed by de facto usage of the hard-fork in practice (ie, not merely expressing public support, although that is a good step to establish agreement before adoption of the BIP). This economic adoption cannot be established merely by a super-majority, except by literally forcing the minority to accept the hard-fork (whether this is viable or not is outside the scope of this document).
Peer services BIPs should be observed to be adopted by at least 1% of public listening nodes for one month.
API/RPC and application layer BIPs must be implemented by at least two independent and compatible software applications.
Software authors are encouraged to publish summaries of what BIPs their software supports to aid in verification of status changes. Good examples of this at the time of writing this BIP, can be observed in [https://github.com/bitcoin/bitcoin/blob/master/doc/bips.md Bitcoin Core's doc/bips.md file] as well as [https://github.com/schildbach/bitcoin-wallet/blob/master/wallet/README.specs Bitcoin Wallet for Android's wallet/README.specs file].
These criteria are considered objective ways to observe the de facto adoption of the BIP, and are not to be used as reasons to oppose or reject a BIP. Should a BIP become actually and unambiguously adopted despite not meeting the criteria outlined here, it should still be updated to Final status.
===Rationale===
Why is this necessary at all?
* BIP 1 defines an ambiguous criteria for the Status field of BIPs, which is often a source of confusion. As a result, many BIPs with significant real-world use have been left as Draft or Accepted status longer than appropriate. By giving objective criteria to judge the progression of BIPs, this proposal aims to help keep the Status accurate and up-to-date.
How is the entire Bitcoin economy defined by people selling goods/services and holders?
* For Bitcoin to function as a currency, it must be accepted as payment. Bitcoins have no value if you cannot acquire anything in exchange for them. If everyone accepting such payments requires a particular set of consensus rules, "bitcoins" are de facto defined by that set of rules - this is already the case today. If those consensus rules are expected to broaden (as with a hard-fork), those merchants need to accept payments made under the new set of rules, or they will reject "bitcoins" as invalid. Holders are relevant to the degree in that they choose the merchants they wish to spend their bitcoins with, and could also as a whole decide to sell under one set of consensus rules or the other, thus flooding the market with bitcoins and crashing the price.
Why aren't <x> included in the economy?
* Some entities may, to some degree, also be involved in offering goods and/or services in exchange for bitcoins, thus in that capacity (but not their capacity as <x>) be involved in the economy.
* Miners are not included in the economy, because they merely *rely on* others to sell/spend their otherwise-worthless mined produce. Therefore, they must accept everyone else's direction in deciding the consensus rules.
* Exchanges are not included in the economy, because they merely provide services of connecting the merchants and users who wish to trade. Even if all exchanges were to defect from Bitcoin, those merchants and users can always trade directly and/or establish their own exchanges.
* Developers are not included in the economy, since they merely write code, and it is up to others to decide to use that code or not.
But they're doing something important and have invested a lot in Bitcoin! Shouldn't they be included in such an important decision?
* This BIP does not aim to address what "should" be the basis of decisions. Such a statement, no matter how perfect in its justification, would be futile without some way to force others to use it. The BIP process does not aim to be a kind of forceful "governance" of Bitcoin, merely to provide a collaborative repository for proposing and providing information on standards, which people may voluntarily adopt or not. It can only hope to achieve accuracy in regard to the "Status" field by striving to reflect the reality of *how things actually are*, rather than *how they should be*.
How can economic agreement veto a soft-fork?
* The group of miners is determined by the consensus rules for the dynamic-membership multi-party signature (for Bitcoin, the proof-of-work algorithm), which can be modified with a hard-fork. Thus, if the same conditions required to modify this group are met in opposition to a soft-fork, the miner majority supporting the soft-fork is effectively void because the economy can decide to replace them with another group of would-be miners who do not support the soft-fork.
What happens if the economy decides to hard-fork away from a controversial soft-fork, more than three months later?
* The controversial soft-fork, in this circumstance, changes from Final to Replaced status to reflect the nature of the hard-fork replacing the previous (final) soft-fork.
What is the ideal percentage of listening nodes needed to adopt peer services proposals?
* This is unknown, and set rather arbitrarily at this time. For a random selection of peers to have at least one other peer implementing the extension, 13% or more would be necessary, but nodes could continue to scan the network for such peers with perhaps some reasonable success. Furthermore, service bits exist to help identification upfront.
Why is it necessary for at least two software projects to release an implementation of API/RPC and application layer BIPs, before they become Final?
* If there is only one implementation of a specification, there is no other program for which a standard interface is used with or needed.
* Even if there are only two projects rather than more, some standard coordination between them exists.
What if a BIP is proposed that only makes sense for a single specific project?
* The BIP process exists for standardisation between independent projects. If something only affects one project, it should be done through that project's own internal processes, and never be proposed as a BIP in the first place.
==BIP comments==
===Specification===
Each BIP should, in its preamble, link to a Bitcoin Wiki page with a summary tone of the comments on that page.
Reviewers of the BIP who consider themselves qualified, should post their own comments on this wiki page in [https://www.mediawiki.org/wiki/Help:Talk_pages#Editing_conventions_on_talk_pages standard "Talk page" format].
The comments page should generally only be used to post final comments for a completed BIP.
If a BIP is not yet completed, reviewers should instead post on the applicable development mailing list thread to allow the BIP author(s) to address any concerns or problems pointed out by the review.
Some BIPs receive exposure outside the development community prior to completion, and other BIPs might not be completed at all. To avoid a situation where critical BIP reviews may go unnoticed during this period, reviewers may, at their option, still post their review on the comments page, provided they first post it to the mailing list and plan to later remove or revise it as applicable based on the completed version. Such revisions should be made by editing the previous review and updating the timestamp. Reviews made prior to the complete version may be removed if they are no longer applicable and have not been updated in a timely manner (eg, within one month).
Pages must be named after the full BIP number (eg, "BIP 0001") and placed in the "BIP Comments" namespace. For example, the link for BIP 1 will be https://en.bitcoin.it/wiki/BIP_Comments:BIP_0001 .
In order to avoid possible abuse of Bitcoin Wiki moderation, BIPs may choose to list a second forum for BIP comments, in addition to the Bitcoin Wiki. In this case, the second forum's URI should be listed below the Bitcoin Wiki's URI.
Summary tones may be chosen from the following, but this BIP does not intend to cover all possible nuances:
* No comments yet.
* Unanimously Recommended for implementation
* Unanimously Discourage for implementation
* Mostly Recommended for implementation, with some Discouragement
* Mostly Discouraged for implementation, with some Recommendation
For example, the preamble to BIP 1 might be updated to include the line:
Comments-Summary: No comments yet.
Comments-URI: https://en.bitcoin.it/wiki/BIP_Comments:BIP_0001
https://some-other-wiki.org/BIP_1_Comments
To avoid doubt: comments and status are unrelated metrics to judge a BIP, and neither should be directly influencing the other.
===Rationale===
What is the purpose of BIP comments?
* Various BIPs have been adopted (the criteria required for "Final" Status) despite being considered generally inadvisable. Some presently regard BIPs as a "good idea" simply by virtue of them being assigned a BIP number. Due to the low barrier of entry for submission of new BIPs, it seems advisable for a way for reviewers to express their opinions on them in a way that is consumable to the public without needing to review the entire development discussion.
Will BIP comments be censored or limited to particular participants/"experts"?
* The Bitcoin Wiki moderators have control over that venue and may make reasonable moderation attempts. Admitted non-experts should refrain from commenting outside of their area of knowledge. However, comments should not be censored, and participation should be open to the public.
* If the Bitcoin Wiki were to abuse its position, the venue for comments can always be changed.
==BIP licensing==
New BIPs may be accepted with the following licenses:
===Specification===
====Recommended licenses====
* [https://opensource.org/licenses/BSD-2-Clause OSI-approved BSD 2-clause license]
* [https://opensource.org/licenses/BSD-3-Clause OSI-approved BSD 3-clause license]
* [https://creativecommons.org/publicdomain/zero/1.0/ Creative Commons CC0 1.0 Universal]
* [http://www.gnu.org/prep/maintain/html_node/License-Notices-for-Other-Files.html GNU All-Permissive License]
In addition, it is recommended that literal code included in the BIP be dual-licensed under the same license terms as the project it modifies. For example, literal code intended for Bitcoin Core would ideally be dual-licensed under the MIT license terms as well as one of the above with the rest of the BIP text.
====Not recommended, but acceptable licenses====
* [http://www.apache.org/licenses/LICENSE-2.0 Apache License, version 2.0]
* [http://www.boost.org/LICENSE_1_0.txt Boost Software License, version 1.0]
* [https://creativecommons.org/licenses/by/4.0/ Creative Commons Attribution 4.0 International]
* [https://creativecommons.org/licenses/by-sa/4.0/ Creative Commons Attribution-ShareAlike 4.0 International]
* [https://opensource.org/licenses/MIT Expat/MIT/X11 license]
* [http://www.gnu.org/licenses/agpl-3.0.en.html GNU Affero General Public License (AGPL), version 3 or newer]
* [http://www.gnu.org/licenses/fdl-1.3.en.html GNU Free Documentation License]
* [http://www.gnu.org/licenses/old-licenses/gpl-2.0.en.html GNU General Public License (GPL), version 2 or newer]
* [http://www.gnu.org/licenses/old-licenses/lgpl-2.1.en.html GNU Lesser General Public License (LGPL), version 2.1 or newer]
* [http://opencontent.org/openpub/ Open Publication License, version 1.0]
===Rationale===
BIP 1 allowed the Open Publication License or releasing into the public domain; was this insufficient?
* The OPL is generally regarded as obsolete, and not a license suitable for new publications.
* Many are unfamiliar with the OPL terms, and may just prefer to use the public domain rather than license under uncertain terms.
* Public domain is not universally recognised as a legitimate action, thus it is inadvisable.
Why are there software licenses included?
* Some BIPs, especially consensus layer, may include literal code in the BIP itself which may not be available under the exact license terms of the BIP.
* Despite this, not all software licenses would be acceptable for content included in BIPs.
==See Also==
* [[bip-0001.mediawiki|BIP 1: BIP Purpose and Guidelines]]
* [[bip-0123.mediawiki|BIP 123: BIP Classification]]
* [https://tools.ietf.org/html/rfc7282 RBF 7282: On Consensus and Humming in the IETF]

7
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>

4
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>

2
bip-0011.mediawiki

@ -2,7 +2,7 @@
BIP: 11
Title: M-of-N Standard Transactions
Author: Gavin Andresen <gavinandresen@gmail.com>
Status: Accepted
Status: Final
Type: Standards Track
Created: 2011-10-18
Post-History: 2011-10-02

4
bip-0014.mediawiki

@ -1,9 +1,9 @@
<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
Status: Final
Type: Standards Track
Created: 2011-11-10
Post-History: 2011-11-02

2
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

2
bip-0021.mediawiki

@ -3,7 +3,7 @@
Title: URI Scheme
Author: Nils Schneider <nils.schneider@gmail.com>
Matt Corallo <bip21@bluematt.me>
Status: Accepted
Status: Final
Type: Standards Track
Created: 2012-01-29
</pre>

2
bip-0022.mediawiki

@ -2,7 +2,7 @@
BIP: 22
Title: getblocktemplate - Fundamentals
Author: Luke Dashjr <luke+bip22@dashjr.org>
Status: Accepted
Status: Final
Type: Standards Track
Created: 2012-02-28
</pre>

2
bip-0023.mediawiki

@ -2,7 +2,7 @@
BIP: 23
Title: getblocktemplate - Pooled Mining
Author: Luke Dashjr <luke+bip22@dashjr.org>
Status: Accepted
Status: Final
Type: Standards Track
Created: 2012-02-28
</pre>

2
bip-0031.mediawiki

@ -2,7 +2,7 @@
BIP: 31
Title: Pong message
Author: Mike Hearn <hearn@google.com>
Status: Accepted
Status: Final
Type: Standards Track
Created: 2012-04-11
</pre>

4
bip-0032.mediawiki

@ -7,8 +7,8 @@ RECENT CHANGES:
<pre>
BIP: 32
Title: Hierarchical Deterministic Wallets
Author: Pieter Wuille
Status: Accepted
Author: Pieter Wuille <pieter.wuille@gmail.com>
Status: Final
Type: Informational
Created: 2012-02-11
</pre>

4
bip-0034.mediawiki

@ -2,7 +2,7 @@
BIP: 34
Title: Block v2, Height in Coinbase
Author: Gavin Andresen <gavinandresen@gmail.com>
Status: Accepted
Status: Final
Type: Standards Track
Created: 2012-07-06
</pre>
@ -19,7 +19,7 @@ Bitcoin blocks and transactions are versioned binary structures. Both currently
==Specification==
# Treat transactions with a version greater than 1 as non-standard (official Satoshi client will not mine or relay them).
# Add height as the first item in the coinbase transaction's scriptSig, and increase block version to 2. The format of the height is "serialized CScript" -- first byte is number of bytes in the number (will be 0x03 on main net for the next 300 or so years), following bytes are little-endian representation of the number. Height is the height of the mined block in the block chain, where the genesis block is height zero (0).
# Add height as the first item in the coinbase transaction's scriptSig, and increase block version to 2. The format of the height is "serialized CScript" -- first byte is number of bytes in the number (will be 0x03 on main net for the next 150 or so years with 2<sup>23</sup>-1 blocks), following bytes are little-endian representation of the number (including a sign bit). Height is the height of the mined block in the block chain, where the genesis block is height zero (0).
# 75% rule: If 750 of the last 1,000 blocks are version 2 or greater, reject invalid version 2 blocks. (testnet3: 51 of last 100)
# 95% rule ("Point of no return"): If 950 of the last 1,000 blocks are version 2 or greater, reject all version 1 blocks. (testnet3: 75 of last 100)

2
bip-0035.mediawiki

@ -2,7 +2,7 @@
BIP: 35
Title: mempool message
Author: Jeff Garzik <jgarzik@exmulti.com>
Status: Accepted
Status: Final
Type: Standards Track
Created: 2012-08-16
</pre>

5
bip-0037.mediawiki

@ -1,8 +1,9 @@
<pre>
BIP: 37
Title: Connection Bloom filtering
Author: Mike Hearn <hearn@google.com>, Matt Corallo <bip@bluematt.me>
Status: Accepted
Author: Mike Hearn <hearn@google.com>
Matt Corallo <bip@bluematt.me>
Status: Final
Type: Standards Track
Created: 2012-10-24
</pre>

4
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

16
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>

24
bip-0039/bip-0039-wordlists.md

@ -6,6 +6,7 @@
* [Chinese (Simplified)](chinese_simplified.txt)
* [Chinese (Traditional)](chinese_traditional.txt)
* [French](french.txt)
* [Italian](italian.txt)
##Wordlists (Special Considerations)
@ -57,3 +58,26 @@ Credits: @Kirvx @NicolasDorier @ecdsa @EricLarch
15. No words in conflict with the spelling corrections of 1990 (http://goo.gl/Y8DU4z).
16. No embarrassing words (in a very, very large scope) or belonging to a particular religion.
17. No identical words with the Spanish wordlist (as Y75QMO wants).
### Italian
Credits: @paoloaga @Polve
Words chosen using the following rules:
1. Simple and common italian words.
2. Length between 4 and 8 characters.
3. First 4 letters must be unique between all words.
4. No accents or special characters.
5. No complex verb forms.
6. No plural words.
7. No words that remind negative/sad/bad things.
8. If both female/male words are available, choose male version.
9. No words with double vocals (like: lineetta).
10. No words already used in other language mnemonic sets.
11. If 3 of the first 4 letters are already used in the same sequence in another mnemonic word, there must be at least other 3 different letters.
12. If 3 of the first 4 letters are already used in the same sequence in another mnemonic word, there not must be the same sequence of 3 or more letters.
Rules 11 and 12 prevent the selection words that are not different enough. This makes each word more recognizable among others and less error prone. For example: the wordlist contains "atono", then "atomo" is rejected, but "atomico" is good.
All the words have been manually selected and automatically checked against the rules.

2048
bip-0039/italian.txt Normal file

File diff suppressed because it is too large Load Diff

12
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>

14
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>
@ -267,7 +267,7 @@ is required and a pull request to the above file should be created.
* [[https://play.google.com/store/apps/details?id=com.mycelium.wallet|Mycelium Bitcoin Wallet (Android)]] ([[https://github.com/mycelium-com/wallet|source]])
* [[https://copay.io/|Copay]] ([[https://github.com/bitpay/copay|source]])
* [[https://maza.club/encompass|Encompass]] ([[https://github.com/mazaclub/encompass|source]])
* [[https://www.crypzo.com/|Crypzo]]
==Reference==
* [[bip-0032.mediawiki|BIP32 - Hierarchical Deterministic Wallets]]

14
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>

13
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>

26
bip-0050.mediawiki

@ -8,27 +8,29 @@
</pre>
==What went wrong==
A block that had a larger number of total transaction inputs than previously seen was mined and broadcasted. Bitcoin 0.8 nodes were able to handle this, but some pre-0.8 Bitcoin nodes rejected it, causing an unexpected hard fork of the chain. The pre-0.8 incompatible chain at that point had around 60% of the hash power ensuring the split did not automatically resolve.
A block that had a larger number of total transaction inputs than previously seen was mined and broadcasted. Bitcoin 0.8 nodes were able to handle this, but some pre-0.8 Bitcoin nodes rejected it, causing an unexpected fork of the blockchain. The pre-0.8-incompatible chain (from here on, the 0.8 chain) at that point had around 60% of the mining hash power ensuring the split did not automatically resolve (as would have occurred if the pre-0.8 chain outpaced the 0.8 chain in total work, forcing 0.8 nodes to reorganise to the pre-0.8 chain).
In order to restore a canonical chain as soon as possible, BTCGuild and Slush downgraded their Bitcoin 0.8 nodes to 0.7 so their pools would also reject the larger block. This placed majority hashpower on the chain without the larger block.
In order to restore a canonical chain as soon as possible, BTCGuild and Slush downgraded their Bitcoin 0.8 nodes to 0.7 so their pools would also reject the larger block. This placed majority hashpower on the chain without the larger block, thus eventually causing the 0.8 nodes to reorganise to the pre-0.8 chain.
During this time there was at least [https://bitcointalk.org/index.php?topic=152348.0 one large double spend]. However, it was done by someone experimenting to see if it was possible and was not intended to be malicious.
==What went right==
* The split was detected very quickly.
* The right people were online and available in IRC or could be raised via Skype.
* Marek Palatinus and Michael Marsee quickly downgraded their nodes to restore a pre-0.8 chain as canonical, despite the fact that this caused them to sacrifice significant amounts of money and they were the ones running the bug-free version.
* The right people were online and available in IRC or could be contacted directly.
* Marek Palatinus (Slush) and Michael Marsee (Eleuthria of BTCGuild) quickly downgraded their nodes to restore a pre-0.8 chain as canonical, despite the fact that this caused them to sacrifice significant amounts of money.
* Deposits to the major exchanges and payments via BitPay were also suspended (and then un-suspended) very quickly.
* Fortunately, the only attack on a merchant was done by someone who was not intending to actually steal money
* Fortunately, the only attack on a merchant was done by someone who was not intending to actually steal money.
==Root cause==
Bitcoin versions prior to 0.8 configure an insufficient number of Berkeley DB locks to process large but technically valid blocks. Berkeley DB locks have to be manually configured by API users depending on anticipated load. The manual says this:
Bitcoin versions prior to 0.8 configure an insufficient number of Berkeley DB locks to process large but otherwise valid blocks. Berkeley DB locks have to be manually configured by API users depending on anticipated load. The manual says this:
:The recommended algorithm for selecting the maximum number of locks, lockers, and lock objects is to run the application under stressful conditions and then review the lock system's statistics to determine the maximum number of locks, lockers, and lock objects that were used. Then, double these values for safety.
With the insufficiently high BDB lock configuration, it implicitly had become a network consensus rule determining block validity (albeit an inconsistent and unsafe rule, since the lock usage could vary from node to node).
Because max-sized blocks had been successfully processed on the testnet, it did not occur to anyone that there could be blocks that were smaller but require more locks than were available. Prior to 0.7 unmodified mining nodes self-imposed a maximum block size of 500,000 bytes, which further prevented this case from being triggered. 0.7 made the target size configurable and miners had been encouraged to increase this target in the week prior to the incident.
Bitcoin 0.8 does not use Berkeley DB. It uses LevelDB instead, which does not require this kind of pre-configuration. Therefore it was able to process the forking block successfully.
Bitcoin 0.8 did not use Berkeley DB. It switched to LevelDB instead, which did not implement the same locking limits as BDB. Therefore it was able to process the forking block successfully.
Note that BDB locks are also required during processing of re-organizations. Versions prior to 0.8 may be unable to process some valid re-orgs.
@ -39,10 +41,10 @@ This would be an issue even if the entire network was running version 0.7.2. It
===Immediately===
'''Done''': Release a version 0.8.1, forked directly from 0.8.0, that, for the next two months has the following new rules:
# Reject blocks that could cause more than 10,000 locks to be taken.
# Reject blocks that would probably could cause more than 10,000 locks to be taken.
# Limit the maximum block-size created to 500,000 bytes
# Release a patch for older versions that implements the same rules, but also increases the maximum number of locks to 120,000
# Create a web page on bitcoin.org that will urge users to upgrade to 0.8.1, but will tell them how to set DB_CONFIG to 120,000 locks if they absolutely cannot.
# Release a patch for older versions that implements the same rules, but also increases the maximum number of locks to 537,000
# Create a web page on bitcoin.org that will urge users to upgrade to 0.8.1, but will tell them how to set DB_CONFIG to 537,000 locks if they absolutely cannot.
# Over the next 2 months, send a series of alerts to users of older versions, pointing to the web page.
===Alert system===
@ -70,3 +72,7 @@ A double spend attack was successful, despite that both sides of the chain heard
===Resolution===
On 16 August, 2013 block 252,451 (0x0000000000000024b58eeb1134432f00497a6a860412996e7a260f47126eed07) was accepted by the main network, forking unpatched nodes off the network.
==Copyright==
This document is placed in the public domain.

2
bip-0065.mediawiki

@ -2,7 +2,7 @@
BIP: 65
Title: OP_CHECKLOCKTIMEVERIFY
Author: Peter Todd <pete@petertodd.org>
Status: Accepted
Status: Final
Type: Standards Track
Created: 2014-10-01
</pre>

5
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 <me@thomaskerin.io>
Jean-Pierre Rupp <root@haskoin.com>
Ruben de Vries <ruben@rubensayshi.com>
Status: Draft
Type: Standards Track
Created: 2015-02-08

50
bip-0068.mediawiki

@ -64,21 +64,21 @@ enum {
/* Setting nSequence to this value for every input in a transaction
* disables nLockTime. */
static const uint32_t SEQUENCE_FINAL = 0xffffffff;
/* Below flags apply in the context of BIP 68*/
/* If this flag set, CTxIn::nSequence is NOT interpreted as a
* relative lock-time. Setting the most significant bit of a
* sequence number disabled relative lock-time. */
* relative lock-time. */
static const uint32_t SEQUENCE_LOCKTIME_DISABLE_FLAG = (1 << 31);
/* If CTxIn::nSequence encodes a relative lock-time and this flag
* is set, the relative lock-time has units of 512 seconds,
* otherwise it specifies blocks with a granularity of 1. */
static const uint32_t SEQUENCE_LOCKTIME_TYPE_FLAG = (1 << 22);
/* If CTxIn::nSequence encodes a relative lock-time, this mask is
* applied to extract that lock-time from the sequence field. */
static const uint32_t SEQUENCE_LOCKTIME_MASK = 0x0000ffff;
/* In order to use the same number of bits to encode roughly the
* same wall-clock duration, and because blocks are naturally
* limited to occur every 600s on average, the minimum granularity
@ -87,12 +87,12 @@ static const uint32_t SEQUENCE_LOCKTIME_MASK = 0x0000ffff;
* multiplying by 512 = 2^9, or equivalently shifting up by
* 9 bits. */
static const int SEQUENCE_LOCKTIME_GRANULARITY = 9;
/**
* Calculates the block height and time which the transaction must be later than
* in order to be considered final in the context of BIP 68. It also removes
* from the vector of input heights any entries which did not correspond to sequence
* locked inputs as they do not affect the calculation.
* Calculates the block height and previous block's median time past at
* which the transaction will be considered final in the context of BIP 68.
* Also removes from the vector of input heights any entries which did not
* correspond to sequence locked inputs as they do not affect the calculation.
*/
static std::pair<int, int64_t> CalculateSequenceLocks(const CTransaction &tx, int flags, std::vector<int>* prevHeights, const CBlockIndex& block)
{
@ -134,6 +134,14 @@ static std::pair<int, int64_t> CalculateSequenceLocks(const CTransaction &tx, in
if (txin.nSequence & CTxIn::SEQUENCE_LOCKTIME_TYPE_FLAG) {
int64_t nCoinTime = block.GetAncestor(std::max(nCoinHeight-1, 0))->GetMedianTimePast();
// NOTE: Subtract 1 to maintain nLockTime semantics
// BIP 68 relative lock times have the semantics of calculating
// the first block or time at which the transaction would be
// valid. When calculating the effective block time or height
// for the entire transaction, we switch to using the
// semantics of nLockTime which is the last invalid block
// time or height. Thus we subtract 1 from the calculated
// time or height.
// Time-based relative lock-times are measured from the
// smallest allowed timestamp of the block containing the
@ -141,10 +149,6 @@ static std::pair<int, int64_t> CalculateSequenceLocks(const CTransaction &tx, in
// block prior.
nMinTime = std::max(nMinTime, nCoinTime + (int64_t)((txin.nSequence & CTxIn::SEQUENCE_LOCKTIME_MASK) << CTxIn::SEQUENCE_LOCKTIME_GRANULARITY) - 1);
} else {
// We subtract 1 from relative lock-times because a lock-
// time of 0 has the semantics of "same block," so a lock-
// time of 1 should mean "next block," but nLockTime has
// the semantics of "last invalid block height."
nMinHeight = std::max(nMinHeight, nCoinHeight + (int)(txin.nSequence & CTxIn::SEQUENCE_LOCKTIME_MASK) - 1);
}
}
@ -154,7 +158,8 @@ static std::pair<int, int64_t> CalculateSequenceLocks(const CTransaction &tx, in
static bool EvaluateSequenceLocks(const CBlockIndex& block, std::pair<int, int64_t> lockPair)
{
int64_t nBlockTime = block.pprev ? block.pprev->GetMedianTimePast() : 0;
assert(block.pprev);
int64_t nBlockTime = block.pprev->GetMedianTimePast();
if (lockPair.first >= block.nHeight || lockPair.second >= nBlockTime)
return false;
@ -169,16 +174,17 @@ bool SequenceLocks(const CTransaction &tx, int flags, std::vector<int>* prevHeig
bool CheckSequenceLocks(const CTransaction &tx, int flags)
{
AssertLockHeld(cs_main);
AssertLockHeld(mempool.cs);
CBlockIndex* tip = chainActive.Tip();
CBlockIndex index;
index.pprev = tip;
// CheckSequenceLocks() uses chainActive.Height()+1 to evaluate
// height based locks because when SequenceLocks() is called within
// CBlock::AcceptBlock(), the height of the block *being*
// evaluated is what is used. Thus if we want to know if a
// transaction can be part of the *next* block, we need to call
// SequenceLocks() with one more than chainActive.Height().
// ConnectBlock(), the height of the block *being*
// evaluated is what is used.
// Thus if we want to know if a transaction can be part of the
// *next* block, we need to use one more than chainActive.Height()
index.nHeight = tip->nHeight + 1;
// pcoinsTip contains the UTXO set for chainActive.Tip()
@ -189,7 +195,7 @@ bool CheckSequenceLocks(const CTransaction &tx, int flags)
const CTxIn& txin = tx.vin[txinIndex];
CCoins coins;
if (!viewMemPool.GetCoins(txin.prevout.hash, coins)) {
return error("%s: Missing input", __func__);
return error("%s: Missing input", __func__);
}
if (coins.nHeight == MEMPOOL_HEIGHT) {
// Assume all mempool transaction confirm in the next block
@ -244,5 +250,5 @@ BIP112: https://github.com/bitcoin/bips/blob/master/bip-0112.mediawiki
BIP113: https://github.com/bitcoin/bips/blob/master/bip-0113.mediawiki
Hashed Timelock Contrats (HTLCs): https://github.com/ElementsProject/lightning/raw/master/doc/deployable-lightning.pdf
Hashed Timelock Contracts (HTLCs): https://github.com/ElementsProject/lightning/raw/master/doc/deployable-lightning.pdf

12
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>

3
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

3
bip-0074.mediawiki

@ -2,6 +2,9 @@
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==

12
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@opentransactions.org>
Jimmy Song <jimmy@monetas.net>
Status: Draft
Type: Informational
Created: 2014-08-11
</pre>

12
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@opentransactions.org>
Jimmy Song <jimmy@monetas.net>
Status: Draft
Type: Informational
Created: 2014-08-11
</pre>

10
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>

2
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>

2
bip-0101.mediawiki

@ -2,7 +2,7 @@
BIP: 101
Title: Increase maximum block size
Author: Gavin Andresen <gavinandresen@gmail.com>
Status: Draft
Status: Withdrawn
Type: Standards Track
Created: 2015-06-22
</pre>

2
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

82
bip-0109.mediawiki Normal file

@ -0,0 +1,82 @@
<pre>
BIP: 109
Title: Two million byte size limit with sigop and sighash limits
Author: Gavin Andresen <gavinandresen@gmail.com>
Status: Draft
Type: Standards Track
Created: 2016-01-28
</pre>
==Abstract==
One-time increase in total amount of transaction data permitted in a block from 1MB to 2MB, with limits on signature operations and hashing.
==Motivation==
# Continue current economic policy.
# Exercise hard fork network upgrade.
# Mitigate potential CPU exhaustion attacks
==Specification==
=== MAX_BLOCK_SIZE increased to 2,000,000 bytes ===
The maximum number of bytes in a canonically serialized block shall be increased from
1,000,000 bytes to 2,000,000 bytes.
=== Switch to accurately-counted sigop limit of 20,000 per block ===
The existing MAX_SIGOPS limit of 20,000 signature operations per block shall be retained,
but only ECDSA verifications actually performed to validate the block shall be counted.
In particular:
* The coinbase scriptSig is not counted
* Signature operations in un-executed branches of a Script are not counted
* OP_CHECKMULTISIG evaluations are counted accurately; if the signature for a 1-of-20 OP_CHECKMULTISIG is satisified by the public key nearest the top of the execution stack, it is counted as one signature operation. If it is satisfied by the public key nearest the bottom of the execution stack, it is counted as twenty signature operations.
* Signature operations involving invalidly encoded signatures or public keys are not counted towards the limit
=== Add a new limit of 1,300,000,000 bytes hashed to compute transaction signatures per block ===
The amount of data hashed to compute signature hashes is limited to 1,300,000,000 bytes per block. The same rules for counting are used as for counting signature operations.
=== Activation: 75% hashpower support trigger, followed by 28-day 'grace period' ===
Solo miners or mining pool operators express their support for this BIP by setting the fourth-highest-bit in the block's 32-bit version number (0x10000000 in hex). The first block with that bit set, a timestamp less than or equal to the expiration time, and with at least 750 out of 1000 blocks preceding it (with heights H-1000..H-1) with that bit set, shall define the beginning of a grace period. Blocks with timestamps greater than or equal to the triggering block's timestamp plus 28 days (60*60*24*28 seconds) shall be subject to the new limits.
As always, miners are expected to use their best judgement for what is best for the entire Bitcoin ecosystem when making decisions about what consensus-level changes to support.
=== Expiration: 1-Jan-2018 ===
If this BIP is not triggered before 1-Jan-2018 00:00:00 GMT it should be considered withdrawn.
Miners that support this BIP should set bit 0x10000000 in the block version until 1-Jan-2018. After that date, that bit can be safely re-used for future consensus rule upgrades.
==Backward compatibility==
Fully validating older clients are not compatible with this change.
The first block exceeding the old limits on block size or inaccurately counted signature operations will partition older clients off the new network.
SPV (simple payment validation) wallets are compatible with this change.
==Rationale==
In the short term, an increase is needed to handle increasing transaction volume.
The limits on signature operations and amount of signature hashing done prevent possible CPU exhaustion attacks by "rogue miners" producing very expensive-to-validate two megabyte blocks. The signature hashing limit is chosen to be impossible to reach with any non-attack transaction or block, to minimize the impact on existing mining or wallet software.
The choices of constants for the deployment scheme were motivated by prior experience with upgrades to the Bitcoin consensus rules:
* 0x10000000 was chosen to be compatible with the BIP 9 proposal for parallel deployment of soft forks
* 75% was chosen instead of 95% to minimize the opportunity for a single large mining pool or miner to be able to veto an increase, either because of ideological opposition or threat of violence or extortion.
* A four-week grace period after the voting period was chosen as a balance between giving people sufficient time to upgrade and keeping people's attention on the urgent need to upgrade.
==Implementation==
https://github.com/gavinandresen/bitcoin-git/tree/two_mb_bump
See also http://gavinandresen.ninja/a-guided-tour-of-the-2mb-fork
==Copyright==
This work is placed in the public domain.

3
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

10
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
@ -345,12 +345,12 @@ semantics and detailed rationale for those semantics.
A reference implementation is provided by the following pull request:
https://github.com/bitcoin/bitcoin/pull/6564
https://github.com/bitcoin/bitcoin/pull/7524
==Deployment==
This BIP is to be deployed by either version-bits BIP9 or by isSuperMajority(). Exact details TDB.
This BIP is to be deployed by either version-bits BIP9 or by IsSuperMajority(). Exact details TDB.
It is recommended to deploy BIP68 and BIP113 at the same time as this BIP.

2
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

2
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>

2
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

12
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>

3
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

2
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

2
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==

96
bip-0145.mediawiki Normal file

@ -0,0 +1,96 @@
<pre>
BIP: 145
Title: getblocktemplate Updates for Segregated Witness
Author: Luke Dashjr <luke+bip22@dashjr.org>
Status: Draft
Type: Standards Track
Created: 2016-01-30
</pre>
==Abstract==
This BIP describes modifications to the getblocktemplate JSON-RPC call ([[bip-0022.mediawiki|BIP 22]]) to support segregated witness as defined by [[bip-0141.mediawiki|BIP 141]].
==Specification==
===Block Template===
The template Object is revised to include these keys:
{| class="wikitable"
!colspan=4| template
|-
! Key !! Required !! Type !! Description
|-
| costlimit || {{No}} || Number || total cost allowed in blocks
|-
| sigoplimit || {{No}} || Number || total sigop cost allowed in blocks divided by 4
|-
| version || {{Yes}} || Number || block version; clients MUST understand the implications of the version they use (eg, comply with [[bip-0141.mediawiki|BIP 141]] for version 5)
|}
====Transactions Object Format====
The Objects listed in the response's "transactions" key is revised to include these keys:
{| class="wikitable"
!colspan=3|template "transactions" element
|-
! Key !! Type !! Description
|-
| txid || String || transaction id encoded in hexadecimal; required for transactions with witness data
|-
| cost || Number || numeric cost of the transaction, as counted for purposes of the block's costlimit; if key is not present, cost is unknown and clients MUST NOT assume it is zero, although they MAY choose to calculate it themselves
|-
| hash || String || reversed hash of complete transaction (with witness data included) encoded in hexadecimal
|}
Transactions with witness data may only be included if the template's block version is at least 5.
===Block Assembly with Witness Transactions===
When block assembly is done without witness transactions, no changes are made by this BIP, and it should be assembled as previously.
When witness transactions are included in the block, the primary merkle root MUST be calculated with those transactions' "txid" field instead of "hash". A secondary merkle root MUST be calculated as per [[bip-0141.mediawiki#Commitment_structure|BIP 141's commitment structure specification]] to be inserted into the generation (coinbase) transaction.
Servers MUST NOT include a commitment in the "coinbasetxn" key on the template. Clients MUST insert the commitment as an additional output at the end of the final generation (coinbase) transaction. Only if the template includes a "mutable" key (see [[bip-0023.mediawiki#Mutations|BIP 23 Mutations]]) including "generation", the client MAY in that case place the commitment output in any position it chooses, provided that no later output matches the commitment pattern.
==Motivation==
Segregated witness substantially changes the structure of blocks, so the previous getblocktemplate specification is no longer sufficient.
It additionally also adds a new way of counting resource limits, and so GBT must be extended to convey this information correctly as well.
==Rationale==
Why doesn't "costlimit" simply redefine the existing "sizelimit"?
* "sizelimit" is already enforced by clients by counting the sum of bytes in transactions' "data" keys.
* Servers may wish to limit the overall size of a block, independently from the "cost" of the block.
Why is "sigoplimit" redefined instead of a new "sigopcostlimit" being added?
* The old limit was already arbitrarily defined, and could not be counted by clients on their own anyway. The concept of "sigop cost" is merely a change in the arbitrary formula used.
Why is "sigoplimit" divided by 4?
* To resemble the previous values. (FIXME: is this a good reason? maybe we shouldn't divide it?)
Why is the witness commitment required to be added to the end of the generation transaction rather than anywhere else?
* Servers which do not allow modification of the generation outputs ought to be checking this as part of the validity of submissions. By requiring a specific placement, they can simply strip the commitment and do a byte-for-byte comparison of the outputs. Placing it at the end avoids the possibility of a later output matching the pattern and overriding it.
Why shouldn't the server simply add the commitment upfront in the "coinbasetxn", and simply send the client stripped transaction data?
* It would become impossible for servers to specify only "coinbasevalue", since clients would no longer have the information required to construct the commitment.
* getblocktemplate is intended to be a *decentralised* mining protocol, and allowing clients to be blinded to the content of the block works contrary to that purpose.
* BIP 23's "transactions" mutations allow the client to modify the transaction-set on their own, which is impossible without the complete transaction data.
==Reference Implementation==
* [https://github.com/bitcoin/libblkmaker/tree/segwit libblkmaker]
* [https://github.com/luke-jr/eloipool/tree/segwit Eloipool]
* [https://github.com/bitcoin/bitcoin/pull/7404/files Bitcoin Core]
==See Also==
* [[bip-0022.mediawiki|BIP 22: getblocktemplate - Fundamentals]]
* [[bip-0023.mediawiki|BIP 23: getblocktemplate - Pooled Mining]]
* [[bip-0141.mediawiki|BIP 141: Segregated Witness (Consensus layer)]]
==Copyright==
This BIP is dual-licensed under the Open Publication License and BSD 2-clause license.

136
scripts/buildtable.pl Executable file

@ -0,0 +1,136 @@
#!/usr/bin/perl
use strict;
use warnings;
my $topbip = 9999;
my %RequiredFields = (
BIP => undef,
Title => undef,
Author => undef,
Status => undef,
Type => undef,
Created => undef,
);
my %MayHaveMulti = (
Author => undef,
'Post-History' => undef,
);
my %DateField = (
Created => undef,
);
my %EmailField = (
Author => undef,
Editor => undef,
);
my %MiscField = (
'Post-History' => undef,
);
my %ValidLayer = (
Process => undef,
);
my %ValidStatus = (
Draft => undef,
Deferred => undef,
Accepted => "background-color: #ffffcf",
Rejected => "background-color: #ffcfcf",
Withdrawn => "background-color: #ffcfcf",
Final => "background-color: #cfffcf",
Active => "background-color: #cfffcf",
Replaced => "background-color: #ffcfcf",
);
my %ValidType = (
'Standards Track' => 'Standard',
'Informational' => undef,
'Process' => undef,
);
my %emails;
my $bipnum = 0;
while (++$bipnum <= $topbip) {
my $fn = sprintf "bip-%04d.mediawiki", $bipnum;
-e $fn || next;
open my $F, "<$fn";
while (<$F> !~ m[^(?:\xef\xbb\xbf)?<pre>$]) {
die "No <pre> in $fn" if eof $F;
}
my %found;
my ($title, $author, $status, $type);
my ($field, $val);
while (<$F>) {
m[^</pre>$] && last;
if (m[^ ([\w-]+)\: (.*\S)$]) {
$field = $1;
$val = $2;
die "Duplicate $field field in $fn" if exists $found{$field};
} elsif (m[^ ( +)(.*\S)$]) {
die "Continuation of non-field in $fn" unless defined $field;
die "Too many spaces in $fn" if length $1 != 2 + length $field;
die "Not allowed for multi-value in $fn" unless exists $MayHaveMulti{$field};
$val = $2;
} else {
die "Bad line in $fn preamble";
}
++$found{$field};
die "Extra spaces in $fn" if $val =~ /^\s/;
if ($field eq 'BIP') {
die "$fn claims to be BIP $val" if $val ne $bipnum;
} elsif ($field eq 'Title') {
$title = $val;
} elsif ($field eq 'Author') {
$val =~ m/^(\S[^<@>]*\S) \<([^@>]*\@[\w.]+\.\w+)\>$/ or die "Malformed Author line in $fn";
my ($authorname, $authoremail) = ($1, $2);
$authoremail =~ s/(?<=\D)$bipnum(?=\D)/<BIPNUM>/g;
$emails{$authorname}->{$authoremail} = undef;
if (defined $author) {
$author .= ", $authorname";
} else {
$author = $authorname;
}
} elsif ($field eq 'Status') {
if ($bipnum == 38) { # HACK
$val =~ s/\s+\(.*\)$//;
}
die "Invalid status in $fn" unless exists $ValidStatus{$val};
$status = $val;
} elsif ($field eq 'Type') {
die "Invalid type in $fn" unless exists $ValidType{$val};
if (defined $ValidType{$val}) {
$type = $ValidType{$val};
} else {
$type = $val;
}
} elsif ($field eq 'Layer') { # BIP 123
die "Invalid layer $val in $fn" unless exists $ValidLayer{$val};
} elsif (exists $DateField{$field}) {
die "Invalid date format in $fn" unless $val =~ /^20\d{2}\-(?:0\d|1[012])\-(?:[012]\d|30|31)$/;
} elsif (exists $EmailField{$field}) {
$val =~ m/^(\S[^<@>]*\S) \<[^@>]*\@[\w.]+\.\w+\>$/ or die "Malformed $field line in $fn";
} elsif (not exists $MiscField{$field}) {
die "Unknown field $field in $fn";
}
}
for my $field (keys %RequiredFields) {
die "Missing $field in $fn" unless $found{$field};
}
print "|-";
if (defined $ValidStatus{$status}) {
print " style=\"" . $ValidStatus{$status} . "\"";
}
print "\n";
print "| [[${fn}|${bipnum}]]\n";
print "| ${title}\n";
print "| ${author}\n";
print "| ${type}\n";
print "| ${status}\n";
close $F;
}
for my $author (sort keys %emails) {
my @emails = sort keys %{$emails{$author}};
my $email_count = @emails;
next unless $email_count > 1;
warn "NOTE: $author has $email_count email addresses: @emails\n";
}