diff options
64 files changed, 5701 insertions, 694 deletions
diff --git a/.travis.yml b/.travis.yml new file mode 100644 index 0000000..ed99de0 --- /dev/null +++ b/.travis.yml @@ -0,0 +1,7 @@ +os: linux +language: generic +sudo: false +script: + - scripts/buildtable.pl >/tmp/table.mediawiki || exit 1 + - diff README.mediawiki /tmp/table.mediawiki | grep '^[<>] |' >/tmp/after.diff || true + - if git checkout HEAD^ && scripts/buildtable.pl >/tmp/table.mediawiki 2>/dev/null; then diff README.mediawiki /tmp/table.mediawiki | grep '^[<>] |' >/tmp/before.diff || true; newdiff=$(diff -s /tmp/before.diff /tmp/after.diff -u | grep '^+'); if [ -n "$newdiff" ]; then echo "$newdiff"; exit 1; fi; else echo 'Cannot build previous commit table for comparison'; fi diff --git a/README.mediawiki b/README.mediawiki index fef0770..970cf93 100644 --- a/README.mediawiki +++ b/README.mediawiki @@ -1,4 +1,4 @@ -People wishing to submit BIPs, first should propose their idea or document to the mailing list. After discussion they should email Greg Maxwell <gmaxwell@gmail.com>. After copy-editing and acceptance, it will be published here. +People wishing to submit BIPs, first should propose their idea or document to the mailing list. After discussion they should email Luke Dashjr <luke_bipeditor@dashjr.org>. After copy-editing and acceptance, it will be published here. We are fairly liberal with approving BIPs, and try not to be too involved in decision making on behalf of the community. The exception is in very rare cases of dispute resolution when a decision is contentious and cannot be agreed upon. In those cases, the conservative option will always be preferred. @@ -16,15 +16,21 @@ Those proposing changes should consider that ultimately consent may rest with th | [[bip-0001.mediawiki|1]] | BIP Purpose and Guidelines | Amir Taaki -| Standard +| Process | Active |- +| [[bip-0002.mediawiki|2]] +| BIP Status and Comments +| Luke Dashjr +| Process +| Draft +|- | [[bip-0009.mediawiki|9]] | Version bits with timeout and delay | Pieter Wuille, Peter Todd, Greg Maxwell, Rusty Russell | Informational | Draft -|- +|- style="background-color: #ffcfcf" | [[bip-0010.mediawiki|10]] | Multi-Sig Transaction Distribution | Alan Reiner @@ -35,7 +41,7 @@ Those proposing changes should consider that ultimately consent may rest with th | M-of-N Standard Transactions | Gavin Andresen | Standard -| Accepted +| Final |- style="background-color: #ffcfcf" | [[bip-0012.mediawiki|12]] | OP_EVAL @@ -53,8 +59,8 @@ Those proposing changes should consider that ultimately consent may rest with th | Protocol Version and User Agent | Amir Taaki, Patrick Strateman | Standard -| Accepted -|- style="background-color: #ffcfcf" +| Final +|- | [[bip-0015.mediawiki|15]] | Aliases | Amir Taaki @@ -62,7 +68,7 @@ Those proposing changes should consider that ultimately consent may rest with th | Deferred |- style="background-color: #cfffcf" | [[bip-0016.mediawiki|16]] -| Pay To Script Hash +| Pay to Script Hash | Gavin Andresen | Standard | Final @@ -95,19 +101,19 @@ Those proposing changes should consider that ultimately consent may rest with th | URI Scheme | Nils Schneider, Matt Corallo | Standard -| Accepted +| Final |- style="background-color: #cfffcf" | [[bip-0022.mediawiki|22]] | getblocktemplate - Fundamentals | Luke Dashjr | Standard -| Accepted +| Final |- style="background-color: #cfffcf" | [[bip-0023.mediawiki|23]] | getblocktemplate - Pooled Mining | Luke Dashjr | Standard -| Accepted +| Final |- style="background-color: #cfffcf" | [[bip-0030.mediawiki|30]] | Duplicate transactions @@ -119,13 +125,13 @@ Those proposing changes should consider that ultimately consent may rest with th | Pong message | Mike Hearn | Standard -| Accepted +| Final |- style="background-color: #cfffcf" | [[bip-0032.mediawiki|32]] | Hierarchical Deterministic Wallets | Pieter Wuille | Informational -| Accepted +| Final |- | [[bip-0033.mediawiki|33]] | Stratized Nodes @@ -134,16 +140,16 @@ Those proposing changes should consider that ultimately consent may rest with th | Draft |- style="background-color: #cfffcf" | [[bip-0034.mediawiki|34]] -| Block v2, Height in coinbase +| Block v2, Height in Coinbase | Gavin Andresen | Standard -| Accepted +| Final |- style="background-color: #cfffcf" | [[bip-0035.mediawiki|35]] | mempool message | Jeff Garzik | Standard -| Accepted +| Final |- | [[bip-0036.mediawiki|36]] | Custom Services @@ -152,32 +158,32 @@ Those proposing changes should consider that ultimately consent may rest with th | Draft |- style="background-color: #cfffcf" | [[bip-0037.mediawiki|37]] -| Bloom filtering -| Mike Hearn and Matt Corallo +| Connection Bloom filtering +| Mike Hearn, Matt Corallo | Standard -| Accepted +| Final |- | [[bip-0038.mediawiki|38]] | Passphrase-protected private key -| Mike Caldwell +| Mike Caldwell, Aaron Voisine | Standard | Draft |- | [[bip-0039.mediawiki|39]] | Mnemonic code for generating deterministic keys -| Slush +| Marek Palatinus, Pavol Rusnak, Aaron Voisine, Sean Bowe | Standard | Draft |- | 40 | Stratum wire protocol -| Slush +| Marek Palatinus | Standard | BIP number allocated |- | 41 | Stratum mining protocol -| Slush +| Marek Palatinus | Standard | BIP number allocated |- @@ -189,19 +195,19 @@ Those proposing changes should consider that ultimately consent may rest with th |- | [[bip-0043.mediawiki|43]] | Purpose Field for Deterministic Wallets -| Slush +| Marek Palatinus, Pavol Rusnak | Standard | Draft |- | [[bip-0044.mediawiki|44]] | Multi-Account Hierarchy for Deterministic Wallets -| Slush +| Marek Palatinus, Pavol Rusnak | Standard | Draft |- | [[bip-0045.mediawiki|45]] | Structure for Deterministic P2SH Multisignature Wallets -| Manuel Araoz +| Manuel Araoz, Ryan X. Charles, Matias Alejo Garcia | Standard | Draft |- @@ -210,12 +216,12 @@ Those proposing changes should consider that ultimately consent may rest with th | Justus Ranvier | Informational | Draft -|- +|- style="background-color: #cfffcf" | [[bip-0050.mediawiki|50]] | March 2013 Chain Fork Post-Mortem | Gavin Andresen | Informational -| Draft +| Final <!-- 50 series reserved for a group of post-mortems --> |- | [[bip-0060.mediawiki|60]] @@ -223,13 +229,13 @@ Those proposing changes should consider that ultimately consent may rest with th | Amir Taaki | Standard | Draft -|- +|- style="background-color: #cfffcf" | [[bip-0061.mediawiki|61]] -| "reject" P2P message +| Reject P2P message | Gavin Andresen | Standard | Final -|- +|- style="background-color: #ffcfcf" | [[bip-0062.mediawiki|62]] | Dealing with malleability | Pieter Wuille @@ -243,63 +249,87 @@ Those proposing changes should consider that ultimately consent may rest with th | BIP number allocated |- | [[bip-0064.mediawiki|64]] -| getutxos message +| getutxo message | Mike Hearn | Standard | Draft -|- +|- style="background-color: #cfffcf" | [[bip-0065.mediawiki|65]] | OP_CHECKLOCKTIMEVERIFY | Peter Todd | Standard -| Draft -|- +| Final +|- style="background-color: #cfffcf" | [[bip-0066.mediawiki|66]] | Strict DER signatures | Pieter Wuille | Standard -| Draft +| Final |- | [[bip-0067.mediawiki|67]] -| Deterministic P2SH multi-signature addresses -| Thomas Kerin +| Deterministic Pay-to-script-hash multi-signature addresses through public key sorting +| Thomas Kerin, Jean-Pierre Rupp, Ruben de Vries | Standard | Draft |- | [[bip-0068.mediawiki|68]] -| Consensus-enforced transaction replacement signalled via sequence numbers -| Mark Friedenbach +| Relative lock-time using consensus-enforced sequence numbers +| Mark Friedenbach, BtcDrak, Nicolas Dorier, kinoshitajona | Standard | Draft |- | [[bip-0069.mediawiki|69]] | Lexicographical Indexing of Transaction Inputs and Outputs | Kristov Atlas -| Standard +| Informational | Draft -|- +|- style="background-color: #cfffcf" | [[bip-0070.mediawiki|70]] -| Payment protocol -| Gavin Andresen +| Payment Protocol +| Gavin Andresen, Mike Hearn | Standard | Final -|- +|- style="background-color: #cfffcf" | [[bip-0071.mediawiki|71]] -| Payment protocol MIME types +| Payment Protocol MIME types | Gavin Andresen | Standard | Final -|- +|- style="background-color: #cfffcf" | [[bip-0072.mediawiki|72]] -| Payment protocol URIs +| bitcoin: uri extensions for Payment Protocol | Gavin Andresen | Standard | Final -|- +|- style="background-color: #cfffcf" | [[bip-0073.mediawiki|73]] -| Use "Accept" header with Payment Request URLs +| Use "Accept" header for response type negotiation with Payment Request URLs | Stephen Pair | Standard +| Final +|- +| [[bip-0074.mediawiki|74]] +| Allow zero value OP_RETURN in Payment Protocol +| Toby Padilla +| Standard +| Draft +|- +| [[bip-0080.mediawiki|80]] +| Hierarchy for Non-Colored Voting Pool Deterministic Multisig Wallets +| Justus Ranvier, Jimmy Song +| Informational +| Draft +|- +| [[bip-0081.mediawiki|81]] +| Hierarchy for Colored Voting Pool Deterministic Multisig Wallets +| Justus Ranvier, Jimmy Song +| Informational +| Draft +|- +| [[bip-0083.mediawiki|83]] +| Dynamic Hierarchical Deterministic Key Trees +| Eric Lombrozo +| Standard | Draft |- | [[bip-0075.mediawiki|75]] @@ -309,16 +339,16 @@ Those proposing changes should consider that ultimately consent may rest with th | Draft |- | [[bip-0099.mediawiki|99]] -| Motivation and deployment of consensus rule changes +| Motivation and deployment of consensus rule changes ([soft/hard]forks) | Jorge Timón -| Informational | Process +| Informational | Draft -|- +|- style="background-color: #ffcfcf" | [[bip-0101.mediawiki|101]] | Increase maximum block size | Gavin Andresen | Standard -| Draft +| Withdrawn |- | [[bip-0102.mediawiki|102]] | Block size increase to 2MB @@ -326,6 +356,12 @@ Those proposing changes should consider that ultimately consent may rest with th | Standard | Draft |- +| [[bip-0103.mediawiki|103]] +| Block size following technological growth +| Pieter Wuille +| Standard +| Draft +|- | [[bip-0105.mediawiki|105]] | Consensus based block size retargeting algorithm | BtcDrak @@ -338,21 +374,33 @@ Those proposing changes should consider that ultimately consent may rest with th | Standard | Draft |- +| [[bip-0107.mediawiki|107]] +| Dynamic limit on the block size +| Washington Y. Sanchez +| Standard +| Draft +|- +| [[bip-0109.mediawiki|109]] +| Two million byte size limit with sigop and sighash limits +| Gavin Andresen +| Standard +| Draft +|- | [[bip-0111.mediawiki|111]] | NODE_BLOOM service bit -| Matt Corallo and Peter Todd +| Matt Corallo, Peter Todd | Standard | Draft |- | [[bip-0112.mediawiki|112]] | CHECKSEQUENCEVERIFY -| BtcDrak and Mark Friedenbach +| BtcDrak, Mark Friedenbach, Eric Lombrozo | Standard | Draft |- | [[bip-0113.mediawiki|113]] | Median time-past as endpoint for lock-time calculations -| Thomas Kerin and Mark Friedenbach +| Thomas Kerin, Mark Friedenbach | Standard | Draft |- @@ -368,17 +416,89 @@ Those proposing changes should consider that ultimately consent may rest with th | Standard | Draft |- +| [[bip-0122.mediawiki|122]] +| URI scheme for Blockchain references / exploration +| Marco Pontello +| Standard +| Draft +|- | [[bip-0123.mediawiki|123]] | BIP Classification | Eric Lombrozo +| Process +| Draft +|- +| [[bip-0124.mediawiki|124]] +| Hierarchical Deterministic Script Templates +| Eric Lombrozo, William Swanson | Informational | Draft |- +| [[bip-0125.mediawiki|125]] +| Opt-in Full Replace-by-Fee Signaling +| David A. Harding, Peter Todd +| Standard +| Draft +|- | [[bip-0130.mediawiki|130]] -| sendheaders message +| sendheaders message | Suhas Daftuar | Standard | Draft +|- +| [[bip-0131.mediawiki|131]] +| "Coalescing Transaction" Specification (wildcard inputs) +| Chris Priest +| Standard +| Draft +|- +| [[bip-0132.mediawiki|132]] +| Committee-based BIP Acceptance Process +| Andy Chase +| Process +| Draft +|- +| [[bip-0133.mediawiki|133]] +| feefilter message +| Alex Morcos +| Standard +| Draft +|- +| [[bip-0140.mediawiki|140]] +| Normalized TXID +| Christian Decker +| Standard +| Draft +|- +| [[bip-0141.mediawiki|141]] +| Segregated Witness (Consensus layer) +| Eric Lombrozo, Johnson Lau, Pieter Wuille +| Standard +| Draft +|- +| [[bip-0142.mediawiki|142]] +| Address Format for Segregated Witness +| Johnson Lau +| Standard +| Deferred +|- +| [[bip-0143.mediawiki|143]] +| Transaction Signature Verification for Version 0 Witness Program +| Johnson Lau, Pieter Wuille +| Standard +| Draft +|- +| [[bip-0144.mediawiki|144]] +| Segregated Witness (Peer Services) +| Eric Lombrozo, Pieter Wuille +| Standard +| Draft +|- +| [[bip-0145.mediawiki|145]] +| getblocktemplate Updates for Segregated Witness +| Luke Dashjr +| Standard +| Draft |} <!-- IMPORTANT! See the instructions at the top of this page, do NOT JUST add BIPs here! --> diff --git a/bip-0001.mediawiki b/bip-0001.mediawiki index 6901080..44fbe8b 100644 --- a/bip-0001.mediawiki +++ b/bip-0001.mediawiki @@ -1,8 +1,9 @@ <pre> BIP: 1 Title: BIP Purpose and Guidelines - Status: Accepted - Type: Standards Track + Author: Amir Taaki <genjix@riseup.net> + Status: Active + Type: Process Created: 2011-08-19 </pre> @@ -13,6 +14,7 @@ BIP stands for Bitcoin Improvement Proposal. A BIP is a design document providin 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. + ==BIP Types== There are three kinds of BIP: @@ -23,30 +25,26 @@ There are three kinds of BIP: ==BIP Work Flow== -The BIP editors assign BIP numbers and change their status. Please send all BIP-related email to the BIP editor, which is listed under [[#BIP_Editors|BIP Editors]] below. Also see [[#BIP_Editor_Responsibilities__Workflow|BIP Editor Responsibilities & 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. Posting to the [https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev bitcoin-dev@lists.linuxfoundation.org] mailing list (and maybe the [https://bitcointalk.org/index.php?board=6.0 Development & Technical Discussion] forum) is the best way to go about this. -Authors MUST NOT self assign numbers, but should use an alias such as "bip-johndoe-infinitebitcoins" which includes the author's name/nick and the BIP subject. +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. Many ideas have been brought forward for changing Bitcoin that have been rejected for various reasons. 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. Small enhancements or patches often don't need standardisation between multiple projects; these don't need a BIP and should be injected into the relevant Bitcoin development work flow with a patch submission to the applicable Bitcoin issue tracker. -The BIP process begins with a new idea for Bitcoin. It is highly recommended that a single BIP contain a single key proposal or new idea. Small enhancements or patches often don't need a BIP and can be injected into the Bitcoin development work flow with a patch submission to the Bitcoin issue tracker. The more focused the BIP, the more successful it tends to be. The BIP editor reserves the right to reject BIP proposals if they appear too unfocused or too broad. If in doubt, split your BIP into several well-focused ones. +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-dev] 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 sent to the bitcoin-dev list and the BIP editor with the draft BIP. This draft must be written in BIP style as described below, else it will be sent back without further regard until proper formatting rules are followed. -Each 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. Posting to the [https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev bitcoin-dev] mailing list (and maybe the [https://bitcointalk.org/index.php?board=6.0 Development&Technical Discussion] forum) is the best way to go about this. +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. -Vetting an idea publicly before going as far as writing a BIP is meant to save the potential author time. Many ideas have been brought forward for changing Bitcoin that have been rejected for various reasons. 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. +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. -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 [https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev bitcoin-dev@lists.linuxfoundation.org]. This gives the author a chance to flesh out the draft BIP to make properly formatted, of high quality, and to address initial concerns about the proposal. +The BIP editors assign BIP numbers and change their status. Please send all BIP-related email to the BIP editor, which is listed under [[#BIP_Editors|BIP Editors]] below. Also see [[#BIP_Editor_Responsibilities__Workflow|BIP Editor Responsibilities & Workflow]]. The BIP editor reserves the right to reject BIP proposals if they appear too unfocused or too broad. -Following a discussion, the proposal should be sent to the Bitcoin-dev list and the BIP editor with the draft BIP. This draft must be written in BIP style as described below, else it will be sent back without further regard until proper formatting rules are followed. +Authors MUST NOT self assign BIP numbers, but should use an alias such as "bip-johndoe-infinitebitcoins" which includes the author's name/nick and the BIP subject. -If the BIP editor approves, he will assign the BIP a number, label it as Standards Track, Informational, or Process, give it status "Draft", and add it to the git repository. The BIP editor will not unreasonably deny a BIP. Reasons for denying BIP status include duplication of effort, being technically unsound, not providing proper motivation or addressing backwards compatibility, or not in keeping with the Bitcoin philosophy. +If the BIP editor approves, he will assign the BIP a number, label it as Standards Track, Informational, or Process, give it status "Draft", and add it to the BIPs git repository. The BIP editor will not unreasonably deny a BIP. Reasons for denying BIP status 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 may also be submitted by the author as pull requests. Standards Track BIPs consist of two parts, a design document and a reference implementation. The BIP should be reviewed and accepted before a reference implementation is begun, unless a reference implementation will aid people in studying the BIP. Standards Track BIPs must include an implementation -- in the form of code, a patch, or a URL to same -- before it can be considered Final. -BIP authors are responsible for collecting community feedback on a 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. - -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. - Once a BIP has been accepted, the reference implementation must be completed. When the reference implementation is complete and accepted by the community, the status will be changed to "Final". A BIP can also be assigned status "Deferred". The BIP author or editor can assign the BIP this status when no progress is being made on the BIP. Once a BIP is deferred, the BIP editor can re-assign it to draft status. @@ -87,9 +85,9 @@ Each BIP should have the following parts: ==BIP Formats and Templates== -BIPs should be written in mediawiki or markdown format. Image files should be included in a subdirectory for that BIP. +BIPs should be written in mediawiki or markdown format. -==BIP Header Preamble== +===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. @@ -131,9 +129,10 @@ The Created header records the date that the BIP was assigned a number, while Po 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. Such files 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"). +===Auxiliary Files=== + +BIPs may include auxiliary files such as diagrams. Image files should be included in a subdirectory for that BIP. Auxiliary files 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"). ==Transferring BIP Ownership== @@ -143,11 +142,11 @@ If you are interested in assuming ownership of a BIP, send a message asking to t ==BIP Editors== -The current BIP editor is Gregory Maxwell who can be contacted at [[mailto:gmaxwell@gmail.com|gmaxwell@gmail.com]]. +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== -A BIP editor must subscribe to the Bitcoin development mailing list. All BIP-related correspondence should be sent (or CC'd) to gmaxwell@gmail.com. +The BIP editor subscribes to the Bitcoin development mailing list. All 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: @@ -167,11 +166,9 @@ The BIP editor will: * List the BIP in [[README.mediawiki]] -* Send email back to the BIP author with next steps (post to bitcoin mailing list). - -Many BIPs are written and maintained by developers with write access to the Bitcoin codebase. The BIP editors monitor BIP changes, and correct any structure, grammar, spelling, or markup mistakes we see. +* Send email back to the BIP author with next steps (post to bitcoin-dev mailing list). -The editors don't pass judgement on BIPs. We merely do the administrative & editorial part. Except for times like this, there's relatively low volume. +The BIP editors are intended to fulfill administrative and editorial responsibilities. The BIP editors monitor BIP changes, and correct any structure, grammar, spelling, or markup mistakes we see. ==History== @@ -179,4 +176,6 @@ This document was derived heavily from Python's PEP-0001. In many places text wa ==Changelog== -10 Oct 2015 - Added clarifications about sumission process and BIP number assignment. +10 Oct 2015 - Added clarifications about submission process and BIP number assignment. + +01 Jan 2016 - Clarified early stages of BIP idea championing, collecting community feedback, etc. diff --git a/bip-0002.mediawiki b/bip-0002.mediawiki new file mode 100644 index 0000000..a667026 --- /dev/null +++ b/bip-0002.mediawiki @@ -0,0 +1,223 @@ +<pre> + BIP: 2 + Title: BIP Status and Comments + Author: Luke Dashjr <luke+bip@dashjr.org> + Status: Draft + Type: Process + Created: 2016-02-03 +</pre> + +==Abstract== + +This BIP describes objective criteria that can be used to determine when a BIP Status should be changed, to ensure it is a reliable metric documenting actual usage of the proposal. It also adds a way for final comment on completed BIPs, by adding to them a reference to a wiki page and summary of the tone thereof. Finally, it extends the list of allowable BIP licenses to include many more popular options. + +==Copyright== + +This BIP is dual-licensed under the Open Publication License and BSD 2-clause license. + +==BIP status field== + +===Specification=== + +Champions of a BIP may decide on their own to change the status between Draft, Deferred, or Withdrawn. + +A BIP may only change status from Draft (or Rejected) to Accepted, when the author deems it is complete, has a working implementation (where applicable), and has community plans to progress it to the Final status. + +BIPs should be changed from Draft or Accepted status, to Rejected status, upon request by any person, if they have not made progress in three years. Such a BIP may be changed to Draft status if the champion provides revisions that meaningfully address public criticism of the proposal, or to Accepted status if it meets the criteria required as described in the previous paragraph. + +An Accepted BIP may progress to Final only when specific criteria reflecting real-world adoption has occurred. This is different for each BIP depending on the nature of its proposed changes, which will be expanded on below. Evaluation of this status change should be objectively verifiable, and/or be discussed on the development mailing list. + +When a Final BIP is no longer relevant, its status may be changed to Replaced or Obsolete (which is equivalent to Replaced). This change must also be objectively verifiable and/or discussed. + +A process BIP may change status from Draft to Active when it achieves rough consensus on the mailing list. Such a proposal is said to have rough consensus if it has been open to discussion on the development mailing list for at least one month, and no person maintains any unaddressed substantiated objections to it. Addressed or obstructive objections may be ignored/overruled by general agreement that they have been sufficiently addressed, but clear reasoning must be given in such circumstances. + +====Progression to Final status==== + +See [[bip-0123.mediawiki|BIP 123]] for definitions of the various BIP layers. Activation of this BIP implies activation of BIP 123. + +A soft-fork BIP strictly requires a clear miner majority expressed by blockchain voting (eg, using BIP 9). In addition, if the economy seems willing to make a "no confidence" hard-fork (such as a change in proof-of-work algorithm), the soft-fork does not become Final for as long as such a hard-fork might have majority support, or at most three months. Soft-fork BIPs may also set additional requirements for their adoption. Because of the possibility of changes to miner dynamics, especially in light of delegated voting (mining pools), it is highly recommended that a supermajority vote around 95% be required by the BIP itself, unless rationale is given for a lower threshold. + +A hard-fork BIP requires adoption from the entire Bitcoin economy, particularly including those selling desirable goods and services in exchange for bitcoin payments, as well as Bitcoin holders who wish to spend or would spend their bitcoins (including selling for other currencies) differently in the event of such a hard-fork. Adoption must be expressed by de facto usage of the hard-fork in practice (ie, not merely expressing public support, although that is a good step to establish agreement before adoption of the BIP). This economic adoption cannot be established merely by a super-majority, except by literally forcing the minority to accept the hard-fork (whether this is viable or not is outside the scope of this document). + +Peer services BIPs should be observed to be adopted by at least 1% of public listening nodes for one month. + +API/RPC and application layer BIPs must be implemented by at least two independent and compatible software applications. + +Software authors are encouraged to publish summaries of what BIPs their software supports to aid in verification of status changes. Good examples of this at the time of writing this BIP, can be observed in [https://github.com/bitcoin/bitcoin/blob/master/doc/bips.md Bitcoin Core's doc/bips.md file] as well as [https://github.com/schildbach/bitcoin-wallet/blob/master/wallet/README.specs Bitcoin Wallet for Android's wallet/README.specs file]. + +These criteria are considered objective ways to observe the de facto adoption of the BIP, and are not to be used as reasons to oppose or reject a BIP. Should a BIP become actually and unambiguously adopted despite not meeting the criteria outlined here, it should still be updated to Final status. + +===Rationale=== + +Why is this necessary at all? + +* BIP 1 defines an ambiguous criteria for the Status field of BIPs, which is often a source of confusion. As a result, many BIPs with significant real-world use have been left as Draft or Accepted status longer than appropriate. By giving objective criteria to judge the progression of BIPs, this proposal aims to help keep the Status accurate and up-to-date. + +How is the entire Bitcoin economy defined by people selling goods/services and holders? + +* For Bitcoin to function as a currency, it must be accepted as payment. Bitcoins have no value if you cannot acquire anything in exchange for them. If everyone accepting such payments requires a particular set of consensus rules, "bitcoins" are de facto defined by that set of rules - this is already the case today. If those consensus rules are expected to broaden (as with a hard-fork), those merchants need to accept payments made under the new set of rules, or they will reject "bitcoins" as invalid. Holders are relevant to the degree in that they choose the merchants they wish to spend their bitcoins with, and could also as a whole decide to sell under one set of consensus rules or the other, thus flooding the market with bitcoins and crashing the price. + +Why aren't <x> included in the economy? + +* Some entities may, to some degree, also be involved in offering goods and/or services in exchange for bitcoins, thus in that capacity (but not their capacity as <x>) be involved in the economy. +* Miners are not included in the economy, because they merely *rely on* others to sell/spend their otherwise-worthless mined produce. Therefore, they must accept everyone else's direction in deciding the consensus rules. +* Exchanges are not included in the economy, because they merely provide services of connecting the merchants and users who wish to trade. Even if all exchanges were to defect from Bitcoin, those merchants and users can always trade directly and/or establish their own exchanges. +* Developers are not included in the economy, since they merely write code, and it is up to others to decide to use that code or not. + +But they're doing something important and have invested a lot in Bitcoin! Shouldn't they be included in such an important decision? + +* This BIP does not aim to address what "should" be the basis of decisions. Such a statement, no matter how perfect in its justification, would be futile without some way to force others to use it. The BIP process does not aim to be a kind of forceful "governance" of Bitcoin, merely to provide a collaborative repository for proposing and providing information on standards, which people may voluntarily adopt or not. It can only hope to achieve accuracy in regard to the "Status" field by striving to reflect the reality of *how things actually are*, rather than *how they should be*. + +What if a single merchant wishes to block a hard-fork? + +* This BIP addresses only the progression of the BIP Status field, not the deployment of the hard-fork (or any other change) itself. +* Regardless, one shop cannot operate in a vacuum: if they are indeed alone, they will soon find themselves no longer selling in exchange for bitcoin payments, as nobody else would exist willing to use the previous blockchain to pay them. If they are no longer selling, they cease to meet the criteria herein which enables their veto. + +How about a small number of merchants (maybe only two) who sell products to each other? + +* In this scenario, it would seem the previous Bitcoin is alive any working, and that the hard-fork has failed. How to resolve such a split is outside the scope of this BIP. + +How can economic agreement veto a soft-fork? + +* The group of miners is determined by the consensus rules for the dynamic-membership multi-party signature (for Bitcoin, the proof-of-work algorithm), which can be modified with a hard-fork. Thus, if the same conditions required to modify this group are met in opposition to a soft-fork, the miner majority supporting the soft-fork is effectively void because the economy can decide to replace them with another group of would-be miners who do not support the soft-fork. + +What happens if the economy decides to hard-fork away from a controversial soft-fork, more than three months later? + +* The controversial soft-fork, in this circumstance, changes from Final to Replaced status to reflect the nature of the hard-fork replacing the previous (final) soft-fork. + +What is the ideal percentage of listening nodes needed to adopt peer services proposals? + +* This is unknown, and set rather arbitrarily at this time. For a random selection of peers to have at least one other peer implementing the extension, 13% or more would be necessary, but nodes could continue to scan the network for such peers with perhaps some reasonable success. Furthermore, service bits exist to help identification upfront. + +Why is it necessary for at least two software projects to release an implementation of API/RPC and application layer BIPs, before they become Final? + +* If there is only one implementation of a specification, there is no other program for which a standard interface is used with or needed. +* Even if there are only two projects rather than more, some standard coordination between them exists. + +What if a BIP is proposed that only makes sense for a single specific project? + +* The BIP process exists for standardisation between independent projects. If something only affects one project, it should be done through that project's own internal processes, and never be proposed as a BIP in the first place. + +==BIP comments== + +===Specification=== + +Each BIP should, in its preamble, link to a Bitcoin Wiki page with a summary tone of the comments on that page. +Reviewers of the BIP who consider themselves qualified, should post their own comments on this wiki page in [https://www.mediawiki.org/wiki/Help:Talk_pages#Editing_conventions_on_talk_pages standard "Talk page" format]. +The comments page should generally only be used to post final comments for a completed BIP. +If a BIP is not yet completed, reviewers should instead post on the applicable development mailing list thread to allow the BIP author(s) to address any concerns or problems pointed out by the review. + +Some BIPs receive exposure outside the development community prior to completion, and other BIPs might not be completed at all. To avoid a situation where critical BIP reviews may go unnoticed during this period, reviewers may, at their option, still post their review on the comments page, provided they first post it to the mailing list and plan to later remove or revise it as applicable based on the completed version. Such revisions should be made by editing the previous review and updating the timestamp. Reviews made prior to the complete version may be removed if they are no longer applicable and have not been updated in a timely manner (eg, within one month). + +Pages must be named after the full BIP number (eg, "BIP 0001") and placed in the "BIP Comments" namespace. For example, the link for BIP 1 will be https://en.bitcoin.it/wiki/BIP_Comments:BIP_0001 . + +In order to avoid possible abuse of Bitcoin Wiki moderation, BIPs may choose to list a second forum for BIP comments, in addition to the Bitcoin Wiki. In this case, the second forum's URI should be listed below the Bitcoin Wiki's URI. + +Summary tones may be chosen from the following, but this BIP does not intend to cover all possible nuances: + +* No comments yet. +* Unanimously Recommended for implementation +* Unanimously Discourage for implementation +* Mostly Recommended for implementation, with some Discouragement +* Mostly Discouraged for implementation, with some Recommendation + +For example, the preamble to BIP 1 might be updated to include the line: + + Comments-Summary: No comments yet. + Comments-URI: https://en.bitcoin.it/wiki/BIP_Comments:BIP_0001 + https://some-other-wiki.org/BIP_1_Comments + +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). + +To avoid doubt: comments and status are unrelated metrics to judge a BIP, and neither should be directly influencing the other. + +===Rationale=== + +What is the purpose of BIP comments? + +* Various BIPs have been adopted (the criteria required for "Final" Status) despite being considered generally inadvisable. Some presently regard BIPs as a "good idea" simply by virtue of them being assigned a BIP number. Due to the low barrier of entry for submission of new BIPs, it seems advisable for a way for reviewers to express their opinions on them in a way that is consumable to the public without needing to review the entire development discussion. + +Will BIP comments be censored or limited to particular participants/"experts"? + +* The Bitcoin Wiki moderators have control over that venue and may make reasonable moderation attempts. Admitted non-experts should refrain from commenting outside of their area of knowledge. However, comments should not be censored, and participation should be open to the public. +* If the Bitcoin Wiki were to abuse its position, the venue for comments can always be changed. + +==BIP licensing== + +===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. + +For example, a preamble might include the following License header: + + License: BSD-2-Clause + GNU-All-Permissive + +In this case, the BIP text is fully licensed under both the OSI-approved BSD 2-clause license as well as the GNU All-Permissive License, and anyone may modify and redistribute the text provided they comply with the terms of *either* license. In other words, the license list is an "OR choice", not an "AND also" requirement. + +It is also possible to license source code differently from the BIP text. A optional License-Code header is placed after the License header. Again, each license must be referenced by their respective abbreviation given below. + +For example, a preamble specifying the optional License-Code header might look like: + + License: BSD-2-Clause + GNU-All-Permissive + License-Code: GPL-2.0+ + +In this case, the code in the BIP is not available under the BSD or All-Permissive licenses, but only under the terms of the GNU General Public License (GPL), version 2 or newer. +If the code were to be available under *only* version 2 exactly, the "+" symbol should be removed from the license abbreviation. +For a later version (eg, GPL 3.0), you would increase the version number (and retain or remove the "+" depending on intent). + + License-Code: GPL-2.0 # This refers to GPL v2.0 *only*, no later license versions are acceptable. + License-Code: GPL-2.0+ # This refers to GPL v2.0 *or later*. + 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. + +====Recommended licenses==== + +* BSD-2-Clause: [https://opensource.org/licenses/BSD-2-Clause OSI-approved BSD 2-clause license] +* BSD-3-Clause: [https://opensource.org/licenses/BSD-3-Clause OSI-approved BSD 3-clause license] +* CC0-1.0: [https://creativecommons.org/publicdomain/zero/1.0/ Creative Commons CC0 1.0 Universal] +* GNU-All-Permissive: [http://www.gnu.org/prep/maintain/html_node/License-Notices-for-Other-Files.html GNU All-Permissive License] + +In addition, it is recommended that literal code included in the BIP be dual-licensed under the same license terms as the project it modifies. For example, literal code intended for Bitcoin Core would ideally be dual-licensed under the MIT license terms as well as one of the above with the rest of the BIP text. + +====Not recommended, but acceptable licenses==== + +* Apache-2.0: [http://www.apache.org/licenses/LICENSE-2.0 Apache License, version 2.0] +* BSL-1.0: [http://www.boost.org/LICENSE_1_0.txt Boost Software License, version 1.0] +* CC-BY-4.0: [https://creativecommons.org/licenses/by/4.0/ Creative Commons Attribution 4.0 International] +* CC-BY-SA-4.0: [https://creativecommons.org/licenses/by-sa/4.0/ Creative Commons Attribution-ShareAlike 4.0 International] +* MIT: [https://opensource.org/licenses/MIT Expat/MIT/X11 license] +* AGPL-3.0+: [http://www.gnu.org/licenses/agpl-3.0.en.html GNU Affero General Public License (AGPL), version 3 or newer] +* 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. + +===Rationale=== + +BIP 1 allowed the Open Publication License or releasing into the public domain; was this insufficient? + +* The OPL is generally regarded as obsolete, and not a license suitable for new publications. +* Many are unfamiliar with the OPL terms, and may just prefer to use the public domain rather than license under uncertain terms. +* Public domain is not universally recognised as a legitimate action, thus it is inadvisable. + +Why are there software licenses included? + +* Some BIPs, especially consensus layer, may include literal code in the BIP itself which may not be available under the exact license terms of the BIP. +* Despite this, not all software licenses would be acceptable for content included in BIPs. + +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. + +==See Also== + +* [[bip-0001.mediawiki|BIP 1: BIP Purpose and Guidelines]] +* [[bip-0123.mediawiki|BIP 123: BIP Classification]] +* [https://tools.ietf.org/html/rfc7282 RFC 7282: On Consensus and Humming in the IETF] diff --git a/bip-0009.mediawiki b/bip-0009.mediawiki index b160810..509a8a9 100644 --- a/bip-0009.mediawiki +++ b/bip-0009.mediawiki @@ -1,9 +1,12 @@ <pre> BIP: 9 Title: Version bits with timeout and delay - Author: Pieter Wuille <pieter.wuille@gmail.com>, Peter Todd <pete@petertodd.org>, Greg Maxwell <greg@xiph.org>, Rusty Russell <rusty@rustcorp.com.au> + Author: Pieter Wuille <pieter.wuille@gmail.com> + Peter Todd <pete@petertodd.org> + Greg Maxwell <greg@xiph.org> + Rusty Russell <rusty@rustcorp.com.au> Status: Draft - Type: Informational Track + Type: Informational Created: 2015-10-04 </pre> @@ -15,135 +18,151 @@ This document specifies a proposed change to the semantics of the 'version' fiel BIP 34 introduced a mechanism for doing soft-forking changes without a predefined flag timestamp (or flag block height), instead relying on measuring miner support indicated by a higher version number in block headers. As it relies on comparing version numbers as integers however, it only supports one single change being rolled out at once, requiring coordination between proposals, and does not allow for permanent rejection: as long as one soft fork is not fully rolled out, no future one can be scheduled. -In addition, BIP 34 made the integer comparison (nVersion >= 2) a consensus rule after its 95% threshold was reached, removing 2<sup>31</sup>+2 values from the set of valid version numbers (all negative numbers, as nVersion is interpreted as a signed integer, as well as 0 and 1). This indicates another downside this approach: every upgrade permanently restricts the set of allowed nVersion field values. This approach was later reused in BIP 66, which further removed nVersion = 2 as valid option. As will be shown further, this is unnecessary. +In addition, BIP 34 made the integer comparison (nVersion >= 2) a consensus rule after its 95% threshold was reached, removing 2<sup>31</sup>+2 values from the set of valid version numbers (all negative numbers, as nVersion is interpreted as a signed integer, as well as 0 and 1). This indicates another downside this approach: every upgrade permanently restricts the set of allowed nVersion field values. This approach was later reused in BIP 66 and BIP 65, which further removed nVersions 2 and 3 as valid options. As will be shown further, this is unnecessary. ==Specification== -===Mechanism=== +Each soft fork deployment is specified by the following per-chain parameters (further elaborated below): -'''Bit flags''' -We are permitting several independent soft forks to be deployed in parallel. For each, a bit B is chosen from the set {0,1,2,...,28}, which is not currently in use for any other ongoing soft fork. Miners signal intent to enforce the new rules associated with the proposed soft fork by setting bit 1<sup>B</sup> in nVersion to 1 in their blocks. +# The '''bit''' determines which bit in the nVersion field of the block is to be used to signal the soft fork lock-in and activation. It is chosen from the set {0,1,2,...,28}. +# The '''starttime''' specifies a minimum median time past of a block at which the bit gains its meaning. +# The '''timeout''' specifies a time at which the deployment is considered failed. If the median time past of a block >= timeout and the soft fork has not yet locked in (including this block's bit state), the deployment is considered failed on all descendants of the block. -'''High bits''' -The highest 3 bits are set to 001, so the range of actually possible nVersion values is [0x20000000...0x3FFFFFFF], inclusive. This leaves two future upgrades for different mechanisms (top bits 010 and 011), while complying to the constraints set by BIP34 and BIP66. Having more than 29 available bits for parallel soft forks does not add anything anyway, as the (nVersion >= 3) requirement already makes that impossible. +===Selection guidelines=== -'''States''' -With every softfork proposal we associate a state BState, which begins -at ''defined'', and can be ''locked-in'', ''activated'', -or ''failed''. Transitions are considered after each -retarget period. +The following guidelines are suggested for selecting these parameters for a soft fork: -'''Soft Fork Support''' -Software which supports the change should begin by setting B in all blocks -mined until it is resolved. +# '''bit''' should be selected such that no two concurrent softforks use the same bit. +# '''starttime''' should be set to some date in the future, approximately one month after a software release date including the soft fork. This allows for some release delays, while preventing triggers as a result of parties running pre-release software. +# '''timeout''' should be 1 year (31536000 seconds) after starttime. - if (BState != activated && BState != failed) { - SetBInBlock(); - } +A later deployment using the same bit is possible as long as the starttime is after the previous one's +timeout or activation, but it is discouraged until necessary, and even then recommended to have a pause in between to detect buggy software. + +===States=== + +With each block and soft fork, we associate a deployment state. The possible states are: + +# '''DEFINED''' is the first state that each soft fork starts out as. The genesis block is by definition in this state for each deployment. +# '''STARTED''' for blocks past the starttime. +# '''LOCKED_IN''' for one retarget period after the first retarget period with STARTED blocks of which at least threshold have the associated bit set in nVersion. +# '''ACTIVE''' for all blocks after the LOCKED_IN retarget period. +# '''FAILED''' for one retarget period past the timeout time, if LOCKED_IN was not reached. + +===Bit flags=== + +Blocks in the STARTED state get an nVersion whose bit position bit is set to 1. The top 3 bits of such blocks must be +001, so the range of actually possible nVersion values is [0x20000000...0x3FFFFFFF], inclusive. + +Due to the constraints set by BIP 34, BIP 66 and BIP 65, we only have 0x7FFFFFFB possible nVersion values available. +This restricts us to at most 30 independent deployments. By restricting the top 3 bits to 001 we get 29 out of those +for the purposes of this proposal, and support two future upgrades for different mechanisms (top bits 010 and 011). +When a block nVersion does not have top bits 001, it is treated as if all +bits are 0 for the purposes of deployments. -'''Success: Lock-in Threshold''' -If bit B is set in 1916 (1512 on testnet) or -more of the 2016 blocks within a retarget period, it is considered -''locked-in''. Miners should continue setting bit B, so uptake is -visible. +Miners should continue setting the bit in LOCKED_IN phase so uptake is visible, though this has no effect on +consensus rules. - if (NextBlockHeight % 2016 == 0) { - if (BState == defined && Previous2016BlocksCountB() >= 1916) { - BState = locked-in; - BActiveHeight = NextBlockHeight + 2016; +===New consensus rules=== + +The new consensus rules for each soft fork are enforced for each block that has ACTIVE state. + +===State transitions=== + +<img src="bip-0009/states.png" align="middle"></img> + +The genesis block has state DEFINED for each deployment, by definition. + + State GetStateForBlock(block) { + if (block.height == 0) { + return DEFINED; } - } -'''Success: Activation Delay''' -The consensus rules related to ''locked-in'' soft fork will be enforced in -the second retarget period; ie. there is a one retarget period in -which the remaining 5% can upgrade. At the that activation block and -after, miners should stop setting bit B, which may be reused for a different soft fork. - - if (BState == locked-in && NextBlockHeight == BActiveHeight) { - BState = activated; - ApplyRulesForBFromNextBlock(); - /* B can be reused, immediately */ - } - -'''Failure: Timeout''' -A soft fork proposal should include a ''timeout''. This is measured -as the beginning of a calendar year as per this table (suggest -adding three to the current calendar year when drafting the soft fork proposal): - -{| -! Timeout Year -! >= Seconds -! Timeout Year -! >= Seconds -|- -|2018 -|1514764800 -|2026 -|1767225600 -|- -|2019 -|1546300800 -|2027 -|1798761600 -|- -|2020 -|1577836800 -|2028 -|1830297600 -|- -|2021 -|1609459200 -|2029 -|1861920000 -|- -|2022 -|1640995200 -|2030 -|1893456000 -|- -|2023 -|1672531200 -|2031 -|1924992000 -|- -|2024 -|1704067200 -|2032 -|1956528000 -|- -|2025 -|1735689600 -|2033 -|1988150400 -|} - -If the soft fork still not ''locked-in'' and the -GetMedianTimePast() of a block following a retarget period is at or -past this timeout, miners should cease setting this bit. - - if (NextBlockHeight % 2016 == 0) { - if (BState == defined && GetMedianTimePast(nextblock) >= BFinalYear) { - BState = failed; +All blocks within a retarget period have the same state. This means that if +floor(block1.height / 2016) = floor(block2.height / 2016), they are guaranteed to have the same state for every +deployment. + + if ((block.height % 2016) != 0) { + return GetStateForBlock(block.parent); } - } -After another retarget period (to allow detection of buggy miners), -the bit may be reused. +Otherwise, the next state depends on the previous state: + + switch (GetStateForBlock(GetAncestorAtHeight(block, block.height - 2016))) { + +We remain in the initial state until either we pass the start time or the timeout. GetMedianTimePast in the code below +refers to the median nTime of a block and its 10 predecessors. The expression GetMedianTimePast(block.parent) is +referred to as MTP in the diagram above, and is treated as a monotonic clock defined by the chain. + + case DEFINED: + if (GetMedianTimePast(block.parent) >= timeout) { + return FAILED; + } + if (GetMedianTimePast(block.parent) >= starttime) { + return STARTED; + } + return DEFINED; + +After a period in the STARTED state, if we're past the timeout, we switch to FAILED. If not, we tally the bits set, +and transition to LOCKED_IN if a sufficient number of blocks in the past period set the deployment bit in their +version numbers. The threshold is 1915 blocks (95% of 2016), or 1512 for testnet (75% of 2016). +The transition to FAILED takes precendence, as otherwise an ambiguity can arise. +There could be two non-overlapping deployments on the same bit, where the first one transitions to LOCKED_IN while the +other one simultaneously transitions to STARTED, which would mean both would demand setting the bit. + +Note that a block's state never depends on its own nVersion; only on that of its ancestors. + + case STARTED: { + if (GetMedianTimePast(block.parent) >= timeout) { + return FAILED; + } + int count = 0; + walk = block; + for (i = 0; i < 2016; i++) { + walk = walk.parent; + if (walk.nVersion & 0xE0000000 == 0x2000000 && (walk.nVersion >> bit) & 1 == 1) { + count++; + } + } + if (count >= threshold) { + return LOCKED_IN; + } + } + +After a retarget period of LOCKED_IN, we automatically transition to ACTIVE. + + case LOCKED_IN: + return ACTIVE; + +And ACTIVE and FAILED are terminal states, which a deployment stays in once they're reached. -'''Warning system''' -To support upgrade warnings, an extra "unknown upgrade" is tracked, using the "implicit bit" mask = (block.nVersion & ~expectedVersion) != 0. Mask will be non-zero whenever an unexpected bit is set in nVersion. Whenever lock-in for the unknown upgrade is detected, the software should warn loudly about the upcoming soft fork. It should warn even more loudly after the next retarget period. + case ACTIVE: + return ACTIVE; -'''Forks''' + case FAILED: + return FAILED; + } + } + +'''Implementation''' It should be noted that the states are maintained along block chain branches, but may need recomputation when a reorganization happens. -===Support for future changes=== +Given that the state for a specific block/deployment combination is completely determined by its ancestry before the +current retarget period (i.e. up to and including its ancestor with height block.height - 1 - (block.height % 2016)), +it is possible to implement the mechanism above efficiently and safely by caching the resulting state of every multiple-of-2016 +block, indexed by its parent. + +===Warning mechanism=== + +To support upgrade warnings, an extra "unknown upgrade" is tracked, using the "implicit bit" mask = (block.nVersion & ~expectedVersion) != 0. Mask will be non-zero whenever an unexpected bit is set in nVersion. Whenever LOCKED_IN for the unknown upgrade is detected, the software should warn loudly about the upcoming soft fork. It should warn even more loudly after the next retarget period (when the unknown upgrade is in the ACTIVE state). + +==Support for future changes== The mechanism described above is very generic, and variations are possible for future soft forks. Here are some ideas that can be taken into account. '''Modified thresholds''' -The 95% threshold (based on in BIP 34) does not have to be maintained for eternity, but changes should take the effect on the warning system into account. In particular, having a lock-in threshold that is incompatible with the one used for the warning system may have long-term effects, as the warning system cannot rely on a permanently detectable condition anymore. +The 1915 threshold (based on in BIP 34's 95%) does not have to be maintained for eternity, but changes should take the effect on the warning system into account. In particular, having a lock-in threshold that is incompatible with the one used for the warning system may have long-term effects, as the warning system cannot rely on a permanently detectable condition anymore. '''Conflicting soft forks''' At some point, two mutually exclusive soft forks may be proposed. The naive way to deal with this is to never create software that implements both, but that is making a bet that at least one side is guaranteed to lose. Better would be to encode "soft fork X cannot be locked-in" as consensus rule for the conflicting soft fork - allowing software that supports both, but can never trigger conflicting changes. diff --git a/bip-0009/states.png b/bip-0009/states.png Binary files differnew file mode 100644 index 0000000..09312a1 --- /dev/null +++ b/bip-0009/states.png diff --git a/bip-0010.mediawiki b/bip-0010.mediawiki index 4307f3e..d15cd77 100644 --- a/bip-0010.mediawiki +++ b/bip-0010.mediawiki @@ -1,8 +1,8 @@ <pre> BIP: 10 Title: Multi-Sig Transaction Distribution - Author: Alan Reiner - Status: Withdrawn + Author: Alan Reiner <etotheipi@gmail.com> + Status: Withdrawn Type: Informational Created: 2011-10-28 </pre> diff --git a/bip-0011.mediawiki b/bip-0011.mediawiki index 2499ac0..4b12340 100644 --- a/bip-0011.mediawiki +++ b/bip-0011.mediawiki @@ -2,7 +2,7 @@ BIP: 11 Title: M-of-N Standard Transactions Author: Gavin Andresen <gavinandresen@gmail.com> - Status: Accepted + Status: Final Type: Standards Track Created: 2011-10-18 Post-History: 2011-10-02 diff --git a/bip-0014.mediawiki b/bip-0014.mediawiki index 111eb78..f11cb63 100644 --- a/bip-0014.mediawiki +++ b/bip-0014.mediawiki @@ -1,9 +1,9 @@ <pre> BIP: 14 - Title: BIP Protocol Version and User Agent + Title: Protocol Version and User Agent Author: Amir Taaki <genjix@riseup.net> Patrick Strateman <bitcoin-bips@covertinferno.org> - Status: Accepted + Status: Final Type: Standards Track Created: 2011-11-10 Post-History: 2011-11-02 diff --git a/bip-0015.mediawiki b/bip-0015.mediawiki index c08498f..b90539d 100644 --- a/bip-0015.mediawiki +++ b/bip-0015.mediawiki @@ -1,6 +1,6 @@ <pre> BIP: 15 - Title: BIP Aliases + Title: Aliases Author: Amir Taaki <genjix@riseup.net> Status: Deferred Type: Standards Track diff --git a/bip-0016.mediawiki b/bip-0016.mediawiki index 0a539fc..25b652d 100644 --- a/bip-0016.mediawiki +++ b/bip-0016.mediawiki @@ -37,7 +37,7 @@ The rules for validating these outpoints when relaying transactions or consideri # Normal validation is done: an initial stack is created from the signatures and {serialized script}, and the hash of the script is computed and validation fails immediately if it does not match the hash in the outpoint. # {serialized script} is popped off the initial stack, and the transaction is validated again using the popped stack and the deserialized script as the scriptPubKey. -These new rules should only be applied when validating transactions in blocks with timestamps >= 1333238400 (Apr 1 2012) <ref>[https://github.com/bitcoin/bitcoin/commit/8f188ece3c82c4cf5d52a3363e7643c23169c0ff Remove -bip16 and -paytoscripthashtime command-line arguments]</ref>. There are transaction earlier than 13333238400 in the block chain that fail these new validation rules. <ref>[http://blockexplorer.com/tx/6a26d2ecb67f27d1fa5524763b49029d7106e91e3cc05743073461a719776192 Transaction 6a26d2ecb67f27d1fa5524763b49029d7106e91e3cc05743073461a719776192]</ref>. Older transactions must be validated under the old rules. (see the Backwards Compatibility section for details). +These new rules should only be applied when validating transactions in blocks with timestamps >= 1333238400 (Apr 1 2012) <ref>[https://github.com/bitcoin/bitcoin/commit/8f188ece3c82c4cf5d52a3363e7643c23169c0ff Remove -bip16 and -paytoscripthashtime command-line arguments]</ref>. There are transaction earlier than 1333238400 in the block chain that fail these new validation rules. <ref>[http://blockexplorer.com/tx/6a26d2ecb67f27d1fa5524763b49029d7106e91e3cc05743073461a719776192 Transaction 6a26d2ecb67f27d1fa5524763b49029d7106e91e3cc05743073461a719776192]</ref>. Older transactions must be validated under the old rules. (see the Backwards Compatibility section for details). For example, the scriptPubKey and corresponding scriptSig for a one-signature-required transaction is: @@ -98,7 +98,7 @@ If a majority of hashing power does not support the new validation rules, then r ===520-byte limitation on serialized script size=== -As a consequence of the requirement for backwards compatiblity the serialized script is itself subject to the same rules as any other PUSHDATA operation, including the rule that no data greater than 520 bytes may be pushed to the stack. Thus is it not possible to spend a P2SH output if the redemption script it refers to is >520 bytes in length. For instance while the OP_CHECKMULTISIG opcode can itself accept up to 20 pubkeys, with 33-byte compressed pubkeys it is only possible to spend a P2SH output requiring a maximum of 15 pubkeys to redeem: 3 bytes + 15 pubkeys * 34 bytes/pubkey = 513 bytes. +As a consequence of the requirement for backwards compatiblity the serialized script is itself subject to the same rules as any other PUSHDATA operation, including the rule that no data greater than 520 bytes may be pushed to the stack. Thus it is not possible to spend a P2SH output if the redemption script it refers to is >520 bytes in length. For instance while the OP_CHECKMULTISIG opcode can itself accept up to 20 pubkeys, with 33-byte compressed pubkeys it is only possible to spend a P2SH output requiring a maximum of 15 pubkeys to redeem: 3 bytes + 15 pubkeys * 34 bytes/pubkey = 513 bytes. ==Reference Implementation== diff --git a/bip-0021.mediawiki b/bip-0021.mediawiki index 2706926..e7094e5 100644 --- a/bip-0021.mediawiki +++ b/bip-0021.mediawiki @@ -3,7 +3,7 @@ Title: URI Scheme Author: Nils Schneider <nils.schneider@gmail.com> Matt Corallo <bip21@bluematt.me> - Status: Accepted + Status: Final Type: Standards Track Created: 2012-01-29 </pre> @@ -56,7 +56,6 @@ The scheme component ("bitcoin:") is case-insensitive, and implementations must *address: bitcoin address *message: message that describes the transaction to the user ([[#Examples|see examples below]]) *size: amount of base bitcoin units ([[#Transfer amount/size|see below]]) -*paycode: payment code (BIP-47) *(others): optional, for future extensions ==== Transfer amount/size ==== @@ -68,11 +67,6 @@ I.e. amount=50.00 or amount=50 is treated as 50 BTC, and amount=50,000.00 is inv Bitcoin clients MAY display the amount in any format that is not intended to deceive the user. They SHOULD choose a format that is foremost least confusing, and only after that most reasonable given the amount requested. For example, so long as the majority of users work in BTC units, values should always be displayed in BTC by default, even if mBTC or TBC would otherwise be a more logical interpretation of the amount. - -==== Payment code ==== - -If a URI provides a payment code, and if the client supports BIP-47, then the resulting transaction SHOULD construct a transaction per BIP-47 instead of using the address provided in the URI. - == Rationale == ===Payment identifiers, not person identifiers=== @@ -128,6 +122,3 @@ Characters must be URI encoded properly. === Bitcoin clients === * Bitcoin-Qt supports the old version of Bitcoin URIs (ie without the req- prefix), with Windows and KDE integration as of commit 70f55355e29c8e45b607e782c5d76609d23cc858. -==References== - -* [[bip-0047.mediawiki|BIP47 - Reusable Payment Codes for Hierarchical Deterministic Wallets]] diff --git a/bip-0022.mediawiki b/bip-0022.mediawiki index b39f957..35b59be 100644 --- a/bip-0022.mediawiki +++ b/bip-0022.mediawiki @@ -2,7 +2,7 @@ BIP: 22 Title: getblocktemplate - Fundamentals Author: Luke Dashjr <luke+bip22@dashjr.org> - Status: Accepted + Status: Final Type: Standards Track Created: 2012-02-28 </pre> diff --git a/bip-0023.mediawiki b/bip-0023.mediawiki index a53b00b..874e60a 100644 --- a/bip-0023.mediawiki +++ b/bip-0023.mediawiki @@ -2,7 +2,7 @@ BIP: 23 Title: getblocktemplate - Pooled Mining Author: Luke Dashjr <luke+bip22@dashjr.org> - Status: Accepted + Status: Final Type: Standards Track Created: 2012-02-28 </pre> diff --git a/bip-0031.mediawiki b/bip-0031.mediawiki index 8adcd29..1bfe143 100644 --- a/bip-0031.mediawiki +++ b/bip-0031.mediawiki @@ -2,7 +2,7 @@ BIP: 31 Title: Pong message Author: Mike Hearn <hearn@google.com> - Status: Accepted + Status: Final Type: Standards Track Created: 2012-04-11 </pre> diff --git a/bip-0032.mediawiki b/bip-0032.mediawiki index 28541f5..8692c6d 100644 --- a/bip-0032.mediawiki +++ b/bip-0032.mediawiki @@ -7,8 +7,8 @@ RECENT CHANGES: <pre> BIP: 32 Title: Hierarchical Deterministic Wallets - Author: Pieter Wuille - Status: Accepted + Author: Pieter Wuille <pieter.wuille@gmail.com> + Status: Final Type: Informational Created: 2012-02-11 </pre> @@ -259,7 +259,7 @@ PyCoin (https://github.com/richardkiss/pycoin) is a suite of utilities for deali A Java implementation is available at https://github.com/bitsofproof/supernode/blob/1.1/api/src/main/java/com/bitsofproof/supernode/api/ExtendedKey.java -A C++ implementation is available at https://github.com/CodeShark/CoinClasses/tree/master/tests/hdwallets +A C++ implementation is available at https://github.com/ciphrex/mSIGNA/blob/master/deps/CoinCore/src/hdkeys.h An Objective-C implementation is available at https://github.com/oleganza/CoreBitcoin/blob/master/CoreBitcoin/BTCKeychain.h @@ -281,4 +281,5 @@ A Haskell implementation is available at https://github.com/haskoin/haskoin toge * Gregory Maxwell for the original idea of type-2 deterministic wallets, and many discussions about it. * Alan Reiner for the implementation of this scheme in Armory, and the suggestions that followed from that. +* Eric Lombrozo for reviewing and revising this BIP. * Mike Caldwell for the version bytes to obtain human-recognizable Base58 strings. diff --git a/bip-0034.mediawiki b/bip-0034.mediawiki index 245985c..4870fc1 100644 --- a/bip-0034.mediawiki +++ b/bip-0034.mediawiki @@ -2,7 +2,7 @@ BIP: 34 Title: Block v2, Height in Coinbase Author: Gavin Andresen <gavinandresen@gmail.com> - Status: Accepted + Status: Final Type: Standards Track Created: 2012-07-06 </pre> @@ -19,7 +19,7 @@ Bitcoin blocks and transactions are versioned binary structures. Both currently ==Specification== # Treat transactions with a version greater than 1 as non-standard (official Satoshi client will not mine or relay them). -# Add height as the first item in the coinbase transaction's scriptSig, and increase block version to 2. The format of the height is "serialized CScript" -- first byte is number of bytes in the number (will be 0x03 on main net for the next 300 or so years), following bytes are little-endian representation of the number. Height is the height of the mined block in the block chain, where the genesis block is height zero (0). +# Add height as the first item in the coinbase transaction's scriptSig, and increase block version to 2. The format of the height is "serialized CScript" -- first byte is number of bytes in the number (will be 0x03 on main net for the next 150 or so years with 2<sup>23</sup>-1 blocks), following bytes are little-endian representation of the number (including a sign bit). Height is the height of the mined block in the block chain, where the genesis block is height zero (0). # 75% rule: If 750 of the last 1,000 blocks are version 2 or greater, reject invalid version 2 blocks. (testnet3: 51 of last 100) # 95% rule ("Point of no return"): If 950 of the last 1,000 blocks are version 2 or greater, reject all version 1 blocks. (testnet3: 75 of last 100) diff --git a/bip-0035.mediawiki b/bip-0035.mediawiki index cdadd1d..c66735c 100644 --- a/bip-0035.mediawiki +++ b/bip-0035.mediawiki @@ -2,7 +2,7 @@ BIP: 35 Title: mempool message Author: Jeff Garzik <jgarzik@exmulti.com> - Status: Accepted + Status: Final Type: Standards Track Created: 2012-08-16 </pre> diff --git a/bip-0037.mediawiki b/bip-0037.mediawiki index 77b917b..f76891e 100644 --- a/bip-0037.mediawiki +++ b/bip-0037.mediawiki @@ -1,8 +1,9 @@ <pre> BIP: 37 Title: Connection Bloom filtering - Author: Mike Hearn <hearn@google.com>, Matt Corallo <bip@bluematt.me> - Status: Accepted + Author: Mike Hearn <hearn@google.com> + Matt Corallo <bip@bluematt.me> + Status: Final Type: Standards Track Created: 2012-10-24 </pre> diff --git a/bip-0038.mediawiki b/bip-0038.mediawiki index 4fc3207..650b7d0 100644 --- a/bip-0038.mediawiki +++ b/bip-0038.mediawiki @@ -1,8 +1,8 @@ <pre> BIP: 38 Title: Passphrase-protected private key - Authors: Mike Caldwell - Aaron Voisine <voisine@gmail.com> + Author: Mike Caldwell <mcaldwell@swipeclock.com> + Aaron Voisine <voisine@gmail.com> Status: Draft (Some confusion applies: The announcements for this never made it to the list, so it hasn't had public discussion) Type: Standards Track Created: 2012-11-20 @@ -210,6 +210,9 @@ Added to alpha version of Casascius Bitcoin Address Utility for Windows availabl Click "Tools" then "PPEC Keygen" (provisional name) +==Other implementations== +* Javascript - https://github.com/bitcoinjs/bip38 + ==Test vectors== ===No compression, no EC multiply=== diff --git a/bip-0039.mediawiki b/bip-0039.mediawiki index da59124..c44ad3e 100644 --- a/bip-0039.mediawiki +++ b/bip-0039.mediawiki @@ -1,12 +1,12 @@ <pre> - BIP: BIP-0039 - Title: Mnemonic code for generating deterministic keys - Authors: Marek Palatinus <slush@satoshilabs.com> - Pavol Rusnak <stick@satoshilabs.com> - Aaron Voisine <voisine@gmail.com> - Sean Bowe <ewillbefull@gmail.com> - Status: Draft - Type: Standards Track + BIP: 39 + Title: Mnemonic code for generating deterministic keys + Author: Marek Palatinus <slush@satoshilabs.com> + Pavol Rusnak <stick@satoshilabs.com> + Aaron Voisine <voisine@gmail.com> + Sean Bowe <ewillbefull@gmail.com> + Status: Draft + Type: Standards Track Created: 2013-09-10 </pre> diff --git a/bip-0039/bip-0039-wordlists.md b/bip-0039/bip-0039-wordlists.md index 203ba06..aef1a23 100644 --- a/bip-0039/bip-0039-wordlists.md +++ b/bip-0039/bip-0039-wordlists.md @@ -6,6 +6,7 @@ * [Chinese (Simplified)](chinese_simplified.txt) * [Chinese (Traditional)](chinese_traditional.txt) * [French](french.txt) +* [Italian](italian.txt) ##Wordlists (Special Considerations) @@ -57,3 +58,26 @@ Credits: @Kirvx @NicolasDorier @ecdsa @EricLarch 15. No words in conflict with the spelling corrections of 1990 (http://goo.gl/Y8DU4z). 16. No embarrassing words (in a very, very large scope) or belonging to a particular religion. 17. No identical words with the Spanish wordlist (as Y75QMO wants). + +### Italian + +Credits: @paoloaga @Polve + +Words chosen using the following rules: + +1. Simple and common italian words. +2. Length between 4 and 8 characters. +3. First 4 letters must be unique between all words. +4. No accents or special characters. +5. No complex verb forms. +6. No plural words. +7. No words that remind negative/sad/bad things. +8. If both female/male words are available, choose male version. +9. No words with double vocals (like: lineetta). +10. No words already used in other language mnemonic sets. +11. If 3 of the first 4 letters are already used in the same sequence in another mnemonic word, there must be at least other 3 different letters. +12. If 3 of the first 4 letters are already used in the same sequence in another mnemonic word, there not must be the same sequence of 3 or more letters. + +Rules 11 and 12 prevent the selection words that are not different enough. This makes each word more recognizable among others and less error prone. For example: the wordlist contains "atono", then "atomo" is rejected, but "atomico" is good. + +All the words have been manually selected and automatically checked against the rules. diff --git a/bip-0039/italian.txt b/bip-0039/italian.txt new file mode 100644 index 0000000..c47370f --- /dev/null +++ b/bip-0039/italian.txt @@ -0,0 +1,2048 @@ +abaco +abbaglio +abbinato +abete +abisso +abolire +abrasivo +abrogato +accadere +accenno +accusato +acetone +achille +acido +acqua +acre +acrilico +acrobata +acuto +adagio +addebito +addome +adeguato +aderire +adipe +adottare +adulare +affabile +affetto +affisso +affranto +aforisma +afoso +africano +agave +agente +agevole +aggancio +agire +agitare +agonismo +agricolo +agrumeto +aguzzo +alabarda +alato +albatro +alberato +albo +albume +alce +alcolico +alettone +alfa +algebra +aliante +alibi +alimento +allagato +allegro +allievo +allodola +allusivo +almeno +alogeno +alpaca +alpestre +altalena +alterno +alticcio +altrove +alunno +alveolo +alzare +amalgama +amanita +amarena +ambito +ambrato +ameba +america +ametista +amico +ammasso +ammenda +ammirare +ammonito +amore +ampio +ampliare +amuleto +anacardo +anagrafe +analista +anarchia +anatra +anca +ancella +ancora +andare +andrea +anello +angelo +angolare +angusto +anima +annegare +annidato +anno +annuncio +anonimo +anticipo +anzi +apatico +apertura +apode +apparire +appetito +appoggio +approdo +appunto +aprile +arabica +arachide +aragosta +araldica +arancio +aratura +arazzo +arbitro +archivio +ardito +arenile +argento +argine +arguto +aria +armonia +arnese +arredato +arringa +arrosto +arsenico +arso +artefice +arzillo +asciutto +ascolto +asepsi +asettico +asfalto +asino +asola +aspirato +aspro +assaggio +asse +assoluto +assurdo +asta +astenuto +astice +astratto +atavico +ateismo +atomico +atono +attesa +attivare +attorno +attrito +attuale +ausilio +austria +autista +autonomo +autunno +avanzato +avere +avvenire +avviso +avvolgere +azione +azoto +azzimo +azzurro +babele +baccano +bacino +baco +badessa +badilata +bagnato +baita +balcone +baldo +balena +ballata +balzano +bambino +bandire +baraonda +barbaro +barca +baritono +barlume +barocco +basilico +basso +batosta +battuto +baule +bava +bavosa +becco +beffa +belgio +belva +benda +benevole +benigno +benzina +bere +berlina +beta +bibita +bici +bidone +bifido +biga +bilancia +bimbo +binocolo +biologo +bipede +bipolare +birbante +birra +biscotto +bisesto +bisnonno +bisonte +bisturi +bizzarro +blando +blatta +bollito +bonifico +bordo +bosco +botanico +bottino +bozzolo +braccio +bradipo +brama +branca +bravura +bretella +brevetto +brezza +briglia +brillante +brindare +broccolo +brodo +bronzina +brullo +bruno +bubbone +buca +budino +buffone +buio +bulbo +buono +burlone +burrasca +bussola +busta +cadetto +caduco +calamaro +calcolo +calesse +calibro +calmo +caloria +cambusa +camerata +camicia +cammino +camola +campale +canapa +candela +cane +canino +canotto +cantina +capace +capello +capitolo +capogiro +cappero +capra +capsula +carapace +carcassa +cardo +carisma +carovana +carretto +cartolina +casaccio +cascata +caserma +caso +cassone +castello +casuale +catasta +catena +catrame +cauto +cavillo +cedibile +cedrata +cefalo +celebre +cellulare +cena +cenone +centesimo +ceramica +cercare +certo +cerume +cervello +cesoia +cespo +ceto +chela +chiaro +chicca +chiedere +chimera +china +chirurgo +chitarra +ciao +ciclismo +cifrare +cigno +cilindro +ciottolo +circa +cirrosi +citrico +cittadino +ciuffo +civetta +civile +classico +clinica +cloro +cocco +codardo +codice +coerente +cognome +collare +colmato +colore +colposo +coltivato +colza +coma +cometa +commando +comodo +computer +comune +conciso +condurre +conferma +congelare +coniuge +connesso +conoscere +consumo +continuo +convegno +coperto +copione +coppia +copricapo +corazza +cordata +coricato +cornice +corolla +corpo +corredo +corsia +cortese +cosmico +costante +cottura +covato +cratere +cravatta +creato +credere +cremoso +crescita +creta +criceto +crinale +crisi +critico +croce +cronaca +crostata +cruciale +crusca +cucire +cuculo +cugino +cullato +cupola +curatore +cursore +curvo +cuscino +custode +dado +daino +dalmata +damerino +daniela +dannoso +danzare +datato +davanti +davvero +debutto +decennio +deciso +declino +decollo +decreto +dedicato +definito +deforme +degno +delegare +delfino +delirio +delta +demenza +denotato +dentro +deposito +derapata +derivare +deroga +descritto +deserto +desiderio +desumere +detersivo +devoto +diametro +dicembre +diedro +difeso +diffuso +digerire +digitale +diluvio +dinamico +dinnanzi +dipinto +diploma +dipolo +diradare +dire +dirotto +dirupo +disagio +discreto +disfare +disgelo +disposto +distanza +disumano +dito +divano +divelto +dividere +divorato +doblone +docente +doganale +dogma +dolce +domato +domenica +dominare +dondolo +dono +dormire +dote +dottore +dovuto +dozzina +drago +druido +dubbio +dubitare +ducale +duna +duomo +duplice +duraturo +ebano +eccesso +ecco +eclissi +economia +edera +edicola +edile +editoria +educare +egemonia +egli +egoismo +egregio +elaborato +elargire +elegante +elencato +eletto +elevare +elfico +elica +elmo +elsa +eluso +emanato +emblema +emesso +emiro +emotivo +emozione +empirico +emulo +endemico +enduro +energia +enfasi +enoteca +entrare +enzima +epatite +epilogo +episodio +epocale +eppure +equatore +erario +erba +erboso +erede +eremita +erigere +ermetico +eroe +erosivo +errante +esagono +esame +esanime +esaudire +esca +esempio +esercito +esibito +esigente +esistere +esito +esofago +esortato +esoso +espanso +espresso +essenza +esso +esteso +estimare +estonia +estroso +esultare +etilico +etnico +etrusco +etto +euclideo +europa +evaso +evidenza +evitato +evoluto +evviva +fabbrica +faccenda +fachiro +falco +famiglia +fanale +fanfara +fango +fantasma +fare +farfalla +farinoso +farmaco +fascia +fastoso +fasullo +faticare +fato +favoloso +febbre +fecola +fede +fegato +felpa +feltro +femmina +fendere +fenomeno +fermento +ferro +fertile +fessura +festivo +fetta +feudo +fiaba +fiducia +fifa +figurato +filo +finanza +finestra +finire +fiore +fiscale +fisico +fiume +flacone +flamenco +flebo +flemma +florido +fluente +fluoro +fobico +focaccia +focoso +foderato +foglio +folata +folclore +folgore +fondente +fonetico +fonia +fontana +forbito +forchetta +foresta +formica +fornaio +foro +fortezza +forzare +fosfato +fosso +fracasso +frana +frassino +fratello +freccetta +frenata +fresco +frigo +frollino +fronde +frugale +frutta +fucilata +fucsia +fuggente +fulmine +fulvo +fumante +fumetto +fumoso +fune +funzione +fuoco +furbo +furgone +furore +fuso +futile +gabbiano +gaffe +galateo +gallina +galoppo +gambero +gamma +garanzia +garbo +garofano +garzone +gasdotto +gasolio +gastrico +gatto +gaudio +gazebo +gazzella +geco +gelatina +gelso +gemello +gemmato +gene +genitore +gennaio +genotipo +gergo +ghepardo +ghiaccio +ghisa +giallo +gilda +ginepro +giocare +gioiello +giorno +giove +girato +girone +gittata +giudizio +giurato +giusto +globulo +glutine +gnomo +gobba +golf +gomito +gommone +gonfio +gonna +governo +gracile +grado +grafico +grammo +grande +grattare +gravoso +grazia +greca +gregge +grifone +grigio +grinza +grotta +gruppo +guadagno +guaio +guanto +guardare +gufo +guidare +ibernato +icona +identico +idillio +idolo +idra +idrico +idrogeno +igiene +ignaro +ignorato +ilare +illeso +illogico +illudere +imballo +imbevuto +imbocco +imbuto +immane +immerso +immolato +impacco +impeto +impiego +importo +impronta +inalare +inarcare +inattivo +incanto +incendio +inchino +incisivo +incluso +incontro +incrocio +incubo +indagine +india +indole +inedito +infatti +infilare +inflitto +ingaggio +ingegno +inglese +ingordo +ingrosso +innesco +inodore +inoltrare +inondato +insano +insetto +insieme +insonnia +insulina +intasato +intero +intonaco +intuito +inumidire +invalido +invece +invito +iperbole +ipnotico +ipotesi +ippica +iride +irlanda +ironico +irrigato +irrorare +isolato +isotopo +isterico +istituto +istrice +italia +iterare +labbro +labirinto +lacca +lacerato +lacrima +lacuna +laddove +lago +lampo +lancetta +lanterna +lardoso +larga +laringe +lastra +latenza +latino +lattuga +lavagna +lavoro +legale +leggero +lembo +lentezza +lenza +leone +lepre +lesivo +lessato +lesto +letterale +leva +levigato +libero +lido +lievito +lilla +limatura +limitare +limpido +lineare +lingua +liquido +lira +lirica +lisca +lite +litigio +livrea +locanda +lode +logica +lombare +londra +longevo +loquace +lorenzo +loto +lotteria +luce +lucidato +lumaca +luminoso +lungo +lupo +luppolo +lusinga +lusso +lutto +macabro +macchina +macero +macinato +madama +magico +maglia +magnete +magro +maiolica +malafede +malgrado +malinteso +malsano +malto +malumore +mana +mancia +mandorla +mangiare +manifesto +mannaro +manovra +mansarda +mantide +manubrio +mappa +maratona +marcire +maretta +marmo +marsupio +maschera +massaia +mastino +materasso +matricola +mattone +maturo +mazurca +meandro +meccanico +mecenate +medesimo +meditare +mega +melassa +melis +melodia +meninge +meno +mensola +mercurio +merenda +merlo +meschino +mese +messere +mestolo +metallo +metodo +mettere +miagolare +mica +micelio +michele +microbo +midollo +miele +migliore +milano +milite +mimosa +minerale +mini +minore +mirino +mirtillo +miscela +missiva +misto +misurare +mitezza +mitigare +mitra +mittente +mnemonico +modello +modifica +modulo +mogano +mogio +mole +molosso +monastero +monco +mondina +monetario +monile +monotono +monsone +montato +monviso +mora +mordere +morsicato +mostro +motivato +motosega +motto +movenza +movimento +mozzo +mucca +mucosa +muffa +mughetto +mugnaio +mulatto +mulinello +multiplo +mummia +munto +muovere +murale +musa +muscolo +musica +mutevole +muto +nababbo +nafta +nanometro +narciso +narice +narrato +nascere +nastrare +naturale +nautica +naviglio +nebulosa +necrosi +negativo +negozio +nemmeno +neofita +neretto +nervo +nessuno +nettuno +neutrale +neve +nevrotico +nicchia +ninfa +nitido +nobile +nocivo +nodo +nome +nomina +nordico +normale +norvegese +nostrano +notare +notizia +notturno +novella +nucleo +nulla +numero +nuovo +nutrire +nuvola +nuziale +oasi +obbedire +obbligo +obelisco +oblio +obolo +obsoleto +occasione +occhio +occidente +occorrere +occultare +ocra +oculato +odierno +odorare +offerta +offrire +offuscato +oggetto +oggi +ognuno +olandese +olfatto +oliato +oliva +ologramma +oltre +omaggio +ombelico +ombra +omega +omissione +ondoso +onere +onice +onnivoro +onorevole +onta +operato +opinione +opposto +oracolo +orafo +ordine +orecchino +orefice +orfano +organico +origine +orizzonte +orma +ormeggio +ornativo +orologio +orrendo +orribile +ortensia +ortica +orzata +orzo +osare +oscurare +osmosi +ospedale +ospite +ossa +ossidare +ostacolo +oste +otite +otre +ottagono +ottimo +ottobre +ovale +ovest +ovino +oviparo +ovocito +ovunque +ovviare +ozio +pacchetto +pace +pacifico +padella +padrone +paese +paga +pagina +palazzina +palesare +pallido +palo +palude +pandoro +pannello +paolo +paonazzo +paprica +parabola +parcella +parere +pargolo +pari +parlato +parola +partire +parvenza +parziale +passivo +pasticca +patacca +patologia +pattume +pavone +peccato +pedalare +pedonale +peggio +peloso +penare +pendice +penisola +pennuto +penombra +pensare +pentola +pepe +pepita +perbene +percorso +perdonato +perforare +pergamena +periodo +permesso +perno +perplesso +persuaso +pertugio +pervaso +pesatore +pesista +peso +pestifero +petalo +pettine +petulante +pezzo +piacere +pianta +piattino +piccino +picozza +piega +pietra +piffero +pigiama +pigolio +pigro +pila +pilifero +pillola +pilota +pimpante +pineta +pinna +pinolo +pioggia +piombo +piramide +piretico +pirite +pirolisi +pitone +pizzico +placebo +planare +plasma +platano +plenario +pochezza +poderoso +podismo +poesia +poggiare +polenta +poligono +pollice +polmonite +polpetta +polso +poltrona +polvere +pomice +pomodoro +ponte +popoloso +porfido +poroso +porpora +porre +portata +posa +positivo +possesso +postulato +potassio +potere +pranzo +prassi +pratica +precluso +predica +prefisso +pregiato +prelievo +premere +prenotare +preparato +presenza +pretesto +prevalso +prima +principe +privato +problema +procura +produrre +profumo +progetto +prolunga +promessa +pronome +proposta +proroga +proteso +prova +prudente +prugna +prurito +psiche +pubblico +pudica +pugilato +pugno +pulce +pulito +pulsante +puntare +pupazzo +pupilla +puro +quadro +qualcosa +quasi +querela +quota +raccolto +raddoppio +radicale +radunato +raffica +ragazzo +ragione +ragno +ramarro +ramingo +ramo +randagio +rantolare +rapato +rapina +rappreso +rasatura +raschiato +rasente +rassegna +rastrello +rata +ravveduto +reale +recepire +recinto +recluta +recondito +recupero +reddito +redimere +regalato +registro +regola +regresso +relazione +remare +remoto +renna +replica +reprimere +reputare +resa +residente +responso +restauro +rete +retina +retorica +rettifica +revocato +riassunto +ribadire +ribelle +ribrezzo +ricarica +ricco +ricevere +riciclato +ricordo +ricreduto +ridicolo +ridurre +rifasare +riflesso +riforma +rifugio +rigare +rigettato +righello +rilassato +rilevato +rimanere +rimbalzo +rimedio +rimorchio +rinascita +rincaro +rinforzo +rinnovo +rinomato +rinsavito +rintocco +rinuncia +rinvenire +riparato +ripetuto +ripieno +riportare +ripresa +ripulire +risata +rischio +riserva +risibile +riso +rispetto +ristoro +risultato +risvolto +ritardo +ritegno +ritmico +ritrovo +riunione +riva +riverso +rivincita +rivolto +rizoma +roba +robotico +robusto +roccia +roco +rodaggio +rodere +roditore +rogito +rollio +romantico +rompere +ronzio +rosolare +rospo +rotante +rotondo +rotula +rovescio +rubizzo +rubrica +ruga +rullino +rumine +rumoroso +ruolo +rupe +russare +rustico +sabato +sabbiare +sabotato +sagoma +salasso +saldatura +salgemma +salivare +salmone +salone +saltare +saluto +salvo +sapere +sapido +saporito +saraceno +sarcasmo +sarto +sassoso +satellite +satira +satollo +saturno +savana +savio +saziato +sbadiglio +sbalzo +sbancato +sbarra +sbattere +sbavare +sbendare +sbirciare +sbloccato +sbocciato +sbrinare +sbruffone +sbuffare +scabroso +scadenza +scala +scambiare +scandalo +scapola +scarso +scatenare +scavato +scelto +scenico +scettro +scheda +schiena +sciarpa +scienza +scindere +scippo +sciroppo +scivolo +sclerare +scodella +scolpito +scomparto +sconforto +scoprire +scorta +scossone +scozzese +scriba +scrollare +scrutinio +scuderia +scultore +scuola +scuro +scusare +sdebitare +sdoganare +seccatura +secondo +sedano +seggiola +segnalato +segregato +seguito +selciato +selettivo +sella +selvaggio +semaforo +sembrare +seme +seminato +sempre +senso +sentire +sepolto +sequenza +serata +serbato +sereno +serio +serpente +serraglio +servire +sestina +setola +settimana +sfacelo +sfaldare +sfamato +sfarzoso +sfaticato +sfera +sfida +sfilato +sfinge +sfocato +sfoderare +sfogo +sfoltire +sforzato +sfratto +sfruttato +sfuggito +sfumare +sfuso +sgabello +sgarbato +sgonfiare +sgorbio +sgrassato +sguardo +sibilo +siccome +sierra +sigla +signore +silenzio +sillaba +simbolo +simpatico +simulato +sinfonia +singolo +sinistro +sino +sintesi +sinusoide +sipario +sisma +sistole +situato +slitta +slogatura +sloveno +smarrito +smemorato +smentito +smeraldo +smilzo +smontare +smottato +smussato +snellire +snervato +snodo +sobbalzo +sobrio +soccorso +sociale +sodale +soffitto +sogno +soldato +solenne +solido +sollazzo +solo +solubile +solvente +somatico +somma +sonda +sonetto +sonnifero +sopire +soppeso +sopra +sorgere +sorpasso +sorriso +sorso +sorteggio +sorvolato +sospiro +sosta +sottile +spada +spalla +spargere +spatola +spavento +spazzola +specie +spedire +spegnere +spelatura +speranza +spessore +spettrale +spezzato +spia +spigoloso +spillato +spinoso +spirale +splendido +sportivo +sposo +spranga +sprecare +spronato +spruzzo +spuntino +squillo +sradicare +srotolato +stabile +stacco +staffa +stagnare +stampato +stantio +starnuto +stasera +statuto +stelo +steppa +sterzo +stiletto +stima +stirpe +stivale +stizzoso +stonato +storico +strappo +stregato +stridulo +strozzare +strutto +stuccare +stufo +stupendo +subentro +succoso +sudore +suggerito +sugo +sultano +suonare +superbo +supporto +surgelato +surrogato +sussurro +sutura +svagare +svedese +sveglio +svelare +svenuto +svezia +sviluppo +svista +svizzera +svolta +svuotare +tabacco +tabulato +tacciare +taciturno +tale +talismano +tampone +tannino +tara +tardivo +targato +tariffa +tarpare +tartaruga +tasto +tattico +taverna +tavolata +tazza +teca +tecnico +telefono +temerario +tempo +temuto +tendone +tenero +tensione +tentacolo +teorema +terme +terrazzo +terzetto +tesi +tesserato +testato +tetro +tettoia +tifare +tigella +timbro +tinto +tipico +tipografo +tiraggio +tiro +titanio +titolo +titubante +tizio +tizzone +toccare +tollerare +tolto +tombola +tomo +tonfo +tonsilla +topazio +topologia +toppa +torba +tornare +torrone +tortora +toscano +tossire +tostatura +totano +trabocco +trachea +trafila +tragedia +tralcio +tramonto +transito +trapano +trarre +trasloco +trattato +trave +treccia +tremolio +trespolo +tributo +tricheco +trifoglio +trillo +trincea +trio +tristezza +triturato +trivella +tromba +trono +troppo +trottola +trovare +truccato +tubatura +tuffato +tulipano +tumulto +tunisia +turbare +turchino +tuta +tutela +ubicato +uccello +uccisore +udire +uditivo +uffa +ufficio +uguale +ulisse +ultimato +umano +umile +umorismo +uncinetto +ungere +ungherese +unicorno +unificato +unisono +unitario +unte +uovo +upupa +uragano +urgenza +urlo +usanza +usato +uscito +usignolo +usuraio +utensile +utilizzo +utopia +vacante +vaccinato +vagabondo +vagliato +valanga +valgo +valico +valletta +valoroso +valutare +valvola +vampata +vangare +vanitoso +vano +vantaggio +vanvera +vapore +varano +varcato +variante +vasca +vedetta +vedova +veduto +vegetale +veicolo +velcro +velina +velluto +veloce +venato +vendemmia +vento +verace +verbale +vergogna +verifica +vero +verruca +verticale +vescica +vessillo +vestale +veterano +vetrina +vetusto +viandante +vibrante +vicenda +vichingo +vicinanza +vidimare +vigilia +vigneto +vigore +vile +villano +vimini +vincitore +viola +vipera +virgola +virologo +virulento +viscoso +visione +vispo +vissuto +visura +vita +vitello +vittima +vivanda +vivido +viziare +voce +voga +volatile +volere +volpe +voragine +vulcano +zampogna +zanna +zappato +zattera +zavorra +zefiro +zelante +zelo +zenzero +zerbino +zibetto +zinco +zircone +zitto +zolla +zotico +zucchero +zufolo +zulu +zuppa diff --git a/bip-0043.mediawiki b/bip-0043.mediawiki index 8f20fc8..4c57935 100644 --- a/bip-0043.mediawiki +++ b/bip-0043.mediawiki @@ -1,10 +1,10 @@ <pre> - BIP: BIP-0043 - Title: Purpose Field for Deterministic Wallets - Authors: Marek Palatinus <slush@satoshilabs.com> - Pavol Rusnak <stick@satoshilabs.com> - Status: Draft - Type: Standards Track + BIP: 43 + Title: Purpose Field for Deterministic Wallets + Author: Marek Palatinus <slush@satoshilabs.com> + Pavol Rusnak <stick@satoshilabs.com> + Status: Draft + Type: Standards Track Created: 2014-04-24 </pre> diff --git a/bip-0044.mediawiki b/bip-0044.mediawiki index 847eb9e..883677a 100644 --- a/bip-0044.mediawiki +++ b/bip-0044.mediawiki @@ -1,10 +1,10 @@ <pre> - BIP: BIP-0044 - Title: Multi-Account Hierarchy for Deterministic Wallets - Authors: Marek Palatinus <slush@satoshilabs.com> - Pavol Rusnak <stick@satoshilabs.com> - Status: Draft - Type: Standards Track + BIP: 44 + Title: Multi-Account Hierarchy for Deterministic Wallets + Author: Marek Palatinus <slush@satoshilabs.com> + Pavol Rusnak <stick@satoshilabs.com> + Status: Draft + Type: Standards Track Created: 2014-04-24 </pre> @@ -149,10 +149,10 @@ All these constants are used as hardened derivation. This BIP is not a central directory for the registered coin types, please visit SatoshiLabs that maintains the full list: -[[http://doc.satoshilabs.com/slips/slip-0044.html|SLIP-0044 : Registered coin types for BIP-0044]] +[[https://github.com/satoshilabs/slips/blob/master/slip-0044.md|SLIP-0044 : Registered coin types for BIP-0044]] To register a new coin type, an existing wallet that implements the standard -is required. This can be done [[https://github.com/satoshilabs/docs/blob/master/slips/slip-0044.rst|here]]. +is required and a pull request to the above file should be created. ==Examples== @@ -265,8 +265,9 @@ is required. This can be done [[https://github.com/satoshilabs/docs/blob/master/ * [[https://mytrezor.com|myTREZOR web wallet]] ([[https://github.com/trezor/webwallet|source]]) * [[https://play.google.com/store/apps/details?id=com.bonsai.wallet32|Wallet32 @ Android]] ([[https://github.com/ksedgwic/Wallet32|source]]) * [[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]] ==Reference== * [[bip-0032.mediawiki|BIP32 - Hierarchical Deterministic Wallets]] diff --git a/bip-0045.mediawiki b/bip-0045.mediawiki index f93319d..1550467 100644 --- a/bip-0045.mediawiki +++ b/bip-0045.mediawiki @@ -1,11 +1,11 @@ <pre> - BIP: BIP-0045 - Title: Structure for Deterministic P2SH Multisignature Wallets - Authors: Manuel Araoz <manu@bitpay.com> - Ryan X. Charles <ryan@bitpay.com> - Matias Alejo Garcia <matias@bitpay.com> - Status: Draft - Type: Standards Track + BIP: 45 + Title: Structure for Deterministic P2SH Multisignature Wallets + Author: Manuel Araoz <manu@bitpay.com> + Ryan X. Charles <ryan@bitpay.com> + Matias Alejo Garcia <matias@bitpay.com> + Status: Draft + Type: Standards Track Created: 2014-04-25 </pre> diff --git a/bip-0047.mediawiki b/bip-0047.mediawiki index 8247e00..bdac681 100644 --- a/bip-0047.mediawiki +++ b/bip-0047.mediawiki @@ -1,15 +1,14 @@ RECENT CHANGES: - +* (18 Dec 2015) Update explanations to resolve FAQs +* (12 Oct 2015) Revise blinding method for notification transactions * (21 Sep 2015) Correct base58check version byte -* (18 Sep 2015) Clarify decoding of notification transactions - <pre> - BIP: 47 - Title: Reusable Payment Codes for Hierarchical Deterministic Wallets - Authors: Justus Ranvier <justus@openbitcoinprivacyproject.org> - Status: Draft - Type: Informational + BIP: 47 + Title: Reusable Payment Codes for Hierarchical Deterministic Wallets + Author: Justus Ranvier <justus@openbitcoinprivacyproject.org> + Status: Draft + Type: Informational Created: 2015-04-24 </pre> @@ -29,9 +28,29 @@ Payment codes add identity information to transactions which is useful in a merc We define the following 3 levels in BIP32 path: -<pre> +<code> m / purpose' / coin_type' / identity' -</pre> +</code> + +The child keys derived from an identity are used in different ways: + +<code> +m / purpose' / coin_type' / identity' / 0 +</code> + +The 0th (non-hardened) child is the notification key. + +<code> +m / purpose' / coin_type' / identity' / 0 through 2147483647 +</code> + +These (non-hardened) keypairs are used for ECDH to generate deposit addresses. + +<code> +m / purpose' / coin_type' / identity' / 0' through 2147483647' +</code> + +These (hardened) keypairs are ephemeral payment codes. Apostrophe in the path indicates that BIP32 hardened derivation is used. @@ -49,19 +68,31 @@ Hardened derivation is used at this level. ===Identity=== -Identity is a particular extended public/private key pair. The extended public key is a payment code. +The identity derivation level produces an extended public key and its associated extended private key. + +When the extended public key at this level is combined with the metadata specified in the Representation section below, the resulting entity is called a "payment code." -Identities SHOULD have 1:1 correspondence with a BIP44 account, as in each BIP44 account in an HD wallet should be assigned exactly one payment code which shares the same index value. +This derivation level is equivalent to the Account level in BIP-44. Wallets SHOULD treat payment codes as intrinsically part of the BIP-44 account at the same index and create payment codes and accounts as pairs. + +For example, the payment code created represented by (m / 47' / 0' / 0') is part of the account represented by (m / 44' / 0' / 0'). + +The second account in a wallet consists of the new account/payment code pair created by using an index of 1 in as the account/identity level of both paths. + +Incoming payments received via this specification are equivalent to payments received to BIP-44 addresses, and unspent outputs from both types of addresses can be used as inputs in the same outgoing transaction. Hardened derivation is used at this level. Except where noted, all keys derived from a payment code use the public derivation method. +==Standard Payment Codes (v1)== + +===Representation=== + ====Binary Serialization==== A payment code contains the following elements: -* Byte 0: type. required value: 0x01 +* Byte 0: version. required value: 0x01 * Byte 1: features bit field. All bits must be zero except where specified elsewhere in this specification ** Bit 0: Bitmessage notification ** Bits 1-7: reserved @@ -85,7 +116,7 @@ It is assumed that Alice can easily obtain Bob's payment code via a suitable met ====Definitions==== -* Payment code: an extended public key which is associated with a particular identity +* Payment code: an extended public key and associated metadata which is associated with a particular identity/account * Notification address: the P2PKH address associated with the 0<sup>th</sup> public key derived from a payment code * Notification transaction: a transaction which sends an output to a notification address which includes an embedded payment code @@ -135,6 +166,17 @@ Bitcoins received via notification transactions require special handling in orde # Outputs received to notification addresses MAY be passed through a mixing service before being added to the user's spendable balance. # Outputs received to notification addresses MAY be donated to miners using dust-b-gone or an equivalent procedure. +=====Standard Notification Transaction Scripts===== + +Alice SHOULD use an input script in one of the following standard forms to expose a public key, and compliant applications SHOULD recognize all of these forms. + +* P2PK (pay to pubkey) +* P2PKH (pay to pubkey hash) +* Multisig (bare multisig, without P2SH) +* a script which spends any of the above script forms via P2SH (pay to script hash) + +Compatible wallets MAY provide a method for a user to manually specify the public key associated with a notification transaction in order to recover payment codes sent via non-standard notification transactions. + ====Sending==== # Each time Alice wants to initiate a transaction to Bob, Alice derives a unique P2PKH address for the transaction using ECDH follows: @@ -175,7 +217,7 @@ If Alice does not want her payment to Bob to be associated with her identity, sh ====Cold Storage==== -* Unlike traditional watching-only wallets, those associated with payment codes help in cold storage can not detect incoming payments immediately. +* Unlike traditional watching-only wallets, those associated with payment codes held in cold storage can not detect incoming payments immediately. * When the watching-only wallet detects an incoming notification transaction, it packages the transaction in an implementation-specific format suitable for transfer to the offline device. * The offline device recovers the payment code, then pre-generates a large number of relevant keypairs (example: 10000) in order to minimize the need for air gap round trips. * The offline device then packages the relevant public keys in an implementation-specific format suitable for transfer to the online device. @@ -194,7 +236,9 @@ When querying a public blockchain explorer, wallets SHOULD connect to the explor Previously-spendable funds will generally not be lost or become inaccessible after a recovery from a seed, but all information regarding previous outgoing payments will be lost. -The metadata which a wallet must store regarding the state an identity consists of: +In order to recover received funds from a seed, the wallet must obtain every notification it has ever received to its notification address, including all spent transactions. It then re-establishes its lookahead window for each subchain by scanning every derived address sequentially until it locates a contiguous block of unused addresses of a user-specified length. + +The metadata which a wallet must store to properly process outgoing transactions consists of: # A list of every payment code to which the identity has sent a notification transaction. ## This list is lost if a wallet must be recovered from a seed. @@ -233,7 +277,7 @@ A recipient prefers to receive notifications via Bitmessage indiates this prefer * Setting bit 0 of the features byte to 1 * Setting byte 67 of the serialized payment code to the desired Bitmessage address version -* Setting byte 67 of the serialized payment code to the desired Bitmessage stream number +* Setting byte 68 of the serialized payment code to the desired Bitmessage stream number The sender uses this information to construct a valid notification Bitmessage address: @@ -247,6 +291,10 @@ The sender transmits their payment code in base58 form to the calculated Bitmess In order to use Bitmessage notification, the recipient must have a Bitmessage client which listens at the address which the senders will derive and is capable of relaying received payment codes to the Bitcoin wallet. +==Test Vectors== + +* [[https://gist.github.com/SamouraiDev/6aad669604c5930864bd|BIP47 Reusable Payment Codes Test Vectors]] + ==Reference== * [[bip-0032.mediawiki|BIP32 - Hierarchical Deterministic Wallets]] diff --git a/bip-0050.mediawiki b/bip-0050.mediawiki index 9ff29d6..4f48fca 100644 --- a/bip-0050.mediawiki +++ b/bip-0050.mediawiki @@ -2,33 +2,35 @@ BIP: 50 Title: March 2013 Chain Fork Post-Mortem Author: Gavin Andresen <gavinandresen@gmail.com> - Status: Draft + Status: Final Type: Informational Created: 2013-03-20 </pre> ==What went wrong== -A block that had a larger number of total transaction inputs than previously seen was mined and broadcasted. Bitcoin 0.8 nodes were able to handle this, but some pre-0.8 Bitcoin nodes rejected it, causing an unexpected hard fork of the chain. The pre-0.8 incompatible chain at that point had around 60% of the hash power ensuring the split did not automatically resolve. +A block that had a larger number of total transaction inputs than previously seen was mined and broadcasted. Bitcoin 0.8 nodes were able to handle this, but some pre-0.8 Bitcoin nodes rejected it, causing an unexpected fork of the blockchain. The pre-0.8-incompatible chain (from here on, the 0.8 chain) at that point had around 60% of the mining hash power ensuring the split did not automatically resolve (as would have occurred if the pre-0.8 chain outpaced the 0.8 chain in total work, forcing 0.8 nodes to reorganise to the pre-0.8 chain). -In order to restore a canonical chain as soon as possible, BTCGuild and Slush downgraded their Bitcoin 0.8 nodes to 0.7 so their pools would also reject the larger block. This placed majority hashpower on the chain without the larger block. +In order to restore a canonical chain as soon as possible, BTCGuild and Slush downgraded their Bitcoin 0.8 nodes to 0.7 so their pools would also reject the larger block. This placed majority hashpower on the chain without the larger block, thus eventually causing the 0.8 nodes to reorganise to the pre-0.8 chain. During this time there was at least [https://bitcointalk.org/index.php?topic=152348.0 one large double spend]. However, it was done by someone experimenting to see if it was possible and was not intended to be malicious. ==What went right== * The split was detected very quickly. -* The right people were online and available in IRC or could be raised via Skype. -* Marek Palatinus and Michael Marsee quickly downgraded their nodes to restore a pre-0.8 chain as canonical, despite the fact that this caused them to sacrifice significant amounts of money and they were the ones running the bug-free version. +* The right people were online and available in IRC or could be contacted directly. +* Marek Palatinus (Slush) and Michael Marsee (Eleuthria of BTCGuild) quickly downgraded their nodes to restore a pre-0.8 chain as canonical, despite the fact that this caused them to sacrifice significant amounts of money. * Deposits to the major exchanges and payments via BitPay were also suspended (and then un-suspended) very quickly. -* Fortunately, the only attack on a merchant was done by someone who was not intending to actually steal money +* Fortunately, the only attack on a merchant was done by someone who was not intending to actually steal money. ==Root cause== -Bitcoin versions prior to 0.8 configure an insufficient number of Berkeley DB locks to process large but technically valid blocks. Berkeley DB locks have to be manually configured by API users depending on anticipated load. The manual says this: +Bitcoin versions prior to 0.8 configure an insufficient number of Berkeley DB locks to process large but otherwise valid blocks. Berkeley DB locks have to be manually configured by API users depending on anticipated load. The manual says this: :The recommended algorithm for selecting the maximum number of locks, lockers, and lock objects is to run the application under stressful conditions and then review the lock system's statistics to determine the maximum number of locks, lockers, and lock objects that were used. Then, double these values for safety. +With the insufficiently high BDB lock configuration, it implicitly had become a network consensus rule determining block validity (albeit an inconsistent and unsafe rule, since the lock usage could vary from node to node). + Because max-sized blocks had been successfully processed on the testnet, it did not occur to anyone that there could be blocks that were smaller but require more locks than were available. Prior to 0.7 unmodified mining nodes self-imposed a maximum block size of 500,000 bytes, which further prevented this case from being triggered. 0.7 made the target size configurable and miners had been encouraged to increase this target in the week prior to the incident. -Bitcoin 0.8 does not use Berkeley DB. It uses LevelDB instead, which does not require this kind of pre-configuration. Therefore it was able to process the forking block successfully. +Bitcoin 0.8 did not use Berkeley DB. It switched to LevelDB instead, which did not implement the same locking limits as BDB. Therefore it was able to process the forking block successfully. Note that BDB locks are also required during processing of re-organizations. Versions prior to 0.8 may be unable to process some valid re-orgs. @@ -39,10 +41,10 @@ This would be an issue even if the entire network was running version 0.7.2. It ===Immediately=== '''Done''': Release a version 0.8.1, forked directly from 0.8.0, that, for the next two months has the following new rules: -# Reject blocks that could cause more than 10,000 locks to be taken. +# Reject blocks that would probably could cause more than 10,000 locks to be taken. # Limit the maximum block-size created to 500,000 bytes -# Release a patch for older versions that implements the same rules, but also increases the maximum number of locks to 120,000 -# Create a web page on bitcoin.org that will urge users to upgrade to 0.8.1, but will tell them how to set DB_CONFIG to 120,000 locks if they absolutely cannot. +# Release a patch for older versions that implements the same rules, but also increases the maximum number of locks to 537,000 +# Create a web page on bitcoin.org that will urge users to upgrade to 0.8.1, but will tell them how to set DB_CONFIG to 537,000 locks if they absolutely cannot. # Over the next 2 months, send a series of alerts to users of older versions, pointing to the web page. ===Alert system=== @@ -70,3 +72,7 @@ A double spend attack was successful, despite that both sides of the chain heard ===Resolution=== On 16 August, 2013 block 252,451 (0x0000000000000024b58eeb1134432f00497a6a860412996e7a260f47126eed07) was accepted by the main network, forking unpatched nodes off the network. + +==Copyright== + +This document is placed in the public domain. diff --git a/bip-0065.mediawiki b/bip-0065.mediawiki index b48fa75..99298bf 100644 --- a/bip-0065.mediawiki +++ b/bip-0065.mediawiki @@ -2,7 +2,7 @@ BIP: 65 Title: OP_CHECKLOCKTIMEVERIFY Author: Peter Todd <pete@petertodd.org> - Status: Draft + Status: Final Type: Standards Track Created: 2014-10-01 </pre> @@ -16,11 +16,17 @@ some point in the future. ==Summary== -CHECKLOCKTIMEVERIFY redefines the existing NOP2 opcode. When executed it -compares the top item on the stack to the nLockTime field of the transaction -containing the scriptSig. If that top stack item is greater than the transaction's -nLockTime field the script fails immediately, otherwise script evaluation continues -as though a NOP was executed. +CHECKLOCKTIMEVERIFY redefines the existing NOP2 opcode. When executed, if +any of the following conditions are true, the script interpreter will terminate +with an error: + +* the stack is empty; or +* the top item on the stack is less than 0; or +* the lock-time type (height vs. timestamp) of the top stack item and the nLockTime field are not the same; or +* the top stack item is greater than the transaction's nLockTime field; or +* the nSequence field of the txin is 0xffffffff; + +Otherwise, script execution will continue as if a NOP had been executed. The nLockTime field in a transaction prevents the transaction from being mined until either a certain block height, or block time, has been reached. By @@ -92,7 +98,7 @@ making transaction malleability a non-issue. ====Two-factor wallets==== -Services like GreenAddress store Bitcoins with 2-of-2 multisig scriptPubKey's +Services like GreenAddress store bitcoins with 2-of-2 multisig scriptPubKey's such that one keypair is controlled by the user, and the other keypair is controlled by the service. To spend funds the user uses locally installed wallet software that generates one of the required signatures, and then uses a @@ -195,6 +201,7 @@ transaction output ''can'' be spent. Refer to the reference implementation, reproduced below, for the precise semantics and detailed rationale for those semantics. + case OP_NOP2: { // CHECKLOCKTIMEVERIFY @@ -270,7 +277,7 @@ https://github.com/petertodd/bitcoin/commit/ab0f54f38e08ee1e50ff72f801680ee84d0f ==Deployment== We reuse the double-threshold IsSuperMajority() switchover mechanism used in -BIP 66 with the same thresholds, but for nVersion = 4. The new rules are +BIP66 with the same thresholds, but for nVersion = 4. The new rules are in effect for every block (at height H) with nVersion = 4 and at least 750 out of 1000 blocks preceding it (with heights H-1000..H-1) also have nVersion >= 4. Furthermore, when 950 out of the 1000 blocks diff --git a/bip-0067.mediawiki b/bip-0067.mediawiki index 8be5c9b..3864c63 100644 --- a/bip-0067.mediawiki +++ b/bip-0067.mediawiki @@ -1,8 +1,9 @@ - <pre> BIP: 67 Title: Deterministic Pay-to-script-hash multi-signature addresses through public key sorting - Author: Thomas Kerin, Jean-Pierre Rupp, Ruben de Vries + Author: Thomas Kerin <me@thomaskerin.io> + Jean-Pierre Rupp <root@haskoin.com> + Ruben de Vries <ruben@rubensayshi.com> Status: Draft Type: Standards Track Created: 2015-02-08 diff --git a/bip-0068.mediawiki b/bip-0068.mediawiki index 12b97c7..8c566b0 100644 --- a/bip-0068.mediawiki +++ b/bip-0068.mediawiki @@ -1,7 +1,10 @@ <pre> BIP: 68 - Title: Consensus-enforced transaction replacement signaled via sequence numbers (relative lock-time) + Title: Relative lock-time using consensus-enforced sequence numbers Author: Mark Friedenbach <mark@friedenbach.org> + BtcDrak <btcdrak@gmail.com> + Nicolas Dorier <nicolas.dorier@gmail.com> + kinoshitajona <kinoshitajona@gmail.com> Status: Draft Type: Standards Track Created: 2015-05-28 @@ -9,246 +12,243 @@ ==Abstract== -This BIP describes a modification to the consensus-enforced semantics of the sequence number field to enable a signed transaction input to remain invalid for a defined period of time after confirmation of its corresponding outpoint, for the purpose of supporting consensus-enforced transaction replacement features. +This BIP introduces relative lock-time (RLT) consensus-enforced semantics of the sequence number field to enable a signed transaction input to remain invalid for a defined period of time after confirmation of its corresponding outpoint. ==Motivation== -Bitcoin has sequence number fields for each input of a transaction. The original idea appears to have been that the highest sequence number should dominate and miners should prefer it over lower sequence numbers. This was never really implemented, and the half-implemented code seemed to be making an assumption that miners would honestly prefer the higher sequence numbers, even if the lower ones were much much more profitable. That turns out to be a dangerous assumption, and so most technical people have assumed that kind of sequence number mediated replacement was useless because there was no way to enforce "honest" behavior, as even a few rational (profit maximizing) miners would break that completely. The change described by this BIP provides the missing piece that makes sequence numbers do something significant with respect to enforcing transaction replacement without assuming anything other than profit-maximizing behavior on the part of miners. +Bitcoin transactions have a sequence number field for each input. The original idea appears to have been that a transaction in the mempool would be replaced by using the same input with a higher sequence value. Although this was not properly implemented, it assumes miners would prefer higher sequence numbers even if the lower ones were more profitable to mine. However, a miner acting on profit motives alone would break that assumption completely. The change described by this BIP repurposes the sequence number for new use cases without breaking existing functionality. It also leaves room for future expansion and other use cases. + +The transaction nLockTime is used to prevent the mining of a transaction until a certain date. nSequence will be repurposed to prevent mining of a transaction until a certain age of the spent output in blocks or timespan. This, among other uses, allows bi-directional payment channels as used in [https://github.com/ElementsProject/lightning/raw/master/doc/deployable-lightning.pdf Hashed Timelock Contracts (HTLCs)] and [https://github.com/bitcoin/bips/blob/master/bip-0112.mediawiki#Bidirectional_Payment_Channels BIP112]. ==Specification== -For transactions with an nVersion of 2 or greater, if the most significant bit (1 << 31) of a sequence number is clear, the remaining 31 bits are interpreted as an encoded relative lock-time. A sequence number with the most significant bit set is given no consensus meaning and can be included in any block, like normal, under all circumstances. +This specification defines the meaning of sequence numbers for transactions with an nVersion greater than or equal to 2 for which the rest of this specification relies on. -If the second most significant bit (1 << 30) is clear, the next 16 bits are interpreted as a minimum block-height constraint over the input's age. The remaining 14 bits have no consensus-enforced meaning. A sequence number of zero indicates a relative lock-time of zero blocks (bits 31 and 30 clear) and can be included in any block. A sequence number of 1 << 14 can be included in the next block after the input it is spending, or any block thereafter, but cannot be included in the same block as its parent. A sequence number of 2 << 14 can't be included until at least two blocks later, and so on. +All references to median-time-past (MTP) are as defined by BIP113. -Alternatively, if the second most significant bit (1 << 30) is set, the next 25 bits are interpreted as a minimum block-time constraint over the input's age. The remaining 5 bits have no consensus-enforced meaning. A sequence number with just that second most significant bit set (0x40000000) is interpreted as a relative lock-time of 0, measured in seconds, and can be included in the same block as the output being spent. Advancing that sequence number by 2^5 (0x40000020) constrains the transaction to be included in blocks with an nTime timestamp at least one second greater than the median time stamp of the 11 blocks prior to the block containing the coin being spent. Advancing the sequence number by an additional 2^5 (0x40000040) constrains the spend to be two seconds later, and so on. +If bit (1 << 31) of the sequence number is set, then no consensus meaning is applied to the sequence number and can be included in any block under all currently possible circumstances. -This is proposed to be accomplished by replacing IsFinalTx() and CheckFinalTx(), existing consensus and non-consensus code functions that return true if a transaction's lock-time constraints are satisfied and false otherwise, with LockTime() and CheckLockTime(), new functions that return a non-zero value if a transaction's lock-time or sequence number constraints are not satisfied and zero otherwise: +If bit (1 << 31) of the sequence number is not set, then the sequence number is interpreted as an encoded relative lock-time. -<pre> - enum { - /* Interpret sequence numbers as relative lock-time constraints. */ - LOCKTIME_VERIFY_SEQUENCE = (1 << 0), - }; - - /* Setting nSequence to this value for every input in a transaction - * disables nLockTime. */ - const uint32_t CTxIn::SEQUENCE_FINAL = 0xffffffff; - /* Threshold for CTxIn::nSequence: below this value it is interpreted - * as arelative lock-time, otherwise ignored. */ - const uint32_t CTxIn::SEQUENCE_LOCKTIME_THRESHOLD = (1 << 31); - /* Threshold for CTxIn::nSequence when interpreted as a relative - * lock-time: below this value it has units of blocks, otherwise - * seconds. */ - const uint32_t CTxIn::SEQUENCE_UNITS_THRESHOLD = (1 << 30); - /* Number of reserved low-order bits (depending on units used) which - * are shifted out prior to relative lock-time constraint checking. */ - const int CTxIn::SEQUENCE_BLOCKS_OFFSET = 14; - const int CTxIn::SEQUENCE_SECONDS_OFFSET = 5; - - int64_t LockTime(const CTransaction &tx, - int flags, const CCoinsView* pCoinsView, - int nBlockHeight, int64_t nBlockTime) - { - CCoins coins; - - bool fEnforceBIP68 = static_cast<uint32_t>(tx.nVersion) >= 2 - && flags & LOCKTIME_VERIFY_SEQUENCE; - - // Will be set to the equivalent height- and time-based nLockTime - // values that would be necessary to satisfy all relative lock- - // time constraints given our view of block chain history. - int nMinHeight = 0; - int64_t nMinTime = 0; - // Will remain equal to true if all inputs are finalized - // (CTxIn::SEQUENCE_FINAL). - bool fFinalized = true; - - BOOST_FOREACH(const CTxIn& txin, tx.vin) { - // Set a flag if we witness an input that isn't finalized. - if (CTxIn::SEQUENCE_FINAL == txin.nSequence) - continue; - else - fFinalized = false; - - // Do not enforce sequence numbers as a relative lock time - // unless we have been instructed to, and a view has been - // provided. - if (!(fEnforceBIP68 && pCoinsView)) - continue; - - // Sequence numbers equal to or above the locktime threshold - // are not treated as relative lock-times, nor are they given - // any consensus-enforced meaning at this point. - if (txin.nSequence >= CTxIn::SEQUENCE_LOCKTIME_THRESHOLD) - continue; - - // Fetch the UTXO corresponding to this input. - if (!pCoinsView->GetCoins(txin.prevout.hash, coins)) { - // It is fully expected that coinbases inputs are not - // found in the UTXO set. Proceed to the next intput... - if (txin.prevout.IsNull()) - continue; - // If a non-coinbase input cannot be found, we cannot - // be certain about whether lock-time constraints have - // been satisfied. Note that it should only ever be - // possible for this to happen with wallet transactions - // that have unknown inputs. - else - return std::numeric_limits<int64_t>::max(); - } - - // coins.nHeight is MEMPOOL_HEIGHT (an absurdly high value) - // if the parent transaction was from the mempool. We can't - // know what height it will have once confirmed, but we - // assume it makes it in the same block. - int nCoinHeight = std::min(coins.nHeight, nBlockHeight); - - if (txin.nSequence < CTxIn::SEQUENCE_UNITS_THRESHOLD) { - // We subtract 1 from relative lock-times because a lock- - // time of 0 has the semantics of "same block," so a lock- - // time of 1 should mean "next block," but nLockTime has - // the semantics of "last invalid block height." - nMinHeight = std::max(nMinHeight, nCoinHeight + (int)( - txin.nSequence >> CTxIn::SEQUENCE_BLOCKS_OFFSET) - 1); - } else { - // In two locations that follow we make reference to - // chainActive.Tip(). To prevent a race condition, we - // store a reference to the current tip. - // - // Note that it is not guaranteed that indexBestBlock will - // be consistent with the passed in view. The proper thing - // to do is to have the view return time information about - // UTXOs. - const CBlockIndex& indexBestBlock = *chainActive.Tip(); - - // The only time the negative branch of this conditional - // is executed is when the prior output was taken from the - // mempool, in which case we assume it makes it into the - // same block (see above). - int64_t nCoinTime = (nCoinHeight <= (indexBestBlock.nHeight+1)) - ? indexBestBlock.GetAncestor(nCoinHeight-1)->GetMedianTimePast() - : nBlockTime; - - // Time-based relative lock-times are measured from the - // smallest allowed timestamp of the block containing the - // txout being spent, which is the median time past of the - // block prior. We subtract one for the same reason as - // above. - nMinTime = std::max(nMinTime, nCoinTime + (int64_t)(( - txin.nSequence - CTxIn::SEQUENCE_UNITS_THRESHOLD) - >> CTxIn::SEQUENCE_SECONDS_OFFSET) - 1); - } - } - - // If all sequence numbers are CTxIn::SEQUENCE_FINAL, the - // transaction is considered final and nLockTime constraints - // are not enforced. - if (fFinalized) - return 0; - - if ((int64_t)tx.nLockTime < LOCKTIME_THRESHOLD) - nMinHeight = std::max(nMinHeight, (int)tx.nLockTime); - else - nMinTime = std::max(nMinTime, (int64_t)tx.nLockTime); - - if (nMinHeight >= nBlockHeight) - return nMinHeight; - if (nMinTime >= nBlockTime) - return nMinTime; - - return 0; - } - - int64_t CheckLockTime(const CTransaction &tx, int flags) - { - AssertLockHeld(cs_main); - - // By convention a negative value for flags indicates that the - // current network-enforced consensus rules should be used. - flags = std::max(flags, 0); - - // pcoinsTip contains the UTXO set for chainActive.Tip() - CCoinsViewMemPool viewMemPool(pcoinsTip, mempool); - const CCoinsView *pCoinsView = &viewMemPool; - - // CheckLockTime() uses chainActive.Height()+1 to evaluate - // nLockTime because when LockTime() is called within - // CBlock::AcceptBlock(), the height of the block *being* - // evaluated is what is used. Thus if we want to know if a - // transaction can be part of the *next* block, we need to call - // LockTime() with one more than chainActive.Height(). - const int nBlockHeight = chainActive.Height() + 1; - - // Timestamps on the other hand don't get any special treatment, - // because we can't know what timestamp the next block will have, - // and there aren't timestamp applications where it matters. - const int64_t nBlockTime = GetAdjustedTime(); - - return LockTime(tx, flags, pCoinsView, nBlockHeight, nBlockTime); - } -</pre> +The sequence number encoding is interpreted as follows: -Code conditional on the return value of IsFinalTx() / CheckLockTime() has to be updated as well, since the semantics of the return value has been inverted. +Bit (1 << 22) determines if the relative lock-time is time-based or block based: If the bit is set, the relative lock-time specifies a timespan in units of 512 seconds granularity. The timespan starts from the median-time-past of the output’s previous block, and ends at the MTP of the previous block. If the bit is not set, the relative lock-time specifies a number of blocks. -==Rationale== +The flag (1<<22) is the highest order bit in a 3-byte signed integer for use in bitcoin scripts as a 3-byte PUSHDATA with OP_CHECKSEQUENCEVERIFY (BIP 112). -Using sequence numbers for locking inputs makes sense, since no transaction can be in a block before its parent transactions. This means that a lower sequence number can always be included earlier than a higher one (even if the time the original coins being spent was unknown when the transaction was authored). Because of this, even rational miners should go along with the scheme: Take the lowest sequence number and collect the fees, or skip over it in the hopes that no one else takes a lower number before the next available higher number becomes spendable. And, of course, users are not constrained to make their sequence numbers go up only one at a time. So it's "take the most updated version, now, or gamble that no one in the next dozen blocks takes the most updated and that you manage to include the next to most when it finally becomes mineable." This is similar to how lock-time works. In fact, this scheme is precisely a per-input relative lock-time. +This specification only interprets 16 bits of the sequence number as relative lock-time, so a mask of 0x0000ffff MUST be applied to the sequence field to extract the relative lock-time. The 16-bit specification allows for a year of relative lock-time and the remaining bits allow for future expansion. -==Example: Bidirectional payment channel== +<img src=bip-0068/encoding.png></img> -A bidirectional payment channel can be established by two parties funding a single output in the following way: Alice funds a 1btc output which is the 2-of-2 multisig of Alice AND Bob, or Alice's key only after a sufficiently long timeout, e.g. 30 days or 4320 blocks. The channel-generating transaction is signed by Alice and broadcast to the network. +For time based relative lock-time, 512 second granularity was chosen because bitcoin blocks are generated every 600 seconds. So when using block-based or time-based, the same amount of time can be encoded with the available number of bits. Converting from a sequence number to seconds is performed by multiplying by 512 = 2^9, or equivalently shifting up by 9 bits. -Alice desires to send Bob a payment of 0.1btc. She does so by constructing a transaction spending the 1btc output and sending 0.1btc to Bob and 0.9btc back to herself. She provides her signature for the 2-of-2 multisig constraint, and sets a relative lock-time using the sequence number field such that the transaction will become valid 24-hours or 144 blocks before the refund timeout. Two more times Alice sends Bob a payment of 0.1btc, each time generating and signing her half of a transaction spending the 1btc output and sending 0.2btc, then 0.3btc to Bob with a relative lock-time of 29 days from creation of the channel. +When the relative lock-time is time-based, it is interpreted as a minimum block-time constraint over the input's age. A relative time-based lock-time of zero indicates an input which can be included in any block. More generally, a relative time-based lock-time n can be included into any block produced 512 * n seconds after the mining date of the output it is spending, or any block thereafter. +The mining date of the output is equals to the median-time-past of the previous block which mined it. -Bob now desires to send Alice a refund of 0.25btc. He does so by constructing a transaction spending the 1btc output and sending 0.95btc (= 0.7btc + 0.25btc) to Alice and 0.05btc to himself. Since Bob will still have in his logs the transaction giving him 0.7btc 29 days after the creation of the channel, Alice demands that this new transaction have a relative lock-time of 28 days so she has a full day to broadcast it before the next transaction matures. +The block produced time is equal to the median-time-past of its previous block. -Alice and Bob continue to make payments to each other, decrementing the relative lock-time by one day each time the channel switches direction, until the present time is reached or either party desires to close out the channel. A close-out is performed by finalizing the input (nSequence = MAX_INT) and both parties signing. +When the relative lock-time is block-based, it is interpreted as a minimum block-height constraint over the input's age. A relative block-based lock-time of zero indicates an input which can be included in any block. More generally, a relative block lock-time n can be included n blocks after the mining date of the output it is spending, or any block thereafter. ==Implementation== A reference implementation is provided by the following pull request -https://github.com/bitcoin/bitcoin/pull/6312 +https://github.com/bitcoin/bitcoin/pull/7184 + +<pre> +enum { + /* Interpret sequence numbers as relative lock-time constraints. */ + LOCKTIME_VERIFY_SEQUENCE = (1 << 0), +}; + +/* Setting nSequence to this value for every input in a transaction + * disables nLockTime. */ +static const uint32_t SEQUENCE_FINAL = 0xffffffff; + +/* Below flags apply in the context of BIP 68*/ +/* If this flag set, CTxIn::nSequence is NOT interpreted as a + * relative lock-time. */ +static const uint32_t SEQUENCE_LOCKTIME_DISABLE_FLAG = (1 << 31); + +/* If CTxIn::nSequence encodes a relative lock-time and this flag + * is set, the relative lock-time has units of 512 seconds, + * otherwise it specifies blocks with a granularity of 1. */ +static const uint32_t SEQUENCE_LOCKTIME_TYPE_FLAG = (1 << 22); + +/* If CTxIn::nSequence encodes a relative lock-time, this mask is + * applied to extract that lock-time from the sequence field. */ +static const uint32_t SEQUENCE_LOCKTIME_MASK = 0x0000ffff; + +/* In order to use the same number of bits to encode roughly the + * same wall-clock duration, and because blocks are naturally + * limited to occur every 600s on average, the minimum granularity + * for time-based relative lock-time is fixed at 512 seconds. + * Converting from CTxIn::nSequence to seconds is performed by + * multiplying by 512 = 2^9, or equivalently shifting up by + * 9 bits. */ +static const int SEQUENCE_LOCKTIME_GRANULARITY = 9; + +/** + * Calculates the block height and previous block's median time past at + * which the transaction will be considered final in the context of BIP 68. + * Also removes from the vector of input heights any entries which did not + * correspond to sequence locked inputs as they do not affect the calculation. + */ +static std::pair<int, int64_t> CalculateSequenceLocks(const CTransaction &tx, int flags, std::vector<int>* prevHeights, const CBlockIndex& block) +{ + assert(prevHeights->size() == tx.vin.size()); + + // Will be set to the equivalent height- and time-based nLockTime + // values that would be necessary to satisfy all relative lock- + // time constraints given our view of block chain history. + // The semantics of nLockTime are the last invalid height/time, so + // use -1 to have the effect of any height or time being valid. + int nMinHeight = -1; + int64_t nMinTime = -1; + + // tx.nVersion is signed integer so requires cast to unsigned otherwise + // we would be doing a signed comparison and half the range of nVersion + // wouldn't support BIP 68. + bool fEnforceBIP68 = static_cast<uint32_t>(tx.nVersion) >= 2 + && flags & LOCKTIME_VERIFY_SEQUENCE; + + // Do not enforce sequence numbers as a relative lock time + // unless we have been instructed to + if (!fEnforceBIP68) { + return std::make_pair(nMinHeight, nMinTime); + } + + for (size_t txinIndex = 0; txinIndex < tx.vin.size(); txinIndex++) { + const CTxIn& txin = tx.vin[txinIndex]; + + // Sequence numbers with the most significant bit set are not + // treated as relative lock-times, nor are they given any + // consensus-enforced meaning at this point. + if (txin.nSequence & CTxIn::SEQUENCE_LOCKTIME_DISABLE_FLAG) { + // The height of this input is not relevant for sequence locks + (*prevHeights)[txinIndex] = 0; + continue; + } + + int nCoinHeight = (*prevHeights)[txinIndex]; + + if (txin.nSequence & CTxIn::SEQUENCE_LOCKTIME_TYPE_FLAG) { + int64_t nCoinTime = block.GetAncestor(std::max(nCoinHeight-1, 0))->GetMedianTimePast(); + // NOTE: Subtract 1 to maintain nLockTime semantics + // BIP 68 relative lock times have the semantics of calculating + // the first block or time at which the transaction would be + // valid. When calculating the effective block time or height + // for the entire transaction, we switch to using the + // semantics of nLockTime which is the last invalid block + // time or height. Thus we subtract 1 from the calculated + // time or height. + + // Time-based relative lock-times are measured from the + // smallest allowed timestamp of the block containing the + // txout being spent, which is the median time past of the + // block prior. + nMinTime = std::max(nMinTime, nCoinTime + (int64_t)((txin.nSequence & CTxIn::SEQUENCE_LOCKTIME_MASK) << CTxIn::SEQUENCE_LOCKTIME_GRANULARITY) - 1); + } else { + nMinHeight = std::max(nMinHeight, nCoinHeight + (int)(txin.nSequence & CTxIn::SEQUENCE_LOCKTIME_MASK) - 1); + } + } + + return std::make_pair(nMinHeight, nMinTime); +} + +static bool EvaluateSequenceLocks(const CBlockIndex& block, std::pair<int, int64_t> lockPair) +{ + assert(block.pprev); + int64_t nBlockTime = block.pprev->GetMedianTimePast(); + if (lockPair.first >= block.nHeight || lockPair.second >= nBlockTime) + return false; + + return true; +} + +bool SequenceLocks(const CTransaction &tx, int flags, std::vector<int>* prevHeights, const CBlockIndex& block) +{ + return EvaluateSequenceLocks(block, CalculateSequenceLocks(tx, flags, prevHeights, block)); +} + +bool CheckSequenceLocks(const CTransaction &tx, int flags) +{ + AssertLockHeld(cs_main); + AssertLockHeld(mempool.cs); + + CBlockIndex* tip = chainActive.Tip(); + CBlockIndex index; + index.pprev = tip; + // CheckSequenceLocks() uses chainActive.Height()+1 to evaluate + // height based locks because when SequenceLocks() is called within + // ConnectBlock(), the height of the block *being* + // evaluated is what is used. + // Thus if we want to know if a transaction can be part of the + // *next* block, we need to use one more than chainActive.Height() + index.nHeight = tip->nHeight + 1; + + // pcoinsTip contains the UTXO set for chainActive.Tip() + CCoinsViewMemPool viewMemPool(pcoinsTip, mempool); + std::vector<int> prevheights; + prevheights.resize(tx.vin.size()); + for (size_t txinIndex = 0; txinIndex < tx.vin.size(); txinIndex++) { + const CTxIn& txin = tx.vin[txinIndex]; + CCoins coins; + if (!viewMemPool.GetCoins(txin.prevout.hash, coins)) { + return error("%s: Missing input", __func__); + } + if (coins.nHeight == MEMPOOL_HEIGHT) { + // Assume all mempool transaction confirm in the next block + prevheights[txinIndex] = tip->nHeight + 1; + } else { + prevheights[txinIndex] = coins.nHeight; + } + } + + std::pair<int, int64_t> lockPair = CalculateSequenceLocks(tx, flags, &prevheights, index); + return EvaluateSequenceLocks(index, lockPair); +} +</pre> ==Acknowledgments== Credit goes to Gregory Maxwell for providing a succinct and clear description of the behavior of this change, which became the basis of this BIP text. +This BIP was edited by BtcDrak, Nicolas Dorier and kinoshitajona. + ==Deployment== -We reuse the double-threshold switch over mechanism from BIPs 34 and 66, with the same thresholds, but for nVersion = 4. The new rules are in effect for every block (at height H) with nVersion = 4 and at least 750 out of 1000 blocks preceding it (with heights H-1000..H-1) also have nVersion = 4. Furthermore, when 950 out of the 1000 blocks preceding a block do have nVersion = 4, nVersion = 3 blocks become invalid, and all further blocks enforce the new rules. +This BIP is to be deployed by either version-bits BIP9 or by isSuperMajority(). Exact details TDB. -It is recommended that this soft-fork deployment trigger include other related proposals for improving Bitcoin's lock-time capabilities, including [https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki BIP 65]: OP_CHECKLOCKTIMEVERIFY, [https://github.com/bitcoin/bips/blob/master/bip-0112.mediawiki BIP 112]: CHECKSEQUENCEVERIFY, and [https://github.com/bitcoin/bips/blob/master/bip-0113.mediawiki BIP 113] Median time-past as endpoint for lock-time calculations. +It is recommended to deploy BIP112 and BIP113 at the same time. ==Compatibility== The only use of sequence numbers by the Bitcoin Core reference client software is to disable checking the nLockTime constraints in a transaction. The semantics of that application are preserved by this BIP. -There may be other uses for the sequence number field that are not commonplace or yet to be discovered. To allow for other uses of the sequence number field, it is only interpreted as a relative lock-time as described in this BIP if the most significant bit is clear. This allows up to 31 bits of the sequence number field to be used for other purposes in applications which don't simultaneously need a per-input relative lock-time. In addition, the unused low-order bits of the relative lock-time encoding are available for use by future soft-fork extensions. +As can be seen from the specification section, a number of bits are undefined by this BIP to allow for other use cases by setting bit (1 << 31) as the remaining 31 bits have no meaning under this BIP. Additionally, bits (1 << 23) through (1 << 30) inclusive have no meaning at all when bit (1 << 31) is unset. + +Additionally, this BIP specifies only 16 bits to actually encode relative lock-time meaning a further 6 are unused (1 << 16 through 1 << 21 inclusive). This allows the possibility to increase granularity by soft-fork, or for increasing the maximum possible relative lock-time in the future. The most efficient way to calculate sequence number from relative lock-time is with bit masks and shifts: <pre> // 0 <= nHeight < 65,535 blocks (1.25 years) - nSequence = nHeight << 14; - nHeight = nSequence >> 14; + nSequence = nHeight; + nHeight = nSequence & 0x0000ffff; // 0 <= nTime < 33,554,431 seconds (1.06 years) - nSequence = 1<<30 | (nTime << 5); - nTime = (nSequence ^ 1<<30) >> 5; + nSequence = (1 << 22) | (nTime >> 9); + nTime = (nSequence & 0x0000ffff) << 9; </pre> ==References== Bitcoin mailing list discussion: https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg07864.html -[https://github.com/bitcoin/bips/blob/master/bip-0034.mediawiki BIP 34]: Block v2, Height in Coinbase - -[https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki BIP 65]: OP_CHECKLOCKTIMEVERIFY +BIP112: https://github.com/bitcoin/bips/blob/master/bip-0112.mediawiki -[https://github.com/bitcoin/bips/blob/master/bip-0066.mediawiki BIP 66]: Strict DER signatures +BIP113: https://github.com/bitcoin/bips/blob/master/bip-0113.mediawiki -[https://github.com/bitcoin/bips/blob/master/bip-0112.mediawiki BIP 112]: CHECKSEQUENCEVERIFY +Hashed Timelock Contracts (HTLCs): https://github.com/ElementsProject/lightning/raw/master/doc/deployable-lightning.pdf -[https://github.com/bitcoin/bips/blob/master/bip-0113.mediawiki BIP 113]: Median time-past as endpoint for lock-time calculations diff --git a/bip-0068/encoding.png b/bip-0068/encoding.png Binary files differnew file mode 100644 index 0000000..cd7649e --- /dev/null +++ b/bip-0068/encoding.png diff --git a/bip-0069.mediawiki b/bip-0069.mediawiki index e23ff04..4094126 100644 --- a/bip-0069.mediawiki +++ b/bip-0069.mediawiki @@ -1,10 +1,10 @@ <pre> - BIP: BIP: 69 - Title: Lexicographical Indexing of Transaction Inputs and Outputs - Authors: Kristov Atlas <kristov@openbitcoinprivacyproject.org> - Editors: Daniel Cousens <bips@dcousens.com> - Status: Draft - Type: Informational + BIP: 69 + Title: Lexicographical Indexing of Transaction Inputs and Outputs + Author: Kristov Atlas <kristov@openbitcoinprivacyproject.org> + Editor: Daniel Cousens <bips@dcousens.com> + Status: Draft + Type: Informational Created: 2015-06-12 </pre> @@ -162,6 +162,8 @@ Outputs: * [[https://github.com/bitcoinjs/bip69/blob/master/index.js|BitcoinJS]] * [[https://github.com/bitcoinjs/bip69/blob/master/test/fixtures.json|BitcoinJS Test Fixtures]] * [[https://www.npmjs.com/package/bip69|NodeJS]] +* [[https://github.com/blockchain/My-Wallet-V3/blob/v3.8.0/src/transaction.js#L120-L142|Blockchain.info public beta]] +* [[https://github.com/btcsuite/btcutil/blob/master/txsort/txsort.go|Btcsuite]] ==Acknowledgements== diff --git a/bip-0070.mediawiki b/bip-0070.mediawiki index 3642784..e3c17cf 100644 --- a/bip-0070.mediawiki +++ b/bip-0070.mediawiki @@ -1,7 +1,8 @@ <pre> BIP: 70 Title: Payment Protocol - Authors: Gavin Andresen <gavinandresen@gmail.com>, Mike Hearn <mhearn@bitcoinfoundation.org> + Author: Gavin Andresen <gavinandresen@gmail.com> + Mike Hearn <mhearn@bitcoinfoundation.org> Status: Final Type: Standards Track Created: 2013-07-29 diff --git a/bip-0073.mediawiki b/bip-0073.mediawiki index a020fb5..41c89a3 100644 --- a/bip-0073.mediawiki +++ b/bip-0073.mediawiki @@ -2,7 +2,7 @@ BIP: 73 Title: Use "Accept" header for response type negotiation with Payment Request URLs Author: Stephen Pair <stephen@bitpay.com> - Status: Draft + Status: Final Type: Standards Track Created: 2013-08-27 </pre> diff --git a/bip-0074.mediawiki b/bip-0074.mediawiki new file mode 100644 index 0000000..a860b38 --- /dev/null +++ b/bip-0074.mediawiki @@ -0,0 +1,62 @@ +<pre> + BIP: 74 + Title: Allow zero value OP_RETURN in Payment Protocol + Author: Toby Padilla <tobypadilla@gmail.com> + Status: Draft + Type: Standards Track + Created: 2016-01-29 +</pre> + +==Abstract== + +This BIP alters the Payment Protocol to allow for zero value OP_RETURN outputs in serialized PaymentRequests. + +==Motivation== + +The Payment Protocol (defined in BIP70) gives merchants a way to build sophisticated transactions by serializing one or more outputs in the form of a PaymentRequest. The PaymentRequest is then served over http/https to a customer's wallet where the serialized transaction can be executed. + +While the Payment Protocol allows for any valid script in its outputs, it also ignores outputs with zero value. This means BIP70 implementations can encode an OP_RETURN script but must provide a greater than dust value for that output. The end result is a successful PaymentRequest transaction with an OP_RETURN but the value assigned to that output is lost forever. + +This BIP allows for zero value OP_RETURN outputs in serialized PaymentRequests. The change means that OP_RETURN scripts will work as they were originally intended from within PaymentRequests without permanently destroying Bitcoin value. Zero value non-OP_RETURN scripts should continue to be ignored. + +In addition to fixing the issue of destroyed value, this change opens up new use cases that were previously impossible. + +While storing data on the blockchain is controversial, when used responsibly OP_RETURN provides a powerful mechanism for attaching metadata to a transaction. This BIP effectively decouples the creation of transactions containing OP_RETURN data from the execution of those transactions. The result are positive benefits for both merchants and wallets/customers. + +By supporting this BIP, wallets can participate in current and future, unforeseen use cases that benefit from metadata stored in OP_RETURN. Until now OP_RETURN transactions have typically been created and submitted by custom software. If a wallet can process a PaymentRequest with OP_RETURN data as proposed by this BIP, it will support potentially sophisticated Bitcoin applications without the wallet developer having to have prior knowledge of that application. + +An example might be a merchant that adds the hash of a plain text invoice to the checkout transaction. The merchant could construct the PaymentRequest with the invoice hash in an OP_RETURN and pass it to the customer's wallet. The wallet could then submit the transaction, including the invoice hash from the PaymentRequest. The wallet will have encoded a proof of purchase to the blockchain without the wallet developer having to coordinate with the merchant software or add features beyond this BIP. + +Merchants and Bitcoin application developers benefit from this BIP because they can now construct transactions that include OP_RETURN data in a keyless environment. Again, prior to this BIP, transactions that used OP_RETURN (with zero value) needed to be constructed and executed in the same software. By separating the two concerns, this BIP allows merchant software to create transactions with OP_RETURN metadata on a server without storing public or private Bitcoin keys. This greatly enhances security where OP_RETURN applications currently need access to a private key to sign transactions. + +==Specification== + +The specification for this BIP is straightforward. BIP70 should be fully implemented with the following changes: + +* Outputs where the script is an OP_RETURN and the value is zero should be accepted by the wallet. + +BIP70 has special handling for the case with multiple zero value outputs: + +<blockquote> +If the sum of outputs.amount is zero, the customer will be asked how much to pay, and the bitcoin client may choose any or all of the Outputs (if there are more than one) for payment. If the sum of outputs.amount is non-zero, then the customer will be asked to pay the sum, and the payment shall be split among the Outputs with non-zero amounts (if there are more than one; Outputs with zero amounts shall be ignored). +</blockquote> + +This behavior should be retained with the exception of OP_RETURN handling. In the case of a multiple output transaction where the sum of the output values is zero, the user should be prompted for a value and that value should be distributed over any or all outputs ''except'' the OP_RETURN output. In the case where the sum of outputs.amount is non-zero then any OP_RETURN outputs should not be ignored but no value should be assigned to them. + +Payment requests also must contain at least one payable output (i.e. no payment requests with ''just'' an OP_RETURN). + +==Rationale== + +As with the discussion around vanilla OP_RETURN, the practice of storing data on the blockchain is controversial. While blockchain and network bloat is an undeniable issue, the benefits that come from attaching metadata to transactions has proven to be too powerful to dismiss entirely. In the absence of OP_RETURN support the Bitcoin ecosystem has seen alternative, less elegant and more wasteful methods employed for Blockchain data storage. + +As it exists today, BIP70 allows for OP_RETURN data storage at the expense of permanently destroyed Bitcoin. Even fully removing support for OP_RETURN values in the Payment Protocol would still leave the door open to suboptimal data encoding via burning a larger than dust value to an output with a false address designed to encode data. + +This BIP offers all of the same benefits that come from the OP_RETURN compromise. Mainly that OP_RETURN scripts are provably unspendable and thus can be pruned from the UTXO pool. Without supporting this BIP, wallets that support BIP70 will allow for wasteful data storage. + +==Compatibility== + +Since this BIP still supports OP_RETURN statements with a greater than zero value, it should be fully backwards compatible with any existing implementations. + +==Copyright== + +This document is placed in the public domain. diff --git a/bip-0080.mediawiki b/bip-0080.mediawiki new file mode 100644 index 0000000..13d8597 --- /dev/null +++ b/bip-0080.mediawiki @@ -0,0 +1,75 @@ +<pre> + BIP: 80 + Title: Hierarchy for Non-Colored Voting Pool Deterministic Multisig Wallets + Author: Justus Ranvier <justus@opentransactions.org> + Jimmy Song <jimmy@monetas.net> + Status: Draft + Type: Informational + Created: 2014-08-11 +</pre> + +==Abstract== + +This BIP defines a logical hierarchy for non-colored voting pool deterministic multisig wallets based on an algorithm described in BIP-0032 (BIP32 from now on) and purpose scheme described in BIP-0043 (BIP43 from now on). + +This BIP is a particular application of BIP43 and is based on BIP44. + +==Motivation== + +The hierarchy proposed in this paper allows the handling of multiple coins and multiple series from a single seed. + +==Path levels== + +We define the following 4 levels in BIP32 path: + +<pre> +m / purpose' / coin_type' / series' / address_index +</pre> + +Apostrophe in the path indicates that BIP32 hardened derivation is used. + +Each level has a special meaning, described in the chapters below. + +===Purpose=== + +Purpose is a constant set following the BIP43 recommendation to: the ASCII value of "80" with the most signifigant bit set to indicate hardened derivation (0x80000050). It indicates that the subtree of this node is used according to this specification. + +Hardened derivation is used at this level. + +===Coin type=== + +One master node (seed) can be used for unlimited number of independent cryptocoins such as Bitcoin, Litecoin or Namecoin. However, sharing the same space for various cryptocoins has some disadvantages. + +This level creates a separate subtree for every cryptocoin, avoiding reusing addresses across cryptocoins and improving privacy issues. + +Coin type is a constant, set for each cryptocoin. The list of registered coin type constants should be obtained from BIP44. + +Hardened derivation is used at this level. + +===Series=== + +Series are used by voting pools in order to implement FIFO cold storage. By directing deposits into multiple series, the private keys for most of the deposits can be kept offline, and a limited portion can be brought online to process withdrawals. + +Hardened derivation is used at this level. + +===Index=== + +Public/private keypairs are numbered from index 0 in sequentially increasing manner. This number is used as child index in BIP32 derivation. + +Public keys obtained at this level of the heirarchy are used to construct multisig deposit scripts, using a schema that is shared between the members as an out-of-band contract. + +Public derivation is used at this level. + +==Compatible wallets== + +* [[https://github.com/btcsuite/btcwallet|btcwallet]] is the reference Bitcoin wallet for voting pools. + +==Copyright== + +This document is placed in the public domain. + +==Reference== + +* [[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]] diff --git a/bip-0081.mediawiki b/bip-0081.mediawiki new file mode 100644 index 0000000..b306075 --- /dev/null +++ b/bip-0081.mediawiki @@ -0,0 +1,72 @@ +<pre> + BIP: 81 + Title: Hierarchy for Colored Voting Pool Deterministic Multisig Wallets + Author: Justus Ranvier <justus@opentransactions.org> + Jimmy Song <jimmy@monetas.net> + Status: Draft + Type: Informational + Created: 2014-08-11 +</pre> + +==Abstract== + +This BIP defines a logical hierarchy for colored coin voting pool deterministic multisig wallets based on an algorithm described in BIP-0032 (BIP32 from now on) and purpose scheme described in BIP-0043 (BIP43 from now on). + +This BIP is a particular application of BIP43 and is based on BIP44. + +==Motivation== + +The hierarchy proposed in this paper allows the handling of multiple color definitions from a single seed. + +==Path levels== + +We define the following 8 levels in BIP32 path: + +<pre> +m / purpose' / series' / (5 color definition levels) / address_index +</pre> + +Apostrophe in the path indicates that BIP32 hardened derivation is used. + +Each level has a special meaning, described in the chapters below. + +===Purpose=== + +Purpose is a constant set following the BIP43 recommendation to: the ASCII value of "81" with the most signifigant bit set to indicate hardened derivation (0x80000051). It indicates that the subtree of this node is used according to this specification. + +Hardened derivation is used at this level. + +===Color Definition=== + +Index values which can be applied to a BIP32 node are limited to 4 bytes (32 bits). + +Since this is not sufficient to identify color definitions without a risk of collision, multiple levels are used. + +Color definitions are first shortened to 20 bytes using the Bitcoin hash160 function. + +The resulting 20 bytes are split into five groups in little endian format, and where each group is used as the seed for the five levels of color definition levels + +Public derivation is used at these levels, even when the index exceeds 2^31. + +===Index=== + +Public/private keypairs are numbered from index 0 in sequentially increasing manner. This number is used as child index in BIP32 derivation. + +Public keys obtained at this level of the heirarchy are used to construct multisig deposit scripts, using a schema that is shared between the members as an out-of-band contract. + +Public derivation is used at this level. + +==Compatible wallets== + +* [[https://github.com/btcsuite/btcwallet|btcwallet]] is the reference Bitcoin wallet for voting pools. + +==Copyright== + +This document is placed in the public domain. + +==Reference== + +* [[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-0080.mediawiki|BIP80 - Hierarchy for Non-Colored Voting Pool Deterministic Multisig Wallets]] diff --git a/bip-0083.mediawiki b/bip-0083.mediawiki new file mode 100644 index 0000000..f6aa8e7 --- /dev/null +++ b/bip-0083.mediawiki @@ -0,0 +1,92 @@ +<pre> + BIP: 83 + Title: Dynamic Hierarchical Deterministic Key Trees + Author: Eric Lombrozo <eric@ciphrex.com> + Status: Draft + Type: Standards Track + Created: 2015-11-16 +</pre> + +==Abstract== + +This BIP defines a scheme for key derivation that allows for dynamic creation of key hierarchies based on the algorithm described in BIP32. + +==Motivation== + +Several proposals have been made to try to standardize a structure for hierarchical deterministic wallets for the sake of interoperability (reference BIP32, BIP44, BIP45). However, all proposals to date have tried to impose a specific structure upfront without providing any flexibility for dynamic creation of new hierarchical levels with different semantics or mapping between different applications that use distinct structures. + +Instead of attempting to impose a specific structure upfront, this BIP proposes that we design the derivation in such a way that we can continue extending hierarchies arbitrarily and indefinitely. + +==Specification== + +BIP32 provides a hierarchical derivation scheme where every node in the tree can be either used to derive child nodes or used as a signing key for ECDSA. This means that as soon as we choose to use a node as a signing key, we can no longer derive children from that node. To draw an analogy to file systems, each node is either a file or a directory but never both. However, given the need to predictably know the location of new children, it is generally not a good idea to mix both signing keys and parent nodes at the same level in the hierarchy. This means that as soon as we've decided that a particular level in the hierarchy is to be used for signing keys, we've lost the ability to nest deeper levels into the tree. + +At every level of the hierarchy, we reserve the child with index 0 to allow further nesting, and for signing key parent nodes use child indices 1 to MAX_INDEX (2<sup>31</sup> - 1) for signing keys. We can use either hardened or nonhardened derivation. + +Let p denote a specific signing key parent node and k be an index greater than 0. The children signing keys are then: + +p / k + +with k > 0. + +To create sublevels, we derive the nested nodes: + +p / 0 / n + +with n ≥ 0. + +Each of these nodes can now contain signing key children of their own, and again we reserve index 0 to allow deeper nesting. + +==Notation== + +We propose the following shorthand for writing nested node derivations: + +p // n instead of p / 0 / n + +p //' n instead of p / 0' / n + +==Mappings== + +Rather than specifying upfront which path is to be used for a specific purpose (i.e. external invoicing vs. internal change), different applications can specify arbitrary parent nodes and derivation paths. This allows for nesting of sublevels to arbitrary depth with application-specified semantics. Rather than trying to specify use cases upfront, we leave the design completely open-ended. Different applications can exchange these mappings for interoperability. Eventually, if certain mappings become popular, application user interfaces can provide convenient shortcuts or use them as defaults. + +Note that BIP32 suggests reserving child 0 for the derivation of signing keys rather than sublevels. It is not really necessary to reserve signing key parents, however, as each key's parent's path can be explicitly stated. But unless we reserve a child for sublevel derivation, we lose the ability to nest deeper levels into the hierarchy. While we could reserve any arbitrary index for nesting sublevels, reserving child 0 seems simplest to implement, leaving all indices > 0 for contiguously indexed signing keys. We could also use MAX_INDEX (2<sup>31</sup> - 1) for this purpose. However, we believe doing so introduces more ideosyncracies into the semantics and will present a problem if we ever decide to extend the scheme to use indices larger than 31 bits. + +==Use Cases== + +===Account Hierarchies=== + +For all that follows, we assume that key indices k > 0 and parent node indices n ≥ 0. + +From a master seed m, we can construct a default account using the following derivations for nonhardened signing keys: + +m / 1 / k (for change/internal outputs) + +m / 2 / k (for invoice/external outputs) + +To create subaccount a<sub>n</sub>, we use: + +a<sub>n</sub> = m // n + +To generate keys for subaccount a<sub>n</sub>, we use: + +a<sub>n</sub> / 1 / k (for change/internal outputs) + +a<sub>n</sub> / 2 / k (for invoice/external outputs) + +We can continue creating subaccounts indefinitely using this scheme. + +===Bidirectional Payment Channels=== + +In order to create a bidirectional payment channel, it is necessary that previous commitments be revokable. In order to revoke previous commitments, each party reveals a secret to the other that would allow them to steal the funds in the channel if a transaction for a previous commitment is inserted into the blockchain. + +By allowing for arbitrary nesting of sublevels, we can construct decision trees of arbitrary depth and revoke an entire branch by revealing a parent node used to derive all the children. + +==References== + +* [[bip-0032.mediawiki|BIP32 - Hierarchical Deterministic Wallets]] +* [[https://lightning.network/lightning-network-paper.pdf|Lightning Network Whitepaper]] + +==Copyright== + +This document is placed in the public domain. + diff --git a/bip-0099.mediawiki b/bip-0099.mediawiki index c40bacb..3e0a43a 100644 --- a/bip-0099.mediawiki +++ b/bip-0099.mediawiki @@ -3,7 +3,7 @@ Title: Motivation and deployment of consensus rule changes ([soft/hard]forks) Author: Jorge Timón <jtimon@jtimon.cc> Status: Draft - Type: Informational | Process + Type: Informational Created: 2015-06-20 Post-History: http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-June/008936.html </pre> diff --git a/bip-0101.mediawiki b/bip-0101.mediawiki index a76db0f..cc8cfd5 100644 --- a/bip-0101.mediawiki +++ b/bip-0101.mediawiki @@ -2,7 +2,7 @@ BIP: 101 Title: Increase maximum block size Author: Gavin Andresen <gavinandresen@gmail.com> - Status: Draft + Status: Withdrawn Type: Standards Track Created: 2015-06-22 </pre> diff --git a/bip-0102.mediawiki b/bip-0102.mediawiki index b75f798..fc909f7 100644 --- a/bip-0102.mediawiki +++ b/bip-0102.mediawiki @@ -13,28 +13,29 @@ Simple, one-time increase in total amount of transaction data permitted in a blo ==Motivation== -# Enable network growth. -# Continue current economic policy of low fee pressure on average. -# Exercise network upgrade procedure. +# Continue current economic policy. +# Exercise hard fork network upgrade. ==Specification== -# Maximum block size permitted to be valid is 1MB. -# Increase this maximum to 2MB as soon as 75% of the last 1,000 blocks have signaled support. +# MAX_BLOCK_SIZE increased to 2,000,000 bytes at trigger point. # Increase maximum block sigops by similar factor, preserving SIZE/50 formula. +# Trigger: (1) Block time 00:00:00 on flag day, AND (2) 95% of the last 1,000 blocks have signaled support. ==Backward compatibility== -Older clients are not compatible with this change. The first block exceeding 1,000,000 bytes will partition older clients off the new network. +Fully validating older clients are not compatible with this change. +The first block exceeding 1,000,000 bytes will partition older clients +off the new network. ==Discussion== -In the short term, an increase is needed to continue to facilitate -network growth, and buy time for more comprehensive solutions to be -developed. This continues the current economic policies with regards to -fees, matching market expectations and preventing market disruption. +In the short term, an increase is needed to continue to current +economic policies with regards to fees and block space, matching +market expectations and preventing market disruption. -In the long term, continued direct management of this limit is a moral hazard that clouds free market input and prevents a healthy fee market from developing. This area of code should be transitioned away from direct management. +In the long term, this limit should focus on reflecting the maximum +network engineering limit. ==Implementation== diff --git a/bip-0103.mediawiki b/bip-0103.mediawiki new file mode 100644 index 0000000..39e8a3f --- /dev/null +++ b/bip-0103.mediawiki @@ -0,0 +1,72 @@ +<pre> + BIP: 103 + Title: Block size following technological growth + Author: Pieter Wuille <pieter.wuille@gmail.com> + Status: Draft + Type: Standards Track + Created: 2015-07-21 +</pre> + +==Abstract== + +This BIP proposes a block size growth intended to accommodate for hardware and other technological improvements for the foreseeable future. + +==Motivation== + +Many people want to see Bitcoin scale over time, allowing an increasing number of transactions on the block chain. It would come at an increased cost for the ecosystem (bandwidth, processing, and storage for relay nodes, as well as an impact on propagation speed of blocks on the network), but technology also improves over time. When all technologies depended on have improved as well as their availability on the market, there is no reason why Bitcoin's fundamental transaction rate cannot improve proportionally. + +Currently, there is a consensus rule in place that limits the size of blocks to 1000000 bytes. Changing this requires a hard-forking change: one that will require every full node in the network to implement the new rules. The new chain created by those changed nodes will be rejected by old nodes, so this would effectively be a request to the ecosystem to migrate to a new and incompatible network. Doing this while controversy exists is dangerous to the network and the ecosystem. + +Furthermore, the effective space available is always constrained by a hash rate majority and its ability to process transactions. No hard forking change that relaxes the block size limit can be guaranteed to provide enough space for every possible demand - or even any particular demand - unless strong centralization of the mining ecosystem is expected. Because of that, the development of a fee market and the evolution towards an ecosystem that is able to cope with block space competition should be considered healthy. This does not mean the block size or its limitation needs to be constant forever. However, the purpose of such a change should be evolution with technological growth, and not kicking the can down the road because of a fear of change in economics. + +Bitcoin's advantage over other systems does not lie in scalability. Well-designed centralized systems can trivially compete with Bitcoin's on-chain transactions in terms of cost, speed, reliability, convenience, and scale. Its power lies in transparency, lack of need for trust in network peers, miners, and those who influence or control the system. Wanting to increase the scale of the system is in conflict with all of those. Attempting to buy time with a fast increase is not wanting to face that reality, and treating the system as something whose scale trumps all other concerns. A long term scalability plan should aim on decreasing the need for trust required in off-chain systems, rather than increasing the need for trust in Bitcoin. + +In summary, hard forks are extremely powerful, and we need to use them very responsibly as a community. They have the ability to fundamentally change the technology or economics of the system, and can be used to disadvantage those who expected certain rules to be immutable. They should be restricted to uncontroversial changes, or risk eroding the expectation of low trust needed in the system in the longer term. As the block size debate has been controversial so far - for good or bad reasons - this BIP aims for gradual change and its effects start far enough in the future. + +==Specification== + +The block size limitation is replaced by the function below, applied to the median of the timestamps of the previous 11 blocks, or in code terms: the block size limit for pindexBlock is GetMaxBlockSize(pindexBlock->pprev->GetMedianTimePast()). + +The sigop limit scales proportionally. + +It implements a series of block size steps, one every ~97 days, between January 2017 and July 2063, each increasing the maximum block size by 4.4%. This allows an overall growth of 17.7% per year. + +<pre> +uint32_t GetMaxBlockSize(int64_t nMedianTimePast) { + // The first step is on January 1st 2017. + if (nMedianTimePast < 1483246800) { + return 1000000; + } + // After that, one step happens every 2^23 seconds. + int64_t step = (nMedianTimePast - 1483246800) >> 23; + // Don't do more than 11 doublings for now. + step = std::min<int64_t>(step, 175); + // Every step is a 2^(1/16) factor. + static const uint32_t bases[16] = { + // bases[i] == round(1000000 * pow(2.0, (i + 1) / 16.0)) + 1044274, 1090508, 1138789, 1189207, + 1241858, 1296840, 1354256, 1414214, + 1476826, 1542211, 1610490, 1681793, + 1756252, 1834008, 1915207, 2000000 + }; + return bases[step & 15] << (step / 16); +} +</pre> + +==Rationale== + +Waiting 1.5 years before the hard fork takes place should provide ample time to minimize the risk of a hard fork, if found uncontroversial. + +Because every increase (including the first) is only 4.4%, risk from large market or technological changes is minimized. + +The growth rate of 17.7% growth per year is consistent with the average growth rate of bandwidth the last years, which seems to be the bottleneck. If over time, this growth factor is beyond what the actual technology offers, the intention should be to soft fork a tighter limit. + +Using a time-based check is very simple to implement, needs little context, is efficient, and is trivially reviewable. Using the "median time past" guarantees monotonic behaviour, as this median is required to be increasing, according to Bitcoin's existing consensus rules. Using the "median time past" of the block before means we know in advance what the limit of each block will be, without depending on the actual block's timestamp. + +==Compatibility== + +This is a hard forking change, thus breaks compatbility with old fully-validating node. It should not be deployed without widespread consensus. + +==Acknowledgements== + +Thanks to Gregory Maxwell and Wladimir J. van der Laan for their suggestions. diff --git a/bip-0107.mediawiki b/bip-0107.mediawiki new file mode 100644 index 0000000..86edd99 --- /dev/null +++ b/bip-0107.mediawiki @@ -0,0 +1,83 @@ +<pre> + BIP: 107 + Title: Dynamic limit on the block size + Author: Washington Y. Sanchez <washington.sanchez@gmail.com> + Status: Draft + Type: Standards Track + Created: 2015-09-11 +</pre> + +==Abstract== + +This BIP proposes a dynamic limit to the block size based on transaction volume. + +==Motivation== + +Over the next few years, large infrastructure investments will be made into: + +# Improving global network connectivity +# Improving block propagation across the Bitcoin network +# Layer 2 services and networks for off-chain transactions +# General efficiency improvements to transactions and the blockchain + +* While there is a consensus between Bitcoin developers, miners, businesses and users that the block size needs to be increased, there is a lingering concern over the potential unintended consequences that may augment the trend towards network and mining centralization (largely driven by mining hardware such as ASICs) and thereby threaten the security of the network. +* In contrast, failing to respond to elevated on-chain transaction volume may lead to a consumer-failure of Bitcoin, where ordinary users - having enjoyed over 6 years of submitting transactions on-chain at relatively low cost - will be priced out of blockchain with the emergence of a prohibitive 'fee market'. +* These two concerns must be delicately balanced so that all users can benefit from a robust, scalable, and neutral network. + +==Specification== + +* Increases in the block size will occur in 2 phases +* '''Phase 1''' +** The block size will be increased similar to [[https://twitter.com/adam3us/status/636410827969421312|Adam Back's proposal]], as a safe runway prior to switching to Phase 2, while network and protocol infrastructure is improved +** The schedule: +*** ''2016-2017:'' 2 MB +*** ''2018-2019:'' 4 MB +*** ''2020:'' 6 MB +* '''Phase 2''' +** In 2020, the maximum block size will be increased dynamically according to sustained increases in transaction volume +** Every 4032 blocks (~4 weeks), a CHECK will be performed to determine if a raise in the maximum block size should occur +*** This calculates to a theoretical maximum of 13 increases per year +** IF of the last >= 3025 blocks were >=60% full, the maximum block size will be increased by 10% +** The maximum block size can only ever be increased, not decreased +* The default <code>limitfreerelay</code> will also be raised in proportion to maximum block size increases +** Transactions without fees can continue to be submitted and relayed on the network as per normal +** <code>limitfreerelay</code> also helps counter attempts to trigger a block size increase by 'penny-flooding' + +For example: +* When the dynamic rules for increasing the block size go live on January 1st 2020, the starting maximum block size will be 6 MB +* IF >=3025 blocks are >= 3.6 MB, the new maximum block size become 6.6 MB. +* The theoretical maximum block size at the end of 2020 would be ~20.7 MB, assuming all 13 increases are triggered every 4 weeks by the end of the year. + +==Rationale== + +* '''Phase 1''' +** This runway has a schedule for conservative increases to the block size in order to relieve transaction volume pressure while allowing network and protocol infrastructure improvements to be made, as well as layer 2 services to emerge +* '''Phase 2''' +** Why 60% full blocks? +*** IF blocks are 60% full, they count as a ''vote'' towards increasing the block size +*** If this parameter is too low, the trigger sensitivity may be too high and vulnerable to spam attacks or miner collusion +*** Setting the parameter too high may set the trigger sensitivity too low, causing transaction delays that are trying to be avoided in the first place +*** Between September 2013-2015, the standard deviation measured from average block size (n=730 data points from blockchain.info) was ~ 0.13 MB or 13% of the maximum block size +**** If blocks needed to be 90% full before an increase were triggered, normal variance in the average block size would mean some blocks would be full before an increase could be triggered +*** Therefore, we need a ''safe distance'' away from the maximum block size to avoid normal block size variance hitting the limit. The 60% level represents a 3 standard deviation distance from the limit. +** Why 3025 blocks? +*** The assessment period is 4032 blocks or ~ 4 weeks, with the threshold set as 4032 blocks/0.75 + 1 +*** Increases in the maximum block size should only occur after a sustained trend can be observed in order to: +***# Demonstrate a market-driven secular elevation in the transaction volume +***# Increase the cost to trigger an increase by spam attacks or miner collusion with zero fee transactions +*** In other words, increases to the maximum block size must be conservative but meaningful to relieve transaction volume pressure in response to true market demand +** Why 10% increase in the block size? +*** Increases in the block size are designed to be conservative and in balance with the number of theoretical opportunities to increase the block size per year +*** Makes any resources spent for spam attacks or miner collusion relatively expensive to achieve a minor increase in the block size. A sustained attack would need to be launched that may be too costly, and ideally detectable by the community + +==Deployment== +Similar deployment model to BIP101: +<blockquote>Activation is achieved when 750 of 1,000 consecutive blocks in the best chain have a version number with the first, second, third, and thirtieth bits set (0x20000007 in hex). The activation time will be the timestamp of the 750'th block plus a two week (1,209,600 second) grace period to give any remaining miners or services time to upgrade to support larger blocks.</blockquote> + +==Acknowledgements== + +Thanks to Austin Williams, Brian Hoffman, Angel Leon, Bulukani Mlalazi, Chris Pacia, and Ryan Shea for their comments. + +==Copyright== + +This work is placed in the public domain. diff --git a/bip-0109.mediawiki b/bip-0109.mediawiki new file mode 100644 index 0000000..667ef5f --- /dev/null +++ b/bip-0109.mediawiki @@ -0,0 +1,82 @@ +<pre> + BIP: 109 + Title: Two million byte size limit with sigop and sighash limits + Author: Gavin Andresen <gavinandresen@gmail.com> + Status: Draft + Type: Standards Track + Created: 2016-01-28 +</pre> + +==Abstract== + +One-time increase in total amount of transaction data permitted in a block from 1MB to 2MB, with limits on signature operations and hashing. + +==Motivation== + +# Continue current economic policy. +# Exercise hard fork network upgrade. +# Mitigate potential CPU exhaustion attacks + +==Specification== + +=== MAX_BLOCK_SIZE increased to 2,000,000 bytes === + +The maximum number of bytes in a canonically serialized block shall be increased from +1,000,000 bytes to 2,000,000 bytes. + +=== Switch to accurately-counted sigop limit of 20,000 per block === + +The existing MAX_SIGOPS limit of 20,000 signature operations per block shall be retained, +but only ECDSA verifications actually performed to validate the block shall be counted. + +In particular: + +* The coinbase scriptSig is not counted +* Signature operations in un-executed branches of a Script are not counted +* OP_CHECKMULTISIG evaluations are counted accurately; if the signature for a 1-of-20 OP_CHECKMULTISIG is satisified by the public key nearest the top of the execution stack, it is counted as one signature operation. If it is satisfied by the public key nearest the bottom of the execution stack, it is counted as twenty signature operations. +* Signature operations involving invalidly encoded signatures or public keys are not counted towards the limit + +=== Add a new limit of 1,300,000,000 bytes hashed to compute transaction signatures per block === + +The amount of data hashed to compute signature hashes is limited to 1,300,000,000 bytes per block. The same rules for counting are used as for counting signature operations. + +=== Activation: 75% hashpower support trigger, followed by 28-day 'grace period' === + +Solo miners or mining pool operators express their support for this BIP by setting the fourth-highest-bit in the block's 32-bit version number (0x10000000 in hex). The first block with that bit set, a timestamp less than or equal to the expiration time, and with at least 750 out of 1000 blocks preceding it (with heights H-1000..H-1) with that bit set, shall define the beginning of a grace period. Blocks with timestamps greater than or equal to the triggering block's timestamp plus 28 days (60*60*24*28 seconds) shall be subject to the new limits. + +As always, miners are expected to use their best judgement for what is best for the entire Bitcoin ecosystem when making decisions about what consensus-level changes to support. + +=== Expiration: 1-Jan-2018 === + +If this BIP is not triggered before 1-Jan-2018 00:00:00 GMT it should be considered withdrawn. + +Miners that support this BIP should set bit 0x10000000 in the block version until 1-Jan-2018. After that date, that bit can be safely re-used for future consensus rule upgrades. + +==Backward compatibility== + +Fully validating older clients are not compatible with this change. +The first block exceeding the old limits on block size or inaccurately counted signature operations will partition older clients off the new network. + +SPV (simple payment validation) wallets are compatible with this change. + +==Rationale== + +In the short term, an increase is needed to handle increasing transaction volume. + +The limits on signature operations and amount of signature hashing done prevent possible CPU exhaustion attacks by "rogue miners" producing very expensive-to-validate two megabyte blocks. The signature hashing limit is chosen to be impossible to reach with any non-attack transaction or block, to minimize the impact on existing mining or wallet software. + +The choices of constants for the deployment scheme were motivated by prior experience with upgrades to the Bitcoin consensus rules: + +* 0x10000000 was chosen to be compatible with the BIP 9 proposal for parallel deployment of soft forks +* 75% was chosen instead of 95% to minimize the opportunity for a single large mining pool or miner to be able to veto an increase, either because of ideological opposition or threat of violence or extortion. +* A four-week grace period after the voting period was chosen as a balance between giving people sufficient time to upgrade and keeping people's attention on the urgent need to upgrade. + +==Implementation== + +https://github.com/gavinandresen/bitcoin-git/tree/two_mb_bump + +See also http://gavinandresen.ninja/a-guided-tour-of-the-2mb-fork + +==Copyright== + +This work is placed in the public domain. diff --git a/bip-0111.mediawiki b/bip-0111.mediawiki index d3bd630..e0ae9e8 100644 --- a/bip-0111.mediawiki +++ b/bip-0111.mediawiki @@ -1,7 +1,8 @@ <pre> BIP: 111 Title: NODE_BLOOM service bit - Author: Matt Corallo <bip@bluematt.me>, Peter Todd <pete@petertodd.org> + Author: Matt Corallo <bip@bluematt.me> + Peter Todd <pete@petertodd.org> Status: Draft Type: Standards Track Created: 2015-08-20 diff --git a/bip-0112.mediawiki b/bip-0112.mediawiki index e1a186f..336f9fc 100644 --- a/bip-0112.mediawiki +++ b/bip-0112.mediawiki @@ -1,9 +1,9 @@ <pre> BIP: 112 Title: CHECKSEQUENCEVERIFY - Authors: BtcDrak <btcdrak@gmail.com> - Mark Friedenbach <mark@friedenbach.org> - Eric Lombrozo <elombrozo@gmail.com> + Author: BtcDrak <btcdrak@gmail.com> + Mark Friedenbach <mark@friedenbach.org> + Eric Lombrozo <elombrozo@gmail.com> Status: Draft Type: Standards Track Created: 2015-08-10 @@ -20,24 +20,20 @@ being spent. ==Summary== CHECKSEQUENCEVERIFY redefines the existing NOP3 opcode. -When executed, the script interpreter continues as if a NOP was executed -so long as one of the following conditions is met: +When executed, if any of the following conditions are true, the script interpreter will terminate with an error: - * the transaction's nVersion field is 0 or 1; - * the top item on the stack is a value greater than or equal to (1 << 31); or - * the top item on the stack and the transaction input's sequence number are both relative lock-times of the same units, and the relative lock-time represented by the sequence number is greater than or equal to the relative lock-time represented by the top item on the stack. +* the stack is empty; or +* the top item on the stack is less than 0; or +* the top item on the stack has the disable flag (1 << 31) unset; and +** the transaction version is less than 2; or +** the transaction input sequence number disable flag (1 << 31) is set; or +** the relative lock-time type is not the same; or +** the top stack item is greater than the transaction sequence (when masked according to the BIP68); -Otherwise, script execution terminates with an error. +Otherwise, script execution will continue as if a NOP had been executed. -BIP 68's redefinition of nSequence prevents a non-final transaction -from being selected for inclusion in a block until the corresponding -input has reached the specified age, as measured in block height or -block time. By comparing the argument to CHECKSEQUENCEVERIFY against -the nSequence field, we indirectly verify a desired minimum age of the -the output being spent; until that relative age has been reached any -script execution pathway including the CHECKSEQUENCEVERIFY will fail -to validate, causing the transaction not to be selected for inclusion -in a block. +BIP 68 prevents a non-final transaction from being selected for inclusion in a block until the corresponding input has reached the specified age, as measured in block-height or block-time. By comparing the argument to CHECKSEQUENCEVERIFY against the nSequence field, we indirectly verify a desired minimum age of the +the output being spent; until that relative age has been reached any script execution pathway including the CHECKSEQUENCEVERIFY will fail to validate, causing the transaction not to be selected for inclusion in a block. ==Motivation== @@ -85,9 +81,9 @@ of some future event. However, given the immutable nature of the blockchain, it is practically impossible to retroactively invalidate a previous commitment that has already confirmed. The only mechanism we really have for retroactive invalidation is blockchain reorganization which, for fundamental security -reasons, is designed to be very hard and very expensive to deliberately pull off. +reasons, is designed to be very hard and very expensive to do. -Despite this limitation, we do have a way to provide something functionally similar +Despite this limitation, we do have a way to provide something functionally similar to retroactive invalidation while preserving irreversibility of past commitments using CHECKSEQUENCEVERIFY. By constructing scripts with multiple branches of execution where one or more of the branches are delayed we provide a time window in which someone can supply an invalidation condition that allows the @@ -100,7 +96,7 @@ Some more specific applications of this idea: ====Hash Time-Locked Contracts==== -Hash Time-Locked Contracts (HTLCs) provide a general mechanism for offchain contract negotiation. An execution pathway can be made to require knowledge of a secret (a hash preimage) that can be presented within an invalidation time window. By sharing the secret it is possible to guarantee to the counterparty that the transaction will never be broadcast since this would allow the counterparty to claim the output immediately while one would have to wait for the time window to pass. If the secret has not been shared, the counterparty will be unable to use the instant pathway and the delayed pathway must be used instead. +Hash Time-Locked Contracts (HTLCs) provide a general mechanism for off-chain contract negotiation. An execution pathway can be made to require knowledge of a secret (a hash preimage) that can be presented within an invalidation time window. By sharing the secret it is possible to guarantee to the counterparty that the transaction will never be broadcast since this would allow the counterparty to claim the output immediately while one would have to wait for the time window to pass. If the secret has not been shared, the counterparty will be unable to use the instant pathway and the delayed pathway must be used instead. ====Bidirectional Payment Channels==== @@ -142,11 +138,12 @@ A simple output, paying to Alice might then look like: HASH160 <revokehash> EQUAL IF - DUP HASH160 <Bob key hash> CHECKSIGVERIFY + <Bob key hash> ELSE - "24h" CHECKSEQUENCEVERIFY - DUP HASH160 <Alice key hash> CHECKSIGVERIFY + "24h" CHECKSEQUENCEVERIFY DROP + <Alice key hash> ENDIF + CHECKSIG This allows Alice to publish the latest commitment transaction at any time and spend the funds after 24 hours, but also ensures that if Alice @@ -156,17 +153,18 @@ With CHECKLOCKTIMEVERIFY, this would look like: HASH160 <revokehash> EQUAL IF - DUP HASH160 <Bob key hash> CHECKSIGVERIFY + <Bob key hash> ELSE - "2015/12/15" CHECKLOCKTIMEVERIFY - DUP HASH160 <Alice key hash> CHECKSIGVERIFY + "2015/12/15" CHECKLOCKTIMEVERIFY DROP + <Alice key hash> ENDIF + CHECKSIG This form of transaction would mean that if the anchor is unspent on 2015/12/16, Alice can use this commitment even if it has been revoked, simply by spending it immediately, giving no time for Bob to claim it. -Ths means that the channel has a deadline that cannot be pushed +This means that the channel has a deadline that cannot be pushed back without hitting the blockchain; and also that funds may not be available until the deadline is hit. CHECKSEQUENCEVERIFY allows you to avoid making such a tradeoff. @@ -179,35 +177,33 @@ delay, and the entire output can be claimed by the other party if the revocation secret is known. With CHECKSEQUENCEVERIFY, a HTLC payable to Alice might look like the following in Alice's commitment transaction: - HASH160 DUP <revokehash> EQUAL + HASH160 DUP <R-HASH> EQUAL IF - DROP DUP HASH160 <Bob key hash> CHECKSIGVERIFY + "24h" CHECKSEQUENCEVERIFY + 2DROP + <Alice key hash> ELSE - <R hash> EQUAL - IF - "24h" CHECKSEQUENCEVERIFY DROP - DUP HASH160 <Alice key hash> CHECKSIGVERIFY - ELSE - "2015/10/20 10:33" CHECKLOCKTIMEVERIFY DROP - DUP HASH160 <Bob key hash> CHECKSIGVERIFY + <Commit-Revocation-Hash> EQUAL + NOTIF + "24h" CHECKLOCKTIMEVERIFY DROP ENDIF + <Bob key hash> ENDIF + CHECKSIG and correspondingly in Bob's commitment transaction: - HASH160 DUP <revokehash> EQUAL + HASH160 DUP <R-HASH> EQUAL + SWAP <Commit-Revocation-Hash> EQUAL ADD IF - DROP DUP HASH160 <Alice key hash> CHECKSIGVERIFY + <Alice key hash> ELSE - <R hash> EQUAL - IF - DUP HASH160 <Alice key hash> CHECKSIGVERIFY - ELSE - "24h" CHECKSEQUENCEVERIFY DROP - "2015/10/20 10:33" CHECKLOCKTIMEVERIFY DROP - DUP HASH160 <Bob key hash> CHECKSIGVERIFY - ENDIF + "2015/10/20 10:33" CHECKLOCKTIMEVERIFY + "24h" CHECKSEQUENCEVERIFY + 2DROP + <Bob key hash> ENDIF + CHECKSIG Note that both CHECKSEQUENCEVERIFY and CHECKLOCKTIMEVERIFY are used in the final branch of above to ensure Bob cannot spend the output until after both @@ -233,128 +229,123 @@ The 2-way pegged sidechain requires a new REORGPROOFVERIFY opcode, the semantics Refer to the reference implementation, reproduced below, for the precise semantics and detailed rationale for those semantics. - - /* Threshold for nSequence: below this value it is interpreted - * as a relative lock-time, otherwise ignored. */ - static const uint32_t SEQUENCE_LOCKTIME_THRESHOLD = (1 << 31); - - /* Threshold for nSequence when interpreted as a relative - * lock-time: below this value it has units of blocks, otherwise - * seconds. */ - static const uint32_t SEQUENCE_UNITS_THRESHOLD = (1 << 30); - - case OP_NOP3: - { - if (!(flags & SCRIPT_VERIFY_CHECKSEQUENCEVERIFY)) { - // not enabled; treat as a NOP3 - if (flags & SCRIPT_VERIFY_DISCOURAGE_UPGRADABLE_NOPS) { - return set_error(serror, SCRIPT_ERR_DISCOURAGE_UPGRADABLE_NOPS); - } - break; +<pre> +/* Below flags apply in the context of BIP 68 */ +/* If this flag set, CTxIn::nSequence is NOT interpreted as a + * relative lock-time. */ +static const uint32_t SEQUENCE_LOCKTIME_DISABLE_FLAG = (1 << 31); + +/* If CTxIn::nSequence encodes a relative lock-time and this flag + * is set, the relative lock-time has units of 512 seconds, + * otherwise it specifies blocks with a granularity of 1. */ +static const uint32_t SEQUENCE_LOCKTIME_TYPE_FLAG = (1 << 22); + +/* If CTxIn::nSequence encodes a relative lock-time, this mask is + * applied to extract that lock-time from the sequence field. */ +static const uint32_t SEQUENCE_LOCKTIME_MASK = 0x0000ffff; + +case OP_NOP3: +{ + if (!(flags & SCRIPT_VERIFY_CHECKSEQUENCEVERIFY)) { + // not enabled; treat as a NOP3 + if (flags & SCRIPT_VERIFY_DISCOURAGE_UPGRADABLE_NOPS) { + return set_error(serror, SCRIPT_ERR_DISCOURAGE_UPGRADABLE_NOPS); } - - if (stack.size() < 1) - return set_error(serror, SCRIPT_ERR_INVALID_STACK_OPERATION); - - // Note that elsewhere numeric opcodes are limited to - // operands in the range -2**31+1 to 2**31-1, however it is - // legal for opcodes to produce results exceeding that - // range. This limitation is implemented by CScriptNum's - // default 4-byte limit. - // - // Thus as a special case we tell CScriptNum to accept up - // to 5-byte bignums, which are good until 2**39-1, well - // beyond the 2**32-1 limit of the nSequence field itself. - const CScriptNum nSequence(stacktop(-1), fRequireMinimal, 5); - - // In the rare event that the argument may be < 0 due to - // some arithmetic being done first, you can always use - // 0 MAX CHECKSEQUENCEVERIFY. - if (nSequence < 0) - return set_error(serror, SCRIPT_ERR_NEGATIVE_LOCKTIME); - - // To provide for future soft-fork extensibility, if the - // operand is too large to be treated as a relative lock- - // time, CHECKSEQUENCEVERIFY behaves as a NOP. - if (nSequence >= SEQUENCE_LOCKTIME_THRESHOLD) - break; - - // Actually compare the specified sequence number with the input. - if (!checker.CheckSequence(nSequence)) - return set_error(serror, SCRIPT_ERR_UNSATISFIED_LOCKTIME); - break; } - - bool TransactionSignatureChecker::CheckSequence(const CScriptNum& nSequence) const - { - // Relative lock times are supported by comparing the passed - // in operand to the sequence number of the input. - const int64_t txToSequence = (int64_t)txTo->vin[nIn].nSequence; - - // Fail if the transaction's version number is not set high - // enough to trigger BIP 68 rules. - if (static_cast<uint32_t>(txTo->nVersion) < 2) - return false; - - // Sequence numbers above SEQUENCE_LOCKTIME_THRESHOLD - // are not consensus constrained. Testing that the transaction's - // sequence number is not above this threshold prevents - // using this property to get around a CHECKSEQUENCEVERIFY - // check. - if (txToSequence >= SEQUENCE_LOCKTIME_THRESHOLD) - return false; - - // There are two kinds of nSequence: lock-by-blockheight - // and lock-by-blocktime, distinguished by whether - // nSequence < SEQUENCE_UNITS_THRESHOLD. - // - // We want to compare apples to apples, so fail the script - // unless the type of nSequence being tested is the same as - // the nSequence in the transaction. - if (!( - (txToSequence < SEQUENCE_UNITS_THRESHOLD && nSequence < SEQUENCE_UNITS_THRESHOLD) || - (txToSequence >= SEQUENCE_UNITS_THRESHOLD && nSequence >= SEQUENCE_UNITS_THRESHOLD) - )) - return false; - - // Now that we know we're comparing apples-to-apples, the - // comparison is a simple numeric one. - if (txTo->vin[nIn].nSequence > txToSequence) - return false; - - return true; - } + if (stack.size() < 1) + return set_error(serror, SCRIPT_ERR_INVALID_STACK_OPERATION); + + // Note that elsewhere numeric opcodes are limited to + // operands in the range -2**31+1 to 2**31-1, however it is + // legal for opcodes to produce results exceeding that + // range. This limitation is implemented by CScriptNum's + // default 4-byte limit. + // + // Thus as a special case we tell CScriptNum to accept up + // to 5-byte bignums, which are good until 2**39-1, well + // beyond the 2**32-1 limit of the nSequence field itself. + const CScriptNum nSequence(stacktop(-1), fRequireMinimal, 5); + + // In the rare event that the argument may be < 0 due to + // some arithmetic being done first, you can always use + // 0 MAX CHECKSEQUENCEVERIFY. + if (nSequence < 0) + return set_error(serror, SCRIPT_ERR_NEGATIVE_LOCKTIME); + + // To provide for future soft-fork extensibility, if the + // operand has the disabled lock-time flag set, + // CHECKSEQUENCEVERIFY behaves as a NOP. + if ((nSequence & CTxIn::SEQUENCE_LOCKTIME_DISABLE_FLAG) != 0) + break; + + // Compare the specified sequence number with the input. + if (!checker.CheckSequence(nSequence)) + return set_error(serror, SCRIPT_ERR_UNSATISFIED_LOCKTIME); + + break; +} + +bool TransactionSignatureChecker::CheckSequence(const CScriptNum& nSequence) const +{ + // Relative lock times are supported by comparing the passed + // in operand to the sequence number of the input. + const int64_t txToSequence = (int64_t)txTo->vin[nIn].nSequence; + + // Fail if the transaction's version number is not set high + // enough to trigger BIP 68 rules. + if (static_cast<uint32_t>(txTo->nVersion) < 2) + return false; + + // Sequence numbers with their most significant bit set are not + // consensus constrained. Testing that the transaction's sequence + // number do not have this bit set prevents using this property + // to get around a CHECKSEQUENCEVERIFY check. + if (txToSequence & CTxIn::SEQUENCE_LOCKTIME_DISABLE_FLAG) + return false; + + // Mask off any bits that do not have consensus-enforced meaning + // before doing the integer comparisons + const uint32_t nLockTimeMask = CTxIn::SEQUENCE_LOCKTIME_TYPE_FLAG | CTxIn::SEQUENCE_LOCKTIME_MASK; + const int64_t txToSequenceMasked = txToSequence & nLockTimeMask; + const CScriptNum nSequenceMasked = nSequence & nLockTimeMask; + + // There are two kinds of nSequence: lock-by-blockheight + // and lock-by-blocktime, distinguished by whether + // nSequenceMasked < CTxIn::SEQUENCE_LOCKTIME_TYPE_FLAG. + // + // We want to compare apples to apples, so fail the script + // unless the type of nSequenceMasked being tested is the same as + // the nSequenceMasked in the transaction. + if (!( + (txToSequenceMasked < CTxIn::SEQUENCE_LOCKTIME_TYPE_FLAG && nSequenceMasked < CTxIn::SEQUENCE_LOCKTIME_TYPE_FLAG) || + (txToSequenceMasked >= CTxIn::SEQUENCE_LOCKTIME_TYPE_FLAG && nSequenceMasked >= CTxIn::SEQUENCE_LOCKTIME_TYPE_FLAG) + )) + return false; + + // Now that we know we're comparing apples-to-apples, the + // comparison is a simple numeric one. + if (nSequenceMasked > txToSequenceMasked) + return false; + + return true; +} +</pre> ==Reference Implementation== A reference implementation is provided by the following pull request: -https://github.com/bitcoin/bitcoin/pull/6564 +https://github.com/bitcoin/bitcoin/pull/7524 ==Deployment== -We reuse the double-threshold switchover mechanism from BIPs 34 and -66, with the same thresholds, but for nVersion = 4. The new rules are -in effect for every block (at height H) with nVersion = 4 and at least -750 out of 1000 blocks preceding it (with heights H-1000..H-1) also -have nVersion = 4. Furthermore, when 950 out of the 1000 blocks -preceding a block do have nVersion = 4, nVersion = 3 blocks become -invalid, and all further blocks enforce the new rules. - -It is recommended that this soft-fork deployment trigger include other -related proposals for improving Bitcoin's lock-time capabilities, including: +This BIP is to be deployed by either version-bits BIP9 or by IsSuperMajority(). Exact details TDB. -[https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki BIP 65]: -OP_CHECKLOCKTIMEVERIFY, +It is recommended to deploy BIP68 and BIP113 at the same time as this BIP. -[https://github.com/bitcoin/bips/blob/master/bip-0068.mediawiki BIP 68]: -Consensus-enforced transaction replacement signalled via sequence numbers, - -and [https://github.com/bitcoin/bips/blob/master/bip-0113.mediawiki BIP 113]: -Median-Past-Time-Lock. ==Credits== @@ -367,12 +358,12 @@ done by Peter Todd for the closely related BIP 65. BtcDrak authored this BIP document. -Thanks to Eric Lombrozo and Anthony Towns for contributing example usecases. +Thanks to Eric Lombrozo and Anthony Towns for contributing example use cases. ==References== -[https://github.com/bitcoin/bips/blob/master/bip-0068.mediawiki BIP 68] Consensus-enforced transaction replacement signalled via sequence numbers +[https://github.com/bitcoin/bips/blob/master/bip-0068.mediawiki BIP 68] Relative lock-time through consensus-enforced sequence numbers [https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki BIP 65] OP_CHECKLOCKTIMEVERIFY @@ -397,3 +388,4 @@ Thanks to Eric Lombrozo and Anthony Towns for contributing example usecases. This document is placed in the public domain. + diff --git a/bip-0113.mediawiki b/bip-0113.mediawiki index 190fb4c..d21054b 100644 --- a/bip-0113.mediawiki +++ b/bip-0113.mediawiki @@ -2,7 +2,7 @@ BIP: 113 Title: Median time-past as endpoint for lock-time calculations Author: Thomas Kerin <me@thomaskerin.io> - Mark Friedenbach <mark@friedenbach.org> + Mark Friedenbach <mark@friedenbach.org> Status: Draft Type: Standards Track Created: 2015-08-10 @@ -34,8 +34,9 @@ value to monotonically advance, thereby removing the capability for miners to claim more transaction fees by lying about the timestamps of their block. -This proposal seeks to ensure reliable behaviour in locktime calculations as -required by BIP65 (CHECKLOCKTIMEVERIFY), BIP68 (sequence numbers), and BIP112 (CHECKSEQUENCEVERIFY). +This proposal seeks to ensure reliable behaviour in locktime calculations +as required by BIP65 (CHECKLOCKTIMEVERIFY) and matching the behavior of +BIP68 (sequence numbers) and BIP112 (CHECKSEQUENCEVERIFY). ==Specification== @@ -58,11 +59,10 @@ block time for the purpose of checking lock-time constraints: return pbegin[(pend - pbegin)/2]; } -Lock-time constraints are checked by the consensus method IsFinalTx(), -or LockTime() under BIP68. These methods take the block time as one -parameter. This BIP proposes that after activation calls to -IsFinalTx() or LockTime() within consensus code use the return value -of `GetMedianTimePast(pindexPrev)` instead. +Lock-time constraints are checked by the consensus method IsFinalTx(). +This method takes the block time as one parameter. This BIP proposes +that after activation calls to IsFinalTx() within consensus code use +the return value of `GetMedianTimePast(pindexPrev)` instead. A reference implementation of this proposal is provided by the following pull request: @@ -72,33 +72,10 @@ https://github.com/bitcoin/bitcoin/pull/6566 ==Deployment== -We reuse the double-threshold switchover mechanism from BIPs 34 and -66, with the same thresholds, but for nVersion = 8. The new rules are -in effect for every block (at height H) with nVersion = 8 and at least -750 out of 1000 blocks preceding it (with heights H-1000..H-1) also -have nVersion = 8. Furthermore, when 950 out of the 1000 blocks -preceding a block do have nVersion = 8, nVersion = 3 blocks become -invalid, and all further blocks enforce the new rules. +This BIP is to be deployed by either version-bits BIP9 or by isSuperMajority(). +Exact details TBD. -When assessing the block version as mask of ~0x20000007 must be applied -to work around the complications caused by -[http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/010396.html BIP101's premature use] -of the [https://gist.github.com/sipa/bf69659f43e763540550 undecided version bits proposal]. - -By applying ~0x20000007 with nVersion = 8, the thresholds should be tested -comparing block nVersion >= 4 as this will save a bit for future use. - -It is recommended that this soft-fork deployment trigger include other related -proposals for improving Bitcoin's lock-time capabilities, including: - -[https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki BIP 65]: -CHECKLOCKTIMEVERIFY, - -[https://github.com/bitcoin/bips/blob/master/bip-0068.mediawiki BIP 68]: -Consensus-enforced transaction replacement signalled via sequence numbers, - -and [https://github.com/bitcoin/bips/blob/master/bip-0112.mediawiki BIP 112]: -CHECKSEQUENCEVERIFY. +It is recommended to deploy BIP68 and BIP112 at the same time as this BIP. ==Acknowledgements== diff --git a/bip-0122.mediawiki b/bip-0122.mediawiki new file mode 100644 index 0000000..5386dd2 --- /dev/null +++ b/bip-0122.mediawiki @@ -0,0 +1,124 @@ +<pre> + BIP: 122 + Title: URI scheme for Blockchain references / exploration + Author: Marco Pontello <marcopon@gmail.com> + Status: Draft + Type: Standards Track + Created: 2015-08-29 + Post-History: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/010712.html +</pre> + +==Abstract== + +This BIP proposes a URI scheme for looking up blocks, transactions and addresses on a Blockchain explorer, or in general to make proper Blockchain references. + +==Motivation== + +The purpose of this URI scheme is to enable users to handle all the requests for details about blocks, transactions, etc. with their preferred tool (being that a web service or a local application). +Currently a Bitcoin client usually points to an arbitrary blockchain explorer when the user looks for the details of a transaction or allows the user to choose from a set of alternatives. +Resorting to copy + paste into a browser is often required. +The same happens with posts and messages that reference some particular txs or blocks, if they provide links at all. + +==Specification== + +The URI follow this form: + + <nowiki>blockchain:[//<chain>]/<tx|block|address>/<hash></nowiki> + +Where: + +{| class="wikitable" +! style="text-align: center;" | Element +! colspan="2" style="text-align: center;" | Description +! Required? +|- +| chain +| colspan="2" | '''chain ID''' (see below) of the desired chain, leading 0s included. If omitted (which would be the usual case), Bitcoin main net is assumed. +| optional +|- +| rowspan="3" | type +| tx +| for transactions. +| rowspan="3" | required +|- +| block +| for blocks (supports both hash or height). +|- +| address +| for addresses. +|- +| hash +| colspan="2" | the relevant hash to refer to (leading zeros included), or block height. +| required +|} + +====ABNF grammar==== + +<pre> +blockchainuri = "blockchain:" ["//" chain] "/" object +object = ("tx" "/" hash) / ("block" "/" (hash / blockheight)) / + ("address" "/" address) +chain = hash +hash = 64HEXDIG +blockheight = 1*15DIGIT ; 15 is somehow arbitrary, i.e. a "small" int. +address = base58 ; https://en.wikipedia.org/wiki/Base58 +</pre> + +---- +===Definition of chain ID=== + +The '''chain ID''' of a chain is the block hash of the corresponding genesis block. For forked chains, it's the block hash of the first block after fork. + +So, for example: +<pre> +Bitcoin main : 000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f +Bitcoin test : 000000000933ea01ad0ee984209779baaec3ced90fa3f408719526f8d77f4943 +Bitcoin regtest: 0f9188f13cb7b2c71f2a335e3a4fc328bf5beb436012afca590b1a11466e2206 +</pre> + +An example of forked chain (Feathercoin, that forked Litecoin): + +<img src=bip-0122/chainid.png></img> + +<pre> +Litecoin : 12a765e31ffd4059bada1e25190f6e98c99d9714d334efa41a195a7e7e04bfe2 +Feathercoin: fdbe99b90c90bae7505796461471d89ae8388ab953997aa06a355bbda8d915cb +</pre> + + +==Examples== + +A transaction on Bitcoin main net: + blockchain:/tx/b462ae6eb8bdae2e060239a2a3ea5d9c3e0f9ef34d9717beb2dcf0ed42cee7da + +A block on Bitcoin main net: + blockchain:/block/00000000000000000119af5bcae2926df54ae262e9071a94a99c913cc217cc72 +or + blockchain:/block/372338 + +An address on Bitcoin main net: + blockchain:/address/16EW6Rv9P9AxFDBrZV816dD4sj1EAYUX3f + +A transaction on Bitcoin test net: + blockchain://000000000933ea01ad0ee984209779baaec3ced90fa3f408719526f8d77f4943/tx/3b95a766d7a99b87188d6875c8484cb2b310b78459b7816d4dfc3f0f7e04281a + +==Rationale== + +From the point of view of a wallet (or other Blockchain related tool) developers which need to reference Blockchain data, using this scheme mean that he can simply make it a `blockchain:` link without having to worry about any specific Blockchain explorer or provide a means for the user to select one. + +Blockchain explorers in turn will simply offer to handle the `blockchain:` URI schema, the first time the user visit their website, or launch/install the application, or even set themselves if there isn't already one. + +Users can link directly to their preferred block explorer (avoiding copy + paste which can be awkward on mobile devices). + +== Sample implementation == + +[https://github.com/MarcoPon/blockchain-exploration Demo Blockchain: URI handler on GitHub] + +==Acknowledgements== + +Thanks to Btc Drak for suggesting support for different networks and Jorge Timon for the suggestion that we could identify each network by its genesis block hash. +Thanks to Richard Moore, Matt Whitlock, Andreas Schildbach for help with the structure and hierarchy of the URI scheme. + +==Copyright== + +This document is placed in the public domain. diff --git a/bip-0122/chainid.png b/bip-0122/chainid.png Binary files differnew file mode 100644 index 0000000..ab6957a --- /dev/null +++ b/bip-0122/chainid.png diff --git a/bip-0123.mediawiki b/bip-0123.mediawiki index 776529a..3d40326 100644 --- a/bip-0123.mediawiki +++ b/bip-0123.mediawiki @@ -2,7 +2,7 @@ BIP: 123 Layer: Process Title: BIP Classification - Author: Eric Lombrozo + Author: Eric Lombrozo <elombrozo@gmail.com> Status: Draft Type: Process Created: 2015-08-26 @@ -82,6 +82,13 @@ The applications layer specifies high level structures, abstractions, and conven | Standard | Active |- +| [[bip-0009.mediawiki|9]] +| Consensus (soft fork) +| Version bits with timeout and delay +| Pieter Wuille, Peter Todd, Greg Maxwell, Rusty Russell +| Informational +| Draft +|- | [[bip-0010.mediawiki|10]] | Applications | Multi-Sig Transaction Distribution @@ -391,11 +398,186 @@ The applications layer specifies high level structures, abstractions, and conven | Standard | Draft |- +| [[bip-0080.mediawiki|80]] +| Applications +| Hierarchy for Non-Colored Voting Pool Deterministic Multisig Wallets +| Monetas +| Informational +| Draft +|- +| [[bip-0083.mediawiki|83]] +| Applications +| Dynamic Hierarchical Deterministic Key Trees +| Eric Lombrozo +| Standard +| Draft +|- +| [[bip-0099.mediawiki|99]] +| Informational +| Motivation and deployment of consensus rule changes ([soft/hard]forks) +| Jorge Timón +| Informational / Process +| Draft +|- | [[bip-0101.mediawiki|101]] | Consensus (hard fork) | Increase maximum block size | Gavin Andresen | Standard | Draft +|- +| [[bip-0102.mediawiki|102]] +| Consensus (hard fork) +| Block size increase to 2MB +| Jeff Garzik +| Standard +| Draft +|- +| [[bip-0103.mediawiki|103]] +| Consensus (hard fork) +| Block size following technological growth +| Pieter Wuille +| Standard +| Draft +|- +| [[bip-0105.mediawiki|105]] +| Consensus (hard fork) +| Consensus based block size retargetting algorithm +| BtcDrak +| Standard +| Draft +|- +| [[bip-0106.mediawiki|106]] +| Consensus (hard fork) +| Dynamically Controlled Bitcoin Block Size Max Cap +| Upal Chakraborty +| Standard +| Draft +|- +| [[bip-0107.mediawiki|107]] +| Consensus (hard fork) +| Dynamic limit on the block size +| Washington Y. Sanchez +| Standard +| Draft +|- +| [[bip-0111.mediawiki|111]] +| Peer Services +| NODE_BLOOM service bit +| Matt Corallo, Peter Todd +| Standard +| Draft +|- +| [[bip-0112.mediawiki|112]] +| Consensus (soft fork) +| CHECKSEQUENCEVERIFY +| BtcDrak, Mark Friedenbach, Eric Lombrozo +| Standard +| Draft +|- +| [[bip-0113.mediawiki|113]] +| Consensus (soft fork) +| Median time-past as endpoint for locktime calculations +| Thomas Kerin, Mark Friedenbach +| Standard +| Draft +|- +| [[bip-0120.mediawiki|120]] +| Applications +| Proof of Payment +| Kalle Rosenbaum +| Standard +| Draft +|- +| [[bip-0121.mediawiki|121]] +| Applications +| Proof of Payment URI scheme +| Kalle Rosenbaum +| Standard +| Draft +|- +| [[bip-0122.mediawiki|122]] +| Applications +| URI scheme for Blockchain references / exploration +| Marco Pontello +| Standard +| Draft +|- +| [[bip-0123.mediawiki|123]] +| Process +| BIP Classification +| Eric Lombrozo +| Standard +| Draft +|- +| [[bip-0124.mediawiki|124]] +| Applications +| Hierarchical Deterministic Script Templates +| Eric Lombrozo, William Swanson +| Standard +| Draft +|- +| [[bip-0125.mediawiki|125]] +| Peer Services +| Opt-in Full Replace-by-Fee Signaling +| David Harding, Peter Todd +| Standard +| Draft +|- +| [[bip-0130.mediawiki|130]] +| Peer Services +| sendheaders message +| Suhas Daftuar +| Standard +| Draft +|- +| [[bip-0131.mediawiki|131]] +| Consensus (hard fork) +| "Coalescing Transaction" Specification (wildcard inputs) +| Chris Priest +| Standard +| Draft +|- +| [[bip-0132.mediawiki|132]] +| Process +| Committee-based BIP Acceptance Process +| Andy Chase +| Process +| Draft +|- +| [[bip-0140.mediawiki|140]] +| Consensus (soft fork) +| Normalized TXID +| Christian Decker +| Standard +| Draft +|- +| [[bip-0141.mediawiki|141]] +| Consensus (soft fork) +| Segregated Witness (Consensus layer) +| Eric Lombrozo, Johnson Lau, Pieter Wuille +| Standard +| Draft +|- +| [[bip-0142.mediawiki|142]] +| Applications +| Address Format for Segregated Witness +| Johnson Lau +| Standard +| Draft +|- +| [[bip-0143.mediawiki|143]] +| Consensus (soft fork) +| Transaction Signature Verification for Version 0 Witness Program +| Johnson Lau, Pieter Wuille +| Standard +| Draft +|- +| [[bip-0144.mediawiki|144]] +| Peer Services +| Segregated Witness (Peer Services) +| Eric Lombrozo, Pieter Wuille +| Standard +| Draft |} diff --git a/bip-0124.mediawiki b/bip-0124.mediawiki new file mode 100644 index 0000000..2f9f4ad --- /dev/null +++ b/bip-0124.mediawiki @@ -0,0 +1,123 @@ +<pre> + BIP: 124 + Title: Hierarchical Deterministic Script Templates + Author: Eric Lombrozo <eric@ciphrex.com> + William Swanson <swansontec@gmail.com> + Status: Draft + Type: Informational + Created: 2015-11-20 + Post-History: http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-November/011795.html +</pre> + +==Abstract== + +This BIP defines a script template format that can be used by wallets to deterministically generate scripts with specific authorization policies using the key derivation mechanism defined in BIP32. + +==Motivation== + +Currently existing wallets typically issue scripts in only a tiny handful of widely used formats. The most popular formats are pay-to-pubkey-hash and m-of-n pay-to-script-hash (BIP16). However, different wallets tend to use mutually incompatible derivation schemes to generate signing keys and construct scripts from them. Moreover, with the advent of hashlocked and timelocked contracts (BIP65, BIP112), it is necessary for different wallets to be able to cooperatively generate even more sophisticated scripts. + +In addition, there's a lot of ongoing work in the development of multilayered protocols that use the blockchain as a settlement layer (i.e. the Lightning Network). These efforts require sufficiently generalized templates to allow for rapidly evolving script designs. + +This BIP provides a generalized format for constructing a script template that guarantees that different wallets will all produce the same scripts for a given set of derivation paths according to BIP32. + +==Specification== + +===Keys=== + +An individual key is determined by a BIP32 derivation path and an index. For convenience, we introduce the following notation: + +'''A'''<sub>k</sub> = (derivation path for A)/k + +===Key Groups=== + +Let '''m'''<sub>i</sub> denote distinct BIP32 derivation paths. We define a key group of n keys as a set of key derivation paths with a free index k: + +{'''K'''<sub>k</sub>} = { '''m'''<sub>1</sub>/k, '''m'''<sub>2</sub>/k, '''m'''<sub>3</sub>/k, ..., '''m'''<sub>n</sub>/k } + +Key groups are useful for constructing scripts that are symmetric in a set of keys. Scripts are symmetric in a set of keys if the semantics of the script is unaffected by permutations of the keys. Key groups enforce a canonical form and can improve privacy. + +===Sorting=== + +We define a lexicographic sorting of the keys. (TODO: specification of sorting conventions - compressed pubkeys, encoding, etc...) + +Define {'''K'''<sub>k</sub>}<sub>j</sub> to be the jth element of the sorted keys for derivation index k. + +===Script Templates=== + +We construct script templates by inserting placeholders for data into a script. To denote a placeholder, we use the following notation: + +''Script''('''A''') = opcodes ['''A'''] opcodes + +We extend this notation to an arbitrary number of placeholders: + +''Script''('''X1''', '''X2''', ..., '''Xn''') = opcodes ['''X1'''] opcodes ['''X2'''] opcodes ... opcodes ['''Xn'''] opcodes + +We introduce the following convenient notation for sorted key groups: + +[{'''K'''<sub>k</sub>}] = [{'''K'''<sub>k</sub>}<sub>1</sub>] [{'''K'''<sub>k</sub>}<sub>2</sub>] ... [{'''K'''<sub>k</sub>}<sub>n</sub>] + +===Operations on Keys=== + +In some applications, we might want to insert the result of some operation performed on a key rather than the key itself into the script. For example, we might want to insert a Hash160 of key '''A'''<sub>k</sub>. We can use the following notation: + +[''Hash160''('''A'''<sub>k</sub>)] + +===Encoding=== + +TODO + +==Examples== + +===2-of-3 Multisig=== + +The script template is defined by: + +''Script''('''X''') = 2 ['''X'''] 3 OP_CHECKMULTISIG + +Letting '''K'''<sub>k</sub> = { '''m'''<sub>1</sub>/k, '''m'''<sub>2</sub>/k, '''m'''<sub>3</sub>/k }, the ''k''th script for this key group is denoted by ''Script''({'''K'''<sub>k</sub>}). + +===1-of-1 or 2-of-3=== + +The script template is defined by: + +''Script''('''A''', '''B''') = <br> + OP_DUP ['''A'''] OP_CHECKSIG<br> + OP_NOTIF<br> + 2 ['''B'''] 3 OP_CHECKMULTISIGVERIFY <br> + OP_NOTIF<br> + OP_ENDIF<br> + OP_TRUE<br> + +Let '''M'''<sub>k</sub> = '''m'''/k be a key of a superuser that can authorize all transactions and {'''K'''<sub>k</sub>} be a key group of three users that can only authorize transactions if at least two of them agree. + +The ''k''th script is given by ''Script''('''M'''<sub>k</sub>, {'''K'''<sub>k</sub>}). + +===Timelocked Contract=== + +The output is payable to Alice immediately if she knows the private key for '''A'''<sub>k</sub>. Bob must know the private key for '''B'''<sub>k</sub> and also wait for a timeout '''t''' before being able to spend the output. + +The script template is defined by: + +''Script''('''A''', '''B''', '''T''') = <br> + OP_IF <br> + OP_DUP OP_HASH160 [''Hash160''('''A''')] OP_EQUALVERIFY OP_CHECKSIG <br> + OP_ELSE <br> + ['''T'''] OP_CHECKLOCKTIMEVERIFY OP_DROP <br> + OP_DUP OP_HASH160 [''Hash160''('''B''')] OP_EQUALVERIFY OP_CHECKSIG <br> + OP_ENDIF + +The ''k''th script with timeout '''t''' is given by ''Script''('''A'''<sub>k</sub>, '''B'''<sub>k</sub>, '''t'''). + +==References== + +* [[bip-0016.mediawiki|BIP16 - Pay to Script Hash]] +* [[bip-0032.mediawiki|BIP32 - Hierarchical Deterministic Wallets]] +* [[bip-0065.mediawiki|BIP65 - OP_CHECKLOCKTIMEVERIFY]] +* [[bip-0112.mediawiki|BIP112 - CHECKSEQUENCEVERIFY]] +* [[https://lightning.network/lightning-network-paper.pdf|Lightning Network Whitepaper]] + +==Copyright== + +This document is placed in the public domain. + diff --git a/bip-0125.mediawiki b/bip-0125.mediawiki new file mode 100644 index 0000000..7d88469 --- /dev/null +++ b/bip-0125.mediawiki @@ -0,0 +1,188 @@ +<pre> + BIP: 125 + Title: Opt-in Full Replace-by-Fee Signaling + Author: David A. Harding <dave@dtrt.org> + Peter Todd <pete@petertodd.org> + Status: Draft + Type: Standards Track + Created: 2015-12-04 +</pre> + +==Abstract== + +Many nodes today will not replace any transaction in their mempool with +another transaction that spends the same inputs, making it difficult for +spenders to adjust their previously-sent transactions to deal with +unexpected confirmation delays or to perform other useful replacements. + +The opt-in full Replace-by-Fee (opt-in full-RBF) signaling policy +described here allows spenders to add a signal to a transaction indicating +that they want to be able to replace that transaction in the future. +In response to this signal, + +* Nodes may allow transactions containing this signal to be replaced in their mempools. + +* The recipient or recipients of a transaction containing this signal may choose not to treat it as payment until it has been confirmed, eliminating the risk that the spender will use allowed replacements to defraud them. + +Nodes and recipients may continue to treat transactions without the +signal the same way they treated them before, preserving the existing +status quo. + +==Summary== + +This policy specifies two ways a transaction can signal that it is +replaceable. + +* '''Explicit signaling:''' A transaction is considered to have opted in to allowing replacement of itself if any of its inputs have an nSequence number less than (0xffffffff - 1). + +* '''Inherited signaling:''' Transactions that don't explicitly signal replaceability are replaceable under this policy for as long as any one of their ancestors signals replaceability and remains unconfirmed. + +===Implementation Details=== + +The initial implementation expected in Bitcoin Core 0.12.0 uses the following rules: + +One or more transactions currently in the mempool (original +transactions) will be replaced by a new transaction (replacement +transaction) that spends one or more of the same inputs if, + +# The original transactions signal replaceability explicitly or through inheritance as described in the above Summary section. + +# The replacement transaction pays an absolute higher fee than the sum paid by the original transactions. + +# The replacement transaction does not contain any new unconfirmed inputs that did not previously appear in the mempool. (Unconfirmed inputs are inputs spending outputs from currently unconfirmed transactions.) + +# The replacement transaction must pay for its own bandwidth in addition to the amount paid by the original transactions at or above the rate set by the node's minimum relay fee setting. For example, if the minimum relay fee is 1 satoshi/byte and the replacement transaction is 500 bytes total, then the replacement must pay a fee at least 500 satoshis higher than the sum of the originals. + +# The number of original transactions to be replaced and their descendant transactions which will be evicted from the mempool must not exceed a total of 100 transactions. + +The initial implementation may be seen in +[https://github.com/bitcoin/bitcoin/pull/6871 Bitcoin Core PR#6871] +and specifically the master branch commits from +5891f870d68d90408aa5ce5b597fb574f2d2cbca to +16a2f93629f75d182871f288f0396afe6cdc8504 (inclusive). + +===Receiving wallet policy=== + +Wallets that display unconfirmed transactions to users or that provide +data about unconfirmed transactions to automated systems should consider +doing one of the following: + +# Conveying additional suspicion about opt-in full-RBF transactions to the user or data consumer. + +# Ignoring the opt-in transaction until it has been confirmed. + +Because descendant transactions may also be replaceable under this +policy through inherited signaling, any method used to process opt-in +full-RBF transactions should be inherited by any descendant transactions +for as long as any ancestor opt-in full-RBF transactions remain +unconfirmed. + +===Spending wallet policy=== + +Wallets that don't want to signal replaceability should use either a max +sequence number (0xffffffff) or a sequence number of (0xffffffff-1) when +then also want to use locktime; all known wallets currently do this. +They should also take care not to spend any unconfirmed transaction that +signals replaceability explicitly or through inherited signaling; most wallets also +currently do this by not spending any unconfirmed transactions except +for those they created themselves. + +Wallets that do want to make replacements should use explicit signaling +and meet the criteria described above in the Implementation Details +section. A +[https://en.bitcoin.it/wiki/Transaction_replacement Bitcoin Wiki page] +has been created to help wallet authors track deployed mempool policies +relating to transaction replacement. + +The initial implementation makes use of P2P protocol reject messages for +rejected replacements, allowing P2P clients to determine whether their +replacements were initially accepted by their peers. Standard P2P +lightweight client practice of sending to some peers while listening for +relays from other peers should allow clients to determine whether the +replacement has propagated. + +==Motivation== + +Satoshi Nakamoto's original Bitcoin implementation provided the +nSequence number field in each input to +[https://github.com/trottier/original-bitcoin/blob/master/src/main.cpp#L434 allow replacement] +of transactions containing that input within the +mempool. When receiving replacements, nodes were supposed to replace +transactions whose inputs had lower sequence numbers with transactions +that had higher sequence numbers. + +In that implementation, replacement transactions did not have to pay +additional fees, so there was no direct incentive for miners to +include the replacement and no built-in rate limiting that prevented +overuse of relay node bandwidth. Nakamoto +[https://github.com/bitcoin/bitcoin/commit/05454818dc7ed92f577a1a1ef6798049f17a52e7#diff-118fcbaaba162ba17933c7893247df3aR522 removed replacement] +from Bitcoin version 0.3.12, leaving only the +comment, "Disable replacement feature for now". + +Replacing transactions with higher-fee transactions provided a way for +spenders to align their desires with miners, but by the time a +Replace-by-Fee (RBF) patch was available to re-enable replacement, some +receivers had begun to expect that the first version of a transaction +they saw was highly likely to be the version of the transaction to be +confirmed, and so some users advocated that replacement should be +disallowed. + +To address those concerns, a variation on RBF was created that +required that the replacement transaction pay all of same outputs as +the original transaction in equal or greater amount. This was called +RBF First Seen Safe (RBF-FSS), and the original RBF became known as +full-RBF. Although agreeable to recipients who relied on the +first-seen version of a transaction, each use of RBF-FSS required +adding an extra input to a transaction, resulting in wallets being +unable to use it if they had no spare inputs, a loss of privacy when +inputs from different origins get used in the same transaction, and a +wasteful increase in transaction byte size. + +Opt-in full-RBF uses Nakamoto's original semantics (with a slight +tweak to allow locktime users to opt-out) to signal that replacement +is possible, providing first-seen users with the ability to ignore +those transactions while also allowing for the efficiency benefits +of full-RBF. + +There are no known problematic interactions between opt-in full-RBF and +other uses of nSequence. Specifically, opt-in full-RBF is compatible +with consensus-enforced locktime as provided in the Bitcoin 0.1 +implementation, draft BIP68 (Relative lock-time using consensus-enforced +sequence numbers), and draft BIP112 (CHECKSEQUENCEVERIFY). + +==Deployment== + +Now, and since Bitcoin's first release, 100% of the network hash rate +mines transactions using opt-in full-RBF semantics (sequence less than +(0xffffffff - 1)). + +Opt-in full-RBF as a default mempool replacement policy among nodes +and miners is expected to become widespread as they upgrade to Bitcoin +Core 0.12.0 (release expected Jan/Feb 2016) and similar node software +such as Bitcoin LJR. + +Actual replacement may be unreliable until two conditions have been satisfied: + +# Enough nodes have upgraded to support it, providing a relay path for replacements to go from spending wallets to miners controlling significant amounts of hash rate. + +# Enough hash rate has upgraded to support replacement, allowing for reasonable probability that a replacement can be mined. + +==Client support== + +No known wallet currently creates transactions by default with +nSequence set below (0xffffffff - 1), so no known existing wallet +explicitly signals replaceability by default. No known popular wallet +spends other users' unconfirmed transactions by default, so no known +existing wallets signals inherited replaceability. + +==See also== + +# [https://en.bitcoin.it/wiki/Transaction_replacement Transaction Replaceability on Bitcoin Wiki] targeted at helping wallet authors use RBF + +# Tools for creating opt-in full-RBF transactions: https://github.com/petertodd/replace-by-fee-tools#replace-by-fee-tools + +# [https://www.reddit.com/r/Bitcoin/comments/3urm8o/optin_rbf_is_misunderstood_ask_questions_about_it/ Reddit: Questions about opt-in RBF] targeted at helping community members understand opt-in full-RBF + +==Copyright== + +This document is placed in the public domain. diff --git a/bip-0131.mediawiki b/bip-0131.mediawiki new file mode 100644 index 0000000..1efe713 --- /dev/null +++ b/bip-0131.mediawiki @@ -0,0 +1,102 @@ +<pre> + BIP: 131 + Title: "Coalescing Transaction" Specification (wildcard inputs) + Author: Chris Priest <cp368202@ohiou.edu> + Status: Draft + Type: Standards Track + Created: 2015-11-30 +</pre> + +==Abstract== + +This specification defines a new type of transaction that supplements (not replaces) +normal "non coalescing" bitcoin transactions. + +==Motivation== + +Normal "non-coalescing" Bitcoin Transactions have one large inefficiency: When you want to spend +from multiple inputs with the exact same scriptPubKey, you have to list each +input separately, along with the same signature multiple times, even though the signature expresses the same information. +This bloats the transaction size and makes it expensive to spend from small value inputs. + +Because small value inputs are expensive to send, they remain in the UTXO pool +which full nodes have to keep around. It is believed that long term increase of the UTXO +set can have negative scaling consequences on the network. + +If maximum blocksize is made to increase *slower* than the actual number of transactions bitcoin users are sending +to the network, this problem is projected to get worse. In other words, as transaction +fees increase, the minimum economical value of a spending a UTXO will increase. + +==Specification== + +=== Redefinition of Transaction version === + +First, this BIP redefines the version field on transactions. The first four bytes +are defined as the version number, while the last four bytes are defined as the +transaction type. Type "0000" denotes normal transactions, and "0001" defines +coalescing transaction. + +Examples: + +version 1 transaction with normal inputs: + version: 10000000 + +version 2 transaction with normal inputs: + version: 20000000 + +version 2 transaction with coalescing inputs: + version: 20000001 + +Essentially the last bit in the version field is set to 1 to enable wildcard inputs for all +inputs present in the transaction. + +=== Wildcard inputs === + +A coalescing transaction is formulated the exact same way as a version 1 transaction +with one exception: each input is treated as a "wildcard input". + +A wildcard input beings the value of all inputs with the exact same scriptPubKey +in a block lower or equal to the block the wildcard input is confirmed into. + +== Changes needed to implement == + +The bitcoin code needs to be modified in three places in order to handle Coalescing Transactions. + +1. <b>Full Node Coalescing validation</b> - When a full node receives a coalescing transaction, it has to +aggregate the value of all the UTXOs in the blockchain older than the input +with the same scriptPubKey. If this value is greater than or equal to the +amount of all outputs, then that coalescing transaction is valid and can be propagated. + +2. <b>Full Node Non-Coalescing validation</b> - When a non-coalescing transaction comes in, the code needs to be modified +to check if each input has not been spent by a coalescing transaction. If there exist any +coalescing transaction in the blockchain with the same scriptPubKey found in a block *after* that input, +then the UTXO has been spent and the transaction is invalid. + +3. <b>Wallet</b> - The user facing wallet portion of the reference client should notify +the user when their wallet contains many UTXOs that qualify it to benefit from +a coalescing transaction. Wallets should not simply replace non-coalescing transactions +with coalescing transactions in all instances. + +== Isn't this BIP bad because it encourage address re-use? == + +Address re-use comes in two forms: re-use by the ''sender'', and re-use by the ''receiver''. + +Re-use by the sender is basically using the same address for the change output. This is generally considered bad +since people looking through your transaction history can determine who you do business with. When +you generate a new address for every change, your privacy is conserved as it is impossible to know which +output is a recipient, and which output is the change output. This BIP has '''no effect''' on re-use +by the sender. + +On the other hand, address re-use by the ''receiver'' occurs under completely different circumstances. +When you publish an address and have multiple people send to that address, you are engaging in address re-use +from the receiver. This activity has historically been considered bad because it leads to re-using a private key. +When you re-use a private key too many times, you run the risk of an attacker performing statistical analysis +on the multiple signatures, which can lead to an attacker finding out your private key. + +This BIP introduces a way to spend multiple inputs ''without'' re-using the private key. In a sense, this BIP +fixes the problem that makes address re-use bad for the receiver. After this BIP becomes implemented +and deployed, address re-use by the receiver will no longer be considered bad form. + +==Copyright== + +This document is placed in the public domain. diff --git a/bip-0132.mediawiki b/bip-0132.mediawiki new file mode 100644 index 0000000..90c09b1 --- /dev/null +++ b/bip-0132.mediawiki @@ -0,0 +1,117 @@ +<pre> + BIP: 132 + Title: Committee-based BIP Acceptance Process + Author: Andy Chase <theandychase@gmail.com> + Status: Draft + Type: Process + Created: 2015-08-31 +</pre> + +== Abstract == + +The current process for accepting a BIP is not clearly defined. While [https://github.com/bitcoin/bips/blob/master/bip-0001.mediawiki BIP-0001] defines the process for writing and submitting a Bitcoin Improvement Proposal to the community it does not specify the precise method for which BIPs are considered accepted or rejected. + +This proposal sets up a method for determining BIP acceptance. + +This BIP has two parts: + +* It sets up a '''process''' which a BIP goes through for comments and acceptance. The Process is: +** BIP Draft +** Submitted for comments (2 weeks) +** Waiting on opinion (2 weeks) +** BIP becomes either Accepted or Deferred +* It sets up '''committees''' for reviewing comments and indicating acceptance under precise conditions. +** Committees are authorized groups that represent client authors, miners, merchants, and users (each as a segment). Each one must represent at least 1% stake in the Bitcoin ecosystem. + +BIP acceptance is defined as at least 70% of the represented percentage stake in 3 out of the 4 Bitcoin segments. + +== Copyright == + +This document is placed into the public domain. + +== Motivation == + +BIPs represent important improvements to Bitcoin infrastructure, and in order to foster continued innovation, the BIP process must have clearly defined stages and acceptance acknowledgement. + +== Rationale == + +A committee system is used to organize the essential concerns of each segment of the Bitcoin ecosystem. Although each segment may have many different viewpoints on each BIP, in order to seek a decisive yes/no on a BIP, a representational authoritative structure is sought. This structure should be fluid, allowing people to move away from committees that do not reflect their views and should be re-validated on each BIP evaluation. + +== Weaknesses == + +Each committee submits a declaration including their claim to represent a certain percentage of the Bitcoin ecosystem in some way. Though guidelines are given, it's up to each committee to prove their stake, and it's up to the reader of the opinions to decide if a BIP was truly accepted or rejected. + +The author doesn't believe this is a problem because a BIP cannot be forced on client authors, miners, merchants, or users. Ultimately this BIP is a tool for determining whether a BIP is overwhelmingly accepted. If one committee's validity claim becomes the factor that decides whether the BIP will succeed or fail, this process simply didn't return a clear answer and the BIP should be considered deferred. + +== Process == + +* '''Submit for Comments.''' The first BIP champion named in the proposal can call a "submit for comments" at any time by posting to the [https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev Dev Mailing List] mailling with the BIP number and a statement that the champion intends to immediately submit the BIP for comments. +** The BIP must have been assigned BIP-number (i.e. been approved by the BIP editor) to be submitted for comments. +* '''Comments.''' +** After a BIP has been submitted for comments, a two-week waiting period begins in which the community should transition from making suggestions about a proposal to publishing their opinions or concerns on the proposal. +* '''Reported Opinions.''' +** After the waiting period has past, committees must submit a summary of the comments which they have received from their represented communities. +** The deadline for this opinion is four weeks after the BIP was submitted for comments. +** Committees cannot reverse their decision after the deadline, but at their request may flag their decision as "likely to change if another submit for comments is called". Committees can change their decision if a resubmit is called. +** Opinions must include: +*** One of the following statements: "Intend to accept", "Intent to implement", "Decline to accept", "Intend to accept, but decline to implement". +*** If rejected, the opinion must cite clear and specific reasons for rejecting including a checklist for what must happen or be change for their committee to accept the proposal. +*** If accepted, the committee must list why they accepted the proposal and also include concerns they have or what about the BIP that, if things changed, would cause the committee to likely reverse their decision if another submit for comments was called. +* '''Accepted.''' +** If at least 70% of the represented percentage stake in 3 out of 4 segments accept a proposal, the BIP is considered accepted. +** If a committee fails to submit an opinion, consider the opinion "Decline to accept". +** The BIP cannot be substantially changed at this point, but can be replaced. Minor changes or clarifications are allowed but must be recorded in the document. +* '''Deferred.''' +** If the acceptance test above is not met, the BIP is sent back into suggestions. +** BIP can be modified and re-submitted for a comments no sooner than two months after the date of the previous submit for comments is called. +** The BIP is marked rejected after two failed submission attempts. A rejected BIP can still be modified and re-submitted. + +== Committees == + +'''BIP Committees.''' + +* BIP Committees are representational structures that represent critical segments of the Bitcoin ecosystem. +* Each committee must prove and maintain a clear claim that they represent at least 1% of the Bitcoin ecosystem in some form. +* If an organization or community does not meet that requirement, it should conglomerate itself with other communities and organizations so that it does. +* The segments that committees can be based around are: +** Bitcoin software +** Exchanges/Merchants/services/payment processors +** Mining operators +** User communities +* A person may be represented by any number of segments, but a committee cannot re-use the same resource as another committee in the same segment. + +'''Committee Declarations.''' +* At any point, a Committee Declaration can be posted. +* This Declaration must contain details about: +** The segment the Committee is representing +** Who the committee claim to represent and it's compositional makeup (if made up of multiple miner orgs, user orgs, companies, clients, etc). +** Proof of claim and minimum 1% stake via: +*** Software: proof of ownership and user base (Min 1% of Bitcoin userbase) +*** Merchant: proof of economic activity (Min 1% of Bitcoin economic activity) +*** Mining: proof of work (Min 1% of Hashpower) +*** For a user organization, auditable signatures qualifies for a valid committee (Min 1% of Bitcoin userbase) +** Who is running the committee, their names and roles +** How represented members can submit comments to the committee +** A code of conduct and code of ethics which the committee promises to abide by +* A committee declaration is accepted if: +** The declaration includes all of the required elements +** The stake is considered valid +** Committee validation is considered when considering the results of opinions submitted by committee on a BIP. A committee must have met the required stake percentage before a BIP is submitted for comments, and have maintained that stake until a valid opinion is submitted. +* Committees can dissolve at any time or submit a declaration at any time +* Declaration must have been submitted no later than the third day following a BIP's request for comments to be eligible for inclusion in a BIP + +== BIP Process Management Role == + +BIPs, Opinions, and Committee Declaration must be public at all times. + +A BIP Process Manager should be chosen who is in charge of: + +* Declaring where and how BIPs, Opinions, and Committee Declaration should be posted and updated officially. +* Maintaining the security and authenticity of BIPs, Opinions, and Committee Declarations +* Publishing advisory documents about what kinds of proof of stakes are valid and what kinds should be rejected. +* Naming a series of successors for the roles of the BIP Process Manager and BIP Editor (BIP-001) as needed. + +== Conditions for activation == + +In order for this process BIP to become active, it must succeed by its own rules. At least a 4% sample of the Bitcoin community must be represented, with at least one committee in each segment included. Once at least one committee has submitted a declaration, a request for comments will be called and the process should be completed from there. + diff --git a/bip-0133.mediawiki b/bip-0133.mediawiki new file mode 100644 index 0000000..7d98f87 --- /dev/null +++ b/bip-0133.mediawiki @@ -0,0 +1,48 @@ +<pre> + BIP: 133 + Title: feefilter message + Author: Alex Morcos <morcos@chaincode.com> + Status: Draft + Type: Standards Track + Created: 2016-02-13 +</pre> + +==Abstract== + +Add a new message, "feefilter", which serves to instruct peers not to send "inv"'s to the node for transactions with fees below the specified fee rate. + +==Motivation== + +The concept of a limited mempool was introduced in Bitcoin Core 0.12 to provide protection against attacks or spam transactions of low fees that are not being mined. A reject filter was also introduced to help prevent repeated requests for the same transaction that might have been recently rejected for insufficient fee. These methods help keep resource utilization on a node from getting out of control. + +However, there are limitations to the effectiveness of these approaches. The reject filter is reset after every block which means transactions that are inv'ed over a longer time period will be rerequested and there is no method to prevent requesting the transaction the first time. Furthermore, inv data is sent at least once either to or from each peer for every transaction accepted to the mempool and there is no mechanism by which to know that an inv sent to a given peer would not result in a getdata request because it represents a transaction with too little fee. + +After receiving a feefilter message, a node can know before sending an inv that a given transaction's fee rate is below the minimum currently required by a given peer, and therefore the node can skip relaying an inv for that transaction to that peer. + +==Specification== + +# The feefilter message is defined as a message containing an int64_t where pchCommand == "feefilter" +# Upon receipt of a "feefilter" message, the node will be permitted, but not required, to filter transaction invs for transactions that fall below the feerate provided in the feefilter message interpreted as satoshis per kilobyte. +# The fee filter is additive with a bloom filter for transactions so if an SPV client were to load a bloom filter and send a feefilter message, transactions would only be relayed if they passed both filters. +# Inv's generated from a mempool message are also subject to a fee filter if it exists. +# Feature discovery is enabled by checking protocol version >= 70013 + +==Considerations== +The propagation efficiency of transactions across the network should not be adversely affected by this change. In general, transactions which are not accepted to a node's mempool are not relayed by this node and the functionality implemented with this message is meant only to filter those transactions. There could be a small number of edge cases where a node's mempool min fee is actually less than the filter value a peer is aware of and transactions with fee rates between these values will now be newly inhibited. + +Feefilter messages are not sent to whitelisted peers if the "-whitelistforcerelay" option is set. In that case, transactions are intended to be relayed even if they are not accepted to the mempool. + +There are privacy concerns with deanonymizing a node by the fact that it is broadcasting identifying information about its mempool min fee. To help ameliorate this concern, the implementation quantizes the filter value broadcast with a small amount of randomness, in addition, the messages are broadcast to different peers at individually randomly distributed times. + +If a node is using prioritisetransaction to accept transactions whose actual fee rates might fall below the node's mempool min fee, it may want to consider disabling the fee filter to make sure it is exposed to all possible txid's. + +==Backward compatibility== + +Older clients remain fully compatible and interoperable after this change. Also, clients implementing this BIP can choose to not send any feefilter messages. + +==Implementation== + +https://github.com/bitcoin/bitcoin/pull/7542 + +==Copyright== +This document is placed in the public domain. diff --git a/bip-0140.mediawiki b/bip-0140.mediawiki new file mode 100644 index 0000000..b187a49 --- /dev/null +++ b/bip-0140.mediawiki @@ -0,0 +1,113 @@ +<pre> + BIP: 140 + Title: Normalized TXID + Author: Christian Decker <decker.christian@gmail.com> + Status: Draft + Type: Standards Track + Created: 2015-10-14 +</pre> +== Abstract == + +This BIP describes the use of normalized transaction IDs (NTXIDs) in order to eliminate transaction malleability, both in the third-party modification scenario as well as the participant modification scenario. The transaction ID is normalized by removing the signature scripts from transactions before computing its hash. The normalized transaction hashes are then used during the signature creation and signature verification of dependent transactions. + +== Motivation == + +Transaction malleability refers to the fact that transactions can be modified, either by one of the signers by re-signing the transaction or a third-party by modifying the signature representation. This is a problem since any modification to the serialized representation also changes the hash of the transaction, which is used by spending transaction to reference the funds that are being transferred. If a transaction is modified and later confirmed by ending up in the blockchain all transactions that depended on the original transaction are no longer valid, and thus orphaned. + +BIPs 62<ref>[[https://github.com/bitcoin/bips/blob/master/bip-0062.mediawiki|BIP 62 - Dealing with malleability]]</ref> and 66<ref>[[https://github.com/bitcoin/bips/blob/master/bip-0066.mediawiki|BIP 66 - Strict DER signatures]]</ref> alleviate the problem of third-party modification by defining a canonical representation of the signatures. However, checking the canonical representation is complex and may not eliminate all sources of third-party malleability. Furthermore, these BIPs do not address modifications by one of the signers, i.e., re-signing the transaction, because signers can produce any number of signatures due to the random parameter in ECDSA. + +This proposal eliminates malleability by removing the malleable signatures from the hash used to reference the outputs spent by a transaction. The new hash used to reference an output is called the ''normalized transaction ID''. The integrity of all data that is used to reference the output is guaranteed by the signature itself, and any modification that would change the normalized transaction ID would also invalidate the signature itself. + +Besides eliminating transaction malleability as a source of problems it also allows the use of transaction templates. Transaction templates simplify higher level protocols and allows new uses. They allow an unsigned template transaction to be used as a basis for a sequence of transaction and only once the sequence matches the signers' expectations they provide the necessary signatures for the template to become valid, thus opting in to the sequence. + +== Specification == + +The use of normalized transaction IDs is introduced as a softfork. The specification is divided into three parts: + +* Computation of the normalized transaction ID +* Introduction of a new extensible signature verification opcode to enable softfork deployment +* Changes to the UTXO tracking to enable normalized transaction ID lookup + +=== Normalized Transaction ID computation === + +In order to calculate the normalized transaction ID, the signature script is stripped from each input of the transaction of non-coinbase transactions and each input is normalized. Stripping the signature script is achieved by setting the script's length to 0 and removing the <code>uchar[]</code> array from the <code>TxIn</code>.<ref>[[https://en.bitcoin.it/wiki/Protocol_Specification#tx|Protocol Specification: TX]]</ref> +Inputs are then normalized by replacing the hash of each previous transaction with its normalized version if available, i.e., the normalized hash of the previous transaction that created the output being spent in the current transaction. Version 1 transactions do not have a normalized transaction ID hence the non-normalized transaction ID is used for input normalization. + +The normalized transaction ID is then computed as the double <code>SHA 256</code> hash of the normalized transaction matching the existing transaction ID computation. The normalized transaction ID remains unchanged even if the signatures of the transaction are replaced/malleated and describe a class of semantically identical transactions. In the following we use ''transaction instance ID'' to refer to the transaction ID computed on the transaction including signatures. Normalized transaction IDs for coinbase transactions are computed with the signature script in the coinbase input, in order to avoid hash collisions. + +=== OP_CHECKSIGEX === +This BIP introduces a new opcode <code>OP_CHECKSIGEX</code> which replaces <code>OP_NOP4</code>. <code>OP_CHECKSIGEX</code> subsumes <code>OP_CHECKSIGVERIFY</code> and <code>OP_CHECKMULTISIGVERIFY</code>, and extends them by accepting a new <code>VERSION</code> parameter. The version parameter is a single integer pushed onto the stack before invoking <code>OP_CHECKSIGEX</code> and is used to group and evolve future versions of signature checking opcodes. + +When executed <code>OP_CHECKSIGEX</code> pops the version from the stack and then performs the signature check according to the specified version. If the verifying client does not support the specified version, i.e., the version was defined after the release of the client, the client must treat the <code>OP_CHECKSIGEX</code> as an <code>OP_NOP</code>. + +==== Version 1 ==== + +The first version of <code>OP_CHECKSIGEX</code> (<code>VERSION=1</code>) implements normalized transaction IDs and uses Schnorr signatures instead of the current ECDSA signatures. + +Version 1 introduces the following new standard script format: + + m {pubkey}...{pubkey} n v OP_CHECKSIGEX + +with matching scriptSig format: + + {signature}...{signature} + +This is the standard ''m-of-n'' script defined in [https://github.com/bitcoin/bips/blob/master/bip-0011.mediawiki BIP 11] with an additional version parameter <code>v</code> and the new opcode. Singlesig transactions are encoded as ''1-of-1'' transactions. + +The existing <code>OP_CHECKMULTISIG</code> and <code>OP_CHECKMULTISIGVERIFY</code> have a bug<ref>[[https://bitcoin.org/en/developer-guide#multisig|Developer Documentation - Multisig]]</ref> that pops one argument too many from the stack. This bug is not reproduced in the implementation of OP_CHECKSIGEX, so the canonical solution of pushing a dummy value onto the stack is not necessary. + +The normalization is achieved by normalizing the transaction before computing the signaturehash, i.e., the hash that is signed. +The transaction must be normalized by replacing all transaction IDs in the inputs by their normalized variants and stripping the signature scripts. The normalized transction IDs are computed as described in the previous section. This normalization step is performed both when creating the signatures as well as when checking the signatures. + +=== Tracking Normalized Transaction IDs === + +The transaction version is bumped to 2. The new version signals to clients receiving the transaction that they should track the normalized transaction ID along with the transaction instance ID in the unspent transaction output (UTXO) set. Upon receiving a version 2 transaction the client computes the normalized transaction ID, annotates the outputs with it, and adds them into the UTXO set indexed by the transaction instance ID as before. Transactions continue using the transaction instance ID to reference the outputs, but while checking the signature they may get normalized. All network messages continue to use the transaction instance ID to reference the transaction, specifically <code>inv</code>, <code>getdata</code>, <code>tx</code> and <code>block</code> messages still use transaction instance IDs, not the normalized transaction IDs. + +Outputs created by version 1 transactions are not annotated with the normalized transaction ID, and when normalizing the hashes in transaction inputs referencing version 1 outputs are not modified. + +== Rationale == + +=== Normalization === +Normalized transaction IDs are provably non-malleable since no data is included in the signaturehash whose integrity is not also proven in the signature, thus any modification causing the hash to change will also invalidate the signature. +Normalized transactions are secure as they still use cryptographic hashes over all the semantic information of the transaction, i.e., the inputs, outputs and metadata, thus it is still computationally infeasible to cause a hash collision between transactions. + +There are a number of advantages to using normalized transaction IDs: + +* Like BIP 62 and BIP 66 it solves the problem of third-parties picking transactions out of the network, modifying them and reinjecting them. +* ''m-of-n'' multisig outputs are often used in higher level protocols<ref>[[http://www.tik.ee.ethz.ch/file/716b955c130e6c703fac336ea17b1670/duplex-micropayment-channels.pdf|A Fast and Scalable Payment Network with Bitcoin Duplex Micropayment Channels ]]</ref><ref>[[http://lightning.network/lightning-network-paper.pdf|The Bitcoin Lightning Network: +Scalable Off-Chain Instant Payments]]</ref> in which several parties sign a transaction. Without normalized transaction IDs it is trivial for one party to re-sign a transaction, hence changing the transaction hash and invalidating any transaction built on top of its outputs. Normalized transaction IDs force the ID not to change, even if a party replaces its signature. +* Many higher level protocols build structures of transactions on top of multisig outputs that are not completely signed. This is currently not possible without one party holding a fully signed transaction and then calculating the ID. It is desirable to be able to build successive transactions without one party collecting all signatures, and thus possibly lock in funds unilaterally. Normalized transaction IDs allow the use of transaction templates, i.e., completely unsigned transactions upon which further transactions can be built, and only once every party is assured the structure matches its expectations it signs the template, thus validating the template. + +The only occurence in which transactions can still be modified unilaterally is in the case <code>SIGHASH_NONE</code>, <code>SIGHASH_SINGLE</code> or <code>SIGHASH_ANYONECANPAY</code> is used. This however is not problematic since in these cases the creator of the transaction explicitly allows modification. + +In case of a transaction becoming invalid due to one of the inputs being malleated it is necessary to modify the spending transaction to reference the modified transaction ID. However, the signatures, which only use the normalized IDs, remain valid as long as the semantics of the funding transaction remain unchanged. An observer in the network may fix the transaction and reinject a corrected version. + +Using version 2 for transactions is an explicit opt-in to the normalized ID tracking and a simple upgrade for existing clients. It avoids having to reprocess the entire blockchain and computing the normalized transaction IDs for existing outputs in the UTXO. This would be further complicated by having to recursively compute normalized transaction IDs down to the coinbase transactions which created the coins. + +Tracking the normalized transaction IDs in the UTXO requires the storage of an additional hash per transaction whose outputs are not completely spent, which at 7,000,000 transactions with unspent outputs amounts to 224MB additional storage on disk. + +The coinbase transactions have been checked for hash-collisions and no collisions were found except for the coinbase transactions in blocks at heights 91842 and 91880, which are known to be identical<ref>[[https://github.com/bitcoin/bips/blob/master/bip-0030.mediawiki|BIP 30 - Duplicate transactions]]</ref>, and motivated the introduction of BIP 34.<ref>[[https://github.com/bitcoin/bips/blob/master/bip-0034.mediawiki|Block v2, Height in Coinbase]]</ref> Since coinbase transactions are invalid if transmitted outside of a block it is not possible to modify them on the fly and since they only mature after being included for a long time in the blockchain they are considered safe. + +=== OP_CHECKSIGEX === + +The new opcode <code>OP_CHECKSIGEX</code> was introduced in order to allow the use of normalized transaction IDs as a softfork and in order to keep the number of <code>OP_NOP</code>s needed to a bare minimum, while enabling future soft-fork updates to the signing algorithms. + +The additional argument containing the version can be pushed on the stack using a single byte up to version 16 (<code>OP_1</code> - <code>OP_16</code>), resulting in one byte overhead for this script type. Using the standard multisig format also for 1-of-1 transactions add an additional 2 bytes, however it also removes the bug requiring a dummy push, resulting in a single byte overhead. +Furthermore, using Schnorr signatures instead of ECDSA brings a number of improvements that reduce the size of transactions (''m-of-m'' is the same size as ''1-of-1'') and increase verification speed (batch signature validation by summing up keys and signatures). The code is already in bitcoin/secp256k1 and can be merged in. We limited the description of this BIP to re-using BIP 11 style ''m-of-n'' scripts to keep it short, however Schnorr also allows a number of more complex applications which we defer to future BIPs. + +Version 0 was intentionally skipped in order to guarantee that the top-most element before <code>OP_CHECKSIGEX</code> is non-zero. This is necessary to guarantee that non-upgraded clients, which interpret <code>OP_CHECKSIGEX</code> as <code>OP_NOP4</code>, do not end up with a zero value on top of the stack after execution, which would be interpreted as script failure. + +=== Impact === + +This is a softfork which replaces <code>OP_NOP4</code> with the new implementation of <code>OP_CHECKSIGEX</code>, as such the impact on the network is minimal. Wallets that do not implement this opcode will not be able to verify the validity of the scripts, however if transactions using <code>OP_CHECKSIGEX</code> are included in blocks they will accept them and track the inputs correctly. This is guaranteed since the transaction inputs still use the non-normalized transaction ID to reference the outputs to be claimed, hence non-upgraded wallets can still lookup the outputs and mark them as spent. Furthermore, clients that do not implement this BIP are unable to identify outputs using this script as their own, however upgrading and rescanning the blockchain will make them available. + +== See also == + +* [[bip-0062.mediawiki|BIP 62: Dealing with malleability]] +* [[bip-0066.mediawiki|BIP 66: Strict DER Signatures]] + +== References == +<references> + +==Copyright== +This document is placed in the public domain.
\ No newline at end of file diff --git a/bip-0141.mediawiki b/bip-0141.mediawiki new file mode 100644 index 0000000..a73cf35 --- /dev/null +++ b/bip-0141.mediawiki @@ -0,0 +1,288 @@ +<pre> + BIP: 141 + Title: Segregated Witness (Consensus layer) + Author: Eric Lombrozo <elombrozo@gmail.com> + Johnson Lau <jl2012@xbt.hk> + Pieter Wuille <pieter.wuille@gmail.com> + Status: Draft + Type: Standards Track + Created: 2015-12-21 +</pre> + +==Abstract== + +This BIP defines a new structure called a "witness" that is committed to blocks separately from the transaction merkle tree. This structure contains data required to check transaction validity but not required to determine transaction effects. In particular, scripts and signatures are moved into this new structure. + +The witness is committed in a tree that is nested into the block's existing merkle root via the coinbase transaction for the purpose of making this BIP soft fork compatible. A future hard fork can place this tree in its own branch. + +==Motivation== + +The entirety of the transaction's effects are determined by output consumption (spends) and new output creation. Other transaction data, and signatures in particular, are only required to validate the blockchain state, not to determine it. + +By removing this data from the transaction structure committed to the transaction merkle tree, several problems are fixed: + +# '''Nonintentional malleability becomes impossible'''. Since signature data is no longer part of the transaction hash, changes to how the transaction was signed are no longer relevant to transaction identification. As a solution of transaction malleability, this is superior to the canonical signature approach ([https://github.com/bitcoin/bips/blob/master/bip-0062.mediawiki BIP62]): +#* It prevents involuntary transaction malleability for any type of scripts, as long as all inputs are signed (with at least one CHECKSIG or CHECKMULTISIG operation) +#* In the case of an m-of-n CHECKMULTISIG script, a transaction is malleable only with agreement of m private key holders (as opposed to only 1 private key holder with BIP62) +#* It prevents involuntary transaction malleability due to unknown ECDSA signature malleability +#* It allows creation of unconfirmed transaction dependency chains without counterparty risk, an important feature for offchain protocols such as the Lightning Network +# '''Transmission of signature data becomes optional'''. It is needed only if a peer is trying to validate a transaction instead of just checking its existence. This reduces the size of SPV proofs and potentially improves the privacy of SPV clients as they can download more transactions using the same bandwidth. +# '''Some constraints could be bypassed with a soft fork''' by moving part of the transaction data to a structure unknown to current protocol, for example: +#* Size of witness could be ignored / discounted when calculating the block size, effectively increasing the block size to some extent +#* Hard coded constants, such as maximum data push size (520 bytes) or sigops limit could be reevaluated or removed +#* New script system could be introduced without any limitation from the existing script semantic. For example, a new transaction digest algorithm for transaction signature verification is described in [https://github.com/bitcoin/bips/blob/master/bip-0143.mediawiki BIP143] + +==Specification== + +=== Transaction ID === + +A new data structure, <code>witness</code>, is defined. Each transaction will have 2 IDs. + +Definition of <code>txid</code> remains unchanged: the double SHA256 of the traditional serialization format: + + [nVersion][txins][txouts][nLockTime] + +A new <code>wtxid</code> is defined: the double SHA256 of the new serialization with witness data: + + [nVersion][marker][flag][txins][txouts][witness][nLockTime] + +Format of <code>nVersion</code>, <code>txins</code>, <code>txouts</code>, and <code>nLockTime</code> are same as traditional serialization. + +The <code>marker</code> MUST be <code>0x00</code>. + +The <code>flag</code> MUST be a 1-byte non-zero value. Currently, <code>0x01</code> MUST be used. + +The <code>witness</code> is a serialization of all witness data of the transaction. Each txin is associated with a witness field. A witness field starts with a <code>var_int</code> to indicate the number of stack items for the txin. It is followed by stack items, with each item starts with a <code>var_int</code> to indicate the length. Witness data is NOT script. + +A non-witness program (defined hereinafter) txin MUST be associated with an empty witness field, represented by a <code>0x00</code>. If all txins are not witness program, a transaction's <code>wtxid</code> is equal to its <code>txid</code>. + +=== Commitment structure === + +A new block rule is added which requires a commitment to the <code>wtxid</code>. The <code>wtxid</code> of coinbase transaction is assumed to be <code>0x0000....0000</code>. + +A witness root hash is calculated with all those <code>wtxid</code> as leaves, in a way similar to the hashMerkleRoot in the block header. + +The commitment is recorded in a scriptPubKey of the coinbase transaction. It must be at least 38 bytes, with the first 6-byte of <code>0x6a24aa21a9ed</code>, that is: + + 1-byte - OP_RETURN (0x6a) + 1-byte - Push the following 36 bytes (0x24) + 4-byte - Commitment header (0xaa21a9ed) + 32-byte - Commitment hash: Double-SHA256(witness root hash|witness nonce) + + 39th byte onwards: Optional data with no consensus meaning + +and the coinbase's input's witness must consist of a single 32-byte array for the witness nonce. + +If there are more than one scriptPubKey matching the pattern, the one with highest output index is assumed to be the commitment. + +=== Witness program === + +A scriptPubKey (or redeemScript as defined in BIP16/P2SH) that consists of a 1-byte push opcode (for 0 to 16) followed by a data push between 2 and 32 bytes gets a new special meaning. The value of the first push is called the "version byte". The following byte vector pushed is called the "witness program". + +There are two cases in which witness validation logic are triggered. Each case determines the location of the witness version byte and program, as well as the form of the scriptSig: +# Triggered by a scriptPubKey that is exactly a push of a version byte, plus a push of a witness program. The scriptSig must be exactly empty. +# Triggered when a scriptPubKey is a P2SH script, and the BIP16 redeemScript pushed in the scriptSig is exactly a push of a version byte plus a push of a witness program. The scriptSig must be exactly a push of the BIP16 redeemScript. + +If the version byte is 0, and the witness program is 20 bytes: +* It is interpreted as a pay-to-witness-public-key-hash (P2WPKH) program. +* The witness must consist of exactly 2 items (≤ 520 bytes each). The first one a signature, and the second one a public key. +* The HASH160 of the public key must match the 20-byte witness program. +* After normal script evaluation, the signature is verified against the public key with CHECKSIG operation. The verification must result in a single TRUE on the stack. + +If the version byte is 0, and the witness program is 32 bytes: +* It is interpreted as a pay-to-witness-script-hash (P2WSH) program. +* The witness must consist of an input stack to feed to the script, followed by a serialized script ("witnessScript"). +* The witnessScript (≤ 10,000 bytes) is popped off the initial witness stack. SHA256 of the witnessScript must match the 32-byte witness program. +* The witnessScript is deserialized, and executed after normal script evaluation with the remaining witness stack (≤ 520 bytes for each stack item). +* The script must not fail, and result in exactly a single TRUE on the stack. + +If the version byte is 0, but the witness program is neither 20 nor 32 bytes, the script must fail. + +If the version byte is 1 to 16, no further interpretation of the witness program or witness happens, and there is no size restriction for the witness. These versions are reserved for future extensions. + +=== Other consensus critical limits === + +==== Block size ==== + +Blocks are currently limited to 1,000,000 bytes (1MB) total size. We change this restriction as follows: + +''Block cost'' is defined. The cost of each byte in the existing header and transactions is 4, while the cost of each byte in witness data is 1. + +The new rule is total ''block cost'' ≤ 4,000,000. + +==== Sigops ==== + +Sigops per block is currently limited to 20,000. We change this restriction as follows: + +''Sigop cost'' is defined. The cost of a sigop in traditional script is 4, while the cost of a sigop in witness program is 1. + +The new rule is total ''sigop cost'' ≤ 80,000. + +== Examples == + +=== P2WPKH witness program === + +The following example is a version 0 pay-to-witness-public-key-hash (P2WPKH) witness program: + + witness: <signature> <pubkey> + scriptSig: (empty) + scriptPubKey: 0 <20-byte-hash> + (0x0014{20-byte-hash}) + +The '0' in scriptPubKey indicates the following push is a version 0 witness program. The length of the witness program indicates that it is a P2WPKH type. The witness must consist of exactly 2 items. The HASH160 of the pubkey in witness must match the witness program. + +The signature is verified as + + <signature> <pubkey> CHECKSIG + +Comparing with a traditional P2PKH output, the P2WPKH equivalent occupies 3 less bytes in the scriptPubKey, and moves the signature and public key from scriptSig to witness. + +=== P2WSH witness program === + +The following example is an 1-of-2 multi-signature version 0 pay-to-witness-script-hash (P2WSH) witness program. + + witness: 0 <signature1> <1 <pubkey1> <pubkey2> 2 CHECKMULTISIG> + scriptSig: (empty) + scriptPubKey: 0 <32-byte-hash> + (0x0020{32-byte-hash}) + +The '0' in scriptPubKey indicates the following push is a version 0 witness program. The length of the witness program indicates that it is a P2WSH type. The last item in the witness (the "witnessScript") is popped off, hashed with SHA256, compared against the 32-byte-hash in scriptPubKey, and deserialized: + + 1 <pubkey1> <pubkey2> 2 CHECKMULTISIG + +The script is executed with the remaining data from witness: + + 0 <signature1> 1 <pubkey1> <pubkey2> 2 CHECKMULTISIG + +A P2WSH witness program allows arbitrarily large script as the 520-byte push limit is bypassed. + +The scriptPubKey occupies 34 bytes, as opposed to 23 bytes of BIP16 P2SH. The increased size improves security against possible collision attacks, as 2<sup>80</sup> work is not infeasible anymore (By the end of 2015, 2<sup>84</sup> hashes have been calculated in Bitcoin mining since the creation of Bitcoin). The spending script is same as the one for an equivalent BIP16 P2SH output but is moved to witness. + +=== Witness program nested in BIP16 P2SH === + +The following example is the same 1-of-2 multi-signature P2WSH witness program, but nested in a BIP16 P2SH output. + + witness: 0 <signature1> <1 <pubkey1> <pubkey2> 2 CHECKMULTISIG> + scriptSig: <0 <32-byte-hash>> + (0x0020{32-byte-hash}) + scriptPubKey: HASH160 <20-byte-hash> EQUAL + (0xA914{20-byte-hash}87) + +The only item in scriptSig is hashed with HASH160, compared against the 20-byte-hash in scriptPubKey, and interpreted as: + + 0 <32-byte-hash> + +The P2WSH witness program is then executed as described in the previous example. + +Comparing with the previous example, the scriptPubKey is 11 bytes smaller (with reduced security) while witness is the same. However, it also requires 35 bytes in scriptSig, which is not prunable in transmission. Although a nested witness program is less efficient in many ways, its payment address is fully transparent and backward compatible for all Bitcoin reference client since version 0.6.0. + +=== Extensible commitment structure === + +The new commitment in coinbase transaction is a hash of the witness root hash and a witness nonce. The nonce currently has no consensus meaning, but in the future allows new commitment values for future softforks. For example, if a new consensus-critical commitment is required in the future, the commitment in +coinbase becomes: + + Double-SHA256(Witness root hash|Hash(new commitment|witness nonce)) + +For backward compatibility, the Hash(new commitment|witness nonce) will go to the coinbase witness, and the witness nonce will be recorded in another location specified by the future softfork. Any number of new commitment could be added in this way. + +Any commitments that are not consensus-critical to Bitcoin, such as merge-mining, MUST NOT use the witness nonce to preserve the ability to do upgrades of the Bitcoin consensus protocol. + +The optional data space following the commitment also leaves room for metadata of future softforks, and MUST NOT be used for other purpose. + +=== Trust-free unconfirmed transaction dependency chain === + +Segregated witness fixes the problem of transaction malleability fundamentally, which enables the building of unconfirmed transaction dependency chains in a trust-free manner. + +Two parties, Alice and Bob, may agree to send certain amount of Bitcoin to a 2-of-2 multisig output (the "funding transaction"). Without signing the funding transaction, they may create another transaction, time-locked in the future, spending the 2-of-2 multisig output to third account(s) (the "spending transaction"). Alice and Bob will sign the spending transaction and exchange the signatures. After examining the signatures, they will sign and commit the funding transaction to the blockchain. Without further action, the spending transaction will be confirmed after the lock-time and release the funding according to the original contract. It also retains the flexibility of revoking the original contract before the lock-time, by another spending transaction with shorter lock-time, but only with mutual-agreement of both parties. + +Such setups is not possible with BIP62 as the malleability fix, since the spending transaction could not be created without both parties first signing the funding transaction. If Alice reveals the funding transaction signature before Bob does, Bob is able to lock up the funding indefinitely without ever signing the spending transaction. + +Unconfirmed transaction dependency chain is a fundamental building block of more sophisticated payment networks, such as duplex micropayment channel and the Lightning Network, which have the potential to greatly improve the scalability and efficiency of the Bitcoin system. + +== Future extensions == + +=== Compact fraud proof for SPV nodes === + +Bitcoin right now only has two real security models. A user either runs a full-node which validates every block with all rules in the system, or a SPV (Simple Payment Verification) client which only validates the headers as a proof of publication of some transactions. The Bitcoin whitepaper suggested that SPV nodes may accept alerts from full nodes when they detect an invalid block, prompting the SPV node to download the questioned blocks and transactions for validation. This approach, however, could become a DoS attack vector as there is virtually no cost to generate a false alarm. An alarm must come with a compact, yet deterministic fraud proof. + +In the current Bitcoin protocol, it is possible to generate compact fraud proof for almost all rules except a few: + +# It is not possible to prove a miner has introduced too many Bitcoins in the coinbase transaction outputs without showing the whole block itself and all input transactions. +# It is not possible to prove the violation of any block specific constraints, such as size and sigop limits, without showing the whole block (and all input transactions in the case of sigop limit) +# It is not possible to prove the spending of a non-existing input without showing all transaction IDs in the blockchain way back to the genesis block. + +Extra witness data can be committed that allows short proofs of block invalidity that SPV nodes can quickly verify: + +# Sum trees for transaction fee can be committed making it possible to construct short proofs that the miner does not add excessive fees to the coinbase transaction. Similar for the block size and sigop count limit. +# Backlinks for the outputs spent by the transaction's inputs can be provided. These backlinks consist of a block hash and an offset that thin clients can easily query and check to verify that the outputs exist. + +These commitments could be included in the extensible commitment structure through a soft fork and will be transparent to nodes that do not understand such new rules. + +=== New script system === + +Since a version byte is pushed before a witness program, and programs with unknown versions are always considered as anyone-can-spend script, it is possible to introduce any new script system with a soft fork. The witness as a structure is not restricted by any existing script semantics and constraints, the 520-byte push limit in particular, and therefore allows arbitrarily large scripts and signatures. + +Examples of new script system include Schnorr signatures which reduce the size of multisig transactions dramatically, Lamport signature which is quantum computing resistance, and Merklized abstract syntax trees which allow very compact witness for conditional scripts with extreme complexity. + +The 32-byte limitation for witness program could be easily extended through a soft fork in case a stronger hash function is needed in the future. The version byte is also expandable through a softfork. + +=== Per-input lock-time and relative-lock-time === + +Currently there is only one nLockTime field in a transaction and all inputs must share the same value. [https://github.com/bitcoin/bips/blob/master/bip-0068.mediawiki BIP68] enables per-input relative-lock-time using the nSequence field, however, with a limited lock-time period and resolution. + +With a soft fork, it is possible to introduce a separate witness structure to allow per-input lock-time and relative-lock-time, and a new script system that could sign and manipulate the new data (like [https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki BIP65] and [https://github.com/bitcoin/bips/blob/master/bip-0112.mediawiki BIP112]). + +== Backward compatibility == + +As a soft fork, older software will continue to operate without modification. Non-upgraded nodes, however, will not see nor validate the witness data and will consider all witness programs as anyone-can-spend scripts (except a few edge cases where the witness programs are equal to 0, which the script must fail). Wallets should always be wary of anyone-can-spend scripts and treat them with suspicion. Non-upgraded nodes are strongly encouraged to upgrade in order to take advantage of the new features. + +'''What a non-upgraded wallet can do''' + +* Receiving bitcoin from non-upgraded and upgraded wallets +* Sending bitcoin to non-upgraded and upgraded wallets with traditional P2PKH address (without any benefit of segregated witness) +* Sending bitcoin to upgraded wallets using a P2SH address +* Sending bitcoin to upgraded wallets using a native witness program through [https://github.com/bitcoin/bips/blob/master/bip-0070.mediawiki BIP70] payment protocol + +'''What a non-upgraded wallet cannot do''' + +* Validating segregated witness transaction. It assumes such a transaction is always valid + +== Deployment == + +We reuse the double-threshold IsSuperMajority() switchover mechanism used in +BIP65 with the same thresholds, but for nVersion = 5. The new rules are +in effect for every block (at height H) with nVersion = 5 and at least +750 out of 1000 blocks preceding it (with heights H-1000..H-1) also +have nVersion >= 5. Furthermore, when 950 out of the 1000 blocks +preceding a block do have nVersion >= 5, nVersion < 5 blocks become +invalid, and all further blocks enforce the new rules. + +(It should be noted that BIP9 involves permanently setting a high-order bit to +1 which results in nVersion >= all prior IsSuperMajority() soft-forks and thus +no bits in nVersion are permanently lost.) + +=== SPV Clients === + +While SPV clients are unable to fully validate blocks, +they are able to validate block headers and, thus, can check block version and proof-of-work. +SPV clients should reject nVersion < 5 blocks if 950 out of 1000 preceding blocks have +nVersion >= 5 to prevent false confirmations from the remaining 5% of +non-upgraded miners when the 95% threshold has been reached. + +== Credits == + +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 + +== References == + +*[[bip-0016.mediawiki|BIP16 Pay to Script Hash]] +*[[bip-0143.mediawiki|BIP143 Transaction Signature Verification for Version 0 Witness Program]] +*[[bip-0144.mediawiki|BIP144 Segregated Witness (Peer Services)]] + +== Copyright == + +This document is placed in the public domain. diff --git a/bip-0142.mediawiki b/bip-0142.mediawiki new file mode 100644 index 0000000..bb60265 --- /dev/null +++ b/bip-0142.mediawiki @@ -0,0 +1,153 @@ +<pre> + BIP: 142 + Title: Address Format for Segregated Witness + Author: Johnson Lau <jl2012@xbt.hk> + Status: Deferred + Type: Standards Track + Created: 2015-12-24 +</pre> + +== Abstract == + +This BIP describes new types of Bitcoin address to support native segregated witness transactions with 20-byte and 32-byte program. + +== Motivation == + +To define standard payment address for native segregated witness (segwit) transactions to promote early adoption of the more efficient transaction method. + +== Specification == + +The new Bitcoin address format defined is for the Pay-to-Witness-Public-Key-Hash (P2WPKH) and Pay-to-Witness-Script-Hash (P2WSH) transaction described in segregated witness soft fork (BIP141). The scriptPubKey is an OP_0 followed by a push of 20-byte-hash (P2WPKH) or 32-byte hash (P2WSH). + +The new address is encoded in a way similar to existing address formats: + + base58-encode: + [1-byte address version] + [1-byte witness program version] + [0x00] + [20/32-byte-hash] + [4-byte checksum] + +For P2WPKH address, the address version is 6 (0x06) for a main-network address or 3 (0x03) for a testnet address. + +For P2WSH address, the address version is 10 (0x0A) for a main-network address or 40 (0x28) for a testnet address. + +The witness program version is a 1-byte value between 0 (0x00) and 16 (0x10). Only version 0 is defined in BIP141. Versions 1 to 16 are reserved for future extensions. + +Following the witness program version is a 0x00 padding to make sure that each witness program version will have a unique prefix. + +Following the padding is the program hash, 20 byte for a P2WPKH address and 32 byte for a P2WSH address. + +The 4-byte checksum is the first four bytes of the double SHA256 hash of the serialization of the previous items. + +All addresses generated with this scheme will have a constant length, with 36 digits for 20-byte and 53 digits for 32-byte. Different witness program versions will have a unique prefix, as shown in the following table: + +{|class="wikitable" style="text-align: center;" +|- +!rowspan=3 style=""|Witness program version +!colspan=4 style=""|Hash size +|- +!colspan=2 style=""|20-byte (36 characters) +!colspan=2 style=""|32-byte (53 characters) +|- +!Mainnet +!Testnet +!Mainnet +!Testnet +|- +|0||p2||QW||7Xh||T7n +|- +|1||p4||QY||7Xq||T7w +|- +|2||p6||Qa||7Xz||T85 +|- +|3||p7||Qc||7Y9||T8E +|- +|4||pA||Qe||7YH||T8N +|- +|5||pB||Qf||7YS||T8X +|- +|6||pD||Qh||7Ya||T8g +|- +|7||pF||Qj||7Yj||T8p +|- +|8||pG||Qm||7Yt||T8y +|- +|9||pJ||Qn||7Z2||T97 +|- +|10||pL||Qp||7ZB||T9G +|- +|11||pN||Qr||7ZK||T9Q +|- +|12||pQ||Qt||7ZU||T9Z +|- +|13||pS||Qv||7Zc||T9i +|- +|14||pT||Qw||7Zm||T9r +|- +|15||pV||Qy||7Zv||TA1 +|- +|16||pX||R1||7a4||TA9 +|- +|} + + +== Rationale == + +BIP141 defines 2 ways of encoding a "witness program", a data push of 2 to 32 bytes: + +* A native witness program output is a scriptPubKey with a push of version byte followed by a push of witness program, and nothing else; +* Segwit-in-P2SH is a BIP16 P2SH redeemScript with a push of version byte followed by a push of witness program, while the scriptPubKey looks like a normal P2SH output. + +Considering the BIP13 P2SH address has been defined in 2012, using segwit-in-P2SH allows most existing wallets to pay a segwit-compatible wallet without any upgrade. However, this method requires more block space and is only a short-term solution to make the transition smoother. Eventually, all users are expected to use the more efficient native witness program as the primary method of payment. + +The drawbacks of Bitcoin addresses have been extensively discussed in BIP13. Since then, better payment methods have been proposed or deployed, for example: +*BIP47 Reusable Payment Codes for Hierarchical Deterministic Wallets +*BIP63 Stealth Addresses +*BIP70 Payment protocol + +However, none of these are as widely adopted as the suboptimal base-58 scriptPubKey template addresses, which is still a standard for the whole eco-system, from wallets, block explorers, merchants, exchanges, to end users. It is believed that the proposed P2WPKH and P2WSH address format is the easiest way for wallets and services to adopt native witness program, which is particularly important in the context of scaling the capacity of the blockchain. + +While P2WPKH address is specific for simple payment to a single public key, P2WSH address allows arbitrarily complex segwit transactions, similar to the BIP13 P2SH address. + +== Compatibility == + +This proposal is not backward-compatible. However, an older implementation will report the new address type as invalid, and refuse to create a transaction. + +This proposal is forward-compatible with future versions of witness programs of 20 and 32 bytes. + +== Example == + +The following public key, + + 0450863AD64A87AE8A2FE83C1AF1A8403CB53F53E486D8511DAD8A04887E5B23522CD470243453A299FA9E77237716103ABC11A1DF38855ED6F2EE187E9C582BA6 + +when encoded as a P2PKH template, would become: + + DUP HASH160 <010966776006953D5567439E5E39F86A0D273BEE> EQUALVERIFY CHECKSIG + +With the corresponding version 1 Bitcoin address being: + + 16UwLL9Risc3QfPqBUvKofHmBQ7wMtjvM + +When the same public key is encoded as P2WPKH, the scriptPubKey becomes: + + OP_0 <010966776006953D5567439E5E39F86A0D273BEE> + +Using 0x06 as address version, followed by 0x00 as witness program version, and a 0x00 padding, the equivalent P2WPKH address is: + + p2xtZoXeX5X8BP8JfFhQK2nD3emtjch7UeFm + +== Reference implementation == + +https://github.com/theuni/bitcoin/commit/ede1b57058ac8efdefe61f67395affb48f2c0d80 + +== References == + +* [[bip-0013.mediawiki|BIP 13: Address Format for pay-to-script-hash]] +* [[bip-0016.mediawiki|BIP 16: Pay to Script Hash]] +* [[bip-0070.mediawiki|BIP 70: Payment Protocol]] +* [[bip-0141.mediawiki|BIP 141: Segregated Witness]] + +== Copyright == +This work is placed in the public domain. diff --git a/bip-0143.mediawiki b/bip-0143.mediawiki new file mode 100644 index 0000000..72ef22d --- /dev/null +++ b/bip-0143.mediawiki @@ -0,0 +1,204 @@ +<pre> + BIP: 143 + Title: Transaction Signature Verification for Version 0 Witness Program + Author: Johnson Lau <jl2012@xbt.hk> + Pieter Wuille <pieter.wuille@gmail.com> + Status: Draft + Type: Standards Track + Created: 2016-01-03 +</pre> + +== Abstract == +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. <ref name=wiki>[https://en.bitcoin.it/wiki/OP_CHECKSIG]</ref> + +Unfortunately, there are at least 2 weaknesses in the original transaction digest algorithm: + +* For the verification of each signature, the amount of data hashing is proportional to the size of the transaction. Therefore, data hashing grows in O(n<sup>2</sup>) as the number of sigops in a transaction increases. While a 1 MB block would normally take 2 seconds to verify with an average computer in 2015, a 1MB transaction with 5569 sigops may take 25 seconds to verify. This could be fixed by optimizing the digest algorithm by introducing some reusable “midstate”, so the time complexity becomes O(n). <ref>[https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2013-2292 CVE-2013-2292]</ref><ref>[https://bitcointalk.org/?topic=140078 New Bitcoin vulnerability: A transaction that takes at least 3 minutes to verify]</ref><ref>[http://rusty.ozlabs.org/?p=522 The Megatransaction: Why Does It Take 25 Seconds?]</ref> +* The algorithm does not involve the amount of Bitcoin being spent by the input. This is usually not a problem for online network nodes as they could request for the specified transaction to acquire the output value. For an offline transaction signing device ("cold wallet"), however, the unknowing of input amount makes it impossible to calculate the exact amount being spent and the transaction fee. To cope with this problem a cold wallet must also acquire the full transaction being spent, which could be a big obstacle in the implementation of lightweight, air-gapped wallet. By including the input value of part of the transaction digest, a cold wallet may safely sign a transaction by learning the value from an untrusted source. In the case that a wrong value is provided and signed, the signature would be invalid and no funding might be lost. <ref>[https://bitcointalk.org/index.php?topic=181734.0 SIGHASH_WITHINPUTVALUE: Super-lightweight HW wallets and offline data]</ref> + +Deploying the aforementioned fixes in the original script system is not a simple task. That would be either a hardfork, or a softfork for new sigops without the ability to remove or insert stack items. However, the introduction of segregated witness softfork offers an opportunity to define a different set of script semantics without disrupting the original system, as the unupgraded nodes would always consider such a transaction output is spendable by arbitrary signature or no signature at all. <ref>[https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki BIP141: Segregated Witness (Consensus layer)]</ref> + +== Specification == +A new transaction digest algorithm is defined, but only applicable to sigops in version 0 witness program: + Double SHA256 of the serialization of: + 1. nVersion of the transaction (4-byte little endian) + 2. hashPrevouts (32-byte hash) + 3. hashSequence (32-byte hash) + 4. outpoint (32-byte hash + 4-byte little endian) + 5. scriptCode of the input (varInt for the length + script) + 6. value of the output spent by this input (8-byte little endian) + 7. nSequence of the input (4-byte little endian) + 8. hashOutputs (32-byte hash) + 9. nLocktime of the transaction (4-byte little endian) + 10. sighash type of the signature (4-byte little endian) + +All components in the original algorithm, including the behavior <code>OP_CODESEPERATOR</code>, remains unchanged. The only difference is the way of serialization and the inclusion of amount being spent. + +The items 1, 4, 7, 9, 10 have the same meaning as the original algorithm. <ref name=wiki></ref> + +The item 5: +*For P2WPKH witness program, the scriptCode is <code>0x1976a914{20-byte-pubkey-hash}88ac</code>. +*For P2WSH witness program, +**if the <code>witnessScript</code> does not contain any <code>OP_CODESEPERATOR</code>, the <code>scriptCode</code> is a <code>varInt</code> for the length of the <code>witnessScript</code>, followed by the <code>witnessScript</code>. +**if the <code>witnessScript</code> contains any <code>OP_CODESEPERATOR</code>, the <code>scriptCode</code> is the evaluated script, with all <code>OP_CODESEPARATOR</code> and everything up to the last <code>OP_CODESEPARATOR</code> before the signature checking opcode being executed removed, and prepended by a <code>varInt</code> for the length of the truncated script. + +The item 6 is a 8-byte value of the amount of bitcoin spent in this input. + +<code>hashPrevouts</code>: +*If the ANYONECANPAY flag is not set, hashPrevouts is the double SHA256 of the serialization of all input outpoints; +*Otherwise, <code>hashPrevouts</code> is a <code>uint256</code> of <code>0x0000......0000</code>. + +<code>hashSequence</code>: +*If none of the ANYONECANPAY, SINGLE, NONE sighash type is set, hashSequence is the double SHA256 of the serialization of nSequence of all inputs; +*Otherwise, <code>hashSequence</code> is a <code>uint256</code> of <code>0x0000......0000</code>. + +<code>hashOutputs</code>: +*If the sighash type is neither SINGLE nor NONE, hashOutputs is the double SHA256 of the serialization of all output value (8-byte little endian) with scriptPubKey (<code>varInt</code> for the length + script); +*If sighash type is SINGLE and the input index is not greater than the number of outputs, <code>hashOutputs</code> is the double SHA256 of the output value with <code>scriptPubKey</code> of the same index as the input; +*Otherwise, <code>hashOutputs</code> is a <code>uint256</code> of <code>0x0000......0000</code>. + +The <code>hashPrevouts</code>, <code>hashSequence</code>, and <code>hashOutputs</code> calculated in an earlier verification may be reused in other inputs of the same transaction, so that the time complexity of the whole hashing process reduces from O(n<sup>2</sup>) to O(n). + +Refer to the reference implementation, reproduced below, for the precise algorithm: + +<source lang="cpp"> + uint256 hashPrevouts; + uint256 hashSequence; + uint256 hashOutputs; + + if (!(nHashType & SIGHASH_ANYONECANPAY)) { + CHashWriter ss(SER_GETHASH, 0); + for (unsigned int n = 0; n < txTo.vin.size(); n++) { + ss << txTo.vin[n].prevout; + } + hashPrevouts = ss.GetHash(); + } + + if (!(nHashType & SIGHASH_ANYONECANPAY) && (nHashType & 0x1f) != SIGHASH_SINGLE && (nHashType & 0x1f) != SIGHASH_NONE) { + CHashWriter ss(SER_GETHASH, 0); + for (unsigned int n = 0; n < txTo.vin.size(); n++) { + ss << txTo.vin[n].nSequence; + } + hashSequence = ss.GetHash(); + } + + if ((nHashType & 0x1f) != SIGHASH_SINGLE && (nHashType & 0x1f) != SIGHASH_NONE) { + CHashWriter ss(SER_GETHASH, 0); + for (unsigned int n = 0; n < txTo.vout.size(); n++) { + ss << txTo.vout[n]; + } + hashOutputs = ss.GetHash(); + } else if ((nHashType & 0x1f) == SIGHASH_SINGLE && nIn < txTo.vout.size()) { + CHashWriter ss(SER_GETHASH, 0); + ss << txTo.vout[nIn]; + hashOutputs = ss.GetHash(); + } + + CHashWriter ss(SER_GETHASH, 0); + // Version + ss << txTo.nVersion; + // Input prevouts/nSequence (none/all, depending on flags) + ss << hashPrevouts; + ss << hashSequence; + // The input being signed (replacing the scriptSig with scriptCode + amount) + // The prevout may already be contained in hashPrevout, and the nSequence + // may already be contain in hashSequence. + ss << txTo.vin[nIn].prevout; + ss << static_cast<const CScriptBase&>(scriptCode); + ss << amount; + ss << txTo.vin[nIn].nSequence; + // Outputs (none/one/all, depending on flags) + ss << hashOutputs; + // Locktime + ss << txTo.nLockTime; + // Sighash type + ss << nHashType; + + return ss.GetHash(); +</source> + +== Example == + + + The following is an unsigned transaction: + 0100000002fff7f7881a8099afa6940d42d1e7f6362bec38171ea3edf433541db4e4ad969f0000000000eeffffffef51e1b804cc89d182d279655c3aa89e815b1b309fe287d9b2b55d57b90ec68a0100000000ffffffff02202cb206000000001976a9148280b37df378db99f66f85c95a783a76ac7a6d5988ac9093510d000000001976a9143bde42dbee7e4dbe6a21b2d50ce2f0167faa815988ac11000000 + + nVersion: 01000000 + txin: 02 fff7f7881a8099afa6940d42d1e7f6362bec38171ea3edf433541db4e4ad969f 00000000 00 eeffffff + ef51e1b804cc89d182d279655c3aa89e815b1b309fe287d9b2b55d57b90ec68a 01000000 00 ffffffff + txout: 02 202cb20600000000 1976a9148280b37df378db99f66f85c95a783a76ac7a6d5988ac + 9093510d00000000 1976a9143bde42dbee7e4dbe6a21b2d50ce2f0167faa815988ac + nLockTime: 11000000 + + The first input comes from an ordinary P2PK: + scriptPubKey: 2103c9f4836b9a4f77fc0d81f7bcb01b7f1b35916864b9476c241ce9fc198bd25432ac value: 6.25 + + The second input comes from a P2WPKH witness program: + scriptPubKey: 00141d0f172a0ecb48aee1be1f2687d2963ae33f71a1, value: 6 + + To sign it with a nHashType of 1 (SIGHASH_ALL): + + hashPrevouts: + dSHA256(fff7f7881a8099afa6940d42d1e7f6362bec38171ea3edf433541db4e4ad969f00000000ef51e1b804cc89d182d279655c3aa89e815b1b309fe287d9b2b55d57b90ec68a01000000) + = 96b827c8483d4e9b96712b6713a7b68d6e8003a781feba36c31143470b4efd37 + + hashSequence: + dSHA256(eeffffffffffffff) + = 52b0a642eea2fb7ae638c36f6252b6750293dbe574a806984b8e4d8548339a3b + + hashOutputs: + dSHA256(202cb206000000001976a9148280b37df378db99f66f85c95a783a76ac7a6d5988ac9093510d000000001976a9143bde42dbee7e4dbe6a21b2d50ce2f0167faa815988ac) + = 863ef3e1a92afbfdb97f31ad0fc7683ee943e9abcf2501590ff8f6551f47e5e5 + + hash preimage: 0100000096b827c8483d4e9b96712b6713a7b68d6e8003a781feba36c31143470b4efd3752b0a642eea2fb7ae638c36f6252b6750293dbe574a806984b8e4d8548339a3bef51e1b804cc89d182d279655c3aa89e815b1b309fe287d9b2b55d57b90ec68a010000001976a9141d0f172a0ecb48aee1be1f2687d2963ae33f71a188ac0046c32300000000ffffffff863ef3e1a92afbfdb97f31ad0fc7683ee943e9abcf2501590ff8f6551f47e5e51100000001000000 + + nVersion: 01000000 + hashPrevouts: 96b827c8483d4e9b96712b6713a7b68d6e8003a781feba36c31143470b4efd37 + hashSequence: 52b0a642eea2fb7ae638c36f6252b6750293dbe574a806984b8e4d8548339a3b + outpoint: ef51e1b804cc89d182d279655c3aa89e815b1b309fe287d9b2b55d57b90ec68a01000000 + scriptCode: 1976a9141d0f172a0ecb48aee1be1f2687d2963ae33f71a188ac + amount: 0046c32300000000 + nSequence: ffffffff + hashOutputs: 863ef3e1a92afbfdb97f31ad0fc7683ee943e9abcf2501590ff8f6551f47e5e5 + nLockTime: 11000000 + nHashType: 01000000 + + sigHash: c37af31116d1b27caf68aae9e3ac82f1477929014d5b917657d0eb49478cb670 + signature: 304402203609e17b84f6a7d30c80bfa610b5b4542f32a8a0d5447a12fb1366d7f01cc44a0220573a954c4518331561406f90300e8f3358f51928d43c212a8caed02de67eebee + + The serialized signed transaction is: 01000000000102fff7f7881a8099afa6940d42d1e7f6362bec38171ea3edf433541db4e4ad969f00000000494830450221008b9d1dc26ba6a9cb62127b02742fa9d754cd3bebf337f7a55d114c8e5cdd30be022040529b194ba3f9281a99f2b1c0a19c0489bc22ede944ccf4ecbab4cc618ef3ed01eeffffffef51e1b804cc89d182d279655c3aa89e815b1b309fe287d9b2b55d57b90ec68a0100000000ffffffff02202cb206000000001976a9148280b37df378db99f66f85c95a783a76ac7a6d5988ac9093510d000000001976a9143bde42dbee7e4dbe6a21b2d50ce2f0167faa815988ac000247304402203609e17b84f6a7d30c80bfa610b5b4542f32a8a0d5447a12fb1366d7f01cc44a0220573a954c4518331561406f90300e8f3358f51928d43c212a8caed02de67eebee0121025476c2e83188368da1ff3e292e7acafcdb3566bb0ad253f62fc70f07aeee635711000000 + + nVersion: 01000000 + marker: 00 + flag: 01 + txin: 02 fff7f7881a8099afa6940d42d1e7f6362bec38171ea3edf433541db4e4ad969f 00000000 494830450221008b9d1dc26ba6a9cb62127b02742fa9d754cd3bebf337f7a55d114c8e5cdd30be022040529b194ba3f9281a99f2b1c0a19c0489bc22ede944ccf4ecbab4cc618ef3ed01 eeffffff + ef51e1b804cc89d182d279655c3aa89e815b1b309fe287d9b2b55d57b90ec68a 01000000 00 ffffffff + txout: 02 202cb20600000000 1976a9148280b37df378db99f66f85c95a783a76ac7a6d5988ac + 9093510d00000000 1976a9143bde42dbee7e4dbe6a21b2d50ce2f0167faa815988ac + witness 00 + 02 47304402203609e17b84f6a7d30c80bfa610b5b4542f32a8a0d5447a12fb1366d7f01cc44a0220573a954c4518331561406f90300e8f3358f51928d43c212a8caed02de67eebee01 21025476c2e83188368da1ff3e292e7acafcdb3566bb0ad253f62fc70f07aeee6357 + nLockTime: 11000000 + +The new serialization format is described in BIP144 <ref>[[bip-0144.mediawiki|BIP144: Segregated Witness (Peer Services)]]</ref> +== Deployment == + +This proposal is deployed with Segregated Witness softfork (BIP 141) + +== Backward compatibility == + +As a soft fork, older software will continue to operate without modification. Non-upgraded nodes, however, will not see nor validate the witness data and will consider all witness programs, inculding the redefined sigops, as anyone-can-spend scripts. + +== Reference Implementation == + +https://github.com/sipa/bitcoin/commits/segwit + +== References == + +<references> + +== Copyright == + +This document is placed in the public domain. diff --git a/bip-0144.mediawiki b/bip-0144.mediawiki new file mode 100644 index 0000000..2da222c --- /dev/null +++ b/bip-0144.mediawiki @@ -0,0 +1,122 @@ +<pre> + BIP: 144 + Title: Segregated Witness (Peer Services) + Author: Eric Lombrozo <elombrozo@gmail.com> + Pieter Wuille <pieter.wuille@gmail.com> + Status: Draft + Type: Standards Track + Created: 2016-01-08 +</pre> + +==Abstract== +This BIP defines new messages and serialization formats for propagation of transactions and blocks committing to segregated witness structures. + +==Motivation== +In addition to defining witness structures and requiring commitments in future blocks ([https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki BIP141] - Consensus segwit BIP), new mechanisms must be defined to allow peers to advertise support for segregated witness and to relay the witness structures and request them from other peers without breaking compatibility with older nodes. + +==Specification== + +=== Serialization === +A new serialization format for tx messages is added to the peer-to-peer protocol. + +The serialization has the following structure: + +{| class="wikitable" style="width: auto; text-align: center; font-size: smaller; table-layout: fixed;" +!Field Size +!Name +!Type +!Description +|- +| 4 +| version +| int32_t +| Transaction data format version +|- +| 1 +| marker +| char +| Must be zero +|- +| 1 +| flag +| char +| Must be nonzero +|- +| 1+ +| txin_count +| var_int +| Number of transaction inputs +|- +| 41+ +| txins +| txin[] +| A list of one or more transaction inputs +|- +| 1+ +| txout_count +| var_int +| Number of transaction outputs +|- +| 9+ +| txouts +| txouts[] +| A list of one or more transaction outputs +|- +| 1+ +| script_witnesses +| script_witnesses[] +| The witness structure as a serialized byte array +|- +| 4 +| lock_time +| uint32_t +| The block number or timestamp until which the transaction is locked +|} + +Parsers supporting this BIP will be able to distinguish between the old serialization format (without the witness) and this one. The marker byte is set to zero so that this structure will never parse as a valid transaction in a parser that does not support this BIP. If parsing were to succeed, such a transaction would contain no inputs and a single output. + +If the witness is empty, the old serialization format should be used. + +Currently, the only witness objects type supported are script witnesses which consist of a stack of byte arrays. It is encoded as a var_int item count followed by each item encoded as a var_int length followed by a string of bytes. Each txin has its own script witness. The number of script witnesses is not explicitly encoded as it is implied by txin_count. Empty script witnesses are encoded as a zero byte. The order of the script witnesses follows the same order as the associated txins. + +* '''Rationale for not having an independent message type with its own serialization''': this would require separate "tx" and "block" messages, and all RPC calls operating on raw transactions would need to be duplicated, or need inefficinent or nondeterministic guesswork to know which type is to be used. + +* '''Rationale for not using just a single 0x00 byte as marker''': that would lead to empty transactions (no inputs, no outputs, which are used in some tests) to be interpreted as new serialized data. + +* '''Rationale for the 0x01 flag byte in between''': this will allow us to easily add more extra non-committed data to transactions (like txouts being spent, ...). It can be interpreted as a bitvector. + +=== Handshake === +A new message 'havewitness' is sent after receiving 'verack' to +indicate that a node can provide witness if requested (similar to +'sendheaders') (Note: it might be better to signal this with a services bit in the version message) + +=== Hashes === +Transaction hashes used in the transaction merkle tree and txin outpoints are always computed using the old non-witness +serialization. + +Support for a new hash including the witness data is added that is +computed from the new witness serialization. (Note that transactions +with an empty witness always use the old serialization, +and therefore, they have witness hash equal to normal hash.) + +<img src=bip-0144/witnesstx.png></img> + +=== Relay === +New inv types MSG_WITNESS_TX and MSG_WITNESS_BLOCK are added, only +for use in getdata. Inventory messages themselves still use just MSG_TX and MSG_BLOCK, +similar to MSG_FILTERED_BLOCK. + +* '''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. + +MSG_WITNESS_TX getdata requests should use the non-witness serialized hash. The peer shall respond with a tx message, and if the witness structure is nonempty, the witness serialization shall be used. + +MSG_WITNESS_BLOCK requests will return a block message with transactions that have a witness using witness serialization. + +== Credits == +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 + +== Copyright == +This document is placed in the public domain. diff --git a/bip-0144/witnesstx.png b/bip-0144/witnesstx.png Binary files differnew file mode 100644 index 0000000..5fd8afc --- /dev/null +++ b/bip-0144/witnesstx.png diff --git a/bip-0145.mediawiki b/bip-0145.mediawiki new file mode 100644 index 0000000..b90725e --- /dev/null +++ b/bip-0145.mediawiki @@ -0,0 +1,96 @@ +<pre> + BIP: 145 + Title: getblocktemplate Updates for Segregated Witness + Author: Luke Dashjr <luke+bip22@dashjr.org> + Status: Draft + Type: Standards Track + Created: 2016-01-30 +</pre> + +==Abstract== + +This BIP describes modifications to the getblocktemplate JSON-RPC call ([[bip-0022.mediawiki|BIP 22]]) to support segregated witness as defined by [[bip-0141.mediawiki|BIP 141]]. + +==Specification== + +===Block Template=== + +The template Object is revised to include these keys: + +{| class="wikitable" +!colspan=4| template +|- +! Key !! Required !! Type !! Description +|- +| costlimit || {{No}} || Number || total cost allowed in blocks +|- +| sigoplimit || {{No}} || Number || total sigop cost allowed in blocks divided by 4 +|- +| version || {{Yes}} || Number || block version; clients MUST understand the implications of the version they use (eg, comply with [[bip-0141.mediawiki|BIP 141]] for version 5) +|} + +====Transactions Object Format==== + +The Objects listed in the response's "transactions" key is revised to include these keys: + +{| class="wikitable" +!colspan=3|template "transactions" element +|- +! Key !! Type !! Description +|- +| txid || String || transaction id encoded in hexadecimal; required for transactions with witness data +|- +| cost || Number || numeric cost of the transaction, as counted for purposes of the block's costlimit; if key is not present, cost is unknown and clients MUST NOT assume it is zero, although they MAY choose to calculate it themselves +|- +| hash || String || reversed hash of complete transaction (with witness data included) encoded in hexadecimal +|} + +Transactions with witness data may only be included if the template's block version is at least 5. + +===Block Assembly with Witness Transactions=== + +When block assembly is done without witness transactions, no changes are made by this BIP, and it should be assembled as previously. + +When witness transactions are included in the block, the primary merkle root MUST be calculated with those transactions' "txid" field instead of "hash". A secondary merkle root MUST be calculated as per [[bip-0141.mediawiki#Commitment_structure|BIP 141's commitment structure specification]] to be inserted into the generation (coinbase) transaction. + +Servers MUST NOT include a commitment in the "coinbasetxn" key on the template. Clients MUST insert the commitment as an additional output at the end of the final generation (coinbase) transaction. Only if the template includes a "mutable" key (see [[bip-0023.mediawiki#Mutations|BIP 23 Mutations]]) including "generation", the client MAY in that case place the commitment output in any position it chooses, provided that no later output matches the commitment pattern. + +==Motivation== + +Segregated witness substantially changes the structure of blocks, so the previous getblocktemplate specification is no longer sufficient. +It additionally also adds a new way of counting resource limits, and so GBT must be extended to convey this information correctly as well. + +==Rationale== + +Why doesn't "costlimit" simply redefine the existing "sizelimit"? +* "sizelimit" is already enforced by clients by counting the sum of bytes in transactions' "data" keys. +* Servers may wish to limit the overall size of a block, independently from the "cost" of the block. + +Why is "sigoplimit" redefined instead of a new "sigopcostlimit" being added? +* The old limit was already arbitrarily defined, and could not be counted by clients on their own anyway. The concept of "sigop cost" is merely a change in the arbitrary formula used. + +Why is "sigoplimit" divided by 4? +* To resemble the previous values. (FIXME: is this a good reason? maybe we shouldn't divide it?) + +Why is the witness commitment required to be added to the end of the generation transaction rather than anywhere else? +* Servers which do not allow modification of the generation outputs ought to be checking this as part of the validity of submissions. By requiring a specific placement, they can simply strip the commitment and do a byte-for-byte comparison of the outputs. Placing it at the end avoids the possibility of a later output matching the pattern and overriding it. + +Why shouldn't the server simply add the commitment upfront in the "coinbasetxn", and simply send the client stripped transaction data? +* It would become impossible for servers to specify only "coinbasevalue", since clients would no longer have the information required to construct the commitment. +* getblocktemplate is intended to be a *decentralised* mining protocol, and allowing clients to be blinded to the content of the block works contrary to that purpose. +* BIP 23's "transactions" mutations allow the client to modify the transaction-set on their own, which is impossible without the complete transaction data. + +==Reference Implementation== + +* [https://github.com/bitcoin/libblkmaker/tree/segwit libblkmaker] +* [https://github.com/luke-jr/eloipool/tree/segwit Eloipool] +* [https://github.com/bitcoin/bitcoin/pull/7404/files Bitcoin Core] + +==See Also== +* [[bip-0022.mediawiki|BIP 22: getblocktemplate - Fundamentals]] +* [[bip-0023.mediawiki|BIP 23: getblocktemplate - Pooled Mining]] +* [[bip-0141.mediawiki|BIP 141: Segregated Witness (Consensus layer)]] + +==Copyright== + +This BIP is dual-licensed under the Open Publication License and BSD 2-clause license. diff --git a/scripts/buildtable.pl b/scripts/buildtable.pl new file mode 100755 index 0000000..568b8eb --- /dev/null +++ b/scripts/buildtable.pl @@ -0,0 +1,136 @@ +#!/usr/bin/perl +use strict; +use warnings; + +my $topbip = 9999; + +my %RequiredFields = ( + BIP => undef, + Title => undef, + Author => undef, + Status => undef, + Type => undef, + Created => undef, +); +my %MayHaveMulti = ( + Author => undef, + 'Post-History' => undef, +); +my %DateField = ( + Created => undef, +); +my %EmailField = ( + Author => undef, + Editor => undef, +); +my %MiscField = ( + 'Post-History' => undef, +); + +my %ValidLayer = ( + Process => undef, +); +my %ValidStatus = ( + Draft => undef, + Deferred => undef, + Accepted => "background-color: #ffffcf", + Rejected => "background-color: #ffcfcf", + Withdrawn => "background-color: #ffcfcf", + Final => "background-color: #cfffcf", + Active => "background-color: #cfffcf", + Replaced => "background-color: #ffcfcf", +); +my %ValidType = ( + 'Standards Track' => 'Standard', + 'Informational' => undef, + 'Process' => undef, +); + +my %emails; + +my $bipnum = 0; +while (++$bipnum <= $topbip) { + my $fn = sprintf "bip-%04d.mediawiki", $bipnum; + -e $fn || next; + open my $F, "<$fn"; + while (<$F> !~ m[^(?:\xef\xbb\xbf)?<pre>$]) { + die "No <pre> in $fn" if eof $F; + } + my %found; + my ($title, $author, $status, $type); + my ($field, $val); + while (<$F>) { + m[^</pre>$] && last; + if (m[^ ([\w-]+)\: (.*\S)$]) { + $field = $1; + $val = $2; + die "Duplicate $field field in $fn" if exists $found{$field}; + } elsif (m[^ ( +)(.*\S)$]) { + die "Continuation of non-field in $fn" unless defined $field; + die "Too many spaces in $fn" if length $1 != 2 + length $field; + die "Not allowed for multi-value in $fn" unless exists $MayHaveMulti{$field}; + $val = $2; + } else { + die "Bad line in $fn preamble"; + } + ++$found{$field}; + die "Extra spaces in $fn" if $val =~ /^\s/; + if ($field eq 'BIP') { + die "$fn claims to be BIP $val" if $val ne $bipnum; + } elsif ($field eq 'Title') { + $title = $val; + } elsif ($field eq 'Author') { + $val =~ m/^(\S[^<@>]*\S) \<([^@>]*\@[\w.]+\.\w+)\>$/ or die "Malformed Author line in $fn"; + my ($authorname, $authoremail) = ($1, $2); + $authoremail =~ s/(?<=\D)$bipnum(?=\D)/<BIPNUM>/g; + $emails{$authorname}->{$authoremail} = undef; + if (defined $author) { + $author .= ", $authorname"; + } else { + $author = $authorname; + } + } elsif ($field eq 'Status') { + if ($bipnum == 38) { # HACK + $val =~ s/\s+\(.*\)$//; + } + die "Invalid status in $fn" unless exists $ValidStatus{$val}; + $status = $val; + } elsif ($field eq 'Type') { + die "Invalid type in $fn" unless exists $ValidType{$val}; + if (defined $ValidType{$val}) { + $type = $ValidType{$val}; + } else { + $type = $val; + } + } elsif ($field eq 'Layer') { # BIP 123 + die "Invalid layer $val in $fn" unless exists $ValidLayer{$val}; + } elsif (exists $DateField{$field}) { + die "Invalid date format in $fn" unless $val =~ /^20\d{2}\-(?:0\d|1[012])\-(?:[012]\d|30|31)$/; + } elsif (exists $EmailField{$field}) { + $val =~ m/^(\S[^<@>]*\S) \<[^@>]*\@[\w.]+\.\w+\>$/ or die "Malformed $field line in $fn"; + } elsif (not exists $MiscField{$field}) { + die "Unknown field $field in $fn"; + } + } + for my $field (keys %RequiredFields) { + die "Missing $field in $fn" unless $found{$field}; + } + print "|-"; + if (defined $ValidStatus{$status}) { + print " style=\"" . $ValidStatus{$status} . "\""; + } + print "\n"; + print "| [[${fn}|${bipnum}]]\n"; + print "| ${title}\n"; + print "| ${author}\n"; + print "| ${type}\n"; + print "| ${status}\n"; + close $F; +} + +for my $author (sort keys %emails) { + my @emails = sort keys %{$emails{$author}}; + my $email_count = @emails; + next unless $email_count > 1; + warn "NOTE: $author has $email_count email addresses: @emails\n"; +} |
