summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
Diffstat
-rw-r--r--README.mediawiki37
-rw-r--r--bip-0039/bip-0039-wordlists.md18
-rw-r--r--bip-0091.mediawiki90
-rw-r--r--bip-0115.mediawiki117
-rw-r--r--bip-0135.mediawiki411
-rw-r--r--bip-0135/bip-0135-states-small.pngbin0 -> 36260 bytes
-rw-r--r--bip-0135/bip-0135-states.pngbin0 -> 158832 bytes
-rw-r--r--bip-0135/bip-0135-states.svg598
-rw-r--r--bip-0149.mediawiki69
-rw-r--r--bip-0171.mediawiki11
-rw-r--r--bip-0173.mediawiki364
-rwxr-xr-xscripts/buildtable.pl7
12 files changed, 1709 insertions, 13 deletions
diff --git a/README.mediawiki b/README.mediawiki
index d66d7d7..ca0138e 100644
--- a/README.mediawiki
+++ b/README.mediawiki
@@ -2,7 +2,7 @@ People wishing to submit BIPs, first should propose their idea or document to th
We are fairly liberal with approving BIPs, and try not to be too involved in decision making on behalf of the community. The exception is in very rare cases of dispute resolution when a decision is contentious and cannot be agreed upon. In those cases, the conservative option will always be preferred.
-Having a BIP here does not make it a formally accepted standard until its status becomes Active. For a BIP to become Active requires the mutual consent of the community.
+Having a BIP here does not make it a formally accepted standard until its status becomes Final or Active.
Those proposing changes should consider that ultimately consent may rest with the consensus of the Bitcoin users (see also: [https://en.bitcoin.it/wiki/Economic_majority economic majority]).
@@ -414,6 +414,13 @@ Those proposing changes should consider that ultimately consent may rest with th
| Informational
| Draft
|-
+| [[bip-0091.mediawiki|91]]
+| Consensus (soft fork)
+| Reduced threshold Segwit MASF
+| James Hilliard
+| Standard
+| Draft
+|-
| [[bip-0099.mediawiki|99]]
|
| Motivation and deployment of consensus rule changes ([soft/hard]forks)
@@ -505,6 +512,13 @@ Those proposing changes should consider that ultimately consent may rest with th
| Standard
| Draft
|-
+| [[bip-0115.mediawiki|115]]
+| Consensus (soft fork)
+| Generic anti-replay protection using Script
+| Luke Dashjr
+| Standard
+| Draft
+|-
| [[bip-0120.mediawiki|120]]
| Applications
| Proof of Payment
@@ -589,6 +603,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
@@ -652,6 +673,13 @@ Those proposing changes should consider that ultimately consent may rest with th
| 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
@@ -687,6 +715,13 @@ Those proposing changes should consider that ultimately consent may rest with th
| 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
diff --git a/bip-0039/bip-0039-wordlists.md b/bip-0039/bip-0039-wordlists.md
index b2957cc..045ad36 100644
--- a/bip-0039/bip-0039-wordlists.md
+++ b/bip-0039/bip-0039-wordlists.md
@@ -12,15 +12,15 @@
### 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
@@ -41,9 +41,9 @@ uniformity, we propose to use normal ASCII spaces (0x20) to separate words as pe
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-0091.mediawiki b/bip-0091.mediawiki
new file mode 100644
index 0000000..bf71882
--- /dev/null
+++ b/bip-0091.mediawiki
@@ -0,0 +1,90 @@
+<pre>
+ BIP: 91
+ Layer: Consensus (soft fork)
+ Title: Reduced threshold Segwit MASF
+ Author: James Hilliard <james.hilliard1@gmail.com>
+ Comments-Summary: No comments yet.
+ Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0091
+ Status: Draft
+ Type: Standards Track
+ Created: 2017-05-22
+ License: BSD-3-Clause
+ CC0-1.0
+</pre>
+
+==Abstract==
+
+This document specifies a method to activate the existing BIP9 segwit deployment with a majority hashpower less than 95%.
+
+==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].
+
+This BIP provides a way for a simple majority of miners to coordinate activation of the existing segwit deployment with less than 95% hashpower. For a number of reasons a complete redeployment of segwit is difficult to do until the existing deployment expires. This is due to 0.13.1+ having many segwit related features active already, including all the P2P components, the new network service flag, the witness-tx and block messages, compact blocks v2 and preferential peering. A redeployment of segwit will need to redefine all these things and doing so before expiry would greatly complicate testing.
+
+==Specification==
+
+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.
+
+==Deployment==
+
+This BIP will be deployed by a "version bits" with an 80%(this can be adjusted if desired) activation threshold BIP9 with the name "segsignal" and using bit 4.
+
+This BIP will have a start time of midnight June 1st, 2017 (epoch time 1496275200) and timeout on midnight November 15th 2017 (epoch time 1510704000). This BIP will cease to be active when segwit is locked-in.
+
+=== 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);
+}
+
+// SEGSIGNAL mandatory segwit signalling.
+if ( VersionBitsState(pindex->pprev, chainparams.GetConsensus(), Consensus::DEPLOYMENT_SEGSIGNAL, versionbitscache) == THRESHOLD_ACTIVE &&
+ !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/0.14...jameshilliard:segsignal-v0.14.1
+
+==Backwards Compatibility==
+
+This deployment is compatible with the existing "segwit" bit 1 deployment scheduled between midnight November 15th, 2016 and midnight November 15th, 2017. Miners will need to upgrade their nodes to support segsignal otherwise they may build on top of an invalid block. While this bip is active users should either upgrade to segsignal or wait for additional confirmations when accepting payments.
+
+==Rationale==
+
+Historically we have used IsSuperMajority() to activate soft forks such as BIP66 which has a mandatory signalling requirement for miners once activated, this ensures that miners are aware of new rules being enforced. This technique can be leveraged to lower the signalling threshold of a soft fork while it is in the process of being deployed in a backwards compatible way.
+
+By orphaning non-signalling blocks during 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]]
+*[[bip-0148.mediawiki|BIP148 Mandatory activation of segwit deployment]]
+*[[bip-0149.mediawiki|BIP149 Segregated Witness (second deployment)]]
+*[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-0115.mediawiki b/bip-0115.mediawiki
new file mode 100644
index 0000000..52366ab
--- /dev/null
+++ b/bip-0115.mediawiki
@@ -0,0 +1,117 @@
+<pre>
+ BIP: 115
+ Layer: Consensus (soft fork)
+ Title: Generic anti-replay protection using Script
+ Author: Luke Dashjr <luke+bip@dashjr.org>
+ Comments-Summary: No comments yet.
+ Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0115
+ Status: Draft
+ Type: Standards Track
+ Created: 2016-09-23
+ License: BSD-2-Clause
+</pre>
+
+==Abstract==
+
+This BIP describes a new opcode (<code>OP_CHECKBLOCKATHEIGHT</code>) for the Bitcoin scripting system that allows construction of transactions which are valid only on specific blockchains.
+
+==Copyright==
+
+This BIP is licensed under the BSD 2-clause license.
+
+==Specification==
+
+<code>OP_CHECKBLOCKATHEIGHT</code> redefines the existing <code>OP_NOP5</code> opcode.
+
+When this opcode is executed:
+
+* If the stack has fewer than 2 elements, the script fails.
+* If the top item on the stack cannot be interpreted as a minimal-length 32-bit CScriptNum, the script fails.
+* The top item on the stack is interpreted as a block height (ParamHeight).
+* If the blockchain (in the context of the execution) does not have ParamHeight blocks prior to the one including this transaction, the script fails (this failure must not be cached across blocks; it is equivalent to non-final status).
+* If ParamHeight specifies a block deeper than 52596 blocks in the chain (including negative values), the opcode completes successfully and script continues as normal.
+* The second-to-top item on the stack is interpreted as a block hash (ParamBlockHash).
+* If ParamBlockHash is longer than 28 bytes, the script fails.
+* If ParamBlockHash does not match the equivalent ending bytes of the block hash specified by ParamHeight, the script fails.
+
+Otherwise, script execution will continue as if a NOP had been executed.
+
+===Deployment===
+
+This BIP will be deployed by "version bits" [[bip-0009.mediawiki|BIP9]] with the '''name''' "cbah" and using '''bit''' TBD.
+
+For Bitcoin '''mainnet''', the BIP9 '''starttime''' will be TBD (Epoch timestamp TBD) and BIP9 '''timeout''' will be TBD (Epoch timestamp TBD).
+
+For Bitcoin '''mainnet''', the BIP9 '''starttime''' will be TBD (Epoch timestamp TBD) and BIP9 '''timeout''' will be TBD (Epoch timestamp TBD).
+
+==Motivation==
+
+===Securely recovering from double spends===
+
+In some circumstances, users may wish to spend received bitcoins before they have confirmed on the blockchain (Tx B1).
+However, if the transaction sending them those bitcoins (Tx A1) is double-spent, the wallet must re-issue their own transaction spending them (Tx B2).
+So long as the double-spend of the incoming transaction (Tx A2) also pays the wallet, this can be managed by simply updating the outgoing transaction with the new outpoint and resigning.
+However, if the double-spend does not pay the wallet, the situation is presently irrecoverable:
+it must spend different, non-conflicting TXOs in Tx B2, which allows an attacker to then reorganise the chain (reversing the incoming transaction's double-spend) and confirm both of his transactions Tx B1 and Tx B2.
+
+By adding <code>OP_CHECKBLOCKATHEIGHT</code>, the wallet can issue Tx B2 with a condition that the block confirming Tx A2 is in the history, thus eliminating this risk.
+
+===Replay protection in the event of a persistent blockchain split===
+
+In the event of a persistent blockchain split, some mechanism is desired by which the UTXOs valid in either chain may be spent without the transaction being validly replayable on the other chain.
+
+This can be guaranteed by choosing a block which exists only on either side of the split, and pinning (using <code>OP_CHECKBLOCKATHEIGHT</code>) common UTXOs to be spent only on chains based on that block.
+
+==Best practices for wallets==
+
+To avoid unnecessary conflicts when a chain is reorganized, wallets should always avoid specifying the last 100 blocks when practical.
+Wallets that use recent blocks when unavoidable SHOULD actively monitor the network and re-create transactions that are reorganised out with updated block hashes.
+Unless it conflicts with local/user security policies, wallets SHOULD retain the private key in memory to re-sign such transactions until the pinned block is at least 100 blocks deep into the chain.
+
+For ordinary usage, wallets SHOULD specify the ParamBlockHash as 16 bytes.
+
+==Rationale==
+
+How is this different from the transaction's lock-time?
+
+* The lock-time specifies a time or block height before a transaction becomes valid. <code>OP_CHECKBLOCKATHEIGHT</code>, on the other hand, specifies a specific block's hash.
+
+Why are block heights required to be absolute, rather than relative?
+
+* A relative block height would allow for creation of transactions which are valid at block N, but not N+1. This is carefully avoided by Bitcoin to ensure that if any given block is reorganised out, non-malicious transactions can be simply re-confirmed in a later block.
+
+Why are blocks older than 52596 deep in the chain not verified?
+
+* This is to avoid creating an infinite storage requirement from all full nodes which would be necessary to maintain all the block headers indefinitely. 52596 block headers requires a fixed size of approximately 4 MB.
+* In any case where you might want to specify a deeper block, you can also just as well specify a more recent one that decends from it.
+* It is assumed that 1 year is sufficient time to double-spend any common UTXOs on all blockchains of interest.
+* If a deeper check is needed, it can be softforked in. Making the check more shallow, on the other hand, is a hardfork.
+
+Why is ParamBlockHash allowed to match less than the full block hash?
+
+* In a chain split, it is sufficient to check only a few bytes to avoid replay.
+* In all scenarios, it is likely sufficient to check only a minority of the full hash to avoid any realistic chance of replay.
+* Allowing less than the full hash to be specified saves space in transaction data.
+* Using a single byte can be combined with other opcodes (such as <code>OP_LESSTHAN</code>) to enable on-chain gambling logic.
+
+What if ParamBlockHash has leading zeros? Should this be prevented?
+
+* If leading zeros are included, they should be compared to the actual block hash. (If they were truncated, fewer bytes would be compared.)
+* It is unlikely that the leading zeros will ever be necessary for sufficient precision, so the additional space is not a concern.
+* Since all block hashes are in principle shorter than than 29 bytes, ParamBlockHash may not be larger than 28 bytes.
+
+Why is it safe to allow checking blocks as recently as the immediate previous block?
+
+* This should only be used when necessary (ie, the deeper block is not sufficient), and when the wallet can actively issue updates should the blockchain reorganise.
+* While this allows intentionally creating a transaction which may be invalid in a reorganization, the same can already be accomplished by creating double spends.
+
+==Backwards Compatibility==
+
+<code>OP_NOP5</code> ought to be forbidden by policy by all miners for future extensions such as this, so old miners will under no circumstances produce blocks which would now be considered invalid under the new rules.
+However, miners must still upgrade to avoid accepting and building on top of such a possible invalid block as part of an attack.
+
+Old nodes will likely also not relay transactions using this opcode for the same extensibility reasons, but this is not important since the rule cannot be verified deterministically outside the context of a block.
+
+==Reference Implementation==
+
+https://github.com/bitcoin/bitcoin/compare/master...luke-jr:cbah
diff --git a/bip-0135.mediawiki b/bip-0135.mediawiki
new file mode 100644
index 0000000..89d3077
--- /dev/null
+++ b/bip-0135.mediawiki
@@ -0,0 +1,411 @@
+<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 these Pull Requests:
+
+* https://github.com/BitcoinUnlimited/BitcoinUnlimited/pull/458
+
+* https://github.com/bitcoin/bitcoin/pull/10437
+
+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
new file mode 100644
index 0000000..9191ae3
--- /dev/null
+++ b/bip-0135/bip-0135-states-small.png
Binary files differ
diff --git a/bip-0135/bip-0135-states.png b/bip-0135/bip-0135-states.png
new file mode 100644
index 0000000..ace0617
--- /dev/null
+++ b/bip-0135/bip-0135-states.png
Binary files differ
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 &lt;= MTP &lt; 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 &gt;= 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 &gt;= 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 &lt; 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 &gt;= 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 &gt;= 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-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-0171.mediawiki b/bip-0171.mediawiki
index 237d233..11eb109 100644
--- a/bip-0171.mediawiki
+++ b/bip-0171.mediawiki
@@ -26,7 +26,7 @@ All matching parameters may be specified with multiple comma-separated values, w
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.
+It is recommended to use TLS (HTTPS) and/or Linked Data Signatures, 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.
@@ -59,6 +59,7 @@ Each currency-pair will receive a separate result, a JSON Object, with the follo
* ''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.
+* ''signature'' - Optional. May be used for Linked Data Signatures.
Example:
@@ -92,6 +93,7 @@ Each currency-pair will receive a separate result, a JSON Object, with the follo
* ''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.
+* ''signature'' - Optional. May be used for Linked Data Signatures.
Example:
@@ -108,12 +110,15 @@ Parameters:
* ''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.
+* ''nonce'' - If specified, the server SHOULD return it in each result.
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.
+* ''nonce'' - Only if the request specified a nonce, the server SHOULD include it here as a JSON String.
+* ''signature'' - Optional. May be used for Linked Data Signatures.
Example:
@@ -189,3 +194,7 @@ While this new standard is adopted, software and providers can continue to use a
==Reference implementation==
TODO
+
+==See also==
+
+* [https://w3c-dvcg.github.io/ld-signatures/ Draft W3c Linked Data Signatures specification]
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/scripts/buildtable.pl b/scripts/buildtable.pl
index 5589abb..36701a5 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,
@@ -87,6 +86,7 @@ my %DefinedLicenses = (
);
my %GrandfatheredPD = map { $_ => undef } qw(9 36 37 38 42 49 50 60 65 67 69 74 80 81 83 90 99 105 107 109 111 112 113 114 122 124 125 126 130 131 132 133 140 141 142 143 144 146 147 150 151 152);
my %TolerateMissingLicense = map { $_ => undef } qw(1 10 11 12 13 14 15 16 21 31 33 34 35 39 43 44 45 47 61 64 68 70 71 72 73 101 102 106 120 121);
+my %TolerateTitleTooLong = map { $_ => undef } qw(39 44 45 47 49 60 67 68 69 73 74 75 80 81 99 105 106 109 113 122 126 131 143 145 147 173);
my %emails;
@@ -121,6 +121,8 @@ while (++$bipnum <= $topbip) {
die "$fn claims to be BIP $val" if $val ne $bipnum;
} elsif ($field eq 'Title') {
$title = $val;
+ my $title_len = length($title);
+ die "$fn has too-long TItle ($title_len > 44 char max)" if $title_len > 44 and not exists $TolerateTitleTooLong{$bipnum};
} elsif ($field eq 'Author') {
$val =~ m/^(\S[^<@>]*\S) \<([^@>]*\@[\w.]+\.\w+)\>$/ or die "Malformed Author line in $fn";
my ($authorname, $authoremail) = ($1, $2);
@@ -154,7 +156,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)$/;
generated by cgit v1.2.3 (git 2.26.2) at 2024-10-06 04:04:53 +0000