diff --git a/README.mediawiki b/README.mediawiki index 8b48af15..da18d6b3 100644 --- a/README.mediawiki +++ b/README.mediawiki @@ -20,10 +20,10 @@ Those proposing changes should consider that ultimately consent may rest with th | Active |- | [[bip-0002.mediawiki|2]] -| BIP Status and Comments +| BIP process, revised | Luke Dashjr | Process -| Deferred +| Draft |- style="background-color: #cfffcf" | [[bip-0009.mediawiki|9]] | Version bits with timeout and delay @@ -216,6 +216,12 @@ Those proposing changes should consider that ultimately consent may rest with th | Justus Ranvier | Informational | Draft +|- +| [[bip-0049.mediawiki|49]] +| Derivation scheme for P2WPKH-nested-in-P2SH based accounts +| Daniel Weigl +| Informational +| Draft |- style="background-color: #cfffcf" | [[bip-0050.mediawiki|50]] | March 2013 Chain Fork Post-Mortem @@ -476,6 +482,12 @@ Those proposing changes should consider that ultimately consent may rest with th | Standard | Draft |- +| [[bip-0134.mediawiki|134]] +| Flexible Transactions +| Tom Zander +| Standard +| Draft +|- | [[bip-0140.mediawiki|140]] | Normalized TXID | Christian Decker @@ -513,8 +525,14 @@ Those proposing changes should consider that ultimately consent may rest with th | Draft |- | [[bip-0146.mediawiki|146]] -| Dealing with signature malleability -| Pieter Wuille, Johnson Lau +| Dealing with signature encoding malleability +| Johnson Lau, Pieter Wuille +| Standard +| Draft +|- +| [[bip-0147.mediawiki|147]] +| Dealing with dummy stack element malleability +| Johnson Lau | Standard | Draft |- diff --git a/bip-0002.mediawiki b/bip-0002.mediawiki index 9d59405f..43a5ce6e 100644 --- a/bip-0002.mediawiki +++ b/bip-0002.mediawiki @@ -1,31 +1,189 @@ 
   BIP: 2
-  Title: BIP Status and Comments
+  Title: BIP process, revised
   Author: Luke Dashjr 
-  Status: Deferred
+  Status: Draft
   Type: Process
   Created: 2016-02-03
