diff options
100 files changed, 1747 insertions, 266 deletions
diff --git a/README.mediawiki b/README.mediawiki index da18d6b..4f6b8bc 100644 --- a/README.mediawiki +++ b/README.mediawiki @@ -8,222 +8,266 @@ Those proposing changes should consider that ultimately consent may rest with th {| class="wikitable sortable" style="width: auto; text-align: center; font-size: smaller; table-layout: fixed;" !Number +!Layer !Title !Owner !Type !Status -|- style="background-color: #cfffcf" +|- style="background-color: #ffcfcf" | [[bip-0001.mediawiki|1]] +| | BIP Purpose and Guidelines | Amir Taaki | Process -| Active -|- +| Replaced +|- style="background-color: #cfffcf" | [[bip-0002.mediawiki|2]] +| | BIP process, revised | Luke Dashjr | Process +| Active +|- +| [[bip-0008.mediawiki|8]] +| +| Version bits with guaranteed lock-in +| Shaolin Fry +| Informational | Draft |- style="background-color: #cfffcf" | [[bip-0009.mediawiki|9]] +| | Version bits with timeout and delay | Pieter Wuille, Peter Todd, Greg Maxwell, Rusty Russell | Informational | Final |- style="background-color: #ffcfcf" | [[bip-0010.mediawiki|10]] +| Applications | Multi-Sig Transaction Distribution | Alan Reiner | Informational | Withdrawn |- style="background-color: #cfffcf" | [[bip-0011.mediawiki|11]] +| Applications | M-of-N Standard Transactions | Gavin Andresen | Standard | Final |- style="background-color: #ffcfcf" | [[bip-0012.mediawiki|12]] +| Consensus (soft fork) | OP_EVAL | Gavin Andresen | Standard | Withdrawn |- style="background-color: #cfffcf" | [[bip-0013.mediawiki|13]] +| Applications | Address Format for pay-to-script-hash | Gavin Andresen | Standard | Final |- style="background-color: #cfffcf" | [[bip-0014.mediawiki|14]] +| Peer Services | Protocol Version and User Agent | Amir Taaki, Patrick Strateman | Standard | Final |- | [[bip-0015.mediawiki|15]] +| Applications | Aliases | Amir Taaki | Standard | Deferred |- style="background-color: #cfffcf" | [[bip-0016.mediawiki|16]] +| Consensus (soft fork) | Pay to Script Hash | Gavin Andresen | Standard | Final |- style="background-color: #ffcfcf" | [[bip-0017.mediawiki|17]] +| Consensus (soft fork) | OP_CHECKHASHVERIFY (CHV) | Luke Dashjr | Standard | Withdrawn |- style="background-color: #ffffcf" | [[bip-0018.mediawiki|18]] +| Consensus (soft fork) | hashScriptCheck | Luke Dashjr | Standard -| Accepted +| Proposed |- | [[bip-0019.mediawiki|19]] +| Applications | M-of-N Standard Transactions (Low SigOp) | Luke Dashjr | Standard | Draft |- style="background-color: #ffcfcf" | [[bip-0020.mediawiki|20]] +| Applications | URI Scheme | Luke Dashjr | Standard | Replaced |- style="background-color: #cfffcf" | [[bip-0021.mediawiki|21]] +| Applications | URI Scheme | Nils Schneider, Matt Corallo | Standard | Final |- style="background-color: #cfffcf" | [[bip-0022.mediawiki|22]] +| API/RPC | getblocktemplate - Fundamentals | Luke Dashjr | Standard | Final |- style="background-color: #cfffcf" | [[bip-0023.mediawiki|23]] +| API/RPC | getblocktemplate - Pooled Mining | Luke Dashjr | Standard | Final |- style="background-color: #cfffcf" | [[bip-0030.mediawiki|30]] +| Consensus (soft fork) | Duplicate transactions | Pieter Wuille | Standard | Final |- style="background-color: #cfffcf" | [[bip-0031.mediawiki|31]] +| Peer Services | Pong message | Mike Hearn | Standard | Final |- style="background-color: #cfffcf" | [[bip-0032.mediawiki|32]] +| Applications | Hierarchical Deterministic Wallets | Pieter Wuille | Informational | Final |- | [[bip-0033.mediawiki|33]] +| Peer Services | Stratized Nodes | Amir Taaki | Standard | Draft |- style="background-color: #cfffcf" | [[bip-0034.mediawiki|34]] +| Consensus (soft fork) | Block v2, Height in Coinbase | Gavin Andresen | Standard | Final |- style="background-color: #cfffcf" | [[bip-0035.mediawiki|35]] +| Peer Services | mempool message | Jeff Garzik | Standard | Final |- | [[bip-0036.mediawiki|36]] +| Peer Services | Custom Services | Stefan Thomas | Standard | Draft |- style="background-color: #cfffcf" | [[bip-0037.mediawiki|37]] +| Peer Services | Connection Bloom filtering | Mike Hearn, Matt Corallo | Standard | Final |- | [[bip-0038.mediawiki|38]] +| Applications | Passphrase-protected private key | Mike Caldwell, Aaron Voisine | Standard | Draft |- style="background-color: #ffffcf" | [[bip-0039.mediawiki|39]] +| Applications | Mnemonic code for generating deterministic keys | Marek Palatinus, Pavol Rusnak, Aaron Voisine, Sean Bowe | Standard -| Accepted +| Proposed |- | 40 +| API/RPC | Stratum wire protocol | Marek Palatinus | Standard | BIP number allocated |- | 41 +| API/RPC | Stratum mining protocol | Marek Palatinus | Standard | BIP number allocated |- | [[bip-0042.mediawiki|42]] +| Consensus (soft fork) | A finite monetary supply for Bitcoin | Pieter Wuille | Standard | Draft |- | [[bip-0043.mediawiki|43]] +| Applications | Purpose Field for Deterministic Wallets | Marek Palatinus, Pavol Rusnak | Informational | Draft |- style="background-color: #ffffcf" | [[bip-0044.mediawiki|44]] +| Applications | Multi-Account Hierarchy for Deterministic Wallets | Marek Palatinus, Pavol Rusnak | Standard -| Accepted +| Proposed |- style="background-color: #ffffcf" | [[bip-0045.mediawiki|45]] +| Applications | Structure for Deterministic P2SH Multisignature Wallets | Manuel Araoz, Ryan X. Charles, Matias Alejo Garcia | Standard -| Accepted +| Proposed |- | [[bip-0047.mediawiki|47]] +| Applications | Reusable Payment Codes for Hierarchical Deterministic Wallets | Justus Ranvier | Informational | Draft |- | [[bip-0049.mediawiki|49]] +| Applications | Derivation scheme for P2WPKH-nested-in-P2SH based accounts | Daniel Weigl | Informational | Draft |- style="background-color: #cfffcf" | [[bip-0050.mediawiki|50]] +| | March 2013 Chain Fork Post-Mortem | Gavin Andresen | Informational @@ -231,328 +275,424 @@ Those proposing changes should consider that ultimately consent may rest with th <!-- 50 series reserved for a group of post-mortems --> |- | [[bip-0060.mediawiki|60]] +| Peer Services | Fixed Length "version" Message (Relay-Transactions Field) | Amir Taaki | Standard | Draft |- style="background-color: #cfffcf" | [[bip-0061.mediawiki|61]] +| Peer Services | Reject P2P message | Gavin Andresen | Standard | Final |- style="background-color: #ffcfcf" | [[bip-0062.mediawiki|62]] +| Consensus (soft fork) | Dealing with malleability | Pieter Wuille | Standard | Withdrawn |- | 63 +| Applications | Stealth Addresses | Peter Todd | Standard | BIP number allocated |- | [[bip-0064.mediawiki|64]] +| Peer Services | getutxo message | Mike Hearn | Standard | Draft |- style="background-color: #cfffcf" | [[bip-0065.mediawiki|65]] +| Consensus (soft fork) | OP_CHECKLOCKTIMEVERIFY | Peter Todd | Standard | Final |- style="background-color: #cfffcf" | [[bip-0066.mediawiki|66]] +| Consensus (soft fork) | Strict DER signatures | Pieter Wuille | Standard | Final |- style="background-color: #ffffcf" | [[bip-0067.mediawiki|67]] +| Applications | Deterministic Pay-to-script-hash multi-signature addresses through public key sorting | Thomas Kerin, Jean-Pierre Rupp, Ruben de Vries | Standard -| Accepted +| Proposed |- style="background-color: #cfffcf" | [[bip-0068.mediawiki|68]] +| Consensus (soft fork) | Relative lock-time using consensus-enforced sequence numbers | Mark Friedenbach, BtcDrak, Nicolas Dorier, kinoshitajona | Standard | Final |- style="background-color: #ffffcf" | [[bip-0069.mediawiki|69]] +| Applications | Lexicographical Indexing of Transaction Inputs and Outputs | Kristov Atlas | Informational -| Accepted +| Proposed |- style="background-color: #cfffcf" | [[bip-0070.mediawiki|70]] +| Applications | Payment Protocol | Gavin Andresen, Mike Hearn | Standard | Final |- style="background-color: #cfffcf" | [[bip-0071.mediawiki|71]] +| Applications | Payment Protocol MIME types | Gavin Andresen | Standard | Final |- style="background-color: #cfffcf" | [[bip-0072.mediawiki|72]] +| Applications | bitcoin: uri extensions for Payment Protocol | Gavin Andresen | Standard | Final |- style="background-color: #cfffcf" | [[bip-0073.mediawiki|73]] +| Applications | Use "Accept" header for response type negotiation with Payment Request URLs | Stephen Pair | Standard | Final |- | [[bip-0074.mediawiki|74]] +| Applications | Allow zero value OP_RETURN in Payment Protocol | Toby Padilla | Standard | Draft |- | [[bip-0075.mediawiki|75]] +| Applications | Out of Band Address Exchange using Payment Protocol Encryption | Justin Newton, Matt David, Aaron Voisine, James MacWhyte | Standard | Draft |- | [[bip-0080.mediawiki|80]] +| | Hierarchy for Non-Colored Voting Pool Deterministic Multisig Wallets | Justus Ranvier, Jimmy Song | Informational | Deferred |- | [[bip-0081.mediawiki|81]] +| | Hierarchy for Colored Voting Pool Deterministic Multisig Wallets | Justus Ranvier, Jimmy Song | Informational | Deferred |- | [[bip-0083.mediawiki|83]] +| Applications | Dynamic Hierarchical Deterministic Key Trees | Eric Lombrozo | Standard | Draft |- +| [[bip-0090.mediawiki|90]] +| Consensus (hard fork) +| Buried Deployments +| Suhas Daftuar +| Informational +| Draft +|- | [[bip-0099.mediawiki|99]] +| | Motivation and deployment of consensus rule changes ([soft/hard]forks) | Jorge Timón | Informational | Draft |- style="background-color: #ffcfcf" | [[bip-0101.mediawiki|101]] +| Consensus (hard fork) | Increase maximum block size | Gavin Andresen | Standard | Withdrawn |- | [[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-0104.mediawiki|104]] +| Consensus (hard fork) +| 'Block75' - Max block size like difficulty +| t.khan +| Standard +| Draft +|- | [[bip-0105.mediawiki|105]] +| Consensus (hard fork) | Consensus based block size retargeting 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 -|- +|- style="background-color: #ffcfcf" | [[bip-0109.mediawiki|109]] +| Consensus (hard fork) | Two million byte size limit with sigop and sighash limits | Gavin Andresen | Standard -| Draft +| Rejected |- style="background-color: #ffffcf" | [[bip-0111.mediawiki|111]] +| Peer Services | NODE_BLOOM service bit | Matt Corallo, Peter Todd | Standard -| Accepted +| Proposed |- style="background-color: #cfffcf" | [[bip-0112.mediawiki|112]] +| Consensus (soft fork) | CHECKSEQUENCEVERIFY | BtcDrak, Mark Friedenbach, Eric Lombrozo | Standard | Final |- style="background-color: #cfffcf" | [[bip-0113.mediawiki|113]] +| Consensus (soft fork) | Median time-past as endpoint for lock-time calculations | Thomas Kerin, Mark Friedenbach | Standard | Final |- | [[bip-0114.mediawiki|114]] +| Consensus (soft fork) | Merkelized Abstract Syntax Tree | Johnson Lau | 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 -|- +|- style="background-color: #cfffcf" | [[bip-0123.mediawiki|123]] +| | BIP Classification | Eric Lombrozo | Process -| Draft +| Active |- | [[bip-0124.mediawiki|124]] +| Applications | Hierarchical Deterministic Script Templates | Eric Lombrozo, William Swanson | Informational | Draft |- style="background-color: #ffffcf" | [[bip-0125.mediawiki|125]] +| Applications | Opt-in Full Replace-by-Fee Signaling | David A. Harding, Peter Todd | Standard -| Accepted +| Proposed |- | [[bip-0126.mediawiki|126]] +| | Best Practices for Heterogeneous Input Script Transactions | Kristov Atlas | Informational | Draft |- style="background-color: #ffffcf" | [[bip-0130.mediawiki|130]] +| Peer Services | sendheaders message | Suhas Daftuar | Standard -| Accepted +| Proposed |- | [[bip-0131.mediawiki|131]] +| Consensus (hard fork) | "Coalescing Transaction" Specification (wildcard inputs) | Chris Priest | Standard | Draft |- style="background-color: #ffcfcf" | [[bip-0132.mediawiki|132]] +| | Committee-based BIP Acceptance Process | Andy Chase | Process | Withdrawn |- | [[bip-0133.mediawiki|133]] +| Peer Services | feefilter message | Alex Morcos | Standard | Draft |- | [[bip-0134.mediawiki|134]] +| Consensus (hard fork) | Flexible Transactions | Tom Zander | Standard | 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 | Deferred |- | [[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 |- | [[bip-0145.mediawiki|145]] +| API/RPC | getblocktemplate Updates for Segregated Witness | Luke Dashjr | Standard | Draft |- | [[bip-0146.mediawiki|146]] +| Consensus (soft fork) | Dealing with signature encoding malleability | Johnson Lau, Pieter Wuille | Standard | Draft |- | [[bip-0147.mediawiki|147]] +| Consensus (soft fork) | Dealing with dummy stack element malleability | Johnson Lau | Standard | Draft |- +| [[bip-0148.mediawiki|148]] +| Consensus (soft fork) +| Mandatory activation of segwit deployment +| Shaolin Fry +| Standard +| Draft +|- | [[bip-0150.mediawiki|150]] +| Peer Services | Peer Authentication | Jonas Schnelli | Standard | Draft |- | [[bip-0151.mediawiki|151]] +| Peer Services | Peer-to-Peer Communication Encryption | Jonas Schnelli | Standard | Draft |- | [[bip-0152.mediawiki|152]] +| Peer Services | Compact Block Relay | Matt Corallo | Standard | Draft +|- +| [[bip-0171.mediawiki|171]] +| Applications +| Currency/exchange rate information API +| Luke Dashjr +| Standard +| Draft +|- +| [[bip-0180.mediawiki|180]] +| Peer Services +| Block size/weight fraud proof +| Luke Dashjr +| Standard +| Draft +|- +| [[bip-0199.mediawiki|199]] +| Applications +| Hashed Time-Locked Contract transactions +| Sean Bowe, Daira Hopwood +| 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 44fbe8b..b1947ea 100644 --- a/bip-0001.mediawiki +++ b/bip-0001.mediawiki @@ -2,9 +2,12 @@ BIP: 1 Title: BIP Purpose and Guidelines Author: Amir Taaki <genjix@riseup.net> - Status: Active + Comments-Summary: No comments yet. + Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0001 + Status: Replaced Type: Process Created: 2011-08-19 + Superseded-By: 2 </pre> ==What is a BIP?== diff --git a/bip-0002.mediawiki b/bip-0002.mediawiki index 43a5ce6..ea60d1d 100644 --- a/bip-0002.mediawiki +++ b/bip-0002.mediawiki @@ -2,9 +2,13 @@ BIP: 2 Title: BIP process, revised Author: Luke Dashjr <luke+bip@dashjr.org> - Status: Draft + Comments-Summary: No comments yet. + Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0002 + Status: Active Type: Process Created: 2016-02-03 + License: BSD-2-Clause + OPL Replaces: 1 </pre> @@ -74,6 +78,7 @@ For each new BIP that comes in an editor does the following: * The title should accurately describe the content. * The BIP draft must have been sent to the Bitcoin development mailing list for discussion. * Motivation and backward compatibility (when applicable) must be addressed. +* The defined Layer header must be correctly assigned for the given specification. * Licensing terms must be acceptable for BIPs. If the BIP isn't ready, the editor will send it back to the author for revision, with specific instructions. @@ -120,6 +125,7 @@ Each BIP must begin with an RFC 822 style header preamble. The headers must appe <pre> BIP: <BIP number, or "?" before being assigned> +* Layer: <Consensus (soft fork) | Consensus (hard fork) | Peer Services | API/RPC | Applications> Title: <BIP title; maximum 44 characters> Author: <list of authors' real names and email addrs> * Discussions-To: <email address> @@ -137,6 +143,9 @@ Each BIP must begin with an RFC 822 style header preamble. The headers must appe * Superseded-By: <BIP number> </pre> +The Layer header (only for Standards Track BIPs) documents which layer of Bitcoin the BIP applies to. +See [[bip-0123.mediawiki|BIP 123]] for definitions of the various BIP layers. Activation of this BIP implies activation of BIP 123. + The Author header lists the names and email addresses of all the authors/owners of the BIP. The format of the Author header value must be @@ -191,8 +200,6 @@ A process BIP may change status from Draft to Active when it achieves rough cons ====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). @@ -395,6 +402,7 @@ Why is Public Domain no longer acceptable for new BIPs? * An implementation is now required (when applicable) before BIPs can proceed to Proposed Status. * BIP Comments are newly introduced. * The License preamble headers have been added. +* The Layer header is included from BIP 123. * Non-image auxiliary files are permitted in the bip-XXXX subdirectory. * Email addresses are now required for authors. * The Post-History header may be provided as a link instead of a simple date. diff --git a/bip-0008.mediawiki b/bip-0008.mediawiki new file mode 100644 index 0000000..b5e46a6 --- /dev/null +++ b/bip-0008.mediawiki @@ -0,0 +1,76 @@ +<pre> + BIP: 8 + Title: Version bits with guaranteed lock-in + Author: Shaolin Fry <shaolinfry@protonmail.ch> + Comments-Summary: No comments yet. + Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0008 + Status: Draft + Type: Informational + Created: 2017-02-01 + License: BSD-3-Clause + CC0-1.0 +</pre> + +==Abstract== + +This document specifies an extension to [[bip-0009.mediawiki|BIP9]] that introduces an additional activation parameter to guarantee activation of backward-compatible changes (further called "soft forks"). + +==Motivation== + +BIP9 introduced a mechanism for doing parallel soft forking deployments based on repurposing the block nVersion field. Activation is dependent on near unanimous hashrate signalling which may be impractical and is also subject to veto by a small minority of non-signalling hashrate. + +This specification provides a way to optionally guarantee lock-in at the end of the [[bip-0009.mediawiki|BIP9]] timeout, and therefore activation, while still allowing a hashrate super majority to trigger activation earlier. + +==Specification== + +This specification is the same as [[bip-0009.mediawiki|BIP9]] except there is no FAILED condition. The state transition from '''STARTED''' to '''LOCKED_IN''' will occur under two condition: + +The first is when the threshold of blocks signalling is reached as per BIP9. The second is if the timeout is still '''STARTED'''. + +===State transitions=== + +<img src="bip-0008/states.png" align="middle"></img> + +During the STARTED state if the '''lockinontimeout''' is set to true, the state will transition to LOCKED_IN when '''timeout''' is reached. + + case STARTED: + // BIP8/9 specification follows + if (GetMedianTimePast(block.parent) >= timeout) { + // implementation detail: if flag set, BIP8 workflow, else BIP9 workflow. + return (fLockInOnTimeout == true) ? THRESHOLD_LOCKED_IN : THRESHOLD_FAILED + } + int count = 0; + walk = block; + for (i = 0; i < 2016; i++) { + walk = walk.parent; + if (walk.nVersion & 0xE0000000 == 0x20000000 && (walk.nVersion >> bit) & 1 == 1) { + count++; + } + } + if (count >= threshold) { + return LOCKED_IN; + } + return STARTED; + +=== Reference implementation === + +https://github.com/bitcoin/bitcoin/compare/master...shaolinfry:bip-uaversionbits + +==Backwards compatibility== + +BIP8 and BIP9 deployments should not share concurrent active deployment bits. Nodes that only implement BIP9 will not activate a BIP8 soft fork if hashpower threshold is not reached by '''timeout''', however, those nodes will still accept the blocks generated by activated nodes. + +==Deployments== + +A living list of deployment proposals can be found [[bip-0008/assignments.mediawiki|here]]. + +==References== + +[[bip-0009.mediawiki|BIP9]] + +[https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-February/013643.html Mailing list discussion] + +==Copyright== + +This document is dual licensed as BSD 3-clause, and Creative Commons CC0 1.0 Universal. + diff --git a/bip-0008/assignments.mediawiki b/bip-0008/assignments.mediawiki new file mode 100644 index 0000000..c18751b --- /dev/null +++ b/bip-0008/assignments.mediawiki @@ -0,0 +1,6 @@ +==Deployments== + +List of deployments. + +State can be defined, active, failed. Dates are in UTC. + diff --git a/bip-0008/states.png b/bip-0008/states.png Binary files differnew file mode 100644 index 0000000..0cc9de7 --- /dev/null +++ b/bip-0008/states.png diff --git a/bip-0009.mediawiki b/bip-0009.mediawiki index 536ef1f..11e3505 100644 --- a/bip-0009.mediawiki +++ b/bip-0009.mediawiki @@ -5,9 +5,12 @@ Peter Todd <pete@petertodd.org> Greg Maxwell <greg@xiph.org> Rusty Russell <rusty@rustcorp.com.au> + Comments-Summary: No comments yet. + Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0009 Status: Final Type: Informational Created: 2015-10-04 + License: PD </pre> ==Abstract== diff --git a/bip-0010.mediawiki b/bip-0010.mediawiki index d15cd77..42071f3 100644 --- a/bip-0010.mediawiki +++ b/bip-0010.mediawiki @@ -1,7 +1,10 @@ <pre> BIP: 10 + Layer: Applications Title: Multi-Sig Transaction Distribution Author: Alan Reiner <etotheipi@gmail.com> + Comments-Summary: No comments yet. + Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0010 Status: Withdrawn Type: Informational Created: 2011-10-28 diff --git a/bip-0011.mediawiki b/bip-0011.mediawiki index 4b12340..bb0a308 100644 --- a/bip-0011.mediawiki +++ b/bip-0011.mediawiki @@ -1,7 +1,10 @@ <pre> BIP: 11 + Layer: Applications Title: M-of-N Standard Transactions Author: Gavin Andresen <gavinandresen@gmail.com> + Comments-Summary: No comments yet. + Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0011 Status: Final Type: Standards Track Created: 2011-10-18 diff --git a/bip-0012.mediawiki b/bip-0012.mediawiki index ee2fda6..9cb3795 100644 --- a/bip-0012.mediawiki +++ b/bip-0012.mediawiki @@ -1,7 +1,10 @@ <pre> BIP: 12 + Layer: Consensus (soft fork) Title: OP_EVAL Author: Gavin Andresen <gavinandresen@gmail.com> + Comments-Summary: No comments yet. + Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0012 Status: Withdrawn Type: Standards Track Created: 2011-10-18 diff --git a/bip-0013.mediawiki b/bip-0013.mediawiki index a537d16..9805ed0 100644 --- a/bip-0013.mediawiki +++ b/bip-0013.mediawiki @@ -1,7 +1,10 @@ <pre> BIP: 13 + Layer: Applications Title: Address Format for pay-to-script-hash Author: Gavin Andresen <gavinandresen@gmail.com> + Comments-Summary: No comments yet. + Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0013 Status: Final Type: Standards Track Created: 2011-10-18 diff --git a/bip-0014.mediawiki b/bip-0014.mediawiki index f11cb63..abd575c 100644 --- a/bip-0014.mediawiki +++ b/bip-0014.mediawiki @@ -1,8 +1,11 @@ <pre> BIP: 14 + Layer: Peer Services Title: Protocol Version and User Agent Author: Amir Taaki <genjix@riseup.net> Patrick Strateman <bitcoin-bips@covertinferno.org> + Comments-Summary: No comments yet. + Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0014 Status: Final Type: Standards Track Created: 2011-11-10 diff --git a/bip-0015.mediawiki b/bip-0015.mediawiki index b90539d..a6e4426 100644 --- a/bip-0015.mediawiki +++ b/bip-0015.mediawiki @@ -1,7 +1,10 @@ <pre> BIP: 15 + Layer: Applications Title: Aliases Author: Amir Taaki <genjix@riseup.net> + Comments-Summary: No comments yet. + Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0015 Status: Deferred Type: Standards Track Created: 2011-12-10 diff --git a/bip-0016.mediawiki b/bip-0016.mediawiki index 25b652d..d5d39ef 100644 --- a/bip-0016.mediawiki +++ b/bip-0016.mediawiki @@ -1,7 +1,10 @@ <pre> BIP: 16 + Layer: Consensus (soft fork) Title: Pay to Script Hash Author: Gavin Andresen <gavinandresen@gmail.com> + Comments-Summary: No comments yet. + Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0016 Status: Final Type: Standards Track Created: 2012-01-03 diff --git a/bip-0017.mediawiki b/bip-0017.mediawiki index 44011d5..671f75a 100644 --- a/bip-0017.mediawiki +++ b/bip-0017.mediawiki @@ -1,16 +1,24 @@ <pre> BIP: 17 + Layer: Consensus (soft fork) Title: OP_CHECKHASHVERIFY (CHV) Author: Luke Dashjr <luke+bip17@dashjr.org> + Comments-Summary: No comments yet. + Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0017 Status: Withdrawn Type: Standards Track Created: 2012-01-18 + License: BSD-2-Clause </pre> ==Abstract== This BIP describes a new opcode (OP_CHECKHASHVERIFY) for the Bitcoin scripting system, and a new 'standard' transaction type that uses it to enables the receiver of bitcoins to specify the transaction type needed to re-spend them. +==Copyright== + +This BIP is licensed under the BSD 2-clause license. + ==Motivation== The purpose of pay-to-script-hash is to move the responsibility for supplying the conditions to redeem a transaction from the sender of the funds to the redeemer. diff --git a/bip-0018.mediawiki b/bip-0018.mediawiki index fce4200..a82ab44 100644 --- a/bip-0018.mediawiki +++ b/bip-0018.mediawiki @@ -1,16 +1,24 @@ <pre> BIP: 18 + Layer: Consensus (soft fork) Title: hashScriptCheck Author: Luke Dashjr <luke+bip17@dashjr.org> - Status: Accepted + Comments-Summary: No comments yet. + Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0018 + Status: Proposed Type: Standards Track Created: 2012-01-27 + License: BSD-2-Clause </pre> ==Abstract== This BIP modifies the basic format of transaction inputs and outputs, replacing the current scriptSig and scriptPubKey (scripts executed to validate a transaction) with new contents: dataSig, scriptCheck, and hashScriptCheck. +==Copyright== + +This BIP is licensed under the BSD 2-clause license. + ==Motivation== The purpose of pay-to-script-hash is to move the responsibility for supplying the conditions to redeem a transaction from the sender of the funds to the redeemer. diff --git a/bip-0019.mediawiki b/bip-0019.mediawiki index 7784e08..99462b7 100644 --- a/bip-0019.mediawiki +++ b/bip-0019.mediawiki @@ -1,16 +1,24 @@ <pre> BIP: 19 + Layer: Applications Title: M-of-N Standard Transactions (Low SigOp) Author: Luke Dashjr <luke+bip17@dashjr.org> + Comments-Summary: No comments yet. + Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0019 Status: Draft Type: Standards Track Created: 2012-01-30 + License: BSD-2-Clause </pre> ==Abstract== This BIP proposes M-of-N-signatures required transactions as a new 'standard' transaction type using the existing scripting system without significant modifications. +==Copyright== + +This BIP is licensed under the BSD 2-clause license. + ==Motivation== Enable secured wallets, escrow transactions, and other use cases where redeeming funds requires more than a single signature. diff --git a/bip-0020.mediawiki b/bip-0020.mediawiki index fad634b..fc3c0ea 100644 --- a/bip-0020.mediawiki +++ b/bip-0020.mediawiki @@ -1,10 +1,14 @@ <pre> BIP: 20 + Layer: Applications Title: URI Scheme Author: Luke Dashjr <luke+bip@dashjr.org> + Comments-Summary: No comments yet. + Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0020 Status: Replaced Type: Standards Track Created: 2011-01-10 + License: BSD-2-Clause </pre> BIP 0020 is based off an earlier document by Nils Schneider. '''And has been replaced by BIP 0021''' @@ -12,6 +16,9 @@ BIP 0020 is based off an earlier document by Nils Schneider. '''And has been rep ==Abstract== This BIP proposes a URI scheme for making Bitcoin payments. +==Copyright== +This BIP is licensed under the BSD 2-clause license. + ==Motivation== The purpose of this URI scheme is to enable users to easily make payments by simply clicking links on webpages or scanning QR Codes. diff --git a/bip-0021.mediawiki b/bip-0021.mediawiki index 513b8bb..cfab856 100644 --- a/bip-0021.mediawiki +++ b/bip-0021.mediawiki @@ -1,8 +1,11 @@ <pre> BIP: 21 + Layer: Applications Title: URI Scheme Author: Nils Schneider <nils.schneider@gmail.com> Matt Corallo <bip21@bluematt.me> + Comments-Summary: No comments yet. + Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0021 Status: Final Type: Standards Track Created: 2012-01-29 diff --git a/bip-0022.mediawiki b/bip-0022.mediawiki index 4b33e59..45ebacf 100644 --- a/bip-0022.mediawiki +++ b/bip-0022.mediawiki @@ -1,10 +1,14 @@ <pre> BIP: 22 + Layer: API/RPC Title: getblocktemplate - Fundamentals Author: Luke Dashjr <luke+bip22@dashjr.org> + Comments-Summary: No comments yet. + Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0022 Status: Final Type: Standards Track Created: 2012-02-28 + License: BSD-2-Clause </pre> ==Abstract== @@ -12,6 +16,10 @@ This BIP describes a new JSON-RPC method for "smart" Bitcoin miners and proxies. Instead of sending a simple block header for hashing, the entire block structure is sent, and left to the miner to (optionally) customize and assemble. +==Copyright== + +This BIP is licensed under the BSD 2-clause license. + ==Specification== ===Block Template Request=== diff --git a/bip-0023.mediawiki b/bip-0023.mediawiki index 0390958..4974a3a 100644 --- a/bip-0023.mediawiki +++ b/bip-0023.mediawiki @@ -1,16 +1,24 @@ <pre> BIP: 23 + Layer: API/RPC Title: getblocktemplate - Pooled Mining Author: Luke Dashjr <luke+bip22@dashjr.org> + Comments-Summary: No comments yet. + Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0023 Status: Final Type: Standards Track Created: 2012-02-28 + License: BSD-2-Clause </pre> ==Abstract== This BIP describes extensions to the getblocktemplate JSON-RPC call to enhance pooled mining. +==Copyright== + +This BIP is licensed under the BSD 2-clause license. + ==Specification== Note that all sections of this specification are optional extensions on top of [[bip-0022.mediawiki|BIP 22]]. diff --git a/bip-0030.mediawiki b/bip-0030.mediawiki index 135d300..a63b737 100644 --- a/bip-0030.mediawiki +++ b/bip-0030.mediawiki @@ -1,15 +1,23 @@ <pre> BIP: 30 + Layer: Consensus (soft fork) Title: Duplicate transactions Author: Pieter Wuille <pieter.wuille@gmail.com> + Comments-Summary: No comments yet. + Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0030 Status: Final Type: Standards Track Created: 2012-02-22 + License: BSD-2-Clause </pre> ==Abstract== This document gives a specification for dealing with duplicate transactions in the block chain, in an attempt to solve certain problems the reference implementations has with them. +==Copyright== + +This BIP is licensed under the 2-clause BSD license. + ==Motivation== So far, the Bitcoin reference implementation always assumed duplicate transactions (transactions with the same identifier) didn't exist. This is not true; in particular coinbases are easy to duplicate, and by building on duplicate coinbases, duplicate normal transactions are possible as well. Recently, an attack that exploits the reference implementation's dealing with duplicate transactions was described and demonstrated. It allows reverting fully-confirmed transactions to a single confirmation, making them vulnerable to become unspendable entirely. Another attack is possible that allows forking the block chain for a subset of the network. diff --git a/bip-0031.mediawiki b/bip-0031.mediawiki index 1bfe143..7f4cec4 100644 --- a/bip-0031.mediawiki +++ b/bip-0031.mediawiki @@ -1,7 +1,10 @@ <pre> BIP: 31 + Layer: Peer Services Title: Pong message Author: Mike Hearn <hearn@google.com> + Comments-Summary: No comments yet. + Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0031 Status: Final Type: Standards Track Created: 2012-04-11 diff --git a/bip-0032.mediawiki b/bip-0032.mediawiki index 0c660ad..9ca80ef 100644 --- a/bip-0032.mediawiki +++ b/bip-0032.mediawiki @@ -1,4 +1,5 @@ RECENT CHANGES: +* (24 Feb 2017) Added test vectors for hardened derivation with leading zeros * (16 Apr 2013) Added private derivation for i ≥ 0x80000000 (less risk of parent private key leakage) * (30 Apr 2013) Switched from multiplication by I<sub>L</sub> to addition of I<sub>L</sub> (faster, easier implementation) * (25 May 2013) Added test vectors @@ -6,11 +7,15 @@ RECENT CHANGES: <pre> BIP: 32 + Layer: Applications Title: Hierarchical Deterministic Wallets Author: Pieter Wuille <pieter.wuille@gmail.com> + Comments-Summary: No comments yet. + Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0032 Status: Final Type: Informational Created: 2012-02-11 + License: BSD-2-Clause </pre> ==Abstract== @@ -21,6 +26,10 @@ The specification is intended to set a standard for deterministic wallets that c The specification consists of two parts. In a first part, a system for deriving a tree of keypairs from a single seed is presented. The second part demonstrates how to build a wallet structure on top of such a tree. +==Copyright== + +This BIP is licensed under the 2-clause BSD license. + ==Motivation== The Bitcoin reference client uses randomly generated keys. In order to avoid the necessity for a backup after every transaction, (by default) 100 keys are cached in a pool of reserve keys. Still, these wallets are not intended to be shared and used on several systems simultaneously. They support hiding their private keys by using the wallet encrypt feature and not sharing the password, but such "neutered" wallets lose the power to generate public keys as well. @@ -251,6 +260,18 @@ Seed (hex): fffcf9f6f3f0edeae7e4e1dedbd8d5d2cfccc9c6c3c0bdbab7b4b1aeaba8a5a29f9c ** ext pub: xpub6FnCn6nSzZAw5Tw7cgR9bi15UV96gLZhjDstkXXxvCLsUXBGXPdSnLFbdpq8p9HmGsApME5hQTZ3emM2rnY5agb9rXpVGyy3bdW6EEgAtqt ** ext prv: xprvA2nrNbFZABcdryreWet9Ea4LvTJcGsqrMzxHx98MMrotbir7yrKCEXw7nadnHM8Dq38EGfSh6dqA9QWTyefMLEcBYJUuekgW4BYPJcr9E7j +===Test vector 3=== + +These vectors test for the retention of leading zeros. See [https://github.com/bitpay/bitcore-lib/issues/47 bitpay/bitcore-lib#47] and [https://github.com/iancoleman/bip39/issues/58 iancoleman/bip39#58] for more information. + +Seed (hex): 4b381541583be4423346c643850da4b320e46a87ae3d2a4e6da11eba819cd4acba45d239319ac14f863b8d5ab5a0d0c64d2e8a1e7d1457df2e5a3c51c73235be +* Chain m +** ext pub: xpub661MyMwAqRbcEZVB4dScxMAdx6d4nFc9nvyvH3v4gJL378CSRZiYmhRoP7mBy6gSPSCYk6SzXPTf3ND1cZAceL7SfJ1Z3GC8vBgp2epUt13 +** ext prv: xprv9s21ZrQH143K25QhxbucbDDuQ4naNntJRi4KUfWT7xo4EKsHt2QJDu7KXp1A3u7Bi1j8ph3EGsZ9Xvz9dGuVrtHHs7pXeTzjuxBrCmmhgC6 +* Chain m/0<sub>H</sub> +** ext pub: xpub68NZiKmJWnxxS6aaHmn81bvJeTESw724CRDs6HbuccFQN9Ku14VQrADWgqbhhTHBaohPX4CjNLf9fq9MYo6oDaPPLPxSb7gwQN3ih19Zm4Y +** ext prv: xprv9uPDJpEQgRQfDcW7BkF7eTya6RPxXeJCqCJGHuCJ4GiRVLzkTXBAJMu2qaMWPrS7AANYqdq6vcBcBUdJCVVFceUvJFjaPdGZ2y9WACViL4L + ==Implementations== Two Python implementations exist: diff --git a/bip-0033.mediawiki b/bip-0033.mediawiki index 6768e19..d95357d 100644 --- a/bip-0033.mediawiki +++ b/bip-0033.mediawiki @@ -1,7 +1,10 @@ <pre> BIP: 33 + Layer: Peer Services Title: Stratized Nodes Author: Amir Taaki <genjix@riseup.net> + Comments-Summary: No comments yet. + Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0033 Status: Draft Type: Standards Track Created: 2012-05-15 diff --git a/bip-0034.mediawiki b/bip-0034.mediawiki index 4870fc1..a993b7e 100644 --- a/bip-0034.mediawiki +++ b/bip-0034.mediawiki @@ -1,7 +1,10 @@ <pre> BIP: 34 + Layer: Consensus (soft fork) Title: Block v2, Height in Coinbase Author: Gavin Andresen <gavinandresen@gmail.com> + Comments-Summary: No comments yet. + Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0034 Status: Final Type: Standards Track Created: 2012-07-06 diff --git a/bip-0035.mediawiki b/bip-0035.mediawiki index c66735c..64edaf5 100644 --- a/bip-0035.mediawiki +++ b/bip-0035.mediawiki @@ -1,7 +1,10 @@ <pre> BIP: 35 + Layer: Peer Services Title: mempool message Author: Jeff Garzik <jgarzik@exmulti.com> + Comments-Summary: No comments yet. + Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0035 Status: Final Type: Standards Track Created: 2012-08-16 diff --git a/bip-0036.mediawiki b/bip-0036.mediawiki index 9c61fdb..d3e36f4 100644 --- a/bip-0036.mediawiki +++ b/bip-0036.mediawiki @@ -1,10 +1,14 @@ <pre> BIP: 36 + Layer: Peer Services Title: Custom Services Author: Stefan Thomas <justmoon@members.fsf.org> + Comments-Summary: No comments yet. + Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0036 Status: Draft Type: Standards Track Created: 2012-08-03 + License: PD </pre> ==Abstract== diff --git a/bip-0037.mediawiki b/bip-0037.mediawiki index eba0628..d817bc0 100644 --- a/bip-0037.mediawiki +++ b/bip-0037.mediawiki @@ -1,11 +1,15 @@ <pre> BIP: 37 + Layer: Peer Services Title: Connection Bloom filtering Author: Mike Hearn <hearn@google.com> Matt Corallo <bip37@bluematt.me> + Comments-Summary: No comments yet. + Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0037 Status: Final Type: Standards Track Created: 2012-10-24 + License: PD </pre> ==Abstract== diff --git a/bip-0038.mediawiki b/bip-0038.mediawiki index 650b7d0..bfe1f4a 100644 --- a/bip-0038.mediawiki +++ b/bip-0038.mediawiki @@ -1,11 +1,15 @@ <pre> BIP: 38 + Layer: Applications Title: Passphrase-protected private key Author: Mike Caldwell <mcaldwell@swipeclock.com> Aaron Voisine <voisine@gmail.com> + Comments-Summary: Unanimously Discourage for implementation + Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0038 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 + License: PD </pre> ==Abstract== diff --git a/bip-0039.mediawiki b/bip-0039.mediawiki index 3c95d4d..6ba8af0 100644 --- a/bip-0039.mediawiki +++ b/bip-0039.mediawiki @@ -1,11 +1,14 @@ <pre> BIP: 39 + Layer: Applications 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: Accepted + Comments-Summary: Unanimously Discourage for implementation + Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0039 + Status: Proposed Type: Standards Track Created: 2013-09-10 </pre> @@ -33,7 +36,7 @@ sentences (also known as brainwallets) into a wallet seed. The mnemonic must encode entropy in a multiple of 32 bits. With more entropy security is improved but the sentence length increases. We refer to the -initial entropy length as ENT. The recommended size of ENT is 128-256 bits. +initial entropy length as ENT. The allowed size of ENT is 128-256 bits. First, an initial entropy of ENT bits is generated. A checksum is generated by taking the first <pre>ENT / 32</pre> bits of its SHA256 hash. This checksum is diff --git a/bip-0039/bip-0039-wordlists.md b/bip-0039/bip-0039-wordlists.md index aef1a23..b2957cc 100644 --- a/bip-0039/bip-0039-wordlists.md +++ b/bip-0039/bip-0039-wordlists.md @@ -1,4 +1,4 @@ -#Wordlists +# Wordlists * [English](english.txt) * [Japanese](japanese.txt) @@ -8,9 +8,9 @@ * [French](french.txt) * [Italian](italian.txt) -##Wordlists (Special Considerations) +## Wordlists (Special Considerations) -###Japanese +### Japanese 1. **Developers implementing phrase generation or checksum verification must separate words using ideographic spaces / accommodate users inputting ideographic spaces.** (UTF-8 bytes: **0xE38080**; C/C+/Java: **"\u3000"**; Python: **u"\u3000"**) @@ -23,7 +23,7 @@ separated phrase or tries to split the phrase input by the user, dealing with AS ideographic spaces may be a necessary step. As a long word split in two could be mistaken easily for two smaller words (This would be a problem with any of the 3 character sets in Japanese) -###Spanish +### Spanish 1. Words can be uniquely determined typing the first 4 characters (sometimes less). @@ -31,12 +31,12 @@ for two smaller words (This would be a problem with any of the 3 character sets 3. There are no words in common between the Spanish wordlist and any other language wordlist, therefore it is possible to detect the language with just one word. -###Chinese +### Chinese 1. Chinese text typically does not use any spaces as word separators. For the sake of uniformity, we propose to use normal ASCII spaces (0x20) to separate words as per standard. -###French +### French Credits: @Kirvx @NicolasDorier @ecdsa @EricLarch ([The pull request](https://github.com/bitcoin/bips/issues/152)) diff --git a/bip-0042.mediawiki b/bip-0042.mediawiki index d7ce71c..00ac10c 100644 --- a/bip-0042.mediawiki +++ b/bip-0042.mediawiki @@ -1,10 +1,14 @@ <pre> BIP: 42 + Layer: Consensus (soft fork) Title: A finite monetary supply for Bitcoin Author: Pieter Wuille <pieter.wuille@gmail.com> + Comments-Summary: Unanimously Recommended for implementation + Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0042 Status: Draft Type: Standards Track Created: 2014-04-01 + License: PD </pre> ==Abstract== diff --git a/bip-0043.mediawiki b/bip-0043.mediawiki index 686221a..85578d8 100644 --- a/bip-0043.mediawiki +++ b/bip-0043.mediawiki @@ -1,8 +1,11 @@ <pre> BIP: 43 + Layer: Applications Title: Purpose Field for Deterministic Wallets Author: Marek Palatinus <slush@satoshilabs.com> Pavol Rusnak <stick@satoshilabs.com> + Comments-Summary: No comments yet. + Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0043 Status: Draft Type: Informational Created: 2014-04-24 diff --git a/bip-0044.mediawiki b/bip-0044.mediawiki index cafe6e1..5ee2209 100644 --- a/bip-0044.mediawiki +++ b/bip-0044.mediawiki @@ -1,9 +1,12 @@ <pre> BIP: 44 + Layer: Applications Title: Multi-Account Hierarchy for Deterministic Wallets Author: Marek Palatinus <slush@satoshilabs.com> Pavol Rusnak <stick@satoshilabs.com> - Status: Accepted + Comments-Summary: Mixed review (one person) + Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0044 + Status: Proposed Type: Standards Track Created: 2014-04-24 </pre> diff --git a/bip-0045.mediawiki b/bip-0045.mediawiki index 757fc7f..d364784 100644 --- a/bip-0045.mediawiki +++ b/bip-0045.mediawiki @@ -1,10 +1,13 @@ <pre> BIP: 45 + Layer: Applications 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: Accepted + Comments-Summary: No comments yet. + Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0045 + Status: Proposed Type: Standards Track Created: 2014-04-25 </pre> diff --git a/bip-0047.mediawiki b/bip-0047.mediawiki index b1145b3..ef680a0 100644 --- a/bip-0047.mediawiki +++ b/bip-0047.mediawiki @@ -5,8 +5,11 @@ RECENT CHANGES: <pre> BIP: 47 + Layer: Applications Title: Reusable Payment Codes for Hierarchical Deterministic Wallets Author: Justus Ranvier <justus@openbitcoinprivacyproject.org> + Comments-Summary: Unanimously Discourage for implementation + Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0047 Status: Draft Type: Informational Created: 2015-04-24 diff --git a/bip-0049.mediawiki b/bip-0049.mediawiki index 4460ba7..109fde8 100644 --- a/bip-0049.mediawiki +++ b/bip-0049.mediawiki @@ -1,10 +1,14 @@ <pre> BIP: 49 + Layer: Applications Title: Derivation scheme for P2WPKH-nested-in-P2SH based accounts Author: Daniel Weigl <Daniel.Weigl@mycelium.com> + Comments-Summary: No comments yet. + Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0049 Status: Draft Type: Informational Created: 2016-05-19 + License: PD </pre> ==Abstract== @@ -101,4 +105,4 @@ This BIP is not backwards compatible by design as described under [#consideratio == Copyright == -This document is placed in the public domain.
\ No newline at end of file +This document is placed in the public domain. diff --git a/bip-0050.mediawiki b/bip-0050.mediawiki index fbc1c0f..0b41c8d 100644 --- a/bip-0050.mediawiki +++ b/bip-0050.mediawiki @@ -2,9 +2,12 @@ BIP: 50 Title: March 2013 Chain Fork Post-Mortem Author: Gavin Andresen <gavinandresen@gmail.com> + Comments-Summary: No comments yet. + Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0050 Status: Final Type: Informational Created: 2013-03-20 + License: PD </pre> ==What went wrong== diff --git a/bip-0060.mediawiki b/bip-0060.mediawiki index ae9592a..8e9f289 100644 --- a/bip-0060.mediawiki +++ b/bip-0060.mediawiki @@ -1,10 +1,14 @@ <pre> BIP: 60 + Layer: Peer Services Title: Fixed Length "version" Message (Relay-Transactions Field) Author: Amir Taaki <genjix@riseup.net> + Comments-Summary: Discouraged for implementation (one person) + Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0060 Status: Draft Type: Standards Track Created: 2013-06-16 + License: PD </pre> ==Abstract== diff --git a/bip-0061.mediawiki b/bip-0061.mediawiki index aca329a..1e3d41f 100644 --- a/bip-0061.mediawiki +++ b/bip-0061.mediawiki @@ -1,7 +1,10 @@ <pre> BIP: 61 + Layer: Peer Services Title: Reject P2P message Author: Gavin Andresen <gavinandresen@gmail.com> + Comments-Summary: Controversial; some recommendation, and some discouragement + Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0061 Status: Final Type: Standards Track Created: 2014-06-18 diff --git a/bip-0062.mediawiki b/bip-0062.mediawiki index 28b20dd..7dd2b5b 100644 --- a/bip-0062.mediawiki +++ b/bip-0062.mediawiki @@ -2,17 +2,25 @@ <pre> BIP: 62 + Layer: Consensus (soft fork) Title: Dealing with malleability Author: Pieter Wuille <pieter.wuille@gmail.com> + Comments-Summary: No comments yet. + Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0062 Status: Withdrawn Type: Standards Track Created: 2014-03-12 + License: BSD-2-Clause </pre> ==Abstract== This document specifies proposed changes to the Bitcoin transaction validity rules in order to make malleability of transactions impossible (at least when the sender doesn't choose to avoid it). +==Copyright== + +This BIP is licensed under the 2-clause BSD license. + ==Motivation== As of february 2014, Bitcoin transactions are malleable in multiple ways. This means a (valid) transaction can be modified in-flight, without invalidating it, but without access to the relevant private keys. diff --git a/bip-0064.mediawiki b/bip-0064.mediawiki index b03dcac..22e56ba 100644 --- a/bip-0064.mediawiki +++ b/bip-0064.mediawiki @@ -1,7 +1,10 @@ <pre> BIP: 64 + Layer: Peer Services Title: getutxo message Author: Mike Hearn <hearn@vinumeris.com> + Comments-Summary: No comments yet. + Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0064 Status: Draft Type: Standards Track Created: 2014-06-10 @@ -100,4 +103,4 @@ results. ==Implementation== -https://github.com/bitcoin/bitcoin/pull/4351/files
\ No newline at end of file +https://github.com/bitcoin/bitcoin/pull/4351/files diff --git a/bip-0065.mediawiki b/bip-0065.mediawiki index 99298bf..904dc16 100644 --- a/bip-0065.mediawiki +++ b/bip-0065.mediawiki @@ -1,10 +1,14 @@ <pre> BIP: 65 + Layer: Consensus (soft fork) Title: OP_CHECKLOCKTIMEVERIFY Author: Peter Todd <pete@petertodd.org> + Comments-Summary: No comments yet. + Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0065 Status: Final Type: Standards Track Created: 2014-10-01 + License: PD </pre> ==Abstract== diff --git a/bip-0066.mediawiki b/bip-0066.mediawiki index 1235afd..a47c82d 100644 --- a/bip-0066.mediawiki +++ b/bip-0066.mediawiki @@ -1,16 +1,24 @@ <pre> BIP: 66 + Layer: Consensus (soft fork) Title: Strict DER signatures Author: Pieter Wuille <pieter.wuille@gmail.com> + Comments-Summary: No comments yet. + Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0066 Status: Final Type: Standards Track Created: 2015-01-10 + License: BSD-2-Clause </pre> ==Abstract== This document specifies proposed changes to the Bitcoin transaction validity rules to restrict signatures to strict DER encoding. +==Copyright== + +This BIP is licensed under the 2-clause BSD license. + ==Motivation== Bitcoin's reference implementation currently relies on OpenSSL for signature validation, which means it is implicitly defining Bitcoin's block validity rules. Unfortunately, OpenSSL is not designed for consensus-critical behaviour (it does not guarantee bug-for-bug compatibility between versions), and thus changes to it can - and have - affected Bitcoin software. diff --git a/bip-0067.mediawiki b/bip-0067.mediawiki index 13e2ed9..9baf6c0 100644 --- a/bip-0067.mediawiki +++ b/bip-0067.mediawiki @@ -1,12 +1,16 @@ <pre> BIP: 67 + Layer: Applications Title: Deterministic Pay-to-script-hash multi-signature addresses through public key sorting Author: Thomas Kerin <me@thomaskerin.io> Jean-Pierre Rupp <root@haskoin.com> Ruben de Vries <ruben@rubensayshi.com> - Status: Accepted + Comments-Summary: No comments yet. + Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0067 + Status: Proposed Type: Standards Track Created: 2015-02-08 + License: PD </pre> ==Abstract== @@ -126,3 +130,8 @@ The authors wish to thank BtcDrak and Luke-Jr for their involvement & contributi == References == <references> + + +== Copyright == +This document is placed in the public domain. + diff --git a/bip-0068.mediawiki b/bip-0068.mediawiki index 923441e..ea0761d 100644 --- a/bip-0068.mediawiki +++ b/bip-0068.mediawiki @@ -1,10 +1,13 @@ <pre> BIP: 68 + Layer: Consensus (soft fork) 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> + Comments-Summary: No comments yet. + Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0068 Status: Final Type: Standards Track Created: 2015-05-28 diff --git a/bip-0069.mediawiki b/bip-0069.mediawiki index 832438c..e9f9245 100644 --- a/bip-0069.mediawiki +++ b/bip-0069.mediawiki @@ -1,11 +1,15 @@ <pre> BIP: 69 + Layer: Applications Title: Lexicographical Indexing of Transaction Inputs and Outputs Author: Kristov Atlas <kristov@openbitcoinprivacyproject.org> Editor: Daniel Cousens <bips@dcousens.com> - Status: Accepted + Comments-Summary: No comments yet. + Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0069 + Status: Proposed Type: Informational Created: 2015-06-12 + License: PD </pre> ==Abstract== @@ -26,11 +30,6 @@ Since wallet clients are left to their own devices to determine this ordering, t For example, a wallet client might naively order inputs based on when addresses were added to a wallet by the user through importing or random generation. Many wallets will place spending outputs first and change outputs second, leaking information about both the sender and receiver’s finances to passive blockchain observers. Such information should remain private not only for the benefit of consumers, but in higher order financial systems must be kept secret to prevent fraud. -Currently, there is no clear standard for how wallet clients ought to order transaction inputs and outputs. -Since wallet clients are left to their own devices to determine this ordering, they often leak information about their users’ finances. -For example, a wallet client might naively order inputs based on when addresses were added to a wallet by the user through importing or random generation. -Many wallets will place spending outputs first and change outputs second, leaking information about both the sender and receiver’s finances to passive blockchain observers. -Such information should remain private not only for the benefit of consumers, but in higher order financial systems must be kept secret to prevent fraud. A researcher recently demonstrated this principle when he detected that Bitstamp leaked information when creating exchange transactions, enabling potential espionage among traders. [1] One way to address these privacy weaknesses is by randomizing the order of inputs and outputs. [2] diff --git a/bip-0070.mediawiki b/bip-0070.mediawiki index e3c17cf..28349ee 100644 --- a/bip-0070.mediawiki +++ b/bip-0070.mediawiki @@ -1,8 +1,11 @@ <pre> BIP: 70 + Layer: Applications Title: Payment Protocol Author: Gavin Andresen <gavinandresen@gmail.com> Mike Hearn <mhearn@bitcoinfoundation.org> + Comments-Summary: No comments yet. + Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0070 Status: Final Type: Standards Track Created: 2013-07-29 diff --git a/bip-0071.mediawiki b/bip-0071.mediawiki index 1fc8489..b4e9def 100644 --- a/bip-0071.mediawiki +++ b/bip-0071.mediawiki @@ -1,7 +1,10 @@ <pre> BIP: 71 + Layer: Applications Title: Payment Protocol MIME types Author: Gavin Andresen <gavinandresen@gmail.com> + Comments-Summary: No comments yet. + Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0071 Status: Final Type: Standards Track Created: 2013-07-29 diff --git a/bip-0072.mediawiki b/bip-0072.mediawiki index 4dcc48b..d5e295e 100644 --- a/bip-0072.mediawiki +++ b/bip-0072.mediawiki @@ -1,7 +1,10 @@ <pre> BIP: 72 + Layer: Applications Title: bitcoin: uri extensions for Payment Protocol Author: Gavin Andresen <gavinandresen@gmail.com> + Comments-Summary: No comments yet. + Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0072 Status: Final Type: Standards Track Created: 2013-07-29 diff --git a/bip-0073.mediawiki b/bip-0073.mediawiki index 41c89a3..e8a37a5 100644 --- a/bip-0073.mediawiki +++ b/bip-0073.mediawiki @@ -1,7 +1,10 @@ <pre> BIP: 73 + Layer: Applications Title: Use "Accept" header for response type negotiation with Payment Request URLs Author: Stephen Pair <stephen@bitpay.com> + Comments-Summary: No comments yet. + Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0073 Status: Final Type: Standards Track Created: 2013-08-27 diff --git a/bip-0074.mediawiki b/bip-0074.mediawiki index a860b38..01fcf2c 100644 --- a/bip-0074.mediawiki +++ b/bip-0074.mediawiki @@ -1,10 +1,14 @@ <pre> BIP: 74 + Layer: Applications Title: Allow zero value OP_RETURN in Payment Protocol Author: Toby Padilla <tobypadilla@gmail.com> + Comments-Summary: Unanimously Discourage for implementation + Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0074 Status: Draft Type: Standards Track Created: 2016-01-29 + License: PD </pre> ==Abstract== diff --git a/bip-0075.mediawiki b/bip-0075.mediawiki index 11fa43b..1a8474f 100644 --- a/bip-0075.mediawiki +++ b/bip-0075.mediawiki @@ -1,13 +1,17 @@ <pre> BIP: 75 + Layer: Applications Title: Out of Band Address Exchange using Payment Protocol Encryption Author: Justin Newton <justin@netki.com> Matt David <mgd@mgddev.com> Aaron Voisine <voisine@gmail.com> James MacWhyte <macwhyte@gmail.com> + Comments-Summary: Recommended for implementation (one person) + Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0075 Status: Draft Type: Standards Track Created: 2015-11-20 + License: CC-BY-4.0 </pre> ==Abstract== @@ -21,6 +25,12 @@ This BIP is an extension to BIP 70 that provides two enhancements to the existin The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. +==Copyright== + +<img src="https://licensebuttons.net/l/by/4.0/88x31.png"> + +This work is licensed under a [[http://creativecommons.org/licenses/by/4.0/|Creative Commons Attribution 4.0 International License]]. + ==Definitions== {| class="wikitable" | Sender || Entity wishing to transfer value that they control @@ -105,7 +115,7 @@ message InvoiceRequest { {| class="wikitable" ! Field Name !! Description |- -| sender_public_key || Sender's EC public key +| sender_public_key || Sender's SEC-encoded EC public key |- | amount || amount is integer-number-of-satoshis (default: 0) |- @@ -141,7 +151,7 @@ message ProtocolMessage { required ProtocolMessageType message_type = 3; required bytes serialized_message = 4; optional string status_message = 5; - optional bytes identifier = 6; + required bytes identifier = 6; } </pre> @@ -158,7 +168,7 @@ message ProtocolMessage { |- |status_message || Human-readable Payment Protocol status message |- -|identifier || Unique key to identify this entire exchange on the server. SHA256 of initial serialized InvoiceRequest SHOULD be used by default +|identifier || Unique key to identify this entire exchange on the server. Default value SHOULD be SHA256(Serialized Initial InvoiceRequest + Current Epoch Time in Seconds as a String) |} ===Versioning=== @@ -177,7 +187,7 @@ message EncryptedProtocolMessage { required bytes receiver_public_key = 5; required bytes sender_public_key = 6; required uint64 nonce = 7; - optional bytes identifier = 8; + required bytes identifier = 8; optional string status_message = 9; optional bytes signature = 10; } @@ -193,13 +203,13 @@ message EncryptedProtocolMessage { |- | encrypted_message || AES-256-GCM Encrypted (as defined in BIP75) Payment Protocol Message |- -| receiver_public_key || Receiver's DER-encoded EC Public Key +| receiver_public_key || Receiver's SEC-encoded EC Public Key |- -| sender_public_key || Sender's DER-encoded EC Public Key +| sender_public_key || Sender's SEC-encoded EC Public Key |- | nonce || Microseconds since epoch |- -| identifier || Unique key to identify this entire exchange on the server. SHA256 of initial serialized InvoiceRequest SHOULD be used by default +| identifier || Unique key to identify this entire exchange on the server. Default value SHOULD be SHA256(Serialized Initial InvoiceRequest + Current Epoch Time in Seconds as a String) |- | status_message || Human-readable Payment Protocol status message |- @@ -320,13 +330,13 @@ For the following we assume the Sender already knows the Receiver's public key, * If '''pki_type''' is x509+sha256 and '''signature''' is valid for the serialized [[#InvoiceRequest|InvoiceRequest]] where signature is set to "", [[#InvoiceRequest|InvoiceRequest]] is VALID ===Sending Encrypted Payment Protocol Messages using EncryptedProtocolMessages=== -* Encrypt the serialized Payment Protocol message using AES-256-CBC setup as described in [[#ECDH_Point_Generation_and_AES256_GCM_Mode_Setup|ECDH Point Generation and AES-256 (GCM Mode) Setup]] +* Encrypt the serialized Payment Protocol message using AES-256-GCM setup as described in [[#ECDH_Point_Generation_and_AES256_GCM_Mode_Setup|ECDH Point Generation and AES-256 (GCM Mode) Setup]] * Create [[#EncryptedProtocolMessage|EncryptedProtocolMessage]] message * Set '''encrypted_message''' to be the encrypted value of the Payment Protocol message * '''version''' SHOULD be set to the highest version number the client understands (currently 1) * '''sender_public_key''' MUST be set to the public key of the Sender's EC keypair * '''receiver_public_key''' MUST be set to the public key of the Receiver's EC keypair -* '''nonce''' MUST be set to the nonce used in the AES-256-CBC encryption operation +* '''nonce''' MUST be set to the nonce used in the AES-256-GCM encryption operation * Set '''identifier''' to the identifier value received in the originating InvoiceRequest's ProtocolMessage or EncryptedProtocolMessage wrapper message * Set '''signature''' to "" * Sign the serialized [[#EncryptedProtocolMessage|EncryptedProtocolMessage]] message with the communicating party's EC public key @@ -362,7 +372,7 @@ When either '''status_code''' OR '''status_message''' are present, the AES-256 G Initial public key retrieval for [[#InvoiceRequest|InvoiceRequest]] encryption via [[#EncryptedProtocolMessage|EncryptedProtocolMessage]] encapsulation can be done in a number of ways including, but not limited to, the following: # Wallet Name public key asset type resolution - DNSSEC-validated name resolution returns Base64 encoded DER-formatted EC public key via TXT Record [https://www.ietf.org/rfc/rfc5480.txt RFC 5480] # Key Server lookup - Key Server lookup (similar to PGP's pgp.mit.edu) based on key server identifier (i.e., e-mail address) returns Base64 encoded DER-formatted EC public key [https://www.ietf.org/rfc/rfc5480.txt RFC 5480] -# QR Code - Use of QR-code to encode DER-formatted EC public key [https://www.ietf.org/rfc/rfc5480.txt RFC 5480] +# QR Code - Use of QR-code to encode SEC-formatted EC public key [https://www.ietf.org/rfc/rfc5480.txt RFC 5480] # Address Service Public Key Exposure ==Payment / PaymentACK Messages with a HTTP Store & Forward Server== @@ -376,7 +386,8 @@ If a Store & Forward server wishes to protect themselves from spam or abuse, the Clients SHOULD keep in mind Receivers can broadcast a transaction without returning an ACK. If a Payment message needs to be updated, it SHOULD include at least one input referenced in the original transaction to prevent the Receiver from broadcasting both transactions and getting paid twice. ==Public Key & Signature Encoding== -* All EC public keys ('''sender_public_key''', '''receiver_public_key''') or x.509 certificates included in any message defined in this BIP MUST be DER [ITU.X690.1994] encoded. +* All x.509 certificates included in any message defined in this BIP MUST be DER [ITU.X690.1994] encoded. +* All EC public keys ('''sender_public_key''', '''receiver_public_key''') in any message defined in this BIP MUST be [[SECP256k1|http://www.secg.org/sec2-v2.pdf]] ECDSA Public Key ECPoints encoded using [[SEC 2.3.3 Encoding|http://www.secg.org/sec1-v2.pdf]]. Encoding MAY be compressed. * All ECC signatures included in any message defined in this BIP MUST use the SHA-256 hashing algorithm and MUST be DER [ITU.X690.1994] encoded. * All OpenPGP certificates must follow [[https://tools.ietf.org/html/rfc4880|RFC4880]], sections 5.5 and 12.1. diff --git a/bip-0075/paymentrequest.proto b/bip-0075/paymentrequest.proto index 5a08192..5097abb 100644 --- a/bip-0075/paymentrequest.proto +++ b/bip-0075/paymentrequest.proto @@ -70,7 +70,7 @@ message ProtocolMessage { required ProtocolMessageType message_type = 3; // Message Type of serialized_message required bytes serialized_message = 4; // Serialized Payment Protocol Message optional string status_message = 5; // Human-readable Payment Protocol status message - optional bytes identifier = 6; // Unique key to identify this entire exchange on the server. SHA256 of initial serialized InvoiceRequest SHOULD be used by default + required bytes identifier = 6; // Unique key to identify this entire exchange on the server. Default value SHOULD be SHA256(Serialized Initial InvoiceRequest + Current Epoch Time in Seconds as a String) } message EncryptedProtocolMessage { @@ -81,7 +81,7 @@ message EncryptedProtocolMessage { required bytes receiver_public_key = 5; // Receiver's DER-encoded EC Public Key required bytes sender_public_key = 6; // Sender's DER-encoded EC Public Key required uint64 nonce = 7; // Microseconds since epoch - optional bytes identifier = 8; // Unique key to identify this entire exchange on the server. SHA256 of initial serialized InvoiceRequest SHOULD be used by default + required bytes identifier = 8; // Unique key to identify this entire exchange on the server. Default value SHOULD be SHA256(Serialized Initial InvoiceRequest + Current Epoch Time in Seconds as a String) optional string status_message = 9; // Human-readable Payment Protocol status message optional bytes signature = 10; // Signature over the full EncryptedProtocolMessage with EC Key Belonging to Sender / Receiver, respectively }
\ No newline at end of file diff --git a/bip-0080.mediawiki b/bip-0080.mediawiki index 05322e0..2c4d8a7 100644 --- a/bip-0080.mediawiki +++ b/bip-0080.mediawiki @@ -3,9 +3,12 @@ Title: Hierarchy for Non-Colored Voting Pool Deterministic Multisig Wallets Author: Justus Ranvier <justus@opentransactions.org> Jimmy Song <jimmy@monetas.net> + Comments-Summary: No comments yet. + Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0080 Status: Deferred Type: Informational Created: 2014-08-11 + License: PD </pre> ==Abstract== diff --git a/bip-0081.mediawiki b/bip-0081.mediawiki index 713cb57..e88ee14 100644 --- a/bip-0081.mediawiki +++ b/bip-0081.mediawiki @@ -3,9 +3,12 @@ Title: Hierarchy for Colored Voting Pool Deterministic Multisig Wallets Author: Justus Ranvier <justus@opentransactions.org> Jimmy Song <jimmy@monetas.net> + Comments-Summary: No comments yet. + Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0081 Status: Deferred Type: Informational Created: 2014-08-11 + License: PD </pre> ==Abstract== diff --git a/bip-0083.mediawiki b/bip-0083.mediawiki index f6aa8e7..a0b1e5e 100644 --- a/bip-0083.mediawiki +++ b/bip-0083.mediawiki @@ -1,10 +1,14 @@ <pre> BIP: 83 + Layer: Applications Title: Dynamic Hierarchical Deterministic Key Trees Author: Eric Lombrozo <eric@ciphrex.com> + Comments-Summary: No comments yet. + Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0083 Status: Draft Type: Standards Track Created: 2015-11-16 + License: PD </pre> ==Abstract== diff --git a/bip-0090.mediawiki b/bip-0090.mediawiki new file mode 100644 index 0000000..a2d3456 --- /dev/null +++ b/bip-0090.mediawiki @@ -0,0 +1,100 @@ +<pre> + BIP: 90 + Layer: Consensus (hard fork) + Title: Buried Deployments + Author: Suhas Daftuar <sdaftuar@chaincode.com> + Comments-Summary: Mostly Recommended for implementation, with some Discouragement + Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0090 + Status: Draft + Type: Informational + Created: 2016-11-08 + License: PD +</pre> + + +==Abstract== + +Prior soft forks (BIP 34, BIP 65, and BIP 66) were activated via miner signaling in block version numbers. Now that the chain has long since passed the blocks at which those consensus rules have triggered, we can (as a simplification) replace the trigger mechanism by caching the block heights at which those consensus rules became enforced. + +==Motivation== + +BIPs 34, 65 and 66 were deployed on mainnet using miner signaling using block version numbers. In short, new consensus rules were proposed for use in blocks with a higher version number (N+1) than the prevailing block version (N) in use on the network, and those rules became enforced under the following conditions: +# 75% rule: If 750 of the prior 1000 blocks are version N+1 or higher, then blocks with version N+1 or higher must correctly enforce the new consensus rule. +# 95% rule: If 950 of the prior 1000 blocks are version N+1 or higher, then blocks with version less than N+1 are invalid. + +Please see those [[#References|BIPs]] for more details. + +Note that this trigger mechanism is dependent on the chain history. To validate a block, we must test whether the trigger was met by looking at the previous 1000 blocks in the chain before it, which can be inefficient. + +In addition, this mechanism for code deployments have been deprecated in favor of BIP 9 deployments, which offer several advantages (please see [https://github.com/bitcoin/bips/blob/master/bip-0009.mediawiki BIP 9]). + +Thus we propose elimination of the logic implementing these kinds of deployments, by replacing the test which governs enforcement of BIP 34, BIP 65, and BIP 66 with simple height checks, which we choose to be the block height triggering the 95% activation rule on mainnet for each of those deployments. This simplification of the consensus rules would reduce the technical debt associated with deployment of those consensus changes. + +==Considerations== + +It is technically possible for this to be a non-backwards compatible change. For example, if an alternate chain were created in which BIP 34's 95% activation triggered at a lower height (H') than it did on the current mainnet chain (H), then older software would enforce that version 1 blocks were invalid at heights between H' and H, while newer software implementing this change would not. Similarly, this BIP proposes doing away with the 75% threshold check altogether, which means, for example, that a version 2 block forking off of mainnet at height H-1 which omitted the height in coinbase would be invalid to older software, while accepted by newer software. + +However, while newer software and older software might validate old blocks differently, that could only cause a consensus split if there were an extremely large blockchain reorganization onto a chain built off such a block. As of November 2016, the most recent of these changes (BIP 65, enforced since December 2015) has nearly 50,000 blocks built on top of it. The occurrence of such a reorg that would cause the activating block to be disconnected would raise fundamental concerns about the security assumptions of Bitcoin, a far bigger issue than any non-backwards compatible change. + +So while this proposal could <i>theoretically</i> result in a consensus split, it is extremely unlikely, and in particular any such circumstances would be sufficiently damaging to the Bitcoin network to dwarf any concerns about the effects of this proposed change. + +==Specification== + +The BIP 34, 66, and 65 activation heights are set to 227931, 363725, and 388381, respectively. + +The 1000-block lookback test, first described in BIP 34, is no longer performed during validation of any blocks. Instead, a new check is added: + + if((block.nVersion < 2 && nHeight >= consensusParams.BIP34Height) || + (block.nVersion < 3 && nHeight >= consensusParams.BIP66Height) || + (block.nVersion < 4 && nHeight >= consensusParams.BIP65Height)) + return state.Invalid(false, REJECT_OBSOLETE, strprintf("bad-version(0x%08x)", block.nVersion), + strprintf("rejected nVersion=0x%08x block", block.nVersion)); + +Furthermore, rather than consider the block versions of the prior 1000 blocks to determine whether to enforce BIP 34, BIP 65, or BIP 66 on a given block, we instead just compare the height of the block being validated with the stored activation heights: + + // Enforce rule that the coinbase starts with serialized block height + if (nHeight >= consensusParams.BIP34Height) + { + CScript expect = CScript() << nHeight; + if (block.vtx[0].vin[0].scriptSig.size() < expect.size() || + !std::equal(expect.begin(), expect.end(), block.vtx[0].vin[0].scriptSig.begin())) { + return state.DoS(100, false, REJECT_INVALID, "bad-cb-height", false, "block height mismatch in coinbase"); + } + } + +and + + // Start enforcing the DERSIG (BIP66) rule + if (pindex->nHeight >= chainparams.GetConsensus().BIP66Height) { + flags |= SCRIPT_VERIFY_DERSIG; + } + + // Start enforcing CHECKLOCKTIMEVERIFY (BIP65) rule + if (pindex->nHeight >= chainparams.GetConsensus().BIP65Height) { + flags |= SCRIPT_VERIFY_CHECKLOCKTIMEVERIFY; + } + +Please see the implementation for additional details. + +==Implementation== + +https://github.com/bitcoin/bitcoin/pull/8391. + + +==References== + +[https://github.com/bitcoin/bips/blob/master/bip-0034.mediawiki BIP34 Block v2, Height in Coinbase] + +[https://github.com/bitcoin/bips/blob/master/bip-0066.mediawiki BIP66 Strict DER signatures] + +[https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki BIP65 OP_CHECKLOCKTIMEVERIFY] + +[https://github.com/bitcoin/bips/blob/master/bip-0009.mediawiki BIP9 Version bits with timeout and delay] + +==Acknowledgements== + +Thanks to Nicolas Dorier for drafting an initial version of this BIP, and to Alex Morcos, Matt Corallo, and Greg Maxwell for suggestions and feedback. + +==Copyright== + +This document is placed in the public domain. diff --git a/bip-0099.mediawiki b/bip-0099.mediawiki index 3e0a43a..cbde553 100644 --- a/bip-0099.mediawiki +++ b/bip-0099.mediawiki @@ -2,9 +2,12 @@ BIP: 99 Title: Motivation and deployment of consensus rule changes ([soft/hard]forks) Author: Jorge Timón <jtimon@jtimon.cc> + Comments-Summary: No comments yet. + Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0099 Status: Draft Type: Informational Created: 2015-06-20 + License: PD 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 cc8cfd5..0321569 100644 --- a/bip-0101.mediawiki +++ b/bip-0101.mediawiki @@ -1,7 +1,10 @@ <pre> BIP: 101 + Layer: Consensus (hard fork) Title: Increase maximum block size Author: Gavin Andresen <gavinandresen@gmail.com> + Comments-Summary: No comments yet. + Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0101 Status: Withdrawn Type: Standards Track Created: 2015-06-22 diff --git a/bip-0102.mediawiki b/bip-0102.mediawiki index fc909f7..ed6b4e3 100644 --- a/bip-0102.mediawiki +++ b/bip-0102.mediawiki @@ -1,7 +1,10 @@ <pre> BIP: 102 + Layer: Consensus (hard fork) Title: Block size increase to 2MB Author: Jeff Garzik <jgarzik@gmail.com> + Comments-Summary: No comments yet. + Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0102 Status: Draft Type: Standards Track Created: 2015-06-23 diff --git a/bip-0103.mediawiki b/bip-0103.mediawiki index 39e8a3f..36bb87f 100644 --- a/bip-0103.mediawiki +++ b/bip-0103.mediawiki @@ -1,16 +1,24 @@ <pre> BIP: 103 + Layer: Consensus (hard fork) Title: Block size following technological growth Author: Pieter Wuille <pieter.wuille@gmail.com> + Comments-Summary: No comments yet. + Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0103 Status: Draft Type: Standards Track Created: 2015-07-21 + License: BSD-2-Clause </pre> ==Abstract== This BIP proposes a block size growth intended to accommodate for hardware and other technological improvements for the foreseeable future. +==Copyright== + +This BIP is licensed under the 2-clause BSD license. + ==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. diff --git a/bip-0104.mediawiki b/bip-0104.mediawiki new file mode 100644 index 0000000..00db9a3 --- /dev/null +++ b/bip-0104.mediawiki @@ -0,0 +1,78 @@ +<pre> + BIP: 104 + Layer: Consensus (hard fork) + Title: 'Block75' - Max block size like difficulty + Author: t.khan <teekhan42@gmail.com> + Comments-Summary: No comments yet. + Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0104 + Status: Draft + Type: Standards Track + Created: 2017-01-13 + License: BSD-2-Clause + GNU-All-Permissive +</pre> + +==Abstract== + +Automatic adjustment of max block size with the target of keeping blocks 75% full, based on the average block size of the previous 2016 blocks. This would be done on the same schedule as difficulty. + +==Motivation== + +Blocks are already too full and cannot support further transaction growth. While SegWit and Lightning (and other off-chain solutions) will help, they will not solve this problem. + +Bitcoin needs a reasonably effective and predictable way of managing the maximum block size which allows moderate growth, keeps max block size as small as possible, and prevents wild swings in transaction fees. + +The every two-week and automatic adjustment of difficulty has proven to be a reasonably effective and predictable way of managing how quickly blocks are mined. It works well because humans aren’t involved (except for setting the original target of a 10 minute per block average), and therefore it isn’t political or contentious. It’s simply a response to changing network resources. + +It’s clear at this point that human beings should not be involved in the determination of max block size, just as they’re not involved in deciding the difficulty. Therefore, it is logical and consistent with Bitcoin’s design to implement a permanent solution which, as with the difficulty adjustment, is simply an automatic response to changing transaction volumes. With the target of keeping blocks 75% full on average, this is the goal of Block75. + + +==Specification== + +The max block size will be recalculated every 2016 blocks, along with difficulty, using Block75’s simple algorithm: + +<code> +new max block size = x + (x * (AVERAGE_CAPACITY - TARGET_CAPACITY)) +</code> + +* TARGET_CAPACITY = 0.75  //Block75's target of keeping blocks 75% full +* AVERAGE_CAPACITY = average percentage full of the last 2016 blocks, as a decimal +* x = current max block size + + +All code which generates/validates blocks or uses/references the current hardcoded limits will need to be changed to support Block75. + +==Rationale== + +The 75% full block target was selected because: +* it is the middle ground between blocks being too small (average 100% full) and blocks being unnecessarily large (average 50% full) +* it can handle short-term spikes in transaction volume of up to 33% +* it limits the growth of max block size to less than 25% over the previous period +* it will maintain average transaction fees at a stable level similar to that of May/June 2016 + +The 2016 block (~2 weeks) period was selected because: +* it has been shown to be reasonably adaptive to changing network resources (re: difficulty) +* the frequent and gradual adjustments that result will be relatively easy for miners and node operators to predict and adapt to, as any unforeseen consequences will be visible well in advance +* it minimizes any effect a malicious party could have in an attempt to manipulate max block size + +The Block75 algorithm will adjust the max block size up and down in response to transaction volume, including changes brought on by SegWit and Lightning. This is important as it will keep average transaction fees stable, thereby allowing miners and businesses using Bitcoin more certainty regarding future income/expenses. + +==Other solutions considered== +A hardcoded increase to max block size (2MB, 8MB, etc.), rejected because: +* only a temporary solution, whatever limit was chosen would inevitably become a problem again +* would cause transaction fees to vary wildly over time + +Allow miners to vote for max block size, rejected because: +* overly complex and political +* human involvement makes this slow to respond to changing transaction volumes +* focuses power over max block size to a relatively small group of people +* unpredictable transaction fees caused by this would create uncertainty in the ecosystem + +==Backward Compatibility== +This BIP is not backward compatible (hard fork). Any code which fully validates blocks must be upgraded prior to activation, as failure to do so will result in rejection of blocks over the current 1MB limit. + +==Activation== +To help negate some of the risks associated with a hard fork and to prevent a single relatively small mining pool from preventing Block75's adoption, activation would occur at the next difficulty adjustment once 900 of the last 1,000 blocks mined signal support and a grace period of 4,032 blocks (~1 month) has elapsed. + +==Copyright== +This BIP is dual-licensed under the BSD 2-clause license and the GNU All-Permissive License. diff --git a/bip-0105.mediawiki b/bip-0105.mediawiki index c4f0a09..125d852 100644 --- a/bip-0105.mediawiki +++ b/bip-0105.mediawiki @@ -1,10 +1,14 @@ <pre> BIP: 105 + Layer: Consensus (hard fork) Title: Consensus based block size retargeting algorithm Author: BtcDrak <btcdrak@gmail.com> + Comments-Summary: No comments yet. + Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0105 Status: Draft Type: Standards Track Created: 2015-08-21 + License: PD </pre> ==Abstract== diff --git a/bip-0106.mediawiki b/bip-0106.mediawiki index e9018fa..399c725 100644 --- a/bip-0106.mediawiki +++ b/bip-0106.mediawiki @@ -1,7 +1,10 @@ <pre> BIP: 106 + Layer: Consensus (hard fork) Title: Dynamically Controlled Bitcoin Block Size Max Cap Author: Upal Chakraborty <bitcoin@upalc.com> + Comments-Summary: No comments yet. + Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0106 Status: Draft Type: Standards Track Created: 2015-08-24 diff --git a/bip-0107.mediawiki b/bip-0107.mediawiki index 86edd99..84cd6a6 100644 --- a/bip-0107.mediawiki +++ b/bip-0107.mediawiki @@ -1,10 +1,14 @@ <pre> BIP: 107 + Layer: Consensus (hard fork) Title: Dynamic limit on the block size Author: Washington Y. Sanchez <washington.sanchez@gmail.com> + Comments-Summary: No comments yet. + Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0107 Status: Draft Type: Standards Track Created: 2015-09-11 + License: PD </pre> ==Abstract== diff --git a/bip-0109.mediawiki b/bip-0109.mediawiki index 667ef5f..69b265b 100644 --- a/bip-0109.mediawiki +++ b/bip-0109.mediawiki @@ -1,10 +1,14 @@ <pre> BIP: 109 + Layer: Consensus (hard fork) Title: Two million byte size limit with sigop and sighash limits Author: Gavin Andresen <gavinandresen@gmail.com> - Status: Draft + Comments-Summary: No comments yet. + Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0109 + Status: Rejected Type: Standards Track Created: 2016-01-28 + License: PD </pre> ==Abstract== diff --git a/bip-0111.mediawiki b/bip-0111.mediawiki index 4557832..cb5028f 100644 --- a/bip-0111.mediawiki +++ b/bip-0111.mediawiki @@ -1,11 +1,15 @@ <pre> BIP: 111 + Layer: Peer Services Title: NODE_BLOOM service bit Author: Matt Corallo <bip111@bluematt.me> Peter Todd <pete@petertodd.org> - Status: Accepted + Comments-Summary: No comments yet. + Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0111 + Status: Proposed Type: Standards Track Created: 2015-08-20 + License: PD </pre> == Abstract == diff --git a/bip-0112.mediawiki b/bip-0112.mediawiki index 40378ee..65171a4 100644 --- a/bip-0112.mediawiki +++ b/bip-0112.mediawiki @@ -1,12 +1,16 @@ <pre> BIP: 112 + Layer: Consensus (soft fork) Title: CHECKSEQUENCEVERIFY Author: BtcDrak <btcdrak@gmail.com> Mark Friedenbach <mark@friedenbach.org> Eric Lombrozo <elombrozo@gmail.com> + Comments-Summary: No comments yet. + Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0112 Status: Final Type: Standards Track Created: 2015-08-10 + License: PD </pre> ==Abstract== diff --git a/bip-0113.mediawiki b/bip-0113.mediawiki index 1c402aa..3686777 100644 --- a/bip-0113.mediawiki +++ b/bip-0113.mediawiki @@ -1,11 +1,15 @@ <pre> BIP: 113 + Layer: Consensus (soft fork) Title: Median time-past as endpoint for lock-time calculations Author: Thomas Kerin <me@thomaskerin.io> Mark Friedenbach <mark@friedenbach.org> + Comments-Summary: No comments yet. + Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0113 Status: Final Type: Standards Track Created: 2015-08-10 + License: PD </pre> diff --git a/bip-0114.mediawiki b/bip-0114.mediawiki index cb9aea7..21d0b6c 100644 --- a/bip-0114.mediawiki +++ b/bip-0114.mediawiki @@ -1,10 +1,14 @@ <pre> BIP: 114 + Layer: Consensus (soft fork) Title: Merkelized Abstract Syntax Tree Author: Johnson Lau <jl2012@xbt.hk> + Comments-Summary: No comments yet. + Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0114 Status: Draft Type: Standards Track Created: 2016-04-02 + License: PD </pre> ==Abstract== diff --git a/bip-0120.mediawiki b/bip-0120.mediawiki index 1602c65..d48cdfa 100644 --- a/bip-0120.mediawiki +++ b/bip-0120.mediawiki @@ -1,7 +1,10 @@ <pre> BIP: 120 + Layer: Applications Title: Proof of Payment Author: Kalle Rosenbaum <kalle@rosenbaum.se> + Comments-Summary: No comments yet. + Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0120 Status: Draft Type: Standards Track Created: 2015-07-28 diff --git a/bip-0121.mediawiki b/bip-0121.mediawiki index bafe856..34820f5 100644 --- a/bip-0121.mediawiki +++ b/bip-0121.mediawiki @@ -1,7 +1,10 @@ <pre> BIP: 121 + Layer: Applications Title: Proof of Payment URI scheme Author: Kalle Rosenbaum <kalle@rosenbaum.se> + Comments-Summary: No comments yet. + Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0121 Status: Draft Type: Standards Track Created: 2015-07-27 diff --git a/bip-0122.mediawiki b/bip-0122.mediawiki index 5386dd2..3fb5df8 100644 --- a/bip-0122.mediawiki +++ b/bip-0122.mediawiki @@ -1,10 +1,14 @@ <pre> BIP: 122 + Layer: Applications Title: URI scheme for Blockchain references / exploration Author: Marco Pontello <marcopon@gmail.com> + Comments-Summary: No comments yet. + Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0122 Status: Draft Type: Standards Track Created: 2015-08-29 + License: PD Post-History: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/010712.html </pre> diff --git a/bip-0123.mediawiki b/bip-0123.mediawiki index 3d40326..2404937 100644 --- a/bip-0123.mediawiki +++ b/bip-0123.mediawiki @@ -1,11 +1,14 @@ <pre> BIP: 123 - Layer: Process Title: BIP Classification Author: Eric Lombrozo <elombrozo@gmail.com> - Status: Draft + Comments-Summary: No comments yet. + Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0123 + Status: Active Type: Process Created: 2015-08-26 + License: CC0-1.0 + GNU-All-Permissive </pre> ==Abstract== @@ -16,6 +19,10 @@ BIPs are classified by system layers with lower numbered layers involving more i The specification defines the layers and sets forth specific criteria for deciding to which layer a particular standards BIP belongs. +==Copyright== + +This BIP is dual-licensed under the Creative Commons CC0 1.0 Universal and GNU All-Permissive licenses. + ==Motivation== Bitcoin is a system involving a number of different standards. Some standards are absolute requirements for interoperability while others can be considered optional, giving implementors a choice of whether to support them. @@ -31,6 +38,8 @@ Standards BIPs are placed in one of four layers: # API/RPC # Applications +Non-standards BIPs may be placed in these layers, or none at all. + ===1. Consensus Layer=== The consensus layer defines cryptographic commitment structures. Its purpose is ensuring that anyone can locally evaluate whether a particular state and history is valid, providing settlement guarantees, and assuring eventual convergence. @@ -76,19 +85,26 @@ The applications layer specifies high level structures, abstractions, and conven !Status |- style="background-color: #cfffcf" | [[bip-0001.mediawiki|1]] -| Process +| | BIP Purpose and Guidelines | Amir Taaki -| Standard +| Process | Active |- +| [[bip-0002.mediawiki|2]] +| +| BIP process, revised +| Luke Dashjr +| Process +| Draft +|- style="background-color: #cfffcf" | [[bip-0009.mediawiki|9]] -| Consensus (soft fork) +| | Version bits with timeout and delay | Pieter Wuille, Peter Todd, Greg Maxwell, Rusty Russell | Informational -| Draft -|- +| Final +|- style="background-color: #ffcfcf" | [[bip-0010.mediawiki|10]] | Applications | Multi-Sig Transaction Distribution @@ -97,11 +113,11 @@ The applications layer specifies high level structures, abstractions, and conven | Withdrawn |- style="background-color: #cfffcf" | [[bip-0011.mediawiki|11]] -| Peer Services +| Applications | M-of-N Standard Transactions | Gavin Andresen | Standard -| Accepted +| Final |- style="background-color: #ffcfcf" | [[bip-0012.mediawiki|12]] | Consensus (soft fork) @@ -122,8 +138,8 @@ The applications layer specifies high level structures, abstractions, and conven | Protocol Version and User Agent | Amir Taaki, Patrick Strateman | Standard -| Accepted -|- style="background-color: #ffcfcf" +| Final +|- | [[bip-0015.mediawiki|15]] | Applications | Aliases @@ -133,7 +149,7 @@ The applications layer specifies high level structures, abstractions, and conven |- style="background-color: #cfffcf" | [[bip-0016.mediawiki|16]] | Consensus (soft fork) -| Pay To Script Hash +| Pay to Script Hash | Gavin Andresen | Standard | Final @@ -142,18 +158,18 @@ The applications layer specifies high level structures, abstractions, and conven | Consensus (soft fork) | OP_CHECKHASHVERIFY (CHV) | Luke Dashjr +| Standard | Withdrawn -| Draft -|- +|- style="background-color: #ffffcf" | [[bip-0018.mediawiki|18]] | Consensus (soft fork) | hashScriptCheck | Luke Dashjr | Standard -| Draft +| Accepted |- | [[bip-0019.mediawiki|19]] -| Peer Services +| Applications | M-of-N Standard Transactions (Low SigOp) | Luke Dashjr | Standard @@ -171,21 +187,21 @@ The applications layer specifies high level structures, abstractions, and conven | URI Scheme | Nils Schneider, Matt Corallo | Standard -| Accepted +| Final |- style="background-color: #cfffcf" | [[bip-0022.mediawiki|22]] | API/RPC | getblocktemplate - Fundamentals | Luke Dashjr | Standard -| Accepted +| Final |- style="background-color: #cfffcf" | [[bip-0023.mediawiki|23]] | API/RPC | getblocktemplate - Pooled Mining | Luke Dashjr | Standard -| Accepted +| Final |- style="background-color: #cfffcf" | [[bip-0030.mediawiki|30]] | Consensus (soft fork) @@ -199,17 +215,17 @@ The applications layer specifies high level structures, abstractions, and conven | Pong message | Mike Hearn | Standard -| Accepted +| Final |- style="background-color: #cfffcf" | [[bip-0032.mediawiki|32]] | Applications | Hierarchical Deterministic Wallets | Pieter Wuille | Informational -| Accepted +| Final |- | [[bip-0033.mediawiki|33]] -| API/RPC +| Peer Services | Stratized Nodes | Amir Taaki | Standard @@ -217,17 +233,17 @@ The applications layer specifies high level structures, abstractions, and conven |- style="background-color: #cfffcf" | [[bip-0034.mediawiki|34]] | Consensus (soft fork) -| Block v2, Height in coinbase +| Block v2, Height in Coinbase | Gavin Andresen | Standard -| Accepted +| Final |- style="background-color: #cfffcf" | [[bip-0035.mediawiki|35]] | Peer Services | mempool message | Jeff Garzik | Standard -| Accepted +| Final |- | [[bip-0036.mediawiki|36]] | Peer Services @@ -238,38 +254,24 @@ The applications layer specifies high level structures, abstractions, and conven |- style="background-color: #cfffcf" | [[bip-0037.mediawiki|37]] | Peer Services -| Bloom filtering -| Mike Hearn and Matt Corallo +| Connection Bloom filtering +| Mike Hearn, Matt Corallo | Standard -| Accepted +| Final |- | [[bip-0038.mediawiki|38]] | Applications | Passphrase-protected private key -| Mike Caldwell +| Mike Caldwell, Aaron Voisine | Standard | Draft -|- +|- style="background-color: #ffffcf" | [[bip-0039.mediawiki|39]] | Applications | Mnemonic code for generating deterministic keys -| Slush -| Standard -| Draft -|- -| 40 -| Applications -| Stratum wire protocol -| Slush -| Standard -| BIP number allocated -|- -| 41 -| Applications -| Stratum mining protocol -| Slush +| Marek Palatinus, Pavol Rusnak, Aaron Voisine, Sean Bowe | Standard -| BIP number allocated +| Accepted |- | [[bip-0042.mediawiki|42]] | Consensus (soft fork) @@ -281,31 +283,44 @@ The applications layer specifies high level structures, abstractions, and conven | [[bip-0043.mediawiki|43]] | Applications | Purpose Field for Deterministic Wallets -| Slush -| Standard +| Marek Palatinus, Pavol Rusnak +| Informational | Draft -|- +|- style="background-color: #ffffcf" | [[bip-0044.mediawiki|44]] | Applications | Multi-Account Hierarchy for Deterministic Wallets -| Slush +| Marek Palatinus, Pavol Rusnak | Standard -| Draft -|- +| Accepted +|- style="background-color: #ffffcf" | [[bip-0045.mediawiki|45]] | Applications | Structure for Deterministic P2SH Multisignature Wallets -| Manuel Araoz +| Manuel Araoz, Ryan X. Charles, Matias Alejo Garcia | Standard +| Accepted +|- +| [[bip-0047.mediawiki|47]] +| Applications +| Reusable Payment Codes for Hierarchical Deterministic Wallets +| Justus Ranvier +| Informational | Draft |- -| [[bip-0050.mediawiki|50]] +| [[bip-0049.mediawiki|49]] +| Applications +| Derivation scheme for P2WPKH-nested-in-P2SH based accounts +| Daniel Weigl | Informational +| Draft +|- style="background-color: #cfffcf" +| [[bip-0050.mediawiki|50]] +| | March 2013 Chain Fork Post-Mortem | Gavin Andresen | Informational -| Draft -<!-- 50 series reserved for a group of post-mortems --> +| Final |- | [[bip-0060.mediawiki|60]] | Peer Services @@ -313,97 +328,118 @@ The applications layer specifies high level structures, abstractions, and conven | Amir Taaki | Standard | Draft -|- +|- style="background-color: #cfffcf" | [[bip-0061.mediawiki|61]] | Peer Services -| "reject" P2P message +| Reject P2P message | Gavin Andresen | Standard | Final -|- +|- style="background-color: #ffcfcf" | [[bip-0062.mediawiki|62]] | Consensus (soft fork) | Dealing with malleability | Pieter Wuille | Standard -| Draft -|- -| 63 -| Applications -| Stealth Addresses -| Peter Todd -| Standard -| BIP number allocated +| Withdrawn |- | [[bip-0064.mediawiki|64]] | Peer Services -| getutxos message +| getutxo message | Mike Hearn | Standard | Draft -|- +|- style="background-color: #cfffcf" | [[bip-0065.mediawiki|65]] | Consensus (soft fork) | OP_CHECKLOCKTIMEVERIFY | Peter Todd | Standard -| Draft -|- +| Final +|- style="background-color: #cfffcf" | [[bip-0066.mediawiki|66]] | Consensus (soft fork) | Strict DER signatures | Pieter Wuille | Standard -| Draft -|- +| Final +|- style="background-color: #ffffcf" | [[bip-0067.mediawiki|67]] | Applications -| 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 -|- +| Accepted +|- style="background-color: #cfffcf" | [[bip-0068.mediawiki|68]] | Consensus (soft fork) -| 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 -|- +| Final +|- style="background-color: #ffffcf" +| [[bip-0069.mediawiki|69]] +| Applications +| Lexicographical Indexing of Transaction Inputs and Outputs +| Kristov Atlas +| Informational +| Accepted +|- style="background-color: #cfffcf" | [[bip-0070.mediawiki|70]] | Applications -| Payment protocol -| Gavin Andresen +| Payment Protocol +| Gavin Andresen, Mike Hearn | Standard | Final -|- +|- style="background-color: #cfffcf" | [[bip-0071.mediawiki|71]] | Applications -| Payment protocol MIME types +| Payment Protocol MIME types | Gavin Andresen | Standard | Final -|- +|- style="background-color: #cfffcf" | [[bip-0072.mediawiki|72]] | Applications -| Payment protocol URIs +| bitcoin: uri extensions for Payment Protocol | Gavin Andresen | Standard | Final -|- +|- style="background-color: #cfffcf" | [[bip-0073.mediawiki|73]] | Applications -| 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]] +| Applications +| Allow zero value OP_RETURN in Payment Protocol +| Toby Padilla +| Standard | Draft |- -| [[bip-0080.mediawiki|80]] +| [[bip-0075.mediawiki|75]] | Applications +| Out of Band Address Exchange using Payment Protocol Encryption +| Justin Newton, Matt David, Aaron Voisine, James MacWhyte +| Standard +| Draft +|- +| [[bip-0080.mediawiki|80]] +| | Hierarchy for Non-Colored Voting Pool Deterministic Multisig Wallets -| Monetas +| Justus Ranvier, Jimmy Song | Informational -| Draft +| Deferred +|- +| [[bip-0081.mediawiki|81]] +| +| Hierarchy for Colored Voting Pool Deterministic Multisig Wallets +| Justus Ranvier, Jimmy Song +| Informational +| Deferred |- | [[bip-0083.mediawiki|83]] | Applications @@ -413,18 +449,18 @@ The applications layer specifies high level structures, abstractions, and conven | Draft |- | [[bip-0099.mediawiki|99]] -| Informational +| | 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]] | Consensus (hard fork) | Increase maximum block size | Gavin Andresen | Standard -| Draft +| Withdrawn |- | [[bip-0102.mediawiki|102]] | Consensus (hard fork) @@ -442,7 +478,7 @@ The applications layer specifies high level structures, abstractions, and conven |- | [[bip-0105.mediawiki|105]] | Consensus (hard fork) -| Consensus based block size retargetting algorithm +| Consensus based block size retargeting algorithm | BtcDrak | Standard | Draft @@ -461,25 +497,39 @@ The applications layer specifies high level structures, abstractions, and conven | Standard | Draft |- +| [[bip-0109.mediawiki|109]] +| Consensus (hard fork) +| Two million byte size limit with sigop and sighash limits +| Gavin Andresen +| Standard +| Draft +|- style="background-color: #ffffcf" | [[bip-0111.mediawiki|111]] | Peer Services | NODE_BLOOM service bit | Matt Corallo, Peter Todd | Standard -| Draft -|- +| Accepted +|- style="background-color: #cfffcf" | [[bip-0112.mediawiki|112]] | Consensus (soft fork) | CHECKSEQUENCEVERIFY | BtcDrak, Mark Friedenbach, Eric Lombrozo | Standard -| Draft -|- +| Final +|- style="background-color: #cfffcf" | [[bip-0113.mediawiki|113]] | Consensus (soft fork) -| Median time-past as endpoint for locktime calculations +| Median time-past as endpoint for lock-time calculations | Thomas Kerin, Mark Friedenbach | Standard +| Final +|- +| [[bip-0114.mediawiki|114]] +| Consensus (soft fork) +| Merkelized Abstract Syntax Tree +| Johnson Lau +| Standard | Draft |- | [[bip-0120.mediawiki|120]] @@ -504,32 +554,39 @@ The applications layer specifies high level structures, abstractions, and conven | Draft |- | [[bip-0123.mediawiki|123]] -| Process +| | BIP Classification | Eric Lombrozo -| Standard +| Process | Draft |- | [[bip-0124.mediawiki|124]] | Applications | Hierarchical Deterministic Script Templates | Eric Lombrozo, William Swanson -| Standard +| Informational | Draft -|- +|- style="background-color: #ffffcf" | [[bip-0125.mediawiki|125]] -| Peer Services +| Applications | Opt-in Full Replace-by-Fee Signaling -| David Harding, Peter Todd +| David A. Harding, Peter Todd | Standard -| Draft +| Accepted |- +| [[bip-0126.mediawiki|126]] +| +| Best Practices for Heterogeneous Input Script Transactions +| Kristov Atlas +| Informational +| Draft +|- style="background-color: #ffffcf" | [[bip-0130.mediawiki|130]] | Peer Services | sendheaders message | Suhas Daftuar | Standard -| Draft +| Accepted |- | [[bip-0131.mediawiki|131]] | Consensus (hard fork) @@ -537,12 +594,26 @@ The applications layer specifies high level structures, abstractions, and conven | Chris Priest | Standard | Draft -|- +|- style="background-color: #ffcfcf" | [[bip-0132.mediawiki|132]] -| Process +| | Committee-based BIP Acceptance Process | Andy Chase | Process +| Withdrawn +|- +| [[bip-0133.mediawiki|133]] +| Peer Services +| feefilter message +| Alex Morcos +| Standard +| Draft +|- +| [[bip-0134.mediawiki|134]] +| Consensus (hard fork) +| Flexible Transactions +| Tom Zander +| Standard | Draft |- | [[bip-0140.mediawiki|140]] @@ -564,7 +635,7 @@ The applications layer specifies high level structures, abstractions, and conven | Address Format for Segregated Witness | Johnson Lau | Standard -| Draft +| Deferred |- | [[bip-0143.mediawiki|143]] | Consensus (soft fork) @@ -578,6 +649,47 @@ The applications layer specifies high level structures, abstractions, and conven | Segregated Witness (Peer Services) | Eric Lombrozo, Pieter Wuille | Standard -| Draft +| Draft +|- +| [[bip-0145.mediawiki|145]] +| API/RPC +| getblocktemplate Updates for Segregated Witness +| Luke Dashjr +| Standard +| Draft +|- +| [[bip-0146.mediawiki|146]] +| Consensus (soft fork) +| Dealing with signature encoding malleability +| Johnson Lau, Pieter Wuille +| Standard +| Draft +|- +| [[bip-0147.mediawiki|147]] +| Consensus (soft fork) +| Dealing with dummy stack element malleability +| Johnson Lau +| Standard +| Draft +|- +| [[bip-0150.mediawiki|150]] +| Peer Services +| Peer Authentication +| Jonas Schnelli +| Standard +| Draft +|- +| [[bip-0151.mediawiki|151]] +| Peer Services +| Peer-to-Peer Communication Encryption +| Jonas Schnelli +| Standard +| Draft +|- +| [[bip-0152.mediawiki|152]] +| Peer Services +| Compact Block Relay +| Matt Corallo +| Standard +| Draft |} - diff --git a/bip-0124.mediawiki b/bip-0124.mediawiki index 2f9f4ad..a5929ac 100644 --- a/bip-0124.mediawiki +++ b/bip-0124.mediawiki @@ -1,11 +1,15 @@ <pre> BIP: 124 + Layer: Applications Title: Hierarchical Deterministic Script Templates Author: Eric Lombrozo <eric@ciphrex.com> William Swanson <swansontec@gmail.com> + Comments-Summary: No comments yet. + Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0124 Status: Draft Type: Informational Created: 2015-11-20 + License: PD Post-History: http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-November/011795.html </pre> diff --git a/bip-0125.mediawiki b/bip-0125.mediawiki index 52dfe40..a4b0279 100644 --- a/bip-0125.mediawiki +++ b/bip-0125.mediawiki @@ -1,11 +1,15 @@ <pre> BIP: 125 + Layer: Applications Title: Opt-in Full Replace-by-Fee Signaling Author: David A. Harding <dave@dtrt.org> Peter Todd <pete@petertodd.org> - Status: Accepted + Comments-Summary: No comments yet. + Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0125 + Status: Proposed Type: Standards Track Created: 2015-12-04 + License: PD </pre> ==Abstract== diff --git a/bip-0126.mediawiki b/bip-0126.mediawiki index 43722d0..f498b1c 100644 --- a/bip-0126.mediawiki +++ b/bip-0126.mediawiki @@ -2,9 +2,12 @@ BIP: 126 Title: Best Practices for Heterogeneous Input Script Transactions Author: Kristov Atlas <kristov@openbitcoinprivacyproject.org> + Comments-Summary: No comments yet. + Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0126 Status: Draft Type: Informational Created: 2016-02-10 + License: PD </pre> ==Abstract== diff --git a/bip-0130.mediawiki b/bip-0130.mediawiki index ae1e602..8d96c0c 100644 --- a/bip-0130.mediawiki +++ b/bip-0130.mediawiki @@ -1,10 +1,14 @@ <pre> BIP: 130 + Layer: Peer Services Title: sendheaders message Author: Suhas Daftuar <sdaftuar@chaincode.com> - Status: Accepted + Comments-Summary: No comments yet. + Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0130 + Status: Proposed Type: Standards Track Created: 2015-05-08 + License: PD </pre> ==Abstract== diff --git a/bip-0131.mediawiki b/bip-0131.mediawiki index 1efe713..5938138 100644 --- a/bip-0131.mediawiki +++ b/bip-0131.mediawiki @@ -1,10 +1,14 @@ <pre> BIP: 131 + Layer: Consensus (hard fork) Title: "Coalescing Transaction" Specification (wildcard inputs) Author: Chris Priest <cp368202@ohiou.edu> + Comments-Summary: No comments yet. + Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0131 Status: Draft Type: Standards Track Created: 2015-11-30 + License: PD </pre> ==Abstract== diff --git a/bip-0132.mediawiki b/bip-0132.mediawiki index 03cc834..e7aed29 100644 --- a/bip-0132.mediawiki +++ b/bip-0132.mediawiki @@ -2,9 +2,12 @@ BIP: 132 Title: Committee-based BIP Acceptance Process Author: Andy Chase <theandychase@gmail.com> + Comments-Summary: No comments yet. + Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0132 Status: Withdrawn Type: Process Created: 2015-08-31 + License: PD </pre> == Abstract == diff --git a/bip-0133.mediawiki b/bip-0133.mediawiki index 7d98f87..c109f12 100644 --- a/bip-0133.mediawiki +++ b/bip-0133.mediawiki @@ -1,10 +1,14 @@ <pre> BIP: 133 + Layer: Peer Services Title: feefilter message Author: Alex Morcos <morcos@chaincode.com> + Comments-Summary: No comments yet. + Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0133 Status: Draft Type: Standards Track Created: 2016-02-13 + License: PD </pre> ==Abstract== diff --git a/bip-0134.mediawiki b/bip-0134.mediawiki index afb5143..9adc8b5 100644 --- a/bip-0134.mediawiki +++ b/bip-0134.mediawiki @@ -1,10 +1,15 @@ <pre> BIP: 134 + Layer: Consensus (hard fork) Title: Flexible Transactions Author: Tom Zander <tomz@freedommail.ch> + Comments-Summary: No comments yet. + Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0134 Status: Draft Type: Standards Track Created: 2016-07-27 + License: CC-BY-SA-4.0 + OPL </pre> ==Abstract== @@ -29,7 +34,7 @@ in future. Soft fork upgrades will become much easier and cleaner this way. This protocol upgrade cleans up past soft fork changes like BIP68 which -reuse existing fields and do them in a much better to maintain and easier +reuse existing fields and do them in a better to maintain and easier to parse system. It creates the building blocks to allow new features to be added much cleaner in the future. @@ -39,14 +44,29 @@ history. Tests show that this can reduce space usage to about 75%. ==Motivation== +After 8 years of using essentially the same transaction version and layout +Bitcoin is in need of an upgrade and lessons learned in that time are +taking into account when designing it. The most important detail is that +we have seen a need for more flexibility. For instance when the 'sequence' +fields were introduced in the old transaction format, and later deprecated +again, the end result was that all transactions still were forced to keep +those fields and grow the blockchain while they all were set to the default +value. + +The way towards that flexibility is to use a generic concept made popular +various decades ago with the XML format. The idea is that we give each +field a name and this means that new fields can be added or optional fields +can be omitted from individual transactions. Some other ideas are the +standardization of data-formats (like integer and string encoding) so +we create a more consistent system. +One thing we shall not inherit from XML is its text-based format. Instead +we use the [https://github.com/bitcoinclassic/documentation/blob/master/spec/compactmessageformat.md Compact Message Format] +(CMF) which is optimized to keep the size small and fast to parse. + Token based file-formats are not new, systems like XML and HTMl use a similar system to allow future growth and they have been quite successful for decades in part because of this property. -Bitcoin needs a similar way of making the transaction future-proof because -re-purposing not used fields for new features is not good for creating -maintainable code. - Next to that this protocol upgrade will re-order the data-fields which allows us to cleanly fix the malleability issue which means that future technologies like Lightning Network will depend on this BIP being deployed. @@ -55,6 +75,19 @@ At the same time, due to this re-ordering of data fields, it becomes very easy to remove signatures from a transaction without breaking its tx-id, which is great for future pruning features. +=== Features === + +* Fixes malleability +* Linear scaling of signature checking +* Very flexible future extensibility +* Makes transactions smaller +* Supports the Lightning Network + +Additionally, in the v4 (flextrans) format we add the support for the +following proofs; +* input amount. Including the amount means we sign this transaction only if the amount we are spending is the one provided. Wallets that do not have the full UTXO DB can safely sign knowing that if they were lied to about the amount being spent, their signature is useless. +* scriptBase is the combined script of input and output, without signatures naturally. Providing this to a hardware wallet means it knows what output it is spending and can respond properly. Including it in the hash means its signature would be broken if we lied.. +* Double spent-proof. Should a node detect a double spent he can notify his peers about this fact. Instead of sending the entire transactions, instead he sends only a proof. The node needs to send two pairs of info that proves that in both transactions the CTxIn are identical. === Tokens === @@ -63,7 +96,8 @@ define how these tokens are named, where they can be placed and which are optional. To refer to XML, this specification would be the schema of a transaction. -CMF tokens are triplets of name, format (like PositiveInteger) and value. +[https://github.com/bitcoinclassic/documentation/blob/master/spec/compactmessageformat.md CMF] +tokens are triplets of name, format (like PositiveInteger) and value. Names in this scope are defined much like an enumeration where the actual integer value (id, below) is equally important to the written name. If any token found that is not covered in the next table it will make the @@ -73,114 +107,92 @@ transaction that contains it invalid. |- ! Name !! id !! Format !! Default Value !! Description |- -|TxEnd || 0 ||BoolTrue || Required ||A marker that is end of the transaction. +|TxEnd || 0 ||BoolTrue || Required ||A marker that is the end of the transaction |- -|TxInPrevHash || 1 ||ByteArray|| Required ||TxId we are spending +|TxInPrevHash || 1 ||ByteArray|| Required ||TxId we are spending |- -|TxPrevIndex || 2 ||Integer || 0 ||Index in prev tx we are spending (applied to previous TxInPrevHash) +|TxPrevIndex || 2 ||Integer || 0 ||Index in prev tx we are spending (applied to previous TxInPrevHash) |- -|TxInScript || 3 ||ByteArray|| Required ||The 'input' part of the script +|TxInputStackItem || 3 ||ByteArray|| ||A 'push' of the input script |- -|TxOutValue || 4 ||Integer || Required ||Amount of Satoshis to transfer +|TxInputStackItemContinued||4||ByteArray|| &nsbp; ||Another section for the same input |- -|TxOutScript || 5 ||ByteArray|| Required ||The 'output' part of the script +|TxOutValue || 5 ||Integer || Required ||Amount of Satoshis to transfer |- -|LockByBlock || 6 ||Integer || Optional ||BIP68 replacement +|TxOutScript || 6 ||ByteArray|| Required ||The output script |- -|LockByTime || 7 ||Integer || Optional ||BIP68 replacement +|TxRelativeBlockLock|| 7 ||Integer || Optional ||Part of the input stating the amount of blocks (max 0XFFFF) after that input was mined, it can be mined |- -|ScriptVersion || 8 ||Integer || 2 ||Defines script version for outputs following +|TxRelativeTimeLock || 8 ||Integer || Optional ||Part of the input stating the amount of time (max 0XFFFF) after that input was mined, it can be mined. 1 Unit is 512 seconds +|- +|CoinbaseMessage || 9 ||ByteArray|| Optional ||A message and some data for a coinbase transaction. Can't be used in combination with any TxIn\* tags +|- +|NOP_1x || 1x || || Optional ||Values that will be ignored by anyone parsing the transaction |- -|NOP_1x || 1x || . || Optional ||Values that will be ignored by anyone parsing the transaction |} === Scripting changes === -In the current version of Bitcoin-script, version 1, there are various -opcodes that are used to validate the cryptographic proofs that users have -to provide in order to spend outputs. +In Bitcoin transactions version 1, checking of signatures is performed by +various opcodes. The OP_CHECKSIG, OP_CHECKMULTISIG and their equivalents +that immediately VERIFY. These are used to validate the cryptographic +proofs that users have to provide in order to spend outputs. + +We additionally have some hashing-types in like SIGHASH_SINGLE that all +specify slightly different subsections of what part of a transaction will +be hashed in order to be signed. + +For transactions with version 4 we calculate a sha256 hash for signing an +individual input based on the following content; + +# If the hash-type is 0 or 1 we hash the tx-id of the transaction. For other hash types we selectively ignore parts of the transaction exactly like it has always worked. With the caveat that we never serialize any signatures. +# the TxId of the transaction we are spending in this input. +# the index of output of the transaction we are spending in this input. +# the input script we are signing (without the signature, naturally). +# the amount, as a var-int. +# the hash-type as a var-int. -The OP_CHECKSIG is the most well known and, as its name implies, it -validates a signature. -In the new version of 'script' (version 2) the data that is signed is -changed to be equivalent to the transaction-id. This is a massive -simplification and also the only change between version 1 and version 2 of -script. === Serialization order=== -The tokens defined above shall be serialized in a certain order for the -transaction to be valid. Not serializing transactions in the -order specified would allow multiple interpretations of the data which -can't be allowed. -There is still some flexibility and for that reason it is important for -implementors to remember that the actual serialized data is used for the -calculation of the transaction-id. Reading and writing it may give you a -different output and when the txid changes, the signatures will break. -At a macro-level the transaction has these segments. The order of the -segments can not be changed, but you can skip segments. +To keep in line with the name Flexible Transactions, there is very little +requirement to have a specific order. The only exception is cases where +there are optional values and reordering would make unclear what is meant. -{| class="wikitable" -!Segment !! Description -|- -| Inputs || Details about inputs. -|- -| Outputs || Details and scripts for outputs -|- -| Additional || For future expansion -|- -| Signatures || The scripts for the inputs -|- -| TxEnd || End of the transaction -|} +For this reason the TxInPrevHash always has to be the first token to start +a new input. This is because the TxPrevIndex is optional. The tokens +TxRelativeTimeLock and TxRelativeBlockLock are part of the input and +similarly have to be set after the TxInPrevHash they belong to. -The TxId is calculated by taking the serialized transaction without the -Signatures and the TxEnd and hashing that. +Similarly, the TxInputStackItem always has to be the first and can be +followed by a number of TxInputStackItemContinued items. +At a larger scope we define 3 sections of a transaction. {| class="wikitable" !Segment !! Tags !! Description |- -|Inputs||TxInPrevHash and TxInPrevIndex||Index can be skipped, but in any input the PrevHash always has to come first -|- -|Outputs||TxOutScript, TxOutValue||Order is not relevant -|- -|Additional||LockByBlock LockByTime NOP_1x +|Transaction||all not elsewhere used||This section is used to make the TxId |- -|Signatures||TxInScript||Exactly the same amount as there are inputs +|Signatures||TxInputStackItem, TxInputStackItemContinued||The input-proofs |- -|TxEnd||TxEnd +|TxEnd||TxEnd|| |} +The TxId is calculated by taking the serialized transaction without the +Signatures and the TxEnd and hashing that. + TxEnd is there to allow a parser to know when one transaction in a stream has ended, allowing the next to be parsed. -Notice that the token ScriptVersion is currently not allowed because we -don't have any valid value to give it. But if we introduce a new script -version it would be placed in the outputs segment. - -=== Script v2 === - -The default value of ScriptVersion is number 2, as opposed to the version 1 -of script that is in use today. The version 2 is mostly identical -to version one, including upgrades made to it over the years and in the -future. The only exception is that the OP_CHECKSIG is made dramatically -simpler. The input-type for OP_CHECKSIG is now no longer configurable, it is -always '1' and the content that will be signed is the txid. - -TODO: does check-multisig need its own mention? - - === Block-malleability === The effect of leaving the signatures out of the calculation of the transaction-id implies that the signatures are also not used for the calculation of the merkle tree. This means that changes in signatures -would not be detectable. Except naturally by the fact that missing or -broken signatures breaks full validation. But it is important to detect -modifications to such signatures outside of validating all transactions. +would not be detectable and open an attack vector. For this reason the merkle tree is extended to include (append) the hash of the v4 transactions. The markle tree will continue to have all the @@ -188,9 +200,8 @@ transactions' tx-ids but appended to that are the v4 hashes that include the signatures as well. Specifically the hash is taken over a data-blob that is built up from: -1. the tx-id -2. the CMF-tokens 'TxInScript' - +# the tx-id +# The entire bytearray that makes up all of the transactions signatures. This is a serialization of all of the signature tokens, so the TxInputStackItem and TxInputStackItemContinued in the order based on the inputs they are associated with. === Future extensibility === @@ -207,9 +218,18 @@ trivially use these tokens for their own usage without cooperation and communication with the rest of the Bitcoin ecosystem as miners certainly have the option to reject transactions that use unknown-to-them tokens. +The amount of tokens that can be added after number 19 is practically +unlimited and they are currently specified to not be allowed in any +transaction and the transaction will be rejected if they are present. +In the future a protocol upgrade may chance that and specify meaning for +any token not yet specified here. Future upgrades should thus be quite a +lot smoother because there is no change in concepts or in format. Just new +data. + ==Backwards compatibility == -Fully validating older clients are not compatible with this change. +Fully validating older clients will not be able to understand or validate +version 4 transactions and will need to be updated to restore that ability. SPV (simple payment validation) wallets need to be updated to receive or create the new transaction type. @@ -220,11 +240,12 @@ backwards compatible for any existing data or parsing-code. ==Reference Implementation== -Bitcoin Classic includes this in its beta releases and a reference -implementation can be found at; - -https://github.com/bitcoinclassic/bitcoinclassic/pull/186 +Bitcoin Classic includes an implementation that is following this spec. +The spec-author rejects the notion of reference implementation. The +specification is always authoritative, the implementation is not. +The official spec can be found at; +https://github.com/bitcoinclassic/documentation/blob/master/spec/transactionv4.md ==Deployment== diff --git a/bip-0140.mediawiki b/bip-0140.mediawiki index b187a49..ea5061f 100644 --- a/bip-0140.mediawiki +++ b/bip-0140.mediawiki @@ -1,11 +1,16 @@ <pre> BIP: 140 + Layer: Consensus (soft fork) Title: Normalized TXID Author: Christian Decker <decker.christian@gmail.com> + Comments-Summary: No comments yet. + Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0140 Status: Draft Type: Standards Track Created: 2015-10-14 + License: PD </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. @@ -110,4 +115,4 @@ This is a softfork which replaces <code>OP_NOP4</code> with the new implementati <references> ==Copyright== -This document is placed in the public domain.
\ No newline at end of file +This document is placed in the public domain. diff --git a/bip-0141.mediawiki b/bip-0141.mediawiki index 352256f..7cc587a 100644 --- a/bip-0141.mediawiki +++ b/bip-0141.mediawiki @@ -1,12 +1,16 @@ <pre> BIP: 141 + Layer: Consensus (soft fork) Title: Segregated Witness (Consensus layer) Author: Eric Lombrozo <elombrozo@gmail.com> Johnson Lau <jl2012@xbt.hk> Pieter Wuille <pieter.wuille@gmail.com> + Comments-Summary: No comments yet. + Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0141 Status: Draft Type: Standards Track Created: 2015-12-21 + License: PD </pre> ==Abstract== diff --git a/bip-0142.mediawiki b/bip-0142.mediawiki index bb60265..80a413f 100644 --- a/bip-0142.mediawiki +++ b/bip-0142.mediawiki @@ -1,10 +1,14 @@ <pre> BIP: 142 + Layer: Applications Title: Address Format for Segregated Witness Author: Johnson Lau <jl2012@xbt.hk> + Comments-Summary: No comments yet. + Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0142 Status: Deferred Type: Standards Track Created: 2015-12-24 + License: PD </pre> == Abstract == diff --git a/bip-0143.mediawiki b/bip-0143.mediawiki index 766fd9f..476b84d 100644 --- a/bip-0143.mediawiki +++ b/bip-0143.mediawiki @@ -1,11 +1,15 @@ <pre> BIP: 143 + Layer: Consensus (soft fork) Title: Transaction Signature Verification for Version 0 Witness Program Author: Johnson Lau <jl2012@xbt.hk> Pieter Wuille <pieter.wuille@gmail.com> + Comments-Summary: No comments yet. + Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0143 Status: Draft Type: Standards Track Created: 2016-01-03 + License: PD </pre> == Abstract == diff --git a/bip-0144.mediawiki b/bip-0144.mediawiki index f10fe0c..8e65554 100644 --- a/bip-0144.mediawiki +++ b/bip-0144.mediawiki @@ -1,11 +1,15 @@ <pre> BIP: 144 + Layer: Peer Services Title: Segregated Witness (Peer Services) Author: Eric Lombrozo <elombrozo@gmail.com> Pieter Wuille <pieter.wuille@gmail.com> + Comments-Summary: No comments yet. + Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0144 Status: Draft Type: Standards Track Created: 2016-01-08 + License: PD </pre> ==Abstract== diff --git a/bip-0145.mediawiki b/bip-0145.mediawiki index cac838d..a7ace98 100644 --- a/bip-0145.mediawiki +++ b/bip-0145.mediawiki @@ -1,10 +1,15 @@ <pre> BIP: 145 + Layer: API/RPC Title: getblocktemplate Updates for Segregated Witness Author: Luke Dashjr <luke+bip22@dashjr.org> + Comments-Summary: No comments yet. + Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0145 Status: Draft Type: Standards Track Created: 2016-01-30 + License: BSD-2-Clause + OPL </pre> ==Abstract== diff --git a/bip-0146.mediawiki b/bip-0146.mediawiki index 5358411..240f82a 100644 --- a/bip-0146.mediawiki +++ b/bip-0146.mediawiki @@ -1,11 +1,15 @@ <pre> BIP: 146 + Layer: Consensus (soft fork) Title: Dealing with signature encoding malleability Author: Johnson Lau <jl2012@xbt.hk> Pieter Wuille <pieter.wuille@gmail.com> + Comments-Summary: No comments yet. + Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0146 Status: Draft Type: Standards Track Created: 2016-08-16 + License: PD </pre> ==Abstract== diff --git a/bip-0147.mediawiki b/bip-0147.mediawiki index 001abc6..8a5c67a 100644 --- a/bip-0147.mediawiki +++ b/bip-0147.mediawiki @@ -1,10 +1,14 @@ <pre> BIP: 147 + Layer: Consensus (soft fork) Title: Dealing with dummy stack element malleability Author: Johnson Lau <jl2012@xbt.hk> + Comments-Summary: No comments yet. + Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0147 Status: Draft Type: Standards Track Created: 2016-09-02 + License: PD </pre> ==Abstract== diff --git a/bip-0148.mediawiki b/bip-0148.mediawiki new file mode 100644 index 0000000..4dca9d7 --- /dev/null +++ b/bip-0148.mediawiki @@ -0,0 +1,88 @@ +<pre> + BIP: 148 + Layer: Consensus (soft fork) + Title: Mandatory activation of segwit deployment + Author: Shaolin Fry <shaolinfry@protonmail.ch> + Comments-Summary: No comments yet. + Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0148 + Status: Draft + Type: Standards Track + Created: 2017-03-12 + License: BSD-3-Clause + CC0-1.0 +</pre> + +==Abstract== + +This document specifies a BIP16 like soft fork flag day activation of the segregated witness BIP9 deployment known as "segwit". + +==Definitions== + +"existing segwit deployment" refer to the BIP9 "segwit" deployment using bit 1, between November 15th 2016 and November 15th 2017 to activate BIP141, BIP143 and BIP147. + +==Motivation== + +Segwit increases the blocksize, fixes transaction malleability, and makes scripting easier to upgrade as well as bringing many other [https://bitcoincore.org/en/2016/01/26/segwit-benefits/ benefits]. + +It is hoped that miners will respond to this BIP by activating segwit early, before this BIP takes effect. Otherwise this BIP will cause the mandatory activation of the existing segwit deployment before the end of midnight November 15th 2017. + +==Specification== + +All times are specified according to median past time. + +This BIP will be active between midnight August 1st 2017 (epoch time 1501545600) and midnight November 15th 2017 (epoch time 1510704000) if the existing segwit deployment is not locked-in or activated before epoch time 1501545600. This BIP will cease to be active when segwit is locked-in. + +While this BIP is active, all blocks must set the nVersion header top 3 bits to 001 together with bit field (1<<1) (according to the existing segwit deployment). Blocks that do not signal as required will be rejected. + +=== Reference implementation === + +<pre> +// Check if Segregated Witness is Locked In +bool IsWitnessLockedIn(const CBlockIndex* pindexPrev, const Consensus::Params& params) +{ + LOCK(cs_main); + return (VersionBitsState(pindexPrev, params, Consensus::DEPLOYMENT_SEGWIT, versionbitscache) == THRESHOLD_LOCKED_IN); +} + +// BIP148 mandatory segwit signalling. +int64_t nMedianTimePast = pindex->GetMedianTimePast(); +if ( (nMedianTimePast >= 1501545600) && // Tue 01 Aug 2017 00:00:00 UTC + (nMedianTimePast <= 1510704000) && // Wed 15 Nov 2017 00:00:00 UTC + (!IsWitnessLockedIn(pindex->pprev, chainparams.GetConsensus()) && // Segwit is not locked in + !IsWitnessEnabled(pindex->pprev, chainparams.GetConsensus())) ) // and is not active. +{ + bool fVersionBits = (pindex->nVersion & VERSIONBITS_TOP_MASK) == VERSIONBITS_TOP_BITS; + bool fSegbit = (pindex->nVersion & VersionBitsMask(chainparams.GetConsensus(), Consensus::DEPLOYMENT_SEGWIT)) != 0; + if (!(fVersionBits && fSegbit)) { + return state.DoS(0, error("ConnectBlock(): relayed block must signal for segwit, please upgrade"), REJECT_INVALID, "bad-no-segwit"); + } +} +</pre> + +https://github.com/bitcoin/bitcoin/compare/master...shaolinfry:bip-segwit-flagday + +==Backwards Compatibility== + +This deployment is compatible with the existing "segwit" bit 1 deployment scheduled between midnight November 15th, 2016 and midnight November 15th, 2017. + +==Rationale== + +Historically, the P2SH soft fork (BIP16) was activated using a predetermined flag day where nodes began enforcing the new rules. P2SH was successfully activated with relatively few issues + +By orphaning non-signalling blocks during the last month of the BIP9 bit 1 "segwit" deployment, this BIP can cause the existing "segwit" deployment to activate without needing to release a new deployment. + +==References== + +*[https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-March/013714.html Mailing list discussion] +*[https://github.com/bitcoin/bitcoin/blob/v0.6.0/src/main.cpp#L1281-L1283 P2SH flag day activation] +*[[bip-0009.mediawiki|BIP9 Version bits with timeout and delay]] +*[[bip-0016.mediawiki|BIP16 Pay to Script Hash]] +*[[bip-0141.mediawiki|BIP141 Segregated Witness (Consensus layer)]] +*[[bip-0143.mediawiki|BIP143 Transaction Signature Verification for Version 0 Witness Program]] +*[[bip-0147.mediawiki|BIP147 Dealing with dummy stack element malleability]] +*[https://bitcoincore.org/en/2016/01/26/segwit-benefits/ Segwit benefits] + +==Copyright== + +This document is dual licensed as BSD 3-clause, and Creative Commons CC0 1.0 Universal. + diff --git a/bip-0150.mediawiki b/bip-0150.mediawiki index b1d46c1..1fe4582 100644 --- a/bip-0150.mediawiki +++ b/bip-0150.mediawiki @@ -1,10 +1,14 @@ <pre> BIP: 150 + Layer: Peer Services Title: Peer Authentication Author: Jonas Schnelli <dev@jonasschnelli.ch> + Comments-Summary: Discouraged for implementation (one person) + Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0150 Status: Draft Type: Standards Track Created: 2016-03-23 + License: PD </pre> == Abstract == diff --git a/bip-0151.mediawiki b/bip-0151.mediawiki index cf221f2..a01a8bb 100644 --- a/bip-0151.mediawiki +++ b/bip-0151.mediawiki @@ -1,10 +1,14 @@ <pre> BIP: 151 + Layer: Peer Services Title: Peer-to-Peer Communication Encryption Author: Jonas Schnelli <dev@jonasschnelli.ch> + Comments-Summary: Controversial; some recommendation, and some discouragement + Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0151 Status: Draft Type: Standards Track Created: 2016-03-23 + License: PD </pre> == Abstract == diff --git a/bip-0152.mediawiki b/bip-0152.mediawiki index b1cc468..8ea3701 100644 --- a/bip-0152.mediawiki +++ b/bip-0152.mediawiki @@ -1,10 +1,14 @@ <pre> BIP: 152 + Layer: Peer Services Title: Compact Block Relay Author: Matt Corallo <bip152@bluematt.me> + Comments-Summary: Unanimously Recommended for implementation + Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0152 Status: Draft Type: Standards Track Created: 2016-04-27 + License: PD </pre> ==Abstract== @@ -120,18 +124,18 @@ A new inv type (MSG_CMPCT_BLOCK == 4) and several new protocol messages are adde # MSG_CMPCT_BLOCK inv objects MUST NOT appear anywhere except for in getdata messages. ====cmpctblock==== -# The cmpctblock message is defined as as a message containing a serialized HeaderAndShortIDs message and pchCommand == "cmpctblock". +# The cmpctblock message is defined as a message containing a serialized HeaderAndShortIDs message and pchCommand == "cmpctblock". # Upon receipt of a cmpctblock message after sending a sendcmpct message, nodes SHOULD calculate the short transaction ID for each unconfirmed transaction they have available (ie in their mempool) and compare each to each short transaction ID in the cmpctblock message. # After finding already-available transactions, nodes which do not have all transactions available to reconstruct the full block SHOULD request the missing transactions using a getblocktxn message. # A node MUST NOT send a cmpctblock message unless they are able to respond to a getblocktxn message which requests every transaction in the block. # A node MUST NOT send a cmpctblock message without having validated that the header properly commits to each transaction in the block, and properly builds on top of the existing chain with a valid proof-of-work. A node MAY send a cmpctblock before validating that each transaction in the block validly spends existing UTXO set entries. ====getblocktxn==== -# The getblocktxn message is defined as as a message containing a serialized BlockTransactionsRequest message and pchCommand == "getblocktxn". -# Upon receipt of a properly-formatted getblocktxnmessage, nodes which recently provided the sender of such a message a cmpctblock for the block hash identified in this message MUST respond with an appropriate blocktxn message. Such a blocktxn message MUST contain exactly and only each transaction which is present in the appropriate block at the index specified in the getblocktxn indexes list, in the order requested. +# The getblocktxn message is defined as a message containing a serialized BlockTransactionsRequest message and pchCommand == "getblocktxn". +# Upon receipt of a properly-formatted getblocktxn message, nodes which recently provided the sender of such a message a cmpctblock for the block hash identified in this message MUST respond with either an appropriate blocktxn message, or a full block message. A blocktxn response MUST contain exactly and only each transaction which is present in the appropriate block at the index specified in the getblocktxn indexes list, in the order requested. ====blocktxn==== -# The blocktxn message is defined as as a message containing a serialized BlockTransactions message and pchCommand == "blocktxn". +# The blocktxn message is defined as a message containing a serialized BlockTransactions message and pchCommand == "blocktxn". # Upon receipt of a properly-formatted requested blocktxn message, nodes SHOULD attempt to reconstruct the full block by: ## Taking the prefilledtxn transactions from the original cmpctblock and placing them in the marked positions. ## For each short transaction ID from the original cmpctblock, in order, find the corresponding transaction either from the blocktxn message or from other sources and place it in the first available position in the block. @@ -183,8 +187,16 @@ Compact blocks version 2 is almost identical to version 1, but supports segregat # Any undefined behavior in this spec may cause failure to transfer block to, peer disconnection by, or self-destruction by the receiving node. A node receiving non-minimally-encoded CompactSize encodings should make a best-effort to eat the sender's cat. +===Pre-Validation Relay and Consistency Considerations=== + # As high-bandwidth mode permits relaying of CMPCTBLOCK messages prior to full validation (requiring only that the block header is valid before relay), nodes SHOULD NOT ban a peer for announcing a new block with a CMPCTBLOCK message that is invalid, but has a valid header. For avoidance of doubt, nodes SHOULD bump their peer-to-peer protocol version to 70015 or higher to signal that they will not ban or punish a peer for announcing compact blocks prior to full validation, and nodes SHOULD NOT announce a CMPCTBLOCK to a peer with a version number below 70015 before fully validating the block. +# SPV nodes which implement this spec must consider the implications of accepting blocks which were not validated by the node which provided them. Especially SPV nodes which allow users to select a "trusted full node" to sync from may wish to avoid implementing this spec in high-bandwidth mode. + +# Note that this spec does not change the requirement that nodes only relay information about blocks which they have fully validated in response to GETDATA/GETHEADERS/GETBLOCKS/etc requests. Nodes which announce using CMPCTBLOCK message and then receive a request for associated block data SHOULD ensure that messages do not go unresponded to, and that the appropriate data is provided after the block has been validated, subject to standard message-response ordering requirements. Note that no requirement is added that the node respond to the request with the new block included in eg GETHEADERS or GETBLOCKS messages, but the node SHOULD re-announce the block using the associated announcement methods after validation has completed if it is not included in the original response. On the other hand, nodes SHOULD delay responding to GETDATA requests for the block until validation has completed, stalling all message processing for the associated peer. REJECT messages are not considered "responses" for the purpose of this section. + +# As a result of the above requirements, implementors may wish to consider the potential for the introduction of delays in responses while remote peers validate blocks, avoiding delay-causing requests where possible. + ==Justification== ====Protocol design==== diff --git a/bip-0171.mediawiki b/bip-0171.mediawiki new file mode 100644 index 0000000..237d233 --- /dev/null +++ b/bip-0171.mediawiki @@ -0,0 +1,191 @@ +<pre> + BIP: 171 + Layer: Applications + Title: Currency/exchange rate information API + Author: Luke Dashjr <luke+bip@dashjr.org> + Comments-Summary: No comments yet. + Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0171 + Status: Draft + Type: Standards Track + Created: 2017-03-04 + License: BSD-2-Clause +</pre> + +==Abstract== + +A common interface for requesting currency exchange rate information from a server. + +==Copyright== + +This BIP is licensed under the BSD 2-clause license. + +==Specification== + +Four requests are defined, which are all made by a GET request to a common URI with parameters encoded in application/x-www-form-urlencoded format. +All matching parameters may be specified with multiple comma-separated values, which are to be interpreted as "any of these". +Each result is always in JSON format, with a line-feed (never a carriage-return) separating multiple results. + +Authentication for subscription-based services MAY be supported using standard HTTP authentication. +It is recommended to use TLS (HTTPS), so that MITM attackers cannot deceive the client. + +To be BIP 171 compatible, servers MUST support at least one currency-pair compared to XBT. +All inquiries for bitcoin amounts MUST be specified in XBT, even if the presentation to the end user is in another unit. +(FIXME: or should this be satoshis?) + +Currency-pair tokens are arbitrary Strings no longer than 255 characters, which may include any ASCII [https://tools.ietf.org/html/rfc3986#section-2.3 RFC 3986 unreserved characters] (ie, alphanumerics and the hyphen, underscore, period, and tilde symbols). + +Currency code(s) used herein are defined as such: + +* All ISO 4217 codes are valid currency codes. +* XBT is defined as 100000000 satoshis (commonly known as 1 BTC). +* Strings longer than 3 characters may be used for currencies without an applicable code. (If a shorter code is desired despite this, it may be padded with space(s) to the left until it is 4 characters. Software MAY strip these spaces.) + +Rate is defined as the amount of quote-currency to be exchanged for one unit of the base-currency. +In other words, <code>1 baseCurrency = rate quoteCurrency</code>. + +===Enumerating supported currency-pair tokens=== + +Parameters: + +* ''mode'' - Always "list" for this request. +* ''quote'' - If provided, the server MAY limit the results to only currency-pairs describing a currency with the given currency code(s). +* ''base'' - If provided, the server MAY limit the results to only currency-pairs describing currency rates compared to the given currency code(s). +* ''locale'' - If provided, the server MAY limit the results to only currency-pairs supporting the given Unicode CLDR locale(s). + +Each currency-pair will receive a separate result, a JSON Object, with the following information: + +* ''cp'' - The currency-pair token. +* ''quote'' - The currency code for the quote currency. +* ''base'' - The currency code for the base currency. +* ''locale'' - If provided, a String with the applicable Unicode CLDR locale. +* ''desc'' - Optional description. For example, it could be "Based on Florida BTM prices." or any other short String that provides information useful to the user. SHOULD be shorter than 45 characters. + +Example: + + Request: http://api.example.tld/?mode=list"e=USD&base=XBT&locale=en_US,en_GB + Result: + {"cp":"XBTUSD-ver4", "quote":"USD", "base": "XBT", "locale": "en_US", "desc": "Smoothed averages"} + {"cp":"2", "quote":"USD", "base": "XBT", "locale": "en_US", "desc": "Updated per-trade"} + {"cp":"XBTUSD-european", "quote":"USD", "base": "XBT", "locale": "en_GB"} + +===Currency-pair information=== + +Parameters: + +* ''mode'' - Always "info" for this request. +* ''cp'' - Currency pair(s) for which information is requested. + +Each currency-pair will receive a separate result, a JSON Object, with the following information: + +* ''cp'' - The currency-pair token. +* ''quote'' - The currency code for the quote currency. +* ''base'' - The currency code for the base currency. +* ''locale'' - If provided, a String with the applicable Unicode CLDR locale. +* ''desc'' - Optional description. For example, it could be "Based on Florida BTM prices." or any other short String that provides information useful to the user. SHOULD be shorter than 45 characters. +* ''longdesc'' - Optional description, but may be longer and include newlines. +* ''symbol'' - An Array of prefix and suffix for the quote currency. Each may be either a fixed String, an Array of two Strings (negative and positive), or null. Any positive or negative symbols must be included in this prefix/suffix; it MUST NOT be implied otherwise. +* ''digits'' - The type of digits to use for the quote currency's numbers. "arabic" should be used for common 0-9 digits. +* ''grouping'' - An Array alternating between Numbers representing a series of digits, and Strings used as delimiters. If terminated by a zero, the final grouping is to be repeated continually. For example, the common US locale thousands grouping would be <code>[3, ",", 0]</code> +* ''fraction_sep'' - A String to be placed between whole numbers and a fractional amount. +* ''fraction_digits'' - Array of absolute minimum (even for whole numbers) number of fractional digits, minimum fractional digits when a fraction exists, and maximum number of fractional digits when absolute precision is not demanded (below which is to be rounded in an implementation-dependent manner). +* ''minpoll'' - A Number of seconds indicating a minimum time between polls to the server. Clients should be prudent about not polling too often, even if this number is low. +* ''longpoll'' - If provided and true, indicates longpolling is supported by the server. +* ''history'' - If provided, indicates the server has historical records going back no earlier than the POSIX timestamp provided as a value. +* ''archive'' - If provided, indicates the server no longer has current rates, and has no historical rates more recent than the POSIX timestamp provided as a value. + +Example: + + Request: http://api.example.tld/?mode=info&cp=XBTUSD-ver4,2 + Result: + {"cp":"XBTUSD-ver4", "quote":"USD", "base": "XBT", "locale": "en_US", "desc": "Smoothed averages", "longdesc": "USD price quotes as compared to Bitcoin value\n\nRecommended for casual usage", "symbol": [["-$", "$"], null], "digits": "arabic", "grouping": [3, ",", 0], "fraction_sep": ".", "fraction_digits": [0, 2, 2], "minpoll": 300, "longpoll": true, "history": 1457231416} + {"cp":"2", "quote":"USD", "base": "XBT", "locale": "en_US", "desc": "Updated per-trade", "longdesc": "Maximum precision USD price quotes as compared to Bitcoin value", "symbol": [["-$", "$"], null], "digits": "arabic", "grouping": [3, ",", 0], "fraction_sep": ".", "fraction_digits": [0, 2, 2], "minpoll": 3600, "longpoll": false, "history": 1467458333.1225} + +===Current exchange rate=== + +Parameters: + +* ''mode'' - Always "rate" for this request. +* ''cp'' - Currency pair(s) for which rate is requested. +* ''type'' - Type of exchange rate data being requested. May be "high", "low", "average", "typical", or any other arbitrary name. If omitted, the server may provide any rates it deems appropriate. +* ''minrate'', ''maxrate'' - If specified, indicates this request is a longpoll. The server should not send a response until the rate(s) fall below or above (respectively) the provided value. + +Each currency-pair receives a separate result (a JSON Object) with all requested rate types: + +* ''cp'' - The currency-pair token. +* ''time'' - The time (as a POSIX timestamp) the rate information is applicable to (should be approximately the request time). +* ''rates'' - A JSON Object with each rate type provided as a key, and a Number as the value specifying the rate. + +Example: + + Request: http://api.example.tld/?mode=rate&cp=XBTUSD-ver4,2&type=typical,high + Result: + {"cp":"XBTUSD-ver4", "time": 1488767410.5463133, "rates": {"typical": 1349.332215, "high": 1351.2}} + {"cp":"2", "time": 1488767410, "rates": {"typical": 1350.111332}} + +===Historical exchange rates=== + +Parameters: + +* ''mode'' - Always "history" for this request. +* ''cp'' - Currency pair(s) for which rate is requested. +* ''type'' - Type of exchange rate data being requested. May be "high", "low", "average", "typical", or any other arbitrary name. If omitted, the server may provide any rates it deems appropriate. +* ''from'' - POSIX timestamp the results should begin with. +* ''to'' - POSIX timestamp the results should end with. If omitted, the present time shall be used. +* ''nearest'' - If provided and true, indicates that only the nearest timestamp to "from" must be returned, and a range is not desired. ("to" should be omitted in this case.) +* ''ratedelta'', ''timedelta'' - If specified, the server may omit data where the rate or time has not changed since the last provided rate and time. If both are provided, either a significant rate change OR time change should trigger a new record in the results. + +A result is provided for each currency-pair and timestamp record, in the same format as the current exchange rate request. +Records MUST be provided in chronological order, but only within the scope of the applicable currency-pair (ie, it is okay to send the full history for one currency-pair, and then the full history for the next; or to intermix them out of any given order). + +If there is no exact record for the times specified by "from" and/or "to", a single record before "from" and/or after "to" should also be included. +This is not necessary when only the nearest record is requested, or when "to" is omitted (ie, ending at the most recent record). + +Example: + + Request: http://api.example.tld/?mode=history&cp=XBTUSD-ver4,2&type=typical&ratedelta=0.1&timedelta=10&from=1488759998&to=1488760090 + Result: + {"cp":"XBTUSD-ver4", "time": 1488760000, "rates": {"typical": 1300}} + {"cp":"XBTUSD-ver4", "time": 1488760010, "rates": {"typical": 1301.1}} + {"cp":"XBTUSD-ver4", "time": 1488760020, "rates": {"typical": 1320}} + {"cp":"XBTUSD-ver4", "time": 1488760030, "rates": {"typical": 1305}} + {"cp":"2", "time": 1488760000.1, "rates": {"typical": 1300}} + {"cp":"2", "time": 1488760010.2, "rates": {"typical": 1301.1}} + {"cp":"2", "time": 1488760020.2, "rates": {"typical": 1320.111332}} + {"cp":"2", "time": 1488760031, "rates": {"typical": 1305.222311}} + {"cp":"XBTUSD-ver4", "time": 1488760040, "rates": {"typical": 1303.33}} + {"cp":"2", "time": 1488760042, "rates": {"typical": 1303.33}} + {"cp":"XBTUSD-ver4", "time": 1488760050, "rates": {"typical": 1305}} + {"cp":"2", "time": 1488760052, "rates": {"typical": 1307}} + {"cp":"XBTUSD-ver4", "time": 1488760060, "rates": {"typical": 1309}} + {"cp":"XBTUSD-ver4", "time": 1488760072, "rates": {"typical": 1308}} + {"cp":"2", "time": 1488760062, "rates": {"typical": 1309.55555555}} + {"cp":"2", "time": 1488760072, "rates": {"typical": 1308}} + {"cp":"XBTUSD-ver4", "time": 1488760082, "rates": {"typical": 1309}} + {"cp":"2", "time": 1488760082, "rates": {"typical": 1309.1}} + +==Motivation== + +End users often desire to see fiat currency information in their Bitcoin wallet software. +Due to the nature of Bitcoin, there is inherently no authoritative source for exchange rates. +There are many independent providers of such information, but they all use different formats for providing it, so wallet software is currently forced to implement dedicated code for each provider. + +By providing a standard interface for retrieving this information, wallets (and other software) and service providers can implement it once, and become immediately interoperable with all other compatible implementations. + +==Rationale== + +Why are multiple results separated by a line-feed rather than using a JSON Array? + +* Clients ought to cache historical data, and using a line-feed format allows them to simply append to a cache file. +* Parsing JSON typically requires the entire data parsed together as a single memory object. Using simple lines to separate results, however, allows parsing a single result at a time. + +What if long descriptions require line and paragraph breaks? + +* Clients should word-wrap long lines, and JSON escapes newlines as "\n" which can be used doubly ("\n\n") for paragraph breaks. + +==Backwards compatibility== + +While this new standard is adopted, software and providers can continue to use and provide their current formats until they are no longer needed. + +==Reference implementation== + +TODO diff --git a/bip-0180.mediawiki b/bip-0180.mediawiki new file mode 100644 index 0000000..9f6bd18 --- /dev/null +++ b/bip-0180.mediawiki @@ -0,0 +1,149 @@ +<pre> + BIP: 180 + Layer: Peer Services + Title: Block size/weight fraud proof + Author: Luke Dashjr <luke+bip@dashjr.org> + Comments-Summary: No comments yet. + Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0180 + Status: Draft + Type: Standards Track + Created: 2017-03-17 + License: BSD-2-Clause +</pre> + +==Abstract== + +A fraud proof that enables light clients to detect oversized (or overweight) blocks. + +==Copyright== + +This BIP is licensed under the BSD 2-clause license. + +==Definitions== + +; full tx size proof : SHA2 midstate and tail data proving the size of the full transaction data being hashed. +; size component : Either a merkle link and height in the merkle tree thereof, or a full tx size proof. +; full-size proof : The set of size components proving the lower-bound size of the block. +; stripped-size proof : The set of size components proving the lower-bound size of the block when stripped of segwit witness data. + +==Specification== + +===Proof format=== + +* varint: ceil(log2(number of transactions in block)) +* varint: number of size components in stripped-size proof +* foreach: +** varint: ceil(log2(number of transactions represented by this size-component)) + 1 +** if zero: +*** (this indicates a full tx size proof) +*** 256-bit: SHA2 midstate up until just before the final SHA2 chunk +*** varint: total size of tx +*** uint8: size of final SHA2 chunk (0-55) +*** 0-55 bytes: final SHA2 chunk +** if one or more: +*** (this indicates default tx size counting) +*** 256-bit: SHA2 hash of merkle link +* varint: number of size components in full-size proof (zero in case of a size-exceeded proof; non-zero for a weight-exceeded proof) +* foreach: (same as with stripped-size proof) + +===Proof verification=== + +To verify an individual size proof: + +#Check that at least one size component is a full tx size proof. (At least one size component MUST be a full tx size proof.) +#Determine the lower-bound number of transactions in the block (lowTxCount). It is either <code>pow(ceil(log2(txcount)) - 1, 2)</code>, or the position of the last full tx proof (plus one, if using 0-based positions). Note that the last full tx proof from *either* of the size proofs (stripped-size and full-size) should be used here. +#Calculate the lower-bound transaction-data size as the default size * lowTxCount. +#For each full tx size proof: +##Subtract the default size it was presumed to consume, and add the claimed total size of tx. +##Take the SHA2 midstate, and update it with the final SHA2 chunk (which needs to be padded, including with the total tx size). The final SHA2 hash is the transaction id (stripped-size proof) or hash (full-size proof). +#For the full-size proof, replace the 60 byte default with any larger sizes proven from the stripped-size proof. +#Build the merkle root, and compare it to the block header (stripped-size proof) or witness commitment (full-size proof). Ensure when building the merkle root, that there are no duplicate merkle links, and each merkle link claims to represent the correct number of represented transactions. +#Add 80 bytes, plus the size of the tx-count varint, to the calculated lower-bound size. +#The calculated size is returned as the lower-bound possible size of the block. + +For the stripped-size proof, the default size of transactions is 60 bytes. +For the full-size proof, it is the size established by the stripped-size proof. + +To verify the complete weight proof: + +# Verify the stripped-size proof. Save the resulting lower-bound size (call it lowStrippedSize). +# Verify the full-size proof. Save the resulting lower-bound size (call it lowFullSize). +# Calculate minFullSize + (minStrippedSize * 3). This is the lower-bound block weight. +# Compare the lower-bound block weight to the applicable block weight limit. + +===Network protocol=== + +If a light client detects that one or more of its peers do not consider the block it knows to have the most work as their best block, it should inquire with all those peers for a fraud proof by sending a new message <code>getfraud</code>, with a block locator (between the last common block, and the presumed best tip) as the sole parameter (extra parameters should be ignored). + +Compatible nodes will respond with a (new) <code>fraud</code> message, which has 2-3 parameters: + +* uint256: The hash of the most recent block in the locator (or a parent thereof) that it has checked. In the event of an invalid block, this should be the exact invalid block's hash (post-invalid blocks should be treated as unchecked, even if the node has independently checked them for some reason). +* varint: Fraud proof type code +** 0 = Block is valid +** 1 = No fraud proof available +** 2 = Size/weight exceeded +* (For type 2) the fraud proof + +If none of the blocks in the locator are recognised, compatible nodes should send a <code>fraud</code> message with no parameters. +(To avoid this outcome, clients may include a known-common block in the locator.) + +In the event that the peer claims a block earlier than the client's tip is valid, the light client should prepare a new locator between that block and its tip, and rerequest <code>getfraud</code> until it has determined which block the peer rejects and why. + +Once a block is proven to be invalid, the light client should never consider any blockchain including it as a candidate for the best chain. +It should not recheck blocks known to be invalid, nor continue proving it from other nodes. +(To avoid doubt: the user MAY be given the opportunity to override any rejections, but should be warned of the implications of doing so.) + +If an invalid fraud proof is provided, the client SHOULD CONSIDER disconnecting and possibly banning the node providing it. +However, if any change has been made to the size/weight limits, that should be taken into consideration (eg, if the limit increases, an innocent node may prove a size smaller than the limit). + +==Information== + +===Creation of proofs=== + +Proofs should ideally use the smallest amount of data required to prove excess of the limit. +The most obvious mechanism in doing so, would be to include full tx size proofs for the largest transactions until the limit is exceeded. +However, in some cases, a smaller size may be accomplished by collapsing more merkle links. + +Because optimisation of proof size may be complicated, nodes are not required to implement it in any particular manner, so long as the proofs meet the requirements given above in [[#proof-verification|Proof verification]]. + +==Motivation== + +Recently, there have been proposals for hardforks to increase the block size limit. +While no consensus has been reached, proponents of these ideas often threaten and attempt to have miners force them through anyway. +As things presently are, light clients cannot detect invalid blocks at all, and could be fooled into accepting an invalid chain created in such a manner. +By supporting block size fraud proofs, light clients can protect their users from this form of unconsensual "hardfork" attempt. + +==Rationale== + +Why must a full tx size proof be included? + +* This is necessary to establish that the claimed block transaction count is not inflated. Otherwise, a prover could claim any number of represented transactions for merkle links, and rely on the default size alone to exceed the limit. + +How does the full tx size proof actually prove the size? + +* The first step of SHA2 hashing is to transform the input data into chunks (per [https://tools.ietf.org/html/rfc4634#section-4.1 RFC 4634]). The final chunk is required to include the absolute length of the input data at the end of the final chunk. Therefore, by committing to the midstate prior to the final chunk, and replaying only the final chunk, we can confirm that the claimed size matches the full transaction data being hashed. + +How does this prove the block weight? + +* The block weight defined by [[bip-0141.mediawiki|BIP 141]] is the size of the block stripped of its segwit signatures times 3, plus the full size of the block. By proving lower-bound sizes of both the stripped block and the full block, a lower-bound weight can also be calculated. + +Why is the number of transactions in the block represented as a log2? + +* To avoid attacks that rely on fooling clients by claiming an amount they cannot verify. + +Why does it matter if a full tx size proof is on the right side of a duplicate merkle link? + +* We assume full tx size proofs show the number of transactions in the block. This assumption doesn't hold if the proof is provided on the right-hand side of duplicate links. + +Why a fraud proof only for oversized/overweight blocks? + +* While it is currently believed to be impossible to prove all invalid (or rather, won't-be-part-of-the-main-chain) blocks, there are regularly active proposals of miners attacking with simply oversized blocks in an attempt to force a hardfork. This specific attack can be proven, and reliably so, since the proof cannot be broken without also breaking the attempted hardfork at the same time. + +==Backwards compatibility== + +These fraud proofs protect only clients which use them. +In non-attack scenarios, they are unnecessary and clients supporting them will otherwise behave as any other. + +==Reference implementation== + +TODO diff --git a/bip-0199.mediawiki b/bip-0199.mediawiki new file mode 100644 index 0000000..887804a --- /dev/null +++ b/bip-0199.mediawiki @@ -0,0 +1,81 @@ +<pre> + BIP: 199 + Layer: Applications + Title: Hashed Time-Locked Contract transactions + Author: Sean Bowe <sean@z.cash> + Daira Hopwood <daira@z.cash> + Comments-Summary: No comments yet. + Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0199 + Status: Draft + Type: Standards Track + Created: 2017-03-27 + License: BSD-3-Clause + CC0-1.0 +</pre> + +==Abstract== + +This BIP describes a script for generalized off-chain contract negotiation. + +==Summary== + +A Hashed Time-Locked Contract (HTLC) is a script that permits a designated party (the "seller") to spend funds by disclosing the preimage of a hash. It also permits +a second party (the "buyer") to spend the funds after a timeout is reached, in a refund situation. + +The script takes the following form: + + OP_IF + [HASHOP] <digest> OP_EQUALVERIFY OP_DUP OP_HASH160 <seller pubkey hash> + OP_ELSE + <num> [TIMEOUTOP] OP_DROP OP_DUP OP_HASH160 <buyer pubkey hash> + OP_ENDIF + OP_EQUALVERIFY + OP_CHECKSIG + +[HASHOP] is either OP_SHA256 or OP_HASH160. + +[TIMEOUTOP] is either OP_CHECKSEQUENCEVERIFY or OP_CHECKLOCKTIMEVERIFY. + +===Interaction=== + +* Victor (the "buyer") and Peggy (the "seller") exchange public keys and mutually agree upon a timeout threshold. Peggy provides a hash digest. Both parties can now +construct the script and P2SH address for the HTLC. +* Victor sends funds to the P2SH address. +* Either: +** Peggy spends the funds, and in doing so, reveals the preimage to Victor in the transaction; OR +** Victor recovers the funds after the timeout threshold. + +Victor is interested in a lower timeout to reduce the amount of time that his funds are encumbered in the event that Peggy does not reveal the preimage. Peggy is +interested in a higher timeout to reduce the risk that she is unable to spend the funds before the threshold, or worse, that her transaction spending the funds does +not enter the blockchain before Victor's but does reveal the preimage to Victor anyway. + +==Motivation== + +In many off-chain protocols, secret disclosure is used as part of a settlement mechanism. In some others, the secrets themselves are valuable. HTLC transactions are +a safe and cheap method of exchanging secrets for money over the blockchain, due to the ability to recover funds from an uncooperative counterparty, and the +opportunity that the possessor of a secret has to receive the funds before such a refund can occur. + +===Lightning network=== + +In the lightning network, HTLC scripts are used to perform atomic swaps between payment channels. + +Alice constructs K and hashes it to produce L. She sends an HTLC payment to Bob for the preimage of L. Bob sends an HTLC payment to Carol for the same preimage and +amount. Only when Alice releases the preimage K does any exchange of value occur, and because the secret is divulged for each hop, all parties are compensated. If +at any point some parties become uncooperative, the process can be aborted via the refund conditions. + +===Zero-knowledge contingent payments=== + +Various practical zero-knowledge proving systems exist which can be used to guarantee that a hash preimage derives valuable information. As an example, a +zero-knowledge proof can be used to prove that a hash preimage acts as a decryption key for an encrypted sudoku puzzle solution. (See +[https://github.com/zcash/pay-to-sudoku pay-to-sudoku] for a concrete example of such a protocol.) + +HTLC transactions can be used to exchange such decryption keys for money without risk, and they do not require large or expensive-to-validate transactions. + +==Implementation== + +https://github.com/bitcoin/bitcoin/pull/7601 + +==Copyright== + +This document is dual licensed as BSD 3-clause, and Creative Commons CC0 1.0 Universal. + diff --git a/scripts/buildtable.pl b/scripts/buildtable.pl index f0e43d2..5589abb 100755 --- a/scripts/buildtable.pl +++ b/scripts/buildtable.pl @@ -3,17 +3,23 @@ use strict; use warnings; my $topbip = 9999; +my $include_layer = 1; my %RequiredFields = ( BIP => undef, Title => undef, Author => undef, + 'Comments-Summary' => undef, + 'Comments-URI' => undef, Status => undef, Type => undef, Created => undef, + # License => undef, (has exceptions) ); my %MayHaveMulti = ( Author => undef, + 'Comments-URI' => undef, + License => undef, 'Post-History' => undef, ); my %DateField = ( @@ -24,20 +30,24 @@ my %EmailField = ( Editor => undef, ); my %MiscField = ( + 'Comments-Summary' => undef, 'Discussions-To' => undef, 'Post-History' => undef, 'Replaces' => undef, 'Superseded-By' => undef, - 'Resolution' => undef, ); my %ValidLayer = ( - Process => undef, + 'Consensus (soft fork)' => undef, + 'Consensus (hard fork)' => undef, + 'Peer Services' => undef, + 'API/RPC' => undef, + 'Applications' => undef, ); my %ValidStatus = ( Draft => undef, Deferred => undef, - Accepted => "background-color: #ffffcf", + Proposed => "background-color: #ffffcf", Rejected => "background-color: #ffcfcf", Withdrawn => "background-color: #ffcfcf", Final => "background-color: #cfffcf", @@ -49,6 +59,34 @@ my %ValidType = ( 'Informational' => undef, 'Process' => undef, ); +my %RecommendedLicenses = ( + 'BSD-2-Clause' => undef, + 'BSD-3-Clause' => undef, + 'CC0-1.0' => undef, + 'GNU-All-Permissive' => undef, +); +my %AcceptableLicenses = ( + %RecommendedLicenses, + 'Apache-2.0' => undef, + 'BSL-1.0' => undef, + 'CC-BY-4.0' => undef, + 'CC-BY-SA-4.0' => undef, + 'MIT' => undef, + 'AGPL-3.0' => undef, + 'AGPL-3.0+' => undef, + 'FDL-1.3' => undef, + 'GPL-2.0' => undef, + 'GPL-2.0+' => undef, + 'LGPL-2.1' => undef, + 'LGPL-2.1+' => undef, +); +my %DefinedLicenses = ( + %AcceptableLicenses, + 'OPL' => undef, + 'PD' => undef, +); +my %GrandfatheredPD = map { $_ => undef } qw(9 36 37 38 42 49 50 60 65 67 69 74 80 81 83 90 99 105 107 109 111 112 113 114 122 124 125 126 130 131 132 133 140 141 142 143 144 146 147 150 151 152); +my %TolerateMissingLicense = map { $_ => undef } qw(1 10 11 12 13 14 15 16 21 31 33 34 35 39 43 44 45 47 61 64 68 70 71 72 73 101 102 106 120 121); my %emails; @@ -61,7 +99,7 @@ while (++$bipnum <= $topbip) { die "No <pre> in $fn" if eof $F; } my %found; - my ($title, $author, $status, $type); + my ($title, $author, $status, $type, $layer); my ($field, $val); while (<$F>) { m[^</pre>$] && last; @@ -69,6 +107,7 @@ while (++$bipnum <= $topbip) { $field = $1; $val = $2; die "Duplicate $field field in $fn" if exists $found{$field}; + die "Too many spaces in $fn" if $val =~ /^\s/; } 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; @@ -77,7 +116,6 @@ while (++$bipnum <= $topbip) { } 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; @@ -108,6 +146,16 @@ while (++$bipnum <= $topbip) { } } elsif ($field eq 'Layer') { # BIP 123 die "Invalid layer $val in $fn" unless exists $ValidLayer{$val}; + $layer = $val; + } elsif ($field eq 'License') { + die "Undefined license $val in $fn" unless exists $DefinedLicenses{$val}; + if (not $found{License}) { + die "Unacceptable license $val in $fn" unless exists $AcceptableLicenses{$val} or ($val eq 'PD' and exists $GrandfatheredPD{$bipnum}); + } + } elsif ($field eq 'Comments-URI') { + if (not $found{'Comments-URI'}) { + die unless $val eq sprintf('https://github.com/bitcoin/bips/wiki/Comments:BIP-%04d', $bipnum); + } } 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}) { @@ -115,6 +163,10 @@ while (++$bipnum <= $topbip) { } elsif (not exists $MiscField{$field}) { die "Unknown field $field in $fn"; } + ++$found{$field}; + } + if (not $found{License}) { + die "Missing License in $fn" unless exists $TolerateMissingLicense{$bipnum}; } for my $field (keys %RequiredFields) { die "Missing $field in $fn" unless $found{$field}; @@ -125,6 +177,13 @@ while (++$bipnum <= $topbip) { } print "\n"; print "| [[${fn}|${bipnum}]]\n"; + if ($include_layer) { + if (defined $layer) { + print "| ${layer}\n"; + } else { + print "|\n"; + } + } print "| ${title}\n"; print "| ${author}\n"; print "| ${type}\n"; |
