diff options
51 files changed, 3151 insertions, 310 deletions
diff --git a/.travis.yml b/.travis.yml new file mode 100644 index 0000000..ed99de0 --- /dev/null +++ b/.travis.yml @@ -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 diff --git a/README.mediawiki b/README.mediawiki index 045fd28..3c6b227 100644 --- a/README.mediawiki +++ b/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,12 +216,12 @@ 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 | Informational -| Draft +| Final <!-- 50 series reserved for a group of post-mortems --> |- | [[bip-0060.mediawiki|60]] @@ -223,13 +229,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 +249,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: #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 | 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 -|- +|- 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]] +| 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,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 @@ -362,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 @@ -370,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 |- @@ -401,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]] @@ -412,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 |- @@ -463,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! --> 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-0002.mediawiki b/bip-0002.mediawiki new file mode 100644 index 0000000..571361c --- /dev/null +++ b/bip-0002.mediawiki @@ -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] 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-0011.mediawiki b/bip-0011.mediawiki index 2499ac0..4b12340 100644 --- a/bip-0011.mediawiki +++ b/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 diff --git a/bip-0014.mediawiki b/bip-0014.mediawiki index 111eb78..f11cb63 100644 --- a/bip-0014.mediawiki +++ b/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 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..e7094e5 100644 --- a/bip-0021.mediawiki +++ b/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> @@ -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-0022.mediawiki b/bip-0022.mediawiki index b39f957..35b59be 100644 --- a/bip-0022.mediawiki +++ b/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> diff --git a/bip-0023.mediawiki b/bip-0023.mediawiki index a53b00b..874e60a 100644 --- a/bip-0023.mediawiki +++ b/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> diff --git a/bip-0031.mediawiki b/bip-0031.mediawiki index 8adcd29..1bfe143 100644 --- a/bip-0031.mediawiki +++ b/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> diff --git a/bip-0032.mediawiki b/bip-0032.mediawiki index ac0ed99..8692c6d 100644 --- a/bip-0032.mediawiki +++ b/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> diff --git a/bip-0034.mediawiki b/bip-0034.mediawiki index 245985c..4870fc1 100644 --- a/bip-0034.mediawiki +++ b/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) diff --git a/bip-0035.mediawiki b/bip-0035.mediawiki index cdadd1d..c66735c 100644 --- a/bip-0035.mediawiki +++ b/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> diff --git a/bip-0037.mediawiki b/bip-0037.mediawiki index 77b917b..f76891e 100644 --- a/bip-0037.mediawiki +++ b/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> diff --git a/bip-0038.mediawiki b/bip-0038.mediawiki index d87c5cf..650b7d0 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-0039/bip-0039-wordlists.md b/bip-0039/bip-0039-wordlists.md index 203ba06..aef1a23 100644 --- a/bip-0039/bip-0039-wordlists.md +++ b/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. diff --git a/bip-0039/italian.txt b/bip-0039/italian.txt new file mode 100644 index 0000000..c47370f --- /dev/null +++ b/bip-0039/italian.txt @@ -0,0 +1,2048 @@ +abaco +abbaglio +abbinato +abete +abisso +abolire +abrasivo +abrogato +accadere +accenno +accusato +acetone +achille +acido +acqua +acre +acrilico +acrobata +acuto +adagio +addebito +addome +adeguato +aderire +adipe +adottare +adulare +affabile +affetto +affisso +affranto +aforisma +afoso +africano +agave +agente +agevole +aggancio +agire +agitare +agonismo +agricolo +agrumeto +aguzzo +alabarda +alato +albatro +alberato +albo +albume +alce +alcolico +alettone +alfa +algebra +aliante +alibi +alimento +allagato +allegro +allievo +allodola +allusivo +almeno +alogeno +alpaca +alpestre +altalena +alterno +alticcio +altrove +alunno +alveolo +alzare +amalgama +amanita +amarena +ambito +ambrato +ameba +america +ametista +amico +ammasso +ammenda +ammirare +ammonito +amore +ampio +ampliare +amuleto +anacardo +anagrafe +analista +anarchia +anatra +anca +ancella +ancora +andare +andrea +anello +angelo +angolare +angusto +anima +annegare +annidato +anno +annuncio +anonimo +anticipo +anzi +apatico +apertura +apode +apparire +appetito +appoggio +approdo +appunto +aprile +arabica +arachide +aragosta +araldica +arancio +aratura +arazzo +arbitro +archivio +ardito +arenile +argento +argine +arguto +aria +armonia +arnese +arredato +arringa +arrosto +arsenico +arso +artefice +arzillo +asciutto +ascolto +asepsi +asettico +asfalto +asino +asola +aspirato +aspro +assaggio +asse +assoluto +assurdo +asta +astenuto +astice +astratto +atavico +ateismo +atomico +atono +attesa +attivare +attorno +attrito +attuale +ausilio +austria +autista +autonomo +autunno +avanzato +avere +avvenire +avviso +avvolgere +azione +azoto +azzimo +azzurro +babele +baccano +bacino +baco +badessa +badilata +bagnato +baita +balcone +baldo +balena +ballata +balzano +bambino +bandire +baraonda +barbaro +barca +baritono +barlume +barocco +basilico +basso +batosta +battuto +baule +bava +bavosa +becco +beffa +belgio +belva +benda +benevole +benigno +benzina +bere +berlina +beta +bibita +bici +bidone +bifido +biga +bilancia +bimbo +binocolo +biologo +bipede +bipolare +birbante +birra +biscotto +bisesto +bisnonno +bisonte +bisturi +bizzarro +blando +blatta +bollito +bonifico +bordo +bosco +botanico +bottino +bozzolo +braccio +bradipo +brama +branca +bravura +bretella +brevetto +brezza +briglia +brillante +brindare +broccolo +brodo +bronzina +brullo +bruno +bubbone +buca +budino +buffone +buio +bulbo +buono +burlone +burrasca +bussola +busta +cadetto +caduco +calamaro +calcolo +calesse +calibro +calmo +caloria +cambusa +camerata +camicia +cammino +camola +campale +canapa +candela +cane +canino +canotto +cantina +capace +capello +capitolo +capogiro +cappero +capra +capsula +carapace +carcassa +cardo +carisma +carovana +carretto +cartolina +casaccio +cascata +caserma +caso +cassone +castello +casuale +catasta +catena +catrame +cauto +cavillo +cedibile +cedrata +cefalo +celebre +cellulare +cena +cenone +centesimo +ceramica +cercare +certo +cerume +cervello +cesoia +cespo +ceto +chela +chiaro +chicca +chiedere +chimera +china +chirurgo +chitarra +ciao +ciclismo +cifrare +cigno +cilindro +ciottolo +circa +cirrosi +citrico +cittadino +ciuffo +civetta +civile +classico +clinica +cloro +cocco +codardo +codice +coerente +cognome +collare +colmato +colore +colposo +coltivato +colza +coma +cometa +commando +comodo +computer +comune +conciso +condurre +conferma +congelare +coniuge +connesso +conoscere +consumo +continuo +convegno +coperto +copione +coppia +copricapo +corazza +cordata +coricato +cornice +corolla +corpo +corredo +corsia +cortese +cosmico +costante +cottura +covato +cratere +cravatta +creato +credere +cremoso +crescita +creta +criceto +crinale +crisi +critico +croce +cronaca +crostata +cruciale +crusca +cucire +cuculo +cugino +cullato +cupola +curatore +cursore +curvo +cuscino +custode +dado +daino +dalmata +damerino +daniela +dannoso +danzare +datato +davanti +davvero +debutto +decennio +deciso +declino +decollo +decreto +dedicato +definito +deforme +degno +delegare +delfino +delirio +delta +demenza +denotato +dentro +deposito +derapata +derivare +deroga +descritto +deserto +desiderio +desumere +detersivo +devoto +diametro +dicembre +diedro +difeso +diffuso +digerire +digitale +diluvio +dinamico +dinnanzi +dipinto +diploma +dipolo +diradare +dire +dirotto +dirupo +disagio +discreto +disfare +disgelo +disposto +distanza +disumano +dito +divano +divelto +dividere +divorato +doblone +docente +doganale +dogma +dolce +domato +domenica +dominare +dondolo +dono +dormire +dote +dottore +dovuto +dozzina +drago +druido +dubbio +dubitare +ducale +duna +duomo +duplice +duraturo +ebano +eccesso +ecco +eclissi +economia +edera +edicola +edile +editoria +educare +egemonia +egli +egoismo +egregio +elaborato +elargire +elegante +elencato +eletto +elevare +elfico +elica +elmo +elsa +eluso +emanato +emblema +emesso +emiro +emotivo +emozione +empirico +emulo +endemico +enduro +energia +enfasi +enoteca +entrare +enzima +epatite +epilogo +episodio +epocale +eppure +equatore +erario +erba +erboso +erede +eremita +erigere +ermetico +eroe +erosivo +errante +esagono +esame +esanime +esaudire +esca +esempio +esercito +esibito +esigente +esistere +esito +esofago +esortato +esoso +espanso +espresso +essenza +esso +esteso +estimare +estonia +estroso +esultare +etilico +etnico +etrusco +etto +euclideo +europa +evaso +evidenza +evitato +evoluto +evviva +fabbrica +faccenda +fachiro +falco +famiglia +fanale +fanfara +fango +fantasma +fare +farfalla +farinoso +farmaco +fascia +fastoso +fasullo +faticare +fato +favoloso +febbre +fecola +fede +fegato +felpa +feltro +femmina +fendere +fenomeno +fermento +ferro +fertile +fessura +festivo +fetta +feudo +fiaba +fiducia +fifa +figurato +filo +finanza +finestra +finire +fiore +fiscale +fisico +fiume +flacone +flamenco +flebo +flemma +florido +fluente +fluoro +fobico +focaccia +focoso +foderato +foglio +folata +folclore +folgore +fondente +fonetico +fonia +fontana +forbito +forchetta +foresta +formica +fornaio +foro +fortezza +forzare +fosfato +fosso +fracasso +frana +frassino +fratello +freccetta +frenata +fresco +frigo +frollino +fronde +frugale +frutta +fucilata +fucsia +fuggente +fulmine +fulvo +fumante +fumetto +fumoso +fune +funzione +fuoco +furbo +furgone +furore +fuso +futile +gabbiano +gaffe +galateo +gallina +galoppo +gambero +gamma +garanzia +garbo +garofano +garzone +gasdotto +gasolio +gastrico +gatto +gaudio +gazebo +gazzella +geco +gelatina +gelso +gemello +gemmato +gene +genitore +gennaio +genotipo +gergo +ghepardo +ghiaccio +ghisa +giallo +gilda +ginepro +giocare +gioiello +giorno +giove +girato +girone +gittata +giudizio +giurato +giusto +globulo +glutine +gnomo +gobba +golf +gomito +gommone +gonfio +gonna +governo +gracile +grado +grafico +grammo +grande +grattare +gravoso +grazia +greca +gregge +grifone +grigio +grinza +grotta +gruppo +guadagno +guaio +guanto +guardare +gufo +guidare +ibernato +icona +identico +idillio +idolo +idra +idrico +idrogeno +igiene +ignaro +ignorato +ilare +illeso +illogico +illudere +imballo +imbevuto +imbocco +imbuto +immane +immerso +immolato +impacco +impeto +impiego +importo +impronta +inalare +inarcare +inattivo +incanto +incendio +inchino +incisivo +incluso +incontro +incrocio +incubo +indagine +india +indole +inedito +infatti +infilare +inflitto +ingaggio +ingegno +inglese +ingordo +ingrosso +innesco +inodore +inoltrare +inondato +insano +insetto +insieme +insonnia +insulina +intasato +intero +intonaco +intuito +inumidire +invalido +invece +invito +iperbole +ipnotico +ipotesi +ippica +iride +irlanda +ironico +irrigato +irrorare +isolato +isotopo +isterico +istituto +istrice +italia +iterare +labbro +labirinto +lacca +lacerato +lacrima +lacuna +laddove +lago +lampo +lancetta +lanterna +lardoso +larga +laringe +lastra +latenza +latino +lattuga +lavagna +lavoro +legale +leggero +lembo +lentezza +lenza +leone +lepre +lesivo +lessato +lesto +letterale +leva +levigato +libero +lido +lievito +lilla +limatura +limitare +limpido +lineare +lingua +liquido +lira +lirica +lisca +lite +litigio +livrea +locanda +lode +logica +lombare +londra +longevo +loquace +lorenzo +loto +lotteria +luce +lucidato +lumaca +luminoso +lungo +lupo +luppolo +lusinga +lusso +lutto +macabro +macchina +macero +macinato +madama +magico +maglia +magnete +magro +maiolica +malafede +malgrado +malinteso +malsano +malto +malumore +mana +mancia +mandorla +mangiare +manifesto +mannaro +manovra +mansarda +mantide +manubrio +mappa +maratona +marcire +maretta +marmo +marsupio +maschera +massaia +mastino +materasso +matricola +mattone +maturo +mazurca +meandro +meccanico +mecenate +medesimo +meditare +mega +melassa +melis +melodia +meninge +meno +mensola +mercurio +merenda +merlo +meschino +mese +messere +mestolo +metallo +metodo +mettere +miagolare +mica +micelio +michele +microbo +midollo +miele +migliore +milano +milite +mimosa +minerale +mini +minore +mirino +mirtillo +miscela +missiva +misto +misurare +mitezza +mitigare +mitra +mittente +mnemonico +modello +modifica +modulo +mogano +mogio +mole +molosso +monastero +monco +mondina +monetario +monile +monotono +monsone +montato +monviso +mora +mordere +morsicato +mostro +motivato +motosega +motto +movenza +movimento +mozzo +mucca +mucosa +muffa +mughetto +mugnaio +mulatto +mulinello +multiplo +mummia +munto +muovere +murale +musa +muscolo +musica +mutevole +muto +nababbo +nafta +nanometro +narciso +narice +narrato +nascere +nastrare +naturale +nautica +naviglio +nebulosa +necrosi +negativo +negozio +nemmeno +neofita +neretto +nervo +nessuno +nettuno +neutrale +neve +nevrotico +nicchia +ninfa +nitido +nobile +nocivo +nodo +nome +nomina +nordico +normale +norvegese +nostrano +notare +notizia +notturno +novella +nucleo +nulla +numero +nuovo +nutrire +nuvola +nuziale +oasi +obbedire +obbligo +obelisco +oblio +obolo +obsoleto +occasione +occhio +occidente +occorrere +occultare +ocra +oculato +odierno +odorare +offerta +offrire +offuscato +oggetto +oggi +ognuno +olandese +olfatto +oliato +oliva +ologramma +oltre +omaggio +ombelico +ombra +omega +omissione +ondoso +onere +onice +onnivoro +onorevole +onta +operato +opinione +opposto +oracolo +orafo +ordine +orecchino +orefice +orfano +organico +origine +orizzonte +orma +ormeggio +ornativo +orologio +orrendo +orribile +ortensia +ortica +orzata +orzo +osare +oscurare +osmosi +ospedale +ospite +ossa +ossidare +ostacolo +oste +otite +otre +ottagono +ottimo +ottobre +ovale +ovest +ovino +oviparo +ovocito +ovunque +ovviare +ozio +pacchetto +pace +pacifico +padella +padrone +paese +paga +pagina +palazzina +palesare +pallido +palo +palude +pandoro +pannello +paolo +paonazzo +paprica +parabola +parcella +parere +pargolo +pari +parlato +parola +partire +parvenza +parziale +passivo +pasticca +patacca +patologia +pattume +pavone +peccato +pedalare +pedonale +peggio +peloso +penare +pendice +penisola +pennuto +penombra +pensare +pentola +pepe +pepita +perbene +percorso +perdonato +perforare +pergamena +periodo +permesso +perno +perplesso +persuaso +pertugio +pervaso +pesatore +pesista +peso +pestifero +petalo +pettine +petulante +pezzo +piacere +pianta +piattino +piccino +picozza +piega +pietra +piffero +pigiama +pigolio +pigro +pila +pilifero +pillola +pilota +pimpante +pineta +pinna +pinolo +pioggia +piombo +piramide +piretico +pirite +pirolisi +pitone +pizzico +placebo +planare +plasma +platano +plenario +pochezza +poderoso +podismo +poesia +poggiare +polenta +poligono +pollice +polmonite +polpetta +polso +poltrona +polvere +pomice +pomodoro +ponte +popoloso +porfido +poroso +porpora +porre +portata +posa +positivo +possesso +postulato +potassio +potere +pranzo +prassi +pratica +precluso +predica +prefisso +pregiato +prelievo +premere +prenotare +preparato +presenza +pretesto +prevalso +prima +principe +privato +problema +procura +produrre +profumo +progetto +prolunga +promessa +pronome +proposta +proroga +proteso +prova +prudente +prugna +prurito +psiche +pubblico +pudica +pugilato +pugno +pulce +pulito +pulsante +puntare +pupazzo +pupilla +puro +quadro +qualcosa +quasi +querela +quota +raccolto +raddoppio +radicale +radunato +raffica +ragazzo +ragione +ragno +ramarro +ramingo +ramo +randagio +rantolare +rapato +rapina +rappreso +rasatura +raschiato +rasente +rassegna +rastrello +rata +ravveduto +reale +recepire +recinto +recluta +recondito +recupero +reddito +redimere +regalato +registro +regola +regresso +relazione +remare +remoto +renna +replica +reprimere +reputare +resa +residente +responso +restauro +rete +retina +retorica +rettifica +revocato +riassunto +ribadire +ribelle +ribrezzo +ricarica +ricco +ricevere +riciclato +ricordo +ricreduto +ridicolo +ridurre +rifasare +riflesso +riforma +rifugio +rigare +rigettato +righello +rilassato +rilevato +rimanere +rimbalzo +rimedio +rimorchio +rinascita +rincaro +rinforzo +rinnovo +rinomato +rinsavito +rintocco +rinuncia +rinvenire +riparato +ripetuto +ripieno +riportare +ripresa +ripulire +risata +rischio +riserva +risibile +riso +rispetto +ristoro +risultato +risvolto +ritardo +ritegno +ritmico +ritrovo +riunione +riva +riverso +rivincita +rivolto +rizoma +roba +robotico +robusto +roccia +roco +rodaggio +rodere +roditore +rogito +rollio +romantico +rompere +ronzio +rosolare +rospo +rotante +rotondo +rotula +rovescio +rubizzo +rubrica +ruga +rullino +rumine +rumoroso +ruolo +rupe +russare +rustico +sabato +sabbiare +sabotato +sagoma +salasso +saldatura +salgemma +salivare +salmone +salone +saltare +saluto +salvo +sapere +sapido +saporito +saraceno +sarcasmo +sarto +sassoso +satellite +satira +satollo +saturno +savana +savio +saziato +sbadiglio +sbalzo +sbancato +sbarra +sbattere +sbavare +sbendare +sbirciare +sbloccato +sbocciato +sbrinare +sbruffone +sbuffare +scabroso +scadenza +scala +scambiare +scandalo +scapola +scarso +scatenare +scavato +scelto +scenico +scettro +scheda +schiena +sciarpa +scienza +scindere +scippo +sciroppo +scivolo +sclerare +scodella +scolpito +scomparto +sconforto +scoprire +scorta +scossone +scozzese +scriba +scrollare +scrutinio +scuderia +scultore +scuola +scuro +scusare +sdebitare +sdoganare +seccatura +secondo +sedano +seggiola +segnalato +segregato +seguito +selciato +selettivo +sella +selvaggio +semaforo +sembrare +seme +seminato +sempre +senso +sentire +sepolto +sequenza +serata +serbato +sereno +serio +serpente +serraglio +servire +sestina +setola +settimana +sfacelo +sfaldare +sfamato +sfarzoso +sfaticato +sfera +sfida +sfilato +sfinge +sfocato +sfoderare +sfogo +sfoltire +sforzato +sfratto +sfruttato +sfuggito +sfumare +sfuso +sgabello +sgarbato +sgonfiare +sgorbio +sgrassato +sguardo +sibilo +siccome +sierra +sigla +signore +silenzio +sillaba +simbolo +simpatico +simulato +sinfonia +singolo +sinistro +sino +sintesi +sinusoide +sipario +sisma +sistole +situato +slitta +slogatura +sloveno +smarrito +smemorato +smentito +smeraldo +smilzo +smontare +smottato +smussato +snellire +snervato +snodo +sobbalzo +sobrio +soccorso +sociale +sodale +soffitto +sogno +soldato +solenne +solido +sollazzo +solo +solubile +solvente +somatico +somma +sonda +sonetto +sonnifero +sopire +soppeso +sopra +sorgere +sorpasso +sorriso +sorso +sorteggio +sorvolato +sospiro +sosta +sottile +spada +spalla +spargere +spatola +spavento +spazzola +specie +spedire +spegnere +spelatura +speranza +spessore +spettrale +spezzato +spia +spigoloso +spillato +spinoso +spirale +splendido +sportivo +sposo +spranga +sprecare +spronato +spruzzo +spuntino +squillo +sradicare +srotolato +stabile +stacco +staffa +stagnare +stampato +stantio +starnuto +stasera +statuto +stelo +steppa +sterzo +stiletto +stima +stirpe +stivale +stizzoso +stonato +storico +strappo +stregato +stridulo +strozzare +strutto +stuccare +stufo +stupendo +subentro +succoso +sudore +suggerito +sugo +sultano +suonare +superbo +supporto +surgelato +surrogato +sussurro +sutura +svagare +svedese +sveglio +svelare +svenuto +svezia +sviluppo +svista +svizzera +svolta +svuotare +tabacco +tabulato +tacciare +taciturno +tale +talismano +tampone +tannino +tara +tardivo +targato +tariffa +tarpare +tartaruga +tasto +tattico +taverna +tavolata +tazza +teca +tecnico +telefono +temerario +tempo +temuto +tendone +tenero +tensione +tentacolo +teorema +terme +terrazzo +terzetto +tesi +tesserato +testato +tetro +tettoia +tifare +tigella +timbro +tinto +tipico +tipografo +tiraggio +tiro +titanio +titolo +titubante +tizio +tizzone +toccare +tollerare +tolto +tombola +tomo +tonfo +tonsilla +topazio +topologia +toppa +torba +tornare +torrone +tortora +toscano +tossire +tostatura +totano +trabocco +trachea +trafila +tragedia +tralcio +tramonto +transito +trapano +trarre +trasloco +trattato +trave +treccia +tremolio +trespolo +tributo +tricheco +trifoglio +trillo +trincea +trio +tristezza +triturato +trivella +tromba +trono +troppo +trottola +trovare +truccato +tubatura +tuffato +tulipano +tumulto +tunisia +turbare +turchino +tuta +tutela +ubicato +uccello +uccisore +udire +uditivo +uffa +ufficio +uguale +ulisse +ultimato +umano +umile +umorismo +uncinetto +ungere +ungherese +unicorno +unificato +unisono +unitario +unte +uovo +upupa +uragano +urgenza +urlo +usanza +usato +uscito +usignolo +usuraio +utensile +utilizzo +utopia +vacante +vaccinato +vagabondo +vagliato +valanga +valgo +valico +valletta +valoroso +valutare +valvola +vampata +vangare +vanitoso +vano +vantaggio +vanvera +vapore +varano +varcato +variante +vasca +vedetta +vedova +veduto +vegetale +veicolo +velcro +velina +velluto +veloce +venato +vendemmia +vento +verace +verbale +vergogna +verifica +vero +verruca +verticale +vescica +vessillo +vestale +veterano +vetrina +vetusto +viandante +vibrante +vicenda +vichingo +vicinanza +vidimare +vigilia +vigneto +vigore +vile +villano +vimini +vincitore +viola +vipera +virgola +virologo +virulento +viscoso +visione +vispo +vissuto +visura +vita +vitello +vittima +vivanda +vivido +viziare +voce +voga +volatile +volere +volpe +voragine +vulcano +zampogna +zanna +zappato +zattera +zavorra +zefiro +zelante +zelo +zenzero +zerbino +zibetto +zinco +zircone +zitto +zolla +zotico +zucchero +zufolo +zulu +zuppa 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..64358d8 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== @@ -267,7 +267,7 @@ is required. This can be done [[https://github.com/satoshilabs/docs/blob/master/ * [[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]] 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-0050.mediawiki b/bip-0050.mediawiki index 9ff29d6..4f48fca 100644 --- a/bip-0050.mediawiki +++ b/bip-0050.mediawiki @@ -2,33 +2,35 @@ BIP: 50 Title: March 2013 Chain Fork Post-Mortem Author: Gavin Andresen <gavinandresen@gmail.com> - Status: Draft + Status: Final Type: Informational Created: 2013-03-20 </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. diff --git a/bip-0065.mediawiki b/bip-0065.mediawiki index df995de..99298bf 100644 --- a/bip-0065.mediawiki +++ b/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> diff --git a/bip-0067.mediawiki b/bip-0067.mediawiki index 8be5c9b..3864c63 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 <me@thomaskerin.io> + 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-0068.mediawiki b/bip-0068.mediawiki index e93d748..fd17ea5 100644 --- a/bip-0068.mediawiki +++ b/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 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-0073.mediawiki b/bip-0073.mediawiki index a020fb5..41c89a3 100644 --- a/bip-0073.mediawiki +++ b/bip-0073.mediawiki @@ -2,7 +2,7 @@ BIP: 73 Title: Use "Accept" header for response type negotiation with Payment Request URLs Author: Stephen Pair <stephen@bitpay.com> - Status: Draft + Status: Final Type: Standards Track Created: 2013-08-27 </pre> 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..13d8597 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@opentransactions.org> + 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..b306075 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@opentransactions.org> + 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-0101.mediawiki b/bip-0101.mediawiki index a76db0f..cc8cfd5 100644 --- a/bip-0101.mediawiki +++ b/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> 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-0109.mediawiki b/bip-0109.mediawiki new file mode 100644 index 0000000..667ef5f --- /dev/null +++ b/bip-0109.mediawiki @@ -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. 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..336f9fc 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 @@ -229,128 +229,120 @@ The 2-way pegged sidechain requires a new REORGPROOFVERIFY opcode, the semantics Refer to the reference implementation, reproduced below, for the precise semantics and detailed rationale for those semantics. - - /* If this flag set, CTxIn::nSequence is NOT interpreted as a - * 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; +<pre> +/* Below flags apply in the context of BIP 68 */ +/* If this flag set, CTxIn::nSequence is NOT interpreted as a + * 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; - case OP_NOP3: - { - if (!(flags & SCRIPT_VERIFY_CHECKSEQUENCEVERIFY)) { - // not enabled; treat as a NOP3 - if (flags & SCRIPT_VERIFY_DISCOURAGE_UPGRADABLE_NOPS) { - return set_error(serror, SCRIPT_ERR_DISCOURAGE_UPGRADABLE_NOPS); - } - break; +case OP_NOP3: +{ + if (!(flags & SCRIPT_VERIFY_CHECKSEQUENCEVERIFY)) { + // not enabled; treat as a NOP3 + if (flags & SCRIPT_VERIFY_DISCOURAGE_UPGRADABLE_NOPS) { + return set_error(serror, SCRIPT_ERR_DISCOURAGE_UPGRADABLE_NOPS); } - - if (stack.size() < 1) - return set_error(serror, SCRIPT_ERR_INVALID_STACK_OPERATION); - - // Note that elsewhere numeric opcodes are limited to - // operands in the range -2**31+1 to 2**31-1, however it is - // legal for opcodes to produce results exceeding that - // range. This limitation is implemented by CScriptNum's - // default 4-byte limit. - // - // Thus as a special case we tell CScriptNum to accept up - // to 5-byte bignums, which are good until 2**39-1, well - // beyond the 2**32-1 limit of the nSequence field itself. - const CScriptNum nSequence(stacktop(-1), fRequireMinimal, 5); - - // In the rare event that the argument may be < 0 due to - // some arithmetic being done first, you can always use - // 0 MAX CHECKSEQUENCEVERIFY. - if (nSequence < 0) - return set_error(serror, SCRIPT_ERR_NEGATIVE_LOCKTIME); - - // To provide for future soft-fork extensibility, if the - // operand has the disabled lock-time flag set, - // CHECKSEQUENCEVERIFY behaves as a NOP. - if ((nSequence & CTxIn::SEQUENCE_LOCKTIME_DISABLE_FLAG) != 0) - break; - - // Compare the specified sequence number with the input. - if (!checker.CheckSequence(nSequence)) - return set_error(serror, SCRIPT_ERR_UNSATISFIED_LOCKTIME); - break; } - - bool TransactionSignatureChecker::CheckSequence(const CScriptNum& nSequence) const - { - // Relative lock times are supported by comparing the passed - // in operand to the sequence number of the input. - const int64_t txToSequence = (int64_t)txTo->vin[nIn].nSequence; - - // Fail if the transaction's version number is not set high - // enough to trigger BIP 68 rules. - if (static_cast<uint32_t>(txTo->nVersion) < 2) - return false; - - // Sequence numbers with their most significant bit set are not - // defined by BIP68. Testing that the transaction's sequence - // number do not have this bit set prevents using this property - // to get around a CHECKSEQUENCEVERIFY check. - if (txToSequence & CTxIn::SEQUENCE_LOCKTIME_DISABLE_FLAG) - return false; - - // Mask off any bits that do not have BIP68 consensus-enforced meaning - // before doing the integer comparisons of ::VerifySequence. - const uint32_t nLockTimeMask = CTxIn::SEQUENCE_LOCKTIME_TYPE_FLAG - | CTxIn::SEQUENCE_LOCKTIME_MASK; - - if (!::VerifySequence(txToSequence & nLockTimeMask, - CTxIn::SEQUENCE_LOCKTIME_TYPE_FLAG, - nSequence & nLockTimeMask)) - return false; - - return true; - } - - static bool VerifySequence(int64_t txToSequence, int64_t nThreshold, const CScriptNum& nSequence) - { - // There are two kinds of nLockTime: lock-by-blockheight - // and lock-by-blocktime, distinguished by whether - // nSequence < nThreshold (CTxIn::SEQUENCE_LOCKTIME_TYPE_FLAG). - // - // We want to compare apples to apples, so fail the script - // unless the type of nSequence being tested is the same as - // the nSequence in the transaction. - if (!( - (txToSequence < nThreshold && nSequence < nThreshold) || - (txToSequence >= nThreshold && nSequence >= nThreshold) - )) - return false; - - // Now that we know we're comparing apples-to-apples, the - // comparison is a simple numeric one. - if (nSequence > txToSequence) - return false; - - return true; - } + if (stack.size() < 1) + return set_error(serror, SCRIPT_ERR_INVALID_STACK_OPERATION); + + // Note that elsewhere numeric opcodes are limited to + // operands in the range -2**31+1 to 2**31-1, however it is + // legal for opcodes to produce results exceeding that + // range. This limitation is implemented by CScriptNum's + // default 4-byte limit. + // + // Thus as a special case we tell CScriptNum to accept up + // to 5-byte bignums, which are good until 2**39-1, well + // beyond the 2**32-1 limit of the nSequence field itself. + const CScriptNum nSequence(stacktop(-1), fRequireMinimal, 5); + + // In the rare event that the argument may be < 0 due to + // some arithmetic being done first, you can always use + // 0 MAX CHECKSEQUENCEVERIFY. + if (nSequence < 0) + return set_error(serror, SCRIPT_ERR_NEGATIVE_LOCKTIME); + + // To provide for future soft-fork extensibility, if the + // operand has the disabled lock-time flag set, + // CHECKSEQUENCEVERIFY behaves as a NOP. + if ((nSequence & CTxIn::SEQUENCE_LOCKTIME_DISABLE_FLAG) != 0) + break; + + // Compare the specified sequence number with the input. + if (!checker.CheckSequence(nSequence)) + return set_error(serror, SCRIPT_ERR_UNSATISFIED_LOCKTIME); + + break; +} + +bool TransactionSignatureChecker::CheckSequence(const CScriptNum& nSequence) const +{ + // Relative lock times are supported by comparing the passed + // in operand to the sequence number of the input. + const int64_t txToSequence = (int64_t)txTo->vin[nIn].nSequence; + + // Fail if the transaction's version number is not set high + // enough to trigger BIP 68 rules. + if (static_cast<uint32_t>(txTo->nVersion) < 2) + return false; + + // Sequence numbers with their most significant bit set are not + // consensus constrained. Testing that the transaction's sequence + // number do not have this bit set prevents using this property + // to get around a CHECKSEQUENCEVERIFY check. + if (txToSequence & CTxIn::SEQUENCE_LOCKTIME_DISABLE_FLAG) + return false; + + // Mask off any bits that do not have consensus-enforced meaning + // before doing the integer comparisons + const uint32_t nLockTimeMask = CTxIn::SEQUENCE_LOCKTIME_TYPE_FLAG | CTxIn::SEQUENCE_LOCKTIME_MASK; + const int64_t txToSequenceMasked = txToSequence & nLockTimeMask; + const CScriptNum nSequenceMasked = nSequence & nLockTimeMask; + + // There are two kinds of nSequence: lock-by-blockheight + // and lock-by-blocktime, distinguished by whether + // nSequenceMasked < CTxIn::SEQUENCE_LOCKTIME_TYPE_FLAG. + // + // We want to compare apples to apples, so fail the script + // unless the type of nSequenceMasked being tested is the same as + // the nSequenceMasked in the transaction. + if (!( + (txToSequenceMasked < CTxIn::SEQUENCE_LOCKTIME_TYPE_FLAG && nSequenceMasked < CTxIn::SEQUENCE_LOCKTIME_TYPE_FLAG) || + (txToSequenceMasked >= CTxIn::SEQUENCE_LOCKTIME_TYPE_FLAG && nSequenceMasked >= CTxIn::SEQUENCE_LOCKTIME_TYPE_FLAG) + )) + return false; + + // Now that we know we're comparing apples-to-apples, the + // comparison is a simple numeric one. + if (nSequenceMasked > txToSequenceMasked) + return false; + + return true; +} +</pre> ==Reference Implementation== 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. 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-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== diff --git a/bip-0145.mediawiki b/bip-0145.mediawiki new file mode 100644 index 0000000..b90725e --- /dev/null +++ b/bip-0145.mediawiki @@ -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. diff --git a/scripts/buildtable.pl b/scripts/buildtable.pl new file mode 100755 index 0000000..568b8eb --- /dev/null +++ b/scripts/buildtable.pl @@ -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"; +} |