+  Replaces: 1
==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. +A Bitcoin Improvement Proposal (BIP) is a design document providing information to the Bitcoin community, or describing a new feature for Bitcoin or its processes or environment. The BIP should provide a concise technical specification of the feature and a rationale for the feature. + +We intend BIPs to be the primary mechanisms for proposing new features, for collecting community input on an issue, and for documenting the design decisions that have gone into Bitcoin. The BIP author is responsible for building consensus within the community and documenting dissenting opinions. + +Because the BIPs are maintained as text files in a versioned repository, their revision history is the historical record of the feature proposal. + +This particular BIP replaces BIP 1 with a more well-defined and clear process. ==Copyright== This BIP is dual-licensed under the Open Publication License and BSD 2-clause license. +==BIP workflow== + +The BIP process begins with a new idea for Bitcoin. Each potential BIP must have a champion -- someone who writes the BIP using the style and format described below, shepherds the discussions in the appropriate forums, and attempts to build community consensus around the idea. The BIP champion (a.k.a. Author) should first attempt to ascertain whether the idea is BIP-able. +Small enhancements or patches to a particular piece of software often don't require standardisation between multiple projects; these don't need a BIP and should be injected into the relevant project-specific development workflow with a patch submission to the applicable issue tracker. +Additionally, many ideas have been brought forward for changing Bitcoin that have been rejected for various reasons. +The first step should be to search past discussions to see if an idea has been considered before, and if so, what issues arose in its progression. +After investigating past work, the best way to proceed is by posting about the new idea to the [https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev Bitcoin development mailing list]. + +Vetting an idea publicly before going as far as writing a BIP is meant to save both the potential author and the wider community time. +Asking the Bitcoin community first if an idea is original helps prevent too much time being spent on something that is guaranteed to be rejected based on prior discussions (searching the internet does not always do the trick). +It also helps to make sure the idea is applicable to the entire community and not just the author. Just because an idea sounds good to the author does not mean it will work for most people in most areas where Bitcoin is used. + +Once the champion has asked the Bitcoin community as to whether an idea has any chance of acceptance, a draft BIP should be presented to the [https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev Bitcoin development mailing list]. +This gives the author a chance to flesh out the draft BIP to make it properly formatted, of high quality, and to address additional concerns about the proposal. +Following a discussion, the proposal should be submitted to the [https://github.com/bitcoin/bips BIPs git repository] as a pull request. +This draft must be written in BIP style as described below, and named with an alias such as "bip-johndoe-infinitebitcoins" until the editor has assigned it a BIP number (authors MUST NOT self-assign BIP numbers). + +BIP authors are responsible for collecting community feedback on both the initial idea and the BIP before submitting it for review. However, wherever possible, long open-ended discussions on public mailing lists should be avoided. Strategies to keep the discussions efficient include: setting up a separate SIG mailing list for the topic, having the BIP author accept private comments in the early design phases, setting up a wiki page or git repository, etc. BIP authors should use their discretion here. + +It is highly recommended that a single BIP contain a single key proposal or new idea. The more focused the BIP, the more successful it tends to be. If in doubt, split your BIP into several well-focused ones. + +When the BIP draft is complete, the BIP editor will assign the BIP a number, label it as Standards Track, Informational, or Process, and merge the pull request to the BIPs git repository. +The BIP editor will not unreasonably reject a BIP. +Reasons for rejecting BIPs include duplication of effort, disregard for formatting rules, being too unfocused or too broad, being technically unsound, not providing proper motivation or addressing backwards compatibility, or not in keeping with the Bitcoin philosophy. +For a BIP to be accepted it must meet certain minimum criteria. +It must be a clear and complete description of the proposed enhancement. +The enhancement must represent a net improvement. +The proposed implementation, if applicable, must be solid and must not complicate the protocol unduly. + +The BIP author may update the draft as necessary in the git repository. Updates to drafts should also be submitted by the author as pull requests. + +===Transferring BIP Ownership=== + +It occasionally becomes necessary to transfer ownership of BIPs to a new champion. In general, we'd like to retain the original author as a co-author of the transferred BIP, but that's really up to the original author. A good reason to transfer ownership is because the original author no longer has the time or interest in updating it or following through with the BIP process, or has fallen off the face of the 'net (i.e. is unreachable or not responding to email). A bad reason to transfer ownership is because you don't agree with the direction of the BIP. We try to build consensus around a BIP, but if that's not possible, you can always submit a competing BIP. + +If you are interested in assuming ownership of a BIP, send a message asking to take over, addressed to both the original author and the BIP editor. If the original author doesn't respond to email in a timely manner, the BIP editor will make a unilateral decision (it's not like such decisions can't be reversed :). + +===BIP Editors=== + +The current BIP editor is Luke Dashjr who can be contacted at [[mailto:luke_bipeditor@dashjr.org|luke_bipeditor@dashjr.org]]. + +===BIP Editor Responsibilities & Workflow=== + +The BIP editor subscribes to the Bitcoin development mailing list. +Off-list BIP-related correspondence should be sent (or CC'd) to luke_bipeditor@dashjr.org. + +For each new BIP that comes in an editor does the following: + +* Read the BIP to check if it is ready: sound and complete. The ideas must make technical sense, even if they don't seem likely to be accepted. +* The title should accurately describe the content. +* The BIP draft must have been sent to the Bitcoin development mailing list for discussion. +* Motivation and backward compatibility (when applicable) must be addressed. +* Licensing terms must be acceptable for BIPs. + +If the BIP isn't ready, the editor will send it back to the author for revision, with specific instructions. + +Once the BIP is ready for the repository it should be submitted as a "pull request" to the [https://github.com/bitcoin/bips BIPs git repository] where it may get further feedback. + +The BIP editor will: + +* Assign a BIP number in the pull request. + +* Merge the pull request when it is ready. + +* List the BIP in [[README.mediawiki]] + +The BIP editors are intended to fulfill administrative and editorial responsibilities. The BIP editors monitor BIP changes, and update BIP headers as appropriate. + +==BIP format and structure== + +===Specification=== + +BIPs should be written in mediawiki format. + +Each BIP should have the following parts: + +* Preamble -- Headers containing metadata about the BIP ([[#BIP header preamble|see below]]). + +* Abstract -- A short (~200 word) description of the technical issue being addressed. + +* Copyright -- The BIP must be explicitly licensed under acceptable copyright terms ([[#BIP licensing|see below]]). + +* Specification -- The technical specification should describe the syntax and semantics of any new feature. The specification should be detailed enough to allow competing, interoperable implementations for any of the current Bitcoin platforms. + +* Motivation -- The motivation is critical for BIPs that want to change the Bitcoin protocol. It should clearly explain why the existing protocol is inadequate to address the problem that the BIP solves. + +* Rationale -- The rationale fleshes out the specification by describing what motivated the design and why particular design decisions were made. It should describe alternate designs that were considered and related work. The rationale should provide evidence of consensus within the community and discuss important objections or concerns raised during discussion. + +* Backwards compatibility -- All BIPs that introduce backwards incompatibilities must include a section describing these incompatibilities and their severity. The BIP must explain how the author proposes to deal with these incompatibilities. + +* Reference implementation -- The reference implementation must be completed before any BIP is given status "Final", but it need not be completed before the BIP is accepted. It is better to finish the specification and rationale first and reach consensus on it before writing code. The final implementation must include test code and documentation appropriate for the Bitcoin protocol. + +====BIP header preamble==== + +Each BIP must begin with an RFC 822 style header preamble. The headers must appear in the following order. Headers marked with "*" are optional and are described below. All other headers are required. + +
+  BIP: 
+  Title: 
+  Author: 
+* Discussions-To: 
+* Comments-Summary: 
+  Comments-URI: 
+  Status: 
+  Type: 
+  Created: 
+  License: 
+* License-Code: 
+* Post-History: 
+* Requires: 
+* Replaces: 
+* Superseded-By: 
+
+ +The Author header lists the names and email addresses of all the authors/owners of the BIP. +The format of the Author header value must be + + Random J. User + +If there are multiple authors, each should be on a separate line following RFC 2822 continuation line conventions. + +While a BIP is in private discussions (usually during the initial Draft phase), a Discussions-To header will indicate the mailing list or URL where the BIP is being discussed. No Discussions-To header is necessary if the BIP is being discussed privately with the author, or on the bitcoin email mailing lists. + +The Type header specifies the type of BIP: Standards Track, Informational, or Process. + +The Created header records the date that the BIP was assigned a number, while Post-History is used to record when new versions of the BIP are posted to bitcoin mailing lists. +Dates should be in yyyy-mm-dd format, e.g. 2001-08-14. +Post-History is permitted to be a link to a specific thread in a mailing list archive. + +BIPs may have a Requires header, indicating the BIP numbers that this BIP depends on. + +BIPs may also have a Superseded-By header indicating that a BIP has been rendered obsolete by a later document; the value is the number of the BIP that replaces the current document. The newer BIP must have a Replaces header containing the number of the BIP that it rendered obsolete. + +====Auxiliary Files==== + +BIPs may include auxiliary files such as diagrams. Auxiliary files should be included in a subdirectory for that BIP, or must be named BIP-XXXX-Y.ext, where "XXXX" is the BIP number, "Y" is a serial number (starting at 1), and "ext" is replaced by the actual file extension (e.g. "png"). + +==BIP types== + +There are three kinds of BIP: + +* A Standards Track BIP describes any change that affects most or all Bitcoin implementations, such as a change to the network protocol, a change in block or transaction validity rules, or any change or addition that affects the interoperability of applications using Bitcoin. Standards Track BIPs consist of two parts, a design document and a reference implementation. +* An Informational BIP describes a Bitcoin design issue, or provides general guidelines or information to the Bitcoin community, but does not propose a new feature. Informational BIPs do not necessarily represent a Bitcoin community consensus or recommendation, so users and implementors are free to ignore Informational BIPs or follow their advice. +* A Process BIP describes a process surrounding Bitcoin, or proposes a change to (or an event in) a process. Process BIPs are like Standards Track BIPs but apply to areas other than the Bitcoin protocol itself. They may propose an implementation, but not to Bitcoin's codebase; they often require community consensus; unlike Informational BIPs, they are more than recommendations, and users are typically not free to ignore them. Examples include procedures, guidelines, changes to the decision-making process, and changes to the tools or environment used in Bitcoin development. Any meta-BIP is also considered a Process BIP. + ==BIP status field== ===Specification=== +The typical paths of the status of BIPs are as follows: + + + Champions of a BIP may decide on their own to change the status between Draft, Deferred, or Withdrawn. +The BIP editor may also change the status to Deferred when no progress is being made on the BIP. -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. +A BIP may only change status from Draft (or Rejected) to Proposed, 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. +BIPs should be changed from Draft or Proposed 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 Proposed 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. +An Proposed 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. @@ -51,7 +209,7 @@ These criteria are considered objective ways to observe the de facto adoption of 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. +* 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 Proposed 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? @@ -102,18 +260,25 @@ What if a BIP is proposed that only makes sense for a single specific project? ===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]. +Each BIP should, in its preamble, link to a public 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. 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 . +Pages must be named after the full BIP number (eg, "BIP 0001") and placed in the "Comments" namespace. +For example, the link for BIP 1 will be https://github.com/bitcoin/bips/wiki/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. +Comments posted to this wiki should use the following format: -Summary tones may be chosen from the following, but this BIP does not intend to cover all possible nuances: + --, + +BIPs may also choose to list a second forum for BIP comments, in addition to the BIPs wiki. +In this case, the second forum's URI should be listed below the primary wiki's URI. + +After some time, the BIP itself may be updated with a summary tone of the comments. +Summary tones may be chosen from the following, but this BIP does not intend to cover all possible nuances and other summaries may be used as needed: * No comments yet. * Unanimously Recommended for implementation @@ -124,7 +289,7 @@ Summary tones may be chosen from the following, but this BIP does not intend to 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 + Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0001 https://some-other-wiki.org/BIP_1_Comments These fields must follow the "Discussions-To" header defined in BIP 1 (if that header is not present, it should follow the position where it would be present; generally this is immediately above the Status header). @@ -139,14 +304,13 @@ What is the purpose of BIP comments? 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. +* Participants should freely refrain from commenting outside of their area of knowledge or expertise. However, comments should not be censored, and participation should be open to the public. ==BIP licensing== ===Specification=== -New BIPs may be accepted with the following licenses. Each new BIP must identify at least one acceptable license in its preamble. The License header in the preamble must be placed after the Created header. Each license must be referenced by their respecitve abbreviation given below. +New BIPs may be accepted with the following licenses. Each new BIP must identify at least one acceptable license in its preamble. The License header in the preamble must be placed after the Created header. Each license must be referenced by their respective abbreviation given below. For example, a preamble might include the following License header: @@ -172,7 +336,10 @@ For a later version (eg, GPL 3.0), you would increase the version number (and re License-Code: GPL-3.0 # This refers to GPL v3.0 *only*, no later license versions are acceptable. License-Code: GPL-3.0+ # This refers to GPL v3.0 *or later*. -In the event that the text or code is not available under common license terms, the list should instead be replaced with the single term "Complex", and full details provided in the Copyright section of the BIP. +In the event that the licensing for the text or code is too complicated to express with a simple list of alternatives, the list should instead be replaced with the single term "Complex". In all cases, details of the licensing terms must be provided in the Copyright section of the BIP. + +BIPs are not required to be *exclusively* licensed under approved terms, and may also be licensed under unacceptable licenses *in addition to* at least one acceptable license. +In this case, only the acceptable license(s) should be listed in the License and License-Code headers. ====Recommended licenses==== @@ -194,10 +361,14 @@ In addition, it is recommended that literal code included in the BIP be dual-lic * FDL-1.3: [http://www.gnu.org/licenses/fdl-1.3.en.html GNU Free Documentation License, version 1.3] * GPL-2.0+: [http://www.gnu.org/licenses/old-licenses/gpl-2.0.en.html GNU General Public License (GPL), version 2 or newer] * LGPL-2.1+: [http://www.gnu.org/licenses/old-licenses/lgpl-2.1.en.html GNU Lesser General Public License (LGPL), version 2.1 or newer] -* OPL: [http://opencontent.org/openpub/ Open Publication License, version 1.0] -Additionally, PD is used to express that the work is placed in the public domain. -This may not be used for new BIPs, and is only defined for use by BIPs predating acceptance of this BIP. +====Not acceptable licenses==== + +All licenses not explicitly included in the above lists are not acceptable terms for a Bitcoin Improvement Proposal unless a later BIP extends this one to add them. +However, BIPs predating the acceptance of this BIP were allowed under other terms, and should use these abbreviation when no other license is granted: + +* OPL: [http://opencontent.org/openpub/ Open Publication License, version 1.0] +* PD: Released into the public domain ===Rationale=== @@ -205,6 +376,7 @@ BIP 1 allowed the Open Publication License or releasing into the public domain; * 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. +* The OPL license terms allowed for the author to prevent publication and derived works, which was widely considered inappropriate for Bitcoin standards. * Public domain is not universally recognised as a legitimate action, thus it is inadvisable. Why are there software licenses included? @@ -216,6 +388,19 @@ Why is Public Domain no longer acceptable for new BIPs? * In some jurisdictions, public domain is not recognised as a legitimate legal action, leaving the BIP simply copyrighted with no redistribution or modification allowed at all. +==Changes from BIP 1== + +* Acceptable licenses are entirely rechosen, allowing a wide variety of open licenses, while prohibiting the problematic older choices. +* Accepted Status has been renamed to Proposed. +* An implementation is now required (when applicable) before BIPs can proceed to Proposed Status. +* BIP Comments are newly introduced. +* The License preamble headers have been added. +* Non-image auxiliary files are permitted in the bip-XXXX subdirectory. +* Email addresses are now required for authors. +* The Post-History header may be provided as a link instead of a simple date. +* Markdown format is no longer permitted for BIPs. +* The Resolution header has been dropped, as it is not applicable to a decentralised system where no authority exists to make final decisions. + ==See Also== * [[bip-0001.mediawiki|BIP 1: BIP Purpose and Guidelines]] diff --git a/bip-0002/process.png b/bip-0002/process.png new file mode 100644 index 00000000..a834947f Binary files /dev/null and b/bip-0002/process.png differ diff --git a/bip-0002/process.svg b/bip-0002/process.svg new file mode 100644 index 00000000..efaa02b0 --- /dev/null +++ b/bip-0002/process.svg @@ -0,0 +1,49 @@ + + + + + + + + + + Draft + + + Proposed + + + Final/Active + + + Replaced + + + + Rejected + + + + + Withdrawn + + + + Deferred + + diff --git a/bip-0009/assignments.mediawiki b/bip-0009/assignments.mediawiki index e145ceb0..6a12e791 100644 --- a/bip-0009/assignments.mediawiki +++ b/bip-0009/assignments.mediawiki @@ -27,11 +27,11 @@ State can be defined, active, failed. Dates are in UTC. |- | segwit | 1 -| TBD -| TBD +| 2016-11-15 00:00:00 +| 2017-11-15 00:00:00 | - | 2016-05-01 00:00:00 | 2017-05-01 00:00:00 | active since #834624 -| [[/bip-0141.mediawiki|141]], [[/bip-0143.mediawiki|143]] +| [[/bip-0141.mediawiki|141]], [[/bip-0143.mediawiki|143]], [[/bip-0147.mediawiki|147]] |} diff --git a/bip-0023.mediawiki b/bip-0023.mediawiki index 874e60a1..03909587 100644 --- a/bip-0023.mediawiki +++ b/bip-0023.mediawiki @@ -13,7 +13,7 @@ This BIP describes extensions to the getblocktemplate JSON-RPC call to enhance p ==Specification== -Note that all sections of this specification are optional extensions on top of [[BIP 0022|BIP 22]]. +Note that all sections of this specification are optional extensions on top of [[bip-0022.mediawiki|BIP 22]]. ===Summary Support Levels=== diff --git a/bip-0039.mediawiki b/bip-0039.mediawiki index 3c95d4d1..f0f59099 100644 --- a/bip-0039.mediawiki +++ b/bip-0039.mediawiki @@ -33,7 +33,7 @@ sentences (also known as brainwallets) into a wallet seed. The mnemonic must encode entropy in a multiple of 32 bits. With more entropy security is improved but the sentence length increases. We refer to the -initial entropy length as ENT. The recommended size of ENT is 128-256 bits. +initial entropy length as ENT. The allowed size of ENT is 128-256 bits. First, an initial entropy of ENT bits is generated. A checksum is generated by taking the first 
ENT / 32
bits of its SHA256 hash. This checksum is diff --git a/bip-0044.mediawiki b/bip-0044.mediawiki index e17c73d1..c289887a 100644 --- a/bip-0044.mediawiki +++ b/bip-0044.mediawiki @@ -267,7 +267,7 @@ is required and a pull request to the above file should be created. * [[https://play.google.com/store/apps/details?id=com.mycelium.wallet|Mycelium Bitcoin Wallet (Android)]] ([[https://github.com/mycelium-com/wallet|source]]) * [[https://copay.io/|Copay]] ([[https://github.com/bitpay/copay|source]]) * [[https://maza.club/encompass|Encompass]] ([[https://github.com/mazaclub/encompass|source]]) -* [[https://www.coinvault.io/|CoinVault]] +* [[https://www.coinvault.io/|CoinVault]] ([[https://github.com/CoinVault/dotblock|source]]) ==Reference== * [[bip-0032.mediawiki|BIP32 - Hierarchical Deterministic Wallets]] diff --git a/bip-0049.mediawiki b/bip-0049.mediawiki new file mode 100644 index 00000000..4460ba76 --- /dev/null +++ b/bip-0049.mediawiki @@ -0,0 +1,104 @@ +
+  BIP: 49
+  Title: Derivation scheme for P2WPKH-nested-in-P2SH based accounts
+  Author: Daniel Weigl 
+  Status: Draft
+  Type: Informational
+  Created: 2016-05-19
+
+ +==Abstract== + +This BIP defines the derivation scheme for HD wallets using the P2WPKH-nested-in-P2SH ([[bip-0141.mediawiki|BIP 141]]) serialization format for segregated witness transactions. + +==Motivation== + +With the usage of P2WPKH-nested-in-P2SH ([[bip-0141.mediawiki#p2wpkh-nested-in-bip16-p2sh|BIP 141]]) transactions it is necessary to have a common derivation scheme. +It allows the user to use different HD wallets with the same masterseed and/or a single account seamlessly. + +Thus the user needs to create a dedicated segregate witness accounts, which ensures that only wallets compatible with this BIP +will detect the account and handle them appropriately. + +===Considerations=== +Two generally different approaches are possible for current BIP44 capable wallets: + +1) Allow the user to use the same account(s) that they already uses, but add segregated witness encoded addresses to it + +1.1) Use the same public keys as defined in BIP44, but in addition to the normal P2PKH address also derive the P2SH address from it. + +1.2) Use the same account root, but branch off and derive different external and internal chain roots to derive dedicated public keys for the segregated witness addresses. + +2) Create dedicated accounts only used for segregated witness addresses. + +The solutions from point 1 have a common disadvantage: if a user imports/recovers a BIP49-compatible wallet masterseed into/in a non-BIP49-compatible wallet, the account might show up but also it might miss some UTXOs. + +Therefore this BIP uses solution 2, which fails in a more visible way. Either the account shows up or not at all. The user does not have to check his balance after using the same seed in different wallets. + + +==Specifications== + +This BIP defines the two needed steps to derive multiple deterministic addresses based on a [[bip-0032.mediawiki|BIP 32]] root account. + +===Public key derivation=== + +To derive a public key from the root account, this BIP uses the same account-structure as defined in +[[bip-0044.mediawiki|BIP 44]], but only uses a different purpose value to indicate the different transaction +serialization method. + +
+m / purpose' / coin_type' / account' / change / address_index
+
+ +For the `purpose`-path level it uses `49'`. The rest of the levels are used as defined in BIP44 + + +===Address derivation=== + +To derive the P2SH address from the above calculated public key, we use the encapsulation defined in [[bip-0141.mediawiki#p2wpkh-nested-in-bip16-p2sh|BIP 141]]: + + witness: + scriptSig: <0 <20-byte-key-hash>> + (0x160014{20-byte-key-hash}) + scriptPubKey: HASH160 <20-byte-script-hash> EQUAL + (0xA914{20-byte-script-hash}87) + +==Backwards Compatibility== + +This BIP is not backwards compatible by design as described under [#considerations]. A not compatible wallet will not discover accounts at all and the user will notice that something is wrong. + + +==Test vectors== + +
+  masterseedWords = abandon abandon abandon abandon abandon abandon abandon abandon abandon abandon abandon about
+  masterseed = tprv8ZgxMBicQKsPe5YMU9gHen4Ez3ApihUfykaqUorj9t6FDqy3nP6eoXiAo2ssvpAjoLroQxHqr3R5nE3a5dU3DHTjTgJDd7zrbniJr6nrCzd (testnet)
+
+  // Account 0, root = m/49'/1'/0'
+  account0Xpriv = tprv8gRrNu65W2Msef2BdBSUgFdRTGzC8EwVXnV7UGS3faeXtuMVtGfEdidVeGbThs4ELEoayCAzZQ4uUji9DUiAs7erdVskqju7hrBcDvDsdbY (testnet)
+
+  // Account 0, first receiving private key = m/49'/1'/0'/0/0
+  account0recvPrivateKey = cULrpoZGXiuC19Uhvykx7NugygA3k86b3hmdCeyvHYQZSxojGyXJ
+  account0recvPrivateKeyHex = 0xc9bdb49cfbaedca21c4b1f3a7803c34636b1d7dc55a717132443fc3f4c5867e8
+  account0recvPublickKeyHex = 0x03a1af804ac108a8a51782198c2d034b28bf90c8803f5a53f76276fa69a4eae77f
+
+  // Address derivation
+  keyhash = HASH160(account0recvPublickKeyHex) = 0x38971f73930f6c141d977ac4fd4a727c854935b3
+  scriptSig = <0 > = 0x001438971f73930f6c141d977ac4fd4a727c854935b3
+  addressBytes = HASH160(scriptSig) = 0x336caa13e08b96080a32b5d818d59b4ab3b36742
+
+  // addressBytes base58check encoded for testnet
+  address = base58check(prefix | addressBytes) = 2Mww8dCYPUpKHofjgcXcBCEGmniw9CoaiD2 (testnet)
+
+ + +==Reference== + +* [[bip-0016.mediawiki|BIP16 - Pay to Script Hash]] +* [[bip-0032.mediawiki|BIP32 - Hierarchical Deterministic Wallets]] +* [[bip-0043.mediawiki|BIP43 - Purpose Field for Deterministic Wallets]] +* [[bip-0044.mediawiki|BIP44 - Multi-Account Hierarchy for Deterministic Wallets]] +* [[bip-0141.mediawiki|BIP141 - Segregated Witness (Consensus layer)]] + +== Copyright == + +This document is placed in the public domain. \ No newline at end of file diff --git a/bip-0112.mediawiki b/bip-0112.mediawiki index 0397332a..40378ee7 100644 --- a/bip-0112.mediawiki +++ b/bip-0112.mediawiki @@ -59,10 +59,10 @@ established in the following way. Alice, Bob and Escrow create a 2-of-3 address with the following redeemscript. IF - 2 3 CHECKMULTISIGVERIFY + 2 3 CHECKMULTISIG ELSE "30d" CHECKSEQUENCEVERIFY DROP - CHECKSIGVERIFY + CHECKSIG ENDIF At any time funds can be spent using signatures from any two of Alice, diff --git a/bip-0126.mediawiki b/bip-0126.mediawiki index eed0c3ea..43722d0d 100644 --- a/bip-0126.mediawiki +++ b/bip-0126.mediawiki @@ -37,6 +37,10 @@ In order to achieve these goals, this specification proposes a set of best pract In order to achieve this, two forms of HIT are proposed: Standard form and alternate form. +==Interaction with Other Procedures== + +Applications which wish to comply both with this procedure and BIP69 should apply this procedure prior to applying BIP69. + ==Standard form heterogenous input script transaction== ===Rules=== @@ -96,3 +100,7 @@ An HIT formed via the preceding procedure will adhere to the following condition ==Non-compliant heterogenous input script transactions== If a user wishes to create an output that is larger than half the total size of their spendable outputs, or if their inputs are not distributed in a manner in which the alternate form procedure can be completed, then the user can not create a transaction which is compliant with this procedure. + +==Reference== + +* [[bip-0069.mediawiki|BIP69 - Lexicographical Indexing of Transaction Inputs and Outputs]] diff --git a/bip-0134.mediawiki b/bip-0134.mediawiki new file mode 100644 index 00000000..afb5143a --- /dev/null +++ b/bip-0134.mediawiki @@ -0,0 +1,245 @@ +
+  BIP: 134
+  Title: Flexible Transactions
+  Author: Tom Zander 
+  Status: Draft
+  Type: Standards Track
+  Created: 2016-07-27
+
+ +==Abstract== + +This BIP describes the next step in making Bitcoin's most basic element, +the transaction, more flexible and easier to extend. At the same time this +fixes all known cases of malleability and resolves significant amounts of +technical debt. + +==Summary== + +Flexible Transactions uses the fact that the first 4 bytes in a transaction +determine the version and that the majority of the clients use a +non-consensus rule (a policy) to not accept transaction version numbers +other than those specifically defined by Bitcoin. +This BIP chooses a new version number, 4, and defines that the data +following the bytes for the version is in a format called Compact Message +Format (CMF). CMF is a flexible, token based format where each token is a +combination of a name, a format and a value. Because the name is added we +can skip unused tokens and we can freely add new tokens in a simple manner +in future. Soft fork upgrades will become much easier and cleaner this +way. + +This protocol upgrade cleans up past soft fork changes like BIP68 which +reuse existing fields and do them in a much better to maintain and easier +to parse system. It creates the building blocks to allow new features to be +added much cleaner in the future. + +It also shows to be possible to remove signatures from transactions with +minimal upgrades of software and still maintain a coherent transaction +history. Tests show that this can reduce space usage to about 75%. + +==Motivation== + +Token based file-formats are not new, systems like XML and HTMl use a +similar system to allow future growth and they have been quite successful +for decades in part because of this property. + +Bitcoin needs a similar way of making the transaction future-proof because +re-purposing not used fields for new features is not good for creating +maintainable code. + +Next to that this protocol upgrade will re-order the data-fields which +allows us to cleanly fix the malleability issue which means that future +technologies like Lightning Network will depend on this BIP being deployed. + +At the same time, due to this re-ordering of data fields, it becomes very +easy to remove signatures from a transaction without breaking its tx-id, +which is great for future pruning features. + + +=== Tokens === + +In the compact message format we define tokens and in this specification we +define how these tokens are named, where they can be placed and which are +optional. To refer to XML, this specification would be the schema of +a transaction. + +CMF tokens are triplets of name, format (like PositiveInteger) and value. +Names in this scope are defined much like an enumeration where the actual +integer value (id, below) is equally important to the written name. +If any token found that is not covered in the next table it will make the +transaction that contains it invalid. + +{| class="wikitable" +|- +! Name !! id !! Format !! Default Value !! Description +|- +|TxEnd || 0 ||BoolTrue || Required ||A marker that is end of the transaction. +|- +|TxInPrevHash || 1 ||ByteArray|| Required ||TxId we are spending +|- +|TxPrevIndex || 2 ||Integer || 0 ||Index in prev tx we are spending (applied to previous TxInPrevHash) +|- +|TxInScript || 3 ||ByteArray|| Required ||The 'input' part of the script +|- +|TxOutValue || 4 ||Integer || Required ||Amount of Satoshis to transfer +|- +|TxOutScript || 5 ||ByteArray|| Required ||The 'output' part of the script +|- +|LockByBlock || 6 ||Integer || Optional ||BIP68 replacement +|- +|LockByTime || 7 ||Integer || Optional ||BIP68 replacement +|- +|ScriptVersion || 8 ||Integer || 2 ||Defines script version for outputs following +|- +|NOP_1x || 1x || . || Optional ||Values that will be ignored by anyone parsing the transaction +|} + + +=== Scripting changes === + +In the current version of Bitcoin-script, version 1, there are various +opcodes that are used to validate the cryptographic proofs that users have +to provide in order to spend outputs. + +The OP_CHECKSIG is the most well known and, as its name implies, it +validates a signature. +In the new version of 'script' (version 2) the data that is signed is +changed to be equivalent to the transaction-id. This is a massive +simplification and also the only change between version 1 and version 2 of +script. + +=== Serialization order=== + +The tokens defined above shall be serialized in a certain order for the +transaction to be valid. Not serializing transactions in the +order specified would allow multiple interpretations of the data which +can't be allowed. +There is still some flexibility and for that reason it is important for +implementors to remember that the actual serialized data is used for the +calculation of the transaction-id. Reading and writing it may give you a +different output and when the txid changes, the signatures will break. + +At a macro-level the transaction has these segments. The order of the +segments can not be changed, but you can skip segments. + +{| class="wikitable" +!Segment !! Description +|- +| Inputs || Details about inputs. +|- +| Outputs || Details and scripts for outputs +|- +| Additional || For future expansion +|- +| Signatures || The scripts for the inputs +|- +| TxEnd || End of the transaction +|} + +The TxId is calculated by taking the serialized transaction without the +Signatures and the TxEnd and hashing that. + + +{| class="wikitable" +!Segment !! Tags !! Description +|- +|Inputs||TxInPrevHash and TxInPrevIndex||Index can be skipped, but in any input the PrevHash always has to come first +|- +|Outputs||TxOutScript, TxOutValue||Order is not relevant +|- +|Additional||LockByBlock LockByTime NOP_1x +|- +|Signatures||TxInScript||Exactly the same amount as there are inputs +|- +|TxEnd||TxEnd +|} + +TxEnd is there to allow a parser to know when one transaction in a stream +has ended, allowing the next to be parsed. + +Notice that the token ScriptVersion is currently not allowed because we +don't have any valid value to give it. But if we introduce a new script +version it would be placed in the outputs segment. + +=== Script v2 === + +The default value of ScriptVersion is number 2, as opposed to the version 1 +of script that is in use today. The version 2 is mostly identical +to version one, including upgrades made to it over the years and in the +future. The only exception is that the OP_CHECKSIG is made dramatically +simpler. The input-type for OP_CHECKSIG is now no longer configurable, it is +always '1' and the content that will be signed is the txid. + +TODO: does check-multisig need its own mention? + + +=== Block-malleability === + +The effect of leaving the signatures out of the calculation of the +transaction-id implies that the signatures are also not used for the +calculation of the merkle tree. This means that changes in signatures +would not be detectable. Except naturally by the fact that missing or +broken signatures breaks full validation. But it is important to detect +modifications to such signatures outside of validating all transactions. + +For this reason the merkle tree is extended to include (append) the hash of +the v4 transactions. The markle tree will continue to have all the +transactions' tx-ids but appended to that are the v4 hashes that include the +signatures as well. Specifically the hash is taken over a data-blob that +is built up from: + +1. the tx-id +2. the CMF-tokens 'TxInScript' + + +=== Future extensibility === + +The NOP_1x wildcard used in the table explaining tokens is actually a list +of 10 values that currently are specified as NOP (no-operation) tags. + +Any implementation that supports the v4 transaction format should ignore +this field in a transaction. Interpreting and using the transaction as if +that field was not present at all. + +Future software may use these fields to decorate a transaction with +additional data or features. Transaction generating software should not +trivially use these tokens for their own usage without cooperation and +communication with the rest of the Bitcoin ecosystem as miners certainly +have the option to reject transactions that use unknown-to-them tokens. + +==Backwards compatibility == + +Fully validating older clients are not compatible with this change. + +SPV (simple payment validation) wallets need to be updated to receive or +create the new transaction type. + +This BIP introduces a new transaction format without changing or +deprecating the existing one or any of its practices. Therefore it is +backwards compatible for any existing data or parsing-code. + +==Reference Implementation== + +Bitcoin Classic includes this in its beta releases and a reference +implementation can be found at; + +https://github.com/bitcoinclassic/bitcoinclassic/pull/186 + + +==Deployment== + +To be determined + +==References== + +[https://github.com/bitcoinclassic/documentation/blob/master/spec/compactmessageformat.md] CMF + +==Copyright== + +Copyright (c) 2016 Tom Zander + +This document is dual-licensed under the Creative-Commons BY-SA license v4.0 +and the Open Publication License v1.0 with the following licence-options: + +Distribution of substantively modified versions of this document is prohibited without the explicit permission of the copyright holder. +Distribution of the work or derivative of the work in any standard (paper) book form is prohibited unless prior permission is obtained from the copyright holder. diff --git a/bip-0141.mediawiki b/bip-0141.mediawiki index ccf18b62..352256f7 100644 --- a/bip-0141.mediawiki +++ b/bip-0141.mediawiki @@ -125,6 +125,32 @@ The sigop limit is likewise quadrupled to ≤ 80,000. Each P2WPKH input is counted as 1 sigop. In addition, opcodes within a P2WSH witnessScript are counted identically as previously within the P2SH redeemScript. That is, CHECKSIG is counted as only 1 sigop, and CHECKMULTISIG is counted as 1 to 20 sigops according to the arguments. This rule applies to both native witness program and P2SH witness program. +=== Additional definitions === + +The following definitions are not used for consensus limits, but are suggested to provide language consistent with the terminology introduced above. + +==== Transaction size calculations ==== + +''Transaction weight'' is defined as ''Base transaction size'' * 3 + ''Total transaction size'' (ie. the same method as calculating ''Block weight'' from ''Base size'' and ''Total size''). + +''Virtual transaction size'' is defined as ''Transaction weight'' / 4 (rounded up to the next integer). + +''Base transaction size'' is the size of the transaction serialised with the witness data stripped. + +''Total transaction size'' is the transaction size in bytes serialized as described in [[bip-0144.mediawiki|BIP144]], including base data and witness data. + +=== New script semantics === + +Despite that the script language for P2WPKH and P2WSH looks very similar to pre-segregated witness script, there are several notable differences. Users MUST NOT assume that a script spendable in pre-segregated witness system would also be spendable as a P2WPKH or P2WSH script. Before large-scale deployment in the production network, developers should test the scripts on testnet with the default relay policy turned on, and with a small amount of money after BIP141 is activated on mainnet. + +A major difference at consensus level is described in [https://github.com/bitcoin/bips/blob/master/bip-0143.mediawiki BIP143], as a new transaction digest algorithm for signature verification in version 0 witness program. + +Three relay and mining policies are also included in the first release of segregated witness at reference implementation version 0.13.1. Softforks based on these policies are likely to be proposed in the near future. To avoid indefinite delay in transaction confirmation and permanent fund loss in a potential softfork, users MUST observe the new semantics carefully: + +# Only compressed public keys are accepted in P2WPKH and P2WSH (See [https://github.com/bitcoin/bips/blob/master/bip-0143.mediawiki#Restrictions_on_public_key_type BIP143]) +# The argument of OP_IF/NOTIF in P2WSH must be minimalhttps://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-August/013014.html +# Signature(s) must be null vector(s) if an OP_CHECKSIG or OP_CHECKMULTISIG is failed (for both pre-segregated witness script and P2WSH. See [https://github.com/bitcoin/bips/blob/master/bip-0146.mediawiki BIP146]) + == Examples == === P2WPKH === @@ -273,7 +299,7 @@ As a soft fork, older software will continue to operate without modification. N This BIP will be deployed by "version bits" BIP9 with the name "segwit" and using bit 1. -For Bitcoin mainnet, the BIP9 starttime will be midnight TBD UTC (Epoch timestamp TBD) and BIP9 timeout will be midnight TBD UTC (Epoch timestamp TBD). +For Bitcoin mainnet, the BIP9 starttime will be midnight 15 november 2016 UTC (Epoch timestamp 1479168000) and BIP9 timeout will be midnight 15 november 2017 UTC (Epoch timestamp 1510704000). For Bitcoin testnet, the BIP9 starttime will be midnight 1 May 2016 UTC (Epoch timestamp 1462060800) and BIP9 timeout will be midnight 1 May 2017 UTC (Epoch timestamp 1493596800). diff --git a/bip-0143.mediawiki b/bip-0143.mediawiki index 892c0278..766fd9f2 100644 --- a/bip-0143.mediawiki +++ b/bip-0143.mediawiki @@ -12,7 +12,7 @@ This proposal defines a new transaction digest algorithm for signature verification in version 0 witness program, in order to minimize redundant data hashing in verification, and to cover the input value by the signature. == Motivation == -There are 4 ECDSA signature verification codes in the original Bitcoin script system: CHECKSIG, CHECKSIGVERIFY, CHECKMULTISIG, CHECKMULTISIGVERIFY (“sigops”). According to the sighash type (ALL, NONE, SINGLE, ANYONECANPAY), a transaction digest is generated with a double SHA256 of a serialized subset of the transaction, and the signature is verified against this digest with a given public key. The detailed procedure is described in a Bitcoin Wiki article. [https://en.bitcoin.it/wiki/OP_CHECKSIG] +There are 4 ECDSA signature verification codes in the original Bitcoin script system: CHECKSIG, CHECKSIGVERIFY, CHECKMULTISIG, CHECKMULTISIGVERIFY (“sigops”). According to the sighash type (ALL, NONE, SINGLE, ANYONECANPAY), a transaction digest is generated with a double SHA256 of a serialized subset of the transaction, and the signature is verified against this digest with a given public key. The detailed procedure is described in a Bitcoin Wiki article. [https://en.bitcoin.it/wiki/OP_CHECKSIG] Unfortunately, there are at least 2 weaknesses in the original SignatureHash transaction digest algorithm: @@ -39,16 +39,16 @@ Semantics of the original sighash types remain unchanged, except the followings: # The way of serialization is changed; # All sighash types commit to the amount being spent by the signed input; # FindAndDelete of the signature is not applied to the scriptCode; -# OP_CODESEPARATOR(s) after the last executed OP_CODESEPARATOR are not removed from the scriptCode; +# OP_CODESEPARATOR(s) after the last executed OP_CODESEPARATOR are not removed from the scriptCode (the last executed OP_CODESEPARATOR and any script before it are always removed); # SINGLE does not commit to the input index. When ANYONECANPAY is not set, the semantics are unchanged since hashPrevouts and outpoint together implictly commit to the input index. When SINGLE is used with ANYONECANPAY, omission of the index commitment allows permutation of the input-output pairs, as long as each pair is located at an equivalent index. The items 1, 4, 7, 9, 10 have the same meaning as the original algorithm. The item 5: -*For P2WPKH witness program, the scriptCode is 0x1976a914{20-byte-pubkey-hash}88ac. -*For P2WSH witness program, -**if the witnessScript does not contain any OP_CODESEPARATOR, the scriptCode is the witnessScript serialized as scripts inside CTxOuts. -**if the witnessScript contains any OP_CODESEPARATOR, the scriptCode is the evaluated script, with everything up to and including the last executed OP_CODESEPARATOR before the signature checking opcode being executed removed, serialized as scripts inside CTxOuts. +*For P2WPKH witness program, the scriptCode is 0x1976a914{20-byte-pubkey-hash}88ac. +*For P2WSH witness program, +**if the witnessScript does not contain any OP_CODESEPARATOR, the scriptCode is the witnessScript serialized as scripts inside CTxOut. +**if the witnessScript contains any OP_CODESEPARATOR, the scriptCode is the witnessScript but removing everything up to and including the last executed OP_CODESEPARATOR before the signature checking opcode being executed, serialized as scripts inside CTxOut. (The exact semantics is demonstrated in the examples below) The item 6 is a 8-byte value of the amount of bitcoin spent in this input. @@ -125,7 +125,15 @@ Refer to the reference implementation, reproduced below, for the precise algorit return ss.GetHash(); +== Restrictions on public key type == +As a default policy, only compressed public keys are accepted in P2WPKH and P2WSH. Each public key passed to a sigop inside version 0 witness program must be a compressed key: the first byte MUST be either 0x02 or 0x03, and the size MUST be 33 bytes. Transactions that break this rule will not be relayed or mined by default. + +Since this policy is preparation for a future softfork proposal, to avoid potential future funds loss, users MUST NOT use uncompressed keys in version 0 witness programs. + == Example == + +To ensure consistency in consensus-critical behaviour, developers should test their implementations against all the tests below. More tests related to this proposal could be found under https://github.com/bitcoin/bitcoin/tree/master/src/test/data . + === Native P2WPKH === The following is an unsigned transaction: @@ -526,6 +534,82 @@ This example is a P2SH-P2WSH 6-of-6 multisig witness program signed with 6 diffe The serialized signed transaction is: 0100000000010136641869ca081e70f394c6948e8af409e18b619df2ed74aa106c1ca29787b96e0100000023220020a16b5755f7f6f96dbd65f5f0d6ab9418b89af4b1f14a1bb8a09062c35f0dcb54ffffffff0200e9a435000000001976a914389ffce9cd9ae88dcc0631e88a821ffdbe9bfe2688acc0832f05000000001976a9147480a33f950689af511e6e84c138dbbd3c3ee41588ac080047304402206ac44d672dac41f9b00e28f4df20c52eeb087207e8d758d76d92c6fab3b73e2b0220367750dbbe19290069cba53d096f44530e4f98acaa594810388cf7409a1870ce01473044022068c7946a43232757cbdf9176f009a928e1cd9a1a8c212f15c1e11ac9f2925d9002205b75f937ff2f9f3c1246e547e54f62e027f64eefa2695578cc6432cdabce271502473044022059ebf56d98010a932cf8ecfec54c48e6139ed6adb0728c09cbe1e4fa0915302e022007cd986c8fa870ff5d2b3a89139c9fe7e499259875357e20fcbb15571c76795403483045022100fbefd94bd0a488d50b79102b5dad4ab6ced30c4069f1eaa69a4b5a763414067e02203156c6a5c9cf88f91265f5a942e96213afae16d83321c8b31bb342142a14d16381483045022100a5263ea0553ba89221984bd7f0b13613db16e7a70c549a86de0cc0444141a407022005c360ef0ae5a5d4f9f2f87a56c1546cc8268cab08c73501d6b3be2e1e1a8a08824730440220525406a1482936d5a21888260dc165497a90a15669636d8edca6b9fe490d309c022032af0c646a34a44d1f4576bf6a4a74b67940f8faa84c7df9abe12a01a11e2b4783cf56210307b8ae49ac90a048e9b53357a2354b3334e9c8bee813ecb98e99a7e07e8c3ba32103b28f0c28bfab54554ae8c658ac5c3e0ce6e79ad336331f78c428dd43eea8449b21034b8113d703413d57761b8b9781957b8c0ac1dfe69f492580ca4195f50376ba4a21033400f6afecb833092a9a21cfdf1ed1376e58c5d1f47de74683123987e967a8f42103a6d48b1131e94ba04d9737d61acdaa1322008af9602b3b14862c07a1789aac162102d8b661b0b3302ee2f162b09e07a55ad5dfbe673a9f01d9f0c19617681024306b56ae00000000 +=== No FindAndDelete === + +These examples show that FindAndDelete for the signature is not applied. The transactions are generated in an unconventional way. Instead of signing using a private key, the signatures are pre-determined as part of witnessScript. The public keys are generated with key recovery, using the fixed signatures and the sighash defined in this proposal. Therefore, the private keys are unknown. + + + The following is an unsigned transaction: 010000000169c12106097dc2e0526493ef67f21269fe888ef05c7a3a5dacab38e1ac8387f14c1d000000ffffffff0101000000000000000000000000 + + nVersion: 01000000 + txin: 01 69c12106097dc2e0526493ef67f21269fe888ef05c7a3a5dacab38e1ac8387f1 4c1d0000 00 ffffffff + txout: 01 0100000000000000 00 + nLockTime: 00000000 + + The input comes from a P2WSH witness program: + scriptPubKey : 00209e1be07558ea5cc8e02ed1d80c0911048afad949affa36d5c3951e3159dbea19, value: 200000 + redeemScript : OP_CHECKSIGVERIFY <0x30450220487fb382c4974de3f7d834c1b617fe15860828c7f96454490edd6d891556dcc9022100baf95feb48f845d5bfc9882eb6aeefa1bc3790e39f59eaa46ff7f15ae626c53e01> + ad4830450220487fb382c4974de3f7d834c1b617fe15860828c7f96454490edd6d891556dcc9022100baf95feb48f845d5bfc9882eb6aeefa1bc3790e39f59eaa46ff7f15ae626c53e01 + + To sign it with a nHashType of 1 (SIGHASH_ALL): + + hashPrevouts: + dSHA256(69c12106097dc2e0526493ef67f21269fe888ef05c7a3a5dacab38e1ac8387f14c1d0000) + = b67c76d200c6ce72962d919dc107884b9d5d0e26f2aea7474b46a1904c53359f + + hashSequence: + dSHA256(ffffffff) + = 3bb13029ce7b1f559ef5e747fcac439f1455a2ec7c5f09b72290795e70665044 + + hashOutputs: + dSHA256(010000000000000000) + = e5d196bfb21caca9dbd654cafb3b4dc0c4882c8927d2eb300d9539dd0b934228 + + hash preimage: 01000000b67c76d200c6ce72962d919dc107884b9d5d0e26f2aea7474b46a1904c53359f3bb13029ce7b1f559ef5e747fcac439f1455a2ec7c5f09b72290795e7066504469c12106097dc2e0526493ef67f21269fe888ef05c7a3a5dacab38e1ac8387f14c1d00004aad4830450220487fb382c4974de3f7d834c1b617fe15860828c7f96454490edd6d891556dcc9022100baf95feb48f845d5bfc9882eb6aeefa1bc3790e39f59eaa46ff7f15ae626c53e01400d030000000000ffffffffe5d196bfb21caca9dbd654cafb3b4dc0c4882c8927d2eb300d9539dd0b9342280000000001000000 + + nVersion: 01000000 + hashPrevouts: b67c76d200c6ce72962d919dc107884b9d5d0e26f2aea7474b46a1904c53359f + hashSequence: 3bb13029ce7b1f559ef5e747fcac439f1455a2ec7c5f09b72290795e70665044 + outpoint: 69c12106097dc2e0526493ef67f21269fe888ef05c7a3a5dacab38e1ac8387f14c1d0000 + scriptCode: 4aad4830450220487fb382c4974de3f7d834c1b617fe15860828c7f96454490edd6d891556dcc9022100baf95feb48f845d5bfc9882eb6aeefa1bc3790e39f59eaa46ff7f15ae626c53e01 + amount: 400d030000000000 + nSequence: ffffffff + hashOutputs: e5d196bfb21caca9dbd654cafb3b4dc0c4882c8927d2eb300d9539dd0b934228 + nLockTime: 00000000 + nHashType: 01000000 + + sigHash: 71c9cd9b2869b9c70b01b1f0360c148f42dee72297db312638df136f43311f23 + signature: 30450220487fb382c4974de3f7d834c1b617fe15860828c7f96454490edd6d891556dcc9022100baf95feb48f845d5bfc9882eb6aeefa1bc3790e39f59eaa46ff7f15ae626c53e 01 + pubkey: 02a9781d66b61fb5a7ef00ac5ad5bc6ffc78be7b44a566e3c87870e1079368df4c + + The serialized signed transaction is: 0100000000010169c12106097dc2e0526493ef67f21269fe888ef05c7a3a5dacab38e1ac8387f14c1d000000ffffffff01010000000000000000034830450220487fb382c4974de3f7d834c1b617fe15860828c7f96454490edd6d891556dcc9022100baf95feb48f845d5bfc9882eb6aeefa1bc3790e39f59eaa46ff7f15ae626c53e012102a9781d66b61fb5a7ef00ac5ad5bc6ffc78be7b44a566e3c87870e1079368df4c4aad4830450220487fb382c4974de3f7d834c1b617fe15860828c7f96454490edd6d891556dcc9022100baf95feb48f845d5bfc9882eb6aeefa1bc3790e39f59eaa46ff7f15ae626c53e0100000000 + + nVersion: 01000000 + marker: 00 + flag: 01 + txin: 01 69c12106097dc2e0526493ef67f21269fe888ef05c7a3a5dacab38e1ac8387f1 4c1d0000 00 ffffffff + txout: 01 0100000000000000 00 + witness: 03 4830450220487fb382c4974de3f7d834c1b617fe15860828c7f96454490edd6d891556dcc9022100baf95feb48f845d5bfc9882eb6aeefa1bc3790e39f59eaa46ff7f15ae626c53e01 + 2102a9781d66b61fb5a7ef00ac5ad5bc6ffc78be7b44a566e3c87870e1079368df4c + 4aad4830450220487fb382c4974de3f7d834c1b617fe15860828c7f96454490edd6d891556dcc9022100baf95feb48f845d5bfc9882eb6aeefa1bc3790e39f59eaa46ff7f15ae626c53e01 + nLockTime: 00000000 + + + + The following transaction is a OP_CHECKMULTISIGVERIFY version of the FindAndDelete examples: 010000000001019275cb8d4a485ce95741c013f7c0d28722160008021bb469a11982d47a6628964c1d000000ffffffff0101000000000000000007004830450220487fb382c4974de3f7d834c1b617fe15860828c7f96454490edd6d891556dcc9022100baf95feb48f845d5bfc9882eb6aeefa1bc3790e39f59eaa46ff7f15ae626c53e0148304502205286f726690b2e9b0207f0345711e63fa7012045b9eb0f19c2458ce1db90cf43022100e89f17f86abc5b149eba4115d4f128bcf45d77fb3ecdd34f594091340c0395960101022102966f109c54e85d3aee8321301136cedeb9fc710fdef58a9de8a73942f8e567c021034ffc99dd9a79dd3cb31e2ab3e0b09e0e67db41ac068c625cd1f491576016c84e9552af4830450220487fb382c4974de3f7d834c1b617fe15860828c7f96454490edd6d891556dcc9022100baf95feb48f845d5bfc9882eb6aeefa1bc3790e39f59eaa46ff7f15ae626c53e0148304502205286f726690b2e9b0207f0345711e63fa7012045b9eb0f19c2458ce1db90cf43022100e89f17f86abc5b149eba4115d4f128bcf45d77fb3ecdd34f594091340c039596017500000000 + + redeemScript: OP_2 OP_CHECKMULTISIGVERIFY <30450220487fb382c4974de3f7d834c1b617fe15860828c7f96454490edd6d891556dcc9022100baf95feb48f845d5bfc9882eb6aeefa1bc3790e39f59eaa46ff7f15ae626c53e01> <304502205286f726690b2e9b0207f0345711e63fa7012045b9eb0f19c2458ce1db90cf43022100e89f17f86abc5b149eba4115d4f128bcf45d77fb3ecdd34f594091340c03959601> + hash preimage: 0100000039283953eb1e26994dde57b7f9362a79a8c523e2f8deba943c27e826a005f1e63bb13029ce7b1f559ef5e747fcac439f1455a2ec7c5f09b72290795e706650449275cb8d4a485ce95741c013f7c0d28722160008021bb469a11982d47a6628964c1d00009552af4830450220487fb382c4974de3f7d834c1b617fe15860828c7f96454490edd6d891556dcc9022100baf95feb48f845d5bfc9882eb6aeefa1bc3790e39f59eaa46ff7f15ae626c53e0148304502205286f726690b2e9b0207f0345711e63fa7012045b9eb0f19c2458ce1db90cf43022100e89f17f86abc5b149eba4115d4f128bcf45d77fb3ecdd34f594091340c0395960175400d030000000000ffffffffe5d196bfb21caca9dbd654cafb3b4dc0c4882c8927d2eb300d9539dd0b9342280000000001000000 + sighash: c1628a1e7c67f14ca0c27c06e4fdeec2e6d1a73c7a91d7c046ff83e835aebb72 + witness: 07 00 + 4830450220487fb382c4974de3f7d834c1b617fe15860828c7f96454490edd6d891556dcc9022100baf95feb48f845d5bfc9882eb6aeefa1bc3790e39f59eaa46ff7f15ae626c53e01 + 48304502205286f726690b2e9b0207f0345711e63fa7012045b9eb0f19c2458ce1db90cf43022100e89f17f86abc5b149eba4115d4f128bcf45d77fb3ecdd34f594091340c03959601 + 0102 + 2102966f109c54e85d3aee8321301136cedeb9fc710fdef58a9de8a73942f8e567c0 + 21034ffc99dd9a79dd3cb31e2ab3e0b09e0e67db41ac068c625cd1f491576016c84e + 9552af4830450220487fb382c4974de3f7d834c1b617fe15860828c7f96454490edd6d891556dcc9022100baf95feb48f845d5bfc9882eb6aeefa1bc3790e39f59eaa46ff7f15ae626c53e0148304502205286f726690b2e9b0207f0345711e63fa7012045b9eb0f19c2458ce1db90cf43022100e89f17f86abc5b149eba4115d4f128bcf45d77fb3ecdd34f594091340c0395960175 + + The new serialization format is described in BIP144 [[bip-0144.mediawiki|BIP144: Segregated Witness (Peer Services)]] == Deployment == @@ -538,11 +622,11 @@ As a soft fork, older software will continue to operate without modification. No == Reference Implementation == -https://github.com/bitcoin/bitcoin/pull/7910 +https://github.com/bitcoin/bitcoin/pull/8149 == References == - + == Copyright == diff --git a/bip-0144.mediawiki b/bip-0144.mediawiki index f2c8857f..f10fe0cd 100644 --- a/bip-0144.mediawiki +++ b/bip-0144.mediawiki @@ -103,9 +103,9 @@ and therefore, they have witness hash equal to normal hash.) === Relay === -New inv types MSG_WITNESS_TX and MSG_WITNESS_BLOCK are added, only +New inv types MSG_WITNESS_TX (0x40000001, or (1<<30)+MSG_TX) and MSG_WITNESS_BLOCK (0x40000002, or (1<<30)+MSG_BLOCK) are added, only for use in getdata. Inventory messages themselves still use just MSG_TX and MSG_BLOCK, -similar to MSG_FILTERED_BLOCK. +similar to MSG_FILTERED_BLOCK. A further inv type MSG_FILTERED_WITNESS_BLOCK (0x40000003, or (1<<30)+MSG_FILTERED_BLOCK) is reserved for future use. * '''Rationale for not advertizing witnessness in invs''': we don't always use invs anymore (with 'sendheaders' BIP 130), plus it's not useful: implicitly, every transaction and block have a witness, old ones just have empty ones. @@ -117,7 +117,7 @@ MSG_WITNESS_BLOCK requests will return a block message with transactions that ha Special thanks to Gregory Maxwell for originating many of the ideas in this BIP and Luke-Jr for figuring out how to deploy this as a soft fork. == Reference Implementation == -https://github.com/sipa/bitcoin/commits/segwit +https://github.com/bitcoin/bitcoin/pull/8149 == Copyright == This document is placed in the public domain. diff --git a/bip-0146.mediawiki b/bip-0146.mediawiki index c92c54ef..5358411a 100644 --- a/bip-0146.mediawiki +++ b/bip-0146.mediawiki @@ -1,8 +1,8 @@ 
   BIP: 146
-  Title: Dealing with signature malleability
-  Author: Pieter Wuille 
-          Johnson Lau 
+  Title: Dealing with signature encoding malleability
+  Author: Johnson Lau 
+          Pieter Wuille 
   Status: Draft
   Type: Standards Track
   Created: 2016-08-16
@@ -10,58 +10,114 @@
 
 ==Abstract==
 
-This document specifies proposed changes to the Bitcoin transaction validity rules to fix signature malleability for common transaction types.
+This document specifies proposed changes to the Bitcoin transaction validity rules to fix signature malleability related to ECDSA signature encoding.
 
 
 ==Motivation==
 
 Signature malleability refers to the ability of any relay node on the network to transform the signature in transactions, with no access to the relevant private keys required. For non-segregated witness transactions, signature malleability will change the txid and invalidate any unconfirmed child transactions. Although the txid of segregated witness ([https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki BIP141]) transactions is not third party malleable, this malleability vector will change the wtxid and may reduce the efficiency of compact block relay ([https://github.com/bitcoin/bips/blob/master/bip-0152.mediawiki BIP152]).
 
-Since the enforcement of Strict DER signatures ([https://github.com/bitcoin/bips/blob/master/bip-0066.mediawiki BIP66]), there are 2 remaining known sources of malleability in the signature passed to ECDSA verification opcodes:
+Since the enforcement of Strict DER signatures ([https://github.com/bitcoin/bips/blob/master/bip-0066.mediawiki BIP66]), there are 2 remaining known sources of malleability in ECDSA signatures:
 
 # '''Inherent ECDSA signature malleability''': ECDSA signatures are inherently malleable as taking the negative of the number S inside (modulo the curve order) does not invalidate it.
 
-# '''Inputs ignored by scripts''': The (unnecessary) extra stack element consumed by OP_CHECKMULTISIG and OP_CHECKMULTISIGVERIFY is not inspected in any manner, and could be replaced with any value.
+# '''Malleability of failing signature''': If a signature failed to validate in OP_CHECKSIG or OP_CHECKMULTISIG, a FALSE would be returned to the stack and the script evaluation would continue. The failing signature may take any value, as long as it follows all the rules described in BIP66.
 
 This document specifies new rules to fix the aforesaid signature malleability.
 
 
 ==Specification==
 
-To fix signature malleability, the following new rules are applied:
+To fix signature encoding malleability, the following new rules are applied to pre-segregated witness and segregated witness scripts:
 
 
 ===LOW_S===
 
 We require that the S value inside ECDSA signatures is at most the curve order divided by 2 (essentially restricting this value to its lower half range). Every signature passed to OP_CHECKSIGIncluding pay-to-witness-public-key-hash (P2WPKH) described in BIP141, OP_CHECKSIGVERIFY, OP_CHECKMULTISIG, or OP_CHECKMULTISIGVERIFY, to which ECDSA verification is applied, MUST use a S value between 0x1 and 0x7FFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF 5D576E73 57A4501D DFE92F46 681B20A0 (inclusive) with strict DER encoding (see [https://github.com/bitcoin/bips/blob/master/bip-0066.mediawiki BIP66]).
 
-These operators all perform ECDSA verifications on pubkey/signature pairs, iterating from the top of the stack backwards. For each such verification, if the signature does not pass the Low S value check, the entire script evaluates to false immediately. If the signature is valid DER with low S value, but does not pass ECDSA verification, opcode execution continues as it used to, causing opcode execution to stop and push false on the stack (but not immediately fail the script) in some cases, which potentially skips further signatures (and thus does not subject them to Low S value check).
+If a signature passing to ECDSA verification does not pass the Low S value check and is not an empty byte array, the entire script evaluates to false immediately.
 
 A high S value in signature could be trivially replaced by S' = 0xFFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFE BAAEDCE6 AF48A03B BFD25E8C D0364141 - S.
 
 
-===NULLDUMMY===
+===NULLFAIL===
 
-The extra stack element consumed by OP_CHECKMULTISIG and OP_CHECKMULTISIGVERIFY MUST be the empty byte array (the result of OP_0). Anything else makes the script evaluate to false immediately.
+If an OP_CHECKSIG is trying to return a FALSE value to the stack, we require that the relevant signature must be an empty byte array.
+
+If an OP_CHECKMULTISIG is trying to return a FALSE value to the stack, we require that all signatures passing to this OP_CHECKMULTISIG must be empty byte arrays, even the processing of some signatures might have been skipped due to early termination of the signature verification.
+
+Otherwise, the entire script evaluates to false immediately.
+
+
+==Examples==
+
+The following examples are the combined results of the LOW_S and NULLFAIL rules.Please note that due to implementation details in reference client v0.13.1, some signatures with S value higher than the half curve order might pass the LOW_S test. However, such signatures are certainly invalid, and will fail later due to NULLFAIL test.
+
+Notation:
+
+  CO       : curve order = 0xFFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFE BAAEDCE6 AF48A03B BFD25E8C D0364141
+  HCO      : half curve order = CO / 2 = 0x7FFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF 5D576E73 57A4501D DFE92F46 681B20A0
+  P1, P2   : valid, serialized, public keys
+  S1L, S2L : valid low S value signatures using respective keys P1 and P2 (1 ≤ S ≤ HCO)
+  S1H, S2H : signatures with high S value (otherwise valid) using respective keys P1 and P2 (HCO < S < CO)
+  F        : any BIP66-compliant non-empty byte array but not a valid signature
+
+These scripts will return a TRUE to the stack as before:
+
+  S1L P1 CHECKSIG
+  0 S1L S2L 2 P1 P2 2 CHECKMULTISIG
+
+These scripts will return a FALSE to the stack as before:
+
+  0 P1 CHECKSIG
+  0 0 0 2 P1 P2 2 CHECKMULTISIG
+
+These previously TRUE scripts will fail immediately under the new rules:
+
+  S1H P1 CHECKSIG
+  0 S1H S2L 2 P1 P2 2 CHECKMULTISIG
+  0 S1L S2H 2 P1 P2 2 CHECKMULTISIG
+  0 S1H S2H 2 P1 P2 2 CHECKMULTISIG
+
+These previously FALSE scripts will fail immediately under the new rules:
+
+  F P1 CHECKSIG
+  0 S2L S1L 2 P1 P2 2 CHECKMULTISIG
+  0 S1L F   2 P1 P2 2 CHECKMULTISIG
+  0 F   S2L 2 P1 P2 2 CHECKMULTISIG
+  0 S1L 0   2 P1 P2 2 CHECKMULTISIG
+  0 0   S2L 2 P1 P2 2 CHECKMULTISIG
+  0 F   0   2 P1 P2 2 CHECKMULTISIG
+  0 0   F   2 P1 P2 2 CHECKMULTISIG
 
 
 ==Deployment==
 
-This BIP will be deployed by "version bits" [https://github.com/bitcoin/bips/blob/master/bip-0009.mediawiki BIP9] using the same parameters for BIP141 and BIP143, with the name "segwit" and using bit 1.
+This BIP will be deployed by "version bits" [https://github.com/bitcoin/bips/blob/master/bip-0009.mediawiki BIP9]. Details TBD.
 
 For Bitcoin mainnet, the BIP9 starttime will be midnight TBD UTC (Epoch timestamp TBD) and BIP9 timeout will be midnight TBD UTC (Epoch timestamp TBD).
 
-For Bitcoin testnet, the BIP9 starttime will be midnight 1 May 2016 UTC (Epoch timestamp 1462060800) and BIP9 timeout will be midnight 1 May 2017 UTC (Epoch timestamp 1493596800).
+For Bitcoin testnet, the BIP9 starttime will be midnight TBD UTC (Epoch timestamp TBD) and BIP9 timeout will be midnight TBD UTC (Epoch timestamp TBD).
 
 
 ==Compatibility==
 
-The reference client has produced compatible signatures since v0.9.0, and NULLDUMMY and LOW_S have been enforced as relay policy by the reference client since v0.10.0 and v0.11.1 respectively. As of August 2016, very few transactions violating the requirement are being added to the chain. In addition, every non-compliant signature can trivially be converted into a compliant one, so there is no loss of functionality by this requirement.
+The reference client has produced LOW_S compatible signatures since v0.9.0, and the LOW_S rule has been enforced as relay policy by the reference client since v0.11.1. As of August 2016, very few transactions violating the requirement are being added to the chain. For all scriptPubKey types in actual use, non-compliant signatures can trivially be converted into compliant ones, so there is no loss of functionality by these requirements.
+
+Scripts with failing OP_CHECKSIG or OP_CHECKMULTISIG rarely happen on the chain. The NULLFAIL rule has been enforced as relay policy by the reference client since v0.13.1.
+
+Users MUST pay extra attention to these new rules when designing exotic scripts.
 
 
 ==Implementation==
 
-An implementation for the reference client is available at https://github.com/bitcoin/bitcoin/pull/8533
+Implementations for the reference client is available at:
+
+https://github.com/bitcoin/bitcoin/blob/35fe0393f216aa6020fc929272118eade5628636/src/script/interpreter.cpp#L185
+
+and
+
+https://github.com/bitcoin/bitcoin/pull/8634
 
 
 ==Footnotes==
diff --git a/bip-0147.mediawiki b/bip-0147.mediawiki
new file mode 100644
index 00000000..001abc65
--- /dev/null
+++ b/bip-0147.mediawiki
@@ -0,0 +1,55 @@
+
+  BIP: 147
+  Title: Dealing with dummy stack element malleability
+  Author: Johnson Lau 
+  Status: Draft
+  Type: Standards Track
+  Created: 2016-09-02
+

+
+==Abstract==
+
+This document specifies proposed changes to the Bitcoin transaction validity rules to fix a malleability vector in the extra stack element consumed by OP_CHECKMULTISIG and OP_CHECKMULTISIGVERIFY.
+
+
+==Motivation==
+
+Signature malleability refers to the ability of any relay node on the network to transform the signature in transactions, with no access to the relevant private keys required. For non-segregated witness transactions, signature malleability will change the txid and invalidate any unconfirmed child transactions. Although the txid of segregated witness ([https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki BIP141]) transactions is not third party malleable, this malleability vector will change the wtxid and may reduce the efficiency of compact block relay ([https://github.com/bitcoin/bips/blob/master/bip-0152.mediawiki BIP152]).
+
+A design flaw in OP_CHECKMULTISIG and OP_CHECKMULTISIGVERIFY causes them to consume an extra stack element ("dummy element") after signature validation. The dummy element is not inspected in any manner, and could be replaced by any value without invalidating the script. This document specifies a new rule to fix this signature malleability.
+
+
+==Specification==
+
+To fix the dummy element malleability, a new consensus rule ("NULLDUMMY") is deployed to require that the dummy element MUST be the empty byte array. Anything else makes the script evaluate to false immediately. The NULLDUMMY rule applies to OP_CHECKMULTISIG and OP_CHECKMULTISIGVERIFY in pre-segregated scripts, and also pay-to-witness-script-hash scripts described in BIP141.
+
+
+==Deployment==
+
+This BIP will be deployed by "version bits" [https://github.com/bitcoin/bips/blob/master/bip-0009.mediawiki BIP9] using the same parameters for BIP141 and BIP143, with the name "segwit" and using bit 1.
+
+For Bitcoin mainnet, the BIP9 starttime is midnight 15 November 2016 UTC (Epoch timestamp 1479168000) and BIP9 timeout is midnight 15 November 2017 UTC (Epoch timestamp 1510704000).
+
+For Bitcoin testnet, the BIP9 starttime is midnight 1 May 2016 UTC (Epoch timestamp 1462060800) and BIP9 timeout is midnight 1 May 2017 UTC (Epoch timestamp 1493596800).
+
+
+==Compatibility==
+
+The reference client has produced compatible signatures from the beginning, and the NULLDUMMY rule has been enforced as relay policy by the reference client since v0.10.0. There has been no transactions violating the requirement being added to the chain since at least August 2015.
+
+For all scriptPubKey types in actual use, non-compliant signatures can trivially be converted into compliant ones, so there is no loss of functionality by this requirement. Users MUST pay extra attention to this new rule when designing exotic scripts.
+
+
+==Implementation==
+
+An implementation for the reference client is available at https://github.com/bitcoin/bitcoin/pull/8636
+
+
+==Acknowledgements==
+
+Peter Todd is the original author of NULLDUMMY. This document is extracted from the previous [https://github.com/bitcoin/bips/blob/master/bip-0062.mediawiki BIP62] proposal, which was composed by Pieter Wuille and had input from various people.
+
+
+==Copyright==
+
+This document is placed in the public domain.
diff --git a/bip-0152.mediawiki b/bip-0152.mediawiki
index cfae0c0d..e05cc2ac 100644
--- a/bip-0152.mediawiki
+++ b/bip-0152.mediawiki
@@ -21,12 +21,12 @@ Thus, decreasing the bandwidth used during block relay is very useful for many i
 
 While the goal of this work is explicitly not to reduce block transfer latency, it does, as a side effect reduce block transfer latencies in some rather significant ways. Additionally, this work forms a foundation for future work explicitly targeting low-latency block transfer.
 
-==Specification==
+==Specification for version 1==
 
 ===Intended Protocol Flow===
 
 
-The protocol is intended to be used in two ways, depending on the peers and bandwidth available, as discussed [[#Implementation_Details|later]]. The "high-bandwidth" mode, which nodes may only enable for a few of their peers, is enabled by setting the first boolean to 1 in a sendcmpct message. In this mode, peers send new block announcements with the short transaction IDs already (via a cmpctblock message), possibly even before fully validating the block (as indicated by the grey box in the image above). In some cases no further round-trip is needed, and the receiver can reconstruct the block and process it as usual immediately. When some transactions were not available from local sources (ie mempool), a getblocktxn/blocktxn roundtrip is necessary, bringing the best-case latency to the same 1.5*RTT minimum time that nodes take today, though with significantly less bandwidth usage.
+The protocol is intended to be used in two ways, depending on the peers and bandwidth available, as discussed [[#Implementation_Notes|later]]. The "high-bandwidth" mode, which nodes may only enable for a few of their peers, is enabled by setting the first boolean to 1 in a sendcmpct message. In this mode, peers send new block announcements with the short transaction IDs already (via a cmpctblock message), possibly even before fully validating the block (as indicated by the grey box in the image above). In some cases no further round-trip is needed, and the receiver can reconstruct the block and process it as usual immediately. When some transactions were not available from local sources (ie mempool), a getblocktxn/blocktxn roundtrip is necessary, bringing the best-case latency to the same 1.5*RTT minimum time that nodes take today, though with significantly less bandwidth usage.
 
 The "low-bandwidth" mode is enabled by setting the first boolean to 0 in a sendcmpct message. In this mode, peers send new block announcements with the usual inv/headers announcements (as per BIP130, and after fully validating the block). The receiving peer may then request the block using a MSG_CMPCT_BLOCK getdata request, which will receive a response of the header and short transaction IDs. In some cases no further round-trip is needed, and the receiver can reconstruct the block and process it as usual, taking the same 1.5*RTT minimum time that nodes take today, though with significantly less bandwidth usage. When some transactions were not available from local sources (ie mempool), a getblocktxn/blocktxn roundtrip is necessary, bringing the latency to at least 2.5*RTT in this case, again with significantly less bandwidth usage than today. Because TCP often exhibits worse transfer latency for larger data sizes (as a multiple of RTT), total latency is expected to be reduced even when the full 2.5*RTT transfer mechanism is used.
 
@@ -45,7 +45,7 @@ A PrefilledTransaction structure is used in HeaderAndShortIDs to provide a list
 |-
 |index||CompactSize||1, 3 bytes||Compact Size, differentially encoded since the last PrefilledTransaction in a list||The index into the block at which this transaction is
 |-
-|tx||Transaction||variable||As encoded in "tx" messages||The transaction which is in the block at index index.
+|tx||Transaction||variable||As encoded in "tx" messages sent in response to getdata MSG_TX||The transaction which is in the block at index index.
 |}
 
 ====HeaderAndShortIDs====
@@ -90,7 +90,7 @@ A BlockTransactions structure is used to provide some of the transactions in a b
 |-
 |transactions_length||CompactSize||1 or 3 bytes||As used to encode array lengths elsewhere||||The number of transactions provided
 |-
-|transactions||List of Transactions||variable||As encoded in "tx" messages||The transactions provided
+|transactions||List of Transactions||variable||As encoded in "tx" messages in response to getdata MSG_TX||The transactions provided
 |}
 
 ====Short transaction IDs====
@@ -108,9 +108,10 @@ A new inv type (MSG_CMPCT_BLOCK == 4) and several new protocol messages are adde
 # The second integer SHALL be interpreted as a little-endian version number. Nodes sending a sendcmpct message MUST currently set this value to 1.
 # Upon receipt of a "sendcmpct" message with the first and second integers set to 1, the node SHOULD announce new blocks by sending a cmpctblock message.
 # Upon receipt of a "sendcmpct" message with the first integer set to 0, the node SHOULD NOT announce new blocks by sending a cmpctblock message, but SHOULD announce new blocks by sending invs or headers, as defined by BIP130.
-# Upon receipt of a "sendcmpct" message with the second integer set to something other than 1, nodes MUST treat the peer as if they had not received the message (as it indicates the peer will provide an unexpected encoding in cmpctblock, and/or other, messages). This allows future versions to send duplicate sendcmpct messages with different versions as a part of a version handshake for future versions.
+# Upon receipt of a "sendcmpct" message with the second integer set to something other than 1, nodes MUST treat the peer as if they had not received the message (as it indicates the peer will provide an unexpected encoding in cmpctblock, and/or other, messages). This allows future versions to send duplicate sendcmpct messages with different versions as a part of a version handshake for future versions. See Protocol Versioning section, below, for more info on the specifics of the version-negotiation mechanics.
 # Nodes SHOULD check for a protocol version of >= 70014 before sending sendcmpct messages.
 # Nodes MUST NOT send a request for a MSG_CMPCT_BLOCK object to a peer before having received a sendcmpct message from that peer.
+# Nodes MUST NOT request a MSG_CMPCT_BLOCK object before having sent all sendcmpct messages to that peer which they intend to send, as the peer cannot know what version protocol to use in the response.
 
 ====MSG_CMPCT_BLOCK====
 # getdata messages may now contain requests for MSG_CMPCT_BLOCK objects.
@@ -127,7 +128,7 @@ A new inv type (MSG_CMPCT_BLOCK == 4) and several new protocol messages are adde
 
 ====getblocktxn====
 # The getblocktxn message is defined as as a message containing a serialized BlockTransactionsRequest message and pchCommand == "getblocktxn".
-# Upon receipt of a properly-formatted getblocktxnmessage, nodes which recently provided the sender of such a message a cmpctblock for the block hash identified in this message MUST respond with an appropriate blocktxn message. Such a blocktxn message MUST contain exactly and only each transaction which is present in the appropriate block at the index specified in the getblocktxn indexes list, in the order requested.
+# Upon receipt of a properly-formatted getblocktxn message, nodes which recently provided the sender of such a message a cmpctblock for the block hash identified in this message MUST respond with either an appropriate blocktxn message, or a full block message. A blocktxn response MUST contain exactly and only each transaction which is present in the appropriate block at the index specified in the getblocktxn indexes list, in the order requested.
 
 ====blocktxn====
 # The blocktxn message is defined as as a message containing a serialized BlockTransactions message and pchCommand == "blocktxn".
@@ -136,7 +137,32 @@ A new inv type (MSG_CMPCT_BLOCK == 4) and several new protocol messages are adde
 ## For each short transaction ID from the original cmpctblock, in order, find the corresponding transaction either from the blocktxn message or from other sources and place it in the first available position in the block.
 # Once the block has been reconstructed, it shall be processed as normal, keeping in mind that short transaction IDs are expected to occasionally collide, and that nodes MUST NOT be penalized for such collisions, wherever they appear.
 
-===Implementation Notes===
+==Protocol Versioning==
+# The protocol version negotiation allows two nodes to agree on the versions of compact blocks which they will exchange. As it is only in a single field, it does not allow a node to support a specific version in only one direction (sending or receiving).
+# Upon connection establishment, a node SHOULD send a burst of sendcmpct messages containing every version of compact block encodings for which they are willing to support sending cmpctblock and blocktxn messages, and receiving getblocktxn messages. These messages SHOULD be ordered in the order of the priority which the node wishes to receive cmpctblock/blocktxn messages, with the highest-priority version sendcmpct message sent first.
+# The encoding version used to send a cmpctblock or blocktxn message or to receive a getblocktxn message MUST be the second integer (version number) in the first sendcmpct message received for which a sendcmpct message with the same version number was sent.
+# Nodes MUST NOT send a sendcmpct message which contains a version number other than the version number which has been negotiated for receiving cmpctblock/blocktxn messages after sending a request for a MSG_CMPCT_BLOCK object, sending a cmpctblock, getblocktxn, blocktxn, or pong message.
+# As a node must send all sendcmpct messages which contain a novel version announcement before any other compact block-related messages, it is possible to determine which version of compact blocks will be used for each object received. It is, however, not possible to know which version will be used to encode the response to a request for a compact block object before any MSG_CMPCT_BLOCK-containing getdata, cmpctblock, getblocktxn, blocktxn, or ping/pong messages have been exchanged.
+# Thus, if a node wishes to determine exactly which version of compact blocks will be used before requesting a compact block object, it must send all of its sendcmpct version announcements, followed by a ping, and wait for the pong response to ensure it has received all sendcmpctblock version announcement messages from the remote peer. Nodes can, obviously, however, determine that the version used will be at least a certain version (in their priority order) after having received a sendcmpct message from the remote peer containing that version as the second integer.
+
+===Sample Version Implementation===
+# By way of example, an implementation of the above protocol might look like the following.
+# Upon exchanging version/verack messages, a node immediately sends its list of sendcmpct announcements to the other side, with the version which it wants to receive sent first.
+# Upon receiving the first sendcmpct announcement with a protocol version which is understood from the remote peer, a node will "lock in" the compact block encoding version which will be used to encode compact blocks to that peer.
+# The node then sets the current receive-protocol-version in use on the connection to that version, and uses it to decode new compact block messages.
+# Upon receiving subsequent sendcmpct announcements with a protocol version which is understood from the remote peer (ie a version which has been announced using a sendcmpct in the other direction), a node will check if that protocol version is higher-receive-priority than the current receive-protocol-version in use on the connection, and switch to that version for decoding new compact block messages received.
+# A node might wish to keep a flag for each peer which indicates compact block version negotiation is complete, which can be set upon receiving any compact block-related, or pong message.
+# The above implementation requires only a compile-time list of supported versions in some static priority order, two version fields per peer, and an optional negotiation-complete boolean per-peer.
+
+==Specification for version 2==
+Compact blocks version 2 is almost identical to version 1, but supports segregated witness transactions (BIP 141 and BIP 144). The changes are:
+
+# The second integer (version number) inside sendcmpct is 2 instead of 1 (see Protocol Versioning section, above).
+# Transactions inside cmpctblock messages (both those used as direct announcement and those in response to getdata) and in blocktxn should include witness data, using the same format as responses to getdata MSG_WITNESS_TX, specified in BIP144.
+# Short transaction IDs sent to us in cmpctblock messages, and sent by us in getblocktxn messages, are computed using the same process as in version 1, but using the wtxid as defined in BIP 141 instead of the txid. Note that, though a node normally SHOULD, if a node does not include (ie must then include the short ID for) the coinbase transaction, it must be computed by encoding the transaction in witness format as defined by BIP 141.
+# Upon receipt of a getdata containing a request for a MSG_CMPCT_BLOCK object for which a cmpctblock message is not sent in response, the block message containing the requested block in non-compact form MUST be encoded with witnesses (as is sent in reply to a MSG_WITNESS_BLOCK getdata) if the protocol version used to encode the cmpctblock message would have been 2, and encoded without witnesses (as is sent in response to a MSG_BLOCK getdata) if the protocol version used to encode the cmpctblock message would have been 1.
+
+==Implementation Notes==
 # For nodes which have sufficient inbound bandwidth, sending a sendcmpct message with the first integer set to 1 to up to 3 peers is RECOMMENDED. If possible, it is RECOMMENDED that those peers be selected based on their past performance in providing blocks quickly (eg the three peers which provided the highest number of the recent N blocks the quickest), allowing nodes to receive blocks which come from those peers in only 0.5*RTT.
 
 # Nodes MUST NOT send such sendcmpct messages to more than three peers, as it encourages wasting outbound bandwidth across the network.
@@ -153,10 +179,12 @@ A new inv type (MSG_CMPCT_BLOCK == 4) and several new protocol messages are adde
 
 # Note that the MSG_CMPCT_BLOCK section does not require that nodes respond to MSG_CMPCT_BLOCK getdata requests for blocks which they did not recently announce. This allows nodes to calculate cmpctblock messages at announce-time instead of at request-time. Blocks which are requested with a MSG_CMPCT_BLOCK getdata, but which are not responded to with a cmpctblock message MUST be responded to with a block message, allowing nodes to request all blocks using MSG_CMPCT_BLOCK getdatas and rely on their peer to pick an appropriate response.
 
-# While the current version sends transactions with the same encodings as is used in tx messages and elsewhere in the protocol, the version field in sendcmpct is intended to allow this to change in the future. For this reason, it is recommended that the code used to decode PrefilledTransaction and BlockTransactions messages be prepared to take a different transaction encoding, if and when the version field in sendcmpct changes in a future BIP.
+# While the current version sends transactions with the same encodings as are used in tx messages and elsewhere in the protocol, the version field in sendcmpct is intended to allow this to change in the future. For this reason, it is recommended that the code used to decode PrefilledTransaction and BlockTransactions messages be prepared to take a different transaction encoding, if and when the version field in sendcmpct changes in a future BIP.
 
 # Any undefined behavior in this spec may cause failure to transfer block to, peer disconnection by, or self-destruction by the receiving node. A node receiving non-minimally-encoded CompactSize encodings should make a best-effort to eat the sender's cat.
 
+# As high-bandwidth mode permits relaying of CMPCTBLOCK messages prior to full validation (requiring only that the block header is valid before relay), nodes SHOULD NOT ban a peer for announcing a new block with a CMPCTBLOCK message that is invalid, but has a valid header.  For avoidance of doubt, nodes SHOULD bump their peer-to-peer protocol version to 70015 or higher to signal that they will not ban or punish a peer for announcing compact blocks prior to full validation, and nodes SHOULD NOT announce a CMPCTBLOCK to a peer with a version number below 70015 before fully validating the block.
+
 ==Justification==
 
 ====Protocol design====
@@ -190,13 +218,26 @@ In case 1, we're good. In cases 2, 3, or 4, we request the full transaction beca
 
 This means that ''B = 48'' bits short IDs suffice for blocks with up to ''t = 10000'' transactions, mempools up to ''m = 100000'' transactions, with failure to reconstruct at most one in ''F = 281474'' blocks. Since failure to reconstruct just means we fall back to normal inv/header based relay, it isn't necessary to avoid such failure completely. It just needs to be sufficiently rare they have a lower impact than random transmission failures (for example, network disconnection, node overloaded, ...).
 
+====Separate version for segregated witness====
+
+The changes to transaction and block relay in BIP 144 introduce separate MSG_FILTERED_ versions of messages in getdata,
+allowing a receiver to choose individually where witness data is wanted.
+
+This method is not useful for compact blocks because `cmpctblock` blocks can be sent unsolicitedly in high-bandwidth
+mode, so we need to negotiate at least whether those should include witness data up front. There is little use for a
+validating node that only sometimes processes witness data, so we may as well use that negotiation for everything and
+turn it into a separate protocol version. We also need a means to distinguish different versions of the same transaction
+with different witnesses for correct reconstruction, so this also forces us to use wtxids instead of txids for short IDs
+everywhere in that case.
+
 ==Backward compatibility==
 
 Older clients remain fully compatible and interoperable after this change.
 
 ==Implementation==
 
-https://github.com/bitcoin/bitcoin/pull/8068
+https://github.com/bitcoin/bitcoin/pull/8068 for version 1.
+https://github.com/bitcoin/bitcoin/pull/8393 for version 2.
 
 ==Acknowledgements==
 
diff --git a/scripts/buildtable.pl b/scripts/buildtable.pl
index 568b8eb0..f0e43d26 100755
--- a/scripts/buildtable.pl
+++ b/scripts/buildtable.pl
@@ -24,7 +24,11 @@ my %EmailField = (
 	Editor => undef,
 );
 my %MiscField = (
+	'Discussions-To' => undef,
 	'Post-History' => undef,
+	'Replaces' => undef,
+	'Superseded-By' => undef,
+	'Resolution' => undef,
 );
 
 my %ValidLayer = (