diff options
34 files changed, 2147 insertions, 44 deletions
diff --git a/README.mediawiki b/README.mediawiki index b8fa3f3..27150fd 100644 --- a/README.mediawiki +++ b/README.mediawiki @@ -27,6 +27,13 @@ Those proposing changes should consider that ultimately consent may rest with th | 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]] | @@ -589,6 +596,13 @@ Those proposing changes should consider that ultimately consent may rest with th | Standard | Draft |- +| [[bip-0135.mediawiki|135]] +| +| Generalized version bits voting +| Sancho Panza +| Informational +| Draft +|- | [[bip-0140.mediawiki|140]] | Consensus (soft fork) | Normalized TXID @@ -645,6 +659,20 @@ Those proposing changes should consider that ultimately consent may rest with th | Standard | Draft |- +| [[bip-0148.mediawiki|148]] +| Consensus (soft fork) +| Mandatory activation of segwit deployment +| Shaolin Fry +| Standard +| Draft +|- +| [[bip-0149.mediawiki|149]] +| Consensus (soft fork) +| Segregated Witness (second deployment) +| Shaolin Fry +| Standard +| Draft +|- | [[bip-0150.mediawiki|150]] | Peer Services | Peer Authentication @@ -665,6 +693,34 @@ Those proposing changes should consider that ultimately consent may rest with th | Matt Corallo | Standard | Draft +|- +| [[bip-0171.mediawiki|171]] +| Applications +| Currency/exchange rate information API +| Luke Dashjr +| Standard +| Draft +|- +| [[bip-0173.mediawiki|173]] +| Applications +| Base32 address format for native v0-16 witness outputs +| Pieter Wuille, Greg Maxwell +| Informational +| 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-0002/process.png b/bip-0002/process.png Binary files differindex a834947..b532799 100644 --- a/bip-0002/process.png +++ b/bip-0002/process.png diff --git a/bip-0002/process.svg b/bip-0002/process.svg index efaa02b..7bfbe7a 100644 --- a/bip-0002/process.svg +++ b/bip-0002/process.svg @@ -1,4 +1,4 @@ -<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 526 206" width="526" height="206"> +<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 720 206" width="720" height="206"> <defs> <style type="text/css"><![CDATA[ rect { @@ -20,7 +20,7 @@ <path d="M0,2 L0,11 L8,6 L0,2" style="fill: black;" /> </marker> </defs> - + <rect x="8" y="8" width="128" height="32"/> <text x="72" y="32" font-size="20" text-anchor="middle">Draft</text> <path d="M136,24 L200,24"/> @@ -32,18 +32,22 @@ <path d="M456,40 L456,80"/> <rect x="392" y="80" width="128" height="32"/> <text x="456" y="104" font-size="20" text-anchor="middle">Replaced</text> - + <path d="M120,40 L120,72 L200,72"/> <rect x="200" y="56" width="128" height="32"/> <text x="264" y="80" font-size="20" text-anchor="middle">Rejected</text> <path d="M328,32 L360,32 L360,72 L328,72" stroke-dasharray="4, 2"/> - + <path d="M88,40 L88,120 L200,120"/> <rect x="200" y="104" width="128" height="32"/> <text x="264" y="128" font-size="20" text-anchor="middle">Withdrawn</text> - + <path d="M24,40 L24,166"/> <rect x="8" y="166" width="128" height="32"/> <text x="72" y="190" font-size="20" text-anchor="middle">Deferred</text> <path d="M56,166 L56,40"/> + + <path d="M520,24 L584,24"/> + <rect x="584" y="8" width="128" height="32"/> + <text x="648" y="32" font-size="20" text-anchor="middle">Obsolete</text> </svg> diff --git a/bip-0008.mediawiki b/bip-0008.mediawiki new file mode 100644 index 0000000..3a1f207 --- /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 from the STARTED state, 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..8d3ca71 --- /dev/null +++ b/bip-0008/states.png diff --git a/bip-0032.mediawiki b/bip-0032.mediawiki index a4c1b96..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 @@ -259,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-0038.mediawiki b/bip-0038.mediawiki index e1e3558..bfe1f4a 100644 --- a/bip-0038.mediawiki +++ b/bip-0038.mediawiki @@ -4,7 +4,7 @@ Title: Passphrase-protected private key Author: Mike Caldwell <mcaldwell@swipeclock.com> Aaron Voisine <voisine@gmail.com> - Comments-Summary: No comments yet. + 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 diff --git a/bip-0039.mediawiki b/bip-0039.mediawiki index 4a6b41e..6ba8af0 100644 --- a/bip-0039.mediawiki +++ b/bip-0039.mediawiki @@ -6,7 +6,7 @@ Pavol Rusnak <stick@satoshilabs.com> Aaron Voisine <voisine@gmail.com> Sean Bowe <ewillbefull@gmail.com> - Comments-Summary: No comments yet. + Comments-Summary: Unanimously Discourage for implementation Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0039 Status: Proposed Type: Standards Track diff --git a/bip-0039/bip-0039-wordlists.md b/bip-0039/bip-0039-wordlists.md index aef1a23..045ad36 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,22 +8,22 @@ * [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"**) +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"**) However, code that only accepts Japanese phrases but does not generate or verify them should be fine as is. This is because when generating the seed, normalization as per the spec will automatically change the ideographic spaces into normal ASCII spaces, so as long as your code never shows the user an ASCII space separated phrase or tries to split the phrase input by the user, dealing with ASCII or Ideographic space is the same. -2. Word-wrapping doesn't work well, so making sure that words only word-wrap at one of the -ideographic spaces may be a necessary step. As a long word split in two could be mistaken easily +2. Word-wrapping doesn't work well, so making sure that words only word-wrap at one of the +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,19 +31,19 @@ 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)) -1. High priority on simple and common french words. +1. High priority on simple and common French words. 2. Only words with 5-8 letters. -3. A word is fully recognizable by typing the first 4 letters (special french characters "é-è" are considered equal to "e", for exemple "museau" and "musée" can not be together). +3. A word is fully recognizable by typing the first 4 letters (special French characters "é-è" are considered equal to "e", for example "museau" and "musée" can not be together). 4. Only infinitive verbs, adjectives and nouns. 5. No pronouns, no adverbs, no prepositions, no conjunctions, no interjections (unless a noun/adjective is also popular than its interjection like "mince;chouette"). 6. No numeral adjectives. @@ -65,7 +65,7 @@ Credits: @paoloaga @Polve Words chosen using the following rules: -1. Simple and common italian words. +1. Simple and common Italian words. 2. Length between 4 and 8 characters. 3. First 4 letters must be unique between all words. 4. No accents or special characters. @@ -76,8 +76,8 @@ Words chosen using the following rules: 9. No words with double vocals (like: lineetta). 10. No words already used in other language mnemonic sets. 11. If 3 of the first 4 letters are already used in the same sequence in another mnemonic word, there must be at least other 3 different letters. -12. If 3 of the first 4 letters are already used in the same sequence in another mnemonic word, there not must be the same sequence of 3 or more letters. +12. If 3 of the first 4 letters are already used in the same sequence in another mnemonic word, there must not be the same sequence of 3 or more letters. -Rules 11 and 12 prevent the selection words that are not different enough. This makes each word more recognizable among others and less error prone. For example: the wordlist contains "atono", then "atomo" is rejected, but "atomico" is good. +Rules 11 and 12 prevent the selection words that are not different enough. This makes each word more recognizable among others and less error prone. For example: the wordlist contains "atono", then "atomo" is rejected, but "atomico" is good. All the words have been manually selected and automatically checked against the rules. diff --git a/bip-0042.mediawiki b/bip-0042.mediawiki index 1b80605..00ac10c 100644 --- a/bip-0042.mediawiki +++ b/bip-0042.mediawiki @@ -3,7 +3,7 @@ Layer: Consensus (soft fork) Title: A finite monetary supply for Bitcoin Author: Pieter Wuille <pieter.wuille@gmail.com> - Comments-Summary: No comments yet. + Comments-Summary: Unanimously Recommended for implementation Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0042 Status: Draft Type: Standards Track diff --git a/bip-0044.mediawiki b/bip-0044.mediawiki index b13ba54..5ee2209 100644 --- a/bip-0044.mediawiki +++ b/bip-0044.mediawiki @@ -4,7 +4,7 @@ Title: Multi-Account Hierarchy for Deterministic Wallets Author: Marek Palatinus <slush@satoshilabs.com> Pavol Rusnak <stick@satoshilabs.com> - Comments-Summary: No comments yet. + Comments-Summary: Mixed review (one person) Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0044 Status: Proposed Type: Standards Track @@ -265,12 +265,16 @@ is required and a pull request to the above file should be created. ==Compatible wallets== -* [[https://mytrezor.com|myTREZOR web wallet]] ([[https://github.com/trezor/webwallet|source]]) -* [[https://play.google.com/store/apps/details?id=com.bonsai.wallet32|Wallet32 @ Android]] ([[https://github.com/ksedgwic/Wallet32|source]]) * [[https://play.google.com/store/apps/details?id=com.mycelium.wallet|Mycelium Bitcoin Wallet (Android)]] ([[https://github.com/mycelium-com/wallet|source]]) * [[https://copay.io/|Copay]] ([[https://github.com/bitpay/copay|source]]) -* [[https://maza.club/encompass|Encompass]] ([[https://github.com/mazaclub/encompass|source]]) * [[https://www.coinvault.io/|CoinVault]] ([[https://github.com/CoinVault/dotblock|source]]) +* [[https://samouraiwallet.com/|Samourai Wallet]] ([[https://github.com/Samourai-Wallet/samourai-wallet-android|source]]) + +* [[https://trezor.io/|TREZOR]] ([[https://github.com/trezor/|source]]) +* [[https://www.keepkey.com/|KeepKey]] ([[https://github.com/keepkey/|source]]) +* [[https://www.ledgerwallet.com/|Ledger Wallet]] ([[https://github.com/LedgerHQ|source]]) +* [[https://21.co/learn/21-lib-wallet/|21 Machine Wallet]] ([[https://github.com/21dotco|source]]) + ==Reference== * [[bip-0032.mediawiki|BIP32 - Hierarchical Deterministic Wallets]] diff --git a/bip-0047.mediawiki b/bip-0047.mediawiki index e16dd7f..ef680a0 100644 --- a/bip-0047.mediawiki +++ b/bip-0047.mediawiki @@ -8,7 +8,7 @@ RECENT CHANGES: Layer: Applications Title: Reusable Payment Codes for Hierarchical Deterministic Wallets Author: Justus Ranvier <justus@openbitcoinprivacyproject.org> - Comments-Summary: No comments yet. + Comments-Summary: Unanimously Discourage for implementation Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0047 Status: Draft Type: Informational diff --git a/bip-0060.mediawiki b/bip-0060.mediawiki index 4627dfb..8e9f289 100644 --- a/bip-0060.mediawiki +++ b/bip-0060.mediawiki @@ -3,7 +3,7 @@ Layer: Peer Services Title: Fixed Length "version" Message (Relay-Transactions Field) Author: Amir Taaki <genjix@riseup.net> - Comments-Summary: No comments yet. + Comments-Summary: Discouraged for implementation (one person) Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0060 Status: Draft Type: Standards Track diff --git a/bip-0061.mediawiki b/bip-0061.mediawiki index 2060658..1e3d41f 100644 --- a/bip-0061.mediawiki +++ b/bip-0061.mediawiki @@ -3,7 +3,7 @@ Layer: Peer Services Title: Reject P2P message Author: Gavin Andresen <gavinandresen@gmail.com> - Comments-Summary: No comments yet. + Comments-Summary: Controversial; some recommendation, and some discouragement Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0061 Status: Final Type: Standards Track diff --git a/bip-0066.mediawiki b/bip-0066.mediawiki index a47c82d..7cc3cf2 100644 --- a/bip-0066.mediawiki +++ b/bip-0066.mediawiki @@ -37,7 +37,7 @@ These operators all perform ECDSA verifications on pubkey/signature pairs, itera The following code specifies the behaviour of strict DER checking. Note that this function tests a signature byte vector which includes the 1-byte sighash flag that Bitcoin adds, even though that flag falls outside of the DER specification, and is unaffected by this proposal. The function is also not called for cases where the length of sig is 0, in order to provide a simple, short and efficiently-verifiable encoding for deliberately invalid signatures. -DER is specified in http://www.itu.int/rec/T-REC-X.690-200811-I/en . +DER is specified in https://www.itu.int/rec/T-REC-X.690/en . <pre> bool static IsValidSignatureEncoding(const std::vector<unsigned char> &sig) { diff --git a/bip-0069.mediawiki b/bip-0069.mediawiki index f262126..e9f9245 100644 --- a/bip-0069.mediawiki +++ b/bip-0069.mediawiki @@ -30,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-0074.mediawiki b/bip-0074.mediawiki index d1f1a23..01fcf2c 100644 --- a/bip-0074.mediawiki +++ b/bip-0074.mediawiki @@ -3,7 +3,7 @@ Layer: Applications Title: Allow zero value OP_RETURN in Payment Protocol Author: Toby Padilla <tobypadilla@gmail.com> - Comments-Summary: No comments yet. + Comments-Summary: Unanimously Discourage for implementation Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0074 Status: Draft Type: Standards Track diff --git a/bip-0075.mediawiki b/bip-0075.mediawiki index 2a6fdd5..1a8474f 100644 --- a/bip-0075.mediawiki +++ b/bip-0075.mediawiki @@ -6,7 +6,7 @@ Matt David <mgd@mgddev.com> Aaron Voisine <voisine@gmail.com> James MacWhyte <macwhyte@gmail.com> - Comments-Summary: No comments yet. + Comments-Summary: Recommended for implementation (one person) Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0075 Status: Draft Type: Standards Track diff --git a/bip-0090.mediawiki b/bip-0090.mediawiki index 653e40d..a2d3456 100644 --- a/bip-0090.mediawiki +++ b/bip-0090.mediawiki @@ -3,7 +3,7 @@ Layer: Consensus (hard fork) Title: Buried Deployments Author: Suhas Daftuar <sdaftuar@chaincode.com> - Comments-Summary: No comments yet. + Comments-Summary: Mostly Recommended for implementation, with some Discouragement Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0090 Status: Draft Type: Informational diff --git a/bip-0135.mediawiki b/bip-0135.mediawiki new file mode 100644 index 0000000..cb6f9a0 --- /dev/null +++ b/bip-0135.mediawiki @@ -0,0 +1,409 @@ +<pre> + BIP: 135 + Title: Generalized version bits voting + Author: Sancho Panza <sanch0panza@protonmail.com> + Comments-Summary: No comments yet. + Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0135 + https://bitco.in/forum/threads/bip9-generalized-version-bits-voting-bip-genvbvoting.1968/ + Status: Draft + Type: Informational + Created: 2017-03-29 + License: CC0-1.0 + GNU-All-Permissive + Post-History: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-April/013969.html + Replaces: 9 +</pre> + + +==Abstract== + +BIP9 introduced a mechanism for using the version bits to signal support for +backwards-compatible changes (soft-forks) using a tally over the previous 2016 +blocks computed at re-targeting intervals. It provided for a fixed threshold and +non-configurable lock-in interval applicable to all deployments on a chain. + +This document describes a generalized signaling scheme which allows each +signaling bit to have its own configurable threshold, window size (number of +blocks over which it is tallied) and a configurable lock-in period. + +It extends the semantics of the signaling bits to cover arbitrary consensus +changes, referred to under the general term 'forks'. The same range +of version bits is used for signaling. + +The states of the BIP9 state machine and its original parameters (name, bit, +starttime, timeout) are retained. Some state transition conditions are +extended by additional parameters ('threshold', 'windowsize', 'minlockedblocks', +'minlockedtime') to provide for fine-tuning of threshold and grace period. + + +==Motivation== + +The Bitcoin protocol requires a flexible scheme for finding consensus on +protocol changes, to ensure that it can adapt to the needs of the market and +remain competitive as an electronic payment system. + +While BIP9 has served the community well for previous deployments, there are +some shortcomings in its approach: + +* it specifically applies only to backward-compatible changes + +* its fixed 95% threshold is not flexible enough to allow for a 'spectrum of contentiousness' to be represented + +* small minorities can veto proposed changes, which can lead to undesirable stagnation + +A generalized revision of the BIP9 specification can address these issues +and satisfy the needs of the market for both soft and hard fork changes +as well as more flexible activation thresholds and upgrade (grace) periods. + +The proposal should allow more freedom of choice in activation strategies +while remaining backward compatible with respect to existing BIP9-based +deployments. + + +==Terms and conventions== + +The version bits used by this proposal for signaling deployment of forks are +referred to as 'signaling bits' or shortened to 'bits' where unambiguous. + +All times in this specification are in seconds since the epoch [1]. +Durations / time offsets are in seconds. + +The term 'MTP' refers to the 'median time past' which is calculated as the +median nTime of a block and its 10 predecessors. It is treated as a monotonic +clock defined by a chain, and evaluated on the ancestor of a block, i.e. + +MTP := '''GetMedianTimePast(block.parent)''' + +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. + + +==Specification== + + +===Backward compatibility=== + +This specification SHALL enable strict backward compatibility with existing +BIP9-based deployments through suitable parameter configuration. Any part of +the specification preventing full backward compatibility SHALL be considered +as erroneous and amended. + +As before, a set of configuration parameters SHALL exist for the version bits +for each chain supported by an implementation. This permits each bit to be +configured independently for each chain (mainnet, testnet, etc.) + + +===Signaling bits=== + + +The signaling bits SHALL comprise the 29 least significant bits of the +nVersion block header field. nVersion is a 32-bit field which is treated as +a little-endian integer. + +Signaling bits SHALL be assigned numbers from 0..28 ranging from the least +significant (bit 0) to the most significant (bit 28) in the range. + +The top 3 bits of nVersion MUST be set to 001 , yielding a range of possible +nVersion values between [0x20000000...0x3FFFFFFF], inclusive. + +If a block's nVersion does not have its top 3 bits set to 001, all its signaling +bits MUST be treated as if they are 0 (see also: 'Tallying' section below). + + +===Deployment states=== + +With each block and fork, we associate a deployment state. +The possible states are: + +# '''DEFINED''' is the first state that each fork starts out as. The genesis block for any chain SHALL by definition be in this state for each deployment. +# '''STARTED''' for blocks past the starttime. +# '''LOCKED_IN''' after STARTED, if at least threshold out of windowsize blocks have the associated bit set in nVersion, measured at next height that is evenly divisible by the windowsize. +# '''ACTIVE''' for all blocks after the grace period conditions have been met. +# '''FAILED''' if past the timeout time and LOCKED_IN was not reached. + +In accordance with BIP9, a block's state SHALL never depend on its own nVersion; +only on that of its ancestors. + + +===Fork deployment parameters=== + +Each fork deployment is specified by the following per-chain parameters: + +# The '''name''' specifies a very brief description of the fork, reasonable for use as an identifier. For deployments described in a single BIP, it is recommended to use the name "bipN" where N is the appropriate BIP number. +# The '''bit''' determines which bit in the nVersion field of the block is to be used to signal the fork deployment. It is chosen from the set {0,1,2,...,28}. +# The '''starttime''' specifies a minimum median time past (MTP) of a block at which the bit gains its meaning. +# The '''timeout''' specifies a time at which the deployment is considered failed. If the MTP of a block >= timeout and the fork has not yet locked in (including this block's bit state), the deployment is considered failed on all descendants of the block. +# The '''windowsize''' specifies the number of past blocks (including the block under consideration) to be taken into account for locking in a fork. +# The '''threshold''' specifies a number of blocks, in the range of 1..windowsize, which must signal for a fork in order to lock it in. The support is measured when the chain height is evenly divisible by the windowsize. If the windowsize is set to 2016 (as in BIP9) this coincides with the 2016-block re-targeting intervals. +# The '''minlockedblocks''' specifies a minimum number of blocks which a fork must remain in locked-in state before it can become active. Both minlockedblocks and minlockedtime (see below) must be satisfied before a fork can become active. +# The '''minlockedtime''' specifies a minimum grace time, an earliest time after lock-in at which the fork can become active. If the MTP of a block >= (minlockedtime + median time of the block that locked in the fork), then the fork becomes activated. Both minlockedtime and minlockedblocks (see above) must be satisfied before a fork can become active. + + +===Tallying=== + +If a block's nVersion does not have its top 3 bits set to 001, all its signaling +bits MUST be treated as if they are '0'. + +A signaling bit value of '1' SHALL indicate support of a fork and SHALL count +towards its tally on a chain. + +A signaling bit value of '0' SHALL indicate absence of support of a fork and +SHALL NOT count towards its tally on a chain. + +The signaling bits SHALL be tallied whenever the head of the active chain +changes (including after reorganizations). + + +===State transitions=== + +The following diagram illustrates the generalized state machine: + +<img src="bip-0135/bip-0135-states-small.png" align="middle"></img> +<br> + +'''NOTES:''' + +The genesis block of any chain SHALL have the state DEFINED for each deployment. + +A given deployment SHALL remain in the DEFINED state until it either passes the +starttime (and becomes STARTED) or the timeout time (and becomes FAILED). + +Once a deployment has STARTED, the signal for that deployment SHALL be tallied +over the the past windowsize blocks whenever a new block is received on that +chain. + +A transition from the STARTED state to the LOCKED_IN state SHALL only occur +when all of these are true: + +* the height of the received block is an integer multiple of the window size +* the MTP is below the timeout time +* at least threshold out of windowsize blocks have signaled support + +A similar height synchronization precondition SHALL exist for the transition from +LOCKED_IN to ACTIVE. +These synchronization conditions are expressed by the "mod(height, windowsize) = 0" +clauses in the diagram, and have been been added so that backward compatibility +with BIP9's use of the 2016-block re-targeting periods can be configured for +existing deployments (see above 'Optional full backward compatibility' section). + +A transition from LOCKED_IN to ACTIVE state SHALL only occur if the height +synchronization criterion is met and two configurable 'grace period' conditions +are fulfilled: + +# current height MUST be at least minlockedblocks above LOCKED_IN height +# MTP must exceed LOCKED_IN time by at least minlockedtime seconds + +NOTE: If minlockedtime and minlockedblocks are both set to 0, then the fork will +proceed directly to ACTIVE state once the chain height reaches a multiple of the +windowsize. + +The ACTIVE and FAILED states are terminal; a deployment stays in these states +once they are reached. + +Deployment states are maintained along block chain branches. +They need re-computation when a reorganization happens. + + +===New consensus rules=== + +New consensus rules deployed by a fork SHALL be enforced for each block that has +ACTIVE state. + + +===Optional operator notifications=== + +An implementation SHOULD notify the operator when a deployment transitions +to STARTED, LOCKED_IN, ACTIVE or FAILED states. + +It is RECOMMENDED that an implementation provide finer-grained notifications +to the operator which allow him/her to track the measured support level for +defined deployments. + +An implementation SHOULD warn the operator if the configured (emitted) nVersion +has been overridden to contain bits set to '1' in contravention of the above +non-signaling recommendations for DEFINED forks. + +It is RECOMMENDED that an implementation warn the operator if no signal has +been received for a given deployment during a full windowsize period after the +deployment has STARTED. This could indicate that something may be wrong with +the operator's configuration that is causing them not to receive the signal +correctly. + +For undefined signals, it is RECOMMENDED that implementation track these and +alert their operators with supportive upgrade notifications, e.g. + +* "warning: signaling started on unknown feature on version bit X" +* "warning: signaling on unknown feature reached X% (over last N blocks)" +* "info: signaling ceased on unknown feature (over last M blocks)" + +Since parameters of these deployments are unknown, it is RECOMMENDED that +implementations allow the user to configure the emission of such notifications +(e.g. suitable N and M parameters in the messages above, e.g. a best-guess +window of 100 blocks). + + +===getblocktemplate changes=== + +The getblocktemplate features introduced in BIP9 remain in effect unmodified. + + +==Rationale== + +The timeout into FAILED state allows eventual reuse of bits if a fork was not +successfully activated. + +A fallow period at the conclusion of a fork attempt allows some detection of +buggy clients, and allows time for warnings and software upgrades for +successful forks. The duration of a fallow period is not specified by this +proposal, although a conventional fallow period of 3 months is RECOMMENDED. + +Due to the constraints set by BIP 34, BIP 66 and BIP 65, there are only +0x7FFFFFFB possible nVersion values available. This limits to at most 30 +independent deployments. +By restricting the top 3 bits to 001 we we are left with 29 out of those for +the purposes of this proposal, and support two future upgrades for different +mechanisms (top bits 010 and 011). + + +==Guidelines== + + +===Parameter selection guidelines=== + +The following guidelines are suggested for selecting the parameters for a fork: + +# '''name''' SHOULD be selected such that no two forks, concurrent or otherwise, ever use the same name. +# '''bit''' SHOULD be selected such that no two concurrent forks use the same bit. Implementors should make an effort to consult resources such as [2] to establish whether the bit they wish to use can reasonably be assumed to be unclaimed by a concurrent fork, and to announce their use ('claim') of a bit for a fork purpose on various project mailing lists, to reduce chance of collisions. +# '''starttime''' SHOULD be set to some date in the future, approximately one month after a software release date which includes the fork signaling. This allows for some release delays, while preventing triggers as a result of parties running pre-release software. +# '''timeout''' is RECOMMENDED to be 1 year (31536000 seconds) after starttime. +# '''windowsize''' SHOULD be set large enough to allow reception of an adequately precise signal. A good high-resolution value would be 2016 blocks as used in BIP9. It is NOT RECOMMENDED to use a windowsize less than 100 blocks. +# '''threshold''' SHOULD be set as high as possible to ensure a smooth activation based on the estimated support and the nature of the proposed changes. It is strongly RECOMMENDED that threshold >= windowsize / 2 (rounded up) to ensure that a proposal is only activated by majority support. +# '''minlockedblocks''' is RECOMMENDED to be set >= windowsize, to ensure that a full window passes in LOCKED_IN state. Lower values will be ineffective as the transition from LOCKED_IN to ACTIVE is guarded by a synchronization based on the window size. +# '''minlockedtime''' SHOULD only be set > 0 if a minimum LOCKED_IN time period needs be strictly enforced. It is permissible to set minlockedblocks to 0 and only specify minlockedtime, however the synchronization condition means the grace period can only expire once the time has passed AND the chain height is a multiple of the windowsize. + +NOTE: If minlockedtime and minlockedblocks are both set to 0, then the fork will +proceed to ACTIVE state when the chain height reaches a multiple of the windowsize. + +A later deployment using the same bit is possible as long as the starttime is +after the previous fork's timeout or activation, but it is discouraged until +necessary, and even then recommended to have a pause in between to detect +buggy software. + + +===Signaling guidelines=== + +An implementation SHOULD signal '0' on a bit if one of the following holds true: + +* the deployment parameters are not DEFINED (not configured or explicitly undefined) +* the deployment is DEFINED and has not yet reached the STARTED state +* the deployment has succeeded (it has become ACTIVE) +* the deployment has FAILED + +An implementation SHOULD enable the operator to choose (override) whether to +signal '0' or '1' on a bit, once its deployment has at least reached the STARTED +state. + +An implementation SHOULD warn the operator if the configured (emitted) nVersion +has been overridden to contain bits set to '1' in contravention of the above +non-signaling recommendations. + +A supporting miner SHOULD signal '1' on a bit for which the deployment +is LOCKED_IN state so that uptake is visible. However, this has no effect on +consensus rules. +Once LOCKED_IN, a deployment proceeds to ACTIVE solely based on the configured +grace period parameters (see 'Fork deployment parameters' above). + +A miner SHOULD signal '0' on a bit if they wish to suspend signaling of support +for a fork that is DEFINED in their software. + +It is NOT RECOMMENDED to signal '1' for bits where the meaning is undefined +(i.e. bits which are unclaimed by proposals). + + +===Settings for BIP9 compatibility=== + +This section lists parameter values which can be used to effect compatibility +with the existing BIP9 versionbits state machine. + +The following table describes mainnet compatibility options (95%, 2016 blocks): + +{| class="wikitable" +!colspan=3 | +|- +! Parameter !! BIP9 value !! BIP135 value +|- +| name || some_name || some_name +|- +| bit || b || b +|- +| starttime || T_start || T_start +|- +| timeout || T_timeout || T_timeout +|- +| windowsize || n/a || 2016 +|- +| threshold || n/a || 1916 +|- +| minlockedblocks || n/a || 2016 +|- +| minlockedtime || n/a || 0 +|} + +The following table describes testnet compatibility options (75%, 2016 blocks): + +{| class="wikitable" +!colspan=3 | +|- +! Parameter !! BIP9 value !! BIP135 value +|- +| name || some_name || some_name +|- +| bit || b || b +|- +| starttime || T_start || T_start +|- +| timeout || T_timeout || T_timeout +|- +| windowsize || n/a || 2016 +|- +| threshold || n/a || 1512 +|- +| minlockedblocks || n/a || 2016 +|- +| minlockedtime || n/a || 0 +|} + + +==Deployment== + +As this BIP is not itself consensus-relevant (Information like BIP9), it can +be rolled out without the use of a BIP9 fork bit. + +Backward compatibility through judicious fork configuration parameters should +ensure that it does not interfere with existing known deployments. + +By way of design it does not interfere with unknown (undefined) deployments. + + +==Reference implementation== + +A working reference implementation, including tests, can be found in this Pull Request: + +https://github.com/BitcoinUnlimited/BitcoinUnlimited/pull/458 + +Existing unit tests and regression tests have been left active to demonstrate +backward compatibility of the default settings with BIP9. + + +==References== + +[1] http://pubs.opengroup.org/onlinepubs/9699919799/xrat/V4_xbd_chap04.html#tag_21_04_16 + +[2] [[https://github.com/bitcoin/bips/blob/master/bip-0009/assignments.mediawiki|List of existing BIP9 deployment proposals]] + + +==Copyright== + +This BIP is dual-licensed under the Creative Commons CC0 1.0 Universal and +GNU All-Permissive licenses. diff --git a/bip-0135/bip-0135-states-small.png b/bip-0135/bip-0135-states-small.png Binary files differnew file mode 100644 index 0000000..9191ae3 --- /dev/null +++ b/bip-0135/bip-0135-states-small.png diff --git a/bip-0135/bip-0135-states.png b/bip-0135/bip-0135-states.png Binary files differnew file mode 100644 index 0000000..ace0617 --- /dev/null +++ b/bip-0135/bip-0135-states.png diff --git a/bip-0135/bip-0135-states.svg b/bip-0135/bip-0135-states.svg new file mode 100644 index 0000000..4b06ef9 --- /dev/null +++ b/bip-0135/bip-0135-states.svg @@ -0,0 +1,598 @@ +<?xml version="1.0" encoding="UTF-8" standalone="no"?> +<!-- Created with Inkscape (http://www.inkscape.org/) --> + +<svg + xmlns:dc="http://purl.org/dc/elements/1.1/" + xmlns:cc="http://creativecommons.org/ns#" + xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" + xmlns:svg="http://www.w3.org/2000/svg" + xmlns="http://www.w3.org/2000/svg" + xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd" + xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape" + width="744.09448819" + height="1052.3622047" + id="svg2" + version="1.1" + inkscape:version="0.48.3.1 r9886" + sodipodi:docname="bip-0135-states.svg"> + <defs + id="defs4"> + <marker + inkscape:stockid="Arrow2Send" + orient="auto" + refY="0.0" + refX="0.0" + id="Arrow2Send" + style="overflow:visible;"> + <path + id="path3908" + style="fill-rule:evenodd;stroke-width:0.62500000;stroke-linejoin:round;" + d="M 8.7185878,4.0337352 L -2.2072895,0.016013256 L 8.7185884,-4.0017078 C 6.9730900,-1.6296469 6.9831476,1.6157441 8.7185878,4.0337352 z " + transform="scale(0.3) rotate(180) translate(-2.3,0)" /> + </marker> + <marker + inkscape:stockid="Arrow2Mend" + orient="auto" + refY="0.0" + refX="0.0" + id="Arrow2Mend" + style="overflow:visible;"> + <path + id="path3902" + style="fill-rule:evenodd;stroke-width:0.62500000;stroke-linejoin:round;" + d="M 8.7185878,4.0337352 L -2.2072895,0.016013256 L 8.7185884,-4.0017078 C 6.9730900,-1.6296469 6.9831476,1.6157441 8.7185878,4.0337352 z " + transform="scale(0.6) rotate(180) translate(0,0)" /> + </marker> + <marker + inkscape:stockid="Arrow1Mend" + orient="auto" + refY="0.0" + refX="0.0" + id="Arrow1Mend" + style="overflow:visible;"> + <path + id="path3884" + d="M 0.0,0.0 L 5.0,-5.0 L -12.5,0.0 L 5.0,5.0 L 0.0,0.0 z " + style="fill-rule:evenodd;stroke:#000000;stroke-width:1.0pt;" + transform="scale(0.4) rotate(180) translate(10,0)" /> + </marker> + <marker + inkscape:stockid="Arrow1Send" + orient="auto" + refY="0.0" + refX="0.0" + id="Arrow1Send" + style="overflow:visible;"> + <path + id="path3890" + d="M 0.0,0.0 L 5.0,-5.0 L -12.5,0.0 L 5.0,5.0 L 0.0,0.0 z " + style="fill-rule:evenodd;stroke:#000000;stroke-width:1.0pt;" + transform="scale(0.2) rotate(180) translate(6,0)" /> + </marker> + <marker + inkscape:stockid="EmptyTriangleOutL" + orient="auto" + refY="0.0" + refX="0.0" + id="EmptyTriangleOutL" + style="overflow:visible"> + <path + id="path4035" + d="M 5.77,0.0 L -2.88,5.0 L -2.88,-5.0 L 5.77,0.0 z " + style="fill-rule:evenodd;fill:#FFFFFF;stroke:#000000;stroke-width:1.0pt" + transform="scale(0.8) translate(-6,0)" /> + </marker> + <marker + inkscape:stockid="Arrow1Lend" + orient="auto" + refY="0.0" + refX="0.0" + id="Arrow1Lend" + style="overflow:visible;"> + <path + id="path3878" + d="M 0.0,0.0 L 5.0,-5.0 L -12.5,0.0 L 5.0,5.0 L 0.0,0.0 z " + style="fill-rule:evenodd;stroke:#000000;stroke-width:1.0pt;" + transform="scale(0.8) rotate(180) translate(12.5,0)" /> + </marker> + <marker + inkscape:stockid="Arrow2Lend" + orient="auto" + refY="0.0" + refX="0.0" + id="Arrow2Lend" + style="overflow:visible;"> + <path + id="path3896" + style="fill-rule:evenodd;stroke-width:0.62500000;stroke-linejoin:round;" + d="M 8.7185878,4.0337352 L -2.2072895,0.016013256 L 8.7185884,-4.0017078 C 6.9730900,-1.6296469 6.9831476,1.6157441 8.7185878,4.0337352 z " + transform="scale(1.1) rotate(180) translate(1,0)" /> + </marker> + <marker + inkscape:stockid="Arrow2Lstart" + orient="auto" + refY="0.0" + refX="0.0" + id="Arrow2Lstart" + style="overflow:visible"> + <path + id="path3893" + style="fill-rule:evenodd;stroke-width:0.62500000;stroke-linejoin:round" + d="M 8.7185878,4.0337352 L -2.2072895,0.016013256 L 8.7185884,-4.0017078 C 6.9730900,-1.6296469 6.9831476,1.6157441 8.7185878,4.0337352 z " + transform="scale(1.1) translate(1,0)" /> + </marker> + <marker + inkscape:stockid="Arrow2Mend" + orient="auto" + refY="0" + refX="0" + id="Arrow2Mend-7" + style="overflow:visible"> + <path + inkscape:connector-curvature="0" + id="path3902-3" + style="fill-rule:evenodd;stroke-width:0.625;stroke-linejoin:round" + d="M 8.7185878,4.0337352 -2.2072895,0.01601326 8.7185884,-4.0017078 c -1.7454984,2.3720609 -1.7354408,5.6174519 -6e-7,8.035443 z" + transform="scale(-0.6,-0.6)" /> + </marker> + <marker + inkscape:stockid="Arrow2Mend" + orient="auto" + refY="0" + refX="0" + id="Arrow2Mend-1" + style="overflow:visible"> + <path + inkscape:connector-curvature="0" + id="path3902-2" + style="fill-rule:evenodd;stroke-width:0.625;stroke-linejoin:round" + d="M 8.7185878,4.0337352 -2.2072895,0.01601326 8.7185884,-4.0017078 c -1.7454984,2.3720609 -1.7354408,5.6174519 -6e-7,8.035443 z" + transform="scale(-0.6,-0.6)" /> + </marker> + <marker + inkscape:stockid="Arrow2Mend" + orient="auto" + refY="0" + refX="0" + id="Arrow2Mend-15" + style="overflow:visible"> + <path + inkscape:connector-curvature="0" + id="path3902-0" + style="fill-rule:evenodd;stroke-width:0.625;stroke-linejoin:round" + d="M 8.7185878,4.0337352 -2.2072895,0.01601326 8.7185884,-4.0017078 c -1.7454984,2.3720609 -1.7354408,5.6174519 -6e-7,8.035443 z" + transform="scale(-0.6,-0.6)" /> + </marker> + <marker + inkscape:stockid="Arrow2Mend" + orient="auto" + refY="0" + refX="0" + id="Arrow2Mend-0" + style="overflow:visible"> + <path + inkscape:connector-curvature="0" + id="path3902-4" + style="fill-rule:evenodd;stroke-width:0.625;stroke-linejoin:round" + d="M 8.7185878,4.0337352 -2.2072895,0.01601326 8.7185884,-4.0017078 c -1.7454984,2.3720609 -1.7354408,5.6174519 -6e-7,8.035443 z" + transform="scale(-0.6,-0.6)" /> + </marker> + <marker + inkscape:stockid="Arrow2Mend" + orient="auto" + refY="0" + refX="0" + id="Arrow2Mend-11" + style="overflow:visible"> + <path + inkscape:connector-curvature="0" + id="path3902-30" + style="fill-rule:evenodd;stroke-width:0.625;stroke-linejoin:round" + d="M 8.7185878,4.0337352 -2.2072895,0.01601326 8.7185884,-4.0017078 c -1.7454984,2.3720609 -1.7354408,5.6174519 -6e-7,8.035443 z" + transform="scale(-0.6,-0.6)" /> + </marker> + <marker + inkscape:stockid="Arrow2Mend" + orient="auto" + refY="0" + refX="0" + id="Arrow2Mend-6" + style="overflow:visible"> + <path + inkscape:connector-curvature="0" + id="path3902-5" + style="fill-rule:evenodd;stroke-width:0.625;stroke-linejoin:round" + d="M 8.7185878,4.0337352 -2.2072895,0.01601326 8.7185884,-4.0017078 c -1.7454984,2.3720609 -1.7354408,5.6174519 -6e-7,8.035443 z" + transform="scale(-0.6,-0.6)" /> + </marker> + <marker + inkscape:stockid="Arrow2Mend" + orient="auto" + refY="0" + refX="0" + id="Arrow2Mend-2" + style="overflow:visible"> + <path + inkscape:connector-curvature="0" + id="path3902-21" + style="fill-rule:evenodd;stroke-width:0.625;stroke-linejoin:round" + d="M 8.7185878,4.0337352 -2.2072895,0.01601326 8.7185884,-4.0017078 c -1.7454984,2.3720609 -1.7354408,5.6174519 -6e-7,8.035443 z" + transform="scale(-0.6,-0.6)" /> + </marker> + </defs> + <sodipodi:namedview + id="base" + pagecolor="#ffffff" + bordercolor="#666666" + borderopacity="1.0" + inkscape:pageopacity="0.0" + inkscape:pageshadow="2" + inkscape:zoom="0.98994949" + inkscape:cx="349.38128" + inkscape:cy="598.85682" + inkscape:document-units="px" + inkscape:current-layer="layer1" + showgrid="true" + showguides="true" + inkscape:guide-bbox="true" + inkscape:window-width="1280" + inkscape:window-height="1004" + inkscape:window-x="1917" + inkscape:window-y="-3" + inkscape:window-maximized="1"> + <sodipodi:guide + orientation="1,0" + position="400,637.14286" + id="guide2985" /> + <inkscape:grid + type="xygrid" + id="grid2987" /> + </sodipodi:namedview> + <metadata + id="metadata7"> + <rdf:RDF> + <cc:Work + rdf:about=""> + <dc:format>image/svg+xml</dc:format> + <dc:type + rdf:resource="http://purl.org/dc/dcmitype/StillImage" /> + <dc:title></dc:title> + </cc:Work> + </rdf:RDF> + </metadata> + <g + inkscape:label="Layer 1" + inkscape:groupmode="layer" + id="layer1"> + <rect + style="fill:none;stroke:#000000;stroke-width:1.27499998;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none" + id="rect3759" + width="180" + height="60" + x="60" + y="212.36218" + inkscape:export-xdpi="300.02325" + inkscape:export-ydpi="300.02325" /> + <text + xml:space="preserve" + style="font-size:40px;font-style:normal;font-weight:normal;line-height:125%;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans" + x="100" + y="252.36218" + id="text3761" + sodipodi:linespacing="125%" + inkscape:export-xdpi="300.02325" + inkscape:export-ydpi="300.02325"><tspan + sodipodi:role="line" + id="tspan3763" + x="100" + y="252.36218" + style="font-size:24px;font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;font-family:Monospace;-inkscape-font-specification:Monospace Bold">DEFINED</tspan></text> + <rect + style="fill:none;stroke:#000000;stroke-width:1.27499998;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none" + id="rect3759-4" + width="180" + height="60" + x="60" + y="372.36218" + inkscape:export-xdpi="300.02325" + inkscape:export-ydpi="300.02325" /> + <text + xml:space="preserve" + style="font-size:40px;font-style:normal;font-weight:normal;line-height:125%;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans" + x="100" + y="412.36218" + id="text3761-9" + sodipodi:linespacing="125%" + inkscape:export-xdpi="300.02325" + inkscape:export-ydpi="300.02325"><tspan + sodipodi:role="line" + id="tspan3763-9" + x="100" + y="412.36218" + style="font-size:24px;font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;font-family:Monospace;-inkscape-font-specification:Monospace Bold">STARTED</tspan></text> + <rect + style="fill:none;stroke:#000000;stroke-width:1.27499998;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none" + id="rect3759-0" + width="220" + height="60" + x="40" + y="532.36218" + inkscape:export-xdpi="300.02325" + inkscape:export-ydpi="300.02325" /> + <text + xml:space="preserve" + style="font-size:46.18802261px;font-style:normal;font-weight:normal;line-height:125%;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans" + x="69.282005" + y="660.90692" + id="text3761-8" + sodipodi:linespacing="125%" + transform="scale(1.1547005,0.86602543)" + inkscape:export-xdpi="300.02325" + inkscape:export-ydpi="300.02325"><tspan + sodipodi:role="line" + id="tspan3763-93" + x="69.282005" + y="660.90692" + style="font-size:24px;font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;font-family:Monospace;-inkscape-font-specification:Monospace Bold">LOCKED_IN</tspan></text> + <rect + style="fill:none;stroke:#000000;stroke-width:1.20957112;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none" + id="rect3759-4-1" + width="180" + height="60" + x="60" + y="692.36218" + inkscape:export-xdpi="300.02325" + inkscape:export-ydpi="300.02325" /> + <text + xml:space="preserve" + style="font-size:40px;font-style:normal;font-weight:normal;line-height:125%;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans" + x="100" + y="732.36218" + id="text3761-9-4" + sodipodi:linespacing="125%" + inkscape:export-xdpi="300.02325" + inkscape:export-ydpi="300.02325"><tspan + sodipodi:role="line" + id="tspan3763-9-8" + x="100" + y="732.36218" + style="font-size:24px;font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;font-family:Monospace;-inkscape-font-specification:Monospace Bold">ACTIVE</tspan></text> + <rect + style="fill:none;stroke:#000000;stroke-width:1.27499998;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none" + id="rect3759-4-9" + width="180" + height="60" + x="390" + y="292.36218" + inkscape:export-xdpi="300.02325" + inkscape:export-ydpi="300.02325" /> + <text + xml:space="preserve" + style="font-size:40px;font-style:normal;font-weight:normal;line-height:125%;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans" + x="430" + y="332.36218" + id="text3761-9-6" + sodipodi:linespacing="125%" + inkscape:export-xdpi="300.02325" + inkscape:export-ydpi="300.02325"><tspan + sodipodi:role="line" + id="tspan3763-9-7" + x="430" + y="332.36218" + style="font-size:24px;font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;font-family:Monospace;-inkscape-font-specification:Monospace Bold">FAILED</tspan></text> + <path + sodipodi:type="arc" + style="fill:none;stroke:#000000;stroke-width:9.2748518;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none;marker-start:none;marker-end:url(#Arrow2Mend)" + id="path3869" + sodipodi:cx="140" + sodipodi:cy="142.36218" + sodipodi:rx="80" + sodipodi:ry="70" + d="m 194.86409,193.30741 a 80,70 0 1 1 24.86632,-56.68713" + sodipodi:start="0.8150924" + sodipodi:end="6.2010659" + sodipodi:open="true" + transform="matrix(0.3037615,0,0,0.35042181,-2.52661,162.0049)" + inkscape:export-xdpi="300.02325" + inkscape:export-ydpi="300.02325" /> + <path + style="fill:none;stroke:#000000;stroke-width:3;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none;marker-end:url(#Arrow2Mend)" + d="m 240,242.36218 150,50" + id="path6409" + inkscape:connector-curvature="0" + sodipodi:nodetypes="cc" + inkscape:export-xdpi="300.02325" + inkscape:export-ydpi="300.02325" /> + <path + style="fill:none;stroke:#000000;stroke-width:3;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none;marker-end:url(#Arrow2Mend)" + d="m 150,272.36218 0,100" + id="path6409-7" + inkscape:connector-curvature="0" + sodipodi:nodetypes="cc" + inkscape:export-xdpi="300.02325" + inkscape:export-ydpi="300.02325" /> + <path + style="fill:none;stroke:#000000;stroke-width:3;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none;marker-end:url(#Arrow2Mend)" + d="m 150,432.36218 0,100" + id="path6409-7-2" + inkscape:connector-curvature="0" + sodipodi:nodetypes="cc" + inkscape:export-xdpi="300.02325" + inkscape:export-ydpi="300.02325" /> + <path + style="fill:none;stroke:#000000;stroke-width:3;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none;marker-end:url(#Arrow2Mend)" + d="m 150,592.36218 0,100" + id="path6409-7-9" + inkscape:connector-curvature="0" + sodipodi:nodetypes="cc" + inkscape:export-xdpi="300.02325" + inkscape:export-ydpi="300.02325" /> + <path + style="fill:none;stroke:#000000;stroke-width:3;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none;marker-end:url(#Arrow2Mend)" + d="m 240,402.36218 150,-50" + id="path6409-0" + inkscape:connector-curvature="0" + sodipodi:nodetypes="cc" + inkscape:export-xdpi="300.02325" + inkscape:export-ydpi="300.02325" /> + <text + xml:space="preserve" + style="font-size:40px;font-style:normal;font-weight:normal;line-height:125%;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans" + x="160" + y="322.36218" + id="text6692" + sodipodi:linespacing="125%" + inkscape:export-xdpi="300.02325" + inkscape:export-ydpi="300.02325"><tspan + sodipodi:role="line" + id="tspan6694" + x="160" + y="322.36218" + style="font-size:14px">starttime <= MTP < timeout</tspan></text> + <text + xml:space="preserve" + style="font-size:40px;font-style:normal;font-weight:normal;line-height:125%;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans" + x="330" + y="262.36218" + id="text6692-1" + sodipodi:linespacing="125%" + inkscape:export-xdpi="300.02325" + inkscape:export-ydpi="300.02325"><tspan + sodipodi:role="line" + id="tspan6694-3" + x="330" + y="262.36218" + style="font-size:14px">MTP >= timeout</tspan></text> + <text + xml:space="preserve" + style="font-size:40px;font-style:normal;font-weight:normal;line-height:125%;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans" + x="330" + y="392.36218" + id="text6692-1-7" + sodipodi:linespacing="125%" + inkscape:export-xdpi="300.02325" + inkscape:export-ydpi="300.02325"><tspan + sodipodi:role="line" + id="tspan6694-3-4" + x="330" + y="392.36218" + style="font-size:14px">MTP >= timeout</tspan></text> + <path + sodipodi:type="arc" + style="fill:none;stroke:#000000;stroke-width:9.2748518;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none;marker-start:none;marker-end:url(#Arrow2Mend)" + id="path3869-3" + sodipodi:cx="140" + sodipodi:cy="142.36218" + sodipodi:rx="80" + sodipodi:ry="70" + d="m 194.86409,193.30741 a 80,70 0 1 1 24.86632,-56.68713" + sodipodi:start="0.8150924" + sodipodi:end="6.2010659" + sodipodi:open="true" + transform="matrix(0.3037615,0,0,0.35042181,-2.52661,317.94584)" + inkscape:export-xdpi="300.02325" + inkscape:export-ydpi="300.02325" /> + <text + xml:space="preserve" + style="font-size:40px;font-style:normal;font-weight:normal;line-height:125%;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans" + x="160" + y="468.36218" + id="text6692-2" + sodipodi:linespacing="125%" + inkscape:export-xdpi="300.02325" + inkscape:export-ydpi="300.02325"><tspan + sodipodi:role="line" + id="tspan6694-1" + x="160" + y="468.36218" + style="font-size:14px"> (mod(height, windowsize) = 0)</tspan><tspan + sodipodi:role="line" + x="160" + y="485.86218" + style="font-size:14px" + id="tspan6856"> AND</tspan><tspan + sodipodi:role="line" + x="160" + y="503.36218" + style="font-size:14px" + id="tspan6858">(MTP < timeout) AND (threshold reached)</tspan></text> + <text + xml:space="preserve" + style="font-size:40px;font-style:normal;font-weight:normal;line-height:125%;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans" + x="110" + y="612.36218" + id="text6692-2-7" + sodipodi:linespacing="125%" + inkscape:export-xdpi="300.02325" + inkscape:export-ydpi="300.02325"><tspan + sodipodi:role="line" + id="tspan6694-1-5" + x="110" + y="612.36218" + style="font-size:14px"> (mod(height, windowsize) = 0)</tspan><tspan + sodipodi:role="line" + x="110" + y="629.86218" + style="font-size:14px" + id="tspan6804"> AND</tspan><tspan + sodipodi:role="line" + x="110" + y="647.36218" + style="font-size:14px" + id="tspan6806"> (height >= locked_in_height + minlockedblocks) </tspan><tspan + sodipodi:role="line" + x="110" + y="664.86218" + style="font-size:14px" + id="tspan3052"> AND</tspan><tspan + sodipodi:role="line" + x="110" + y="682.36218" + style="font-size:14px" + id="tspan3054"> (MTP >= locked_in_time + minlockedtime)</tspan></text> + <path + sodipodi:type="arc" + style="fill:none;stroke:#000000;stroke-width:9.2748518;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none;marker-start:none;marker-end:url(#Arrow2Mend)" + id="path3869-3-4" + sodipodi:cx="140" + sodipodi:cy="142.36218" + sodipodi:rx="80" + sodipodi:ry="70" + d="m 194.86409,193.30741 a 80,70 0 1 1 24.86632,-56.68713" + sodipodi:start="0.8150924" + sodipodi:end="6.2010659" + sodipodi:open="true" + transform="matrix(0.3037615,0,0,0.35042181,-2.52661,637.94584)" + inkscape:export-xdpi="300.02325" + inkscape:export-ydpi="300.02325" /> + <path + sodipodi:type="arc" + style="fill:none;stroke:#000000;stroke-width:9.2748518;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none;marker-start:none;marker-end:url(#Arrow2Mend)" + id="path3869-3-4-7" + sodipodi:cx="140" + sodipodi:cy="142.36218" + sodipodi:rx="80" + sodipodi:ry="70" + d="m 194.86409,193.30741 a 80,70 0 1 1 24.86632,-56.68713" + sodipodi:start="0.8150924" + sodipodi:end="6.2010659" + sodipodi:open="true" + transform="matrix(-0.3037615,0,0,0.35042181,632.52661,237.0049)" + inkscape:export-xdpi="300.02325" + inkscape:export-ydpi="300.02325" /> + <text + xml:space="preserve" + style="font-size:40px;font-style:normal;font-weight:normal;line-height:125%;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans" + x="80" + y="642.36218" + id="text6692-1-3" + sodipodi:linespacing="125%" + inkscape:export-xdpi="300.02325" + inkscape:export-ydpi="300.02325"><tspan + sodipodi:role="line" + id="tspan6694-3-6" + x="80" + y="642.36218" + style="font-size:14px;font-style:italic;-inkscape-font-specification:Sans Italic">(Always)</tspan></text> + </g> +</svg> 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-0149.mediawiki b/bip-0149.mediawiki new file mode 100644 index 0000000..c2a1853 --- /dev/null +++ b/bip-0149.mediawiki @@ -0,0 +1,69 @@ +<pre> + BIP: 149 + Layer: Consensus (soft fork) + Title: Segregated Witness (second deployment) + Author: Shaolin Fry <shaolinfry@protonmail.ch> + Comments-Summary: No comments yet. + Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0149 + Status: Draft + Type: Standards Track + Created: 2017-04-14 + License: BSD-3-Clause + CC0-1.0 +</pre> + +==Abstract== + +This document specifies a user activated soft fork for [[bip-0141.mediawiki|BIP141]], [[bip-0143.mediawiki|BIP143]] and [[bip-0147.mediawiki|BIP147]] using versionbits with guaranteed lock-in. + +==Motivation== + +Miners have been reluctant to signal the BIP9 segwit deployment despite a large portion of the Bitcoin ecosystem who want the soft fork activated. This BIP specifies a user activated soft fork (UASF) that deploys segwit again using versionbits with guaranteed lock-in on timeout if the BIP is not already locked-in or activated by the timeout. This ensures users have sufficient time to prepare and no longer require a miner supermajority, while still allowing for an earlier miner activated soft fork (MASF). + +==Reference implementation== + +The reference implementation will refuse to run on Bitcoin mainnet before 7 November 2017, and can only be run on testnet and regtest until then. + +https://github.com/bitcoin/bitcoin/compare/master...shaolinfry:uasegwit-flagday + +==Specification== + +This deployment will set service bit (1<<5) as NODE_UAWITNESS. + +==Deployment== + +This BIP should only be deployed if BIP9-segwit fails to lock-in or activate before timeout on 15 November 2017. This BIP cannot be deployed before 15 November 2017. + +This BIP will be deployed by BIP8 with the name "segwit" and using bit 1. + +For Bitcoin mainnet, the BIP8 starttime will be midnight 16 November 2017 UTC (Epoch timestamp 1510790400) and BIP8 timeout will be 4 July 2018 UTC (Epoch timestamp 1530662400). + +For Bitcoin testnet, segwit is already activated so no deployment is specified. + +==Backwards Compatibility== + +This deployment reuses the GBT deployment name "segwit" to maintain compatibility with existing mining software. + +This deployment is incompatible with the BIP9-segwit deployment and should not be run concurrently with it. + +==Rationale== + +The '''starttime''' of this BIP is after the BIP9-segwit timeout to remove compatibility issues with old nodes. + +==References== + +[https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-April/014234.html Mailing list discussion] + +[[bip-0008.mediawiki|BIP8]] + +[[bip-0009.mediawiki|BIP9]] + +[[bip-0141.mediawiki|BIP141]] + +[[bip-0143.mediawiki|BIP143]] + +[[bip-0147.mediawiki|BIP147]] + +==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 e3f74f5..1fe4582 100644 --- a/bip-0150.mediawiki +++ b/bip-0150.mediawiki @@ -3,7 +3,7 @@ Layer: Peer Services Title: Peer Authentication Author: Jonas Schnelli <dev@jonasschnelli.ch> - Comments-Summary: No comments yet. + Comments-Summary: Discouraged for implementation (one person) Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0150 Status: Draft Type: Standards Track diff --git a/bip-0151.mediawiki b/bip-0151.mediawiki index 228f66d..a01a8bb 100644 --- a/bip-0151.mediawiki +++ b/bip-0151.mediawiki @@ -3,7 +3,7 @@ Layer: Peer Services Title: Peer-to-Peer Communication Encryption Author: Jonas Schnelli <dev@jonasschnelli.ch> - Comments-Summary: No comments yet. + Comments-Summary: Controversial; some recommendation, and some discouragement Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0151 Status: Draft Type: Standards Track diff --git a/bip-0152.mediawiki b/bip-0152.mediawiki index 0d2b65c..8ea3701 100644 --- a/bip-0152.mediawiki +++ b/bip-0152.mediawiki @@ -3,7 +3,7 @@ Layer: Peer Services Title: Compact Block Relay Author: Matt Corallo <bip152@bluematt.me> - Comments-Summary: No comments yet. + Comments-Summary: Unanimously Recommended for implementation Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0152 Status: Draft Type: Standards Track 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-0173.mediawiki b/bip-0173.mediawiki new file mode 100644 index 0000000..af2516d --- /dev/null +++ b/bip-0173.mediawiki @@ -0,0 +1,364 @@ +<pre> + BIP: 173 + Layer: Applications + Title: Base32 address format for native v0-16 witness outputs + Author: Pieter Wuille <pieter.wuille@gmail.com> + Greg Maxwell <greg@xiph.org> + Comments-Summary: No comments yet. + Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0173 + Status: Draft + Type: Informational + Created: 2016-03-20 + License: BSD-2-Clause + Replaces: 142 +</pre> + +==Introduction== + +===Abstract=== + +This document proposes a checksummed base32 format, "Bech32", and a standard for native segregated witness output addresses using it. + +===Copyright=== + +This BIP is licensed under the 2-clause BSD license. + +===Motivation=== + +For most of its history, Bitcoin has relied on base58 addresses with a +truncated double-SHA256 checksum. They were part of the original +software and their scope was extended in +[https://github.com/bitcoin/bips/blob/master/bip-0013.mediawiki BIP13] +for Pay-to-script-hash +([https://github.com/bitcoin/bips/blob/master/bip-0016.mediawiki P2SH]). +However, both the character set and the checksum algorithm have limitations: +* Base58 needs a lot of space in QR codes, as it cannot use the ''alphanumeric mode''. +* The mixed case in base58 makes it inconvenient to reliably write down, type on mobile keyboards, or read out loud. +* The double SHA256 checksum is slow and has no error-detection guarantees. +* Most of the research on error-detecting codes only applies to character-set sizes that are a [https://en.wikipedia.org/wiki/Prime_power prime power], which 58 is not. +* Base58 decoding is complicated and relatively slow. + +Included in the Segregated Witness proposal are a new class of outputs +(witness programs, see +[https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki BIP141]), +and two instances of it ("P2WPKH" and "P2WSH", see +[https://github.com/bitcoin/bips/blob/master/bip-0143.mediawiki BIP143]). +Their functionality is available indirectly to older clients by embedding in P2SH +outputs, but for optimal efficiency and security it is best to use it +directly. In this document we propose a new address format for native +witness outputs (current and future versions). + +This replaces +[https://github.com/bitcoin/bips/blob/master/bip-0142.mediawiki BIP142], +and was previously discussed +[https://bitcoincore.org/logs/2016-05-zurich-meeting-notes.html#base32 here] (summarized +[https://bitcoincore.org/en/meetings/2016/05/20/#error-correcting-codes-for-future-address-types here]). + +===Examples=== + +All examples use public key +<tt>0279BE667EF9DCBBAC55A06295CE870B07029BFCDB2DCE28D959F2815B16F81798</tt>. +The P2WSH examples use <tt>key OP_CHECKSIG</tt> as script. + +* Mainnet P2WPKH: <tt>bc1qw508d6qejxtdg4y5r3zarvary0c5xw7kv8f3t4</tt> +* Testnet P2WPKH: <tt>tb1qw508d6qejxtdg4y5r3zarvary0c5xw7kxpjzsx</tt> +* Mainnet P2WSH: <tt>bc1qrp33g0q5c5txsp9arysrx4k6zdkfs4nce4xj0gdcccefvpysxf3qccfmv3</tt> +* Testnet P2WSH: <tt>tb1qrp33g0q5c5txsp9arysrx4k6zdkfs4nce4xj0gdcccefvpysxf3q0sl5k7</tt> + +==Specification== + +We first describe the general checksummed base32<ref>'''Why use base32 at all?''' The lack of mixed case makes it more +efficient to read out loud or to put into QR codes. It does come with a 15% length +increase, but that does not matter when copy-pasting addresses.</ref> format called +''Bech32'' and then define Segregated Witness addresses using it. + +===Bech32=== + +A Bech32<ref>'''Why call it Bech32?''' "Bech" contains the characters BCH (the error +detection algorithm used) and sounds a bit like "base".</ref> string is at most 90 characters long and consists of: +* The '''human-readable part''', which is intended to convey the type of data or anything else that is relevant for the reader. Its validity (including the used set of characters) is application specific, but restricted to ASCII characters with values in the range 33-126. +* The '''separator''', which is always "1". In case "1" is allowed inside the human-readable part, the last one in the string is the separator<ref>'''Why include a separator in addresses?''' That way the human-readable +part is unambiguously separated from the data part, avoiding potential +collisions with other human-readable parts that share a prefix. It also +allows us to avoid having character-set restrictions on the human-readable part. The +separator is ''1'' because using a non-alphanumeric character would +complicate copy-pasting of addresses (with no double-click selection in +several applications). Therefore an alphanumeric character outside the normal character set +was chosen.</ref>. +* The '''data part''', which is at least 6 characters long and only consists of alphanumeric characters excluding "1", "b", "i", and "o"<ref>'''Why not use an existing character set like [http://www.faqs.org/rfcs/rfc3548.html RFC3548] or [https://philzimmermann.com/docs/human-oriented-base-32-encoding.txt z-base-32]'''? +The character set is chosen to minimize ambiguity according to +[https://hissa.nist.gov/~black/GTLD/ this] visual similarity data, and +the ordering is chosen to minimize the number of pairs of similar +characters (according to the same data) that differ in more than 1 bit. +As the checksum is chosen to maximize detection capabilities for low +numbers of bit errors, this choice improves its performance under some +error models.</ref>. + + +{| class="wikitable" +|- +! +!0 +!1 +!2 +!3 +!4 +!5 +!6 +!7 +|- +!+0 +|q||p||z||r||y||9||x||8 +|- +!+8 +|g||f||2||t||v||d||w||0 +|- +!+16 +|s||3||j||n||5||4||k||h +|- +!+24 +|c||e||6||m||u||a||7||l +|} + + +'''Checksum''' + +The last six characters of the data part form a checksum and contain no +information. Valid strings MUST pass the criteria for validity specified +by the Python3 code snippet below. The function +<tt>bech32_verify_checksum</tt> must return true when its arguments are: +* <tt>hrp</tt>: the human-readable part as a string +* <tt>data</tt>: the data part as a list of integers representing the characters after conversion using the table above + +<pre> +def bech32_polymod(values): + GEN = [0x3b6a57b2, 0x26508e6d, 0x1ea119fa, 0x3d4233dd, 0x2a1462b3] + chk = 1 + for v in values: + b = (chk >> 25) + chk = (chk & 0x1ffffff) << 5 ^ v + for i in range(5): + chk ^= GEN[i] if ((b >> i) & 1) else 0 + return chk + +def bech32_hrp_expand(s): + return [ord(x) >> 5 for x in s] + [0] + [ord(x) & 31 for x in s] + +def bech32_verify_checksum(hrp, data): + return bech32_polymod(bech32_hrp_expand(hrp) + data) == 1 +</pre> + +This implements a [https://en.wikipedia.org/wiki/BCH_code BCH code] that +guarantees detection of '''any error affecting at most 4 characters''' +and has less than a 1 in 10<sup>9</sup> chance of failing to detect more +errors. More details about the properties can be found in the +Checksum Design appendix. The human-readable part is processed by first +feeding the higher bits of each character's ASCII value into the +checksum calculation followed by a zero and then the lower bits of each<ref>'''Why are the high bits of the human-readable part processed first?''' +This results in the actually checksummed data being ''[high hrp] 0 [low hrp] [data]''. This means that under the assumption that errors to the +human readable part only change the low 5 bits (like changing an alphabetical character into another), errors are restricted to the ''[low hrp] [data]'' +part, which is at most 89 characters, and thus all error detection properties (see appendix) remain applicable.</ref>. + +To construct a valid checksum given the human-readable part and (non-checksum) values of the data-part characters, the code below can be used: + +<pre> +def bech32_create_checksum(hrp, data): + values = bech32_hrp_expand(hrp) + data + polymod = bech32_polymod(values + [0,0,0,0,0,0]) ^ 1 + return [(polymod >> 5 * (5 - i)) & 31 for i in range(6)] +</pre> + +'''Error correction''' + +One of the properties of these BCH codes is that they can be used for +error correction. An unfortunate side effect of error correction is that +it erodes error detection: correction changes invalid inputs into valid +inputs, but if more than a few errors were made then the valid input may +not be the correct input. Use of an incorrect but valid input can cause +funds to be lost irrecoverably. Because of this, implementations SHOULD +NOT implement correction beyond potentially suggesting to the user where +in the string an error might be found, without suggesting the correction +to make. + +'''Uppercase/lowercase''' + +Decoders MUST accept both uppercase and lowercase strings, but +not mixed case. The lowercase form is used when determining a character's +value for checksum purposes. For presentation, lowercase is usually +preferable, but inside QR codes uppercase SHOULD be used, as those permit +the use of +''[http://www.thonky.com/qr-code-tutorial/alphanumeric-mode-encoding alphanumeric mode]'', which is 45% more compact than the normal +''[http://www.thonky.com/qr-code-tutorial/byte-mode-encoding byte mode]''. + +===Segwit address format=== + +A segwit address<ref>'''Why not make an address format that is generic for all scriptPubKeys?''' +That would lead to confusion about addresses for +existing scriptPubKey types. Furthermore, if addresses that do not have a one-to-one mapping with scriptPubKeys (such as ECDH-based +addresses) are ever introduced, having a fully generic old address type available would +permit reinterpreting the resulting scriptPubKeys using the old address +format, with lost funds as a result if bitcoins are sent to them.</ref> is a Bech32 encoding of: + +* The human-readable part "bc"<ref>'''Why use 'bc' as human-readable part and not 'btc'?''' 'bc' is shorter.</ref> for mainnet, and "tb"<ref>'''Why use 'tb' as human-readable part for testnet?''' It was chosen to +be of the same length as the mainnet counterpart (to simplify +implementations' assumptions about lengths), but still be visually +distinct.</ref> for testnet. +* The data-part values: +** 1 value: the witness version +** A conversion of the the 2-to-40-byte witness program (as defined by [https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki BIP141]) to base32: +*** Start with the bits of the witness program, most significant bit per byte first. +*** Re-arrange those bits into groups of 5, and pad with zeroes at the end if needed. +*** Translate those bits to characters using the table above. + +'''Decoding''' + +Software interpreting a segwit address: +* MUST verify that the human-readable part is "bc" for mainnet and "tb" for testnet. +* MUST verify that the first decoded data value (the witness version) is between 0 and 16, inclusive. +* Convert the rest of the data to bytes: +** Translate the values to 5 bits, most significant bit first. +** Re-arrange those bits into groups of 8 bits. Any incomplete group at the end MUST be 4 bits or less, MUST be all zeroes, and is discarded. +** There MUST be between 2 and 40 groups, which are interpreted as the bytes of the witness program. + +Decoders SHOULD enforce known-length restrictions on witness programs. +For example, BIP141 specifies ''If the version byte is 0, but the witness +program is neither 20 nor 32 bytes, the script must fail.'' + +As a result of the previous rules, addresses are always between 14 and 74 characters long, and their length modulo 8 cannot be 0, 3, or 5. +Version 0 witness addresses are always 42 or 62 characters, but implementations MUST allow the use of any version. + +===Compatibility=== + +Only new software will be able to use these addresses, and only for +receivers with segwit-enabled new software. In all other cases, P2SH or +P2PKH addresses can be used. + +==Rationale== + +<references /> + +==Reference implementations== + +* Reference encoder and decoder: +** [https://github.com/sipa/bech32/tree/master/ref/c For C] +** [https://github.com/sipa/bech32/tree/master/ref/javascript For JavaScript] +** [https://github.com/sipa/bech32/tree/master/ref/python For Python] +** [https://github.com/sipa/bech32/tree/master/ref/haskell For Haskell] +** [https://github.com/sipa/bech32/tree/master/ref/rust For Rust] + +* Fancy decoder that localizes errors: +** [https://github.com/sipa/bech32/tree/master/ecc/javascript For JavaScript] ([http://bitcoin.sipa.be/bech32/demo/demo.html demo website]) + +==Appendices== + +===Test vectors=== + +The following strings have a valid Bech32 checksum. +* <tt>A12UEL5L</tt> +* <tt>an83characterlonghumanreadablepartthatcontainsthenumber1andtheexcludedcharactersbio1tt5tgs</tt> +* <tt>abcdef1qpzry9x8gf2tvdw0s3jn54khce6mua7lmqqqxw</tt> +* <tt>11qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqc8247j</tt> +* <tt>split1checkupstagehandshakeupstreamerranterredcaperred2y9e3w</tt> + +The following list gives valid segwit addresses and the scriptPubKey that they +translate to in hex. +* <tt>BC1QW508D6QEJXTDG4Y5R3ZARVARY0C5XW7KV8F3T4</tt>: <tt>0014751e76e8199196d454941c45d1b3a323f1433bd6</tt> +* <tt>tb1qrp33g0q5c5txsp9arysrx4k6zdkfs4nce4xj0gdcccefvpysxf3q0sl5k7</tt>: <tt>00201863143c14c5166804bd19203356da136c985678cd4d27a1b8c6329604903262</tt> +* <tt>bc1pw508d6qejxtdg4y5r3zarvary0c5xw7kw508d6qejxtdg4y5r3zarvary0c5xw7k7grplx</tt>: <tt>8128751e76e8199196d454941c45d1b3a323f1433bd6751e76e8199196d454941c45d1b3a323f1433bd6</tt> +* <tt>BC1SW50QA3JX3S</tt>: <tt>9002751e</tt> +* <tt>bc1zw508d6qejxtdg4y5r3zarvaryvg6kdaj</tt>: <tt>8210751e76e8199196d454941c45d1b3a323</tt> +* <tt>tb1qqqqqp399et2xygdj5xreqhjjvcmzhxw4aywxecjdzew6hylgvsesrxh6hy</tt>: <tt>0020000000c4a5cad46221b2a187905e5266362b99d5e91c6ce24d165dab93e86433</tt> + +The following list gives invalid segwit addresses and the reason for +their invalidity. +* <tt>tc1qw508d6qejxtdg4y5r3zarvary0c5xw7kg3g4ty</tt>: Invalid human-readable part +* <tt>bc1qw508d6qejxtdg4y5r3zarvary0c5xw7kv8f3t5</tt>: Invalid checksum +* <tt>BC13W508D6QEJXTDG4Y5R3ZARVARY0C5XW7KN40WF2</tt>: Invalid witness version +* <tt>bc1rw5uspcuh</tt>: Invalid program length +* <tt>bc10w508d6qejxtdg4y5r3zarvary0c5xw7kw508d6qejxtdg4y5r3zarvary0c5xw7kw5rljs90</tt>: Invalid program length +* <tt>BC1QR508D6QEJXTDG4Y5R3ZARVARYV98GJ9P</tt>: Invalid program length for witness version 0 (per BIP141) +* <tt>tb1qrp33g0q5c5txsp9arysrx4k6zdkfs4nce4xj0gdcccefvpysxf3q0sL5k7</tt>: Mixed case +* <tt>tb1pw508d6qejxtdg4y5r3zarqfsj6c3</tt>: zero padding of more than 4 bits +* <tt>tb1qrp33g0q5c5txsp9arysrx4k6zdkfs4nce4xj0gdcccefvpysxf3pjxtptv</tt>: Non-zero padding in 8-to-5 conversion + +===Checksum design=== + +'''Design choices''' + +BCH codes can be constructed over any prime-power alphabet and can be chosen to have a good trade-off between +size and error-detection capabilities. While most work around BCH codes uses a binary alphabet, that is not a requirement. +This makes them more appropriate for our use case than [https://en.wikipedia.org/wiki/Cyclic_redundancy_check CRC codes]. Unlike +[https://en.wikipedia.org/wiki/Reed%E2%80%93Solomon_error_correction Reed-Solomon codes], +they are not restricted in length to one less than the alphabet size. While they also support efficient error correction, +the implementation of just error detection is very simple. + +We pick 6 checksum characters as a trade-off between length of the addresses and the error-detection capabilities, as 6 +characters is the lowest number sufficient for a random failure chance below 1 per billion. For the length of data +we're interested in protecting (up to 71 bytes for a potential future 40-byte witness +program), BCH codes can be constructed that guarantee detecting up to 4 errors. + +'''Selected properties''' + +Many of these codes perform badly when dealing with more errors than they are designed to detect, but not all. +For that reason, we consider codes that are designed to detect only 3 errors as well as 4 errors, +and analyse how well they perform in practice. + +The specific code chosen here is the result +of: +* Starting with an exhaustive list of 159605 BCH codes designed to detect 3 or 4 errors up to length 93, 151, 165, 341, 1023, and 1057. +* From those, requiring the detection of 4 errors up to length 71, resulting in 28825 remaining codes. +* From those, choosing the codes with the best worst-case window for 5-character errors, resulting in 310 remaining codes. +* From those, picking the code with the lowest chance for not detecting small numbers of ''bit'' errors. + +As a naive search would require over 6.5 * 10<sup>19</sup> checksum evaluations, a collision-search approach was used for +analysis. The code can be found [https://github.com/sipa/ezbase32/ here]. + +'''Properties''' + +The following table summarizes the chances for detection failure (as +multiples of 1 in 10<sup>9</sup>). + +{| class="wikitable" +|- +!colspan="2" | Window length +!colspan="6" | Number of wrong characters +|- +!Length +!Description +!≤4 +!5 +!6 +!7 +!8 +!≥9 +|- +| 8 || Longest detecting 6 errors || colspan="3" | 0 || 1.127 || 0.909 || n/a +|- +| 18 || Longest detecting 5 errors || colspan="2" | 0 || 0.965 || 0.929 || 0.932 || 0.931 +|- +| 19 || Worst case for 6 errors || 0 || 0.093 || 0.972 || 0.928 || colspan="2" | 0.931 +|- +| 39 || Length for a P2WPKH address || 0 || 0.756 || 0.935 || 0.932 || colspan="2" | 0.931 +|- +| 59 || Length for a P2WSH address || 0 || 0.805 || 0.933 || colspan="3" | 0.931 +|- +| 71 || Length for a 40-byte program address || 0 || 0.830 || 0.934 || colspan="3" | 0.931 +|- +| 89 || Longest detecting 4 errors || 0 || 0.867 || 0.933 || colspan="3" | 0.931 +|} +This means that when 5 changed characters occur randomly distributed in +the 39 characters of a P2WPKH address, there is a chance of +''0.756 per billion'' that it will go undetected. When those 5 changes +occur randomly within a 19-character window, that chance goes down to +''0.093 per billion''. As the number of errors goes up, the chance +converges towards ''1 in 2<sup>30</sup>'' = ''0.931 per billion''. + +Even though the chosen code performs reasonably well up to 1023 characters, +other designs are preferable for lengths above 89 characters (excluding the +separator). + +==Acknowledgements== + +This document is inspired by the [https://rusty.ozlabs.org/?p=578 address proposal] by Rusty Russell, the +[https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2014-February/004402.html base32] proposal by Mark Friedenbach, and had input from Luke Dashjr, +Johnson Lau, Eric Lombrozo, Peter Todd, and various other reviewers. 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 5589abb..415d133 100755 --- a/scripts/buildtable.pl +++ b/scripts/buildtable.pl @@ -9,7 +9,6 @@ my %RequiredFields = ( BIP => undef, Title => undef, Author => undef, - 'Comments-Summary' => undef, 'Comments-URI' => undef, Status => undef, Type => undef, @@ -154,7 +153,8 @@ while (++$bipnum <= $topbip) { } } 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); + my $first_comments_uri = sprintf('https://github.com/bitcoin/bips/wiki/Comments:BIP-%04d', $bipnum); + die "First Comments-URI must be exactly \"$first_comments_uri\" in $fn" unless $val eq $first_comments_uri; } } elsif (exists $DateField{$field}) { die "Invalid date format in $fn" unless $val =~ /^20\d{2}\-(?:0\d|1[012])\-(?:[012]\d|30|31)$/; |
