From 6d97bf5c98e636dfb902f9accc88a62ac348897e Mon Sep 17 00:00:00 2001 From: Dr Washington Sanchez Date: Sun, 13 Sep 2015 22:00:11 +1000 Subject: [PATCH 001/259] Dynamic block size proposal Will update with BIP number if/when assigned one. --- dynamicblocksize.mediawiki | 83 ++++++++++++++++++++++++++++++++++++++ 1 file changed, 83 insertions(+) create mode 100644 dynamicblocksize.mediawiki diff --git a/dynamicblocksize.mediawiki b/dynamicblocksize.mediawiki new file mode 100644 index 00000000..7431a1c1 --- /dev/null +++ b/dynamicblocksize.mediawiki @@ -0,0 +1,83 @@ +
+  BIP: XXX
+  Title: Dynamic limit on the block size
+  Author: Dr Washington Y. Sanchez 
+  Status: Draft
+  Type: Standards Track
+  Created: 2015-09-11
+
+ +==Abstract== + +This BIP proposes a dynamic limit to the block size based on transaction volume. + +==Motivation== + +Over the next few years, large infrastructure investments will be made into: + +# Improving global network connectivity +# Improving block propogation across the Bitcoin network +# Layer 2 services and networks for off-chain transactions +# General efficiency improvements to transactions and the blockchain + +* While there is a consensus between Bitcoin developers, miners, businesses and users that the block size needs to be increased, there is a lingering concern over the potential unintended consequences that may agument the trend towards network and mining centralization (largely driven by mining hardware such as ASICs) and thereby threaten the security of the network. +* In contrast, failing to respond to elevated on-chain transaction volume may lead to a consumer-failure of Bitcoin, where ordinary users - having enjoyed over 6 years of submitting transactions on-chain at relatively low cost - will be priced out of blockchain with the emergence of a prohibitive 'fee market'. +* These two concerns must be delicately balanced so that all users can benefit from a robust, scalable, and neutral network. + +==Specification== + +* Increases in the block size will occur in 2 phases +* '''Phase 1''' +** The block size will be increased similar to [[https://twitter.com/adam3us/status/636410827969421312|Adam Back's proposal]], as a safe runway prior to switching to Phase 2, while network and protocol infrastructure is improved +** The schedule: +*** ''2016-2017:'' 2 MB +*** ''2018-2019:'' 4 MB +*** ''2020:'' 6 MB +* '''Phase 2''' +** In 2020, the maximum block size will be increased dynamically according to sustained increases in transaction volume +** Every 4032 blocks (~4 weeks), a CHECK will be performed to determine if a raise in the maximum block size should occur +*** This calculates to a theoretical maximum of 13 increases per year +** IF of the last >= 3025 blocks were >=60% full, the maximum block size will be increased by 10% +** The maximum block size can only ever be increased, not decreased +* The default limitfreerelay will also be raised in proportion to maximum block size increases +** Transactions without fees can continue to be submitted and relayed on the network as per normal +** limitfreerelay also helps counter attempts to trigger a block size increase by 'penny-flooding' + +For example: +* When the dynamic rules for increasing the block size go live on January 1st 2020, the starting maximum block size wil be 6 MB +* IF >=3025 blocks are >= 3.6 MB, the new maximum block size become 6.6 MB. +* The theoretical maximum block size at the end of 2020 would be ~20.7 MB, assuming all 13 increases are triggered every 4 weeks by the end of the year. + +==Rationale== + +* '''Phase 1''' +** This runway has a schedule for conservative increases to the block size in order to relieve transaction volume pressure while allowing network and protocol infrastructure improvements to be made, as well as layer 2 services to emerge +* '''Phase 2''' +** Why 60% full blocks? +*** IF blocks are 60% full, they count as a ''vote'' towards increasing the block size +*** If this parameter is too low, the trigger sensitivity may be too high and vulnerable to spam attacks or miner collusion +*** Setting the parameter too high may set the trigger sensitivity too low, causing transaction delays that are trying to be avoided in the first place +*** Between September 2013-2015, the standard deviation measured from average block size (n=730 data points from blockchain.info) was ~ 0.13 MB or 13% of the maximum block size +**** If blocks needed to be 90% full before an increase were triggered, normal variance in the average block size would mean some blocks would be full before an increase could be triggered +*** Therefore, we need a ''safe distance'' away from the maximum block size to avoid normal block size variance hitting the limit. The 60% level represents a 3 standard deviation distrance from the limit. +** Why 3025 blocks? +*** The assessment period is 4032 blocks or ~ 4 weeks, with the threshold set as 4032 blocks/0.75 + 1 +*** Increases in the maximum block size should only occur after a sustained trend can be observed in order to: +***# Demonstrate a market-driven secular elevation in the transaction volume +***# Increase the cost to trigger an increase by spam attacks or miner collusion with zero fee transactions +*** In other words, increases to the maximum block size must be conservative but meaningful to relieve transaction volume pressure in response to true market demand +** Why 10% increase in the block size? +*** Increases in the block size are designed to be conservative and in balance with the number of theoretical opportunitites to increase the block size per year +*** Makes any resources spent for spam attacks or miner collusion relatively expensive to achieve a minor increase in the block size. A sustained attack would need to be launched that may be too costly, and ideally detectable by the community + +==Deployment== +''From BIP66:'' +We reuse the double-threshold switchover mechanism from BIP 34, with the same thresholds, but for nVersion = ''n''. The new rules are in effect for every block (at height H) with nVersion = ''n'' and at least 750 out of 1000 blocks preceding it (with heights H-1000..H-1) also have nVersion = ''n''. Furthermore, when 950 out of the 1000 blocks preceding a block do have nVersion = ''n'', nVersion = ''n-1'' blocks become invalid, and all further blocks enforce the new rules. + +==Acknowledgements== + +Thanks to Austin Hill, Brian Hoffman, Angel Leon, Bulukani Mlalazi, Chris Pacia, and Ryan Shea for their comments. + +==Copyright== + +This work is placed in the public domain. From 38ea34dee5a1f029d3346176f1eed6a2b1adff16 Mon Sep 17 00:00:00 2001 From: Eric Lombrozo Date: Fri, 9 Oct 2015 15:59:07 -0400 Subject: [PATCH 002/259] Updated C++ library link and added acknowledgement. --- bip-0032.mediawiki | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/bip-0032.mediawiki b/bip-0032.mediawiki index 902a5eb2..b5ab1452 100644 --- a/bip-0032.mediawiki +++ b/bip-0032.mediawiki @@ -259,7 +259,7 @@ PyCoin (https://github.com/richardkiss/pycoin) is a suite of utilities for deali A Java implementation is available at https://github.com/bitsofproof/supernode/blob/1.1/api/src/main/java/com/bitsofproof/supernode/api/ExtendedKey.java -A C++ implementation is available at https://github.com/CodeShark/CoinClasses/tree/master/tests/hdwallets +A C++ implementation is available at https://github.com/ciphrex/mSIGNA/blob/master/deps/CoinCore/src/hdkeys.h An Objective-C implementation is available at https://github.com/oleganza/CoreBitcoin/blob/master/CoreBitcoin/BTCKeychain.h @@ -281,4 +281,5 @@ A Haskell implementation is available at https://github.com/haskoin/haskoin toge * Gregory Maxwell for the original idea of type-2 deterministic wallets, and many discussions about it. * Alan Reiner for the implementation of this scheme in Armory, and the suggestions that followed from that. +* Eric Lombrozo for reviewing and revising this BIP. * Mike Caldwell for the version bytes to obtain human-recognizable Base58 strings. From 46d25f86298fc70b4e00f06b3068f2c81231eb61 Mon Sep 17 00:00:00 2001 From: Christian Decker Date: Wed, 13 May 2015 11:16:55 +0200 Subject: [PATCH 003/259] Draft of the normalized transaction ID BIP --- bip-00nn.mediawiki | 120 +++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 120 insertions(+) create mode 100644 bip-00nn.mediawiki diff --git a/bip-00nn.mediawiki b/bip-00nn.mediawiki new file mode 100644 index 00000000..923b9e72 --- /dev/null +++ b/bip-00nn.mediawiki @@ -0,0 +1,120 @@ +
+  BIP: NN
+  Title: Normalized TXID
+  Author: Christian Decker 
+  Status: Draft
+  Type: Standards Track
+  Created: 2015-10-14
+
+== Abstract == + +This BIP describes the use of normalized transaction IDs (TXIDs) in order to eliminate transaction malleability, both in the third-party modification scenario as well as the participant modification scenario. The transaction ID is normalized by removing the signature scripts from transactions before computing its hash. The normalized transaction hashes are then used during the signature creation and signature verification of dependent transactions. + +== Motivation == + +Transaction malleability refers to the fact that transactions can be modified, either by one of the signers by re-signing the transaction or a third-party by modifying the signature representation. This is a problem since any modification to the serialized representation also changes the hash of the transaction, which is used by spending transaction to reference the funds that are being transferred. If a transaction is modified and later confirmed by ending up in the blockchain all transactions that depended on the original transaction are no longer valid, and thus orphaned. + +BIPs 62[[https://github.com/bitcoin/bips/blob/master/bip-0062.mediawiki|BIP 62 - Dealing with malleability]] and 66[[https://github.com/bitcoin/bips/blob/master/bip-0066.mediawiki|BIP 66 - Strict DER signatures]] alleviate the problem of third-party modification by defining a canonical representation of the signatures. However, the checking the canonical representation is complex and may not eliminate all sources of third-party malleability. Furthermore, these BIPs do not address modifications by one of the signers, i.e., re-signing the transaction, because signers can produce any number of signatures due to the random parameter in ECDSA. + +This proposal eliminates malleability altogether by removing the malleable signatures from the hash used to reference the outputs spent by a transaction. The new hash used to reference an output is called the ''normalized transaction ID''. The integrity of all data that is used to reference the output is guaranteed by the signature itself, and any modification that would change the normalized transaction ID would also invalidate the signature itself. + +Besides eliminating transaction malleability as a source of problems it also allows the use of transaction templates. Transaction templates simplify higher level protocols and allows new uses. They allow an unsigned template transaction to be used as a basis for a sequence of transaction and only once the sequence matches the signers' expectations they provide the necessary signatures for the template to become valid, thus opting in to the sequence. + +== Specification == + +The use of normalized transaction IDs is introduced as a softfork. The specification is divided into three parts: + + - Computation of the normalized transaction ID + - Introduction of a new extensible signature verification opcode to enable softfork deployment + - Changes to the UTXO tracking to enable normalized transaction ID lookup + +=== Normalized Transaction ID computation === + +In order to calculate the normalized transaction ID, the signature script is stripped from each input of the transaction of non-coinbase transactions. Stripping the signature script is achieved by setting the script's length to 0 and removing the uchar[] array from the TxIn.[[https://en.bitcoin.it/wiki/Protocol_Specification#tx|Protocol Specification: TX]] +The normalized transaction ID is then computed as the SHA 256 hash of the stripped transaction matching the existing transaction ID computation. The normalized transaction ID remains unchanged even if the signatures of the transaction are replaced/malleated and describe a class of semantically identical transactions. In the following we use ''transaction instance ID'' to refer to the transaction ID computed on the transaction including signatures. Normalized transaction IDs for coinbase transactions are computed with the signature script in the coinbase input, in order to avoid hash collisions. + +=== OP_CHECKSIGEX === +This BIP introduces a new opcode OP_CHECKSIGEX which replaces OP_NOP4. OP_CHECKSIGEX subsumes OP_CHECKSIG(VERIFY) and OP_CHECKMULTISIG(VERIFY) and extends their semantics by allowing additional parameters. + +When executed OP_CHECKSIGEX pops an integer from the top of the stack. This integer encodes the binary options which determine how OP_CHECKSIGEX verifies signatures. The following table shows the possible flags at the time of writing: + +{| class="wikitable" +!colspan="6"|OP_CHECKSIGEX flags +|- +! Name +! Value +! Description +|- +| SCRIPT_CHECKSIGEX_VERIFY +| 2^0 +| Verify after checking validity and fail script if verification failed +|- +| SCRIPT_CHECKSIGEX_MULTI +| 2^1 +| Mimic OP_CHECKMULTISIG if set otherwise mimic OP_CHECKSIG +|- +| SCRIPT_CHECKSIGEX_NORMALIZE +| 2^2 +| Normalize input hashes before checking signature +|} + +A combination of SCRIPT_CHECKSIGEX_VERIFY and SCRIPT_CHECKSIGEX_MULTI recreates the semantics of OP_CHECKSIG, OP_CHECKSIGVERIFY, OP_CHECKMULTISIG and OP_CHECKMULTISIGVERIFY. Refer to the developer documentation[[https://bitcoin.org/en/developer-guide#p2pkh-script-validation|Developer Documentation - P2PKH Script Validation]] for their semantics. + +The existing OP_CHECKMULTISIG and OP_CHECKMULTISIGVERIFY have a bug[[https://bitcoin.org/en/developer-guide#multisig|Developer Documentation - Multisig]] that pops one argument too many from the stack. This bug is not reproduced in the implementation of OP_CHECKSIGEX, so the canonical solution of pushing a dummy value onto the stack is not necessary. + +SCRIPT_CHECKSIGEX_NORMALIZE indicates that before computing the signaturehash, i.e., the hash that is signed, the transaction should be normalized by replacing all transaction IDs in the inputs by their normalized variants. The normalized transction IDs are computed as described in the next section. This normalization step is performed both when creating the signatures as well as when checking the signatures. + +In order to make use of the normalization feature, this BIP introduces two new standard transaction types + + OP_DUP OP_HASH160 OP_EQUALVERIFY OP_4 OP_CHECKSIGEX + +and + + OP_6 OP_CHECKSIGEX + +The first is the equivalent of the pay-to-pubkeyhash script with normalization (OP_4 = SCRIPT_CHECKSIGEX_NORMALIZE), while the second is the equivalent of the pay-to-multisig also with normalization (OP_6 = SCRIPT_CHECKSIGEX_NORMALIZE | SCRIPT_CHECKSIGEX_MULTI). The format of the scriptSig corresponds to the original version, with exception of omitting the dummy OP_0 in the multisig case. + +=== Tracking Normalized Transaction IDs === + +The transaction version is bumped to 2. The new version signals to clients receiving the transaction that they should track the normalized transaction ID along with the transaction instance ID in the unspent transaction output (UTXO) set. Upon receiving a version 2 transaction the client computes the normalized transaction ID, annotates the outputs with it, and adds them into the UTXO set indexed by the transaction instance ID as before. Transactions continue using the transaction instance ID to reference the outputs, but while checking the signature they may get normalized. All network messages continue to use the transaction instance ID to reference the transaction, specifically inv, getdata, tx and block messages still use transaction instance IDs, not the normalized transaction IDs. + +Outputs created by version 1 transactions are not annotated with the normalized transaction ID, and when normalizing the hashes in transaction inputs referencing version 1 outputs are not modified. + +== Rationale == + +Normalized transaction IDs are provably non-malleable since no data is included in the signaturehash whose integrity is not also proven in the signature, thus any modification causing the hash to change will also invalidate the signature. +Normalized transactions are secure as they still use cryptographic hashes over all the semantic information of the transaction, i.e., the inputs, outputs and metadata, thus it is still computationally infeasible to cause a hash collision between transactions. + +There are a number of advantages to using normalized transaction IDs: + +* Like BIP 62 and BIP 66 it solves the problem of third-parties picking transactions out of the network, modifying them and reinjecting them, as was allegedly done to defraud MtGox[[http://www.tik.ee.ethz.ch/file/7e4a7f3f2991784786037285f4876f5c/malleability.pdf|Bitcoin Transaction Malleability and MtGox]]. +* ''m-of-n'' multisig outputs are often used in higher level protocols[[http://www.tik.ee.ethz.ch/file/716b955c130e6c703fac336ea17b1670/duplex-micropayment-channels.pdf|A Fast and Scalable Payment Network with Bitcoin Duplex Micropayment Channels ]][[http://lightning.network/lightning-network-paper.pdf|The Bitcoin Lightning Network: +Scalable Off-Chain Instant Payments]] in which several parties sign a transaction. Without normalized transaction IDs it is trivial for one party to re-sign a transaction, hence changing the transaction hash and invalidating any transaction built on top of its outputs. Normalized transaction IDs force the ID not to change, even if a party replaces its signature. +* Many higher level protocols build structures of transactions on top of multisig outputs that are not completely signed. This is currently not possible without one party holding a fully signed transaction and then calculating the ID. It is desirable to be able to build successive transactions without one party collecting all signatures, and thus possibly lock in funds unilaterally. Normalized transaction IDs allow the use of transaction templates, i.e., completely unsigned transactions upon which further transactions can be built, and only once every party is assured the structure matches its expectations it signs the template, thus validating the template. + +The only occurence in which transactions can still be modified unilaterally is in the case SIGHASH_NONE, SIGHASH_SINGLE or SIGHASH_ANYONECANPAY is used. This however is not problematic since in these cases the creator of the transaction explicitly allows modification. + +In case of a transaction becoming invalid due to one of the inputs being malleated it is necessary to modify the spending transaction to reference the modified transaction ID. However, the signatures, which only use the normalized IDs, remain valid as long as the semantics of the funding transaction remain unchanged. An observer in the network may fix the transaction and reinject a corrected version. + +Using version 2 for transactions is an explicit optin to the normalized ID tracking and a simple upgrade for existing clients. It avoids having to reprocess the entire blockchain and computing the normalized transaction IDs for existing outputs in the UTXO. This would be further complicated by having to recursively compute normalized transaction IDs down to the coinbase transactions which created the coins. + +The new opcode OP_CHECKSIGEX was introduced in order to allow the use of normalized transaction IDs as a softfork and in order to keep the number of OP_NOPs needed to a bare minimum. The additional argument containing the flags can be pushed on the stack using a single byte as long as only the least significant 4 bits are set (OP_1 - OP_16), resulting in one byte overhead for this script type. Furthermore it removes the bug requiring a dummy push in the multisig scenario, resulting in the same size in this scenario. + +Tracking the normalized transaction IDs in the UTXO requires the storage of an additional hash per transaction whose outputs are not completely spent, which at 7,000,000 transactions with unspent outputs amounts to 224MB additional storage on disk. + +The coinbase transactions have been checked for hash-collisions and no collisions were found except for the coinbase transactions in blocks at heights 91842 and 91880, which are known to be identical[[https://github.com/bitcoin/bips/blob/master/bip-0030.mediawiki|BIP 30 - Duplicate transactions]], and motivated the introduction of BIP 34.[[https://github.com/bitcoin/bips/blob/master/bip-0034.mediawiki|Block v2, Height in Coinbase]] Since coinbase transactions are invalid if transmitted outside of a block it is not possible to modify them on the fly and since they only mature after being included for a long time in the blockchain they are considered safe. + +=== Impact === + +This is a softfork which replaces OP_NOP4 with the new implementation of OP_CHECKSIGEX, as such the impact on the network is minimal. Wallets that do not implement this opcode will not be able to verify the validity of the scripts, however if transactions using OP_CHECKSIGEX are included in blocks they will accept them and track the inputs correctly. This is guaranteed since the transaction inputs still use the non-normalized transaction ID to reference the outputs to be claimed, hence non-upgraded wallets can still lookup the outputs and mark them as spent. Furthermore, clients that do not implement this BIP are unable to identify outputs using this script as their own, however upgrading and rescanning the blockchain will make them available. + +== See also == + +* [[bip-0062.mediawiki|BIP 62: Dealing with malleability]] +* [[bip-0066.mediawiki|BIP 66: Strict DER Signatures]] + +== References == + + +==Copyright== +This document is placed in the public domain. \ No newline at end of file From 451260d6d906a8372675d39cd36e9a97aec089ce Mon Sep 17 00:00:00 2001 From: Chris Priest Date: Fri, 16 Oct 2015 20:10:54 -0700 Subject: [PATCH 004/259] added bip122 --- bip-0122.mediawiki | 47 ++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 47 insertions(+) create mode 100644 bip-0122.mediawiki diff --git a/bip-0122.mediawiki b/bip-0122.mediawiki new file mode 100644 index 00000000..dc1c6d7b --- /dev/null +++ b/bip-0122.mediawiki @@ -0,0 +1,47 @@ +
+  BIP: 122
+  Title: Creation of new testnet for scaling experiments
+  Author: Chris Priest 
+  Status: Draft
+  Type: Standards Track
+  Created: 2015-10-16
+
+ +==Abstract== + +This BIP defines the creation of a new parallel text network called "ScaleNet", +which will be used to test the effects of massive scale upon the bitcoin +consensus protocol. + +==Motivation== + +Bitcoin was originally designed to be an experiment. With the increase in the market +cap, this experimental nature is decreased. There is considerable doubt whether +the Bitcoin consensus protocol can handle transaction rates orders of magnitude +higher than the network sees today. + +==Specification== + +The code for ScaleNet will resemble the current Bitcoin testnet code in every way possible. +The only difference will be the elimination of the blocksize limit. + +ScaleNet coins will have 0 monetary value, just like TestNet coins. + +There will also be a ScaleNet faucet that wil be used to automatically get free ScaleNet coins. + +==ScaleNet spammer== + +Along with the creation of the ScaleNet client, there will also be a piece of software +called the "ScaleNet Spammer Client". The purpose of this software is to simply send large amounts +of transactions to the network. This software works very much like how software used to "stress test" +the main Bitcoin network. + +==Lessons Hopefully learned== + +* What happens when the blockchain get too large to fit entirely onto a consumer grade hard drive? +* How will it be possible to run a full node when there are hundreds of GB of unconfirmed transactions in the mempool? +* What kind of special attention needs to go into mining gigantic blocks (>100MB) without through the roof orphan tares. + +Each of these questions will be answered by ScaleNet. At some point in time +bitcoin will need to face these problems. Hopefully the insights learned +from ScaleNet will help drive a more data-driven approach to Bitcoin Development. From 029bd7d178fb3f163de17cd1a1b16286190ec696 Mon Sep 17 00:00:00 2001 From: Chris Priest Date: Fri, 16 Oct 2015 20:11:56 -0700 Subject: [PATCH 005/259] typos --- bip-0122.mediawiki | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/bip-0122.mediawiki b/bip-0122.mediawiki index dc1c6d7b..b1576e7b 100644 --- a/bip-0122.mediawiki +++ b/bip-0122.mediawiki @@ -40,7 +40,7 @@ the main Bitcoin network. * What happens when the blockchain get too large to fit entirely onto a consumer grade hard drive? * How will it be possible to run a full node when there are hundreds of GB of unconfirmed transactions in the mempool? -* What kind of special attention needs to go into mining gigantic blocks (>100MB) without through the roof orphan tares. +* What kind of special attention needs to go into mining gigantic blocks (>100MB) without through the roof orphan rates? Each of these questions will be answered by ScaleNet. At some point in time bitcoin will need to face these problems. Hopefully the insights learned From 6447c8df9e25df04e0e1b233a2fc69d61bb9fb4f Mon Sep 17 00:00:00 2001 From: Chris Priest Date: Fri, 16 Oct 2015 20:14:09 -0700 Subject: [PATCH 006/259] more typos --- bip-0122.mediawiki | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/bip-0122.mediawiki b/bip-0122.mediawiki index b1576e7b..ea9c903c 100644 --- a/bip-0122.mediawiki +++ b/bip-0122.mediawiki @@ -22,12 +22,12 @@ higher than the network sees today. ==Specification== -The code for ScaleNet will resemble the current Bitcoin testnet code in every way possible. +The code for ScaleNet will resemble the current Bitcoin TestNet code in every way possible. The only difference will be the elimination of the blocksize limit. ScaleNet coins will have 0 monetary value, just like TestNet coins. -There will also be a ScaleNet faucet that wil be used to automatically get free ScaleNet coins. +There will also be a ScaleNet faucet that will be used to automatically get free ScaleNet coins. ==ScaleNet spammer== From 478c14dc171a448bc5f216d34b4a39e3ad6ac1ed Mon Sep 17 00:00:00 2001 From: Chris Priest Date: Fri, 16 Oct 2015 20:14:57 -0700 Subject: [PATCH 007/259] more typos --- bip-0122.mediawiki | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/bip-0122.mediawiki b/bip-0122.mediawiki index ea9c903c..7dceb073 100644 --- a/bip-0122.mediawiki +++ b/bip-0122.mediawiki @@ -29,14 +29,14 @@ ScaleNet coins will have 0 monetary value, just like TestNet coins. There will also be a ScaleNet faucet that will be used to automatically get free ScaleNet coins. -==ScaleNet spammer== +==ScaleNet Spammer== Along with the creation of the ScaleNet client, there will also be a piece of software called the "ScaleNet Spammer Client". The purpose of this software is to simply send large amounts of transactions to the network. This software works very much like how software used to "stress test" the main Bitcoin network. -==Lessons Hopefully learned== +==Lessons Hopefully Learned== * What happens when the blockchain get too large to fit entirely onto a consumer grade hard drive? * How will it be possible to run a full node when there are hundreds of GB of unconfirmed transactions in the mempool? From 53c9fa273dd440658f5c62949efac8c4b0292fdb Mon Sep 17 00:00:00 2001 From: tx Date: Tue, 27 Oct 2015 01:15:47 -0700 Subject: [PATCH 008/259] add link to btcsuite implementation of bip 0069 --- bip-0069.mediawiki | 1 + 1 file changed, 1 insertion(+) diff --git a/bip-0069.mediawiki b/bip-0069.mediawiki index e23ff042..f556a441 100644 --- a/bip-0069.mediawiki +++ b/bip-0069.mediawiki @@ -162,6 +162,7 @@ Outputs: * [[https://github.com/bitcoinjs/bip69/blob/master/index.js|BitcoinJS]] * [[https://github.com/bitcoinjs/bip69/blob/master/test/fixtures.json|BitcoinJS Test Fixtures]] * [[https://www.npmjs.com/package/bip69|NodeJS]] +* [[https://github.com/btcsuite/btcutil/blob/master/txsort/txsort.go|Btcsuite]] ==Acknowledgements== From 694a073e15577b45fdbd679e43ff8ae76f46b7ba Mon Sep 17 00:00:00 2001 From: Daniel Cousens Date: Sat, 31 Oct 2015 23:38:23 +1100 Subject: [PATCH 009/259] bip65: accepted status --- bip-0065.mediawiki | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/bip-0065.mediawiki b/bip-0065.mediawiki index ed874782..2cbadb98 100644 --- a/bip-0065.mediawiki +++ b/bip-0065.mediawiki @@ -2,7 +2,7 @@ BIP: 65 Title: OP_CHECKLOCKTIMEVERIFY Author: Peter Todd - Status: Draft + Status: Accepted Type: Standards Track Created: 2014-10-01 From 893a4ff584e57bf431dcc12708c812c9153005e9 Mon Sep 17 00:00:00 2001 From: Christian Decker Date: Mon, 2 Nov 2015 18:09:35 +0100 Subject: [PATCH 010/259] Replaced binary flags with version, added migration to Schnorr, specified recursive computation and fixed a few minor things. --- bip-00nn.mediawiki | 83 +++++++++++++++++++++------------------------- 1 file changed, 38 insertions(+), 45 deletions(-) diff --git a/bip-00nn.mediawiki b/bip-00nn.mediawiki index 923b9e72..dfe48a53 100644 --- a/bip-00nn.mediawiki +++ b/bip-00nn.mediawiki @@ -8,15 +8,15 @@ == Abstract == -This BIP describes the use of normalized transaction IDs (TXIDs) in order to eliminate transaction malleability, both in the third-party modification scenario as well as the participant modification scenario. The transaction ID is normalized by removing the signature scripts from transactions before computing its hash. The normalized transaction hashes are then used during the signature creation and signature verification of dependent transactions. +This BIP describes the use of normalized transaction IDs (NTXIDs) in order to eliminate transaction malleability, both in the third-party modification scenario as well as the participant modification scenario. The transaction ID is normalized by removing the signature scripts from transactions before computing its hash. The normalized transaction hashes are then used during the signature creation and signature verification of dependent transactions. == Motivation == Transaction malleability refers to the fact that transactions can be modified, either by one of the signers by re-signing the transaction or a third-party by modifying the signature representation. This is a problem since any modification to the serialized representation also changes the hash of the transaction, which is used by spending transaction to reference the funds that are being transferred. If a transaction is modified and later confirmed by ending up in the blockchain all transactions that depended on the original transaction are no longer valid, and thus orphaned. -BIPs 62[[https://github.com/bitcoin/bips/blob/master/bip-0062.mediawiki|BIP 62 - Dealing with malleability]] and 66[[https://github.com/bitcoin/bips/blob/master/bip-0066.mediawiki|BIP 66 - Strict DER signatures]] alleviate the problem of third-party modification by defining a canonical representation of the signatures. However, the checking the canonical representation is complex and may not eliminate all sources of third-party malleability. Furthermore, these BIPs do not address modifications by one of the signers, i.e., re-signing the transaction, because signers can produce any number of signatures due to the random parameter in ECDSA. +BIPs 62[[https://github.com/bitcoin/bips/blob/master/bip-0062.mediawiki|BIP 62 - Dealing with malleability]] and 66[[https://github.com/bitcoin/bips/blob/master/bip-0066.mediawiki|BIP 66 - Strict DER signatures]] alleviate the problem of third-party modification by defining a canonical representation of the signatures. However, checking the canonical representation is complex and may not eliminate all sources of third-party malleability. Furthermore, these BIPs do not address modifications by one of the signers, i.e., re-signing the transaction, because signers can produce any number of signatures due to the random parameter in ECDSA. -This proposal eliminates malleability altogether by removing the malleable signatures from the hash used to reference the outputs spent by a transaction. The new hash used to reference an output is called the ''normalized transaction ID''. The integrity of all data that is used to reference the output is guaranteed by the signature itself, and any modification that would change the normalized transaction ID would also invalidate the signature itself. +This proposal eliminates malleability by removing the malleable signatures from the hash used to reference the outputs spent by a transaction. The new hash used to reference an output is called the ''normalized transaction ID''. The integrity of all data that is used to reference the output is guaranteed by the signature itself, and any modification that would change the normalized transaction ID would also invalidate the signature itself. Besides eliminating transaction malleability as a source of problems it also allows the use of transaction templates. Transaction templates simplify higher level protocols and allows new uses. They allow an unsigned template transaction to be used as a basis for a sequence of transaction and only once the sequence matches the signers' expectations they provide the necessary signatures for the template to become valid, thus opting in to the sequence. @@ -24,55 +24,40 @@ Besides eliminating transaction malleability as a source of problems it also all The use of normalized transaction IDs is introduced as a softfork. The specification is divided into three parts: - - Computation of the normalized transaction ID - - Introduction of a new extensible signature verification opcode to enable softfork deployment - - Changes to the UTXO tracking to enable normalized transaction ID lookup +* Computation of the normalized transaction ID +* Introduction of a new extensible signature verification opcode to enable softfork deployment +* Changes to the UTXO tracking to enable normalized transaction ID lookup === Normalized Transaction ID computation === -In order to calculate the normalized transaction ID, the signature script is stripped from each input of the transaction of non-coinbase transactions. Stripping the signature script is achieved by setting the script's length to 0 and removing the uchar[] array from the TxIn.[[https://en.bitcoin.it/wiki/Protocol_Specification#tx|Protocol Specification: TX]] -The normalized transaction ID is then computed as the SHA 256 hash of the stripped transaction matching the existing transaction ID computation. The normalized transaction ID remains unchanged even if the signatures of the transaction are replaced/malleated and describe a class of semantically identical transactions. In the following we use ''transaction instance ID'' to refer to the transaction ID computed on the transaction including signatures. Normalized transaction IDs for coinbase transactions are computed with the signature script in the coinbase input, in order to avoid hash collisions. +In order to calculate the normalized transaction ID, the signature script is stripped from each input of the transaction of non-coinbase transactions and each input is normalized. Stripping the signature script is achieved by setting the script's length to 0 and removing the uchar[] array from the TxIn.[[https://en.bitcoin.it/wiki/Protocol_Specification#tx|Protocol Specification: TX]] +Inputs are then normalized by replacing the hash of each previous transaction with its normalized version if available, i.e., the normalized hash of the previous transaction that created the output being spent in the current transaction. Version 1 transactions do not have a normalized transaction ID hence the non-normalized transaction ID is used for input normalization. + +The normalized transaction ID is then computed as the double SHA 256 hash of the normalized transaction matching the existing transaction ID computation. The normalized transaction ID remains unchanged even if the signatures of the transaction are replaced/malleated and describe a class of semantically identical transactions. In the following we use ''transaction instance ID'' to refer to the transaction ID computed on the transaction including signatures. Normalized transaction IDs for coinbase transactions are computed with the signature script in the coinbase input, in order to avoid hash collisions. === OP_CHECKSIGEX === -This BIP introduces a new opcode OP_CHECKSIGEX which replaces OP_NOP4. OP_CHECKSIGEX subsumes OP_CHECKSIG(VERIFY) and OP_CHECKMULTISIG(VERIFY) and extends their semantics by allowing additional parameters. +This BIP introduces a new opcode OP_CHECKSIGEX which replaces OP_NOP4. OP_CHECKSIGEX subsumes OP_CHECKSIGVERIFY and OP_CHECKMULTISIGVERIFY, and extends them by accepting a new VERSION parameter. The version parameter is a single integer pushed onto the stack before invoking OP_CHECKSIGEX and is used to group and evolve future versions of signature checking opcodes. -When executed OP_CHECKSIGEX pops an integer from the top of the stack. This integer encodes the binary options which determine how OP_CHECKSIGEX verifies signatures. The following table shows the possible flags at the time of writing: +When executed OP_CHECKSIGEX pops the version from the stack and then performs the signature check according to the specified version. If the verifying client does not support the specified version, i.e., the version was defined after the release of the client, the client must treat the OP_CHECKSIGEX as an OP_NOP. -{| class="wikitable" -!colspan="6"|OP_CHECKSIGEX flags -|- -! Name -! Value -! Description -|- -| SCRIPT_CHECKSIGEX_VERIFY -| 2^0 -| Verify after checking validity and fail script if verification failed -|- -| SCRIPT_CHECKSIGEX_MULTI -| 2^1 -| Mimic OP_CHECKMULTISIG if set otherwise mimic OP_CHECKSIG -|- -| SCRIPT_CHECKSIGEX_NORMALIZE -| 2^2 -| Normalize input hashes before checking signature -|} +==== Version 1 ==== -A combination of SCRIPT_CHECKSIGEX_VERIFY and SCRIPT_CHECKSIGEX_MULTI recreates the semantics of OP_CHECKSIG, OP_CHECKSIGVERIFY, OP_CHECKMULTISIG and OP_CHECKMULTISIGVERIFY. Refer to the developer documentation[[https://bitcoin.org/en/developer-guide#p2pkh-script-validation|Developer Documentation - P2PKH Script Validation]] for their semantics. +The first version of OP_CHECKSIGEX (VERSION=1) implements normalized transaction IDs and uses Schnorr signatures instead of the current ECDSA signatures. + +Version 1 introduces the following new standard script format: + + m {pubkey}...{pubkey} n v OP_CHECKSIGEX + +with matching scriptSig format: + + {signature}...{signature} + +This is the standard ''m-of-n'' script defined in [https://github.com/bitcoin/bips/blob/master/bip-0011.mediawiki BIP 11] with an additional version parameter v and the new opcode. Singlesig transactions are encoded as ''1-of-1'' transactions. The existing OP_CHECKMULTISIG and OP_CHECKMULTISIGVERIFY have a bug[[https://bitcoin.org/en/developer-guide#multisig|Developer Documentation - Multisig]] that pops one argument too many from the stack. This bug is not reproduced in the implementation of OP_CHECKSIGEX, so the canonical solution of pushing a dummy value onto the stack is not necessary. -SCRIPT_CHECKSIGEX_NORMALIZE indicates that before computing the signaturehash, i.e., the hash that is signed, the transaction should be normalized by replacing all transaction IDs in the inputs by their normalized variants. The normalized transction IDs are computed as described in the next section. This normalization step is performed both when creating the signatures as well as when checking the signatures. - -In order to make use of the normalization feature, this BIP introduces two new standard transaction types - - OP_DUP OP_HASH160 OP_EQUALVERIFY OP_4 OP_CHECKSIGEX - -and - - OP_6 OP_CHECKSIGEX - -The first is the equivalent of the pay-to-pubkeyhash script with normalization (OP_4 = SCRIPT_CHECKSIGEX_NORMALIZE), while the second is the equivalent of the pay-to-multisig also with normalization (OP_6 = SCRIPT_CHECKSIGEX_NORMALIZE | SCRIPT_CHECKSIGEX_MULTI). The format of the scriptSig corresponds to the original version, with exception of omitting the dummy OP_0 in the multisig case. +The normalization is achieved by normalizing the transaction before computing the signaturehash, i.e., the hash that is signed. +The transaction must be normalized by replacing all transaction IDs in the inputs by their normalized variants and stripping the signature scripts. The normalized transction IDs are computed as described in the previous section. This normalization step is performed both when creating the signatures as well as when checking the signatures. === Tracking Normalized Transaction IDs === @@ -82,12 +67,13 @@ Outputs created by version 1 transactions are not annotated with the normalized == Rationale == +=== Normalization === Normalized transaction IDs are provably non-malleable since no data is included in the signaturehash whose integrity is not also proven in the signature, thus any modification causing the hash to change will also invalidate the signature. Normalized transactions are secure as they still use cryptographic hashes over all the semantic information of the transaction, i.e., the inputs, outputs and metadata, thus it is still computationally infeasible to cause a hash collision between transactions. There are a number of advantages to using normalized transaction IDs: -* Like BIP 62 and BIP 66 it solves the problem of third-parties picking transactions out of the network, modifying them and reinjecting them, as was allegedly done to defraud MtGox[[http://www.tik.ee.ethz.ch/file/7e4a7f3f2991784786037285f4876f5c/malleability.pdf|Bitcoin Transaction Malleability and MtGox]]. +* Like BIP 62 and BIP 66 it solves the problem of third-parties picking transactions out of the network, modifying them and reinjecting them. * ''m-of-n'' multisig outputs are often used in higher level protocols[[http://www.tik.ee.ethz.ch/file/716b955c130e6c703fac336ea17b1670/duplex-micropayment-channels.pdf|A Fast and Scalable Payment Network with Bitcoin Duplex Micropayment Channels ]][[http://lightning.network/lightning-network-paper.pdf|The Bitcoin Lightning Network: Scalable Off-Chain Instant Payments]] in which several parties sign a transaction. Without normalized transaction IDs it is trivial for one party to re-sign a transaction, hence changing the transaction hash and invalidating any transaction built on top of its outputs. Normalized transaction IDs force the ID not to change, even if a party replaces its signature. * Many higher level protocols build structures of transactions on top of multisig outputs that are not completely signed. This is currently not possible without one party holding a fully signed transaction and then calculating the ID. It is desirable to be able to build successive transactions without one party collecting all signatures, and thus possibly lock in funds unilaterally. Normalized transaction IDs allow the use of transaction templates, i.e., completely unsigned transactions upon which further transactions can be built, and only once every party is assured the structure matches its expectations it signs the template, thus validating the template. @@ -96,14 +82,21 @@ The only occurence in which transactions can still be modified unilaterally is i In case of a transaction becoming invalid due to one of the inputs being malleated it is necessary to modify the spending transaction to reference the modified transaction ID. However, the signatures, which only use the normalized IDs, remain valid as long as the semantics of the funding transaction remain unchanged. An observer in the network may fix the transaction and reinject a corrected version. -Using version 2 for transactions is an explicit optin to the normalized ID tracking and a simple upgrade for existing clients. It avoids having to reprocess the entire blockchain and computing the normalized transaction IDs for existing outputs in the UTXO. This would be further complicated by having to recursively compute normalized transaction IDs down to the coinbase transactions which created the coins. - -The new opcode OP_CHECKSIGEX was introduced in order to allow the use of normalized transaction IDs as a softfork and in order to keep the number of OP_NOPs needed to a bare minimum. The additional argument containing the flags can be pushed on the stack using a single byte as long as only the least significant 4 bits are set (OP_1 - OP_16), resulting in one byte overhead for this script type. Furthermore it removes the bug requiring a dummy push in the multisig scenario, resulting in the same size in this scenario. +Using version 2 for transactions is an explicit opt-in to the normalized ID tracking and a simple upgrade for existing clients. It avoids having to reprocess the entire blockchain and computing the normalized transaction IDs for existing outputs in the UTXO. This would be further complicated by having to recursively compute normalized transaction IDs down to the coinbase transactions which created the coins. Tracking the normalized transaction IDs in the UTXO requires the storage of an additional hash per transaction whose outputs are not completely spent, which at 7,000,000 transactions with unspent outputs amounts to 224MB additional storage on disk. The coinbase transactions have been checked for hash-collisions and no collisions were found except for the coinbase transactions in blocks at heights 91842 and 91880, which are known to be identical[[https://github.com/bitcoin/bips/blob/master/bip-0030.mediawiki|BIP 30 - Duplicate transactions]], and motivated the introduction of BIP 34.[[https://github.com/bitcoin/bips/blob/master/bip-0034.mediawiki|Block v2, Height in Coinbase]] Since coinbase transactions are invalid if transmitted outside of a block it is not possible to modify them on the fly and since they only mature after being included for a long time in the blockchain they are considered safe. +=== OP_CHECKSIGEX === + +The new opcode OP_CHECKSIGEX was introduced in order to allow the use of normalized transaction IDs as a softfork and in order to keep the number of OP_NOPs needed to a bare minimum, while enabling future soft-fork updates to the signing algorithms. + +The additional argument containing the version can be pushed on the stack using a single byte up to version 16 (OP_1 - OP_16), resulting in one byte overhead for this script type. Using the standard multisig format also for 1-of-1 transactions add an additional 2 bytes, however it also removes the bug requiring a dummy push, resulting in a single byte overhead. +Furthermore, using Schnorr signatures instead of ECDSA brings a number of improvements that reduce the size of transactions (''m-of-m'' is the same size as ''1-of-1'') and increase verification speed (batch signature validation by summing up keys and signatures). The code is already in bitcoin/secp256k1 and can be merged in. We limited the description of this BIP to re-using BIP 11 style ''m-of-n'' scripts to keep it short, however Schnorr also allows a number of more complex applications which we defer to future BIPs. + +Version 0 was intentionally skipped in order to guarantee that the top-most element before OP_CHECKSIGEX is non-zero. This is necessary to guarantee that non-upgraded clients, which interpret OP_CHECKSIGEX as OP_NOP4, do not end up with a zero value on top of the stack after execution, which would be interpreted as script failure. + === Impact === This is a softfork which replaces OP_NOP4 with the new implementation of OP_CHECKSIGEX, as such the impact on the network is minimal. Wallets that do not implement this opcode will not be able to verify the validity of the scripts, however if transactions using OP_CHECKSIGEX are included in blocks they will accept them and track the inputs correctly. This is guaranteed since the transaction inputs still use the non-normalized transaction ID to reference the outputs to be claimed, hence non-upgraded wallets can still lookup the outputs and mark them as spent. Furthermore, clients that do not implement this BIP are unable to identify outputs using this script as their own, however upgrading and rescanning the blockchain will make them available. From c77b653249a067caa8f764080a639781f0887e1e Mon Sep 17 00:00:00 2001 From: Jonathan Wilkins Date: Mon, 9 Nov 2015 13:01:53 -0800 Subject: [PATCH 011/259] squashed version --- README.mediawiki | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/README.mediawiki b/README.mediawiki index 94537b76..eed2b750 100644 --- a/README.mediawiki +++ b/README.mediawiki @@ -314,6 +314,12 @@ Those proposing changes should consider that ultimately consent may rest with th | Standard | Draft |- +| [[bip-0103/blocksize.mediawiki|103]] +| Block size following technological growth +| Pieter Wuille +| Standard +| Draft +|- | [[bip-0105.mediawiki|105]] | Consensus based block size retargeting algorithm | BtcDrak From 23208ea690c0f1c2b0faa2e82df98f4a6cf7b404 Mon Sep 17 00:00:00 2001 From: Jonathan Wilkins Date: Mon, 9 Nov 2015 13:22:35 -0800 Subject: [PATCH 012/259] adding Pieter Wuille's 'Block size following technological growth --- README.mediawiki | 2 +- bip-0103.mediawiki | 72 ++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 73 insertions(+), 1 deletion(-) create mode 100644 bip-0103.mediawiki diff --git a/README.mediawiki b/README.mediawiki index eed2b750..c4d7d869 100644 --- a/README.mediawiki +++ b/README.mediawiki @@ -314,7 +314,7 @@ Those proposing changes should consider that ultimately consent may rest with th | Standard | Draft |- -| [[bip-0103/blocksize.mediawiki|103]] +| [[bip-0103.mediawiki|103]] | Block size following technological growth | Pieter Wuille | Standard diff --git a/bip-0103.mediawiki b/bip-0103.mediawiki new file mode 100644 index 00000000..39e8a3f6 --- /dev/null +++ b/bip-0103.mediawiki @@ -0,0 +1,72 @@ +
+  BIP: 103
+  Title: Block size following technological growth
+  Author: Pieter Wuille 
+  Status: Draft
+  Type: Standards Track
+  Created: 2015-07-21
+
+ +==Abstract== + +This BIP proposes a block size growth intended to accommodate for hardware and other technological improvements for the foreseeable future. + +==Motivation== + +Many people want to see Bitcoin scale over time, allowing an increasing number of transactions on the block chain. It would come at an increased cost for the ecosystem (bandwidth, processing, and storage for relay nodes, as well as an impact on propagation speed of blocks on the network), but technology also improves over time. When all technologies depended on have improved as well as their availability on the market, there is no reason why Bitcoin's fundamental transaction rate cannot improve proportionally. + +Currently, there is a consensus rule in place that limits the size of blocks to 1000000 bytes. Changing this requires a hard-forking change: one that will require every full node in the network to implement the new rules. The new chain created by those changed nodes will be rejected by old nodes, so this would effectively be a request to the ecosystem to migrate to a new and incompatible network. Doing this while controversy exists is dangerous to the network and the ecosystem. + +Furthermore, the effective space available is always constrained by a hash rate majority and its ability to process transactions. No hard forking change that relaxes the block size limit can be guaranteed to provide enough space for every possible demand - or even any particular demand - unless strong centralization of the mining ecosystem is expected. Because of that, the development of a fee market and the evolution towards an ecosystem that is able to cope with block space competition should be considered healthy. This does not mean the block size or its limitation needs to be constant forever. However, the purpose of such a change should be evolution with technological growth, and not kicking the can down the road because of a fear of change in economics. + +Bitcoin's advantage over other systems does not lie in scalability. Well-designed centralized systems can trivially compete with Bitcoin's on-chain transactions in terms of cost, speed, reliability, convenience, and scale. Its power lies in transparency, lack of need for trust in network peers, miners, and those who influence or control the system. Wanting to increase the scale of the system is in conflict with all of those. Attempting to buy time with a fast increase is not wanting to face that reality, and treating the system as something whose scale trumps all other concerns. A long term scalability plan should aim on decreasing the need for trust required in off-chain systems, rather than increasing the need for trust in Bitcoin. + +In summary, hard forks are extremely powerful, and we need to use them very responsibly as a community. They have the ability to fundamentally change the technology or economics of the system, and can be used to disadvantage those who expected certain rules to be immutable. They should be restricted to uncontroversial changes, or risk eroding the expectation of low trust needed in the system in the longer term. As the block size debate has been controversial so far - for good or bad reasons - this BIP aims for gradual change and its effects start far enough in the future. + +==Specification== + +The block size limitation is replaced by the function below, applied to the median of the timestamps of the previous 11 blocks, or in code terms: the block size limit for pindexBlock is GetMaxBlockSize(pindexBlock->pprev->GetMedianTimePast()). + +The sigop limit scales proportionally. + +It implements a series of block size steps, one every ~97 days, between January 2017 and July 2063, each increasing the maximum block size by 4.4%. This allows an overall growth of 17.7% per year. + +
+uint32_t GetMaxBlockSize(int64_t nMedianTimePast) {
+    // The first step is on January 1st 2017.
+    if (nMedianTimePast < 1483246800) {
+        return 1000000;
+    }
+    // After that, one step happens every 2^23 seconds.
+    int64_t step = (nMedianTimePast - 1483246800) >> 23;
+    // Don't do more than 11 doublings for now.
+    step = std::min(step, 175);
+    // Every step is a 2^(1/16) factor.
+    static const uint32_t bases[16] = {
+        // bases[i] == round(1000000 * pow(2.0, (i + 1) / 16.0))
+        1044274, 1090508, 1138789, 1189207,
+        1241858, 1296840, 1354256, 1414214,
+        1476826, 1542211, 1610490, 1681793,
+        1756252, 1834008, 1915207, 2000000
+    };
+    return bases[step & 15] << (step / 16);
+}
+
+ +==Rationale== + +Waiting 1.5 years before the hard fork takes place should provide ample time to minimize the risk of a hard fork, if found uncontroversial. + +Because every increase (including the first) is only 4.4%, risk from large market or technological changes is minimized. + +The growth rate of 17.7% growth per year is consistent with the average growth rate of bandwidth the last years, which seems to be the bottleneck. If over time, this growth factor is beyond what the actual technology offers, the intention should be to soft fork a tighter limit. + +Using a time-based check is very simple to implement, needs little context, is efficient, and is trivially reviewable. Using the "median time past" guarantees monotonic behaviour, as this median is required to be increasing, according to Bitcoin's existing consensus rules. Using the "median time past" of the block before means we know in advance what the limit of each block will be, without depending on the actual block's timestamp. + +==Compatibility== + +This is a hard forking change, thus breaks compatbility with old fully-validating node. It should not be deployed without widespread consensus. + +==Acknowledgements== + +Thanks to Gregory Maxwell and Wladimir J. van der Laan for their suggestions. From 64fda4ea054314a188899cfc6aef25ddd1ad3676 Mon Sep 17 00:00:00 2001 From: Eric Lombrozo Date: Tue, 17 Nov 2015 06:02:55 -0500 Subject: [PATCH 013/259] Added parameters for specification to BIP0009. --- bip-0009.mediawiki | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/bip-0009.mediawiki b/bip-0009.mediawiki index b160810f..8cd71aed 100644 --- a/bip-0009.mediawiki +++ b/bip-0009.mediawiki @@ -19,6 +19,13 @@ In addition, BIP 34 made the integer comparison (nVersion >= 2) a consensus rule ==Specification== +Each soft fork deployment is specified by the following parameters (further elaborated below): + +# The '''bit''' determines which bit in the nVersion field of the block is to be used to signal the soft fork lock-in and activation. +# The '''threshold''' specifies how many blocks within a single retarget period (2016 blocks) must have the bit set before we lock in the deployment. +# The '''deploytime''' specifies a time at which the bit starts counting towards lock-in. +# The '''timeout''' specifies a time at which the deployment is considered failed. If the median time of a block >= timeout and the soft fork has not yet locked in (including this block's bit state), the deployment is considered failed on all descendants of the block. + ===Mechanism=== '''Bit flags''' From cc90614074444d1bff1a60e1511c051e336eaab8 Mon Sep 17 00:00:00 2001 From: Eric Lombrozo Date: Tue, 17 Nov 2015 07:37:03 -0500 Subject: [PATCH 014/259] BIP-0112 minor revision to text. --- bip-0112.mediawiki | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/bip-0112.mediawiki b/bip-0112.mediawiki index e1a186fc..f79fd322 100644 --- a/bip-0112.mediawiki +++ b/bip-0112.mediawiki @@ -85,9 +85,9 @@ of some future event. However, given the immutable nature of the blockchain, it is practically impossible to retroactively invalidate a previous commitment that has already confirmed. The only mechanism we really have for retroactive invalidation is blockchain reorganization which, for fundamental security -reasons, is designed to be very hard and very expensive to deliberately pull off. +reasons, is designed to be very hard and very expensive to do. -Despite this limitation, we do have a way to provide something functionally similar +Despite this limitation, we do have a way to provide something functionally similar to retroactive invalidation while preserving irreversibility of past commitments using CHECKSEQUENCEVERIFY. By constructing scripts with multiple branches of execution where one or more of the branches are delayed we provide a time window in which someone can supply an invalidation condition that allows the From b5bc89a67c4fd5a0bd0fe1af0b328793ff783ff3 Mon Sep 17 00:00:00 2001 From: BtcDrak Date: Fri, 20 Nov 2015 10:47:46 +0000 Subject: [PATCH 015/259] BIP68: Simplify language and update for current implementation --- bip-0068.mediawiki | 229 +++++++++++++++++++-------------------------- 1 file changed, 98 insertions(+), 131 deletions(-) diff --git a/bip-0068.mediawiki b/bip-0068.mediawiki index 12b97c78..fa05c4a9 100644 --- a/bip-0068.mediawiki +++ b/bip-0068.mediawiki @@ -2,6 +2,8 @@ BIP: 68 Title: Consensus-enforced transaction replacement signaled via sequence numbers (relative lock-time) Author: Mark Friedenbach + BtcDrak + Nicolas Dorier Status: Draft Type: Standards Track Created: 2015-05-28 @@ -9,19 +11,41 @@ ==Abstract== -This BIP describes a modification to the consensus-enforced semantics of the sequence number field to enable a signed transaction input to remain invalid for a defined period of time after confirmation of its corresponding outpoint, for the purpose of supporting consensus-enforced transaction replacement features. +This BIP describes introduces consensus-enforced semantics of the sequence number field to enable a signed transaction input to remain invalid for a defined period of time after confirmation of its corresponding outpoint, for the purpose of supporting consensus-enforced transaction replacement features. ==Motivation== -Bitcoin has sequence number fields for each input of a transaction. The original idea appears to have been that the highest sequence number should dominate and miners should prefer it over lower sequence numbers. This was never really implemented, and the half-implemented code seemed to be making an assumption that miners would honestly prefer the higher sequence numbers, even if the lower ones were much much more profitable. That turns out to be a dangerous assumption, and so most technical people have assumed that kind of sequence number mediated replacement was useless because there was no way to enforce "honest" behavior, as even a few rational (profit maximizing) miners would break that completely. The change described by this BIP provides the missing piece that makes sequence numbers do something significant with respect to enforcing transaction replacement without assuming anything other than profit-maximizing behavior on the part of miners. +Bitcoin transactions have a sequence number fields for each input of a transaction. The original idea appears to have been that the highest sequence number should dominate and miners should prefer higher sequence numbers by policy alone, although this was not implemented it assumes miners would prefer the higher sequence numbers even if the lower ones were much much more profitable. However, profit maximizing miners would break that assumption completely. The change described by this BIP repurposes the sequence number into a new usage without breaking existing usages while leaving room for future expansion and other use cases. + +The transaction nLockTime is used to prevent the mining of a transaction until a certain date. (in block height or time) +nSequence will be repurposed to prevent mining of a transaction until a certain age of the spent output. (in blocks or timespan) +This, among other usage, allows bi-directional payment channels as used in [Hashed Timelock Contrats (HTLCs)](https://github.com/ElementsProject/lightning/raw/master/doc/deployable-lightning.pdf) and [BIP112](https://github.com/bitcoin/bips/blob/master/bip-0112.mediawiki#Bidirectional_Payment_Channels). ==Specification== -For transactions with an nVersion of 2 or greater, if the most significant bit (1 << 31) of a sequence number is clear, the remaining 31 bits are interpreted as an encoded relative lock-time. A sequence number with the most significant bit set is given no consensus meaning and can be included in any block, like normal, under all circumstances. +This specification defined the meaning of sequence numbers for transactions with an nVersion greater than or equal to 2 for which the rest of this specification relies on. -If the second most significant bit (1 << 30) is clear, the next 16 bits are interpreted as a minimum block-height constraint over the input's age. The remaining 14 bits have no consensus-enforced meaning. A sequence number of zero indicates a relative lock-time of zero blocks (bits 31 and 30 clear) and can be included in any block. A sequence number of 1 << 14 can be included in the next block after the input it is spending, or any block thereafter, but cannot be included in the same block as its parent. A sequence number of 2 << 14 can't be included until at least two blocks later, and so on. +If bit (1 << 31) of the sequence number is set, then no consensus meaning is applied to the sequence number and can be included in any block, like normal, under all circumstances. -Alternatively, if the second most significant bit (1 << 30) is set, the next 25 bits are interpreted as a minimum block-time constraint over the input's age. The remaining 5 bits have no consensus-enforced meaning. A sequence number with just that second most significant bit set (0x40000000) is interpreted as a relative lock-time of 0, measured in seconds, and can be included in the same block as the output being spent. Advancing that sequence number by 2^5 (0x40000020) constrains the transaction to be included in blocks with an nTime timestamp at least one second greater than the median time stamp of the 11 blocks prior to the block containing the coin being spent. Advancing the sequence number by an additional 2^5 (0x40000040) constrains the spend to be two seconds later, and so on. +If bit (1 << 31) of the sequence number is clear, then the sequence number is interpreted as an encoded relative lock-time. + +The sequence number encoding is interpreted as follows: + +Bit (1 << 22) determines if the relative lock-time is time based or block based. +If the bit is set, the interpretation for relative lock-time in units of 512 seconds. If the bit is not set, it specifies relative lock-time in blocks. + +Note (1 << 22) was chosen because it is the highest you can go without moving to 4-byte pushes when using the Bitcoin scripting language in conjunction with OP_CHECKSEQUENCEVERIFY: i.e. 3 bytes = 24 bits where pushes are signed integers which leaving 1 bit for the flag and 22 bits for the relative lock-time encoding. + +This specification only interprets 16 bits of the sequence number as relative lock-time, so a mask of 0x0000ffff must be applied to the sequence field to extract the relative lock-time. This is to allow for future expansion. The specification allows for a year of relative lock-time. + +For time based relative lock-time, 512 second granularity was chosen because bitcoin blocks are generated every 600 seconds. So when using block based or time based relative locktime, the same amount of time can be encoded with the available number of bits. Converting from a sequence number to seconds is performed by multiplying by 512 = 2^9, or equivalently shifting up by 9 bits. + +When the relative lock-time is time-based, it is interpreted as a minimum block-time constraint over the input's age. A relative time-based lock-time of zero indicates an input which can be included in any block. More generally, a relative time-based lock-time n can be included into any block produced 512 * n seconds after the mining date of the output it is spending, or any block thereafter. +The mining date of the output is equals to the Median Time Past of the previous block which mined it. + +The block produced time is either equals to median time past of its parent or to its nTime field, depending on the state of BIP113 (MTP). + +When the relative lock-time is block-based, it is interpreted as a minimum block-height constraint over the input's age. A relative block-based lock-time of zero indicates an input which can be included in any block. More generally, a relative block lock-time n can be included n blocks after the mining date of the output it is spending, or any block thereafter. This is proposed to be accomplished by replacing IsFinalTx() and CheckFinalTx(), existing consensus and non-consensus code functions that return true if a transaction's lock-time constraints are satisfied and false otherwise, with LockTime() and CheckLockTime(), new functions that return a non-zero value if a transaction's lock-time or sequence number constraints are not satisfied and zero otherwise: @@ -33,28 +57,41 @@ This is proposed to be accomplished by replacing IsFinalTx() and CheckFinalTx(), /* Setting nSequence to this value for every input in a transaction * disables nLockTime. */ - const uint32_t CTxIn::SEQUENCE_FINAL = 0xffffffff; - /* Threshold for CTxIn::nSequence: below this value it is interpreted - * as arelative lock-time, otherwise ignored. */ - const uint32_t CTxIn::SEQUENCE_LOCKTIME_THRESHOLD = (1 << 31); - /* Threshold for CTxIn::nSequence when interpreted as a relative - * lock-time: below this value it has units of blocks, otherwise - * seconds. */ - const uint32_t CTxIn::SEQUENCE_UNITS_THRESHOLD = (1 << 30); - /* Number of reserved low-order bits (depending on units used) which - * are shifted out prior to relative lock-time constraint checking. */ - const int CTxIn::SEQUENCE_BLOCKS_OFFSET = 14; - const int CTxIn::SEQUENCE_SECONDS_OFFSET = 5; + static const uint32_t SEQUENCE_FINAL = 0xffffffff; - int64_t LockTime(const CTransaction &tx, - int flags, const CCoinsView* pCoinsView, - int nBlockHeight, int64_t nBlockTime) + /* If this flag set, CTxIn::nSequence is NOT interpreted as a + * relative lock-time. Setting the most significant bit of a + * sequence number disabled relative lock-time. */ + static const uint32_t SEQUENCE_LOCKTIME_DISABLED_FLAG = (1 << 31); + + /* If CTxIn::nSequence encodes a relative lock-time and this flag + * is set, the relative lock-time has units of 512 seconds, + * otherwise it specifies blocks with a granularity of 1. */ + static const uint32_t SEQUENCE_LOCKTIME_SECONDS_FLAG = (1 << 22); + + /* If CTxIn::nSequence encodes a relative lock-time, this mask is + * applied to extract that lock-time from the sequence field. */ + static const uint32_t SEQUENCE_LOCKTIME_MASK = 0x0000ffff; + + /* In order to use the same number of bits to encode roughly the + * same wall-clock duration, and because blocks are naturally + * limited to occur every 600s on average, the minimum granularity + * for time-based relative lock-time is fixed at 512 seconds. + * Converting from CTxIn::nSequence to seconds is performed by + * multiplying by 512 = 2^9, or equivalently shifting up by + * 9 bits. */ + static const int SEQUENCE_LOCKTIME_GRANULARITY = 9; + + int64_t LockTime(const CTransaction &tx, int flags, const std::vector* prevHeights, const CBlockIndex& block) { - CCoins coins; - + assert(prevHeights == NULL || prevHeights->size() == tx.vin.size()); + int64_t nBlockTime = (flags & LOCKTIME_MEDIAN_TIME_PAST) + ? block.GetAncestor(std::max(block.nHeight-1, 0))->GetMedianTimePast() + : block.GetBlockTime(); + bool fEnforceBIP68 = static_cast(tx.nVersion) >= 2 && flags & LOCKTIME_VERIFY_SEQUENCE; - + // Will be set to the equivalent height- and time-based nLockTime // values that would be necessary to satisfy all relative lock- // time constraints given our view of block chain history. @@ -63,10 +100,10 @@ This is proposed to be accomplished by replacing IsFinalTx() and CheckFinalTx(), // Will remain equal to true if all inputs are finalized // (CTxIn::SEQUENCE_FINAL). bool fFinalized = true; - - BOOST_FOREACH(const CTxIn& txin, tx.vin) { + for (size_t txinIndex = 0; txinIndex < tx.vin.size(); txinIndex++) { + const CTxIn& txin = tx.vin[txinIndex]; // Set a flag if we witness an input that isn't finalized. - if (CTxIn::SEQUENCE_FINAL == txin.nSequence) + if (txin.nSequence == CTxIn::SEQUENCE_FINAL) continue; else fFinalized = false; @@ -74,70 +111,35 @@ This is proposed to be accomplished by replacing IsFinalTx() and CheckFinalTx(), // Do not enforce sequence numbers as a relative lock time // unless we have been instructed to, and a view has been // provided. - if (!(fEnforceBIP68 && pCoinsView)) + if (!fEnforceBIP68) continue; - // Sequence numbers equal to or above the locktime threshold - // are not treated as relative lock-times, nor are they given - // any consensus-enforced meaning at this point. - if (txin.nSequence >= CTxIn::SEQUENCE_LOCKTIME_THRESHOLD) + // Sequence numbers with the most significant bit set are not + // treated as relative lock-times, nor are they given any + // consensus-enforced meaning at this point. + if (txin.nSequence & CTxIn::SEQUENCE_LOCKTIME_DISABLED_FLAG) continue; - // Fetch the UTXO corresponding to this input. - if (!pCoinsView->GetCoins(txin.prevout.hash, coins)) { - // It is fully expected that coinbases inputs are not - // found in the UTXO set. Proceed to the next intput... - if (txin.prevout.IsNull()) - continue; - // If a non-coinbase input cannot be found, we cannot - // be certain about whether lock-time constraints have - // been satisfied. Note that it should only ever be - // possible for this to happen with wallet transactions - // that have unknown inputs. - else - return std::numeric_limits::max(); - } - - // coins.nHeight is MEMPOOL_HEIGHT (an absurdly high value) - // if the parent transaction was from the mempool. We can't - // know what height it will have once confirmed, but we - // assume it makes it in the same block. - int nCoinHeight = std::min(coins.nHeight, nBlockHeight); - - if (txin.nSequence < CTxIn::SEQUENCE_UNITS_THRESHOLD) { + if (prevHeights == NULL) + continue; + + int nCoinHeight = (*prevHeights)[txinIndex]; + + if (txin.nSequence & CTxIn::SEQUENCE_LOCKTIME_SECONDS_FLAG) { + + int64_t nCoinTime = block.GetAncestor(std::max(nCoinHeight-1, 0))->GetMedianTimePast(); + + // Time-based relative lock-times are measured from the + // smallest allowed timestamp of the block containing the + // txout being spent, which is the median time past of the + // block prior. + nMinTime = std::max(nMinTime, nCoinTime + (int64_t)((txin.nSequence & CTxIn::SEQUENCE_LOCKTIME_MASK) << CTxIn::SEQUENCE_LOCKTIME_GRANULARITY) - 1); + } else { // We subtract 1 from relative lock-times because a lock- // time of 0 has the semantics of "same block," so a lock- // time of 1 should mean "next block," but nLockTime has // the semantics of "last invalid block height." - nMinHeight = std::max(nMinHeight, nCoinHeight + (int)( - txin.nSequence >> CTxIn::SEQUENCE_BLOCKS_OFFSET) - 1); - } else { - // In two locations that follow we make reference to - // chainActive.Tip(). To prevent a race condition, we - // store a reference to the current tip. - // - // Note that it is not guaranteed that indexBestBlock will - // be consistent with the passed in view. The proper thing - // to do is to have the view return time information about - // UTXOs. - const CBlockIndex& indexBestBlock = *chainActive.Tip(); - - // The only time the negative branch of this conditional - // is executed is when the prior output was taken from the - // mempool, in which case we assume it makes it into the - // same block (see above). - int64_t nCoinTime = (nCoinHeight <= (indexBestBlock.nHeight+1)) - ? indexBestBlock.GetAncestor(nCoinHeight-1)->GetMedianTimePast() - : nBlockTime; - - // Time-based relative lock-times are measured from the - // smallest allowed timestamp of the block containing the - // txout being spent, which is the median time past of the - // block prior. We subtract one for the same reason as - // above. - nMinTime = std::max(nMinTime, nCoinTime + (int64_t)(( - txin.nSequence - CTxIn::SEQUENCE_UNITS_THRESHOLD) - >> CTxIn::SEQUENCE_SECONDS_OFFSET) - 1); + nMinHeight = std::max(nMinHeight, nCoinHeight + (int)(txin.nSequence & CTxIn::SEQUENCE_LOCKTIME_MASK) - 1); } } @@ -146,62 +148,30 @@ This is proposed to be accomplished by replacing IsFinalTx() and CheckFinalTx(), // are not enforced. if (fFinalized) return 0; - + if ((int64_t)tx.nLockTime < LOCKTIME_THRESHOLD) nMinHeight = std::max(nMinHeight, (int)tx.nLockTime); else nMinTime = std::max(nMinTime, (int64_t)tx.nLockTime); - if (nMinHeight >= nBlockHeight) + if (nMinHeight >= block.nHeight) return nMinHeight; + if (nMinTime >= nBlockTime) return nMinTime; return 0; - } - - int64_t CheckLockTime(const CTransaction &tx, int flags) - { - AssertLockHeld(cs_main); - - // By convention a negative value for flags indicates that the - // current network-enforced consensus rules should be used. - flags = std::max(flags, 0); - - // pcoinsTip contains the UTXO set for chainActive.Tip() - CCoinsViewMemPool viewMemPool(pcoinsTip, mempool); - const CCoinsView *pCoinsView = &viewMemPool; - - // CheckLockTime() uses chainActive.Height()+1 to evaluate - // nLockTime because when LockTime() is called within - // CBlock::AcceptBlock(), the height of the block *being* - // evaluated is what is used. Thus if we want to know if a - // transaction can be part of the *next* block, we need to call - // LockTime() with one more than chainActive.Height(). - const int nBlockHeight = chainActive.Height() + 1; - - // Timestamps on the other hand don't get any special treatment, - // because we can't know what timestamp the next block will have, - // and there aren't timestamp applications where it matters. - const int64_t nBlockTime = GetAdjustedTime(); - - return LockTime(tx, flags, pCoinsView, nBlockHeight, nBlockTime); - } - + } Code conditional on the return value of IsFinalTx() / CheckLockTime() has to be updated as well, since the semantics of the return value has been inverted. -==Rationale== - -Using sequence numbers for locking inputs makes sense, since no transaction can be in a block before its parent transactions. This means that a lower sequence number can always be included earlier than a higher one (even if the time the original coins being spent was unknown when the transaction was authored). Because of this, even rational miners should go along with the scheme: Take the lowest sequence number and collect the fees, or skip over it in the hopes that no one else takes a lower number before the next available higher number becomes spendable. And, of course, users are not constrained to make their sequence numbers go up only one at a time. So it's "take the most updated version, now, or gamble that no one in the next dozen blocks takes the most updated and that you manage to include the next to most when it finally becomes mineable." This is similar to how lock-time works. In fact, this scheme is precisely a per-input relative lock-time. - ==Example: Bidirectional payment channel== -A bidirectional payment channel can be established by two parties funding a single output in the following way: Alice funds a 1btc output which is the 2-of-2 multisig of Alice AND Bob, or Alice's key only after a sufficiently long timeout, e.g. 30 days or 4320 blocks. The channel-generating transaction is signed by Alice and broadcast to the network. +A bidirectional payment channel can be established by two parties funding a single output in the following way: Alice funds a 1 BTC output which is the 2-of-2 multisig of Alice AND Bob, or Alice's key only after a sufficiently long timeout, e.g. 30 days or 4320 blocks. The channel-generating transaction is signed by Alice and broadcast to the network. -Alice desires to send Bob a payment of 0.1btc. She does so by constructing a transaction spending the 1btc output and sending 0.1btc to Bob and 0.9btc back to herself. She provides her signature for the 2-of-2 multisig constraint, and sets a relative lock-time using the sequence number field such that the transaction will become valid 24-hours or 144 blocks before the refund timeout. Two more times Alice sends Bob a payment of 0.1btc, each time generating and signing her half of a transaction spending the 1btc output and sending 0.2btc, then 0.3btc to Bob with a relative lock-time of 29 days from creation of the channel. +Alice desires to send Bob a payment of 0.1 BTC. She does so by constructing a transaction spending the 1 BTC output and sending 0.1 BTC to Bob and 0.9 BTC back to herself. She provides her signature for the 2-of-2 multisig constraint, and sets a relative lock-time using the sequence number field such that the transaction will become valid 24-hours or 144 blocks before the refund timeout. Two more times Alice sends Bob a payment of 0.1 BTC, each time generating and signing her half of a transaction spending the 1btc output and sending 0.2 BTC, then 0.3 BTC to Bob with a relative lock-time of 29 days from creation of the channel. -Bob now desires to send Alice a refund of 0.25btc. He does so by constructing a transaction spending the 1btc output and sending 0.95btc (= 0.7btc + 0.25btc) to Alice and 0.05btc to himself. Since Bob will still have in his logs the transaction giving him 0.7btc 29 days after the creation of the channel, Alice demands that this new transaction have a relative lock-time of 28 days so she has a full day to broadcast it before the next transaction matures. +Bob now desires to send Alice a refund of 0.25 BTC. He does so by constructing a transaction spending the 1btc output and sending 0.95 BTC (= 0.7 BTC + 0.25 BTC) to Alice and 0.05 BTC to himself. Since Bob will still have in his logs the transaction giving him 0.7 BTC 29 days after the creation of the channel, Alice demands that this new transaction have a relative lock-time of 28 days so she has a full day to broadcast it before the next transaction matures. Alice and Bob continue to make payments to each other, decrementing the relative lock-time by one day each time the channel switches direction, until the present time is reached or either party desires to close out the channel. A close-out is performed by finalizing the input (nSequence = MAX_INT) and both parties signing. @@ -215,11 +185,13 @@ https://github.com/bitcoin/bitcoin/pull/6312 Credit goes to Gregory Maxwell for providing a succinct and clear description of the behavior of this change, which became the basis of this BIP text. +This BIP was edited by BtcDrak and Nicholas Dorier. + ==Deployment== -We reuse the double-threshold switch over mechanism from BIPs 34 and 66, with the same thresholds, but for nVersion = 4. The new rules are in effect for every block (at height H) with nVersion = 4 and at least 750 out of 1000 blocks preceding it (with heights H-1000..H-1) also have nVersion = 4. Furthermore, when 950 out of the 1000 blocks preceding a block do have nVersion = 4, nVersion = 3 blocks become invalid, and all further blocks enforce the new rules. +This BIP is to be deployed by either version-bits BIP9 or by isSuperMajority(). Exact details TDB. -It is recommended that this soft-fork deployment trigger include other related proposals for improving Bitcoin's lock-time capabilities, including [https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki BIP 65]: OP_CHECKLOCKTIMEVERIFY, [https://github.com/bitcoin/bips/blob/master/bip-0112.mediawiki BIP 112]: CHECKSEQUENCEVERIFY, and [https://github.com/bitcoin/bips/blob/master/bip-0113.mediawiki BIP 113] Median time-past as endpoint for lock-time calculations. +It is recommended to deploy BIP68 and BIP112 at the same time as this BIP. ==Compatibility== @@ -243,12 +215,7 @@ The most efficient way to calculate sequence number from relative lock-time is w Bitcoin mailing list discussion: https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg07864.html -[https://github.com/bitcoin/bips/blob/master/bip-0034.mediawiki BIP 34]: Block v2, Height in Coinbase +BIP112: https://github.com/bitcoin/bips/blob/master/bip-0112.mediawiki +BIP113: https://github.com/bitcoin/bips/blob/master/bip-0113.mediawiki +Hashed Timelock Contrats (HTLCs): https://github.com/ElementsProject/lightning/raw/master/doc/deployable-lightning.pdf -[https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki BIP 65]: OP_CHECKLOCKTIMEVERIFY - -[https://github.com/bitcoin/bips/blob/master/bip-0066.mediawiki BIP 66]: Strict DER signatures - -[https://github.com/bitcoin/bips/blob/master/bip-0112.mediawiki BIP 112]: CHECKSEQUENCEVERIFY - -[https://github.com/bitcoin/bips/blob/master/bip-0113.mediawiki BIP 113]: Median time-past as endpoint for lock-time calculations From 2bc1979601fb0efed3d3f65ec645ed77e2025234 Mon Sep 17 00:00:00 2001 From: BtcDrak Date: Fri, 20 Nov 2015 15:11:01 +0000 Subject: [PATCH 016/259] Edits from kinoshitajona --- bip-0068.mediawiki | 42 +++++++++++++++++++++--------------------- 1 file changed, 21 insertions(+), 21 deletions(-) diff --git a/bip-0068.mediawiki b/bip-0068.mediawiki index fa05c4a9..26861eee 100644 --- a/bip-0068.mediawiki +++ b/bip-0068.mediawiki @@ -4,6 +4,7 @@ Author: Mark Friedenbach BtcDrak Nicolas Dorier + kinoshitajona Status: Draft Type: Standards Track Created: 2015-05-28 @@ -11,34 +12,33 @@ ==Abstract== -This BIP describes introduces consensus-enforced semantics of the sequence number field to enable a signed transaction input to remain invalid for a defined period of time after confirmation of its corresponding outpoint, for the purpose of supporting consensus-enforced transaction replacement features. +This BIP introduces consensus-enforced semantics of the sequence number field to enable a signed transaction input to remain invalid for a defined period of time after confirmation of its corresponding outpoint, for the purpose of supporting consensus-enforced transaction replacement features. ==Motivation== -Bitcoin transactions have a sequence number fields for each input of a transaction. The original idea appears to have been that the highest sequence number should dominate and miners should prefer higher sequence numbers by policy alone, although this was not implemented it assumes miners would prefer the higher sequence numbers even if the lower ones were much much more profitable. However, profit maximizing miners would break that assumption completely. The change described by this BIP repurposes the sequence number into a new usage without breaking existing usages while leaving room for future expansion and other use cases. +Bitcoin transactions have a sequence number field for each input. The original idea appears to have been that a transaction in the mempool would be replaced by using the same input with a higher sequence value. Although this was not properly implemented, it assumes miners would prefer higher sequence numbers even if the lower ones were more profitable to mine. However, a miner acting on profit motives alone would break that assumption completely. The change described by this BIP repurposes the sequence number for new use cases without breaking existing functionality. It also leaves room for future expansion and other use cases. The transaction nLockTime is used to prevent the mining of a transaction until a certain date. (in block height or time) nSequence will be repurposed to prevent mining of a transaction until a certain age of the spent output. (in blocks or timespan) -This, among other usage, allows bi-directional payment channels as used in [Hashed Timelock Contrats (HTLCs)](https://github.com/ElementsProject/lightning/raw/master/doc/deployable-lightning.pdf) and [BIP112](https://github.com/bitcoin/bips/blob/master/bip-0112.mediawiki#Bidirectional_Payment_Channels). +This, among other uses, allows bi-directional payment channels as used in [Hashed Timelock Contracts (HTLCs)](https://github.com/ElementsProject/lightning/raw/master/doc/deployable-lightning.pdf) and [BIP112](https://github.com/bitcoin/bips/blob/master/bip-0112.mediawiki#Bidirectional_Payment_Channels). ==Specification== -This specification defined the meaning of sequence numbers for transactions with an nVersion greater than or equal to 2 for which the rest of this specification relies on. +This specification defines the meaning of sequence numbers for transactions with an nVersion greater than or equal to 2 for which the rest of this specification relies on. -If bit (1 << 31) of the sequence number is set, then no consensus meaning is applied to the sequence number and can be included in any block, like normal, under all circumstances. +If bit (1 << 31) of the sequence number is set, then no consensus meaning is applied to the sequence number and can be included in any block under all currently possible circumstances. -If bit (1 << 31) of the sequence number is clear, then the sequence number is interpreted as an encoded relative lock-time. +If bit (1 << 31) of the sequence number is not set, then the sequence number is interpreted as an encoded relative lock-time. The sequence number encoding is interpreted as follows: -Bit (1 << 22) determines if the relative lock-time is time based or block based. -If the bit is set, the interpretation for relative lock-time in units of 512 seconds. If the bit is not set, it specifies relative lock-time in blocks. +Bit (1 << 22) determines if the relative lock-time is time-based or block based: If the bit is set, it specifies relative lock-time in units of 512 seconds granularity from the median time past of its previous block to the block-time Median Time Past or nTime depending on the enforcement status of BIP113. If the bit is not set, it specifies relative lock-time in blocks. Note (1 << 22) was chosen because it is the highest you can go without moving to 4-byte pushes when using the Bitcoin scripting language in conjunction with OP_CHECKSEQUENCEVERIFY: i.e. 3 bytes = 24 bits where pushes are signed integers which leaving 1 bit for the flag and 22 bits for the relative lock-time encoding. -This specification only interprets 16 bits of the sequence number as relative lock-time, so a mask of 0x0000ffff must be applied to the sequence field to extract the relative lock-time. This is to allow for future expansion. The specification allows for a year of relative lock-time. +This specification only interprets 16 bits of the sequence number as relative lock-time, so a mask of 0x0000ffff MUST be applied to the sequence field to extract the relative lock-time. This is to allow for future expansion. The specification allows for a year of relative lock-time. -For time based relative lock-time, 512 second granularity was chosen because bitcoin blocks are generated every 600 seconds. So when using block based or time based relative locktime, the same amount of time can be encoded with the available number of bits. Converting from a sequence number to seconds is performed by multiplying by 512 = 2^9, or equivalently shifting up by 9 bits. +For time based relative lock-time, 512 second granularity was chosen because bitcoin blocks are generated every 600 seconds. So when using block based or time based relative lock-time, the same amount of time can be encoded with the available number of bits. Converting from a sequence number to seconds is performed by multiplying by 512 = 2^9, or equivalently shifting up by 9 bits. When the relative lock-time is time-based, it is interpreted as a minimum block-time constraint over the input's age. A relative time-based lock-time of zero indicates an input which can be included in any block. More generally, a relative time-based lock-time n can be included into any block produced 512 * n seconds after the mining date of the output it is spending, or any block thereafter. The mining date of the output is equals to the Median Time Past of the previous block which mined it. @@ -47,11 +47,11 @@ The block produced time is either equals to median time past of its parent or to When the relative lock-time is block-based, it is interpreted as a minimum block-height constraint over the input's age. A relative block-based lock-time of zero indicates an input which can be included in any block. More generally, a relative block lock-time n can be included n blocks after the mining date of the output it is spending, or any block thereafter. -This is proposed to be accomplished by replacing IsFinalTx() and CheckFinalTx(), existing consensus and non-consensus code functions that return true if a transaction's lock-time constraints are satisfied and false otherwise, with LockTime() and CheckLockTime(), new functions that return a non-zero value if a transaction's lock-time or sequence number constraints are not satisfied and zero otherwise: +This is proposed to be accomplished by replacing IsFinalTx() and CheckFinalTx(), existing consensus and non-consensus code functions that return true if a transaction's lock-time constraints are satisfied and false otherwise, with LockTime() and CheckLockTime(), new functions that return a non-zero value if a transaction's lock-time or sequence valuenumber constraints are not satisfied and zero otherwise: 
     enum {
-        /* Interpret sequence numbers as relative lock-time constraints. */
+        /* Interpret sequence valuenumbers as relative lock-time constraints. */
         LOCKTIME_VERIFY_SEQUENCE = (1 << 0),
     };
     
@@ -61,7 +61,7 @@ This is proposed to be accomplished by replacing IsFinalTx() and CheckFinalTx(),
     
     /* If this flag set, CTxIn::nSequence is NOT interpreted as a
      * relative lock-time. Setting the most significant bit of a
-     * sequence number disabled relative lock-time. */
+     * sequence valuenumber disabled relative lock-time. */
     static const uint32_t SEQUENCE_LOCKTIME_DISABLED_FLAG = (1 << 31);
     
     /* If CTxIn::nSequence encodes a relative lock-time and this flag
@@ -108,13 +108,13 @@ This is proposed to be accomplished by replacing IsFinalTx() and CheckFinalTx(),
             else
                 fFinalized = false;
     
-            // Do not enforce sequence numbers as a relative lock time
+            // Do not enforce sequence valuenumbers as a relative lock time
             // unless we have been instructed to, and a view has been
             // provided.
             if (!fEnforceBIP68)
                 continue;
     
-            // Sequence numbers with the most significant bit set are not
+            // Sequence valuenumbers with the most significant bit set are not
             // treated as relative lock-times, nor are they given any
             // consensus-enforced meaning at this point.
             if (txin.nSequence & CTxIn::SEQUENCE_LOCKTIME_DISABLED_FLAG)
@@ -143,7 +143,7 @@ This is proposed to be accomplished by replacing IsFinalTx() and CheckFinalTx(),
             }
         }
     
-        // If all sequence numbers are CTxIn::SEQUENCE_FINAL, the
+        // If all sequence valuenumbers are CTxIn::SEQUENCE_FINAL, the
         // transaction is considered final and nLockTime constraints
         // are not enforced.
         if (fFinalized)
@@ -169,7 +169,7 @@ Code conditional on the return value of IsFinalTx() / CheckLockTime() has to be
 
 A bidirectional payment channel can be established by two parties funding a single output in the following way: Alice funds a 1 BTC output which is the 2-of-2 multisig of Alice AND Bob, or Alice's key only after a sufficiently long timeout, e.g. 30 days or 4320 blocks. The channel-generating transaction is signed by Alice and broadcast to the network.
 
-Alice desires to send Bob a payment of 0.1 BTC. She does so by constructing a transaction spending the 1 BTC output and sending 0.1 BTC to Bob and 0.9 BTC back to herself. She provides her signature for the 2-of-2 multisig constraint, and sets a relative lock-time using the sequence number field such that the transaction will become valid 24-hours or 144 blocks before the refund timeout. Two more times Alice sends Bob a payment of 0.1 BTC, each time generating and signing her half of a transaction spending the 1btc output and sending 0.2 BTC, then 0.3 BTC to Bob with a relative lock-time of 29 days from creation of the channel.
+Alice desires to send Bob a payment of 0.1 BTC. She does so by constructing a transaction spending the 1 BTC output and sending 0.1 BTC to Bob and 0.9 BTC back to herself. She provides her signature for the 2-of-2 multisig constraint, and sets a relative lock-time using the sequence valuenumber field such that the transaction will become valid 24-hours or 144 blocks before the refund timeout. Two more times Alice sends Bob a payment of 0.1 BTC, each time generating and signing her half of a transaction spending the 1btc output and sending 0.2 BTC, then 0.3 BTC to Bob with a relative lock-time of 29 days from creation of the channel.
 
 Bob now desires to send Alice a refund of 0.25 BTC. He does so by constructing a transaction spending the 1btc output and sending 0.95 BTC (= 0.7 BTC + 0.25 BTC) to Alice and 0.05 BTC to himself. Since Bob will still have in his logs the transaction giving him 0.7 BTC 29 days after the creation of the channel, Alice demands that this new transaction have a relative lock-time of 28 days so she has a full day to broadcast it before the next transaction matures.
 
@@ -185,7 +185,7 @@ https://github.com/bitcoin/bitcoin/pull/6312
 
 Credit goes to Gregory Maxwell for providing a succinct and clear description of the behavior of this change, which became the basis of this BIP text.
 
-This BIP was edited by BtcDrak and Nicholas Dorier.
+This BIP was edited by BtcDrak and Nicolas Dorier.
 
 ==Deployment==
 
@@ -195,11 +195,11 @@ It is recommended to deploy BIP68 and BIP112 at the same time as this BIP.
 
 ==Compatibility==
 
-The only use of sequence numbers by the Bitcoin Core reference client software is to disable checking the nLockTime constraints in a transaction. The semantics of that application are preserved by this BIP.
+The only use of sequence valuenumbers by the Bitcoin Core reference client software is to disable checking the nLockTime constraints in a transaction. The semantics of that application are preserved by this BIP.
 
-There may be other uses for the sequence number field that are not commonplace or yet to be discovered. To allow for other uses of the sequence number field, it is only interpreted as a relative lock-time as described in this BIP if the most significant bit is clear. This allows up to 31 bits of the sequence number field to be used for other purposes in applications which don't simultaneously need a per-input relative lock-time. In addition, the unused low-order bits of the relative lock-time encoding are available for use by future soft-fork extensions.
+There may be other uses for the sequence valuenumber field that are not commonplace or yet to be discovered. To allow for other uses of the sequence valuenumber field, it is only interpreted as a relative lock-time as described in this BIP if the most significant bit is clear. This allows up to 31 bits of the sequence valuenumber field to be used for other purposes in applications which don't simultaneously need a per-input relative lock-time. In addition, the unused low-order bits of the relative lock-time encoding are available for use by future soft-fork extensions.
 
-The most efficient way to calculate sequence number from relative lock-time is with bit masks and shifts:
+The most efficient way to calculate sequence valuenumber from relative lock-time is with bit masks and shifts:
 
 
     // 0 <= nHeight < 65,535 blocks (1.25 years)

From 7d7083f722efa414b9cf3d7c1346d34d53f89b01 Mon Sep 17 00:00:00 2001
From: BtcDrak 
Date: Fri, 20 Nov 2015 15:11:50 +0000
Subject: [PATCH 017/259] clarify specification further

---
 bip-0068.mediawiki | 20 +++++++++-----------
 1 file changed, 9 insertions(+), 11 deletions(-)

diff --git a/bip-0068.mediawiki b/bip-0068.mediawiki
index 26861eee..44b8a1a0 100644
--- a/bip-0068.mediawiki
+++ b/bip-0068.mediawiki
@@ -18,9 +18,7 @@ This BIP introduces consensus-enforced semantics of the sequence number field to
 
 Bitcoin transactions have a sequence number field for each input. The original idea appears to have been that a transaction in the mempool would be replaced by using the same input with a higher sequence value. Although this was not properly implemented, it assumes miners would prefer higher sequence numbers even if the lower ones were more profitable to mine. However, a miner acting on profit motives alone would break that assumption completely. The change described by this BIP repurposes the sequence number for new use cases without breaking existing functionality. It also leaves room for future expansion and other use cases.
 
-The transaction nLockTime is used to prevent the mining of a transaction until a certain date. (in block height or time)
-nSequence will be repurposed to prevent mining of a transaction until a certain age of the spent output. (in blocks or timespan)
-This, among other uses, allows bi-directional payment channels as used in [Hashed Timelock Contracts (HTLCs)](https://github.com/ElementsProject/lightning/raw/master/doc/deployable-lightning.pdf) and [BIP112](https://github.com/bitcoin/bips/blob/master/bip-0112.mediawiki#Bidirectional_Payment_Channels).
+The transaction nLockTime is used to prevent the mining of a transaction until a certain date. nSequence will be repurposed to prevent mining of a transaction until a certain age of the spent output in blocks or timespan. This, among other uses, allows bi-directional payment channels as used in https://github.com/ElementsProject/lightning/raw/master/doc/deployable-lightning.pdf Hashed Timelock Contracts (HTLCs)] and [https://github.com/bitcoin/bips/blob/master/bip-0112.mediawiki#Bidirectional_Payment_Channels BIP112).
 
 ==Specification==
 
@@ -32,7 +30,7 @@ If bit (1 << 31) of the sequence number is not set, then the sequence number is
 
 The sequence number encoding is interpreted as follows: 
 
-Bit (1 << 22) determines if the relative lock-time is time-based or block based: If the bit is set, it specifies relative lock-time in units of 512 seconds granularity from the median time past of its previous block to the block-time Median Time Past or nTime depending on the enforcement status of BIP113. If the bit is not set, it specifies relative lock-time in blocks.
+Bit (1 << 22) determines if the relative lock-time is time-based or block based: If the bit is set, the relative lock-time specifies a timespan in units of 512 seconds granularity. The timespan starts from the median-time-past (MTP) of the output’s previous block, and ends either at the MTP of the previous block or at the nTime of the transaction’s block (depending on the enforcement status of BIP113). If the bit is not set, the relative lock-time specifies a number of blocks.
 
 Note (1 << 22) was chosen because it is the highest you can go without moving to 4-byte pushes when using the Bitcoin scripting language in conjunction with OP_CHECKSEQUENCEVERIFY: i.e. 3 bytes = 24 bits where pushes are signed integers which leaving 1 bit for the flag and 22 bits for the relative lock-time encoding.
 
@@ -47,11 +45,11 @@ The block produced time is either equals to median time past of its parent or to
 
 When the relative lock-time is block-based, it is interpreted as a minimum block-height constraint over the input's age. A relative block-based lock-time of zero indicates an input which can be included in any block. More generally, a relative block lock-time n can be included n blocks after the mining date of the output it is spending, or any block thereafter.
 
-This is proposed to be accomplished by replacing IsFinalTx() and CheckFinalTx(), existing consensus and non-consensus code functions that return true if a transaction's lock-time constraints are satisfied and false otherwise, with LockTime() and CheckLockTime(), new functions that return a non-zero value if a transaction's lock-time or sequence valuenumber constraints are not satisfied and zero otherwise:
+This is proposed to be accomplished by replacing IsFinalTx() and CheckFinalTx(), existing consensus and non-consensus code functions that return true if a transaction's lock-time constraints are satisfied and false otherwise, with LockTime() and CheckLockTime(), new functions that return a non-zero value if a transaction's lock-time or sequence number constraints are not satisfied and zero otherwise:
 
 
     enum {
-        /* Interpret sequence valuenumbers as relative lock-time constraints. */
+        /* Interpret sequence numbers as relative lock-time constraints. */
         LOCKTIME_VERIFY_SEQUENCE = (1 << 0),
     };
     
@@ -61,7 +59,7 @@ This is proposed to be accomplished by replacing IsFinalTx() and CheckFinalTx(),
     
     /* If this flag set, CTxIn::nSequence is NOT interpreted as a
      * relative lock-time. Setting the most significant bit of a
-     * sequence valuenumber disabled relative lock-time. */
+     * sequence number disabled relative lock-time. */
     static const uint32_t SEQUENCE_LOCKTIME_DISABLED_FLAG = (1 << 31);
     
     /* If CTxIn::nSequence encodes a relative lock-time and this flag
@@ -108,13 +106,13 @@ This is proposed to be accomplished by replacing IsFinalTx() and CheckFinalTx(),
             else
                 fFinalized = false;
     
-            // Do not enforce sequence valuenumbers as a relative lock time
+            // Do not enforce sequence numbers as a relative lock time
             // unless we have been instructed to, and a view has been
             // provided.
             if (!fEnforceBIP68)
                 continue;
     
-            // Sequence valuenumbers with the most significant bit set are not
+            // Sequence numbers with the most significant bit set are not
             // treated as relative lock-times, nor are they given any
             // consensus-enforced meaning at this point.
             if (txin.nSequence & CTxIn::SEQUENCE_LOCKTIME_DISABLED_FLAG)
@@ -143,7 +141,7 @@ This is proposed to be accomplished by replacing IsFinalTx() and CheckFinalTx(),
             }
         }
     
-        // If all sequence valuenumbers are CTxIn::SEQUENCE_FINAL, the
+        // If all sequence numbers are CTxIn::SEQUENCE_FINAL, the
         // transaction is considered final and nLockTime constraints
         // are not enforced.
         if (fFinalized)
@@ -169,7 +167,7 @@ Code conditional on the return value of IsFinalTx() / CheckLockTime() has to be
 
 A bidirectional payment channel can be established by two parties funding a single output in the following way: Alice funds a 1 BTC output which is the 2-of-2 multisig of Alice AND Bob, or Alice's key only after a sufficiently long timeout, e.g. 30 days or 4320 blocks. The channel-generating transaction is signed by Alice and broadcast to the network.
 
-Alice desires to send Bob a payment of 0.1 BTC. She does so by constructing a transaction spending the 1 BTC output and sending 0.1 BTC to Bob and 0.9 BTC back to herself. She provides her signature for the 2-of-2 multisig constraint, and sets a relative lock-time using the sequence valuenumber field such that the transaction will become valid 24-hours or 144 blocks before the refund timeout. Two more times Alice sends Bob a payment of 0.1 BTC, each time generating and signing her half of a transaction spending the 1btc output and sending 0.2 BTC, then 0.3 BTC to Bob with a relative lock-time of 29 days from creation of the channel.
+Alice desires to send Bob a payment of 0.1 BTC. She does so by constructing a transaction spending the 1 BTC output and sending 0.1 BTC to Bob and 0.9 BTC back to herself. She provides her signature for the 2-of-2 multisig constraint, and sets a relative lock-time using the sequence number field such that the transaction will become valid 24-hours or 144 blocks before the refund timeout. Two more times Alice sends Bob a payment of 0.1 BTC, each time generating and signing her half of a transaction spending the 1btc output and sending 0.2 BTC, then 0.3 BTC to Bob with a relative lock-time of 29 days from creation of the channel.
 
 Bob now desires to send Alice a refund of 0.25 BTC. He does so by constructing a transaction spending the 1btc output and sending 0.95 BTC (= 0.7 BTC + 0.25 BTC) to Alice and 0.05 BTC to himself. Since Bob will still have in his logs the transaction giving him 0.7 BTC 29 days after the creation of the channel, Alice demands that this new transaction have a relative lock-time of 28 days so she has a full day to broadcast it before the next transaction matures.
 

From c141645a1f6428ba183c927391efb1d316f45743 Mon Sep 17 00:00:00 2001
From: BtcDrak 
Date: Fri, 20 Nov 2015 16:50:18 +0000
Subject: [PATCH 018/259] Update compatibility section

---
 bip-0068.mediawiki | 16 ++++++++--------
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/bip-0068.mediawiki b/bip-0068.mediawiki
index 44b8a1a0..6d0b1467 100644
--- a/bip-0068.mediawiki
+++ b/bip-0068.mediawiki
@@ -183,7 +183,7 @@ https://github.com/bitcoin/bitcoin/pull/6312
 
 Credit goes to Gregory Maxwell for providing a succinct and clear description of the behavior of this change, which became the basis of this BIP text.
 
-This BIP was edited by BtcDrak and Nicolas Dorier.
+This BIP was edited by BtcDrak, Nicolas Dorier and kinoshitajona.
 
 ==Deployment==
 
@@ -193,20 +193,20 @@ It is recommended to deploy BIP68 and BIP112 at the same time as this BIP.
 
 ==Compatibility==
 
-The only use of sequence valuenumbers by the Bitcoin Core reference client software is to disable checking the nLockTime constraints in a transaction. The semantics of that application are preserved by this BIP.
+The only use of sequence numbers by the Bitcoin Core reference client software is to disable checking the nLockTime constraints in a transaction. The semantics of that application are preserved by this BIP.
 
-There may be other uses for the sequence valuenumber field that are not commonplace or yet to be discovered. To allow for other uses of the sequence valuenumber field, it is only interpreted as a relative lock-time as described in this BIP if the most significant bit is clear. This allows up to 31 bits of the sequence valuenumber field to be used for other purposes in applications which don't simultaneously need a per-input relative lock-time. In addition, the unused low-order bits of the relative lock-time encoding are available for use by future soft-fork extensions.
+As can be seen from the specification section, a number of bits are undefined by this BIP to allow for other use cases by setting bit (1 << 31) as the remaining 31 bits have no meaning under this BIP. Additionally, bits (1 << 23) through (1 << 30) inclusive have no meaning at all when bit (1 << 31) is unset.
 
-The most efficient way to calculate sequence valuenumber from relative lock-time is with bit masks and shifts:
+The most efficient way to calculate sequence number from relative lock-time is with bit masks and shifts:
 
 
     // 0 <= nHeight < 65,535 blocks (1.25 years)
-    nSequence = nHeight << 14;
-    nHeight = nSequence >> 14;
+    nSequence = nHeight;
+    nHeight = nSequence;
     
     // 0 <= nTime < 33,554,431 seconds (1.06 years)
-    nSequence = 1<<30 | (nTime << 5);
-    nTime = (nSequence ^ 1<<30) >> 5;
+    nSequence = (1 << 22) | (nTime >> 9);
+    nTime = (nSequence & 0x0000ffff) << 9;
 

 
 ==References==

From 060c37f6d530881e4e5b06a711244adb2d18a7de Mon Sep 17 00:00:00 2001
From: BtcDrak 
Date: Fri, 20 Nov 2015 17:12:43 +0000
Subject: [PATCH 019/259] Add note about free bits and correct deployment
 recommendations

---
 bip-0068.mediawiki | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/bip-0068.mediawiki b/bip-0068.mediawiki
index 6d0b1467..8077d08c 100644
--- a/bip-0068.mediawiki
+++ b/bip-0068.mediawiki
@@ -189,7 +189,7 @@ This BIP was edited by BtcDrak, Nicolas Dorier and kinoshitajona.
 
 This BIP is to be deployed by either version-bits BIP9 or by isSuperMajority(). Exact details TDB.
 
-It is recommended to deploy BIP68 and BIP112 at the same time as this BIP.
+It is recommended to deploy BIP112 and BIP113 at the same time as this BIP.
 
 ==Compatibility==
 
@@ -197,6 +197,8 @@ The only use of sequence numbers by the Bitcoin Core reference client software i
 
 As can be seen from the specification section, a number of bits are undefined by this BIP to allow for other use cases by setting bit (1 << 31) as the remaining 31 bits have no meaning under this BIP. Additionally, bits (1 << 23) through (1 << 30) inclusive have no meaning at all when bit (1 << 31) is unset.
 
+Additionally, this BIP specifies only 16 bits to actually encode relative lock-time meaning a further 6 are unused (1 << 16 through 1 << 21 inclusive). This allows the possibility to increase granularity by soft-fork, or for increasing the maximum possible relative lock-time in the future.
+
 The most efficient way to calculate sequence number from relative lock-time is with bit masks and shifts:
 
 

From f26cc0c4d35a1a5e4e05802afed7da122dcda672 Mon Sep 17 00:00:00 2001
From: BtcDrak 
Date: Fri, 20 Nov 2015 19:32:36 +0000
Subject: [PATCH 020/259] Clarify (1 << 22) logic

---
 bip-0068.mediawiki | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/bip-0068.mediawiki b/bip-0068.mediawiki
index 8077d08c..fff10927 100644
--- a/bip-0068.mediawiki
+++ b/bip-0068.mediawiki
@@ -32,9 +32,9 @@ The sequence number encoding is interpreted as follows:
 
 Bit (1 << 22) determines if the relative lock-time is time-based or block based: If the bit is set, the relative lock-time specifies a timespan in units of 512 seconds granularity. The timespan starts from the median-time-past (MTP) of the output’s previous block, and ends either at the MTP of the previous block or at the nTime of the transaction’s block (depending on the enforcement status of BIP113). If the bit is not set, the relative lock-time specifies a number of blocks.
 
-Note (1 << 22) was chosen because it is the highest you can go without moving to 4-byte pushes when using the Bitcoin scripting language in conjunction with OP_CHECKSEQUENCEVERIFY: i.e. 3 bytes = 24 bits where pushes are signed integers which leaving 1 bit for the flag and 22 bits for the relative lock-time encoding.
+The flag (1<<22) is the highest order bit in a 3-byte signed integer for use in bitcoin scripts as a 3-byte PUSHDATA with OP_CHECKSEQUENCEVERIFY (BIP 112).
 
-This specification only interprets 16 bits of the sequence number as relative lock-time, so a mask of 0x0000ffff MUST be applied to the sequence field to extract the relative lock-time. This is to allow for future expansion. The specification allows for a year of relative lock-time.
+This specification only interprets 16 bits of the sequence number as relative lock-time, so a mask of 0x0000ffff MUST be applied to the sequence field to extract the relative lock-time. The 16-bit specification allows for a year of relative lock-time and the remaining bits allow for future expansion.
 
 For time based relative lock-time, 512 second granularity was chosen because bitcoin blocks are generated every 600 seconds. So when using block based or time based relative lock-time, the same amount of time can be encoded with the available number of bits. Converting from a sequence number to seconds is performed by multiplying by 512 = 2^9, or equivalently shifting up by 9 bits.
 

From 83fc19d97aa72f1ac83acf799ce854f8eede9504 Mon Sep 17 00:00:00 2001
From: BtcDrak 
Date: Sat, 21 Nov 2015 06:37:07 +0000
Subject: [PATCH 021/259] Improve title, add encoding diagram and small fixup

---
 README.mediawiki      |   4 ++--
 bip-0068.mediawiki    |  12 ++++++++----
 bip-0068/encoding.png | Bin 0 -> 6311 bytes
 3 files changed, 10 insertions(+), 6 deletions(-)
 create mode 100644 bip-0068/encoding.png

diff --git a/README.mediawiki b/README.mediawiki
index 925910c2..3cf21beb 100644
--- a/README.mediawiki
+++ b/README.mediawiki
@@ -267,8 +267,8 @@ Those proposing changes should consider that ultimately consent may rest with th
 | Draft
 |-
 | [[bip-0068.mediawiki|68]]
-| Consensus-enforced transaction replacement signalled via sequence numbers
-| Mark Friedenbach
+| Relative lock-time through consensus-enforced sequence numbers
+| Mark Friedenbach, BtcDrak and Nicolas Dorier
 | Standard
 | Draft
 |-
diff --git a/bip-0068.mediawiki b/bip-0068.mediawiki
index fff10927..414d0740 100644
--- a/bip-0068.mediawiki
+++ b/bip-0068.mediawiki
@@ -1,6 +1,6 @@
 
   BIP: 68
-  Title: Consensus-enforced transaction replacement signaled via sequence numbers (relative lock-time)
+  Title: Relative lock-time through consensus-enforced sequence numbers
   Author: Mark Friedenbach 
           BtcDrak 
           Nicolas Dorier 
@@ -12,13 +12,13 @@
 
 ==Abstract==
 
-This BIP introduces consensus-enforced semantics of the sequence number field to enable a signed transaction input to remain invalid for a defined period of time after confirmation of its corresponding outpoint, for the purpose of supporting consensus-enforced transaction replacement features.
+This BIP introduces consensus-enforced semantics of the sequence number field to enable a signed transaction input to remain invalid for a defined period of time after confirmation of its corresponding outpoint.
 
 ==Motivation==
 
 Bitcoin transactions have a sequence number field for each input. The original idea appears to have been that a transaction in the mempool would be replaced by using the same input with a higher sequence value. Although this was not properly implemented, it assumes miners would prefer higher sequence numbers even if the lower ones were more profitable to mine. However, a miner acting on profit motives alone would break that assumption completely. The change described by this BIP repurposes the sequence number for new use cases without breaking existing functionality. It also leaves room for future expansion and other use cases.
 
-The transaction nLockTime is used to prevent the mining of a transaction until a certain date. nSequence will be repurposed to prevent mining of a transaction until a certain age of the spent output in blocks or timespan. This, among other uses, allows bi-directional payment channels as used in https://github.com/ElementsProject/lightning/raw/master/doc/deployable-lightning.pdf Hashed Timelock Contracts (HTLCs)] and [https://github.com/bitcoin/bips/blob/master/bip-0112.mediawiki#Bidirectional_Payment_Channels BIP112).
+The transaction nLockTime is used to prevent the mining of a transaction until a certain date. nSequence will be repurposed to prevent mining of a transaction until a certain age of the spent output in blocks or timespan. This, among other uses, allows bi-directional payment channels as used in [https://github.com/ElementsProject/lightning/raw/master/doc/deployable-lightning.pdf Hashed Timelock Contracts (HTLCs)] and [https://github.com/bitcoin/bips/blob/master/bip-0112.mediawiki#Bidirectional_Payment_Channels BIP112].
 
 ==Specification==
 
@@ -36,6 +36,8 @@ The flag (1<<22) is the highest order bit in a 3-byte signed integer for use in
 
 This specification only interprets 16 bits of the sequence number as relative lock-time, so a mask of 0x0000ffff MUST be applied to the sequence field to extract the relative lock-time. The 16-bit specification allows for a year of relative lock-time and the remaining bits allow for future expansion.
 
+
+
 For time based relative lock-time, 512 second granularity was chosen because bitcoin blocks are generated every 600 seconds. So when using block based or time based relative lock-time, the same amount of time can be encoded with the available number of bits. Converting from a sequence number to seconds is performed by multiplying by 512 = 2^9, or equivalently shifting up by 9 bits.
 
 When the relative lock-time is time-based, it is interpreted as a minimum block-time constraint over the input's age. A relative time-based lock-time of zero indicates an input which can be included in any block. More generally, a relative time-based lock-time n can be included into any block produced 512 * n seconds after the mining date of the output it is spending, or any block thereafter.
@@ -204,7 +206,7 @@ The most efficient way to calculate sequence number from relative lock-time is w
 
     // 0 <= nHeight < 65,535 blocks (1.25 years)
     nSequence = nHeight;
-    nHeight = nSequence;
+    nHeight = nSequence & 0x0000ffff;
     
     // 0 <= nTime < 33,554,431 seconds (1.06 years)
     nSequence = (1 << 22) | (nTime >> 9);
@@ -216,6 +218,8 @@ The most efficient way to calculate sequence number from relative lock-time is w
 Bitcoin mailing list discussion: https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg07864.html
 
 BIP112: https://github.com/bitcoin/bips/blob/master/bip-0112.mediawiki
+
 BIP113: https://github.com/bitcoin/bips/blob/master/bip-0113.mediawiki
+
 Hashed Timelock Contrats (HTLCs): https://github.com/ElementsProject/lightning/raw/master/doc/deployable-lightning.pdf
 
diff --git a/bip-0068/encoding.png b/bip-0068/encoding.png
new file mode 100644
index 0000000000000000000000000000000000000000..cd7649e0a9c3a29130d51d98f7c7addd9653090c
GIT binary patch
literal 6311
zcmd5=cTiK?w+0(F;HrR1ReBM)2mz%FNC*&`Kxl$UlM-4eQllWCRO!7#NGOTa1SFs$
z2!tXnkrqU00Ru`1y*#{k=FOeCZ|2RsnK$$M%Ve>q;xdFxoh7#LVS{=OK~C0MwQolJfp@O`G43+xve
z6cR5EBrq^s(*|kXGkrQiopuRjcOrNFa!*Mm>*(m*P}g9+asLLJ=9=!MYPN^5Qn6`f
z7Fr)q1f-QmBCGh3XH~0()W&KrU=`
zUv|DA1f4A_`{{PqHOAu%aBiNrP8_e#yqS;fAL!q{4}fFyw^hgehH&;b8irZU|F$=5
zP9E=Hxc_$iW&h*D{{i9ulKj8INeVDYs;z?}&mGBCBLOd?)ajj8mT`R3;ns1s`+8N8@2d_
zD~8JUA^m5VIn!Q3MWv($HgoRDK%toH7L#Q9_th(oA>hJp#U|3l%8|~^9Q&FxleV%Y
zv@6Gs_$D~l`Rd0q)y@BWlP;D1S
z8?eqo5X4k{xCl*9*pPFuZ^B-55mmj
zp+HX)*h;&`st)1d-BKgtQv3Nv>
z+URCZ!TWhC#!_)&Gl%j0rk5t;&CNC06S|W#Gbc3&&HM6m3$xG=aNvwd6KUgYyy&G#
zqsT7^1kR%CTF1@bpPn}zck9&g`j4Xho2!2@rjBci_DyYY-o4QnCng!=)KkZO9!1uM
z=eHSDtV==jO0QJenqzhJGRz)Guk|`piydWLCz`$EgUL4L1H&{G)
z9)Np(Kz^E4oB)qYbFz$TGr*mQ<|8a&d3wM{zVO#^`H}gPennwVAJ4CBQ3TY};P4;VvwOcz};qj+GL*;yCQ!5uA{LG8B^NVk_NMq3LLRP@+l8mNmWYZ>ms-5BEmS$6|%QLCG
zBeK{|%G|PK4pCeuLl5jL)1y{DI>j!2WeQdc>J2=6wXxRsQ|G!_(1b^S>reCEUR#9C
zDAoDfM5*%%Y%GDz!FD3s>DgrgDwpgX4Q;bR8SC45Ge?^maLjHssJkU10B6q*RaSOa
zrGE7^4S2aDpYL?0=oDex1)-2;JZDrd)fx1s4cxx{i+9d==69=98xI$B%~z@2JE+%o
zwt=)1OpG9_SCEbJ#b4;7ytZ*$Gxh`Dv~9k`S)&s>qoi%RlAKm@C55`t26^F@mh7ht
zLIpuSvnW*aC&cVrSA?k=t}`b~2ND@X->;{Bqt6PXrrzxN*SC)_9n#0JE_cDXG7vi+
zxK^Y%?roo(lFeiB_1kGVIf!~7mJ%n{0r;hkTRlJ)R@&}&ja)JTvs3Iudv19}nN_0R
z=#d9h>TLLgbe^lUAX~QB8#6U$2)pqGLN{$yoluv^c<8Wy3N{Tk61eZH9}&-@~_^n%I>}a@)_>
zZ0M?pL$nc%-xJ3gPv&*dQF5S)b|P$gMYQkxhlKbx_Q(E%IH8G5R|{Xz6v#_LTitSQb-NVXPF3&0!(J$6mHrvE4f`?0)S(nDpjs7cTHM$jsvn`Hk
zZSDnUaIKr?c$zFdFYx4jF^e3P)P;flvJWSu@xf
zG8fLCg*@~1Kh%$2XP@&kzhg(K7!ZTp6X#m85-EtK_W64bp9#CY2$ekil~PgDl5QSp
zK4e0+g{pSdSNnvWUeUa8rV@nhQG}6{CR)OKz0RzZG@eAiW-qhyF-}Qo*fM1yoP0*0
z#k!S$V0=h@&`Kue1h(J`{AH@
zQ`tQA=POY|pCa@Xeo
z-tg^>rZ1~0UAVSVhvB(|-b`8MuHhK@bwSS15ZKzhMs&M5^mlGIuhGhvnv?_#XU-^(ko$tdpa5MC-cZ{y2Ubjn*AW1GrLDnnq9
zz@$fD-f1(lM(e`14I~-d0y30*3zP~x?Nh7jq_pyKXX{0KmUYQ~f}lXpDJ_5uz65pkgosF55X86c(
zmxp#wqc-9oR<(xGVIxBGJj6*!?mBMCjm_EC8P9+@oe~*Id?l`-!D~U9DNbxf8#O4QWVY9nw4p28UI@X3
zmMnMYw!Qj*%Y+OLsccwa@8@hBdQPheYZqizI8k>V)e#p?FAWT-n33~4&oC%F!fis*
zouOlGi6rT@jU|9il3Km?V4y4J7i*x&(*$VFxS~#mwHRQD{*u!MQgy=!U^Rn48_?{!
z4=)QTv5S@2hWMklR+M@yF`$X^pThZLjqZPhUAg~Atc)s3PqHba)RRAF07WE-iz&j_
zt?3JWr%+Qy2YBeqTO6DWHZZA>{>BgrNAPkfDi)?zO#;G^n$6;Kb$^tmL1A*O4&bOD
z+x?aaS^Y-E12C+qyj$lsN@?Tp<)o>|hsAHC@zwKavVkUfypjz@X_ElPWGEL;KGyB&
zuX7Aae~@}u-#`gH^fE+(hMJlMM#~Lwtx`l*R8W<+7eHMzy%1t2+nRb3(UDktKNAF@3pQI#rsY?CMT8!U%e|`0yvcDaza*@AV9kq!bIWYC(|6!I)-#xh(#M9(p3b0LRbq5~
zR6J4aS8&5LL;oG3?U6+@`0du}@RnU`$!3L%yZQ=n!)*O-4JX-Z%aB|dJQ$AV3!sh_
zyubkPG*EwdQ39`RIO6Mo>mXO~*Lgwz>^hUlK#x(ELBMD7Ry6V;QZL=~N!tLiAbXl^
z(yQ*W7iZ~U(<@l(9Y#xjCXo?^xxr
z+6=9hXI(=tVs+MkW-wJW*&sWB6mo5#=+`NJ@b*U5gBck`tS5paZ^L|X2yfOyc+ke1
zBA+nwjFlhYN%wJb7IELpoAg_s299n%7gEf&(?3XU+YzA|rSI`VxRM+tb8tVt1-FSF
zl^v>39P)h{h{(O(C)4TiVUX&qE>#B6bNaPCf97hN|7qeR8{od+)c^vxpNZx~A%cQj
znq(|rEktqNt^~Z_&w}a?ki`&aNAaZT$9WQS1-tJ*VrD!I9G!Dvz`$JUE1v=Mlk{RH7RJ&i
z50=a>3dzit-MI^q-#ln-mBnU>Nc12F9P1T6QQ*$PSuRzIc(~bd<=M>G92$oPjW?%E
z&56!+aRVKh=&$@qZC58z(Dn+s@88EJlG7xy!}QS-OUbB^pzawpaPERKV!&TqtRxN7
zs;n|^hQ<;>y~>5C6Cz~-6DS9viWR--2(xyulb9D)p1WmVX}S8OMB{2a+Zet|T*)qD
z`Fi=l!_x9dLgT{I)wRA^Mm+JBDI+6eRI8QSK<$TtqdT#3c9t=1W{;ap%O9SMx>MtN
zw2L2WyvURx)l<6L2(qU1*-xXlKBJ(`8L<+Je)YxdMOipe
zF?fo(>5~2QOdRNsxo-((vep6!j%3f7{F~ct~ZTs;!Tn^ULGXi2_mMk
zFaz8)h3NTmW>+RYiSl;?6Vv8f_7Lsjv%|rRm(JgMqct^e-3uHR%O~JMA!(U8Wu_nz
zJG`YThC}{j@Gz!N7X>Wy_V3V3P*T6RAJ{OcI``;*5`6SbN-fGkdEXQtCFGhXKI~DQ_
zTUO{NC14kH7c!|v$(0JZXuf5y5=_%dc5Y9Tb&!wsyY~HHjpRLDSL-ee|u5>UCs4C5|pNO{O1!
zMDX=D4cWE(NY+V!;XwuBB2S-5@s_TWpalM14^Fwfu>bX3)gSGI$QL2%xD!GaMkv2$b{0A-T2iq
zk&u2;+IFUY>Y`k~(lToE$}TcCCatmj$;vD?JA&kx%k8uB-Ci3$qR(4P))PCvIF1|xw-Ykk94;A;rn1*Yc=)+UZ_0ZJZI#&H5s+mxM}n&DU3lKCzWDKJy=k)s(l<~
zUcIeLP|dFDDP1)^(8anfqkDG=dwO)!Vl{Jnv7?Xt39ao_6U^H&8KIfTFs3cBUvE2e
z_P@3J^$wY;Oion_9}Z_^r*4cVIw-bzm8ypCvd}H3O?e{AH$KuQ!hclP#V5<8OeMMX
zz7wGjMdKBN=YXB-S
zqnbedRtohx();AjJoZLAJj&w)5YT*dt$*eX1js7lHa{987wVL#vC3P#S#16njR3YU
z`bjL6)f?pMo+
zb7{oSb~K{lH%_SV;2D{H4(W4IL*#@msx{BK-t2PBIjL7569^FZ+7CYr0lq|$7w*aW
zgHw6{%?sOgBH&NDZC6!kw_I{qvRvhb3l(zhJnSO`OJ6JXUsZ$34w|MLmtGeRe}8sF
zcw$i_1fv5Z6k)*{%bh6PkDjw#S^I3MKM!?A$_=i65Axw`7
zBkW6>KQU|S!7t|z)Ba#rh3h^2FUHzQt-E7ZG>!fX1RsceAiZUDL?cfSPM+TG?r6w{
zeVpSU@;xq)Da3CfUF{@)lEVM|$xQ1ATKuHBpL__Kxh3YiIVhJPBmj_ma6y?|`f}wa
zWnD&cYt)UVvBfEDbd{+0XpF^qE`q+$FMK;TsD~mZ5BK|V^4UtRQ#ft!o(=1I{Qzau
zQtXcM5(yJCh#3tVqBg!6;^(mokI|)3YgT%c&^s!Xs6j-y)!ujg&K;$&jCyMf5rZBI
zk{0z@vFLm{tiZ_N&F*dtEWhU?H%Jmzw?)NI@9MUA3p_FO+?Q0o`)jCy}I0YA3Dt&%$#B<`uO#)>ESzJ
z8;;+~=U)QnpEBpK@%7)*=3fHme;B6y9=`pDh5tQ)|KF4M?%09*!J_%^bQ-K4qhJ8t
LH_$?BJc{@)l{4te

literal 0
HcmV?d00001


From 8ad8cad875842ee9f63eb43216eb7eb7ac02de4d Mon Sep 17 00:00:00 2001
From: BtcDrak 
Date: Sat, 21 Nov 2015 10:52:11 +0000
Subject: [PATCH 022/259] Rename flags in code example to match implementation

---
 bip-0068.mediawiki | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/bip-0068.mediawiki b/bip-0068.mediawiki
index 414d0740..a487392d 100644
--- a/bip-0068.mediawiki
+++ b/bip-0068.mediawiki
@@ -62,12 +62,12 @@ This is proposed to be accomplished by replacing IsFinalTx() and CheckFinalTx(),
     /* If this flag set, CTxIn::nSequence is NOT interpreted as a
      * relative lock-time. Setting the most significant bit of a
      * sequence number disabled relative lock-time. */
-    static const uint32_t SEQUENCE_LOCKTIME_DISABLED_FLAG = (1 << 31);
+    static const uint32_t SEQUENCE_LOCKTIME_DISABLE_FLAG = (1 << 31);
     
     /* If CTxIn::nSequence encodes a relative lock-time and this flag
      * is set, the relative lock-time has units of 512 seconds,
      * otherwise it specifies blocks with a granularity of 1. */
-    static const uint32_t SEQUENCE_LOCKTIME_SECONDS_FLAG = (1 << 22);
+    static const uint32_t SEQUENCE_LOCKTIME_TYPE_FLAG = (1 << 22);
     
     /* If CTxIn::nSequence encodes a relative lock-time, this mask is
      * applied to extract that lock-time from the sequence field. */
@@ -117,7 +117,7 @@ This is proposed to be accomplished by replacing IsFinalTx() and CheckFinalTx(),
             // Sequence numbers with the most significant bit set are not
             // treated as relative lock-times, nor are they given any
             // consensus-enforced meaning at this point.
-            if (txin.nSequence & CTxIn::SEQUENCE_LOCKTIME_DISABLED_FLAG)
+            if (txin.nSequence & CTxIn::SEQUENCE_LOCKTIME_DISABLE_FLAG)
                 continue;
     
             if (prevHeights == NULL)
@@ -125,7 +125,7 @@ This is proposed to be accomplished by replacing IsFinalTx() and CheckFinalTx(),
         
             int nCoinHeight = (*prevHeights)[txinIndex];
         
-            if (txin.nSequence & CTxIn::SEQUENCE_LOCKTIME_SECONDS_FLAG) {
+            if (txin.nSequence & CTxIn::SEQUENCE_LOCKTIME_TYPE_FLAG) {
             
                 int64_t nCoinTime = block.GetAncestor(std::max(nCoinHeight-1, 0))->GetMedianTimePast();
             

From 4048f45316faa85f8327d1febe080c83b72fc2e7 Mon Sep 17 00:00:00 2001
From: BtcDrak 
Date: Mon, 23 Nov 2015 20:21:32 +0000
Subject: [PATCH 023/259] BIP112: Update document to match implementation

---
 bip-0112.mediawiki | 111 +++++++++++++++++++++++++--------------------
 1 file changed, 63 insertions(+), 48 deletions(-)

diff --git a/bip-0112.mediawiki b/bip-0112.mediawiki
index e1a186fc..8821bf52 100644
--- a/bip-0112.mediawiki
+++ b/bip-0112.mediawiki
@@ -21,23 +21,18 @@ being spent.
 
 CHECKSEQUENCEVERIFY redefines the existing NOP3 opcode.
 When executed, the script interpreter continues as if a NOP was executed
-so long as one of the following conditions is met:
+so long as:
 
-  * the transaction's nVersion field is 0 or 1;
-  * the top item on the stack is a value greater than or equal to (1 << 31); or
-  * the top item on the stack and the transaction input's sequence number are both relative lock-times of the same units, and the relative lock-time represented by the sequence number is greater than or equal to the relative lock-time represented by the top item on the stack.
+* the top item on the stack is greater than or equal to 0; and
+* the top item on the stack does not have disable flag (1 << 31) set; and
+* the transaction version is 2 or above; and
+* the transaction input's sequence number does not have the disable flag (1 << 31) set; and
+* the top item on the stack and the transaction input's sequence number are both relative lock-times of the same type, and sequence number is greater than or equal to the top item on the stack.
 
 Otherwise, script execution terminates with an error.
 
-BIP 68's redefinition of nSequence prevents a non-final transaction
-from being selected for inclusion in a block until the corresponding
-input has reached the specified age, as measured in block height or
-block time. By comparing the argument to CHECKSEQUENCEVERIFY against
-the nSequence field, we indirectly verify a desired minimum age of the
-the output being spent; until that relative age has been reached any
-script execution pathway including the CHECKSEQUENCEVERIFY will fail
-to validate, causing the transaction not to be selected for inclusion
-in a block.
+BIP 68 prevents a non-final transaction from being selected for inclusion in a block until the corresponding input has reached the specified age, as measured in block-height or block-time. By comparing the argument to CHECKSEQUENCEVERIFY against the nSequence field, we indirectly verify a desired minimum age of the
+the output being spent; until that relative age has been reached any script execution pathway including the CHECKSEQUENCEVERIFY will fail to validate, causing the transaction not to be selected for inclusion in a block.
 
 
 ==Motivation==
@@ -100,7 +95,7 @@ Some more specific applications of this idea:
 
 ====Hash Time-Locked Contracts====
 
-Hash Time-Locked Contracts (HTLCs) provide a general mechanism for offchain contract negotiation. An execution pathway can be made to require knowledge of a secret (a hash preimage) that can be presented within an invalidation time window. By sharing the secret it is possible to guarantee to the counterparty that the transaction will never be broadcast since this would allow the counterparty to claim the output immediately while one would have to wait for the time window to pass. If the secret has not been shared, the counterparty will be unable to use the instant pathway and the delayed pathway must be used instead.
+Hash Time-Locked Contracts (HTLCs) provide a general mechanism for off-chain contract negotiation. An execution pathway can be made to require knowledge of a secret (a hash preimage) that can be presented within an invalidation time window. By sharing the secret it is possible to guarantee to the counterparty that the transaction will never be broadcast since this would allow the counterparty to claim the output immediately while one would have to wait for the time window to pass. If the secret has not been shared, the counterparty will be unable to use the instant pathway and the delayed pathway must be used instead.
 
 ====Bidirectional Payment Channels====
 
@@ -166,7 +161,7 @@ This form of transaction would mean that if the anchor is unspent on
 2015/12/16, Alice can use this commitment even if it has been revoked,
 simply by spending it immediately, giving no time for Bob to claim it.
 
-Ths means that the channel has a deadline that cannot be pushed
+This means that the channel has a deadline that cannot be pushed
 back without hitting the blockchain; and also that funds may not be
 available until the deadline is hit. CHECKSEQUENCEVERIFY allows you
 to avoid making such a tradeoff.
@@ -234,15 +229,19 @@ Refer to the reference implementation, reproduced below, for the precise
 semantics and detailed rationale for those semantics.
 
     
-    /* Threshold for nSequence: below this value it is interpreted
-     * as a relative lock-time, otherwise ignored. */
-    static const uint32_t SEQUENCE_LOCKTIME_THRESHOLD = (1 << 31);
+    /* If this flag set, CTxIn::nSequence is NOT interpreted as a
+     * relative lock-time. */
+    static const uint32_t SEQUENCE_LOCKTIME_DISABLE_FLAG = (1 << 31);
     
-    /* Threshold for nSequence when interpreted as a relative
-     * lock-time: below this value it has units of blocks, otherwise
-     * seconds. */
-    static const uint32_t SEQUENCE_UNITS_THRESHOLD = (1 << 30);
+    /* If CTxIn::nSequence encodes a relative lock-time and this flag
+     * is set, the relative lock-time has units of 512 seconds,
+     * otherwise it specifies blocks with a granularity of 1. */
+    static const uint32_t SEQUENCE_LOCKTIME_TYPE_FLAG = (1 << 22);
     
+    /* If CTxIn::nSequence encodes a relative lock-time, this mask is
+     * applied to extract that lock-time from the sequence field. */
+    static const uint32_t SEQUENCE_LOCKTIME_MASK = 0x0000ffff;
+   
     case OP_NOP3:
     {
         if (!(flags & SCRIPT_VERIFY_CHECKSEQUENCEVERIFY)) {
@@ -252,10 +251,10 @@ semantics and detailed rationale for those semantics.
             }
             break;
         }
-        
+    
         if (stack.size() < 1)
             return set_error(serror, SCRIPT_ERR_INVALID_STACK_OPERATION);
-        
+     
         // Note that elsewhere numeric opcodes are limited to
         // operands in the range -2**31+1 to 2**31-1, however it is
         // legal for opcodes to produce results exceeding that
@@ -266,23 +265,24 @@ semantics and detailed rationale for those semantics.
         // to 5-byte bignums, which are good until 2**39-1, well
         // beyond the 2**32-1 limit of the nSequence field itself.
         const CScriptNum nSequence(stacktop(-1), fRequireMinimal, 5);
-        
+    
         // In the rare event that the argument may be < 0 due to
         // some arithmetic being done first, you can always use
         // 0 MAX CHECKSEQUENCEVERIFY.
         if (nSequence < 0)
             return set_error(serror, SCRIPT_ERR_NEGATIVE_LOCKTIME);
-        
+    
         // To provide for future soft-fork extensibility, if the
-        // operand is too large to be treated as a relative lock-
-        // time, CHECKSEQUENCEVERIFY behaves as a NOP.
-        if (nSequence >= SEQUENCE_LOCKTIME_THRESHOLD)
+        // operand has the disabled lock-time flag set,
+        // CHECKSEQUENCEVERIFY behaves as a NOP.
+        if ((nSequence & CTxIn::SEQUENCE_LOCKTIME_DISABLE_FLAG) != 0)
             break;
-        
-        // Actually compare the specified sequence number with the input.
+    
+        // Actually compare the specified inverse sequence number
+        // with the input.
         if (!checker.CheckSequence(nSequence))
             return set_error(serror, SCRIPT_ERR_UNSATISFIED_LOCKTIME);
-        
+    
         break;
     }
     
@@ -291,38 +291,52 @@ semantics and detailed rationale for those semantics.
         // Relative lock times are supported by comparing the passed
         // in operand to the sequence number of the input.
         const int64_t txToSequence = (int64_t)txTo->vin[nIn].nSequence;
-        
+    
         // Fail if the transaction's version number is not set high
         // enough to trigger BIP 68 rules.
         if (static_cast(txTo->nVersion) < 2)
             return false;
-        
-        // Sequence numbers above SEQUENCE_LOCKTIME_THRESHOLD
-        // are not consensus constrained. Testing that the transaction's
-        // sequence number is not above this threshold prevents
-        // using this property to get around a CHECKSEQUENCEVERIFY
-        // check.
-        if (txToSequence >= SEQUENCE_LOCKTIME_THRESHOLD)
+    
+        // Sequence numbers with their most significant bit set are not
+        // consensus constrained. Testing that the transaction's sequence
+        // number do not have this bit set prevents using this property
+        // to get around a CHECKSEQUENCEVERIFY check.
+        if (txToSequence & CTxIn::SEQUENCE_LOCKTIME_DISABLE_FLAG)
             return false;
+    
+        // Mask off any bits that do not have consensus-enforced meaning
+        // before doing the integer comparisons of ::VerifySequence.
+        const uint32_t nLockTimeMask = CTxIn::SEQUENCE_LOCKTIME_TYPE_FLAG
+                                     | CTxIn::SEQUENCE_LOCKTIME_MASK;
         
-        // There are two kinds of nSequence: lock-by-blockheight
+        if (!::VerifySequence(txToSequence & nLockTimeMask,
+                              CTxIn::SEQUENCE_LOCKTIME_TYPE_FLAG,
+                              nSequence & nLockTimeMask))
+            return false;
+    
+        return true;
+    }
+    
+    static bool VerifySequence(int64_t txToSequence, int64_t nThreshold, const CScriptNum& nSequence)
+    {
+        // There are two kinds of nLockTime: lock-by-blockheight
         // and lock-by-blocktime, distinguished by whether
-        // nSequence < SEQUENCE_UNITS_THRESHOLD.
+        // nSequence < nThreshold (CTxIn::SEQUENCE_LOCKTIME_TYPE_FLAG).
         //
         // We want to compare apples to apples, so fail the script
         // unless the type of nSequence being tested is the same as
         // the nSequence in the transaction.
         if (!(
-            (txToSequence <  SEQUENCE_UNITS_THRESHOLD && nSequence <  SEQUENCE_UNITS_THRESHOLD) ||
-            (txToSequence >= SEQUENCE_UNITS_THRESHOLD && nSequence >= SEQUENCE_UNITS_THRESHOLD)
+            (txToSequence <  nThreshold && nSequence <  nThreshold) ||
+            (txToSequence >= nThreshold && nSequence >= nThreshold)
         ))
             return false;
-        
+    
         // Now that we know we're comparing apples-to-apples, the
         // comparison is a simple numeric one.
-        if (txTo->vin[nIn].nSequence > txToSequence)
+        if (nSequence > txToSequence)
             return false;
-        
+    
         return true;
     }
 
@@ -367,7 +381,7 @@ done by Peter Todd for the closely related BIP 65.
 
 BtcDrak authored this BIP document.
 
-Thanks to Eric Lombrozo and Anthony Towns for contributing example usecases.
+Thanks to Eric Lombrozo and Anthony Towns for contributing example use cases.
 
 
 ==References==
@@ -397,3 +411,4 @@ Thanks to Eric Lombrozo and Anthony Towns for contributing example usecases.
 
 This document is placed in the public domain.
 
+

From 565cc313a612595b7677af713eacdef8abc9a0a2 Mon Sep 17 00:00:00 2001
From: Michael Goldstein 
Date: Mon, 23 Nov 2015 15:14:59 -0600
Subject: [PATCH 024/259] fix typo

---
 bip-0047.mediawiki | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/bip-0047.mediawiki b/bip-0047.mediawiki
index 8247e001..e460a12d 100644
--- a/bip-0047.mediawiki
+++ b/bip-0047.mediawiki
@@ -175,7 +175,7 @@ If Alice does not want her payment to Bob to be associated with her identity, sh
 
 ====Cold Storage====
 
-* Unlike traditional watching-only wallets, those associated with payment codes help in cold storage can not detect incoming payments immediately.
+* Unlike traditional watching-only wallets, those associated with payment codes held in cold storage can not detect incoming payments immediately.
 * When the watching-only wallet detects an incoming notification transaction, it packages the transaction in an implementation-specific format suitable for transfer to the offline device.
 * The offline device recovers the payment code, then pre-generates a large number of relevant keypairs (example: 10000) in order to minimize the need for air gap round trips.
 * The offline device then packages the relevant public keys in an implementation-specific format suitable for transfer to the online device.

From 421c88ca2ee105e042c7e5eadb8b0012ffe7196b Mon Sep 17 00:00:00 2001
From: XBTdev 
Date: Tue, 24 Nov 2015 00:54:04 -0800
Subject: [PATCH 025/259] add copay link to bip44 compatible wallets list

add copay link to bip44 compatible wallets list
---
 bip-0044.mediawiki | 1 +
 1 file changed, 1 insertion(+)

diff --git a/bip-0044.mediawiki b/bip-0044.mediawiki
index 847eb9eb..f9d12549 100644
--- a/bip-0044.mediawiki
+++ b/bip-0044.mediawiki
@@ -265,6 +265,7 @@ is required. This can be done [[https://github.com/satoshilabs/docs/blob/master/
 * [[https://mytrezor.com|myTREZOR web wallet]] ([[https://github.com/trezor/webwallet|source]])
 * [[https://play.google.com/store/apps/details?id=com.bonsai.wallet32|Wallet32 @ Android]] ([[https://github.com/ksedgwic/Wallet32|source]])
 * [[https://play.google.com/store/apps/details?id=com.mycelium.wallet|Mycelium Bitcoin Wallet (Android)]] ([[https://github.com/mycelium-com/wallet|source]])
+* [[https://copay.io/|Copay]] ([[https://github.com/bitpay/copay|source]])
 * [[https://maza.club/encompass|Encompass]] ([[https://github.com/mazaclub/encompass|source]])
 
 ==Reference==

From d30f1c6d0b02f1c22086852e274b3c4ba98d2434 Mon Sep 17 00:00:00 2001
From: BtcDrak 
Date: Tue, 24 Nov 2015 13:08:54 +0000
Subject: [PATCH 026/259] More clearly define script execution failure pathway

---
 bip-0112.mediawiki | 26 +++++++++++++-------------
 1 file changed, 13 insertions(+), 13 deletions(-)

diff --git a/bip-0112.mediawiki b/bip-0112.mediawiki
index 8821bf52..db5147d3 100644
--- a/bip-0112.mediawiki
+++ b/bip-0112.mediawiki
@@ -20,16 +20,16 @@ being spent.
 ==Summary==
 
 CHECKSEQUENCEVERIFY redefines the existing NOP3 opcode.
-When executed, the script interpreter continues as if a NOP was executed
-so long as:
+When executed, if any of the following conditions are true, the script interpreter will terminate with an error:
 
-* the top item on the stack is greater than or equal to 0; and
-* the top item on the stack does not have disable flag (1 << 31) set; and
-* the transaction version is 2 or above; and
-* the transaction input's sequence number does not have the disable flag (1 << 31) set; and
-* the top item on the stack and the transaction input's sequence number are both relative lock-times of the same type, and sequence number is greater than or equal to the top item on the stack.
+* the top item on the stack is less than 0; or
+* the top item on the stack has the disable flag (1 << 31) unset; and
+** the transaction version is less than 2; or
+** the transaction input sequence number disable flag (1 << 31) is set; and
+** the relative lock-time type is not the same; or
+** the top stack item is greater than the transaction sequence (when masked according to the BIP68);
 
-Otherwise, script execution terminates with an error.
+Otherwise, script execution will continue as if a NOP had been executed.
 
 BIP 68 prevents a non-final transaction from being selected for inclusion in a block until the corresponding input has reached the specified age, as measured in block-height or block-time. By comparing the argument to CHECKSEQUENCEVERIFY against the nSequence field, we indirectly verify a desired minimum age of the
 the output being spent; until that relative age has been reached any script execution pathway including the CHECKSEQUENCEVERIFY will fail to validate, causing the transaction not to be selected for inclusion in a block.
@@ -196,9 +196,9 @@ and correspondingly in Bob's commitment transaction:
    ELSE
         EQUAL
        IF
+           "24h" CHECKSEQUENCEVERIFY DROP
            DUP HASH160  CHECKSIGVERIFY
        ELSE
-           "24h" CHECKSEQUENCEVERIFY DROP
            "2015/10/20 10:33" CHECKLOCKTIMEVERIFY DROP
            DUP HASH160  CHECKSIGVERIFY
        ENDIF
@@ -298,13 +298,13 @@ semantics and detailed rationale for those semantics.
             return false;
     
         // Sequence numbers with their most significant bit set are not
-        // consensus constrained. Testing that the transaction's sequence
+        // defined by BIP68. Testing that the transaction's sequence
         // number do not have this bit set prevents using this property
         // to get around a CHECKSEQUENCEVERIFY check.
         if (txToSequence & CTxIn::SEQUENCE_LOCKTIME_DISABLE_FLAG)
             return false;
     
-        // Mask off any bits that do not have consensus-enforced meaning
+        // Mask off any bits that do not have BIP68 consensus-enforced meaning
         // before doing the integer comparisons of ::VerifySequence.
         const uint32_t nLockTimeMask = CTxIn::SEQUENCE_LOCKTIME_TYPE_FLAG
                                      | CTxIn::SEQUENCE_LOCKTIME_MASK;
@@ -365,7 +365,7 @@ related proposals for improving Bitcoin's lock-time capabilities, including:
 OP_CHECKLOCKTIMEVERIFY, 
 
 [https://github.com/bitcoin/bips/blob/master/bip-0068.mediawiki BIP 68]: 
-Consensus-enforced transaction replacement signalled via sequence numbers,
+Relative lock-time through consensus-enforced sequence numbers,
 
 and [https://github.com/bitcoin/bips/blob/master/bip-0113.mediawiki BIP 113]: 
 Median-Past-Time-Lock.
@@ -386,7 +386,7 @@ Thanks to Eric Lombrozo and Anthony Towns for contributing example use cases.
 
 ==References==
 
-[https://github.com/bitcoin/bips/blob/master/bip-0068.mediawiki BIP 68] Consensus-enforced transaction replacement signalled via sequence numbers
+[https://github.com/bitcoin/bips/blob/master/bip-0068.mediawiki BIP 68] Relative lock-time through consensus-enforced sequence numbers
 
 [https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki BIP 65] OP_CHECKLOCKTIMEVERIFY
 

From 8d85335f2a09413e3d365b0e329e2c22f879af30 Mon Sep 17 00:00:00 2001
From: BtcDrak 
Date: Tue, 24 Nov 2015 17:44:54 +0000
Subject: [PATCH 027/259] Fixup comment

---
 bip-0112.mediawiki | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/bip-0112.mediawiki b/bip-0112.mediawiki
index db5147d3..fd89e614 100644
--- a/bip-0112.mediawiki
+++ b/bip-0112.mediawiki
@@ -278,8 +278,7 @@ semantics and detailed rationale for those semantics.
         if ((nSequence & CTxIn::SEQUENCE_LOCKTIME_DISABLE_FLAG) != 0)
             break;
     
-        // Actually compare the specified inverse sequence number
-        // with the input.
+        // Compare the specified sequence number with the input.
         if (!checker.CheckSequence(nSequence))
             return set_error(serror, SCRIPT_ERR_UNSATISFIED_LOCKTIME);
     

From 0026fcb929c430c9211631aa9277d417c532bb34 Mon Sep 17 00:00:00 2001
From: BtcDrak 
Date: Wed, 25 Nov 2015 18:48:39 +0000
Subject: [PATCH 028/259] Use optimised script examples

Taken from 20/11/15 version of deployable lightning
---
 bip-0112.mediawiki | 50 +++++++++++++++++++++++-----------------------
 1 file changed, 25 insertions(+), 25 deletions(-)

diff --git a/bip-0112.mediawiki b/bip-0112.mediawiki
index fd89e614..592fb5f7 100644
--- a/bip-0112.mediawiki
+++ b/bip-0112.mediawiki
@@ -137,11 +137,12 @@ A simple output, paying to Alice might then look like:
 
     HASH160  EQUAL
     IF
-        DUP HASH160  CHECKSIGVERIFY
+        
     ELSE
-        "24h" CHECKSEQUENCEVERIFY
-        DUP HASH160  CHECKSIGVERIFY
+        "24h" CHECKSEQUENCEVERIFY DROP
+        
     ENDIF
+    CHECKSIG
 
 This allows Alice to publish the latest commitment transaction at any
 time and spend the funds after 24 hours, but also ensures that if Alice
@@ -151,11 +152,12 @@ With CHECKLOCKTIMEVERIFY, this would look like:
 
     HASH160  EQUAL
     IF
-        DUP HASH160  CHECKSIGVERIFY
+        
     ELSE
-        "2015/12/15" CHECKLOCKTIMEVERIFY
-        DUP HASH160  CHECKSIGVERIFY
+        "2015/12/15" CHECKLOCKTIMEVERIFY DROP
+        
     ENDIF
+    CHECKSIG
 
 This form of transaction would mean that if the anchor is unspent on
 2015/12/16, Alice can use this commitment even if it has been revoked,
@@ -174,35 +176,33 @@ delay, and the entire output can be claimed by the other party if the
 revocation secret is known. With CHECKSEQUENCEVERIFY, a HTLC payable to
 Alice might look like the following in Alice's commitment transaction:
 
-    HASH160 DUP  EQUAL
+    HASH160 DUP  EQUAL
     IF
-        DROP DUP HASH160  CHECKSIGVERIFY
+        "24h" CHECKSEQUENCEVERIFY
+        2DROP
+        
     ELSE
-         EQUAL
-        IF
-            "24h" CHECKSEQUENCEVERIFY DROP
-            DUP HASH160  CHECKSIGVERIFY
-        ELSE
-            "2015/10/20 10:33" CHECKLOCKTIMEVERIFY DROP
-            DUP HASH160  CHECKSIGVERIFY
+         EQUAL
+        NOTIF
+            "24h" CHECKLOCKTIMEVERIFY DROP
         ENDIF
+        
     ENDIF
+    CHECKSIG
 
 and correspondingly in Bob's commitment transaction:
 
-   HASH160 DUP  EQUAL
+   HASH160 DUP  EQUAL
+   SWAP  EQUAL ADD
    IF
-       DROP DUP HASH160  CHECKSIGVERIFY
+       
    ELSE
-        EQUAL
-       IF
-           "24h" CHECKSEQUENCEVERIFY DROP
-           DUP HASH160  CHECKSIGVERIFY
-       ELSE
-           "2015/10/20 10:33" CHECKLOCKTIMEVERIFY DROP
-           DUP HASH160  CHECKSIGVERIFY
-       ENDIF
+       "2015/10/20 10:33" CHECKLOCKTIMEVERIFY
+       "24h" CHECKSEQUENCEVERIFY
+       2DROP
+       
    ENDIF
+   CHECKSIG
 
 Note that both CHECKSEQUENCEVERIFY and CHECKLOCKTIMEVERIFY are used in the
 final branch of above to ensure Bob cannot spend the output until after both

From 86d135825603f64c6b03df86a356f98969b811d3 Mon Sep 17 00:00:00 2001
From: BtcDrak 
Date: Wed, 25 Nov 2015 18:53:09 +0000
Subject: [PATCH 029/259] Update deployment to be TBD

---
 bip-0112.mediawiki | 19 ++-----------------
 1 file changed, 2 insertions(+), 17 deletions(-)

diff --git a/bip-0112.mediawiki b/bip-0112.mediawiki
index 592fb5f7..1c535611 100644
--- a/bip-0112.mediawiki
+++ b/bip-0112.mediawiki
@@ -349,25 +349,10 @@ https://github.com/bitcoin/bitcoin/pull/6564
 
 ==Deployment==
 
-We reuse the double-threshold switchover mechanism from BIPs 34 and
-66, with the same thresholds, but for nVersion = 4. The new rules are
-in effect for every block (at height H) with nVersion = 4 and at least
-750 out of 1000 blocks preceding it (with heights H-1000..H-1) also
-have nVersion = 4. Furthermore, when 950 out of the 1000 blocks
-preceding a block do have nVersion = 4, nVersion = 3 blocks become
-invalid, and all further blocks enforce the new rules.
+This BIP is to be deployed by either version-bits BIP9 or by isSuperMajority(). Exact details TDB.
 
-It is recommended that this soft-fork deployment trigger include other 
-related proposals for improving Bitcoin's lock-time capabilities, including:
+It is recommended to deploy BIP68 and BIP113 at the same time as this BIP.
 
-[https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki BIP 65]: 
-OP_CHECKLOCKTIMEVERIFY, 
-
-[https://github.com/bitcoin/bips/blob/master/bip-0068.mediawiki BIP 68]: 
-Relative lock-time through consensus-enforced sequence numbers,
-
-and [https://github.com/bitcoin/bips/blob/master/bip-0113.mediawiki BIP 113]: 
-Median-Past-Time-Lock.
 
 ==Credits==
 

From 7abd7509887e5d0420eb28bf7e02542bfc5c02fc Mon Sep 17 00:00:00 2001
From: Dionysis Zindros 
Date: Sat, 28 Nov 2015 04:27:46 +0200
Subject: [PATCH 030/259] Fix small typo in BIP 0016

---
 bip-0016.mediawiki | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/bip-0016.mediawiki b/bip-0016.mediawiki
index 0a539fc2..4c2a524e 100644
--- a/bip-0016.mediawiki
+++ b/bip-0016.mediawiki
@@ -98,7 +98,7 @@ If a majority of hashing power does not support the new validation rules, then r
 
 ===520-byte limitation on serialized script size===
 
-As a consequence of the requirement for backwards compatiblity the serialized script is itself subject to the same rules as any other PUSHDATA operation, including the rule that no data greater than 520 bytes may be pushed to the stack. Thus is it not possible to spend a P2SH output if the redemption script it refers to is >520 bytes in length. For instance while the OP_CHECKMULTISIG opcode can itself accept up to 20 pubkeys, with 33-byte compressed pubkeys it is only possible to spend a P2SH output requiring a maximum of 15 pubkeys to redeem: 3 bytes + 15 pubkeys * 34 bytes/pubkey = 513 bytes.
+As a consequence of the requirement for backwards compatiblity the serialized script is itself subject to the same rules as any other PUSHDATA operation, including the rule that no data greater than 520 bytes may be pushed to the stack. Thus it is not possible to spend a P2SH output if the redemption script it refers to is >520 bytes in length. For instance while the OP_CHECKMULTISIG opcode can itself accept up to 20 pubkeys, with 33-byte compressed pubkeys it is only possible to spend a P2SH output requiring a maximum of 15 pubkeys to redeem: 3 bytes + 15 pubkeys * 34 bytes/pubkey = 513 bytes.
 
 
 ==Reference Implementation==

From 94820a96b5cefc06c1bb05493a111c47faf778b9 Mon Sep 17 00:00:00 2001
From: Eric Lombrozo 
Date: Sat, 28 Nov 2015 16:32:08 -0500
Subject: [PATCH 031/259] Removed deploytime parameter.

---
 bip-0009.mediawiki | 1 -
 1 file changed, 1 deletion(-)

diff --git a/bip-0009.mediawiki b/bip-0009.mediawiki
index 8cd71aed..98f3f9e6 100644
--- a/bip-0009.mediawiki
+++ b/bip-0009.mediawiki
@@ -23,7 +23,6 @@ Each soft fork deployment is specified by the following parameters (further elab
 
 # The '''bit''' determines which bit in the nVersion field of the block is to be used to signal the soft fork lock-in and activation.
 # The '''threshold''' specifies how many blocks within a single retarget period (2016 blocks) must have the bit set before we lock in the deployment.
-# The '''deploytime''' specifies a time at which the bit starts counting towards lock-in.
 # The '''timeout''' specifies a time at which the deployment is considered failed. If the median time of a block >= timeout and the soft fork has not yet locked in (including this block's bit state), the deployment is considered failed on all descendants of the block.
 
 ===Mechanism===

From a8e0d0f4c77f9e3002da7d4e9c6d4671d0dffa01 Mon Sep 17 00:00:00 2001
From: BtcDrak 
Date: Sat, 28 Nov 2015 22:30:58 +0000
Subject: [PATCH 032/259] Small fixup

---
 bip-0068.mediawiki | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/bip-0068.mediawiki b/bip-0068.mediawiki
index a487392d..02bc2a4e 100644
--- a/bip-0068.mediawiki
+++ b/bip-0068.mediawiki
@@ -1,6 +1,6 @@
 
   BIP: 68
-  Title: Relative lock-time through consensus-enforced sequence numbers
+  Title: Relative lock-time using consensus-enforced sequence numbers
   Author: Mark Friedenbach 
           BtcDrak 
           Nicolas Dorier 
@@ -12,7 +12,7 @@
 
 ==Abstract==
 
-This BIP introduces consensus-enforced semantics of the sequence number field to enable a signed transaction input to remain invalid for a defined period of time after confirmation of its corresponding outpoint.
+This BIP introduces relative lock-time (RLT) consensus-enforced semantics of the sequence number field to enable a signed transaction input to remain invalid for a defined period of time after confirmation of its corresponding outpoint.
 
 ==Motivation==
 
@@ -38,12 +38,12 @@ This specification only interprets 16 bits of the sequence number as relative lo
 
 
 
-For time based relative lock-time, 512 second granularity was chosen because bitcoin blocks are generated every 600 seconds. So when using block based or time based relative lock-time, the same amount of time can be encoded with the available number of bits. Converting from a sequence number to seconds is performed by multiplying by 512 = 2^9, or equivalently shifting up by 9 bits.
+For time based relative lock-time, 512 second granularity was chosen because bitcoin blocks are generated every 600 seconds. So when using block-based or time-based, the same amount of time can be encoded with the available number of bits. Converting from a sequence number to seconds is performed by multiplying by 512 = 2^9, or equivalently shifting up by 9 bits.
 
 When the relative lock-time is time-based, it is interpreted as a minimum block-time constraint over the input's age. A relative time-based lock-time of zero indicates an input which can be included in any block. More generally, a relative time-based lock-time n can be included into any block produced 512 * n seconds after the mining date of the output it is spending, or any block thereafter.
-The mining date of the output is equals to the Median Time Past of the previous block which mined it.
+The mining date of the output is equals to the median-time-past of the previous block which mined it.
 
-The block produced time is either equals to median time past of its parent or to its nTime field, depending on the state of BIP113 (MTP).
+The block produced time is either equals to median time past of its parent or to its nTime field, depending on the state of BIP113 median-time-past.
 
 When the relative lock-time is block-based, it is interpreted as a minimum block-height constraint over the input's age. A relative block-based lock-time of zero indicates an input which can be included in any block. More generally, a relative block lock-time n can be included n blocks after the mining date of the output it is spending, or any block thereafter.
 

From ac4cd1d46cf64b67f6d2d4376119a7d18728ce4b Mon Sep 17 00:00:00 2001
From: jl2012 
Date: Tue, 1 Dec 2015 01:47:16 +0800
Subject: [PATCH 033/259] Corrections with the conditions for script failure

---
 bip-0112.mediawiki | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/bip-0112.mediawiki b/bip-0112.mediawiki
index c7ee45e8..643c6176 100644
--- a/bip-0112.mediawiki
+++ b/bip-0112.mediawiki
@@ -22,10 +22,11 @@ being spent.
 CHECKSEQUENCEVERIFY redefines the existing NOP3 opcode.
 When executed, if any of the following conditions are true, the script interpreter will terminate with an error:
 
+* the stack is empty; or
 * the top item on the stack is less than 0; or
 * the top item on the stack has the disable flag (1 << 31) unset; and
 ** the transaction version is less than 2; or
-** the transaction input sequence number disable flag (1 << 31) is set; and
+** the transaction input sequence number disable flag (1 << 31) is set; or
 ** the relative lock-time type is not the same; or
 ** the top stack item is greater than the transaction sequence (when masked according to the BIP68);
 

From bd5e1ead70eed7aa3cb9398be73e761e96b36678 Mon Sep 17 00:00:00 2001
From: Chris Priest 
Date: Mon, 30 Nov 2015 16:40:31 -0800
Subject: [PATCH 034/259] added txver2

---
 bip-tx-ver2.mediawiki | 32 ++++++++++++++++++++++++++++++++
 1 file changed, 32 insertions(+)
 create mode 100644 bip-tx-ver2.mediawiki

diff --git a/bip-tx-ver2.mediawiki b/bip-tx-ver2.mediawiki
new file mode 100644
index 00000000..10517232
--- /dev/null
+++ b/bip-tx-ver2.mediawiki
@@ -0,0 +1,32 @@
+
+  BIP: 122
+  Title: Transaction Version 2 Specification (wildcard inputs)
+  Author: Chris Priest 
+  Status: Draft
+  Type: Standards Track
+  Created: 2015-11-30
+

+
+==Abstract==
+
+This specification defines a new type of transaction that supplements (not replaces)
+version 1 transactions.
+
+==Motivation==
+
+Version 1 Bitcoin Transactions have one large inefficiency: When you want to spend
+from multiple inputs with the exact same scriptPubKey, you have to list the same
+signature multiple times. This bloats the transaction size and makes it expensive to spend
+from small value inputs.
+
+Because small value inputs are expensive to send, they remain in the UTXO pool
+which full nodes have to keep around. It is believed that long term increase of the UTXO
+set can have negative scaling consequences on the network.
+
+==Specification==
+
+A version 2 transaction is formulated the exact same way as a version 1 transaction
+with one exception: each input is treated as a "wildcard input".
+
+A wildcard input beings the value of all inputs with the exact same scriptPubKey
+in a block lower or equal to the block the wildcard input is confirmed into.

From 71dd5c44e831bf2c87633455291592ef2decae24 Mon Sep 17 00:00:00 2001
From: jl2012 
Date: Wed, 2 Dec 2015 02:03:30 +0800
Subject: [PATCH 035/259] Full description of the behavior of the OP_CLTV

---
 bip-0065.mediawiki | 16 +++++++++++-----
 1 file changed, 11 insertions(+), 5 deletions(-)

diff --git a/bip-0065.mediawiki b/bip-0065.mediawiki
index b48fa759..a960e543 100644
--- a/bip-0065.mediawiki
+++ b/bip-0065.mediawiki
@@ -16,11 +16,17 @@ some point in the future.
 
 ==Summary==
 
-CHECKLOCKTIMEVERIFY redefines the existing NOP2 opcode. When executed it
-compares the top item on the stack to the nLockTime field of the transaction
-containing the scriptSig. If that top stack item is greater than the transaction's
-nLockTime field the script fails immediately, otherwise script evaluation continues
-as though a NOP was executed.
+CHECKLOCKTIMEVERIFY redefines the existing NOP2 opcode. When executed, if
+any of the following conditions are true, the script interpreter will terminate
+with an error:
+
+* the stake is empty; or
+* the top item on the stack is less than 0; or
+* the lock-time type (height vs. timestamp) of the top stake item and the nLockTime field are not the same; or
+* the top stack item is greater than the transaction's nLockTime field; or
+* the nLockTime feature is disabled by setting the nSequence field of the txin to 0xffffffff;
+
+Otherwise, script execution will continue as if a NOP had been executed.
 
 The nLockTime field in a transaction prevents the transaction from being mined
 until either a certain block height, or block time, has been reached. By

From 7576a135dd78e8d5faa88746476e836785e9327d Mon Sep 17 00:00:00 2001
From: "Wladimir J. van der Laan" 
Date: Tue, 1 Dec 2015 21:00:48 +0100
Subject: [PATCH 036/259] Change BIP1 to status Active

From the text: "Some Informational and Process BIPs may also have a
status of "Active" if they are never meant to be completed. E.g. BIP 1
(this BIP)."
---
 bip-0001.mediawiki | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/bip-0001.mediawiki b/bip-0001.mediawiki
index 69010808..7af25cde 100644
--- a/bip-0001.mediawiki
+++ b/bip-0001.mediawiki
@@ -1,7 +1,7 @@
 
   BIP: 1
   Title: BIP Purpose and Guidelines
-  Status: Accepted
+  Status: Active
   Type: Standards Track
   Created: 2011-08-19
 


From a5093f1c4ab36a396644e4a12b64c344a9b95998 Mon Sep 17 00:00:00 2001
From: Chris Priest 
Date: Tue, 1 Dec 2015 13:14:55 -0800
Subject: [PATCH 037/259] added more stuff

---
 bip-tx-ver2.mediawiki | 11 +++++++----
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/bip-tx-ver2.mediawiki b/bip-tx-ver2.mediawiki
index 10517232..71cfa692 100644
--- a/bip-tx-ver2.mediawiki
+++ b/bip-tx-ver2.mediawiki
@@ -15,18 +15,21 @@ version 1 transactions.
 ==Motivation==
 
 Version 1 Bitcoin Transactions have one large inefficiency: When you want to spend
-from multiple inputs with the exact same scriptPubKey, you have to list the same
-signature multiple times. This bloats the transaction size and makes it expensive to spend
-from small value inputs.
+from multiple inputs with the exact same scriptSig, you have to list each
+input separately, along with the same signature multiple times.
+This bloats the transaction size and makes it expensive to spend from small value inputs.
 
 Because small value inputs are expensive to send, they remain in the UTXO pool
 which full nodes have to keep around. It is believed that long term increase of the UTXO
 set can have negative scaling consequences on the network.
 
+If maximum blocksize is made to increase *slower* than the actual number of transactins bitcoin users are sending
+to the network, this problem is projected to get worse.
+
 ==Specification==
 
 A version 2 transaction is formulated the exact same way as a version 1 transaction
 with one exception: each input is treated as a "wildcard input".
 
-A wildcard input beings the value of all inputs with the exact same scriptPubKey
+A wildcard input beings the value of all inputs with the exact same scriptSig
 in a block lower or equal to the block the wildcard input is confirmed into.

From bec0d9e8f64d0194eccca8a38f7a7aba7af913f2 Mon Sep 17 00:00:00 2001
From: Chris Priest 
Date: Wed, 2 Dec 2015 14:44:26 -0800
Subject: [PATCH 038/259] added 'needed to implement' section

---
 bip-tx-ver2.mediawiki | 29 ++++++++++++++++++++++++-----
 1 file changed, 24 insertions(+), 5 deletions(-)

diff --git a/bip-tx-ver2.mediawiki b/bip-tx-ver2.mediawiki
index 71cfa692..14789221 100644
--- a/bip-tx-ver2.mediawiki
+++ b/bip-tx-ver2.mediawiki
@@ -1,5 +1,5 @@
 
-  BIP: 122
+  BIP: (no number)
   Title: Transaction Version 2 Specification (wildcard inputs)
   Author: Chris Priest 
   Status: Draft
@@ -15,7 +15,7 @@ version 1 transactions.
 ==Motivation==
 
 Version 1 Bitcoin Transactions have one large inefficiency: When you want to spend
-from multiple inputs with the exact same scriptSig, you have to list each
+from multiple inputs with the exact same scriptPubKey, you have to list each
 input separately, along with the same signature multiple times.
 This bloats the transaction size and makes it expensive to spend from small value inputs.
 
@@ -23,13 +23,32 @@ Because small value inputs are expensive to send, they remain in the UTXO pool
 which full nodes have to keep around. It is believed that long term increase of the UTXO
 set can have negative scaling consequences on the network.
 
-If maximum blocksize is made to increase *slower* than the actual number of transactins bitcoin users are sending
-to the network, this problem is projected to get worse.
+If maximum blocksize is made to increase *slower* than the actual number of transactions bitcoin users are sending
+to the network, this problem is projected to get worse. In other words, as transaction
+fees increase, the minimum economical value of a spending a UTXO will increase.
 
 ==Specification==
 
 A version 2 transaction is formulated the exact same way as a version 1 transaction
 with one exception: each input is treated as a "wildcard input".
 
-A wildcard input beings the value of all inputs with the exact same scriptSig
+A wildcard input beings the value of all inputs with the exact same scriptPubKey
 in a block lower or equal to the block the wildcard input is confirmed into.
+
+== Changes needed to implement ==
+
+The bitcoin code needs to be modified in three places in order to handle Version 2 Transactions.
+
+1. **Full Node V2 validation** - When a full node receives a V2 transaction, it has to
+   aggregate the value of all the UTXOs in the blockchain older than the input
+   with the same scriptPubKey. If this value is greater than or equal to the
+   amount of all outputs, then that V2 transaction is valid and can be propagated.
+
+2. **Full Node V1 validation** - When a V1 transaction comes in, the code needs to be modified
+   to check if each inut has not been spent by a V2 transaction. If there exist any
+   V2 transaction in the blockchain with the same scriptPubKey *after* that input,
+   then the UTXO has been spent and the transaction is invalid.
+
+3. **Wallet** - The user facing wallet portion of the reference client should notify
+   the user when their wallet contains many UTXOs that qualify it to benefit from
+   a V2 transaction. Wallets should not simply replace V1 transactions with V2 transactions.

From 6f0c335b184f7dce4ac2caee87553f3b8df26112 Mon Sep 17 00:00:00 2001
From: Andy Chase 
Date: Fri, 4 Dec 2015 02:48:43 -0800
Subject: [PATCH 039/259] BIP-0001 Should be labeled as "Process" Type

Previously BIP-0001 listed in its header preamble that is was a "Standards Track"
type proposal. This conflicts with both its own definition of "Standards Track"
proposal as well as the type listed in PEP-0001 of which BIP-0001 is based on.

Defitions of each type of proposal:

A Standards Track BIP describes any change that affects most or all Bitcoin implementations.

An Informational BIP describes a Bitcoin design issue, or provides general guidelines or information to the Bitcoin community, but does not propose a new feature.

A Process BIP describes a process surrounding Bitcoin, or proposes a change to (or an event in) a process.
Specifically: "Any meta-BIP is also considered a Process BIP."

Based on these definitions BIP-0001 should have always been labeled as a "Process" BIP and this patch corrects this.
---
 README.mediawiki   | 2 +-
 bip-0001.mediawiki | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/README.mediawiki b/README.mediawiki
index 7fb41744..b45c17a0 100644
--- a/README.mediawiki
+++ b/README.mediawiki
@@ -16,7 +16,7 @@ Those proposing changes should consider that ultimately consent may rest with th
 | [[bip-0001.mediawiki|1]]
 | BIP Purpose and Guidelines
 | Amir Taaki
-| Standard
+| Process
 | Active
 |-
 | [[bip-0009.mediawiki|9]]
diff --git a/bip-0001.mediawiki b/bip-0001.mediawiki
index 7af25cde..faa80290 100644
--- a/bip-0001.mediawiki
+++ b/bip-0001.mediawiki
@@ -2,7 +2,7 @@
   BIP: 1
   Title: BIP Purpose and Guidelines
   Status: Active
-  Type: Standards Track
+  Type: Process
   Created: 2011-08-19
 

 

From 8dcddf5267417d928fa84831f497eb9074f8deaa Mon Sep 17 00:00:00 2001
From: T Dev D 
Date: Fri, 4 Dec 2015 15:27:39 +0000
Subject: [PATCH 040/259] Add link to BIP47 test vectors

Results obtained upon implementing BIP47 for Samourai Wallet. Payment codes are calculated assuming v1 specification without use of BitMessage. Also assumes notification transaction from Alice to Bob has been sent.
---
 bip-0047.mediawiki | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/bip-0047.mediawiki b/bip-0047.mediawiki
index e460a12d..4b68d5d5 100644
--- a/bip-0047.mediawiki
+++ b/bip-0047.mediawiki
@@ -247,6 +247,10 @@ The sender transmits their payment code in base58 form to the calculated Bitmess
 
 In order to use Bitmessage notification, the recipient must have a Bitmessage client which listens at the address which the senders will derive and is capable of relaying received payment codes to the Bitcoin wallet.
 
+==Test Vectors==
+
+* [[https://gist.github.com/SamouraiDev/6aad669604c5930864bd|BIP47 Reusable Payment Codes Test Vectors]]
+
 ==Reference==
 
 * [[bip-0032.mediawiki|BIP32 - Hierarchical Deterministic Wallets]]

From 3ff75f1ad20ecea54d2db998a9f3218d7baf311e Mon Sep 17 00:00:00 2001
From: Chris Priest 
Date: Fri, 4 Dec 2015 14:32:24 -0800
Subject: [PATCH 041/259] added part about version field

---
 bip-tx-ver2.mediawiki | 46 ++++++++++++++++++++++++++++++++-----------
 1 file changed, 35 insertions(+), 11 deletions(-)

diff --git a/bip-tx-ver2.mediawiki b/bip-tx-ver2.mediawiki
index 14789221..f0a68116 100644
--- a/bip-tx-ver2.mediawiki
+++ b/bip-tx-ver2.mediawiki
@@ -1,6 +1,6 @@
 
   BIP: (no number)
-  Title: Transaction Version 2 Specification (wildcard inputs)
+  Title: "Coalescing Transaction" Specification (wildcard inputs)
   Author: Chris Priest 
   Status: Draft
   Type: Standards Track
@@ -10,13 +10,13 @@
 ==Abstract==
 
 This specification defines a new type of transaction that supplements (not replaces)
-version 1 transactions.
+normal "non coalescing" bitcoin transactions.
 
 ==Motivation==
 
-Version 1 Bitcoin Transactions have one large inefficiency: When you want to spend
+Normal "non-coalescing" Bitcoin Transactions have one large inefficiency: When you want to spend
 from multiple inputs with the exact same scriptPubKey, you have to list each
-input separately, along with the same signature multiple times.
+input separately, along with the same signature multiple times, even though the signature expresses the same information.
 This bloats the transaction size and makes it expensive to spend from small value inputs.
 
 Because small value inputs are expensive to send, they remain in the UTXO pool
@@ -29,7 +29,30 @@ fees increase, the minimum economical value of a spending a UTXO will increase.
 
 ==Specification==
 
-A version 2 transaction is formulated the exact same way as a version 1 transaction
+=== Redefinition of Transaction version ===
+
+First, this bips redefines the version field on transactions. The first four bytes
+are defined as the version number, while the last four bytes are defined as the
+transaction type. Type "0000" denotes normal transactions, and "0001" defines
+coalescing transaction.
+
+Examples:
+
+version 1 transaction with normal inputs:
+`version: 10000000`
+
+version 2 transaction with normal inputs:
+`version: 20000000`
+
+version 2 transaction with coalescing inputs:
+`version: 20000001`
+
+Essentially the last bit in the version field is set to 1 to enable wildcard inputs for all
+inputs present in the transaction.
+
+=== Wildcard inputs ====
+
+A coalescing transaction is formulated the exact same way as a version 1 transaction
 with one exception: each input is treated as a "wildcard input".
 
 A wildcard input beings the value of all inputs with the exact same scriptPubKey
@@ -39,16 +62,17 @@ in a block lower or equal to the block the wildcard input is confirmed into.
 
 The bitcoin code needs to be modified in three places in order to handle Version 2 Transactions.
 
-1. **Full Node V2 validation** - When a full node receives a V2 transaction, it has to
+1. **Full Node Coalescing validation** - When a full node receives a coalescing transaction, it has to
    aggregate the value of all the UTXOs in the blockchain older than the input
    with the same scriptPubKey. If this value is greater than or equal to the
-   amount of all outputs, then that V2 transaction is valid and can be propagated.
+   amount of all outputs, then that coalescing transaction is valid and can be propagated.
 
-2. **Full Node V1 validation** - When a V1 transaction comes in, the code needs to be modified
-   to check if each inut has not been spent by a V2 transaction. If there exist any
-   V2 transaction in the blockchain with the same scriptPubKey *after* that input,
+2. **Full Node Non-Coalescing validation** - When a non-coalescing transaction comes in, the code needs to be modified
+   to check if each input has not been spent by a coalescing transaction. If there exist any
+   coalescing transaction in the blockchain with the same scriptPubKey found in a block *after* that input,
    then the UTXO has been spent and the transaction is invalid.
 
 3. **Wallet** - The user facing wallet portion of the reference client should notify
    the user when their wallet contains many UTXOs that qualify it to benefit from
-   a V2 transaction. Wallets should not simply replace V1 transactions with V2 transactions.
+   a coalescing transaction. Wallets should not simply replace non-coalescing transactions
+   with coalescing transactions in all instances.

From 632bf072521efd394106ff6cb9a13e2210077611 Mon Sep 17 00:00:00 2001
From: Chris Priest 
Date: Fri, 4 Dec 2015 14:34:53 -0800
Subject: [PATCH 042/259] typo

---
 bip-tx-ver2.mediawiki | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/bip-tx-ver2.mediawiki b/bip-tx-ver2.mediawiki
index f0a68116..101842d3 100644
--- a/bip-tx-ver2.mediawiki
+++ b/bip-tx-ver2.mediawiki
@@ -31,7 +31,7 @@ fees increase, the minimum economical value of a spending a UTXO will increase.
 
 === Redefinition of Transaction version ===
 
-First, this bips redefines the version field on transactions. The first four bytes
+First, this BIP redefines the version field on transactions. The first four bytes
 are defined as the version number, while the last four bytes are defined as the
 transaction type. Type "0000" denotes normal transactions, and "0001" defines
 coalescing transaction.

From d982c11f87bfd5fa97b8456c9f98d9c7909a9c00 Mon Sep 17 00:00:00 2001
From: Chris Priest 
Date: Fri, 4 Dec 2015 14:37:51 -0800
Subject: [PATCH 043/259] fixed formatting

---
 bip-tx-ver2.mediawiki | 18 +++++++++---------
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/bip-tx-ver2.mediawiki b/bip-tx-ver2.mediawiki
index 101842d3..b0339547 100644
--- a/bip-tx-ver2.mediawiki
+++ b/bip-tx-ver2.mediawiki
@@ -63,16 +63,16 @@ in a block lower or equal to the block the wildcard input is confirmed into.
 The bitcoin code needs to be modified in three places in order to handle Version 2 Transactions.
 
 1. **Full Node Coalescing validation** - When a full node receives a coalescing transaction, it has to
-   aggregate the value of all the UTXOs in the blockchain older than the input
-   with the same scriptPubKey. If this value is greater than or equal to the
-   amount of all outputs, then that coalescing transaction is valid and can be propagated.
+aggregate the value of all the UTXOs in the blockchain older than the input
+with the same scriptPubKey. If this value is greater than or equal to the
+amount of all outputs, then that coalescing transaction is valid and can be propagated.
 
 2. **Full Node Non-Coalescing validation** - When a non-coalescing transaction comes in, the code needs to be modified
-   to check if each input has not been spent by a coalescing transaction. If there exist any
-   coalescing transaction in the blockchain with the same scriptPubKey found in a block *after* that input,
-   then the UTXO has been spent and the transaction is invalid.
+to check if each input has not been spent by a coalescing transaction. If there exist any
+coalescing transaction in the blockchain with the same scriptPubKey found in a block *after* that input,
+then the UTXO has been spent and the transaction is invalid.
 
 3. **Wallet** - The user facing wallet portion of the reference client should notify
-   the user when their wallet contains many UTXOs that qualify it to benefit from
-   a coalescing transaction. Wallets should not simply replace non-coalescing transactions
-   with coalescing transactions in all instances.
+the user when their wallet contains many UTXOs that qualify it to benefit from
+a coalescing transaction. Wallets should not simply replace non-coalescing transactions
+with coalescing transactions in all instances.

From e97833688dc31c747ff0c3a9105fece26fbfa6e9 Mon Sep 17 00:00:00 2001
From: Chris Priest 
Date: Fri, 4 Dec 2015 14:40:01 -0800
Subject: [PATCH 044/259] removed reference to version 2

---
 bip-tx-ver2.mediawiki | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/bip-tx-ver2.mediawiki b/bip-tx-ver2.mediawiki
index b0339547..f7b59429 100644
--- a/bip-tx-ver2.mediawiki
+++ b/bip-tx-ver2.mediawiki
@@ -60,7 +60,7 @@ in a block lower or equal to the block the wildcard input is confirmed into.
 
 == Changes needed to implement ==
 
-The bitcoin code needs to be modified in three places in order to handle Version 2 Transactions.
+The bitcoin code needs to be modified in three places in order to handle Coalescing Transactions.
 
 1. **Full Node Coalescing validation** - When a full node receives a coalescing transaction, it has to
 aggregate the value of all the UTXOs in the blockchain older than the input

From a07c8b62b30d501efcfee147bf1e69d4619b698d Mon Sep 17 00:00:00 2001
From: Chris Priest 
Date: Fri, 4 Dec 2015 14:40:38 -0800
Subject: [PATCH 045/259] formatting changes

---
 bip-tx-ver2.mediawiki | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/bip-tx-ver2.mediawiki b/bip-tx-ver2.mediawiki
index f7b59429..ca4cf900 100644
--- a/bip-tx-ver2.mediawiki
+++ b/bip-tx-ver2.mediawiki
@@ -39,18 +39,18 @@ coalescing transaction.
 Examples:
 
 version 1 transaction with normal inputs:
-`version: 10000000`
+``version: 10000000``
 
 version 2 transaction with normal inputs:
-`version: 20000000`
+``version: 20000000``
 
 version 2 transaction with coalescing inputs:
-`version: 20000001`
+``version: 20000001``
 
 Essentially the last bit in the version field is set to 1 to enable wildcard inputs for all
 inputs present in the transaction.
 
-=== Wildcard inputs ====
+=== Wildcard inputs ===
 
 A coalescing transaction is formulated the exact same way as a version 1 transaction
 with one exception: each input is treated as a "wildcard input".

From f9d64e782b6ec5b8a8cfed4556791e7dbabf83d5 Mon Sep 17 00:00:00 2001
From: Chris Priest 
Date: Fri, 4 Dec 2015 14:41:46 -0800
Subject: [PATCH 046/259] formatting changes

---
 bip-tx-ver2.mediawiki | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/bip-tx-ver2.mediawiki b/bip-tx-ver2.mediawiki
index ca4cf900..b4ca8e81 100644
--- a/bip-tx-ver2.mediawiki
+++ b/bip-tx-ver2.mediawiki
@@ -39,13 +39,13 @@ coalescing transaction.
 Examples:
 
 version 1 transaction with normal inputs:
-``version: 10000000``
+    version: 10000000
 
 version 2 transaction with normal inputs:
-``version: 20000000``
+    version: 20000000
 
 version 2 transaction with coalescing inputs:
-``version: 20000001``
+    version: 20000001
 
 Essentially the last bit in the version field is set to 1 to enable wildcard inputs for all
 inputs present in the transaction.

From bdd7c9ff76405b265af1f1822736cc95b0a44228 Mon Sep 17 00:00:00 2001
From: Chris Priest 
Date: Fri, 4 Dec 2015 15:48:37 -0800
Subject: [PATCH 047/259] renamed file

---
 bip-tx-ver2.mediawiki => bip-coalesc-wildcard.mediawiki | 0
 1 file changed, 0 insertions(+), 0 deletions(-)
 rename bip-tx-ver2.mediawiki => bip-coalesc-wildcard.mediawiki (100%)

diff --git a/bip-tx-ver2.mediawiki b/bip-coalesc-wildcard.mediawiki
similarity index 100%
rename from bip-tx-ver2.mediawiki
rename to bip-coalesc-wildcard.mediawiki

From aa7cbf77a6f741ef7753ea86990baf4fc3d08b41 Mon Sep 17 00:00:00 2001
From: Peter Todd 
Date: Sat, 5 Dec 2015 17:57:04 +0800
Subject: [PATCH 048/259] Minor: fix capitalisation

---
 bip-0065.mediawiki | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/bip-0065.mediawiki b/bip-0065.mediawiki
index b48fa759..cd0b0ae5 100644
--- a/bip-0065.mediawiki
+++ b/bip-0065.mediawiki
@@ -92,7 +92,7 @@ making transaction malleability a non-issue.
 
 ====Two-factor wallets====
 
-Services like GreenAddress store Bitcoins with 2-of-2 multisig scriptPubKey's
+Services like GreenAddress store bitcoins with 2-of-2 multisig scriptPubKey's
 such that one keypair is controlled by the user, and the other keypair is
 controlled by the service. To spend funds the user uses locally installed
 wallet software that generates one of the required signatures, and then uses a

From 0feb1209d0d224b9465532db55b9bf19b9b42e04 Mon Sep 17 00:00:00 2001
From: Peter Todd 
Date: Sat, 5 Dec 2015 17:57:43 +0800
Subject: [PATCH 049/259] Remove space in BIP66

Seems to be how people are writing BIP's these days.
---
 bip-0065.mediawiki | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/bip-0065.mediawiki b/bip-0065.mediawiki
index cd0b0ae5..57b3d025 100644
--- a/bip-0065.mediawiki
+++ b/bip-0065.mediawiki
@@ -270,7 +270,7 @@ https://github.com/petertodd/bitcoin/commit/ab0f54f38e08ee1e50ff72f801680ee84d0f
 ==Deployment==
 
 We reuse the double-threshold IsSuperMajority() switchover mechanism used in
-BIP 66 with the same thresholds, but for nVersion = 4. The new rules are
+BIP66 with the same thresholds, but for nVersion = 4. The new rules are
 in effect for every block (at height H) with nVersion = 4 and at least
 750 out of 1000 blocks preceding it (with heights H-1000..H-1) also
 have nVersion >= 4. Furthermore, when 950 out of the 1000 blocks

From 7cd2a7bdbbb46e2803855f13e2e39ec20d4f96a1 Mon Sep 17 00:00:00 2001
From: Peter Todd 
Date: Sat, 5 Dec 2015 17:58:33 +0800
Subject: [PATCH 050/259] Fix missing case statement at beginning of
 specification

Wasn't being displayed on github; adding an empty line prior to the spec
seems to fix this.
---
 bip-0065.mediawiki | 1 +
 1 file changed, 1 insertion(+)

diff --git a/bip-0065.mediawiki b/bip-0065.mediawiki
index 57b3d025..f5144ebe 100644
--- a/bip-0065.mediawiki
+++ b/bip-0065.mediawiki
@@ -195,6 +195,7 @@ transaction output ''can'' be spent.
 Refer to the reference implementation, reproduced below, for the precise
 semantics and detailed rationale for those semantics.
 
+    
     case OP_NOP2:
     {
         // CHECKLOCKTIMEVERIFY

From 004be2e8225d582fa1bfd27f08b856996c981586 Mon Sep 17 00:00:00 2001
From: jl2012 
Date: Sun, 6 Dec 2015 23:52:42 +0800
Subject: [PATCH 051/259] Update bip-0065.mediawiki

---
 bip-0065.mediawiki | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/bip-0065.mediawiki b/bip-0065.mediawiki
index a960e543..a90be623 100644
--- a/bip-0065.mediawiki
+++ b/bip-0065.mediawiki
@@ -20,9 +20,9 @@ CHECKLOCKTIMEVERIFY redefines the existing NOP2 opcode. When executed, if
 any of the following conditions are true, the script interpreter will terminate
 with an error:
 
-* the stake is empty; or
+* the stack is empty; or
 * the top item on the stack is less than 0; or
-* the lock-time type (height vs. timestamp) of the top stake item and the nLockTime field are not the same; or
+* the lock-time type (height vs. timestamp) of the top stack item and the nLockTime field are not the same; or
 * the top stack item is greater than the transaction's nLockTime field; or
 * the nLockTime feature is disabled by setting the nSequence field of the txin to 0xffffffff;
 

From e994fa264a7a9a854b4450d3e84f03a7858598c6 Mon Sep 17 00:00:00 2001
From: Chris Priest 
Date: Mon, 7 Dec 2015 15:55:42 -0800
Subject: [PATCH 052/259] fixed bolding

---
 bip-coalesc-wildcard.mediawiki | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/bip-coalesc-wildcard.mediawiki b/bip-coalesc-wildcard.mediawiki
index b4ca8e81..c729d069 100644
--- a/bip-coalesc-wildcard.mediawiki
+++ b/bip-coalesc-wildcard.mediawiki
@@ -62,17 +62,17 @@ in a block lower or equal to the block the wildcard input is confirmed into.
 
 The bitcoin code needs to be modified in three places in order to handle Coalescing Transactions.
 
-1. **Full Node Coalescing validation** - When a full node receives a coalescing transaction, it has to
+1. Full Node Coalescing validation - When a full node receives a coalescing transaction, it has to
 aggregate the value of all the UTXOs in the blockchain older than the input
 with the same scriptPubKey. If this value is greater than or equal to the
 amount of all outputs, then that coalescing transaction is valid and can be propagated.
 
-2. **Full Node Non-Coalescing validation** - When a non-coalescing transaction comes in, the code needs to be modified
+2. Full Node Non-Coalescing validation - When a non-coalescing transaction comes in, the code needs to be modified
 to check if each input has not been spent by a coalescing transaction. If there exist any
 coalescing transaction in the blockchain with the same scriptPubKey found in a block *after* that input,
 then the UTXO has been spent and the transaction is invalid.
 
-3. **Wallet** - The user facing wallet portion of the reference client should notify
+3. Wallet - The user facing wallet portion of the reference client should notify
 the user when their wallet contains many UTXOs that qualify it to benefit from
 a coalescing transaction. Wallets should not simply replace non-coalescing transactions
 with coalescing transactions in all instances.

From abc7ae83a0ae3f31e83bf7933bcf26ed4f6b529d Mon Sep 17 00:00:00 2001
From: jl2012 
Date: Wed, 9 Dec 2015 00:37:25 +0800
Subject: [PATCH 053/259] Update bip-0065.mediawiki

the nLockTime feature may still be active as other inputs may not be final
---
 bip-0065.mediawiki | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/bip-0065.mediawiki b/bip-0065.mediawiki
index a90be623..84bad657 100644
--- a/bip-0065.mediawiki
+++ b/bip-0065.mediawiki
@@ -24,7 +24,7 @@ with an error:
 * the top item on the stack is less than 0; or
 * the lock-time type (height vs. timestamp) of the top stack item and the nLockTime field are not the same; or
 * the top stack item is greater than the transaction's nLockTime field; or
-* the nLockTime feature is disabled by setting the nSequence field of the txin to 0xffffffff;
+* the nSequence field of the txin is 0xffffffff;
 
 Otherwise, script execution will continue as if a NOP had been executed.
 

From 385e3d73437c0be164d74ff34fd19c7aede96343 Mon Sep 17 00:00:00 2001
From: Kristov Atlas 
Date: Wed, 9 Dec 2015 15:32:00 -0500
Subject: [PATCH 054/259] fix typo in block height of P2SH validation

---
 bip-0016.mediawiki | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/bip-0016.mediawiki b/bip-0016.mediawiki
index 0a539fc2..18ef2f40 100644
--- a/bip-0016.mediawiki
+++ b/bip-0016.mediawiki
@@ -37,7 +37,7 @@ The rules for validating these outpoints when relaying transactions or consideri
 # Normal validation is done: an initial stack is created from the signatures and {serialized script}, and the hash of the script is computed and validation fails immediately if it does not match the hash in the outpoint.
 # {serialized script} is popped off the initial stack, and the transaction is validated again using the popped stack and the deserialized script as the scriptPubKey.
 
-These new rules should only be applied when validating transactions in blocks with timestamps >= 1333238400 (Apr 1 2012) [https://github.com/bitcoin/bitcoin/commit/8f188ece3c82c4cf5d52a3363e7643c23169c0ff Remove -bip16 and -paytoscripthashtime command-line arguments]. There are transaction earlier than 13333238400 in the block chain that fail these new validation rules. [http://blockexplorer.com/tx/6a26d2ecb67f27d1fa5524763b49029d7106e91e3cc05743073461a719776192 Transaction 6a26d2ecb67f27d1fa5524763b49029d7106e91e3cc05743073461a719776192]. Older transactions must be validated under the old rules. (see the Backwards Compatibility section for details).
+These new rules should only be applied when validating transactions in blocks with timestamps >= 1333238400 (Apr 1 2012) [https://github.com/bitcoin/bitcoin/commit/8f188ece3c82c4cf5d52a3363e7643c23169c0ff Remove -bip16 and -paytoscripthashtime command-line arguments]. There are transaction earlier than 1333238400 in the block chain that fail these new validation rules. [http://blockexplorer.com/tx/6a26d2ecb67f27d1fa5524763b49029d7106e91e3cc05743073461a719776192 Transaction 6a26d2ecb67f27d1fa5524763b49029d7106e91e3cc05743073461a719776192]. Older transactions must be validated under the old rules. (see the Backwards Compatibility section for details).
 
 For example, the scriptPubKey and corresponding scriptSig for a one-signature-required transaction is:
 

From 7239c330c77310865deea6ea0d45ca9dda68e411 Mon Sep 17 00:00:00 2001
From: BtcDrak 
Date: Thu, 10 Dec 2015 20:01:35 +0000
Subject: [PATCH 055/259] BIP68 now assume MTP in all instances

---
 bip-0068.mediawiki | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/bip-0068.mediawiki b/bip-0068.mediawiki
index 02bc2a4e..58974ec3 100644
--- a/bip-0068.mediawiki
+++ b/bip-0068.mediawiki
@@ -30,7 +30,7 @@ If bit (1 << 31) of the sequence number is not set, then the sequence number is
 
 The sequence number encoding is interpreted as follows: 
 
-Bit (1 << 22) determines if the relative lock-time is time-based or block based: If the bit is set, the relative lock-time specifies a timespan in units of 512 seconds granularity. The timespan starts from the median-time-past (MTP) of the output’s previous block, and ends either at the MTP of the previous block or at the nTime of the transaction’s block (depending on the enforcement status of BIP113). If the bit is not set, the relative lock-time specifies a number of blocks.
+Bit (1 << 22) determines if the relative lock-time is time-based or block based: If the bit is set, the relative lock-time specifies a timespan in units of 512 seconds granularity. The timespan starts from the median-time-past (MTP) of the output’s previous block, and ends either at the MTP of the previous block or at the nTime of the transaction’s block as defined by BIP113. If the bit is not set, the relative lock-time specifies a number of blocks.
 
 The flag (1<<22) is the highest order bit in a 3-byte signed integer for use in bitcoin scripts as a 3-byte PUSHDATA with OP_CHECKSEQUENCEVERIFY (BIP 112).
 
@@ -43,7 +43,7 @@ For time based relative lock-time, 512 second granularity was chosen because bit
 When the relative lock-time is time-based, it is interpreted as a minimum block-time constraint over the input's age. A relative time-based lock-time of zero indicates an input which can be included in any block. More generally, a relative time-based lock-time n can be included into any block produced 512 * n seconds after the mining date of the output it is spending, or any block thereafter.
 The mining date of the output is equals to the median-time-past of the previous block which mined it.
 
-The block produced time is either equals to median time past of its parent or to its nTime field, depending on the state of BIP113 median-time-past.
+The block produced time is equal to the median-time-past of its parent according to BIP113.
 
 When the relative lock-time is block-based, it is interpreted as a minimum block-height constraint over the input's age. A relative block-based lock-time of zero indicates an input which can be included in any block. More generally, a relative block lock-time n can be included n blocks after the mining date of the output it is spending, or any block thereafter.
 

From df9d34d5375751aa49f10f4e6abfe5a4a333e588 Mon Sep 17 00:00:00 2001
From: BtcDrak 
Date: Thu, 10 Dec 2015 20:03:28 +0000
Subject: [PATCH 056/259] Update deployment specification

BIP68 must be deployed with BIP113 because MTP calculations are
used by this BIP.
---
 bip-0068.mediawiki | 8 +++++---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/bip-0068.mediawiki b/bip-0068.mediawiki
index 58974ec3..55905afc 100644
--- a/bip-0068.mediawiki
+++ b/bip-0068.mediawiki
@@ -24,13 +24,15 @@ The transaction nLockTime is used to prevent the mining of a transaction until a
 
 This specification defines the meaning of sequence numbers for transactions with an nVersion greater than or equal to 2 for which the rest of this specification relies on.
 
+All references to median-time-past (MTP) are as defined by BIP113.
+
 If bit (1 << 31) of the sequence number is set, then no consensus meaning is applied to the sequence number and can be included in any block under all currently possible circumstances.
 
 If bit (1 << 31) of the sequence number is not set, then the sequence number is interpreted as an encoded relative lock-time.
 
 The sequence number encoding is interpreted as follows: 
 
-Bit (1 << 22) determines if the relative lock-time is time-based or block based: If the bit is set, the relative lock-time specifies a timespan in units of 512 seconds granularity. The timespan starts from the median-time-past (MTP) of the output’s previous block, and ends either at the MTP of the previous block or at the nTime of the transaction’s block as defined by BIP113. If the bit is not set, the relative lock-time specifies a number of blocks.
+Bit (1 << 22) determines if the relative lock-time is time-based or block based: If the bit is set, the relative lock-time specifies a timespan in units of 512 seconds granularity. The timespan starts from the median-time-past of the output’s previous block, and ends at the MTP of the previous block. If the bit is not set, the relative lock-time specifies a number of blocks.
 
 The flag (1<<22) is the highest order bit in a 3-byte signed integer for use in bitcoin scripts as a 3-byte PUSHDATA with OP_CHECKSEQUENCEVERIFY (BIP 112).
 
@@ -43,7 +45,7 @@ For time based relative lock-time, 512 second granularity was chosen because bit
 When the relative lock-time is time-based, it is interpreted as a minimum block-time constraint over the input's age. A relative time-based lock-time of zero indicates an input which can be included in any block. More generally, a relative time-based lock-time n can be included into any block produced 512 * n seconds after the mining date of the output it is spending, or any block thereafter.
 The mining date of the output is equals to the median-time-past of the previous block which mined it.
 
-The block produced time is equal to the median-time-past of its parent according to BIP113.
+The block produced time is equal to the median-time-past of its previous block.
 
 When the relative lock-time is block-based, it is interpreted as a minimum block-height constraint over the input's age. A relative block-based lock-time of zero indicates an input which can be included in any block. More generally, a relative block lock-time n can be included n blocks after the mining date of the output it is spending, or any block thereafter.
 
@@ -191,7 +193,7 @@ This BIP was edited by BtcDrak, Nicolas Dorier and kinoshitajona.
 
 This BIP is to be deployed by either version-bits BIP9 or by isSuperMajority(). Exact details TDB.
 
-It is recommended to deploy BIP112 and BIP113 at the same time as this BIP.
+BIP68 MUST be deployed together with BIP113. It is also recommended to deploy BIP112 at the same time.
 
 ==Compatibility==
 

From b57eea446cbd99088da1a9badc2fb85396982b9f Mon Sep 17 00:00:00 2001
From: "David A. Harding" 
Date: Fri, 4 Dec 2015 20:24:33 -0500
Subject: [PATCH 057/259] Add opt-in full-RBF signaling BIP

---
 README.mediawiki         |   6 ++
 bip-opt-in-rbf.mediawiki | 187 +++++++++++++++++++++++++++++++++++++++
 2 files changed, 193 insertions(+)
 create mode 100644 bip-opt-in-rbf.mediawiki

diff --git a/README.mediawiki b/README.mediawiki
index b45c17a0..14d8a06c 100644
--- a/README.mediawiki
+++ b/README.mediawiki
@@ -379,6 +379,12 @@ Those proposing changes should consider that ultimately consent may rest with th
 | Suhas Daftuar
 | Standard
 | Draft
+|-
+| [[bip-opt-in-rbf.mediawiki|FIXME]]
+| Opt-in Full Replace-by-Fee Signaling
+| David Harding, Peter Todd
+| Standard
+| Draft
 |}
 
 
diff --git a/bip-opt-in-rbf.mediawiki b/bip-opt-in-rbf.mediawiki
new file mode 100644
index 00000000..5bd24729
--- /dev/null
+++ b/bip-opt-in-rbf.mediawiki
@@ -0,0 +1,187 @@
+
+  BIP: bip-harding-opt-in-replace-by-fee
+  Title: Opt-in Full Replace-by-Fee Signaling
+  Author: David A. Harding , Peter Todd 
+  Status: Draft
+  Type: Standards Track
+  Created: 2015-12-04
+

+
+==Abstract==
+
+Many nodes today will not replace any transaction in their mempool with
+another transaction that spends the same inputs, making it difficult for
+spenders to adjust their previously-sent transactions to deal with
+unexpected confirmation delays or to perform other useful replacements.
+
+The opt-in full Replace-by-Fee (opt-in full-RBF) signaling policy
+described here allows spenders to add a signal to a transaction indicating
+that they want to be able to replace that transaction in the future.
+In response to this signal,
+
+* Nodes may allow transactions containing this signal to be replaced in their mempools.
+
+* The recipient or recipients of a transaction containing this signal may choose not to treat it as payment until it has been confirmed, eliminating the risk that the spender will use allowed replacements to defraud them.
+
+Nodes and recipients may continue to treat transactions without the
+signal the same way they treated them before, preserving the existing
+status quo.
+
+==Summary==
+
+This policy specifies two ways a transaction can signal that it is
+replaceable.
+
+* '''Explicit signaling:''' A transaction is considered to have opted in to allowing replacement of itself if any of its inputs have an nSequence number less than (0xffffffff - 1).
+
+* '''Inherited signaling:''' Transactions that don't explicitly signal replaceability are replaceable under this policy for as long as any one of their ancestors signals replaceability and remains unconfirmed.
+
+===Implementation Details===
+
+The initial implementation expected in Bitcoin Core 0.12.0 uses the following rules:
+
+One or more transactions currently in the mempool (original
+transactions) will be replaced by a new transaction (replacement
+transaction) that spends one or more of the same inputs if,
+
+# The original transactions signal replaceability explicitly or through inheritance as described in the above Summary section.
+
+# The replacement transaction pays an absolute higher fee than the sum paid by the original transactions.
+
+# The replacement transaction does not contain any new unconfirmed inputs that did not previously appear in the mempool. (Unconfirmed inputs are inputs spending outputs from currently unconfirmed transactions.)
+
+# The replacement transaction must pay for its own bandwidth in addition to the amount paid by the original transactions at or above the rate set by the node's minimum relay fee setting.  For example, if the minimum relay fee is 1 satoshi/byte and the replacement transaction is 500 bytes total, then the replacement must pay a fee at least 500 satoshis higher than the sum of the originals.
+
+# The number of original transactions to be replaced and their descendant transactions which will be evicted from the mempool must not exceed a total of 100 transactions.
+
+The initial implementation may be seen in
+[https://github.com/bitcoin/bitcoin/pull/6871 Bitcoin Core PR#6871]
+and specifically the master branch commits from
+5891f870d68d90408aa5ce5b597fb574f2d2cbca to
+16a2f93629f75d182871f288f0396afe6cdc8504 (inclusive).
+
+===Receiving wallet policy===
+
+Wallets that display unconfirmed transactions to users or that provide
+data about unconfirmed transactions to automated systems should consider
+doing one of the following:
+
+# Conveying additional suspicion about opt-in full-RBF transactions to the user or data consumer.
+
+# Ignoring the opt-in transaction until it has been confirmed.
+
+Because descendant transactions may also be replaceable under this
+policy through inherited signaling, any method used to process opt-in
+full-RBF transactions should be inherited by any descendant transactions
+for as long as any ancestor opt-in full-RBF transactions remain
+unconfirmed.
+
+===Spending wallet policy===
+
+Wallets that don't want to signal replaceability should use either a max
+sequence number (0xffffffff) or a sequence number of (0xffffffff-1) when
+then also want to use locktime; all known wallets currently do this.
+They should also take care not to spend any unconfirmed transaction that
+signals replaceability explicitly or through inherited signaling; most wallets also
+currently do this by not spending any unconfirmed transactions except
+for those they created themselves.
+
+Wallets that do want to make replacements should use explicit signaling
+and meet the criteria described above in the Implementation Details
+section. A
+[https://en.bitcoin.it/wiki/Transaction_replacement Bitcoin Wiki page]
+has been created to help wallet authors track deployed mempool policies
+relating to transaction replacement.
+
+The initial implementation makes use of P2P protocol reject messages for
+rejected replacements, allowing P2P clients to determine whether their
+replacements were initially accepted by their peers. Standard P2P
+lightweight client practice of sending to some peers while listening for
+relays from other peers should allow clients to determine whether the
+replacement has propagated.
+
+==Motivation==
+
+Satoshi Nakamoto's original Bitcoin implementation provided the
+nSequence number field in each input to
+[https://github.com/trottier/original-bitcoin/blob/master/src/main.cpp#L434 allow replacement]
+of transactions containing that input within the
+mempool. When receiving replacements, nodes were supposed to replace
+transactions whose inputs had lower sequence numbers with transactions
+that had higher sequence numbers.
+
+In that implementation, replacement transactions did not have to pay
+additional fees, so there was no direct incentive for miners to
+include the replacement and no built-in rate limiting that prevented
+overuse of relay node bandwidth. Nakamoto
+[https://github.com/bitcoin/bitcoin/commit/05454818dc7ed92f577a1a1ef6798049f17a52e7#diff-118fcbaaba162ba17933c7893247df3aR522 removed replacement]
+from Bitcoin version 0.3.12, leaving only the
+comment, "Disable replacement feature for now".
+
+Replacing transactions with higher-fee transactions provided a way for
+spenders to align their desires with miners, but by the time a
+Replace-by-Fee (RBF) patch was available to re-enable replacement, some
+receivers had begun to expect that the first version of a transaction
+they saw was highly likely to be the version of the transaction to be
+confirmed, and so some users advocated that replacement should be
+disallowed.
+
+To address those concerns, a variation on RBF was created that
+required that the replacement transaction pay all of same outputs as
+the original transaction in equal or greater amount.  This was called
+RBF First Seen Safe (RBF-FSS), and the original RBF became known as
+full-RBF.  Although agreeable to recipients who relied on the
+first-seen version of a transaction, each use of RBF-FSS required
+adding an extra input to a transaction, resulting in wallets being
+unable to use it if they had no spare inputs, a loss of privacy when
+inputs from different origins get used in the same transaction, and a
+wasteful increase in transaction byte size.
+
+Opt-in full-RBF uses Nakamoto's original semantics (with a slight
+tweak to allow locktime users to opt-out) to signal that replacement
+is possible, providing first-seen users with the ability to ignore
+those transactions while also allowing for the efficiency benefits
+of full-RBF.
+
+There are no known problematic interactions between opt-in full-RBF and
+other uses of nSequence. Specifically, opt-in full-RBF is compatible
+with consensus-enforced locktime as provided in the Bitcoin 0.1
+implementation, draft BIP68 (Relative lock-time using consensus-enforced
+sequence numbers), and draft BIP112 (CHECKSEQUENCEVERIFY).
+
+==Deployment==
+
+Now, and since Bitcoin's first release, 100% of the network hash rate
+mines transactions using opt-in full-RBF semantics (sequence less than
+(0xffffffff - 1)).
+
+Opt-in full-RBF as a default mempool replacement policy among nodes
+and miners is expected to become widespread as they upgrade to Bitcoin
+Core 0.12.0 (release expected Jan/Feb 2016) and similar node software
+such as Bitcoin LJR.
+
+Actual replacement may be unreliable until two conditions have been satisfied:
+
+# Enough nodes have upgraded to support it, providing a relay path for replacements to go from spending wallets to miners controlling significant amounts of hash rate.
+
+# Enough hash rate has upgraded to support replacement, allowing for reasonable probability that a replacement can be mined.
+
+==Client support==
+
+No known wallet currently creates transactions by default with
+nSequence set below (0xffffffff - 1), so no known existing wallet
+explicitly signals replaceability by default.  No known popular wallet
+spends other users' unconfirmed transactions by default, so no known
+existing wallets signals inherited replaceability.
+
+==See also==
+
+# [https://en.bitcoin.it/wiki/Transaction_replacement Transaction Replaceability on Bitcoin Wiki] targeted at helping wallet authors use RBF
+
+# Tools for creating opt-in full-RBF transactions: https://github.com/petertodd/replace-by-fee-tools#replace-by-fee-tools
+
+# [https://www.reddit.com/r/Bitcoin/comments/3urm8o/optin_rbf_is_misunderstood_ask_questions_about_it/ Reddit: Questions about opt-in RBF] targeted at helping community members understand opt-in full-RBF
+
+==Copyright==
+
+This document is placed in the public domain.

From 097983d2563ea0a11ad3bc0add9946c8232e3e17 Mon Sep 17 00:00:00 2001
From: Jeff Garzik 
Date: Thu, 17 Dec 2015 23:21:13 -0500
Subject: [PATCH 058/259] BIP 102: update to match implementation

---
 bip-0102.mediawiki | 24 +++++++++++++-----------
 1 file changed, 13 insertions(+), 11 deletions(-)

diff --git a/bip-0102.mediawiki b/bip-0102.mediawiki
index b75f7984..a84d8007 100644
--- a/bip-0102.mediawiki
+++ b/bip-0102.mediawiki
@@ -13,28 +13,30 @@ Simple, one-time increase in total amount of transaction data permitted in a blo
 
 ==Motivation==
 
-# Enable network growth.
-# Continue current economic policy of low fee pressure on average.
-# Exercise network upgrade procedure.
+# Continue current economic policy.
+# Exercise hard fork network upgrade.
 
 ==Specification==
 
-# Maximum block size permitted to be valid is 1MB.
-# Increase this maximum to 2MB as soon as 75% of the last 1,000 blocks have signaled support.
+# MAX_BLOCK_SIZE increased to 2,000,000 bytes at trigger point.
 # Increase maximum block sigops by similar factor, preserving SIZE/50 formula.
+# Each 10-minute segment thereafter increases MAX_BLOCK_SIZE by 20 bytes.
+# Trigger:  (1) Block time 00:00:00 on flag day, AND (2) 75% of the last 1,000 blocks have signaled support.
 
 ==Backward compatibility==
 
-Older clients are not compatible with this change.  The first block exceeding 1,000,000 bytes will partition older clients off the new network.
+Fully validating older clients are not compatible with this change.
+The first block exceeding 1,000,000 bytes will partition older clients
+off the new network.
 
 ==Discussion==
 
-In the short term, an increase is needed to continue to facilitate
-network growth, and buy time for more comprehensive solutions to be
-developed.  This continues the current economic policies with regards to
-fees, matching market expectations and preventing market disruption.
+In the short term, an increase is needed to continue to current
+economic policies with regards to fees and block space, matching
+market expectations and preventing market disruption.
 
-In the long term, continued direct management of this limit is a moral hazard that clouds free market input and prevents a healthy fee market from developing.  This area of code should be transitioned away from direct management.
+In the long term, this limit should focus on reflecting the maximum
+network engineering limit.
 
 ==Implementation==
 

From 32112987af3ba178661e3f1f1f2616ecab547f8f Mon Sep 17 00:00:00 2001
From: Jeff Garzik 
Date: Fri, 18 Dec 2015 08:01:30 -0500
Subject: [PATCH 059/259] BIP 102: remove dynamic adjustment

---
 bip-0102.mediawiki | 1 -
 1 file changed, 1 deletion(-)

diff --git a/bip-0102.mediawiki b/bip-0102.mediawiki
index a84d8007..ea25979f 100644
--- a/bip-0102.mediawiki
+++ b/bip-0102.mediawiki
@@ -20,7 +20,6 @@ Simple, one-time increase in total amount of transaction data permitted in a blo
 
 # MAX_BLOCK_SIZE increased to 2,000,000 bytes at trigger point.
 # Increase maximum block sigops by similar factor, preserving SIZE/50 formula.
-# Each 10-minute segment thereafter increases MAX_BLOCK_SIZE by 20 bytes.
 # Trigger:  (1) Block time 00:00:00 on flag day, AND (2) 75% of the last 1,000 blocks have signaled support.
 
 ==Backward compatibility==

From 5cdae758f3941272962beb28897b2ae03189712e Mon Sep 17 00:00:00 2001
From: Jeff Garzik 
Date: Fri, 18 Dec 2015 08:39:00 -0500
Subject: [PATCH 060/259] BIP 102: 95% update req

---
 bip-0102.mediawiki | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/bip-0102.mediawiki b/bip-0102.mediawiki
index ea25979f..fc909f75 100644
--- a/bip-0102.mediawiki
+++ b/bip-0102.mediawiki
@@ -20,7 +20,7 @@ Simple, one-time increase in total amount of transaction data permitted in a blo
 
 # MAX_BLOCK_SIZE increased to 2,000,000 bytes at trigger point.
 # Increase maximum block sigops by similar factor, preserving SIZE/50 formula.
-# Trigger:  (1) Block time 00:00:00 on flag day, AND (2) 75% of the last 1,000 blocks have signaled support.
+# Trigger:  (1) Block time 00:00:00 on flag day, AND (2) 95% of the last 1,000 blocks have signaled support.
 
 ==Backward compatibility==
 

From 876af7fa87945870eaf4ec5bf4b4ec5a01f1f715 Mon Sep 17 00:00:00 2001
From: Justus Ranvier 
Date: Fri, 18 Dec 2015 10:14:13 -0600
Subject: [PATCH 061/259] add missing change notification and minor corrections

---
 bip-0047.mediawiki | 10 ++++++++--
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/bip-0047.mediawiki b/bip-0047.mediawiki
index e460a12d..31190403 100644
--- a/bip-0047.mediawiki
+++ b/bip-0047.mediawiki
@@ -1,5 +1,7 @@
 RECENT CHANGES:
 
+* (12 Oct 2015) Revise blinding method for notification transactions
+
 * (21 Sep 2015) Correct base58check version byte
 
 * (18 Sep 2015) Clarify decoding of notification transactions
@@ -57,11 +59,15 @@ Hardened derivation is used at this level.
 
 Except where noted, all keys derived from a payment code use the public derivation method.
 
+==Standard Payment Codes (v1)==
+
+===Representation===
+
 ====Binary Serialization====
 
 A payment code contains the following elements:
 
-* Byte 0: type. required value: 0x01
+* Byte 0: version. required value: 0x01
 * Byte 1: features bit field. All bits must be zero except where specified elsewhere in this specification
 ** Bit 0: Bitmessage notification
 ** Bits 1-7: reserved
@@ -233,7 +239,7 @@ A recipient prefers to receive notifications via Bitmessage indiates this prefer
 
 * Setting bit 0 of the features byte to 1
 * Setting byte 67 of the serialized payment code to the desired Bitmessage address version
-* Setting byte 67 of the serialized payment code to the desired Bitmessage stream number
+* Setting byte 68 of the serialized payment code to the desired Bitmessage stream number
 
 The sender uses this information to construct a valid notification Bitmessage address:
 

From 07ab320513843bf75b55def318d60ced47434548 Mon Sep 17 00:00:00 2001
From: Justus Ranvier 
Date: Fri, 18 Dec 2015 10:47:44 -0600
Subject: [PATCH 062/259] clarify the various types of child keys derived from
 an identity

---
 bip-0047.mediawiki | 24 ++++++++++++++++++++++--
 1 file changed, 22 insertions(+), 2 deletions(-)

diff --git a/bip-0047.mediawiki b/bip-0047.mediawiki
index 31190403..650c0959 100644
--- a/bip-0047.mediawiki
+++ b/bip-0047.mediawiki
@@ -31,9 +31,29 @@ Payment codes add identity information to transactions which is useful in a merc
 
 We define the following 3 levels in BIP32 path:
 
-
+
 m / purpose' / coin_type' / identity'
-

+
+
+The child keys derived from an identity are used in different ways:
+
+
+m / purpose' / coin_type' / identity' / 0
+
+
+The 0th (non-hardened) child is the notification key.
+
+
+m / purpose' / coin_type' / identity' / 0 through 2147483647
+
+
+These (non-hardened) keypairs are used for ECDH to generate deposit addresses.
+
+
+m / purpose' / coin_type' / identity' / 0' through 2147483647'
+
+
+These (hardened) keypairs are ephemeral payment codes.
 
 Apostrophe in the path indicates that BIP32 hardened derivation is used.
 

From a6f4ae5b5d3a247b6a8f2a8baec7e5b8ed165051 Mon Sep 17 00:00:00 2001
From: Justus Ranvier 
Date: Fri, 18 Dec 2015 10:28:27 -0600
Subject: [PATCH 063/259] clarify wallet recovery procedure

---
 bip-0047.mediawiki | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/bip-0047.mediawiki b/bip-0047.mediawiki
index 650c0959..066878bb 100644
--- a/bip-0047.mediawiki
+++ b/bip-0047.mediawiki
@@ -220,7 +220,9 @@ When querying a public blockchain explorer, wallets SHOULD connect to the explor
 
 Previously-spendable funds will generally not be lost or become inaccessible after a recovery from a seed, but all information regarding previous outgoing payments will be lost.
 
-The metadata which a wallet must store regarding the state an identity consists of:
+In order to recover received funds from a seed, the wallet must obtain every notification it has ever received to its notification address, including all spent transactions. It then re-establishes its lookahead window for each subchain by scanning every derived address sequentially until it locates a contiguous block of unused addresses of a user-specified length.
+
+The metadata which a wallet must store to properly process outgoing transactions consists of:
 
 # A list of every payment code to which the identity has sent a notification transaction.
 ## This list is lost if a wallet must be recovered from a seed.

From 650fa601ad0fb7b928dbc7c34fb4abe3388e2e5d Mon Sep 17 00:00:00 2001
From: Justus Ranvier 
Date: Fri, 18 Dec 2015 10:37:43 -0600
Subject: [PATCH 064/259] enumerate the list of script forms which can convey a
 notification pubkey

---
 bip-0047.mediawiki | 11 +++++++++++
 1 file changed, 11 insertions(+)

diff --git a/bip-0047.mediawiki b/bip-0047.mediawiki
index 066878bb..99b0be21 100644
--- a/bip-0047.mediawiki
+++ b/bip-0047.mediawiki
@@ -161,6 +161,17 @@ Bitcoins received via notification transactions require special handling in orde
 # Outputs received to notification addresses MAY be passed through a mixing service before being added to the user's spendable balance.
 # Outputs received to notification addresses MAY be donated to miners using dust-b-gone or an equivalent procedure.
 
+=====Standard Notification Transaction Scripts=====
+
+Alice SHOULD use an input script in one of the following standard forms to expose a public key, and compliant applications SHOULD recognize all of these forms.
+
+* P2PK (pay to pubkey)
+* P2PKH (pay to pubkey hash)
+* Multisig (bare multisig, without P2SH)
+* a script which spends any of the above script forms via P2SH (pay to script hash)
+
+Compatible wallets MAY provide a method for a user to manually specify the public key associated with a notification transaction in order to recover payment codes sent via non-standard notification transactions.
+
 ====Sending====
 
 # Each time Alice wants to initiate a transaction to Bob, Alice derives a unique P2PKH address for the transaction using ECDH follows:

From 27848f7d6bfa1152c80fb16e8c235a38644e0680 Mon Sep 17 00:00:00 2001
From: Justus Ranvier 
Date: Fri, 18 Dec 2015 13:40:54 -0600
Subject: [PATCH 065/259] Clarify the definition of identity and the
 relationship to BIP-44

---
 bip-0047.mediawiki | 14 +++++++++++---
 1 file changed, 11 insertions(+), 3 deletions(-)

diff --git a/bip-0047.mediawiki b/bip-0047.mediawiki
index 99b0be21..50baaac6 100644
--- a/bip-0047.mediawiki
+++ b/bip-0047.mediawiki
@@ -71,9 +71,17 @@ Hardened derivation is used at this level.
 
 ===Identity===
 
-Identity is a particular extended public/private key pair. The extended public key is a payment code.
+The identity derivation level produces an extended public key and its associated extended private key.
 
-Identities SHOULD have 1:1 correspondence with a BIP44 account, as in each BIP44 account in an HD wallet should be assigned exactly one payment code which shares the same index value.
+When the extended public key at this level is combined with the metadata specified in the Representation section below, the resulting entity is called a "payment code."
+
+This derivation level is equivalent to the Account level in BIP-44. Wallets SHOULD treat payment codes as intrinsically part of the BIP-44 account at the same index and create payment codes and accounts as pairs.
+
+For example, the payment code created represented by (m / 47' / 0' / 0') is part of the account represented by (m / 44' / 0' / 0').
+
+The second account in a wallet consists of the new account/payment code pair created by using an index of 1 in as the account/identity level of both paths.
+
+Incoming payments received via this specification are equivalent to payments received to BIP-44 addresses, and unspent outputs from both types of addresses can be used as inputs in the same outgoing transaction.
 
 Hardened derivation is used at this level.
 
@@ -111,7 +119,7 @@ It is assumed that Alice can easily obtain Bob's payment code via a suitable met
 
 ====Definitions====
 
-* Payment code: an extended public key which is associated with a particular identity
+* Payment code: an extended public key and associated metadata which is associated with a particular identity/account
 * Notification address: the P2PKH address associated with the 0th public key derived from a payment code
 * Notification transaction: a transaction which sends an output to a notification address which includes an embedded payment code
 

From 2f566884f488056c666bdd52805422517254401f Mon Sep 17 00:00:00 2001
From: Justus Ranvier 
Date: Fri, 18 Dec 2015 13:48:13 -0600
Subject: [PATCH 066/259] update recent changes

---
 bip-0047.mediawiki | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/bip-0047.mediawiki b/bip-0047.mediawiki
index 50baaac6..c3c50586 100644
--- a/bip-0047.mediawiki
+++ b/bip-0047.mediawiki
@@ -1,11 +1,11 @@
 RECENT CHANGES:
 
+* (18 Dec 2015) Update explanations to resolve FAQs
+
 * (12 Oct 2015) Revise blinding method for notification transactions
 
 * (21 Sep 2015) Correct base58check version byte
 
-* (18 Sep 2015) Clarify decoding of notification transactions
-
 
   BIP:     47
   Title:   Reusable Payment Codes for Hierarchical Deterministic Wallets

From 01201d6ce58d7df1d48034bb434a577cceb507fe Mon Sep 17 00:00:00 2001
From: MarcoPon 
Date: Sat, 19 Sep 2015 19:24:35 +0200
Subject: [PATCH 067/259] Created bip-MarcoPon-01.mediawiki URI scheme for
 Blockchain references / exploration

---
 README.mediawiki          |  6 ++++
 bip-MarcoPon-01.mediawiki | 67 +++++++++++++++++++++++++++++++++++++++
 2 files changed, 73 insertions(+)
 create mode 100644 bip-MarcoPon-01.mediawiki

diff --git a/README.mediawiki b/README.mediawiki
index 925910c2..4d90c239 100644
--- a/README.mediawiki
+++ b/README.mediawiki
@@ -373,6 +373,12 @@ Those proposing changes should consider that ultimately consent may rest with th
 | Suhas Daftuar
 | Standard
 | Draft
+|-
+| [[bip-MarcoPon-01.mediawiki| xx]]
+| URI scheme for Blockchain references / exploration
+| Marco Pontello
+| Standard
+| Draft
 |}
 
 
diff --git a/bip-MarcoPon-01.mediawiki b/bip-MarcoPon-01.mediawiki
new file mode 100644
index 00000000..9c0fe4a2
--- /dev/null
+++ b/bip-MarcoPon-01.mediawiki
@@ -0,0 +1,67 @@
+
+  BIP: MarcoPon-01
+  Title: URI scheme for Blockchain references / exploration
+  Author: Marco Pontello 
+  Status: Draft
+  Type: Standards Track
+  Created: 29 August 2015
+

+
+==Abstract==
+
+This BIP propose an URI scheme for looking up blocks, transactions, addresses on a Blockchain explorer, or in general to make proper Blockchain references
+
+==Motivation==
+
+The purpose of this URI scheme is to enable users to handle all the requests for details about blocks, transactions, etc. with their preferred tool (being that a web service or a local application).
+Currently a Bitcoin client usually point to an arbitrary blockchain explorer when the user look for the details of a transaction (es. Bitcoin Wallet use BitEasy, Mycelium or Electrum use Blockchain.info, etc.).
+Other times resorting to cut&paste is needed.
+The same happens with posts and messages that reference some particular txs or blocks, if they provide links at all.
+
+==Specification==
+
+The URI follow this simple form:
+
+ blockchain:[//chain]
+
+Where:
+
+;chain:
+: (optional) to uniquely point to a specific chain, the hash of the corresponding genesis block is used (see [http://https://github.com/jtimon/bitcoin/commit/3191d5e8e75687a27cf466b7a4c70bdc04809d39 Bitcoin src/chainparams.cpp]). In principle some kind of alias/mnemonic could also be used, but that is out of the scope of this BIP, and maybe could be developed in another subsequent one.
+
+;type: 
+: '''tx''': for transactions.
+: '''block''': for blocks (supports both hash or height).
+: '''address''': for addresses.
+
+;hash: 
+: the relevant hash (or height) to refer to.
+
+==Examples==
+
+A transaction on Bitcoin's mainnet:
+ blockchain:/tx/b462ae6eb8bdae2e060239a2a3ea5d9c3e0f9ef34d9717beb2dcf0ed42cee7da
+
+A block on Bitcoin's mainnet:
+ blockchain:/block/00000000000000000119af5bcae2926df54ae262e9071a94a99c913cc217cc72
+or
+ blockchain:/block/372338
+
+An address on Bitcoin's mainnet:
+ blockchain:/address/16EW6Rv9P9AxFDBrZV816dD4sj1EAYUX3f
+
+A transaction on Bitcoin's testnet:
+ blockchain://000000000933ea01ad0ee984209779baaec3ced90fa3f408719526f8d77f4943/tx/3b95a766d7a99b87188d6875c8484cb2b310b78459b7816d4dfc3f0f7e04281a
+
+==Rationale==
+
+From the point of view of a wallet developer (or other tool that need to show any kind of Blockchain references), using this scheme mean that he can simply make it a blockchain: link and be done with it, without having to worry about any specific Blockchain explorer or provide a means for the user to select one.
+
+Blockchain explorers in turn will simply offer to handle the blockchain: URI, the first time the user visit their website, or launch/install the application, or even set themselves if there isn't already one.
+
+Users get the convenience of using always their preferred explorer, which can be especially handy on mobile devices, where juggling with cut&paste is far from ideal.
+
+==Copyright==
+
+This document is placed in the public domain.
+

From e84e2d5c38910dce8cb5508eceee9a946b8b2bb6 Mon Sep 17 00:00:00 2001
From: Dionysis Zindros 
Date: Sun, 15 Nov 2015 13:50:43 +0200
Subject: [PATCH 068/259] Fix broken GitHub https URL

---
 bip-MarcoPon-01.mediawiki | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/bip-MarcoPon-01.mediawiki b/bip-MarcoPon-01.mediawiki
index 9c0fe4a2..c919fe98 100644
--- a/bip-MarcoPon-01.mediawiki
+++ b/bip-MarcoPon-01.mediawiki
@@ -27,7 +27,7 @@ The URI follow this simple form:
 Where:
 
 ;chain:
-: (optional) to uniquely point to a specific chain, the hash of the corresponding genesis block is used (see [http://https://github.com/jtimon/bitcoin/commit/3191d5e8e75687a27cf466b7a4c70bdc04809d39 Bitcoin src/chainparams.cpp]). In principle some kind of alias/mnemonic could also be used, but that is out of the scope of this BIP, and maybe could be developed in another subsequent one.
+: (optional) to uniquely point to a specific chain, the hash of the corresponding genesis block is used (see [https://github.com/jtimon/bitcoin/commit/3191d5e8e75687a27cf466b7a4c70bdc04809d39 Bitcoin src/chainparams.cpp]). In principle some kind of alias/mnemonic could also be used, but that is out of the scope of this BIP, and maybe could be developed in another subsequent one.
 
 ;type: 
 : '''tx''': for transactions.

From 29b8eaef022d1e34d57f8cdcde08e72530f2082f Mon Sep 17 00:00:00 2001
From: MarcoPon 
Date: Mon, 16 Nov 2015 00:44:34 +0100
Subject: [PATCH 069/259] Some clarifications, typos

---
 bip-MarcoPon-01.mediawiki | 21 +++++++++++++++++----
 1 file changed, 17 insertions(+), 4 deletions(-)

diff --git a/bip-MarcoPon-01.mediawiki b/bip-MarcoPon-01.mediawiki
index c919fe98..b8483c22 100644
--- a/bip-MarcoPon-01.mediawiki
+++ b/bip-MarcoPon-01.mediawiki
@@ -14,7 +14,7 @@ This BIP propose an URI scheme for looking up blocks, transactions, addresses on
 ==Motivation==
 
 The purpose of this URI scheme is to enable users to handle all the requests for details about blocks, transactions, etc. with their preferred tool (being that a web service or a local application).
-Currently a Bitcoin client usually point to an arbitrary blockchain explorer when the user look for the details of a transaction (es. Bitcoin Wallet use BitEasy, Mycelium or Electrum use Blockchain.info, etc.).
+Currently a Bitcoin client usually points to an arbitrary blockchain explorer when the user looks for the details of a transaction (es. Bitcoin Wallet uses BitEasy, Mycelium or Electrum uses Blockchain.info, etc.).
 Other times resorting to cut&paste is needed.
 The same happens with posts and messages that reference some particular txs or blocks, if they provide links at all.
 
@@ -27,7 +27,15 @@ The URI follow this simple form:
 Where:
 
 ;chain:
-: (optional) to uniquely point to a specific chain, the hash of the corresponding genesis block is used (see [https://github.com/jtimon/bitcoin/commit/3191d5e8e75687a27cf466b7a4c70bdc04809d39 Bitcoin src/chainparams.cpp]). In principle some kind of alias/mnemonic could also be used, but that is out of the scope of this BIP, and maybe could be developed in another subsequent one.
+: (optional) to uniquely point to a specific chain, the hash of the corresponding genesis block is used (leading zeros included). In principle some kind of alias/mnemonic could also be used, but that is out of the scope of this BIP, and maybe could be developed in another subsequent one. If omitted (which would be the usual case), Bitcoin's mainnet is assumed. As a reference, see for example this code fragment from Bitcoin chainparams.cpp source:
+  const std::map CChainParams::supportedChains =
+      boost::assign::map_list_of
+      ( "main", uint256S("0x000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f"))
+      ( "test", uint256S("0x000000000933ea01ad0ee984209779baaec3ced90fa3f408719526f8d77f4943"))
+      ( "regtest", uint256S("0x0f9188f13cb7b2c71f2a335e3a4fc328bf5beb436012afca590b1a11466e2206"))
+      ;
+
+
 
 ;type: 
 : '''tx''': for transactions.
@@ -35,7 +43,7 @@ Where:
 : '''address''': for addresses.
 
 ;hash: 
-: the relevant hash (or height) to refer to.
+: the relevant hash to refer to (leading zeros included), or block height.
 
 ==Examples==
 
@@ -55,12 +63,17 @@ A transaction on Bitcoin's testnet:
 
 ==Rationale==
 
-From the point of view of a wallet developer (or other tool that need to show any kind of Blockchain references), using this scheme mean that he can simply make it a blockchain: link and be done with it, without having to worry about any specific Blockchain explorer or provide a means for the user to select one.
+From the point of view of a wallet (or other Blockchain related tool) developer that need to show any kind of Blockchain references, using this scheme mean that he can simply make it a blockchain: link and be done with it, without having to worry about any specific Blockchain explorer or provide a means for the user to select one.
 
 Blockchain explorers in turn will simply offer to handle the blockchain: URI, the first time the user visit their website, or launch/install the application, or even set themselves if there isn't already one.
 
 Users get the convenience of using always their preferred explorer, which can be especially handy on mobile devices, where juggling with cut&paste is far from ideal.
 
+==Acknowledgements==
+Thanks to Btc Drak for suggesting to provide support for different networks.
+Thanks to Jorge Timon for the idea of using genesis blocks hashes to identify them.
+Thanks to Richard Moore, Matt Whitlock, Andreas Schildbach for suggestions about the structure and hierarchy of the URI scheme.
+
 ==Copyright==
 
 This document is placed in the public domain.

From 7bce321a18dac4a1be114eeb03fa71da9c1469ed Mon Sep 17 00:00:00 2001
From: jl2012 
Date: Sat, 19 Dec 2015 03:52:06 +0800
Subject: [PATCH 070/259] Create bip-segwit.mediawiki

---
 bip-codeshark-jl2012-segwit.mediawiki | 277 ++++++++++++++++++++++++++
 1 file changed, 277 insertions(+)
 create mode 100644 bip-codeshark-jl2012-segwit.mediawiki

diff --git a/bip-codeshark-jl2012-segwit.mediawiki b/bip-codeshark-jl2012-segwit.mediawiki
new file mode 100644
index 00000000..1fc711d8
--- /dev/null
+++ b/bip-codeshark-jl2012-segwit.mediawiki
@@ -0,0 +1,277 @@
+
+  BIP: x
+  Title: Segregated Witness (Consensus layer)
+  Author: 
+  Status: Draft
+  Type: Standards Track
+  Created: 2015-12
+

+
+==Abstract==
+
+This BIP defines a new structure called a "witness" that is committed to blocks separately from the transaction merkle tree. This structure contains data required to check transaction validity but not required to determine transaction effects. In particular, scripts and signatures are moved into this new structure.
+
+The witness is committed in a tree that is nested into the block's existing merkle root via the coinbase transaction for the purpose of making this BIP soft fork compatible. A future hard fork can place this tree in its own branch.
+
+==Motivation==
+
+The entirety of the transaction's effects are determined by output consumption (spends) and new output creation. Other transaction data, and signatures in particular, are only required to validate the blockchain state, not to determine it.
+
+By removing this data from the transaction structure committed to the transaction merkle tree, several problems are fixed:
+
+# '''Nonintentional malleability becomes impossible'''. Since signature data is no longer part of the transaction hash, changes to how the transaction was authorized is no longer relevant to transaction identification. As a solution of transaction malleability, this is superior to the canonical signature approach (BIP62):
+#* It prevents involuntary transaction malleability for any type of scripts, as long as all inputs are signed (with at least one CHECKSIG or MULTICHECKSIG operation)
+#* In the case of a n-of-m MULTICHECKSIG script, a transaction is malleable only with agreement of n private key holders (as opposed to only 1 private key holder with BIP62)
+#* It prevents involuntary transaction malleability due to unknown ECDSA signature malleability
+#* It allows creation of unconfirmed transaction dependency chains without counterparty risk
+# '''Transmission of signature data becomes optional'''. It is needed only if a peer is trying to validate a transaction, instead of just to prove its existence. This also improves prviacy of SPV clients as using the same bandwidth they could request for more transactions for obscuration.
+# '''Some constriants could be bypassed with a soft fork''' by moving part of the transaction data to a structure unknown to current protocol, for example:
+#* Size of witness could be ignored / discounted when calculating the block size, effectively increasing the block size to some extent
+#* Hard coded constants, such as maximum data push size (520 bytes) or sigops limit could be reevaluated or removed
+#* New script system could be introduced without any limitation from the existing script semantic
+
+==Specification==
+
+Maybe a seperate BIP
+
+* CTransaction gets, in addition to vin and vout, a vwit, which
+contains a CTxInWitness object for each input. A CTxInWitness contains a CScriptWitness object
+and can potentially be extended to contain other kinds of witness data.
+A CScriptWitness is a vector of byte vectors (nominally: the input stack to the program, no longer
+encoded as a CScript, but just the resulting stack directly).
+
+* A new serialization for CTransaction is defined: http://blockhawk.net/diagrams/witnesstx.png
+(int32 nVersion,
+0x00 marker, 0x01 flag, vector, vector,
+vector, int32 nLockTime) instead of (int32 nVersion,
+vector, vector, int32 nLockTime). This will never parse
+as a valid transaction (even if parsing succeeds, it means it's
+interpreted as a transaction with no inputs and 1 output). If all
+witnesses are empty, the old serialization format is used.
+- Rationale for not having an independent CWitnessTransaction with
+its own serialization: this would require separate "tx" and "block"
+messages, and all RPC calls operating on raw transactions would need
+to be duplicated, or need inefficinent or nondeterministic guesswork
+to know which type is to be used.
+- Rationale for not using just a single 0x00 byte as marker: that
+would lead to empty transactions (no inputs, no outputs, which are
+used in some tests) to be interpreted as new serialized data.
+- Rationale for the 0x01 flag byte in between: this will allow us to
+easily add more extra non-committed data to transactions (like txouts
+being spent, ...). It can be interpreted as a bitvector.
+
+* A new message 'havewitness' is sent after receiving 'verack' to
+indicate that a node can provide witness if requested (similar to
+'sendheaders')
+
+* New inv types MSG_WITNESS_TX and MSG_WITNESS_BLOCK are added, only
+for use in getdata. Inv itself still use just MSG_TX and MSG_BLOCK,
+similar to MSG_FILTERED_BLOCK.
+- Rationale for not advertizing witnessness in invs: we don't always
+use invs anymore (with 'sendheaders' BIP 130), plus it's not useful:
+implicitly, every transaction and block have a witness, old ones just
+have empty ones.
+
+* Transactions' GetHash is always computed on the old non-witness
+serialization. A new CTransaction::GetWitnessHash is added which is
+computed from the witness-serialization (this means that transactions
+with an empty witness have witness hash equal to normal hash).
+

+
+=== Commitment structure ===
+
+UPDATE NEEDED
+A new block rule is added which requires a commitment (a merkle root
+computed similarly to the normal transaction one) to the witness
+hashes to be present as the last 32 bytes of
+block.vtx[0].vin[0].scriptSig (it doesn't need to be a push). This
+hopefully does not conflict with any other existing commitment
+schemes. To make it extensible, an extra merkle path can be provided
+(in the coinbase's "witness" field) so that coinbase commitment can be
+used for multiple things.
+
+    // Validation for witness commitments.
+    // * We compute the witness hash (which is the hash including witnesses) of all the block's transactions, except the
+    //   coinbase (where 0x0000....0000 is used instead).
+    // * We build a merkle tree with all those witness hashes as leaves (similar to the hashMerkleRoot in the block header).
+    // * The first coinbase scriptSig minimal push of 41 bytes for which the first 4 bytes are {0xaa, 0x21, 0xa9, 0xed} is
+    //   treated as a commitment header. If no such push is present, the block is invalid. If multiple are present, the first
+    //   is used.
+    //   * The first 4 bytes of the commitment header are just magic identifier bytes, and have no further meaning.
+    //   * The next 4 bytes describe a nonce.
+    //   * The next 1 byte describes the number of levels in a Merkle tree.
+    //   * locator = SHA256('WitnessV1\x00\x00\x00\x00\x00\x00\x00' || nonce). The first levels bits of locator, interpreted
+    //     in little endian, are assumed to be the position in the leaves of this Merkle tree where the witness commitment
+    //     goes.
+    //   * The last 32 bytes of the commitment header are its root hash.
+    //   * The coinbase's input's witness must consist of a single byte array of 32 * levels bytes, and are assumed to be
+    //     the Merkle path to connect the witness root hash to the commitment root hash.
+    
+    // No witness data is allowed in blocks that don't commit to witness data, as this would otherwise leave room from spam.
+

+
+=== Block size limit ===
+2-4-8? Discount for witness data?
+
+=== Witness program ===
+
+* A scriptPubKey (or redeemScript as defined in BIP16/P2SH) that consists of a single push of 2 to 41 bytes gets a new special meaning. The byte vector pushed by it is called the "witness program".
+** In case the scriptPubKey pushes a witness program directly, the scriptSig must be exactly empty.
+** In case the redeemScript pushes a witness program, the scriptSig must be exactly the single push of the redeemScript.
+
+* The first byte of a witness program is the "version byte", an unsigned integer.
+** If the version byte is 0, the rest of the witness program is the actual script.
+*** The script is executed after normal script evaluation but with data from the witness rather than the scriptSig.
+*** The program must not fail, and result in exactly a single TRUE on the stack.
+** If the version byte is 1, the rest of the witness program must be 32 bytes, as a SHA256 hash of the actual script.
+*** The witness must consist of an input stack to feed to the program, followed by the serialized program.
+*** The serialized program is popped off the initial witness stack. Hash of the serialized program must match the hash pushed in the witness program.
+*** The serialized program is deserialized, and executed after normal script evaluation with the remaining witness stack.
+*** The script must not fail, and result in exactly a single TRUE on the stack.
+** If the witness version byte is 2 or above, no further interpretation of the witness program or witness happens.
+
+=== Other consensus critical constraints ===
+
+== Block size analysis ==
+Definitions:
+
+ Core block size (CBS): The block size as seen by a non-upgrading full node
+ Witness size (WS): The total size of witness in a block
+ Total block size (TBS): CBS + WS
+ Witness discount (WD): A discount factor for witness for calculationg of VBS (1 = no discount)
+ Virtual block size (VBS): CBS + (WS * WD)
+ Witness adoption (WA): Proportion of new format transactions among all transactions
+ Prunable ratio (PR): Proportion of signature data size in a transaction
+

+
+With some transformation it could be shown that:
+
+ TBS = CBS / (1 - WA * PR)
+     = VBS / (1 - WA * PR * (1 - WD))
+

+
+In order to keep the proposal as a soft fork, the CBS must not have a upper limit higher than 1MB.
+
+TBS is a function of only CBS, PR, and WA.
+
+The PR heavily depends on the transaction script type and input-output ratio. For example, the PR of 1-in 2-out P2PKH and 1-in 1-out 2-of-2 multisig P2SH are about 47% and 72% respectively. According to the data presented by Pieter Wuille on 7 December 2015, the current average PR on the blockchain is about 60%.
+
+
+
+== Examples ==
+
+=== Version 0 witness program ===
+
+The following example is a version 0 witness program, equivalent to the existing Pay-to-Pubkey-Hash (P2PKH) output.
+
+    witness:       
+    scriptSig:    (empty)
+    scriptPubKey: <0x0076A914{20-byte-hash-value}88AC>
+
+The version byte 0x00 is removed. The rest of the witness program is deserialized and becomes:
+
+    DUP HASH160 <20byte-hash-value> EQUALVERIFY CHECKSIG
+
+The script is executed with the data from witness
+
+      DUP HASH160 <20byte-hash-value> EQUALVERIFY CHECKSIG
+
+Comparing with a P2PKH output, the witness program equivalent occupies 2 more bytes in the scriptPubKey, while moving the signature and public key from scriptSig to witness.
+
+=== Version 1 witness program ===
+
+The following example is an 1-of-2 multi-signature version 1 witness program.
+
+    witness:      0  <0x5121{33-byte-pubkey1}21{33-byte-pubkey2}52AE>
+    scriptSig:    (empty)
+    scriptPubKey: <0x01{32-byte-hash-value}>
+
+The last item in the witness is popped off, hashed with SHA256, compared against the 32-byte-hash-value in scriptPubKey, and deserialized:
+
+    1 <33-byte-pubkey1> <33-byte-pubkey2> 2 CHECKMULTISIG
+
+The script is executed with the remaining data from witness:
+
+    0  1 <33-byte-pubkey1> <33-byte-pubkey2> 2 CHECKMULTISIG
+
+Since the actual program is larger than 40 bytes, it cannot be accommodated in a version 0 witness program. A version 1 witness program allows arbitrarily large script as the 520-byte push limit is bypassed.
+
+The scriptPubKey occupies 34 bytes, as opposed to 23 bytes of P2SH. The increased size improves security against possible collision attacks, as 2^80 work is not infeasible anymore (By the end of 2015, 2^84 hashes have been calculated in Bitcoin mining since the creation of Bitcoin). The spending script is same as the one for an equivalent P2SH output but is moved to witness.
+
+=== Witness program nested in Pay-to-Script-Hash ===
+
+The following example is the same 1-of-2 multi-signature version 1 witness program, but nested in a P2SH output.
+
+    witness:      0  <0x5121{33-byte-pubkey1}21{33-byte-pubkey2}52AE>
+    scriptSig:    <0x2101{32-byte-hash-value}>
+    scriptPubKey: HASH160 <20-byte-hash-value> EQUAL
+
+The only item in scriptSig is hashed with HASH160, compared against the 20-byte-hash-value in scriptPubKey, and interpreted as a single push of:
+
+    <0x01{32-byte-hash-value}>
+
+The version 1 witness program is then executed as described in the last example
+
+Comparing with the last example, the scriptPubKey is 11 bytes smaller (with reduced security) while witness is the same. However, it also requires 35 bytes in scriptSig, which is not prunable in transmission. Although a nested witness program is less efficient in many ways, its payment address is fully transparent and backward compatible for all Bitcoin reference client since version 0.6.0.
+
+=== Trust-free unconfirmed transaction dependency chain ===
+Segregated witness fixes the problem of transaction malleability fundamentally, which enables the building of unconfirmed transaction dependency chains in a trust-free manner.
+
+Two parties, Alice and Bob, may agree to send certain amount of Bitcoin to a 2-of-2 multisig output (the "funding transaction"). Without signing the funding transaction, they may create another transaction, time-locked in the future, spending the 2-of-2 multisig output to third account(s) (the "spending transaction"). Alice and Bob will sign the spending transaction and exchange the signatures. After examining the signatures, they will sign and commit the funding transaction to the blockchain. Without further action, the spending transaction will be confirmed after the lock-time and release the funding according to the original contract. It also retains the flexibility of revoking the original contract before the lock-time, by another spending transaction with shorter lock-time, but only with mutual-agreement of both parties.
+
+Such setups is not possible with BIP62 as the malleability fix, since the spending transaction could not be created without both parties first signing the funding transaction. If Alice reveals the funding transaction signature before Bob does, Bob is able to lock up the funding indefinitely without ever signing the spending transaction.
+
+Unconfirmed transaction dependency chain is a fundamental building block of more sophisticated payment networks, such as duplex micropayment channel and the Lightning Network, which have the potential to greatly improve the scalability and efficiency of the Bitcoin system.
+
+== Future extensions ==
+=== Compact fraud proof for SPV nodes ===
+Bitcoin right now only has two real security models. A user either runs a full-node which validates every block with all rules in the system, or a SPV (Simple Payment Verification) client which only validates the headers as a proof of publication of some transactions. The Bitcoin whitepaper suggested that SPV nodes may accept alerts from full nodes when they detect an invalid block, prompting the SPV node to download the questioned blocks and transactions for validation. This approach, however, could become a DoS attack vector as there is virtually no cost to generate a false alarm. An alarm must come with a compact, yet deterministic fraud proof.
+
+In the current Bitcoin protocol, it is possible to generate compact fraud proof for almost all rules except a few:
+
+# It is not possible to proof a miner has introduced too many Bitcoins in the coinbase transaction outputs without showing the whole block itself and all input transactions.
+# It is not possible to prove the violation of any block specific constraints, such as size and sigop limits, without showing the whole block (and all input transactions in the case of sigop limit)
+# It is not possible to prove the spending of a non-existing input without showing all transaction IDs in the blockchain way back to the genesis block.
+
+It is possible to proof the first 2 types of fraud if a block is committed to a Merkle-sum-tree of the fee, size, and sigop count of each transaction. It is also possible to proof the last type of fraud if a block is committed to a Merkle tree with the originating block height and transaction index of all inputs. These commitments could be included in the extensible witness commitment through a soft fork and will be transparent to nodes that do not understand such new rules.
+
+=== New script system ===
+Since all witness programs begin with a version byte, and programs with unknown versions are always considered as anyone-can-spend script, it is possible to introduce any new script system with a soft fork. The witness as a structure is not restricted by any existing script semantics and constraints, the 520-byte push limit in particular, and therefore allows arbitrarily large scripts and signatures.
+
+Examples of new script system include Schnorr signatures which reduce the size of multisig transactions dramatically, Lamport signature which is quantum computing resistance, and Merklized abstract syntax trees which allow very compact witness for conditional scripts with extreme complexity.
+
+The 41-byte limitation for witness programme could be easily extended through a soft fork in case a stronger hash function is needed in the future. The version byte is also expandable by introducing a secondary version byte for some specific primary version values.
+
+== Backward compatibility ==
+Without lifting the core block size limit of 1MB at the beginning, this proposal is a soft fork which all existing full nodes and SPV nodes are compatible. Non-upgrading nodes, however, will not see nor validate the witness data, and will consider all witness programs as anyone-can-spend scripts (except a few edge cases in version 0 witness programs which are provably unspendable with original script semantics). Non-upgrading nodes are also unable to generate or sign for scriptPubKey templates (payment address). Nonetheless, they may still pay to a witness program if it is nested in a P2SH address, which has been defined since 2012.
+
+When the core block size limit is increased to over 1MB as scheduled, this proposal becomes a hard fork. Anybody running code that fully validates blocks must upgrade before the activation time or they will reject a chain containing blocks with core block size above 1MB. SPV software is not affected, unless it makes assumptions about the maximum depth of the Merkle tree based on the minimum size of a transaction and the maximum block size.
+
+== Deployment ==
+
+We reuse the double-threshold IsSuperMajority() switchover mechanism used in
+BIP65 with the same thresholds, but for nVersion = 5. The new rules are
+in effect for every block (at height H) with nVersion = 5 and at least
+750 out of 1000 blocks preceding it (with heights H-1000..H-1) also
+have nVersion >= 5. Furthermore, when 950 out of the 1000 blocks
+preceding a block do have nVersion >= 5, nVersion < 5 blocks become
+invalid, and all further blocks enforce the new rules.
+
+It should be noted that BIP9 involves permanently setting a high-order bit to
+1 which results in nVersion >= all prior IsSuperMajority() soft-forks and thus
+no bits in nVersion are permanently lost.
+
+
+=== SPV Clients ===
+
+While SPV clients are (currently) unable to validate blocks in general,
+trusting miners to do validation for them, they are able to validate block
+headers and thus can validate a subset of the deployment rules. SPV clients
+should reject nVersion < 5 blocks if 950 out of 1000 preceding blocks have
+nVersion >= 5 to prevent false confirmations from the remaining 5% of
+non-upgraded miners when the 95% threshold has been reached.
+
+== Credits ==
+
+== Reference Implementation ==
+https://github.com/sipa/bitcoin/commits/segwit

From 1817685aa94fdc5a58823e7e0a407463bea55ae0 Mon Sep 17 00:00:00 2001
From: Eric Lombrozo 
Date: Sat, 19 Dec 2015 21:55:26 -0500
Subject: [PATCH 071/259] Added fraud proof motivation.

---
 bip-codeshark-jl2012-segwit.mediawiki | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/bip-codeshark-jl2012-segwit.mediawiki b/bip-codeshark-jl2012-segwit.mediawiki
index 1fc711d8..703954c0 100644
--- a/bip-codeshark-jl2012-segwit.mediawiki
+++ b/bip-codeshark-jl2012-segwit.mediawiki
@@ -29,6 +29,9 @@ By removing this data from the transaction structure committed to the transactio
 #* Size of witness could be ignored / discounted when calculating the block size, effectively increasing the block size to some extent
 #* Hard coded constants, such as maximum data push size (520 bytes) or sigops limit could be reevaluated or removed
 #* New script system could be introduced without any limitation from the existing script semantic
+# '''Additional data required for fraud proofs can be added to witness'''. Extra data can be committed that allows short proofs of block invalidity that SPV nodes can quickly verify.
+#* Backlinks for the outputs spent by the transaction's inputs can be provided. These backlinks consist of a block hash and an offset that thin clients can easily query and check to verify that the outputs exist.
+#* Sum trees for transaction inputs and outputs can be committed making it possible to construct short proofs that no new coins are created in any noncoinbase transaction and that the miner does not add excessive fees to the coinbase transaction. 
 
 ==Specification==
 

From 1cdf145b9b74f465b514b19067c6a781769fdc77 Mon Sep 17 00:00:00 2001
From: jl2012 
Date: Mon, 21 Dec 2015 13:27:25 +0800
Subject: [PATCH 072/259] Update bip-segwit.mediawiki

---
 bip-codeshark-jl2012-segwit.mediawiki | 93 ++++++++++++++++-----------
 1 file changed, 56 insertions(+), 37 deletions(-)

diff --git a/bip-codeshark-jl2012-segwit.mediawiki b/bip-codeshark-jl2012-segwit.mediawiki
index 703954c0..cc87de3c 100644
--- a/bip-codeshark-jl2012-segwit.mediawiki
+++ b/bip-codeshark-jl2012-segwit.mediawiki
@@ -34,7 +34,6 @@ By removing this data from the transaction structure committed to the transactio
 #* Sum trees for transaction inputs and outputs can be committed making it possible to construct short proofs that no new coins are created in any noncoinbase transaction and that the miner does not add excessive fees to the coinbase transaction. 
 
 ==Specification==
-
 Maybe a seperate BIP
 
 * CTransaction gets, in addition to vin and vout, a vwit, which
@@ -42,7 +41,6 @@ contains a CTxInWitness object for each input. A CTxInWitness contains a CScript
 and can potentially be extended to contain other kinds of witness data.
 A CScriptWitness is a vector of byte vectors (nominally: the input stack to the program, no longer
 encoded as a CScript, but just the resulting stack directly).
-
 * A new serialization for CTransaction is defined: http://blockhawk.net/diagrams/witnesstx.png
 (int32 nVersion,
 0x00 marker, 0x01 flag, vector, vector,
@@ -83,38 +81,54 @@ with an empty witness have witness hash equal to normal hash).
 
 === Commitment structure ===
 
-UPDATE NEEDED
-A new block rule is added which requires a commitment (a merkle root
-computed similarly to the normal transaction one) to the witness
-hashes to be present as the last 32 bytes of
-block.vtx[0].vin[0].scriptSig (it doesn't need to be a push). This
-hopefully does not conflict with any other existing commitment
-schemes. To make it extensible, an extra merkle path can be provided
-(in the coinbase's "witness" field) so that coinbase commitment can be
-used for multiple things.
-
-    // Validation for witness commitments.
-    // * We compute the witness hash (which is the hash including witnesses) of all the block's transactions, except the
-    //   coinbase (where 0x0000....0000 is used instead).
-    // * We build a merkle tree with all those witness hashes as leaves (similar to the hashMerkleRoot in the block header).
-    // * The first coinbase scriptSig minimal push of 41 bytes for which the first 4 bytes are {0xaa, 0x21, 0xa9, 0xed} is
-    //   treated as a commitment header. If no such push is present, the block is invalid. If multiple are present, the first
-    //   is used.
-    //   * The first 4 bytes of the commitment header are just magic identifier bytes, and have no further meaning.
-    //   * The next 4 bytes describe a nonce.
-    //   * The next 1 byte describes the number of levels in a Merkle tree.
-    //   * locator = SHA256('WitnessV1\x00\x00\x00\x00\x00\x00\x00' || nonce). The first levels bits of locator, interpreted
-    //     in little endian, are assumed to be the position in the leaves of this Merkle tree where the witness commitment
-    //     goes.
-    //   * The last 32 bytes of the commitment header are its root hash.
-    //   * The coinbase's input's witness must consist of a single byte array of 32 * levels bytes, and are assumed to be
-    //     the Merkle path to connect the witness root hash to the commitment root hash.
-    
-    // No witness data is allowed in blocks that don't commit to witness data, as this would otherwise leave room from spam.
-

+!!!DRAFT ONLY!!!
+
+A new block rule is added which requires a commitment to the witness hashes in the coinbase (or an OP_RETURN output of a specific transaction, or somewhere else)
+
+(Hardfork after x year to move the commitment to block header?)
+
+Witness hash is the double SHA256 of a transaction including witnesses: http://blockhawk.net/diagrams/witnesstx.png. For the coinbase transaction, its witness hash is assumed to be 0x0000....0000.
+
+A witness root hash is calculated with all those witness hashes as leaves, in a way similar to the hashMerkleRoot in the block header.
+
+No witness data is allowed in blocks that don't commit to witness data, as this would otherwise leave room from spam.
+
+==== Proposal 1: balance tree (the current implementation) ====
+The commitment is a push of exactly 41 bytes:
+*The first 4 bytes are commitment header: 0xaa21a9ed
+*The next 4 bytes describe a nonce
+*The next 1 byte is the "levels bytes", describes the number of levels in a Merkle tree (0 to 32)
+*The next 32 bytes is a commitment root hash (not the witness root hash)
+
+Locator of the witness root hash is defined as:
+
+
SHA256('WitnessV1\x00\x00\x00\x00\x00\x00\x00' || nonce)

+
+The first levels bits of locator, interpreted in little endian, are assumed to be the position in the leaves of the Merkle tree where the witness root hash goes.
+
+The coinbase's input's witness must consist of a single byte array of 32 * levels bytes, and are assumed to be the Merkle path to connect the witness root hash to the commitment root hash.
+
+====Proposal 2: imbalance tree====
+The commitment is a push of exactly 40 bytes:
+*The first 4 bytes are commitment header: 0xaa21a9ed
+*The next 4 bytes describe a nonce
+*The next 32 bytes is a commitment root hash (not the witness root hash)
+
+Locator of the witness root hash is defined as:
+
+
SHA256('WitnessV1\x00\x00\x00\x00\x00\x00\x00' || nonce)

+
+The first levels bits of locator, interpreted in little endian, are assumed to be the position in the leaves of the Merkle tree where the witness root hash goes.
+
+The coinbase's input's witness must consist of a single byte array, which the size must be a multiple of 32 bytes but not bigger than 32*32 bytes. These are assumed to be the Merkle path to connect the witness root hash to the commitment root hash. Depth of the commitment is determined by the length of the path. If the depth of the tree is 0, the path should be represented by 0x00, and the witness root hash will be same as the commitment root hash.
 
 === Block size limit ===
-2-4-8? Discount for witness data?
+A seperate BIP?
+
+2-4-8?
+Discount for witness data?
+Start at softfork, moving to hardfork?
+

 
 === Witness program ===
 
@@ -136,14 +150,16 @@ used for multiple things.
 === Other consensus critical constraints ===
 
 == Block size analysis ==
+WORK IN PROGRESS
+
 Definitions:
 
  Core block size (CBS): The block size as seen by a non-upgrading full node
- Witness size (WS): The total size of witness in a block
+ Witness size (WS): The total size of witness data in a block
  Total block size (TBS): CBS + WS
- Witness discount (WD): A discount factor for witness for calculationg of VBS (1 = no discount)
+ Witness discount (WD): A discount factor for witness data in VBS calculation (1 = no discount)
  Virtual block size (VBS): CBS + (WS * WD)
- Witness adoption (WA): Proportion of new format transactions among all transactions
+ Witness adoption (WA): Proportion (in size) of new format transactions among all transactions
  Prunable ratio (PR): Proportion of signature data size in a transaction
 

 
@@ -155,8 +171,6 @@ With some transformation it could be shown that:
 
 In order to keep the proposal as a soft fork, the CBS must not have a upper limit higher than 1MB.
 
-TBS is a function of only CBS, PR, and WA.
-
 The PR heavily depends on the transaction script type and input-output ratio. For example, the PR of 1-in 2-out P2PKH and 1-in 1-out 2-of-2 multisig P2SH are about 47% and 72% respectively. According to the data presented by Pieter Wuille on 7 December 2015, the current average PR on the blockchain is about 60%.
 
 
@@ -245,6 +259,11 @@ Examples of new script system include Schnorr signatures which reduce the size o
 
 The 41-byte limitation for witness programme could be easily extended through a soft fork in case a stronger hash function is needed in the future. The version byte is also expandable by introducing a secondary version byte for some specific primary version values.
 
+=== Per-input lock-time and relative-lock-time ===
+Currently there is only one nLockTime field in a transaction and all inputs must share the same value. BIP68 enables per-input relative-lock-time using the nSequence field, however, with a limited lock-time period and resolution.
+
+With a soft fork, it is possible to introduce a separate witness structure to allow per-input lock-time and relative-lock-time, and a new script system that could sign and manipulate the new data (like BIP65 and BIP112).
+
 == Backward compatibility ==
 Without lifting the core block size limit of 1MB at the beginning, this proposal is a soft fork which all existing full nodes and SPV nodes are compatible. Non-upgrading nodes, however, will not see nor validate the witness data, and will consider all witness programs as anyone-can-spend scripts (except a few edge cases in version 0 witness programs which are provably unspendable with original script semantics). Non-upgrading nodes are also unable to generate or sign for scriptPubKey templates (payment address). Nonetheless, they may still pay to a witness program if it is nested in a P2SH address, which has been defined since 2012.
 

From f026c28da5d32489c0c2346c33664d2b8a2f7d16 Mon Sep 17 00:00:00 2001
From: Eric Lombrozo 
Date: Tue, 22 Dec 2015 06:15:05 -0500
Subject: [PATCH 073/259] MULICHECKSIG -> CHECKMULTISIG

n-of-m -> m-of-n

LN motivation

smaller SPV proof motivation
---
 bip-codeshark-jl2012-segwit.mediawiki | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/bip-codeshark-jl2012-segwit.mediawiki b/bip-codeshark-jl2012-segwit.mediawiki
index cc87de3c..f7026d6c 100644
--- a/bip-codeshark-jl2012-segwit.mediawiki
+++ b/bip-codeshark-jl2012-segwit.mediawiki
@@ -20,11 +20,11 @@ The entirety of the transaction's effects are determined by output consumption (
 By removing this data from the transaction structure committed to the transaction merkle tree, several problems are fixed:
 
 # '''Nonintentional malleability becomes impossible'''. Since signature data is no longer part of the transaction hash, changes to how the transaction was authorized is no longer relevant to transaction identification. As a solution of transaction malleability, this is superior to the canonical signature approach (BIP62):
-#* It prevents involuntary transaction malleability for any type of scripts, as long as all inputs are signed (with at least one CHECKSIG or MULTICHECKSIG operation)
-#* In the case of a n-of-m MULTICHECKSIG script, a transaction is malleable only with agreement of n private key holders (as opposed to only 1 private key holder with BIP62)
+#* It prevents involuntary transaction malleability for any type of scripts, as long as all inputs are signed (with at least one CHECKSIG or CHECKMULTISIG operation)
+#* In the case of an m-of-n CHECKMULTISIG script, a transaction is malleable only with agreement of m private key holders (as opposed to only 1 private key holder with BIP62)
 #* It prevents involuntary transaction malleability due to unknown ECDSA signature malleability
-#* It allows creation of unconfirmed transaction dependency chains without counterparty risk
-# '''Transmission of signature data becomes optional'''. It is needed only if a peer is trying to validate a transaction, instead of just to prove its existence. This also improves prviacy of SPV clients as using the same bandwidth they could request for more transactions for obscuration.
+#* It allows creation of unconfirmed transaction dependency chains without counterparty risk, an important feature for offchain protocols such as the Lightning Network
+# '''Transmission of signature data becomes optional'''. It is needed only if a peer is trying to validate a transaction instead of just checking its existence. This reduces the size of SPV proofs and potentially improves the privacy of SPV clients as they can download more transactions using the same bandwidth.
 # '''Some constriants could be bypassed with a soft fork''' by moving part of the transaction data to a structure unknown to current protocol, for example:
 #* Size of witness could be ignored / discounted when calculating the block size, effectively increasing the block size to some extent
 #* Hard coded constants, such as maximum data push size (520 bytes) or sigops limit could be reevaluated or removed

From 26a7293e67740b6bba854d0feb2ed25875c9037d Mon Sep 17 00:00:00 2001
From: Johnson Lau 
Date: Tue, 22 Dec 2015 22:54:40 +0800
Subject: [PATCH 074/259] Update bip-segwit.mediawiki

---
 bip-codeshark-jl2012-segwit.mediawiki | 10 ++--------
 1 file changed, 2 insertions(+), 8 deletions(-)

diff --git a/bip-codeshark-jl2012-segwit.mediawiki b/bip-codeshark-jl2012-segwit.mediawiki
index f7026d6c..5c0d28ea 100644
--- a/bip-codeshark-jl2012-segwit.mediawiki
+++ b/bip-codeshark-jl2012-segwit.mediawiki
@@ -123,12 +123,8 @@ The first levels bits of locator, interpreted in little endian, are assumed to b
 The coinbase's input's witness must consist of a single byte array, which the size must be a multiple of 32 bytes but not bigger than 32*32 bytes. These are assumed to be the Merkle path to connect the witness root hash to the commitment root hash. Depth of the commitment is determined by the length of the path. If the depth of the tree is 0, the path should be represented by 0x00, and the witness root hash will be same as the commitment root hash.
 
 === Block size limit ===
-A seperate BIP?
-
-2-4-8?
 Discount for witness data?
-Start at softfork, moving to hardfork?
-

+Virtual block size limit?
 
 === Witness program ===
 
@@ -265,9 +261,7 @@ Currently there is only one nLockTime field in a transaction and all inputs must
 With a soft fork, it is possible to introduce a separate witness structure to allow per-input lock-time and relative-lock-time, and a new script system that could sign and manipulate the new data (like BIP65 and BIP112).
 
 == Backward compatibility ==
-Without lifting the core block size limit of 1MB at the beginning, this proposal is a soft fork which all existing full nodes and SPV nodes are compatible. Non-upgrading nodes, however, will not see nor validate the witness data, and will consider all witness programs as anyone-can-spend scripts (except a few edge cases in version 0 witness programs which are provably unspendable with original script semantics). Non-upgrading nodes are also unable to generate or sign for scriptPubKey templates (payment address). Nonetheless, they may still pay to a witness program if it is nested in a P2SH address, which has been defined since 2012.
-
-When the core block size limit is increased to over 1MB as scheduled, this proposal becomes a hard fork. Anybody running code that fully validates blocks must upgrade before the activation time or they will reject a chain containing blocks with core block size above 1MB. SPV software is not affected, unless it makes assumptions about the maximum depth of the Merkle tree based on the minimum size of a transaction and the maximum block size.
+Without lifting the core block size limit of 1MB, this proposal is a soft fork which all existing full nodes and SPV nodes are compatible. Non-upgrading nodes, however, will not see nor validate the witness data, and will consider all witness programs as anyone-can-spend scripts (except a few edge cases in version 0 witness programs which are provably unspendable with original script semantics). Non-upgrading nodes are also unable to generate or sign for scriptPubKey templates (payment address). Nonetheless, they may still pay to a witness program if it is nested in a P2SH address, which has been defined since 2012.
 
 == Deployment ==
 

From 7f196396d34d5cf1ad36491f87880ff6ef25ff90 Mon Sep 17 00:00:00 2001
From: Eric Lombrozo 
Date: Tue, 22 Dec 2015 19:45:26 -0500
Subject: [PATCH 075/259] Updates to backward compatibility section

---
 bip-codeshark-jl2012-segwit.mediawiki | 21 ++++++++++++++-------
 1 file changed, 14 insertions(+), 7 deletions(-)

diff --git a/bip-codeshark-jl2012-segwit.mediawiki b/bip-codeshark-jl2012-segwit.mediawiki
index 5c0d28ea..efed2b27 100644
--- a/bip-codeshark-jl2012-segwit.mediawiki
+++ b/bip-codeshark-jl2012-segwit.mediawiki
@@ -261,7 +261,15 @@ Currently there is only one nLockTime field in a transaction and all inputs must
 With a soft fork, it is possible to introduce a separate witness structure to allow per-input lock-time and relative-lock-time, and a new script system that could sign and manipulate the new data (like BIP65 and BIP112).
 
 == Backward compatibility ==
-Without lifting the core block size limit of 1MB, this proposal is a soft fork which all existing full nodes and SPV nodes are compatible. Non-upgrading nodes, however, will not see nor validate the witness data, and will consider all witness programs as anyone-can-spend scripts (except a few edge cases in version 0 witness programs which are provably unspendable with original script semantics). Non-upgrading nodes are also unable to generate or sign for scriptPubKey templates (payment address). Nonetheless, they may still pay to a witness program if it is nested in a P2SH address, which has been defined since 2012.
+As a soft fork, older software will continue to operate without modification.  Non-upgraded nodes, however, will not see nor validate the witness data and will consider all witness programs as anyone-can-spend scripts (except a few edge cases in version 0 witness programs which are provably unspendable with original script semantics). Wallets should always be wary of anyone-can-spend scripts and treat them with suspicion. Non-upgraded nodes are strongly encouraged to upgrade in order to take advantage of the new features.
+
+Wallets will be able to migrate in two phases:
+
+=== P2SH compatibility ===
+Witness programs are hashed to 256 bit "redeemscripts" which are then hashed to 160 bit P2SH. This format is fully compatible with currently existing wallets that support P2SH. Upgraded wallets will be able to send and receive to and from older wallets without any problems.
+
+=== Native outputs ===
+Witness programs are hashed to a 256 bit output. This format will not be compatible with older wallets but will require less block space and will have better security due to increased collision resistance.
 
 == Deployment ==
 
@@ -273,17 +281,16 @@ have nVersion >= 5. Furthermore, when 950 out of the 1000 blocks
 preceding a block do have nVersion >= 5, nVersion < 5 blocks become
 invalid, and all further blocks enforce the new rules.
 
-It should be noted that BIP9 involves permanently setting a high-order bit to
+(It should be noted that BIP9 involves permanently setting a high-order bit to
 1 which results in nVersion >= all prior IsSuperMajority() soft-forks and thus
-no bits in nVersion are permanently lost.
+no bits in nVersion are permanently lost.)
 
 
 === SPV Clients ===
 
-While SPV clients are (currently) unable to validate blocks in general,
-trusting miners to do validation for them, they are able to validate block
-headers and thus can validate a subset of the deployment rules. SPV clients
-should reject nVersion < 5 blocks if 950 out of 1000 preceding blocks have
+While SPV clients are unable to fully validate blocks,
+they are able to validate block headers and, thus, can check block version and proof-of-work.
+SPV clients should reject nVersion < 5 blocks if 950 out of 1000 preceding blocks have
 nVersion >= 5 to prevent false confirmations from the remaining 5% of
 non-upgraded miners when the 95% threshold has been reached.
 

From a208f3de00a7a79cf5cdc1731b6f7d166e799e37 Mon Sep 17 00:00:00 2001
From: Eric Lombrozo 
Date: Tue, 22 Dec 2015 21:06:10 -0500
Subject: [PATCH 076/259] Copyright statement

---
 bip-codeshark-jl2012-segwit.mediawiki | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/bip-codeshark-jl2012-segwit.mediawiki b/bip-codeshark-jl2012-segwit.mediawiki
index efed2b27..da624122 100644
--- a/bip-codeshark-jl2012-segwit.mediawiki
+++ b/bip-codeshark-jl2012-segwit.mediawiki
@@ -298,3 +298,6 @@ non-upgraded miners when the 95% threshold has been reached.
 
 == Reference Implementation ==
 https://github.com/sipa/bitcoin/commits/segwit
+
+== Copyright ==
+This document is placed in the public domain.

From 656b72695dc0a6d63cb691b02befc15039f7e5bc Mon Sep 17 00:00:00 2001
From: Eric Lombrozo 
Date: Tue, 22 Dec 2015 21:15:11 -0500
Subject: [PATCH 077/259] Credits

---
 bip-codeshark-jl2012-segwit.mediawiki | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/bip-codeshark-jl2012-segwit.mediawiki b/bip-codeshark-jl2012-segwit.mediawiki
index da624122..df43c273 100644
--- a/bip-codeshark-jl2012-segwit.mediawiki
+++ b/bip-codeshark-jl2012-segwit.mediawiki
@@ -1,7 +1,7 @@
 
   BIP: x
   Title: Segregated Witness (Consensus layer)
-  Author: 
+  Authors: Eric Lombrozo , Johnson Lau , Pieter Wuille 
   Status: Draft
   Type: Standards Track
   Created: 2015-12
@@ -295,6 +295,7 @@ nVersion >= 5 to prevent false confirmations from the remaining 5% of
 non-upgraded miners when the 95% threshold has been reached.
 
 == Credits ==
+Special thanks to Gregory Maxwell for originating many of the ideas in this BIP and Luke-Jr for figuring out how to deploy this as a soft fork.
 
 == Reference Implementation ==
 https://github.com/sipa/bitcoin/commits/segwit

From ec059d15822228d11a2c21a14fe6b91d2307888b Mon Sep 17 00:00:00 2001
From: Eric Lombrozo 
Date: Tue, 22 Dec 2015 21:24:47 -0500
Subject: [PATCH 078/259] Wallet migration phase update

---
 bip-codeshark-jl2012-segwit.mediawiki | 6 ++----
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/bip-codeshark-jl2012-segwit.mediawiki b/bip-codeshark-jl2012-segwit.mediawiki
index df43c273..72bb9806 100644
--- a/bip-codeshark-jl2012-segwit.mediawiki
+++ b/bip-codeshark-jl2012-segwit.mediawiki
@@ -263,12 +263,10 @@ With a soft fork, it is possible to introduce a separate witness structure to al
 == Backward compatibility ==
 As a soft fork, older software will continue to operate without modification.  Non-upgraded nodes, however, will not see nor validate the witness data and will consider all witness programs as anyone-can-spend scripts (except a few edge cases in version 0 witness programs which are provably unspendable with original script semantics). Wallets should always be wary of anyone-can-spend scripts and treat them with suspicion. Non-upgraded nodes are strongly encouraged to upgrade in order to take advantage of the new features.
 
-Wallets will be able to migrate in two phases:
-
-=== P2SH compatibility ===
+=== Version 0 witness programs ===
 Witness programs are hashed to 256 bit "redeemscripts" which are then hashed to 160 bit P2SH. This format is fully compatible with currently existing wallets that support P2SH. Upgraded wallets will be able to send and receive to and from older wallets without any problems.
 
-=== Native outputs ===
+=== Version 1 witness programs ===
 Witness programs are hashed to a 256 bit output. This format will not be compatible with older wallets but will require less block space and will have better security due to increased collision resistance.
 
 == Deployment ==

From 4c0863a2e406c7706b8ee44e6074d3bdf080a458 Mon Sep 17 00:00:00 2001
From: Eric Lombrozo 
Date: Tue, 22 Dec 2015 21:43:05 -0500
Subject: [PATCH 079/259] typo fix

---
 bip-codeshark-jl2012-segwit.mediawiki | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/bip-codeshark-jl2012-segwit.mediawiki b/bip-codeshark-jl2012-segwit.mediawiki
index 72bb9806..f44c6f1e 100644
--- a/bip-codeshark-jl2012-segwit.mediawiki
+++ b/bip-codeshark-jl2012-segwit.mediawiki
@@ -25,7 +25,7 @@ By removing this data from the transaction structure committed to the transactio
 #* It prevents involuntary transaction malleability due to unknown ECDSA signature malleability
 #* It allows creation of unconfirmed transaction dependency chains without counterparty risk, an important feature for offchain protocols such as the Lightning Network
 # '''Transmission of signature data becomes optional'''. It is needed only if a peer is trying to validate a transaction instead of just checking its existence. This reduces the size of SPV proofs and potentially improves the privacy of SPV clients as they can download more transactions using the same bandwidth.
-# '''Some constriants could be bypassed with a soft fork''' by moving part of the transaction data to a structure unknown to current protocol, for example:
+# '''Some constraints could be bypassed with a soft fork''' by moving part of the transaction data to a structure unknown to current protocol, for example:
 #* Size of witness could be ignored / discounted when calculating the block size, effectively increasing the block size to some extent
 #* Hard coded constants, such as maximum data push size (520 bytes) or sigops limit could be reevaluated or removed
 #* New script system could be introduced without any limitation from the existing script semantic

From 181280bed71acbee34ea5c83671b240ed28545dd Mon Sep 17 00:00:00 2001
From: Eric Lombrozo 
Date: Tue, 22 Dec 2015 21:52:55 -0500
Subject: [PATCH 080/259] Added block size limit

---
 bip-codeshark-jl2012-segwit.mediawiki | 7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/bip-codeshark-jl2012-segwit.mediawiki b/bip-codeshark-jl2012-segwit.mediawiki
index f44c6f1e..61f341e7 100644
--- a/bip-codeshark-jl2012-segwit.mediawiki
+++ b/bip-codeshark-jl2012-segwit.mediawiki
@@ -123,8 +123,11 @@ The first levels bits of locator, interpreted in little endian, are assumed to b
 The coinbase's input's witness must consist of a single byte array, which the size must be a multiple of 32 bytes but not bigger than 32*32 bytes. These are assumed to be the Merkle path to connect the witness root hash to the commitment root hash. Depth of the commitment is determined by the length of the path. If the depth of the tree is 0, the path should be represented by 0x00, and the witness root hash will be same as the commitment root hash.
 
 === Block size limit ===
-Discount for witness data?
-Virtual block size limit?
+Blocks are currently limited to 1 MB total size. We change this restriction as follows:
+
+We define a base block size sb consisting of the existing header and transactions, a witness size sw consisting of only the size of the witness data, and a virtual block size sv = sb + sw/4.
+
+The new rule is sv <= 1 MB.
 
 === Witness program ===
 

From 8fd3a42a954683268d158639aa7d602309950720 Mon Sep 17 00:00:00 2001
From: Eric Lombrozo 
Date: Wed, 23 Dec 2015 09:57:37 -0500
Subject: [PATCH 081/259] Removed peer services specification.

---
 bip-codeshark-jl2012-segwit.mediawiki | 44 ---------------------------
 1 file changed, 44 deletions(-)

diff --git a/bip-codeshark-jl2012-segwit.mediawiki b/bip-codeshark-jl2012-segwit.mediawiki
index 61f341e7..bbbf58cd 100644
--- a/bip-codeshark-jl2012-segwit.mediawiki
+++ b/bip-codeshark-jl2012-segwit.mediawiki
@@ -34,50 +34,6 @@ By removing this data from the transaction structure committed to the transactio
 #* Sum trees for transaction inputs and outputs can be committed making it possible to construct short proofs that no new coins are created in any noncoinbase transaction and that the miner does not add excessive fees to the coinbase transaction. 
 
 ==Specification==
-Maybe a seperate BIP
-
-* CTransaction gets, in addition to vin and vout, a vwit, which
-contains a CTxInWitness object for each input. A CTxInWitness contains a CScriptWitness object
-and can potentially be extended to contain other kinds of witness data.
-A CScriptWitness is a vector of byte vectors (nominally: the input stack to the program, no longer
-encoded as a CScript, but just the resulting stack directly).
-* A new serialization for CTransaction is defined: http://blockhawk.net/diagrams/witnesstx.png
-(int32 nVersion,
-0x00 marker, 0x01 flag, vector, vector,
-vector, int32 nLockTime) instead of (int32 nVersion,
-vector, vector, int32 nLockTime). This will never parse
-as a valid transaction (even if parsing succeeds, it means it's
-interpreted as a transaction with no inputs and 1 output). If all
-witnesses are empty, the old serialization format is used.
-- Rationale for not having an independent CWitnessTransaction with
-its own serialization: this would require separate "tx" and "block"
-messages, and all RPC calls operating on raw transactions would need
-to be duplicated, or need inefficinent or nondeterministic guesswork
-to know which type is to be used.
-- Rationale for not using just a single 0x00 byte as marker: that
-would lead to empty transactions (no inputs, no outputs, which are
-used in some tests) to be interpreted as new serialized data.
-- Rationale for the 0x01 flag byte in between: this will allow us to
-easily add more extra non-committed data to transactions (like txouts
-being spent, ...). It can be interpreted as a bitvector.
-
-* A new message 'havewitness' is sent after receiving 'verack' to
-indicate that a node can provide witness if requested (similar to
-'sendheaders')
-
-* New inv types MSG_WITNESS_TX and MSG_WITNESS_BLOCK are added, only
-for use in getdata. Inv itself still use just MSG_TX and MSG_BLOCK,
-similar to MSG_FILTERED_BLOCK.
-- Rationale for not advertizing witnessness in invs: we don't always
-use invs anymore (with 'sendheaders' BIP 130), plus it's not useful:
-implicitly, every transaction and block have a witness, old ones just
-have empty ones.
-
-* Transactions' GetHash is always computed on the old non-witness
-serialization. A new CTransaction::GetWitnessHash is added which is
-computed from the witness-serialization (this means that transactions
-with an empty witness have witness hash equal to normal hash).
-

 
 === Commitment structure ===
 

From 894d8ac1cb8d2717b865d36b342f58fe7253a2c0 Mon Sep 17 00:00:00 2001
From: Eric Lombrozo 
Date: Wed, 23 Dec 2015 09:58:58 -0500
Subject: [PATCH 082/259] Moved authors to separate lines.

---
 bip-codeshark-jl2012-segwit.mediawiki | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/bip-codeshark-jl2012-segwit.mediawiki b/bip-codeshark-jl2012-segwit.mediawiki
index bbbf58cd..3bddf8a6 100644
--- a/bip-codeshark-jl2012-segwit.mediawiki
+++ b/bip-codeshark-jl2012-segwit.mediawiki
@@ -1,10 +1,12 @@
 
   BIP: x
   Title: Segregated Witness (Consensus layer)
-  Authors: Eric Lombrozo , Johnson Lau , Pieter Wuille 
+  Author: Eric Lombrozo 
+          Johnson Lau 
+          Pieter Wuille 
   Status: Draft
   Type: Standards Track
-  Created: 2015-12
+  Created: 2015-12-21
 

 
 ==Abstract==

From 09192275acbaf8bed98738db107297434a3bba0a Mon Sep 17 00:00:00 2001
From: Johnson Lau 
Date: Thu, 24 Dec 2015 21:45:11 +0800
Subject: [PATCH 083/259] Create bip-segwitaddress.mediawiki

---
 bip-segwitaddress.mediawiki | 97 +++++++++++++++++++++++++++++++++++++
 1 file changed, 97 insertions(+)
 create mode 100644 bip-segwitaddress.mediawiki

diff --git a/bip-segwitaddress.mediawiki b/bip-segwitaddress.mediawiki
new file mode 100644
index 00000000..eed5b313
--- /dev/null
+++ b/bip-segwitaddress.mediawiki
@@ -0,0 +1,97 @@
+
+  BIP: x
+  Title: Address Format for Witness Program
+  Author: Johnson Lau 
+  Status: Draft
+  Type: Standards Track
+  Created: 2015-12-24
+

+
+==Abstract==
+
+This BIP describes a new type of Bitcoin address to support native Segregated Witness (segwit) transactions. An address encoded under this proposal represents the base-58 encoding of a witness program. It supports arbitrarily complex transactions, and is forward compatible to new version witness programs in the future.
+
+==Motivation==
+
+To define a standard payment address for native segwit transactions, with minimal changes from existing address types, for the promotion of early adoption of the more efficient transaction method.
+
+==Specification==
+
+The new bitcoin address type is constructed in a similar manner of the original pay-to-public-key-hash addresses and pay-to-script-hash addresses (see BIP13):
+
+  base58-encode:
+    [one-byte version]
+    [one-byte program length]
+    [2 to 41-byte witness program]
+    [padding by 0x00 to 43 bytes]
+    [4-byte checksum]
+    (47 bytes in total)
+
+Version byte is 0x15 for a main-network address, 0x37 for a testnet address.
+
+Program length byte indicates the length of witness program (L), from 0x02 to 0x29.
+
+The following 2 to 41 bytes is the actual witness program.
+
+The following (41 minus L) bytes is padded by 0x00.
+
+The 4-byte checksum is the first four bytes of the double SHA256 hash of the version, program length, program, and padding.
+
+All addresses generated with this scheme will have 64 characters, with a "B" prefix for main-network and "T" prefix for testnet.
+
+==Rationale==
+
+The segregated witness soft fork (BIP x) defines 2 ways of encoding "witness program", a data push of 2 to 41 bytes:
+
+* A native witness program output is a scriptPubKey with a single push of a witness program, and nothing else;
+* A witness program in P2SH is a P2SH redeemScript with a single push of a witness program, while the scriptPubKey looks like a normal P2SH output.
+
+As the P2SH address has been defined in 2012, using witness program in P2SH allows most existing wallets to pay a segwit-compatible wallet without any upgrade. However, this method requires more block space and is less collision-resistance than a native witness program, and is only a short-term solution to make the transition smoother. Eventually, all users are expected to use the more efficient native witness program as the primary payment method.
+
+Currently there are 2 payment addresses format in Bitcoin, the original pay-to-public-key-hash addresses and the pay-to-script-hash addresses defined in 2012. All address formats, including the one defined in this BIP, are mutually incompatible. However, due to the excellent upgradability of witness programme, this proposal is likely to be the last address format encoding a scriptPubKey template.
+
+The drawbacks of Bitcoin addresses have been extensively discussed in BIP13. Since then, better payment methods have been proposed or deployed, for example:
+*BIP47 Reusable Payment Codes for Hierarchical Deterministic Wallets
+*BIP63 Stealth Addresses
+*BIP70 Payment protocol
+However, none of these are as widely adopted as the suboptimal base-58 scriptPubKey template addresses, which is still a standard for the whole eco-system, from wallets, block explorers, merchants, exchanges, to end users. The author believes this proposal as the most efficient way to promote early adoption of native witness program, which is particularly important in the context of scaling the capacity of the blockchain.
+
+Following the same rationale of BIP13, and to minimize the changes needed in wallet upgrade, this proposal resembles the original address format, including the checksum algorithm.
+
+==Compatibility==
+
+This proposal is not backward compatible, but it fails gracefully -- if an older implementation is given one of these new Bitcoin addresses, it will report the address as invalid and will refuse to create a transaction.
+
+This proposal is forward compatible to any new version witness program in the future.
+
+==Example==
+
+The following public key,
+    0450863AD64A87AE8A2FE83C1AF1A8403CB53F53E486D8511DAD8A04887E5B23522CD470243453A299FA9E77237716103ABC11A1DF38855ED6F2EE187E9C582BA6
+when encoded as a P2PKH template, would become:
+    DUP HASH160 <010966776006953D5567439E5E39F86A0D273BEE> EQUALVERIFY CHECKSIG
+And the corresponding version 1 Bitcoin address is
+    16UwLL9Risc3QfPqBUvKofHmBQ7wMtjvM
+In the case of using the same P2PKH template as a version 0 witness program, the scriptPubKey becomes a 26-byte single push of:
+    0076A914010966776006953D5567439E5E39F86A0D273BEE88AC
+Prefixing with the address version byte 0x15 and program length 0x1A:
+    151A0076A914010966776006953D5567439E5E39F86A0D273BEE88AC
+Padding with 41 - 26 = 15 0x00:
+    151A0076A914010966776006953D5567439E5E39F86A0D273BEE88AC000000000000000000000000000000
+Perform double SHA-256 hash:
+    1B4A8136E38479EF5F08626D524534E6C94C92B1E77690B727CE8BD30BB3DAA0
+Take the first 4 bytes. This is the address checksum:
+    1B4A8136
+Add the 4 checksum bytes at the end of extended witness program. This is the 47-byte binary witness program address:
+    151A0076A914010966776006953D5567439E5E39F86A0D273BEE88AC0000000000000000000000000000001B4A8136
+Convert the result from a byte string into a base58 string with 64 characters. 
+    BAxHaPmrSLbCt4QjJkW1W7MMXZmMdJkoxFHTEQXKmL9LpMUvDMcLAGgeeuLnkvNR
+
+==Reference Implementation==
+
+==See Also==
+
+* [[bip-0013.mediawiki|BIP 13: Address Format for pay-to-script-hash]]
+* [[bip-0016.mediawiki|BIP 16: Pay to Script Hash (aka "/P2SH/")]]
+* [[bip-xxxx.mediawiki|BIP x: Segregated Witness]]
+

From 9b9a8c4b71317afb946ef5198836df31914ed6f9 Mon Sep 17 00:00:00 2001
From: Eric Lombrozo 
Date: Thu, 24 Dec 2015 14:23:27 -0500
Subject: [PATCH 084/259] Segregated Witness Peer Services BIP

---
 bip-codeshark-segwit-peer-services.mediawiki | 340 +++++++++++++++++++
 1 file changed, 340 insertions(+)
 create mode 100644 bip-codeshark-segwit-peer-services.mediawiki

diff --git a/bip-codeshark-segwit-peer-services.mediawiki b/bip-codeshark-segwit-peer-services.mediawiki
new file mode 100644
index 00000000..6f33378c
--- /dev/null
+++ b/bip-codeshark-segwit-peer-services.mediawiki
@@ -0,0 +1,340 @@
+
+  BIP: x
+  Title: Segregated Witness (Peer Services)
+  Authors: Eric Lombrozo , Pieter Wuille 
+  Status: Draft
+  Type: Standards Track
+  Created: 2015-12
+

+
+==Abstract==
+
+This BIP defines new messages and serialization formats for propagation of transactions and blocks committing to segregated witness structures.
+
+==Motivation==
+
+==Specification==
+
+A new message type called "witnesstx" is added to the peer-to-peer protocol. (http://blockhawk.net/diagrams/witnesstx.png)
+
+The message has the following structure:
+
+{| class="wikitable" style="width: auto; text-align: center; font-size: smaller; table-layout: fixed;"
+!Field Size
+!Name
+!Type
+!Description
+|-
+| 4
+| version
+| int32_t
+| Transaction data format version
+|-
+| 1
+| marker
+| char
+| Must be zero
+|-
+| 1
+| flag
+| char
+| Must be nonzero
+|-
+| 1+
+| txin_count
+| var_int
+| Number of transaction inputs
+|-
+| 41+
+| txins
+| txin[]
+| A list of one or more transaction inputs
+|-
+| 1+
+| txout_count
+| var_int
+| Number of transaction outputs
+|-
+| 9+
+| txouts
+| txouts[]
+| A list of one or more transaction outputs
+|-
+| 
+| txin_witness
+| txin_witness
+| Transaction input witness
+|-
+| 4
+| lock_time
+| uint32_t
+| The block number or timestamp until which the transaction is locked
+|}
+
+* CTransaction gets, in addition to vin and vout, a vwit, which
+contains a CTxInWitness object for each input. A CTxInWitness contains a CScriptWitness object
+and can potentially be extended to contain other kinds of witness data.
+A CScriptWitness is a vector of byte vectors (nominally: the input stack to the program, no longer
+encoded as a CScript, but just the resulting stack directly).
+* A new serialization for CTransaction is defined: http://blockhawk.net/diagrams/witnesstx.png
+(int32 nVersion,
+0x00 marker, 0x01 flag, vector, vector,
+vector, int32 nLockTime) instead of (int32 nVersion,
+vector, vector, int32 nLockTime). This will never parse
+as a valid transaction (even if parsing succeeds, it means it's
+interpreted as a transaction with no inputs and 1 output). If all
+witnesses are empty, the old serialization format is used.
+- Rationale for not having an independent CWitnessTransaction with
+its own serialization: this would require separate "tx" and "block"
+messages, and all RPC calls operating on raw transactions would need
+to be duplicated, or need inefficinent or nondeterministic guesswork
+to know which type is to be used.
+- Rationale for not using just a single 0x00 byte as marker: that
+would lead to empty transactions (no inputs, no outputs, which are
+used in some tests) to be interpreted as new serialized data.
+- Rationale for the 0x01 flag byte in between: this will allow us to
+easily add more extra non-committed data to transactions (like txouts
+being spent, ...). It can be interpreted as a bitvector.
+
+* A new message 'havewitness' is sent after receiving 'verack' to
+indicate that a node can provide witness if requested (similar to
+'sendheaders')
+
+* New inv types MSG_WITNESS_TX and MSG_WITNESS_BLOCK are added, only
+for use in getdata. Inv itself still use just MSG_TX and MSG_BLOCK,
+similar to MSG_FILTERED_BLOCK.
+- Rationale for not advertizing witnessness in invs: we don't always
+use invs anymore (with 'sendheaders' BIP 130), plus it's not useful:
+implicitly, every transaction and block have a witness, old ones just
+have empty ones.
+
+* Transactions' GetHash is always computed on the old non-witness
+serialization. A new CTransaction::GetWitnessHash is added which is
+computed from the witness-serialization (this means that transactions
+with an empty witness have witness hash equal to normal hash).
+

+
+=== Commitment structure ===
+
+!!!DRAFT ONLY!!!
+
+A new block rule is added which requires a commitment to the witness hashes in the coinbase (or an OP_RETURN output of a specific transaction, or somewhere else)
+
+(Hardfork after x year to move the commitment to block header?)
+
+Witness hash is the double SHA256 of a transaction including witnesses: http://blockhawk.net/diagrams/witnesstx.png. For the coinbase transaction, its witness hash is assumed to be 0x0000....0000.
+
+A witness root hash is calculated with all those witness hashes as leaves, in a way similar to the hashMerkleRoot in the block header.
+
+No witness data is allowed in blocks that don't commit to witness data, as this would otherwise leave room from spam.
+
+==== Proposal 1: balance tree (the current implementation) ====
+The commitment is a push of exactly 41 bytes:
+*The first 4 bytes are commitment header: 0xaa21a9ed
+*The next 4 bytes describe a nonce
+*The next 1 byte is the "levels bytes", describes the number of levels in a Merkle tree (0 to 32)
+*The next 32 bytes is a commitment root hash (not the witness root hash)
+
+Locator of the witness root hash is defined as:
+
+
SHA256('WitnessV1\x00\x00\x00\x00\x00\x00\x00' || nonce)

+
+The first levels bits of locator, interpreted in little endian, are assumed to be the position in the leaves of the Merkle tree where the witness root hash goes.
+
+The coinbase's input's witness must consist of a single byte array of 32 * levels bytes, and are assumed to be the Merkle path to connect the witness root hash to the commitment root hash.
+
+====Proposal 2: imbalance tree====
+The commitment is a push of exactly 40 bytes:
+*The first 4 bytes are commitment header: 0xaa21a9ed
+*The next 4 bytes describe a nonce
+*The next 32 bytes is a commitment root hash (not the witness root hash)
+
+Locator of the witness root hash is defined as:
+
+
SHA256('WitnessV1\x00\x00\x00\x00\x00\x00\x00' || nonce)

+
+The first levels bits of locator, interpreted in little endian, are assumed to be the position in the leaves of the Merkle tree where the witness root hash goes.
+
+The coinbase's input's witness must consist of a single byte array, which the size must be a multiple of 32 bytes but not bigger than 32*32 bytes. These are assumed to be the Merkle path to connect the witness root hash to the commitment root hash. Depth of the commitment is determined by the length of the path. If the depth of the tree is 0, the path should be represented by 0x00, and the witness root hash will be same as the commitment root hash.
+
+=== Block size limit ===
+Blocks are currently limited to 1 MB total size. We change this restriction as follows:
+
+We define a base block size sb consisting of the existing header and transactions, a witness size sw consisting of only the size of the witness data, and a virtual block size sv = sb + sw/4.
+
+The new rule is sv <= 1 MB.
+
+=== Witness program ===
+
+* A scriptPubKey (or redeemScript as defined in BIP16/P2SH) that consists of a single push of 2 to 41 bytes gets a new special meaning. The byte vector pushed by it is called the "witness program".
+** In case the scriptPubKey pushes a witness program directly, the scriptSig must be exactly empty.
+** In case the redeemScript pushes a witness program, the scriptSig must be exactly the single push of the redeemScript.
+
+* The first byte of a witness program is the "version byte", an unsigned integer.
+** If the version byte is 0, the rest of the witness program is the actual script.
+*** The script is executed after normal script evaluation but with data from the witness rather than the scriptSig.
+*** The program must not fail, and result in exactly a single TRUE on the stack.
+** If the version byte is 1, the rest of the witness program must be 32 bytes, as a SHA256 hash of the actual script.
+*** The witness must consist of an input stack to feed to the program, followed by the serialized program.
+*** The serialized program is popped off the initial witness stack. Hash of the serialized program must match the hash pushed in the witness program.
+*** The serialized program is deserialized, and executed after normal script evaluation with the remaining witness stack.
+*** The script must not fail, and result in exactly a single TRUE on the stack.
+** If the witness version byte is 2 or above, no further interpretation of the witness program or witness happens.
+
+=== Other consensus critical constraints ===
+
+== Block size analysis ==
+WORK IN PROGRESS
+
+Definitions:
+
+ Core block size (CBS): The block size as seen by a non-upgrading full node
+ Witness size (WS): The total size of witness data in a block
+ Total block size (TBS): CBS + WS
+ Witness discount (WD): A discount factor for witness data in VBS calculation (1 = no discount)
+ Virtual block size (VBS): CBS + (WS * WD)
+ Witness adoption (WA): Proportion (in size) of new format transactions among all transactions
+ Prunable ratio (PR): Proportion of signature data size in a transaction
+

+
+With some transformation it could be shown that:
+
+ TBS = CBS / (1 - WA * PR)
+     = VBS / (1 - WA * PR * (1 - WD))
+

+
+In order to keep the proposal as a soft fork, the CBS must not have a upper limit higher than 1MB.
+
+The PR heavily depends on the transaction script type and input-output ratio. For example, the PR of 1-in 2-out P2PKH and 1-in 1-out 2-of-2 multisig P2SH are about 47% and 72% respectively. According to the data presented by Pieter Wuille on 7 December 2015, the current average PR on the blockchain is about 60%.
+
+
+
+== Examples ==
+
+=== Version 0 witness program ===
+
+The following example is a version 0 witness program, equivalent to the existing Pay-to-Pubkey-Hash (P2PKH) output.
+
+    witness:       
+    scriptSig:    (empty)
+    scriptPubKey: <0x0076A914{20-byte-hash-value}88AC>
+
+The version byte 0x00 is removed. The rest of the witness program is deserialized and becomes:
+
+    DUP HASH160 <20byte-hash-value> EQUALVERIFY CHECKSIG
+
+The script is executed with the data from witness
+
+      DUP HASH160 <20byte-hash-value> EQUALVERIFY CHECKSIG
+
+Comparing with a P2PKH output, the witness program equivalent occupies 2 more bytes in the scriptPubKey, while moving the signature and public key from scriptSig to witness.
+
+=== Version 1 witness program ===
+
+The following example is an 1-of-2 multi-signature version 1 witness program.
+
+    witness:      0  <0x5121{33-byte-pubkey1}21{33-byte-pubkey2}52AE>
+    scriptSig:    (empty)
+    scriptPubKey: <0x01{32-byte-hash-value}>
+
+The last item in the witness is popped off, hashed with SHA256, compared against the 32-byte-hash-value in scriptPubKey, and deserialized:
+
+    1 <33-byte-pubkey1> <33-byte-pubkey2> 2 CHECKMULTISIG
+
+The script is executed with the remaining data from witness:
+
+    0  1 <33-byte-pubkey1> <33-byte-pubkey2> 2 CHECKMULTISIG
+
+Since the actual program is larger than 40 bytes, it cannot be accommodated in a version 0 witness program. A version 1 witness program allows arbitrarily large script as the 520-byte push limit is bypassed.
+
+The scriptPubKey occupies 34 bytes, as opposed to 23 bytes of P2SH. The increased size improves security against possible collision attacks, as 2^80 work is not infeasible anymore (By the end of 2015, 2^84 hashes have been calculated in Bitcoin mining since the creation of Bitcoin). The spending script is same as the one for an equivalent P2SH output but is moved to witness.
+
+=== Witness program nested in Pay-to-Script-Hash ===
+
+The following example is the same 1-of-2 multi-signature version 1 witness program, but nested in a P2SH output.
+
+    witness:      0  <0x5121{33-byte-pubkey1}21{33-byte-pubkey2}52AE>
+    scriptSig:    <0x2101{32-byte-hash-value}>
+    scriptPubKey: HASH160 <20-byte-hash-value> EQUAL
+
+The only item in scriptSig is hashed with HASH160, compared against the 20-byte-hash-value in scriptPubKey, and interpreted as a single push of:
+
+    <0x01{32-byte-hash-value}>
+
+The version 1 witness program is then executed as described in the last example
+
+Comparing with the last example, the scriptPubKey is 11 bytes smaller (with reduced security) while witness is the same. However, it also requires 35 bytes in scriptSig, which is not prunable in transmission. Although a nested witness program is less efficient in many ways, its payment address is fully transparent and backward compatible for all Bitcoin reference client since version 0.6.0.
+
+=== Trust-free unconfirmed transaction dependency chain ===
+Segregated witness fixes the problem of transaction malleability fundamentally, which enables the building of unconfirmed transaction dependency chains in a trust-free manner.
+
+Two parties, Alice and Bob, may agree to send certain amount of Bitcoin to a 2-of-2 multisig output (the "funding transaction"). Without signing the funding transaction, they may create another transaction, time-locked in the future, spending the 2-of-2 multisig output to third account(s) (the "spending transaction"). Alice and Bob will sign the spending transaction and exchange the signatures. After examining the signatures, they will sign and commit the funding transaction to the blockchain. Without further action, the spending transaction will be confirmed after the lock-time and release the funding according to the original contract. It also retains the flexibility of revoking the original contract before the lock-time, by another spending transaction with shorter lock-time, but only with mutual-agreement of both parties.
+
+Such setups is not possible with BIP62 as the malleability fix, since the spending transaction could not be created without both parties first signing the funding transaction. If Alice reveals the funding transaction signature before Bob does, Bob is able to lock up the funding indefinitely without ever signing the spending transaction.
+
+Unconfirmed transaction dependency chain is a fundamental building block of more sophisticated payment networks, such as duplex micropayment channel and the Lightning Network, which have the potential to greatly improve the scalability and efficiency of the Bitcoin system.
+
+== Future extensions ==
+=== Compact fraud proof for SPV nodes ===
+Bitcoin right now only has two real security models. A user either runs a full-node which validates every block with all rules in the system, or a SPV (Simple Payment Verification) client which only validates the headers as a proof of publication of some transactions. The Bitcoin whitepaper suggested that SPV nodes may accept alerts from full nodes when they detect an invalid block, prompting the SPV node to download the questioned blocks and transactions for validation. This approach, however, could become a DoS attack vector as there is virtually no cost to generate a false alarm. An alarm must come with a compact, yet deterministic fraud proof.
+
+In the current Bitcoin protocol, it is possible to generate compact fraud proof for almost all rules except a few:
+
+# It is not possible to proof a miner has introduced too many Bitcoins in the coinbase transaction outputs without showing the whole block itself and all input transactions.
+# It is not possible to prove the violation of any block specific constraints, such as size and sigop limits, without showing the whole block (and all input transactions in the case of sigop limit)
+# It is not possible to prove the spending of a non-existing input without showing all transaction IDs in the blockchain way back to the genesis block.
+
+It is possible to proof the first 2 types of fraud if a block is committed to a Merkle-sum-tree of the fee, size, and sigop count of each transaction. It is also possible to proof the last type of fraud if a block is committed to a Merkle tree with the originating block height and transaction index of all inputs. These commitments could be included in the extensible witness commitment through a soft fork and will be transparent to nodes that do not understand such new rules.
+
+=== New script system ===
+Since all witness programs begin with a version byte, and programs with unknown versions are always considered as anyone-can-spend script, it is possible to introduce any new script system with a soft fork. The witness as a structure is not restricted by any existing script semantics and constraints, the 520-byte push limit in particular, and therefore allows arbitrarily large scripts and signatures.
+
+Examples of new script system include Schnorr signatures which reduce the size of multisig transactions dramatically, Lamport signature which is quantum computing resistance, and Merklized abstract syntax trees which allow very compact witness for conditional scripts with extreme complexity.
+
+The 41-byte limitation for witness programme could be easily extended through a soft fork in case a stronger hash function is needed in the future. The version byte is also expandable by introducing a secondary version byte for some specific primary version values.
+
+=== Per-input lock-time and relative-lock-time ===
+Currently there is only one nLockTime field in a transaction and all inputs must share the same value. BIP68 enables per-input relative-lock-time using the nSequence field, however, with a limited lock-time period and resolution.
+
+With a soft fork, it is possible to introduce a separate witness structure to allow per-input lock-time and relative-lock-time, and a new script system that could sign and manipulate the new data (like BIP65 and BIP112).
+
+== Backward compatibility ==
+As a soft fork, older software will continue to operate without modification.  Non-upgraded nodes, however, will not see nor validate the witness data and will consider all witness programs as anyone-can-spend scripts (except a few edge cases in version 0 witness programs which are provably unspendable with original script semantics). Wallets should always be wary of anyone-can-spend scripts and treat them with suspicion. Non-upgraded nodes are strongly encouraged to upgrade in order to take advantage of the new features.
+
+=== Version 0 witness programs ===
+Witness programs are hashed to 256 bit "redeemscripts" which are then hashed to 160 bit P2SH. This format is fully compatible with currently existing wallets that support P2SH. Upgraded wallets will be able to send and receive to and from older wallets without any problems.
+
+=== Version 1 witness programs ===
+Witness programs are hashed to a 256 bit output. This format will not be compatible with older wallets but will require less block space and will have better security due to increased collision resistance.
+
+== Deployment ==
+
+We reuse the double-threshold IsSuperMajority() switchover mechanism used in
+BIP65 with the same thresholds, but for nVersion = 5. The new rules are
+in effect for every block (at height H) with nVersion = 5 and at least
+750 out of 1000 blocks preceding it (with heights H-1000..H-1) also
+have nVersion >= 5. Furthermore, when 950 out of the 1000 blocks
+preceding a block do have nVersion >= 5, nVersion < 5 blocks become
+invalid, and all further blocks enforce the new rules.
+
+(It should be noted that BIP9 involves permanently setting a high-order bit to
+1 which results in nVersion >= all prior IsSuperMajority() soft-forks and thus
+no bits in nVersion are permanently lost.)
+
+
+=== SPV Clients ===
+
+While SPV clients are unable to fully validate blocks,
+they are able to validate block headers and, thus, can check block version and proof-of-work.
+SPV clients should reject nVersion < 5 blocks if 950 out of 1000 preceding blocks have
+nVersion >= 5 to prevent false confirmations from the remaining 5% of
+non-upgraded miners when the 95% threshold has been reached.
+
+== Credits ==
+Special thanks to Gregory Maxwell for originating many of the ideas in this BIP and Luke-Jr for figuring out how to deploy this as a soft fork.
+
+== Reference Implementation ==
+https://github.com/sipa/bitcoin/commits/segwit
+
+== Copyright ==
+This document is placed in the public domain.

From 0112d56051d3406ba035a75a5033fe5de52a6c86 Mon Sep 17 00:00:00 2001
From: Eric Lombrozo 
Date: Thu, 24 Dec 2015 17:23:02 -0500
Subject: [PATCH 085/259] Embedded diagram

---
 bip-codeshark-segwit-peer-services.mediawiki  |  25 +++++++++---------
 .../witnesstx.png                             | Bin 0 -> 18923 bytes
 2 files changed, 13 insertions(+), 12 deletions(-)
 create mode 100644 bip-codeshark-segwit-peer-services/witnesstx.png

diff --git a/bip-codeshark-segwit-peer-services.mediawiki b/bip-codeshark-segwit-peer-services.mediawiki
index 6f33378c..c81e1dbb 100644
--- a/bip-codeshark-segwit-peer-services.mediawiki
+++ b/bip-codeshark-segwit-peer-services.mediawiki
@@ -15,9 +15,9 @@ This BIP defines new messages and serialization formats for propagation of trans
 
 ==Specification==
 
-A new message type called "witnesstx" is added to the peer-to-peer protocol. (http://blockhawk.net/diagrams/witnesstx.png)
+A new serialization format for tx messages is added to the peer-to-peer protocol.
 
-The message has the following structure:
+The serialization has the following structure:
 
 {| class="wikitable" style="width: auto; text-align: center; font-size: smaller; table-layout: fixed;"
 !Field Size
@@ -71,16 +71,17 @@ The message has the following structure:
 | The block number or timestamp until which the transaction is locked
 |}
 
-* CTransaction gets, in addition to vin and vout, a vwit, which
-contains a CTxInWitness object for each input. A CTxInWitness contains a CScriptWitness object
-and can potentially be extended to contain other kinds of witness data.
-A CScriptWitness is a vector of byte vectors (nominally: the input stack to the program, no longer
-encoded as a CScript, but just the resulting stack directly).
-* A new serialization for CTransaction is defined: http://blockhawk.net/diagrams/witnesstx.png
-(int32 nVersion,
-0x00 marker, 0x01 flag, vector, vector,
-vector, int32 nLockTime) instead of (int32 nVersion,
-vector, vector, int32 nLockTime). This will never parse
+
+
+Parsers supporting this BIP will be able to distinguish between the old serialization format (without the witnesses) and this one. The marker byte is set to zero so that this structure will never parse as a valid transaction in a parser that does not support this BIP. If parsing were to succeeded, such a transaction would contain no inputs and a single output.
+
+If all witnesses are empty, the old serialization format should be used. 
+
+Witness objects can potentially be extended to contain other kinds of witness data.
+
+A script witness is a vector of byte vectors (nominally: the input stack to the program, no longer
+encoded as a scriptSig, but just the resulting stack directly).
+
 as a valid transaction (even if parsing succeeds, it means it's
 interpreted as a transaction with no inputs and 1 output). If all
 witnesses are empty, the old serialization format is used.
diff --git a/bip-codeshark-segwit-peer-services/witnesstx.png b/bip-codeshark-segwit-peer-services/witnesstx.png
new file mode 100644
index 0000000000000000000000000000000000000000..5fd8afcb01ce0cf08b7de1003c8be0539f226ba6
GIT binary patch
literal 18923
zcmeHv2~^T)+c(uXPRry>n^`F{m8rQfWo53kn|o?$xK@hhxRCpTKuyzPSyV2hrc|bm
zxu9SYE>P2AipnIpAR^_O0umyqAn^U6nR#ZObKdWLzwbNmIqx~&aE_%NxX
zegCdM8OPimzh1Us83+XW+Ue*aFA!+49QfJt)tA6Kh5UCbfPWUndpRBeRd;Th0Dk!*
ze81a%5U3WreBrbf@cYtpM`7_G(5eLW&!WLFa0&?Ibl&OE{^Kb@0uHLi432`NDQl0O
zNzd?{*%183bNk@^`$sZ2>YPwMI5G)x)^fIYTC;ZVq{Lt*cW~p^aXF8+TF?2cm;C&d
z;n_9u#bwoyO`g`&QEHb+V>zE1p*mo6LmnKOJ34Np!>(#96+Eo
z&Ma-v`2!}v!jBpMZLrUj31%8U`30Gi#1_1-XOm)yIOT
zm0Jub73spdGHR^;c%OR_~^5=_{?9`
zLLSnscqe_TpJtflTg%{v^NGcLrfnNFK@Se@DF|5u
z=*hGdy~dlyY`%Wv_Ib(J`b%n!58)6!wUq&}t6{qWrwTwdF&g0q*3#S7THQX(9HlM=
z@s6;{lCx10JKG#8ty+u$qm(5N-GKTI99nl{^CDiyj%8}|WLR)3LtvDlZN#$;16GSp
zaWuj&ZO_e7&sa)Ftp@enAbJRm)Jeom&yzQSUtey-s8_M!@Z#Tss-DpeC*KCD+z6P(Q(8hdme&ma%SxJ6T>Ij8CBqFH(n&Y}
zZV*8Dy2t-!x8`EL3(iw|y4m{3Y3nwJ=GBM=%_`O`{as0hbHaR>zSyRbD{Qnr)IoR1Q)BH)dN+Hl0z)g>*JGQNEtJNd!I(`{j(S8FU(ey{uVRVNA`8tzAGE`(O$E{T|Kv~FZrv$ytMWvjZmHS!2^E;MZ@{~>#rVKLxO(U`u
z-RsxNPT#YRso%|B70w|)y40rp=5))_mvk}x=(JUpv!
zJW}iuyKP+0UfMTVTosX=KE9axWh9o6yi
zU}vR#<=JIFnyzN#Wmfs3E~6h1F{h9uI`_=Y#K*x`-p*yJ+>a#9ckuQ^QkR4<)0B53
z3R(~^b)O_3LxIf=7>=AHfn1RNt%~BxeAl=#K;YSlZMI0^3vcK
z7aw0~!GT?~hFj+6<1bYNPVSNWcz4~j-@{3MzvR~#JBKk&za(t!Grifv7Z6-s9x<`R
zXe<)Z($vdGSd?{M5Dc6dO#HF5yS36+{y|b#cvEmW6-?W)Tjd9N>L!Wm2-z0ImfAI*
zN^CLCcKRc+Jm;fQcJra!5d>Cd){ruOA#9I#>b(awgt%t(24J5IO7d)$Qe
zWY*?IB8hN2K#c~s;wx4J<~@RkuTOI3fxN%um$g}AT?HKn9MDPVGevLnl(HB5?Cr-2
z7jE6>BY;pGi;7=I?XP@j2dh4E>D)qQ4E63SBH*E&VA_*!F2mSA2&fZSy{eF?cv1`n
z?qMsp!}&~b2c}YcBMvHTGHExr#IGGHheK)YOXG2h!{mu)eeTtavoKp^^Mw<~)IRz-
z?%SN=^W43uMxC7=?OAPUYZl(lG_)g3ly2Dyb0FE>i}p+H%nN#bXNazR_i_*8q|^(J
z37wI>mbN##Z(L_4FYZO9r;0N>-q>LoG@t7+-jPuSy;iwak&5$@`#@fNVJzQR?vmQz
zY80PDZ5=DIix?ESB=5N!=BpgU5}X}LRG_Ju?5x5-@t%5ScIfbRn4rwv>2#mf24L(^J2t%)|+>h
zQ*KV&yGF=T^uns5>?juZsMr=H5sw=9sx$U@*P4>nhr73*Dgf%>^ZOtU)1`08Y0l*jen+TGE0`WuPu5p9fF_o&_bg3dJdIXH|%k=hlzy=i8JsT$70+O%?sKKvi8$
zpIqqZDpaC>LyY&--Uq7H&T|({iw_rq{^GvZoV*))$C91{t{VFOvX|61WvNb$
z9gyMm4zX}KhgnyCuf{X(O`>si0r%W`>i2SF`gXJ+@!v{c&PU?0SAVaN6Z-JrhD@T)
z@74JCDscPo|4)$NP{RsP_E8p4_sx!%(L@S==lnNB>-iHHCO;5#Y#o5ePWp=;Z0Z95
z5%9k@2LQ-~8#cj~fGUfCDs2oPM*!UcSdQMh8Gt4_ph|N%7(h*=RfCm_Kt3M8U;xkk
zr{GXP#7tKxOOBpqYoiiP)&8{BBtZqrFUUT(m
zYDS2|EGg)6PM>b>1HNwddTapfo7>85Hw6JE-`t*F)sj9H-n_!J7Gidg1u@=XKp}p&
zS>d*cP4W6}^Qhs?`2j|np3j-!lb4CX$IjTr!S^4M73{5#FWGmf&1I9Af|u;9d`YcY
z0jJ%6nKIJ$)72TP*r;*m3spo^!^Odn;flgClEt@ojHrYHG%xI
z;Qu*0EPF6IDK0vxANOW;1#PZnK~Z7^c-qW;KBiuF-3UzF@f(9+K_A3-wTnl3eSO1)
z!ac?M!dsJf#SR6{s#6+&eAIMLoX@SCeZfU{FiEp6)_?O(+DaIFQLvQK^Muq<0C?it
z>z48z#~^c878I&!EP-$n_F-Q&@8)W?-+KjhdP=pk{^n%7Tkz#`n_+(ufTgG8@5H=`
z&SS*D%AuLj~QEv`dZ>5}S$
zT*|O9`ddhqIJ
z3y&wQu@PXB3FdfV?P#q0ac`jrIS;3Pz)rUCQx77kqS4Ww!#z7R5hnCoHxiQOD}FN~HNtW%te^b?2MurI9KTYvNIlHqH2wq>CpaCtTBFc9poH)Jc`E>E~$
z*|Hp3f6$eZ9e&2>O-HYthkVI?-0g|%s>7IS*N{tqGAFE_KB
z_i3_3T6XD6kAUmYpsBK4#an9Pdyxl0`RSKk(KFwliVvD_)1(2|@Gh-|PnOkf?$|R_
zm=Y|$JegQE9|vAHW-c$@OXBuwG8-)tcE7-N-6xURV8%8ZKjtuShIY6bYTI|xu`+8S
zinVe*Pc)Liy&&kQ7T*gbT?f)p<`ZN2FdW%G^LF{*;D`LenkSZSoy`2fe8`t+amT{=
zKiqDYxgiJnD{1eO7zOH-c*~*0WZcod+NNwbDxs8mqAwgkoy;&dT+ruDNOX^{ckmz5
zx%UK2Lw%P8UYxBsy;YqZWr6g?oX|!h6l0Xnj~$MH_MW9s#yKz+x1oyUv4<=lYWiKL
z-Ny2~{q&}q#MjzUXQ&ew?Kku-Sz;OKsQ>jDv~}XPqV
zFRMG=A|Kwx5-*P5`xwRS!Srim-x8C%b~hdc9Q&g$3yi#A6#Q;XS)NDWgP&riV-vGc
zEWxhPbkdt~=O!ZbuBHqT$L85q$FCqZAqxzfEJg*yYCb(w6C~Uxm5D6O8Ocw~Bh67f
z*4&%S@qsELbazN$Y^!=RigFZE_pTLfxfcqXFFqj!vbe4!i!68`3&(Ktb(b(OX5IXxw*{Fm{sh~#X6o|YYxHO+%Y>kY#(TUdg~T-!a-EVc0saustg
z_s(wy9|d9;JqWY?k)NV{$CMXh8&=pZcISxJai;_tywSyoLi?iA$!Oa)<*8L_^l%iq
z(*{YqT^`OVSjFwEyJG-exj7YJ>e
z_=s&8qncX{enY(}__x`WE#=`passVZHb9Okr>c5X0Sex?*uV-l1~bSF@AY4a)|f(Q
zLspDhcNYdz(h?rV4l^3TqMCBD5G_%8aumVP9lcF4!GW}TN^kmY_1;|cks{`YS}JU@
zY;TTeO#C=_;jKvwBHng(!_B`{q)?QYy4(TAnfp1U0u`=;OFGK%4N2s9o*D19#zz}F
zJFL>18-|~jy)#-TAS^Ms##MVSck3iD^sn701tFl+(J6_Tz%j
z8~+E;Bn~=h$txHRsAvQ|?Q_g=j&3iRczGt92_uJd#-$?yxVmz#oPvCGF8f=>{Rh$g
zgW3OeNJ;RL9zF!TLX(M^C2h(HL^>wvlKPE9q4W0^9@8Q|pN$rQ&P)D_l)^9WZAzs=
zUa{Qb>HP*ik^UI3oGI%#4g#GrfG&K{skjcIKAn2!8<=>)GBFi6Xpx&n&AU%u(f6^R
zr7)^|*MLBGxjDW;F#Xh#+ug+ml3ykjLJa2fSSzaNMtAd6B4P69)$YH}Nja5opvrfB$J6TPI&#KRM^hjl*%qECDS0k}Q$?~$EKv^CmJ7ohh~2?cMMe#=^9^1bGqOdlyY-hXH$0Q&@nYQl{RT-~y9imQOYo
z<|yJB_T-@FGv!|ZDloczgPUQ}*(na&Rd6I6u6lUgqCcRuAf};Qvy*o^$I4bJDrmBb
z?qsUCFziPw8&f%cVZ_LauEbGiN;I2Cw;sReo&50%;Dm)rA;k$0(;rEwnnH5rJ*Kj$
zWLl$ImTUYhCmDf$+aYQJ2Xj(}Z*-J9N;WF3Oh2
zcwIqvR|K6&=k_KqL>69sgN>WG^sC4acq9*sGoRTG77;^DB2*f+p^Qny`}|OK)}|5DA5pg38;I!Gi8MvRVb_KgN;m`wlUxs8ct|O;EzDJnRFXO$
z`_4JcQar}Fs{yN&r11Q?ehL{umBuMlN3oT6V|OZxrj+q`Yu)E>aOZAJMtC6euU_5s
zbJM~ogg}*4A$AKp{eigyyB!^-Z%?uq=p<<^aOKiyE$s`baI~NFObkaa3bK}`L>Q?LpAF`Wo^%z{(e@7Yqx*o4u81LTEvdNn}8%dK!O7uzxcB)fd
zJmB_IGOLqQ02BKDJ@Uiy;FFja2W=WvPY9^0JiimTfH)_~d2PG<7ILcf*Y~5^9QHk^
zZkleJ{9Y&ZXrfBarKPdigFYTEDs#EGXtqgqa35e+!IRz|<|5-PqRz2j5EwbT8@%uw
z{4V^Hhr|5HWT&mLlB!Y&5$FzfWU#znMsxwS0U348c2uyK7c|?@&@y$`ihU
zCpbd%Yz1vna1bmzW@!W}0m$2B(!p6OxnZ_h7^t7rce;CbZ-966xV^BPj*;Oz%TVS<
zpwVOMVV5B3r^UEfX5NA>ZSIwX3l`sP;kT*Yef2C2;8vH_14%>1PVssUmGemz#aM?1
zr5p&>ckPSzwPvHv|HJ_Tue-<|Ir$T2D8tAHm=DFH(PZ6(m@&}(P{0x&f@U7-c56X9
zKa~ZfO_X#rgR)&&+QtKb2RFi|w;*SyqNlVzk8}XMHp)ac!A`AioN5>g0y&ogE1ufO
zoqL^2#LRuT;%hZ;8&-Q}7a!XR2j4$e-UpSv#SWUu
zjqvGliQ*0`t3Ut3he~U)95XpEK@4Ry_m2rI*2;&mP&A2OrV8No_#^(*$BP9W&Gz0y
zSI&>)gB8;_TGSt!YQiSdva=5m27T8c?zAmHE;0tn$FZjg>r@f~MgdUU&wc=IJ}&{P
zUUpG0SU~0m6($d+CccI8YhFAyt$zBDqJ6##V7r%`Yc<3HW0ySQFIjP(sPltso5M2@
z@Wu=E8~Ymhm@!LyMCsyVHgNDM&_lke2chtJk}Mnq@=6IH|I6>%l;1jT@(hgc*bNj5
zXW*`N#WOju|C7HR)HwnC{Rm5Y{dqcs)|B?~AlT1dDZ&z@LN3=;>wbcICO(@?NE^51
z!ca0MzIy8E@Xg-^|EC=Qz%A*2yak0sl@Ff5{A%
zs8e$W=trnf54j8M=3`*IDd3Pb+X0(h6C7cA(4FXRw3&i2IZ$o)&O&C;3SKZ_9NSXD
zwx$rd=%_U147~+ZsRQiVs|GW9ZxAwC(uJcY#21O~r3__wFHgxYn!-z;#tMjd1EiD{
z?qO$P7!3yT_OrB4)>_cf*^=XP%sB6Pk8rlysbd^0der;YBFfFmD|k
zYVT{e$IXRN&^gsoHxROD?_MA<*GA$L3FU6vUz1je$J&&Y^q4Nl)%Tv&AeqKA6UBv$ZN3XxWr5|!3jFSTi}2$Ytgo?XSPy(=Xw1yur0
zU2}$aOv(ZnU5xh
z4?{EN!-1=m`bFnHrCNPyyl?yXMDS9txWlO2lmR{^gkr3|3fv*
z1EpNa1BS21e3t4n3DbB>O#_vtLSiO}c>nLeRlg=IY`bAB6%L>7xH9gHnUa?rV`fuZ
z7~C|?x#-sPrEa>ydS}hcKAL1$9{N55_2DL?IWROH^G32{BKb^Iva^~sSx5OP!0U`{
zykUxQM(=mNUzYG+_KmmU)wIgUHT()lEp$Y7Va9exy={q_g1H{B-@>G}kh01y`(@-U
z(~Dk7XZZ1>9%_yz?v=-7Tpu`2u}@aGo?Ymr=5r2Le}~KN>kL?G;5@YZP0oH3+Z|HM
zw2_+dp$r+laN+Av(BCQCGX?G@YI10^?=2VSsPO79bPPosM%wOY7p|8F%x9_DqX1FX
z2Se$V0O&2W(d(o#HPaMw+w_g0VZEjAPgm}wd>scr*5;mxs$OUXsHg+gbFH6N$q!b8
zkJ46$GdV8n^DU#
zQBy)EN0!AoWeD1H-aptHbTL3Lo47gzZ;DZKMz>7SJDXlAZ}GIdgfIK1veo>OS)3N-
z(aWSU=TFC05%yQFaAsxHGIF450_x3Ls9w;Sf6V@m+5ZD?XW)E~8|lX#O+1>F)yck_
zG)S}mG|La^G5rsNz<7r*e)i=JJlmsEIRqBZ;VxB2?ip>8Ql^W!h1J$+y&rr07jJqY9lIvT0D3
zRU*w+ZMuv8Qq_m~jZ1cK|AZ^dT^1Y~_vy&Rd`h+va;b;q)2d8pOkLB=Kvk+$^5wa6
z-|ES4c@mPRhz~_AaDxKkvn0qJ_1XvTjK$@1Q3{;V)W$#`@uNv-y7XE4a5yJk+}>Cj
zJ-)FKf>S5xq8u4;o=uD~tmfc-qy-a#5r=OAq|+G79l?bi+^JT@y%hif
zR;)X;4~ErEiF#ia&}O-#k20S>9)bDptniEBi^qiR0*uK~dK9;l|6RdFTPb8k@sg0J
zmf+Av-J|Lvh-iI<@q*6I458j{kcrrzVI@~9b7XNHua#Sp(mZ9vmAhlp7&V7==_}yv2LiwM=DOMWG<$#
zZ2pID#4l$=sV!~F+!h-WG*8Qh9=Zt37z&Jd*tlB}12nZ>JX&9HBeBIM&jKg7Tx;Or
zKC9n1$hTpz_UpO<)w}923k+d1OR+(H(wp7v}54`jIfK_8I
z`Q7+QM1KT61047(X*5dpj)Zb7Hui4?#E#u{g7DIKWFG@wJ8T+_et%OKFbqJtYyd6h&_`&-CG?P
z(=YRozu(~}b+`HK;OHDht!~`(tH>#Q{(PJAg4_t~TPB2Kw0jv?bVkyaVcIEnaio-I
zc2Zgvc%6%0sH3O6#)t5T0VJBCn>E*LnzD+(?^Rm5w
zcbSQ;TI#fJZz>lQK1dajSG?!zmlq1!lwtXad1gF&3;A`lrTe`c%$cbb=@jnktVRdS
zWS*ify2{mzRv4y7U!zn*!y0^q#b^Xtk4*hJoKG}>W3n~wLfeI#-gT+bLg;V7^OWM8
z)Tp#qwF@_~YZN)eUwCO(Ug`K8>_(t3=TSz#(KSdzc--HlyXeQ;kI$e&p{bxShLrbmBC
zus0`N9Kl}%JS?6;cGH|D*zJMR;Y^gAj}$LD
zMIY92-N@+C`9d%{lG}VzvnFNO@o9XTbGEWpo};kQtf@#ZXUd*&4Pclt@#TyjFN5G$
z)(#l&_eSW52Ylc=&JKuu`+n8GoXN
z59!J|Lf^piiwMkbakuj|L%OhvJfB$xTF{it+#Tw*aHwIF5av23Ael*O_$@{+T6M+y
z`oUjKi#z+j57D;06#xUX7x6-ik|$Tz&m|#n>f+j2YQojtIXYcf%j1)1#~L}rb%lr{
zf3DyAHRP>R_>d#B-p;{3X(1StKl&;?t5?|=2E}y<+pxkOgd>ZfIacuQEVoc8bJ^jF
z4+_WO{xvdyFvido!logjX9glpB}cS#w@>(wap%sRJKg{t
z>BSD3idSWIoU9lMQ&Zo){Hd>n)5I7hrduE3z!2z>
zF$+1WT$DchFXzCD&X1X>DKpe8w~Fijmm^`1Avj&E@)yXtsyf+Za!eKa)04=G0x)XC
zkD~+|QNL>(L;;;uK(6Q=NEBIj+jA8@flr0X=j6x8pj6rZX4LE@Oi>^s(N%+pvmOoJ
zmN`y-UygkgG?bJ~_SWfao}vH;$9MZp<>clMs>-Roa@FH08NT;KvH`hFHct=cOEcNf
zhN($Duh0Eor|6*6e0t(*7nHOh-NyB=3Y#ERii*c5ND55Ca0L4|k3VdVOtvL={;6i_
zL}UdLEyPq!QAC#~i?Z-A4yvEDa#GOPnYus8zITTvRNU{RIZlGhuRLd7zsh8SRTWOMK=EBlzj1y@q#~bVD~)R@Gr+@UM{0hgh80}
z@RAyZnuE6No-J3LKUt(2wW??YdZP)i1k|nSgMD9wm+GkfR>`;IMw&fBy_@fqKTREp
zp?=`SK+Yk3{`W_0+Ti%`cvY{!KqKqqw!qo-Wb$BO;XyWkW|?wpdpEaNKhdNZx*nBOIQ1zcaM8zca7=fCpI3z~Q&3yQY
zx+$gCwa{YBzR%E~rR_XcrdLzn#hNw#nbf(4Oh-DW4VX>1#urjY2gFxfxWya6q1@PP#S)>c77Mv-J&~Ve7#C{5ilqb09BFZ%RW?+
zB(ZxOEaXml&=BrAar7(%WL=vM$J_xr7|_|MQ&k<}<)qkVbYqlzWBWGLS65TxRDQRd
zfAs5o(i_Bf)eGE~UHSxvzjoTyCBg;k#_R|0?TRna(G@*~fsgc`L3Ire)r!|lNW~@4
za0UG+@#BJZ1ZPMx@tEHtEyLW%NGzCL^*EJm!huo^1T7XjgVf*kpxxuwxNmHkuRKjL
zGi$75R#Onc1bmh$T99}*H)+ug_#vk#)$}>r31viA{mZzx2tu%b8dXX=SC=J!R`+p%
zR2N(Zr=w-hb_o()oOpYx&I1pai)_lE%#h(FV<}-bbe}bNNiRIfZS&2p8qnhy3u6nF
zjzH%~$9(+5zLEntrUm-@wTuMYDHkV(F4N1)T4zVF?Af;^mToTa9fjsGx^E*&_Fjw0
zw~F@8hZx#B7!>4MTjUnjLkbJsu}+xRLX%7=_o0~41!rL;&V+-0F&i${1qnoM;t{h3
zw;e$fl%d+|H-Fbc7jBwd@31UjJKSmeCDJw6fR(^3dJQdLky|}7eHH!cqlc^>B`Aws
zYCIFs7#~hxPRG$>5J>q8$MwNI55P|&5VrU++KjJVn+U;Y`7$)b!IY1S(P!IU3*{o>pEK_PoGxj7rwz#fe7>LE=TM=q>e@k9E86UKJ+z0n%grt+eNz(Ajh+cu
zKwPagb6`!ClqD1KBnRa?vGvC@nRPJ3bB#l~bWRnKTU4ZUFc)na#$uygoe1kHkTSbgh3VlY3qfjFmGGh1gBdhy(T3ho_B0^Eue54>
zGrO)GSh%gwZy#i&&1d_$iKOZ#N2g4k#R9r*7^`~j)y~qjEuneSeMLpf#7V7+RX^Tw
z`1B|m+iP5+*dH^nj#l9e;a<*8+M&HU6wPOP!DZ`$xhuGbHQ+{H^ulaoXI2Ql3Y`xbU8D#)$Jtr
z=1mws7LKhIe8NxUy=s?}<}
zb?^sYO6g$<_ZEPiz^m#>>cvGvA{XKc;PenV_4u*)uB0+~KRBpMToN(N%NmPNRUAE;
zpcK^gB7wFggYg;2-slKQZHx)yE;+aRkHOK>b8>dfRMo8R|+c&@{{sb9++UNqDY
zC<3}bIqr?wNuCBFdbbm7yNU)ax&`ts?ZSjc#Ra1rPSVmKKytzfX_l1yDU;yuN0`GE
z0?#o?pQiBV_Ph#-<9(Zrx=&Cm-enO_YJ+uA2e!bA7H=?&>mjz#dScUAVzZEbmDX>$
z%fcFG>a&*dQ{K9<3;fC1yX=$ek+#jAX|Hy-bOmZRbz?SH4&1zqPZ;>x4p8
a_XyRdy1QZ%@C8jEr^D`tst=s{>3;#p)Md^9

literal 0
HcmV?d00001


From 5036ebe02b4c2090386f8c1dc7ebee6d65a26c48 Mon Sep 17 00:00:00 2001
From: Eric Lombrozo 
Date: Thu, 24 Dec 2015 17:37:28 -0500
Subject: [PATCH 086/259] Removed consensus layer stuff and added new section
 headers.

---
 bip-codeshark-segwit-peer-services.mediawiki | 219 +------------------
 1 file changed, 5 insertions(+), 214 deletions(-)

diff --git a/bip-codeshark-segwit-peer-services.mediawiki b/bip-codeshark-segwit-peer-services.mediawiki
index c81e1dbb..35bd0598 100644
--- a/bip-codeshark-segwit-peer-services.mediawiki
+++ b/bip-codeshark-segwit-peer-services.mediawiki
@@ -15,6 +15,8 @@ This BIP defines new messages and serialization formats for propagation of trans
 
 ==Specification==
 
+=== Serializations ===
+
 A new serialization format for tx messages is added to the peer-to-peer protocol.
 
 The serialization has the following structure:
@@ -113,223 +115,12 @@ have empty ones.
 serialization. A new CTransaction::GetWitnessHash is added which is
 computed from the witness-serialization (this means that transactions
 with an empty witness have witness hash equal to normal hash).
-

 
-=== Commitment structure ===
+== Synchronization ==
 
-!!!DRAFT ONLY!!!
+=== Initial Blockchain Download ===
 
-A new block rule is added which requires a commitment to the witness hashes in the coinbase (or an OP_RETURN output of a specific transaction, or somewhere else)
-
-(Hardfork after x year to move the commitment to block header?)
-
-Witness hash is the double SHA256 of a transaction including witnesses: http://blockhawk.net/diagrams/witnesstx.png. For the coinbase transaction, its witness hash is assumed to be 0x0000....0000.
-
-A witness root hash is calculated with all those witness hashes as leaves, in a way similar to the hashMerkleRoot in the block header.
-
-No witness data is allowed in blocks that don't commit to witness data, as this would otherwise leave room from spam.
-
-==== Proposal 1: balance tree (the current implementation) ====
-The commitment is a push of exactly 41 bytes:
-*The first 4 bytes are commitment header: 0xaa21a9ed
-*The next 4 bytes describe a nonce
-*The next 1 byte is the "levels bytes", describes the number of levels in a Merkle tree (0 to 32)
-*The next 32 bytes is a commitment root hash (not the witness root hash)
-
-Locator of the witness root hash is defined as:
-
-
SHA256('WitnessV1\x00\x00\x00\x00\x00\x00\x00' || nonce)

-
-The first levels bits of locator, interpreted in little endian, are assumed to be the position in the leaves of the Merkle tree where the witness root hash goes.
-
-The coinbase's input's witness must consist of a single byte array of 32 * levels bytes, and are assumed to be the Merkle path to connect the witness root hash to the commitment root hash.
-
-====Proposal 2: imbalance tree====
-The commitment is a push of exactly 40 bytes:
-*The first 4 bytes are commitment header: 0xaa21a9ed
-*The next 4 bytes describe a nonce
-*The next 32 bytes is a commitment root hash (not the witness root hash)
-
-Locator of the witness root hash is defined as:
-
-
SHA256('WitnessV1\x00\x00\x00\x00\x00\x00\x00' || nonce)

-
-The first levels bits of locator, interpreted in little endian, are assumed to be the position in the leaves of the Merkle tree where the witness root hash goes.
-
-The coinbase's input's witness must consist of a single byte array, which the size must be a multiple of 32 bytes but not bigger than 32*32 bytes. These are assumed to be the Merkle path to connect the witness root hash to the commitment root hash. Depth of the commitment is determined by the length of the path. If the depth of the tree is 0, the path should be represented by 0x00, and the witness root hash will be same as the commitment root hash.
-
-=== Block size limit ===
-Blocks are currently limited to 1 MB total size. We change this restriction as follows:
-
-We define a base block size sb consisting of the existing header and transactions, a witness size sw consisting of only the size of the witness data, and a virtual block size sv = sb + sw/4.
-
-The new rule is sv <= 1 MB.
-
-=== Witness program ===
-
-* A scriptPubKey (or redeemScript as defined in BIP16/P2SH) that consists of a single push of 2 to 41 bytes gets a new special meaning. The byte vector pushed by it is called the "witness program".
-** In case the scriptPubKey pushes a witness program directly, the scriptSig must be exactly empty.
-** In case the redeemScript pushes a witness program, the scriptSig must be exactly the single push of the redeemScript.
-
-* The first byte of a witness program is the "version byte", an unsigned integer.
-** If the version byte is 0, the rest of the witness program is the actual script.
-*** The script is executed after normal script evaluation but with data from the witness rather than the scriptSig.
-*** The program must not fail, and result in exactly a single TRUE on the stack.
-** If the version byte is 1, the rest of the witness program must be 32 bytes, as a SHA256 hash of the actual script.
-*** The witness must consist of an input stack to feed to the program, followed by the serialized program.
-*** The serialized program is popped off the initial witness stack. Hash of the serialized program must match the hash pushed in the witness program.
-*** The serialized program is deserialized, and executed after normal script evaluation with the remaining witness stack.
-*** The script must not fail, and result in exactly a single TRUE on the stack.
-** If the witness version byte is 2 or above, no further interpretation of the witness program or witness happens.
-
-=== Other consensus critical constraints ===
-
-== Block size analysis ==
-WORK IN PROGRESS
-
-Definitions:
-
- Core block size (CBS): The block size as seen by a non-upgrading full node
- Witness size (WS): The total size of witness data in a block
- Total block size (TBS): CBS + WS
- Witness discount (WD): A discount factor for witness data in VBS calculation (1 = no discount)
- Virtual block size (VBS): CBS + (WS * WD)
- Witness adoption (WA): Proportion (in size) of new format transactions among all transactions
- Prunable ratio (PR): Proportion of signature data size in a transaction
-

-
-With some transformation it could be shown that:
-
- TBS = CBS / (1 - WA * PR)
-     = VBS / (1 - WA * PR * (1 - WD))
-

-
-In order to keep the proposal as a soft fork, the CBS must not have a upper limit higher than 1MB.
-
-The PR heavily depends on the transaction script type and input-output ratio. For example, the PR of 1-in 2-out P2PKH and 1-in 1-out 2-of-2 multisig P2SH are about 47% and 72% respectively. According to the data presented by Pieter Wuille on 7 December 2015, the current average PR on the blockchain is about 60%.
-
-
-
-== Examples ==
-
-=== Version 0 witness program ===
-
-The following example is a version 0 witness program, equivalent to the existing Pay-to-Pubkey-Hash (P2PKH) output.
-
-    witness:       
-    scriptSig:    (empty)
-    scriptPubKey: <0x0076A914{20-byte-hash-value}88AC>
-
-The version byte 0x00 is removed. The rest of the witness program is deserialized and becomes:
-
-    DUP HASH160 <20byte-hash-value> EQUALVERIFY CHECKSIG
-
-The script is executed with the data from witness
-
-      DUP HASH160 <20byte-hash-value> EQUALVERIFY CHECKSIG
-
-Comparing with a P2PKH output, the witness program equivalent occupies 2 more bytes in the scriptPubKey, while moving the signature and public key from scriptSig to witness.
-
-=== Version 1 witness program ===
-
-The following example is an 1-of-2 multi-signature version 1 witness program.
-
-    witness:      0  <0x5121{33-byte-pubkey1}21{33-byte-pubkey2}52AE>
-    scriptSig:    (empty)
-    scriptPubKey: <0x01{32-byte-hash-value}>
-
-The last item in the witness is popped off, hashed with SHA256, compared against the 32-byte-hash-value in scriptPubKey, and deserialized:
-
-    1 <33-byte-pubkey1> <33-byte-pubkey2> 2 CHECKMULTISIG
-
-The script is executed with the remaining data from witness:
-
-    0  1 <33-byte-pubkey1> <33-byte-pubkey2> 2 CHECKMULTISIG
-
-Since the actual program is larger than 40 bytes, it cannot be accommodated in a version 0 witness program. A version 1 witness program allows arbitrarily large script as the 520-byte push limit is bypassed.
-
-The scriptPubKey occupies 34 bytes, as opposed to 23 bytes of P2SH. The increased size improves security against possible collision attacks, as 2^80 work is not infeasible anymore (By the end of 2015, 2^84 hashes have been calculated in Bitcoin mining since the creation of Bitcoin). The spending script is same as the one for an equivalent P2SH output but is moved to witness.
-
-=== Witness program nested in Pay-to-Script-Hash ===
-
-The following example is the same 1-of-2 multi-signature version 1 witness program, but nested in a P2SH output.
-
-    witness:      0  <0x5121{33-byte-pubkey1}21{33-byte-pubkey2}52AE>
-    scriptSig:    <0x2101{32-byte-hash-value}>
-    scriptPubKey: HASH160 <20-byte-hash-value> EQUAL
-
-The only item in scriptSig is hashed with HASH160, compared against the 20-byte-hash-value in scriptPubKey, and interpreted as a single push of:
-
-    <0x01{32-byte-hash-value}>
-
-The version 1 witness program is then executed as described in the last example
-
-Comparing with the last example, the scriptPubKey is 11 bytes smaller (with reduced security) while witness is the same. However, it also requires 35 bytes in scriptSig, which is not prunable in transmission. Although a nested witness program is less efficient in many ways, its payment address is fully transparent and backward compatible for all Bitcoin reference client since version 0.6.0.
-
-=== Trust-free unconfirmed transaction dependency chain ===
-Segregated witness fixes the problem of transaction malleability fundamentally, which enables the building of unconfirmed transaction dependency chains in a trust-free manner.
-
-Two parties, Alice and Bob, may agree to send certain amount of Bitcoin to a 2-of-2 multisig output (the "funding transaction"). Without signing the funding transaction, they may create another transaction, time-locked in the future, spending the 2-of-2 multisig output to third account(s) (the "spending transaction"). Alice and Bob will sign the spending transaction and exchange the signatures. After examining the signatures, they will sign and commit the funding transaction to the blockchain. Without further action, the spending transaction will be confirmed after the lock-time and release the funding according to the original contract. It also retains the flexibility of revoking the original contract before the lock-time, by another spending transaction with shorter lock-time, but only with mutual-agreement of both parties.
-
-Such setups is not possible with BIP62 as the malleability fix, since the spending transaction could not be created without both parties first signing the funding transaction. If Alice reveals the funding transaction signature before Bob does, Bob is able to lock up the funding indefinitely without ever signing the spending transaction.
-
-Unconfirmed transaction dependency chain is a fundamental building block of more sophisticated payment networks, such as duplex micropayment channel and the Lightning Network, which have the potential to greatly improve the scalability and efficiency of the Bitcoin system.
-
-== Future extensions ==
-=== Compact fraud proof for SPV nodes ===
-Bitcoin right now only has two real security models. A user either runs a full-node which validates every block with all rules in the system, or a SPV (Simple Payment Verification) client which only validates the headers as a proof of publication of some transactions. The Bitcoin whitepaper suggested that SPV nodes may accept alerts from full nodes when they detect an invalid block, prompting the SPV node to download the questioned blocks and transactions for validation. This approach, however, could become a DoS attack vector as there is virtually no cost to generate a false alarm. An alarm must come with a compact, yet deterministic fraud proof.
-
-In the current Bitcoin protocol, it is possible to generate compact fraud proof for almost all rules except a few:
-
-# It is not possible to proof a miner has introduced too many Bitcoins in the coinbase transaction outputs without showing the whole block itself and all input transactions.
-# It is not possible to prove the violation of any block specific constraints, such as size and sigop limits, without showing the whole block (and all input transactions in the case of sigop limit)
-# It is not possible to prove the spending of a non-existing input without showing all transaction IDs in the blockchain way back to the genesis block.
-
-It is possible to proof the first 2 types of fraud if a block is committed to a Merkle-sum-tree of the fee, size, and sigop count of each transaction. It is also possible to proof the last type of fraud if a block is committed to a Merkle tree with the originating block height and transaction index of all inputs. These commitments could be included in the extensible witness commitment through a soft fork and will be transparent to nodes that do not understand such new rules.
-
-=== New script system ===
-Since all witness programs begin with a version byte, and programs with unknown versions are always considered as anyone-can-spend script, it is possible to introduce any new script system with a soft fork. The witness as a structure is not restricted by any existing script semantics and constraints, the 520-byte push limit in particular, and therefore allows arbitrarily large scripts and signatures.
-
-Examples of new script system include Schnorr signatures which reduce the size of multisig transactions dramatically, Lamport signature which is quantum computing resistance, and Merklized abstract syntax trees which allow very compact witness for conditional scripts with extreme complexity.
-
-The 41-byte limitation for witness programme could be easily extended through a soft fork in case a stronger hash function is needed in the future. The version byte is also expandable by introducing a secondary version byte for some specific primary version values.
-
-=== Per-input lock-time and relative-lock-time ===
-Currently there is only one nLockTime field in a transaction and all inputs must share the same value. BIP68 enables per-input relative-lock-time using the nSequence field, however, with a limited lock-time period and resolution.
-
-With a soft fork, it is possible to introduce a separate witness structure to allow per-input lock-time and relative-lock-time, and a new script system that could sign and manipulate the new data (like BIP65 and BIP112).
-
-== Backward compatibility ==
-As a soft fork, older software will continue to operate without modification.  Non-upgraded nodes, however, will not see nor validate the witness data and will consider all witness programs as anyone-can-spend scripts (except a few edge cases in version 0 witness programs which are provably unspendable with original script semantics). Wallets should always be wary of anyone-can-spend scripts and treat them with suspicion. Non-upgraded nodes are strongly encouraged to upgrade in order to take advantage of the new features.
-
-=== Version 0 witness programs ===
-Witness programs are hashed to 256 bit "redeemscripts" which are then hashed to 160 bit P2SH. This format is fully compatible with currently existing wallets that support P2SH. Upgraded wallets will be able to send and receive to and from older wallets without any problems.
-
-=== Version 1 witness programs ===
-Witness programs are hashed to a 256 bit output. This format will not be compatible with older wallets but will require less block space and will have better security due to increased collision resistance.
-
-== Deployment ==
-
-We reuse the double-threshold IsSuperMajority() switchover mechanism used in
-BIP65 with the same thresholds, but for nVersion = 5. The new rules are
-in effect for every block (at height H) with nVersion = 5 and at least
-750 out of 1000 blocks preceding it (with heights H-1000..H-1) also
-have nVersion >= 5. Furthermore, when 950 out of the 1000 blocks
-preceding a block do have nVersion >= 5, nVersion < 5 blocks become
-invalid, and all further blocks enforce the new rules.
-
-(It should be noted that BIP9 involves permanently setting a high-order bit to
-1 which results in nVersion >= all prior IsSuperMajority() soft-forks and thus
-no bits in nVersion are permanently lost.)
-
-
-=== SPV Clients ===
-
-While SPV clients are unable to fully validate blocks,
-they are able to validate block headers and, thus, can check block version and proof-of-work.
-SPV clients should reject nVersion < 5 blocks if 950 out of 1000 preceding blocks have
-nVersion >= 5 to prevent false confirmations from the remaining 5% of
-non-upgraded miners when the 95% threshold has been reached.
+=== Message Propagation ===
 
 == Credits ==
 Special thanks to Gregory Maxwell for originating many of the ideas in this BIP and Luke-Jr for figuring out how to deploy this as a soft fork.

From 0d887af4035dc8f5258ad3c54f5a42d2973f6b1d Mon Sep 17 00:00:00 2001
From: Eric Lombrozo 
Date: Fri, 25 Dec 2015 19:03:02 -0500
Subject: [PATCH 087/259] Separate authors into two lines.

---
 bip-codeshark-segwit-peer-services.mediawiki | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/bip-codeshark-segwit-peer-services.mediawiki b/bip-codeshark-segwit-peer-services.mediawiki
index 35bd0598..121cd5a1 100644
--- a/bip-codeshark-segwit-peer-services.mediawiki
+++ b/bip-codeshark-segwit-peer-services.mediawiki
@@ -1,7 +1,8 @@
 
   BIP: x
   Title: Segregated Witness (Peer Services)
-  Authors: Eric Lombrozo , Pieter Wuille 
+  Author: Eric Lombrozo 
+          Pieter Wuille 
   Status: Draft
   Type: Standards Track
   Created: 2015-12

From 84dc2f7ddcf0b08adec056532fd9021ee461d1d5 Mon Sep 17 00:00:00 2001
From: Eric Lombrozo 
Date: Fri, 25 Dec 2015 18:57:27 -0500
Subject: [PATCH 088/259] New sections

---
 bip-codeshark-segwit-peer-services.mediawiki | 30 ++++++++------------
 1 file changed, 12 insertions(+), 18 deletions(-)

diff --git a/bip-codeshark-segwit-peer-services.mediawiki b/bip-codeshark-segwit-peer-services.mediawiki
index 121cd5a1..37c5d17d 100644
--- a/bip-codeshark-segwit-peer-services.mediawiki
+++ b/bip-codeshark-segwit-peer-services.mediawiki
@@ -16,8 +16,7 @@ This BIP defines new messages and serialization formats for propagation of trans
 
 ==Specification==
 
-=== Serializations ===
-
+=== Serialization ===
 A new serialization format for tx messages is added to the peer-to-peer protocol.
 
 The serialization has the following structure:
@@ -63,7 +62,7 @@ The serialization has the following structure:
 | txouts[]
 | A list of one or more transaction outputs
 |-
-| 
+| 1+
 | txin_witness
 | txin_witness
 | Transaction input witness
@@ -85,10 +84,7 @@ Witness objects can potentially be extended to contain other kinds of witness da
 A script witness is a vector of byte vectors (nominally: the input stack to the program, no longer
 encoded as a scriptSig, but just the resulting stack directly).
 
-as a valid transaction (even if parsing succeeds, it means it's
-interpreted as a transaction with no inputs and 1 output). If all
-witnesses are empty, the old serialization format is used.
-- Rationale for not having an independent CWitnessTransaction with
+- Rationale for not having an independent message type with
 its own serialization: this would require separate "tx" and "block"
 messages, and all RPC calls operating on raw transactions would need
 to be duplicated, or need inefficinent or nondeterministic guesswork
@@ -100,29 +96,27 @@ used in some tests) to be interpreted as new serialized data.
 easily add more extra non-committed data to transactions (like txouts
 being spent, ...). It can be interpreted as a bitvector.
 
-* A new message 'havewitness' is sent after receiving 'verack' to
+=== Handshake ===
+A new message 'havewitness' is sent after receiving 'verack' to
 indicate that a node can provide witness if requested (similar to
-'sendheaders')
+'sendheaders') (Note: it might be better to signal this with a services bit in the version message)
 
-* New inv types MSG_WITNESS_TX and MSG_WITNESS_BLOCK are added, only
+=== Relay ===
+New inv types MSG_WITNESS_TX and MSG_WITNESS_BLOCK are added, only
 for use in getdata. Inv itself still use just MSG_TX and MSG_BLOCK,
 similar to MSG_FILTERED_BLOCK.
+
 - Rationale for not advertizing witnessness in invs: we don't always
 use invs anymore (with 'sendheaders' BIP 130), plus it's not useful:
 implicitly, every transaction and block have a witness, old ones just
 have empty ones.
 
-* Transactions' GetHash is always computed on the old non-witness
-serialization. A new CTransaction::GetWitnessHash is added which is
+=== Hashes ===
+Transaction hashes used in the transaction merkle tree and txin outpoints is always computed on the old non-witness
+serialization. A new hash including the witness data is added that is
 computed from the witness-serialization (this means that transactions
 with an empty witness have witness hash equal to normal hash).
 
-== Synchronization ==
-
-=== Initial Blockchain Download ===
-
-=== Message Propagation ===
-
 == Credits ==
 Special thanks to Gregory Maxwell for originating many of the ideas in this BIP and Luke-Jr for figuring out how to deploy this as a soft fork.
 

From 0ea5ba232dd33836d9ce0a4b24690dd8a8c0f193 Mon Sep 17 00:00:00 2001
From: Eric Lombrozo 
Date: Fri, 25 Dec 2015 19:14:36 -0500
Subject: [PATCH 089/259] Added motivation section text.

---
 bip-codeshark-segwit-peer-services.mediawiki | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/bip-codeshark-segwit-peer-services.mediawiki b/bip-codeshark-segwit-peer-services.mediawiki
index 37c5d17d..7e94b737 100644
--- a/bip-codeshark-segwit-peer-services.mediawiki
+++ b/bip-codeshark-segwit-peer-services.mediawiki
@@ -9,10 +9,10 @@
 

 
 ==Abstract==
-
 This BIP defines new messages and serialization formats for propagation of transactions and blocks committing to segregated witness structures.
 
 ==Motivation==
+In addition to defining witness structures and requiring commitments in future blocks (BIPxxxx - Consensus segwit BIP), new mechanisms must be defined to allow peers to advertise support for segregated witness and to relay the witness structures and request them from other peers without breaking compatibility with older nodes.
 
 ==Specification==
 

From 0ab3b3eb0c50ea24c9043219d7f968825dc68221 Mon Sep 17 00:00:00 2001
From: Eric Lombrozo 
Date: Fri, 25 Dec 2015 19:17:00 -0500
Subject: [PATCH 090/259] Moved diagrams to hashes section.

---
 bip-codeshark-segwit-peer-services.mediawiki | 15 +++++++++------
 1 file changed, 9 insertions(+), 6 deletions(-)

diff --git a/bip-codeshark-segwit-peer-services.mediawiki b/bip-codeshark-segwit-peer-services.mediawiki
index 7e94b737..c5b205ef 100644
--- a/bip-codeshark-segwit-peer-services.mediawiki
+++ b/bip-codeshark-segwit-peer-services.mediawiki
@@ -73,8 +73,6 @@ The serialization has the following structure:
 | The block number or timestamp until which the transaction is locked
 |}
 
-
-
 Parsers supporting this BIP will be able to distinguish between the old serialization format (without the witnesses) and this one. The marker byte is set to zero so that this structure will never parse as a valid transaction in a parser that does not support this BIP. If parsing were to succeeded, such a transaction would contain no inputs and a single output.
 
 If all witnesses are empty, the old serialization format should be used. 
@@ -112,10 +110,15 @@ implicitly, every transaction and block have a witness, old ones just
 have empty ones.
 
 === Hashes ===
-Transaction hashes used in the transaction merkle tree and txin outpoints is always computed on the old non-witness
-serialization. A new hash including the witness data is added that is
-computed from the witness-serialization (this means that transactions
-with an empty witness have witness hash equal to normal hash).
+Transaction hashes used in the transaction merkle tree and txin outpoints are always computed using the old non-witness
+serialization.
+
+Support for a new hash including the witness data is added that is
+computed from the new witness serialization. (Note that transactions
+with an empty witness always use the old serialization,
+and therefore, they have witness hash equal to normal hash.)
+
+
 
 == Credits ==
 Special thanks to Gregory Maxwell for originating many of the ideas in this BIP and Luke-Jr for figuring out how to deploy this as a soft fork.

From 1f538fd4589b18ddede831e0cbfb0401f5ec8472 Mon Sep 17 00:00:00 2001
From: Eric Lombrozo 
Date: Fri, 25 Dec 2015 19:41:39 -0500
Subject: [PATCH 091/259] Bulletted rationales and other minor changes.

---
 bip-codeshark-segwit-peer-services.mediawiki | 30 ++++++--------------
 1 file changed, 9 insertions(+), 21 deletions(-)

diff --git a/bip-codeshark-segwit-peer-services.mediawiki b/bip-codeshark-segwit-peer-services.mediawiki
index c5b205ef..6e0bc6e7 100644
--- a/bip-codeshark-segwit-peer-services.mediawiki
+++ b/bip-codeshark-segwit-peer-services.mediawiki
@@ -63,9 +63,9 @@ The serialization has the following structure:
 | A list of one or more transaction outputs
 |-
 | 1+
-| txin_witness
-| txin_witness
-| Transaction input witness
+| txin_witnesses
+| txin_witnesses[]
+| A list of one or more transaction input witnesses (note: the count is just txin_count)
 |-
 | 4
 | lock_time
@@ -77,22 +77,13 @@ Parsers supporting this BIP will be able to distinguish between the old serializ
 
 If all witnesses are empty, the old serialization format should be used. 
 
-Witness objects can potentially be extended to contain other kinds of witness data.
+Witness objects can be extended to contain other kinds of witness data not yet specified. This BIP is agnostic to the witness data structure, defined in BIPxxxx (Consensus Segwit BIP), and treats it as an arbitrary byte array.
 
-A script witness is a vector of byte vectors (nominally: the input stack to the program, no longer
-encoded as a scriptSig, but just the resulting stack directly).
+* '''Rationale for not having an independent message type with its own serialization''': this would require separate "tx" and "block" messages, and all RPC calls operating on raw transactions would need to be duplicated, or need inefficinent or nondeterministic guesswork to know which type is to be used.
 
-- Rationale for not having an independent message type with
-its own serialization: this would require separate "tx" and "block"
-messages, and all RPC calls operating on raw transactions would need
-to be duplicated, or need inefficinent or nondeterministic guesswork
-to know which type is to be used.
-- Rationale for not using just a single 0x00 byte as marker: that
-would lead to empty transactions (no inputs, no outputs, which are
-used in some tests) to be interpreted as new serialized data.
-- Rationale for the 0x01 flag byte in between: this will allow us to
-easily add more extra non-committed data to transactions (like txouts
-being spent, ...). It can be interpreted as a bitvector.
+* '''Rationale for not using just a single 0x00 byte as marker''': that would lead to empty transactions (no inputs, no outputs, which are used in some tests) to be interpreted as new serialized data.
+
+* '''Rationale for the 0x01 flag byte in between''': this will allow us to easily add more extra non-committed data to transactions (like txouts being spent, ...). It can be interpreted as a bitvector.
 
 === Handshake ===
 A new message 'havewitness' is sent after receiving 'verack' to
@@ -104,10 +95,7 @@ New inv types MSG_WITNESS_TX and MSG_WITNESS_BLOCK are added, only
 for use in getdata. Inv itself still use just MSG_TX and MSG_BLOCK,
 similar to MSG_FILTERED_BLOCK.
 
-- Rationale for not advertizing witnessness in invs: we don't always
-use invs anymore (with 'sendheaders' BIP 130), plus it's not useful:
-implicitly, every transaction and block have a witness, old ones just
-have empty ones.
+* '''Rationale for not advertizing witnessness in invs''': we don't always use invs anymore (with 'sendheaders' BIP 130), plus it's not useful: implicitly, every transaction and block have a witness, old ones just have empty ones.
 
 === Hashes ===
 Transaction hashes used in the transaction merkle tree and txin outpoints are always computed using the old non-witness

From 35990e2faa69c326807418a6405a25139e92db6f Mon Sep 17 00:00:00 2001
From: Eric Lombrozo 
Date: Fri, 25 Dec 2015 19:56:11 -0500
Subject: [PATCH 092/259] Use abstract witness structure

---
 bip-codeshark-segwit-peer-services.mediawiki | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/bip-codeshark-segwit-peer-services.mediawiki b/bip-codeshark-segwit-peer-services.mediawiki
index 6e0bc6e7..7501d2b8 100644
--- a/bip-codeshark-segwit-peer-services.mediawiki
+++ b/bip-codeshark-segwit-peer-services.mediawiki
@@ -63,9 +63,9 @@ The serialization has the following structure:
 | A list of one or more transaction outputs
 |-
 | 1+
-| txin_witnesses
-| txin_witnesses[]
-| A list of one or more transaction input witnesses (note: the count is just txin_count)
+| witness
+| witness
+| The witness structure as a serialized byte array
 |-
 | 4
 | lock_time
@@ -73,9 +73,9 @@ The serialization has the following structure:
 | The block number or timestamp until which the transaction is locked
 |}
 
-Parsers supporting this BIP will be able to distinguish between the old serialization format (without the witnesses) and this one. The marker byte is set to zero so that this structure will never parse as a valid transaction in a parser that does not support this BIP. If parsing were to succeeded, such a transaction would contain no inputs and a single output.
+Parsers supporting this BIP will be able to distinguish between the old serialization format (without the witness) and this one. The marker byte is set to zero so that this structure will never parse as a valid transaction in a parser that does not support this BIP. If parsing were to succeeded, such a transaction would contain no inputs and a single output.
 
-If all witnesses are empty, the old serialization format should be used. 
+If the witness is empty, the old serialization format should be used. 
 
 Witness objects can be extended to contain other kinds of witness data not yet specified. This BIP is agnostic to the witness data structure, defined in BIPxxxx (Consensus Segwit BIP), and treats it as an arbitrary byte array.
 

From d1f008b8787f2d9151beeadeb749468400e6c2b2 Mon Sep 17 00:00:00 2001
From: Marco Pontello 
Date: Sat, 26 Dec 2015 16:46:02 +0100
Subject: [PATCH 093/259] Changed temporary name to bip-MarcoPon-BlockchainURI
 - Waiting for BIP number assignment

---
 README.mediawiki                                                | 2 +-
 ...arcoPon-01.mediawiki => bip-MarcoPon-BlockchainURI.mediawiki | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)
 rename bip-MarcoPon-01.mediawiki => bip-MarcoPon-BlockchainURI.mediawiki (99%)

diff --git a/README.mediawiki b/README.mediawiki
index 4d90c239..9e68b022 100644
--- a/README.mediawiki
+++ b/README.mediawiki
@@ -374,7 +374,7 @@ Those proposing changes should consider that ultimately consent may rest with th
 | Standard
 | Draft
 |-
-| [[bip-MarcoPon-01.mediawiki| xx]]
+| [[bip-MarcoPon-BlockchainURI.mediawiki| xx]]
 | URI scheme for Blockchain references / exploration
 | Marco Pontello
 | Standard
diff --git a/bip-MarcoPon-01.mediawiki b/bip-MarcoPon-BlockchainURI.mediawiki
similarity index 99%
rename from bip-MarcoPon-01.mediawiki
rename to bip-MarcoPon-BlockchainURI.mediawiki
index b8483c22..2380f80c 100644
--- a/bip-MarcoPon-01.mediawiki
+++ b/bip-MarcoPon-BlockchainURI.mediawiki
@@ -1,5 +1,5 @@
 
-  BIP: MarcoPon-01
+  BIP: bip-MarcoPon-BlockchainURI
   Title: URI scheme for Blockchain references / exploration
   Author: Marco Pontello 
   Status: Draft

From d0ad38fb692ac919bd116a69f5f60e0c856b9148 Mon Sep 17 00:00:00 2001
From: Eric Lombrozo 
Date: Sat, 26 Dec 2015 16:41:57 -0500
Subject: [PATCH 094/259] Added to relay section.

---
 bip-codeshark-segwit-peer-services.mediawiki | 18 +++++++++++-------
 1 file changed, 11 insertions(+), 7 deletions(-)

diff --git a/bip-codeshark-segwit-peer-services.mediawiki b/bip-codeshark-segwit-peer-services.mediawiki
index 7501d2b8..78412c1d 100644
--- a/bip-codeshark-segwit-peer-services.mediawiki
+++ b/bip-codeshark-segwit-peer-services.mediawiki
@@ -90,13 +90,6 @@ A new message 'havewitness' is sent after receiving 'verack' to
 indicate that a node can provide witness if requested (similar to
 'sendheaders') (Note: it might be better to signal this with a services bit in the version message)
 
-=== Relay ===
-New inv types MSG_WITNESS_TX and MSG_WITNESS_BLOCK are added, only
-for use in getdata. Inv itself still use just MSG_TX and MSG_BLOCK,
-similar to MSG_FILTERED_BLOCK.
-
-* '''Rationale for not advertizing witnessness in invs''': we don't always use invs anymore (with 'sendheaders' BIP 130), plus it's not useful: implicitly, every transaction and block have a witness, old ones just have empty ones.
-
 === Hashes ===
 Transaction hashes used in the transaction merkle tree and txin outpoints are always computed using the old non-witness
 serialization.
@@ -108,6 +101,17 @@ and therefore, they have witness hash equal to normal hash.)
 
 
 
+=== Relay ===
+New inv types MSG_WITNESS_TX and MSG_WITNESS_BLOCK are added, only
+for use in getdata. Inventory messages themselves still use just MSG_TX and MSG_BLOCK,
+similar to MSG_FILTERED_BLOCK.
+
+* '''Rationale for not advertizing witnessness in invs''': we don't always use invs anymore (with 'sendheaders' BIP 130), plus it's not useful: implicitly, every transaction and block have a witness, old ones just have empty ones.
+
+MSG_WITNESS_TX getdata requests should use the non-witness serialized hash. The peer shall respond with a tx message, and if the witness structure is nonempty, the witness serialization shall be used.
+
+MSG_WITNESS_BLOCK requests will return a block message with transactions that have a witness using witness serialization.
+
 == Credits ==
 Special thanks to Gregory Maxwell for originating many of the ideas in this BIP and Luke-Jr for figuring out how to deploy this as a soft fork.
 

From 93cedfbf2d50eb1f0ba750d364304f7adf7bcf79 Mon Sep 17 00:00:00 2001
From: Johnson Lau 
Date: Sun, 27 Dec 2015 16:21:19 +0800
Subject: [PATCH 095/259] New proposal with 2 address types

---
 bip-segwitaddress.mediawiki | 115 +++++++++++++++++++++++-------------
 1 file changed, 75 insertions(+), 40 deletions(-)

diff --git a/bip-segwitaddress.mediawiki b/bip-segwitaddress.mediawiki
index eed5b313..34ff5f3e 100644
--- a/bip-segwitaddress.mediawiki
+++ b/bip-segwitaddress.mediawiki
@@ -1,6 +1,6 @@
 
   BIP: x
-  Title: Address Format for Witness Program
+  Title: Address Formats for Witness Program
   Author: Johnson Lau 
   Status: Draft
   Type: Standards Track
@@ -9,35 +9,65 @@
 
 ==Abstract==
 
-This BIP describes a new type of Bitcoin address to support native Segregated Witness (segwit) transactions. An address encoded under this proposal represents the base-58 encoding of a witness program. It supports arbitrarily complex transactions, and is forward compatible to new version witness programs in the future.
+This BIP describes 2 new types of Bitcoin address to support native Segregated Witness (segwit) transactions. The first type resembles the original P2PKH base-58 address. The second type is a z-base-32 representation of a witness program with Damm algorithm checksum, which supports arbitrarily complex transactions, and is forward compatible to new version witness programs in the future.
 
 ==Motivation==
 
-To define a standard payment address for native segwit transactions, with minimal changes from existing address types, for the promotion of early adoption of the more efficient transaction method.
+To define standard payment addresses for native segwit transactions to promote early adoption of the more efficient transaction method.
 
-==Specification==
+== Specification ==
+=== P2PKH segwit address ===
+The first new Bitcoin address format defined is specific to pay-to-public-key-hash segwit transaction. The scriptPubKey is a single push of version-0 witness program in this form,
+  <0x0076A914{20-byte-hash-value}88AC>
+The new address is encoded exactly in the same way as the original pay-to-public-key-hash address:
+  base58-encode: [1-byte version][20-byte-hash-value][4-byte checksum]
+Version byte is 0x19 for a main-network address, 0x41 for a testnet address. The following 20-byte is the public key hash. And the 4-byte checksum is the first four bytes of the double SHA256 hash of the version and public key hash.
 
-The new bitcoin address type is constructed in a similar manner of the original pay-to-public-key-hash addresses and pay-to-script-hash addresses (see BIP13):
+All addresses generated with this scheme will a constant length of 34 characters, with a "B" prefix for main-network and "T" prefix for testnet.
 
-  base58-encode:
-    [one-byte version]
-    [one-byte program length]
-    [2 to 41-byte witness program]
-    [padding by 0x00 to 43 bytes]
-    [4-byte checksum]
-    (47 bytes in total)
+=== General segwit address ===
+The second new bitcoin address format defined is applicable to any version of witness program with a length of 2 to 33 bytes.
 
-Version byte is 0x15 for a main-network address, 0x37 for a testnet address.
+The z-base-32 character set is used:
+{|class="wikitable" style="width:40ex; text-align: center; margin: 0 auto 0 auto;"
+!width="12%"|Value
+!width="12%"|Symbol
+!width="12%"|Value
+!width="12%"|Symbol
+!width="12%"|Value
+!width="12%"|Symbol
+!width="12%"|Value
+!width="12%"|Symbol
+|-
+| 0 || y ||  8 || e || 16 || o || 24 || a
+|-
+| 1 || b ||  9 || j || 17 || t || 25 || 2
+|-
+| 2 || n || 10 || k || 18 || 1 || 26 || 4
+|-
+| 3 || d || 11 || m || 19 || u || 27 || 5
+|-
+| 4 || r || 12 || c || 20 || w || 28 || h
+|-
+| 5 || f || 13 || p || 21 || i || 29 || 7
+|-
+| 6 || g || 14 || q || 22 || s || 30 || 6
+|-
+| 7 || 8 || 15 || x || 23 || z || 31 || 9
+|}
 
-Program length byte indicates the length of witness program (L), from 0x02 to 0x29.
+It is case-insensitive and includes all alphanumeric characters excluding 0, 2, l, v. The order of alphabet is chosen so that less ambiguous alphabet characters will appear more frequently than others.
 
-The following 2 to 41 bytes is the actual witness program.
+An address starts with a version digit, which is b32 for the main-network and t32 for the testnet.
 
-The following (41 minus L) bytes is padded by 0x00.
+The next digit is a length digit, which the value is length of the witness program in byte (L) minus 2.
 
-The 4-byte checksum is the first four bytes of the double SHA256 hash of the version, program length, program, and padding.
+The length digit is followed by the witness program. The witness program is padded with leading 0b to become 265-bit, and transformed to z-base-32 with 53 digits.
+
+The 55-digit raw address is then divided into 11 equal segments. For each segment, a checksum is calculated with Damm algorithm and appended to the end of the segment. This makes the length increases to 66 digits.
+
+A second round of checksum is calculated by taking the digits in the same position of the 11 segments, and appended to the end of the address. This is the final address with 71 digits.
 
-All addresses generated with this scheme will have 64 characters, with a "B" prefix for main-network and "T" prefix for testnet.
 
 ==Rationale==
 
@@ -48,50 +78,55 @@ The segregated witness soft fork (BIP x) defines 2 ways of encoding "witness pro
 
 As the P2SH address has been defined in 2012, using witness program in P2SH allows most existing wallets to pay a segwit-compatible wallet without any upgrade. However, this method requires more block space and is less collision-resistance than a native witness program, and is only a short-term solution to make the transition smoother. Eventually, all users are expected to use the more efficient native witness program as the primary payment method.
 
-Currently there are 2 payment addresses format in Bitcoin, the original pay-to-public-key-hash addresses and the pay-to-script-hash addresses defined in 2012. All address formats, including the one defined in this BIP, are mutually incompatible. However, due to the excellent upgradability of witness programme, this proposal is likely to be the last address format encoding a scriptPubKey template.
-
 The drawbacks of Bitcoin addresses have been extensively discussed in BIP13. Since then, better payment methods have been proposed or deployed, for example:
 *BIP47 Reusable Payment Codes for Hierarchical Deterministic Wallets
 *BIP63 Stealth Addresses
 *BIP70 Payment protocol
-However, none of these are as widely adopted as the suboptimal base-58 scriptPubKey template addresses, which is still a standard for the whole eco-system, from wallets, block explorers, merchants, exchanges, to end users. The author believes this proposal as the most efficient way to promote early adoption of native witness program, which is particularly important in the context of scaling the capacity of the blockchain.
 
-Following the same rationale of BIP13, and to minimize the changes needed in wallet upgrade, this proposal resembles the original address format, including the checksum algorithm.
+However, none of these are as widely adopted as the suboptimal base-58 scriptPubKey template addresses, which is still a standard for the whole eco-system, from wallets, block explorers, merchants, exchanges, to end users. As P2PKH transactions are still dominating the blockchain, the author believes that the proposed P2PKH segwit addresses is the easiest way for wallets and services to adopt native witness program, which is particularly important in the context of scaling the capacity of the blockchain.
+
+The P2PKH segwit addresses only allow simple payment to a single public key. For arbitrarily complex segwit transactions, the general segwit address is used. The use of z-base-32 eliminates case-sensitiveness and simplifies transformation to and from hexadecimals. The Damm algorithm checksum allows detection of all single-digit errors and all adjacent transposition errors. With the excellent upgradability of witness program, this proposal is also forward compatible to new version witness programs that is not longer than 33 bytes.
 
 ==Compatibility==
 
 This proposal is not backward compatible, but it fails gracefully -- if an older implementation is given one of these new Bitcoin addresses, it will report the address as invalid and will refuse to create a transaction.
 
-This proposal is forward compatible to any new version witness program in the future.
+This proposal is forward compatible to any new version witness program with 2 to 33 bytes.
 
 ==Example==
-
+=== Address for Pay-to-Public-Key-Hash Version 0 Witness Program ===
 The following public key,
     0450863AD64A87AE8A2FE83C1AF1A8403CB53F53E486D8511DAD8A04887E5B23522CD470243453A299FA9E77237716103ABC11A1DF38855ED6F2EE187E9C582BA6
 when encoded as a P2PKH template, would become:
     DUP HASH160 <010966776006953D5567439E5E39F86A0D273BEE> EQUALVERIFY CHECKSIG
 And the corresponding version 1 Bitcoin address is
     16UwLL9Risc3QfPqBUvKofHmBQ7wMtjvM
-In the case of using the same P2PKH template as a version 0 witness program, the scriptPubKey becomes a 26-byte single push of:
-    0076A914010966776006953D5567439E5E39F86A0D273BEE88AC
-Prefixing with the address version byte 0x15 and program length 0x1A:
-    151A0076A914010966776006953D5567439E5E39F86A0D273BEE88AC
-Padding with 41 - 26 = 15 0x00:
-    151A0076A914010966776006953D5567439E5E39F86A0D273BEE88AC000000000000000000000000000000
-Perform double SHA-256 hash:
-    1B4A8136E38479EF5F08626D524534E6C94C92B1E77690B727CE8BD30BB3DAA0
-Take the first 4 bytes. This is the address checksum:
-    1B4A8136
-Add the 4 checksum bytes at the end of extended witness program. This is the 47-byte binary witness program address:
-    151A0076A914010966776006953D5567439E5E39F86A0D273BEE88AC0000000000000000000000000000001B4A8136
-Convert the result from a byte string into a base58 string with 64 characters. 
-    BAxHaPmrSLbCt4QjJkW1W7MMXZmMdJkoxFHTEQXKmL9LpMUvDMcLAGgeeuLnkvNR
+When the same script is encoded as a version 0 witness program, the scriptPubKey becomes a single push of 
+    <0x0076A914010966776006953D5567439E5E39F86A0D273BEE88AC>
+Using 0x19 as the address version, the equivalent witness program address is:
+    B4YZZ3nMBETWVF9ZSfotSwTxVnqhdkTi7r
+
+=== General witness program address ===
+With the same 26 bytes witness program in the last example:
+    0x0076A914010966776006953D5567439E5E39F86A0D273BEE88AC
+The witness program is transformed to z-base-32 with 53 digits:
+    yyyyyyyyyyyyyq4wteyejc35sybwi8iksqoh6mah9o4oprh767nfc
+Prepending with version digit b32 and length digit a32 (24 = 26 - 2)
+    bayyyyyyyyyyyyyq4wteyejc35sybwi8iksqoh6mah9o4oprh767nfc
+Split into 11 equal segments:
+    bayyy -yyyyy -yyyyy -q4wte -yejc3 -5sybw -i8iks -qoh6m -ah9o4 -oprh7 -67nfc
+Calculate the Damm checksum for each segment:
+    For example: Damm(bayyy) = h
+    bayyyh-yyyyyy-yyyyyy-q4wtey-yejc3w-5sybwu-i8iksj-qoh6mr-ah9o4h-oprh7t-67nfcs
+Calculate the Damm checksum for digits in the same position of different segments:
+    For example: Damm(byyqy5iqao6) = d
+    bayyyh-yyyyyy-yyyyyy-q4wtey-yejc3w-5sybwu-i8iksj-qoh6mr-ah9o4h-oprh7t-67nfcs-dmi1t
 
 ==Reference Implementation==
+From arbitrary witness program to general segwit address: https://gist.github.com/jl2012/760b0f952715b8b6c608
 
 ==See Also==
 
 * [[bip-0013.mediawiki|BIP 13: Address Format for pay-to-script-hash]]
 * [[bip-0016.mediawiki|BIP 16: Pay to Script Hash (aka "/P2SH/")]]
-* [[bip-xxxx.mediawiki|BIP x: Segregated Witness]]
-
+* [[bip-xxxx.mediawiki|BIP x: Segregated Witness]] https://github.com/bitcoin/bips/pull/265

From 3e3006127e7d9d6a4f172d692df5195cf740cf71 Mon Sep 17 00:00:00 2001
From: Johnson Lau 
Date: Tue, 29 Dec 2015 01:32:35 +0800
Subject: [PATCH 096/259] Clarify Backward compatibility

---
 bip-codeshark-jl2012-segwit.mediawiki | 11 +++++++----
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/bip-codeshark-jl2012-segwit.mediawiki b/bip-codeshark-jl2012-segwit.mediawiki
index 3bddf8a6..643b9d13 100644
--- a/bip-codeshark-jl2012-segwit.mediawiki
+++ b/bip-codeshark-jl2012-segwit.mediawiki
@@ -224,11 +224,14 @@ With a soft fork, it is possible to introduce a separate witness structure to al
 == Backward compatibility ==
 As a soft fork, older software will continue to operate without modification.  Non-upgraded nodes, however, will not see nor validate the witness data and will consider all witness programs as anyone-can-spend scripts (except a few edge cases in version 0 witness programs which are provably unspendable with original script semantics). Wallets should always be wary of anyone-can-spend scripts and treat them with suspicion. Non-upgraded nodes are strongly encouraged to upgrade in order to take advantage of the new features.
 
-=== Version 0 witness programs ===
-Witness programs are hashed to 256 bit "redeemscripts" which are then hashed to 160 bit P2SH. This format is fully compatible with currently existing wallets that support P2SH. Upgraded wallets will be able to send and receive to and from older wallets without any problems.
+'''What a non-upgraded wallet can do'''
+* Receiving bitcoin from non-upgraded and upgraded wallets
+* Sending bitcoin to non-upgraded wallets
+* Sending bitcoin to upgraded wallets using a P2SH address (a less efficient way to use segregated witness)
 
-=== Version 1 witness programs ===
-Witness programs are hashed to a 256 bit output. This format will not be compatible with older wallets but will require less block space and will have better security due to increased collision resistance.
+'''What a non-upgraded wallet cannot do'''
+* Validating segregated witness transaction. It assumes such a transaction is always valid
+* Sending bitcoin to upgraded wallets using a native witness program (a more efficient way to use segregated witness)
 
 == Deployment ==
 

From c2d3488c026f074fbdc2ac989de484bc5fc33456 Mon Sep 17 00:00:00 2001
From: Johnson Lau 
Date: Tue, 29 Dec 2015 15:19:25 +0800
Subject: [PATCH 097/259] Update for new witness prog design & formatting

---
 bip-segwitaddress.mediawiki | 97 +++++++++++++++++++++++--------------
 1 file changed, 61 insertions(+), 36 deletions(-)

diff --git a/bip-segwitaddress.mediawiki b/bip-segwitaddress.mediawiki
index 34ff5f3e..f92e3680 100644
--- a/bip-segwitaddress.mediawiki
+++ b/bip-segwitaddress.mediawiki
@@ -7,16 +7,18 @@
   Created: 2015-12-24
 

 
-==Abstract==
+== Abstract ==
 
 This BIP describes 2 new types of Bitcoin address to support native Segregated Witness (segwit) transactions. The first type resembles the original P2PKH base-58 address. The second type is a z-base-32 representation of a witness program with Damm algorithm checksum, which supports arbitrarily complex transactions, and is forward compatible to new version witness programs in the future.
 
-==Motivation==
+== Motivation ==
 
 To define standard payment addresses for native segwit transactions to promote early adoption of the more efficient transaction method.
 
 == Specification ==
+
 === P2PKH segwit address ===
+
 The first new Bitcoin address format defined is specific to pay-to-public-key-hash segwit transaction. The scriptPubKey is a single push of version-0 witness program in this form,
   <0x0076A914{20-byte-hash-value}88AC>
 The new address is encoded exactly in the same way as the original pay-to-public-key-hash address:
@@ -26,7 +28,8 @@ Version byte is 0x19 for a main-network address, 0x41 for a testnet address. The
 All addresses generated with this scheme will a constant length of 34 characters, with a "B" prefix for main-network and "T" prefix for testnet.
 
 === General segwit address ===
-The second new bitcoin address format defined is applicable to any version of witness program with a length of 2 to 33 bytes.
+
+The second new bitcoin address format defined is applicable to witness program of version 0 to 15 with a length of 2 to 32 bytes.
 
 The z-base-32 character set is used:
 {|class="wikitable" style="width:40ex; text-align: center; margin: 0 auto 0 auto;"
@@ -58,23 +61,34 @@ The z-base-32 character set is used:
 
 It is case-insensitive and includes all alphanumeric characters excluding 0, 2, l, v. The order of alphabet is chosen so that less ambiguous alphabet characters will appear more frequently than others.
 
-An address starts with a version digit, which is b32 for the main-network and t32 for the testnet.
+An address is a 270-bit string in z-base-32 with the following components:
 
-The next digit is a length digit, which the value is length of the witness program in byte (L) minus 2.
+  5 address version bits
+  5 length bits
+  4 witness program version bits
+  256 witness program bits
 
-The length digit is followed by the witness program. The witness program is padded with leading 0b to become 265-bit, and transformed to z-base-32 with 53 digits.
+The address version bits is 00001b for the main-network and 11001b for the testnet.
 
-The 55-digit raw address is then divided into 11 equal segments. For each segment, a checksum is calculated with Damm algorithm and appended to the end of the segment. This makes the length increases to 66 digits.
+Value of the length bits is the length of the witness program in byte minus 1.
 
-A second round of checksum is calculated by taking the digits in the same position of the 11 segments, and appended to the end of the address. This is the final address with 71 digits.
+Witness program version bits indicates version of the witness program (v0 to v15).
+
+The witness program is padded with leading 0b to 256 bits.
+
+The 270-bit string is transformed to z-base-32 with 54 digits.
+
+The 54-digit raw address is then divided into 9 equal segments. For each segment, a checksum is calculated with Damm algorithm and appended to the end of the segment. This makes the length increases to 63 digits.
+
+A second round of checksum is calculated by taking the digits in the same position of the 9 segments, and appended to the end of the address. This is the final address with 69 digits.
 
 
-==Rationale==
+== Rationale ==
 
-The segregated witness soft fork (BIP x) defines 2 ways of encoding "witness program", a data push of 2 to 41 bytes:
+The segregated witness soft fork (BIP x) defines 2 ways of encoding "witness program", a data push of 2 to 32 bytes:
 
-* A native witness program output is a scriptPubKey with a single push of a witness program, and nothing else;
-* A witness program in P2SH is a P2SH redeemScript with a single push of a witness program, while the scriptPubKey looks like a normal P2SH output.
+* A native witness program output is a scriptPubKey with a push of version byte followed by a push of witness program, and nothing else;
+* A witness program in P2SH is a P2SH redeemScript with a push of version byte followed by a push of witness program, while the scriptPubKey looks like a normal P2SH output.
 
 As the P2SH address has been defined in 2012, using witness program in P2SH allows most existing wallets to pay a segwit-compatible wallet without any upgrade. However, this method requires more block space and is less collision-resistance than a native witness program, and is only a short-term solution to make the transition smoother. Eventually, all users are expected to use the more efficient native witness program as the primary payment method.
 
@@ -85,48 +99,59 @@ The drawbacks of Bitcoin addresses have been extensively discussed in BIP13. Sin
 
 However, none of these are as widely adopted as the suboptimal base-58 scriptPubKey template addresses, which is still a standard for the whole eco-system, from wallets, block explorers, merchants, exchanges, to end users. As P2PKH transactions are still dominating the blockchain, the author believes that the proposed P2PKH segwit addresses is the easiest way for wallets and services to adopt native witness program, which is particularly important in the context of scaling the capacity of the blockchain.
 
-The P2PKH segwit addresses only allow simple payment to a single public key. For arbitrarily complex segwit transactions, the general segwit address is used. The use of z-base-32 eliminates case-sensitiveness and simplifies transformation to and from hexadecimals. The Damm algorithm checksum allows detection of all single-digit errors and all adjacent transposition errors. With the excellent upgradability of witness program, this proposal is also forward compatible to new version witness programs that is not longer than 33 bytes.
+The P2PKH segwit addresses only allow simple payment to a single public key. For arbitrarily complex segwit transactions, the general segwit address is used. The use of z-base-32 eliminates case-sensitiveness and simplifies transformation to and from hexadecimals. The Damm algorithm checksum allows detection of all single-digit errors and all adjacent transposition errors. With the excellent upgradability of witness program, this proposal is also forward compatible to new version witness programs that is not longer than 32 bytes.
 
-==Compatibility==
+== Compatibility ==
 
 This proposal is not backward compatible, but it fails gracefully -- if an older implementation is given one of these new Bitcoin addresses, it will report the address as invalid and will refuse to create a transaction.
 
-This proposal is forward compatible to any new version witness program with 2 to 33 bytes.
+This proposal is forward compatible to any new witness program format with version 2 to 15 and length of 2 to 32 bytes.
+
+== Example ==
+
+=== P2PKH segwit address ===
 
-==Example==
-=== Address for Pay-to-Public-Key-Hash Version 0 Witness Program ===
 The following public key,
     0450863AD64A87AE8A2FE83C1AF1A8403CB53F53E486D8511DAD8A04887E5B23522CD470243453A299FA9E77237716103ABC11A1DF38855ED6F2EE187E9C582BA6
 when encoded as a P2PKH template, would become:
     DUP HASH160 <010966776006953D5567439E5E39F86A0D273BEE> EQUALVERIFY CHECKSIG
 And the corresponding version 1 Bitcoin address is
     16UwLL9Risc3QfPqBUvKofHmBQ7wMtjvM
-When the same script is encoded as a version 0 witness program, the scriptPubKey becomes a single push of 
-    <0x0076A914010966776006953D5567439E5E39F86A0D273BEE88AC>
+When the same script is encoded as a version 0 witness program, the scriptPubKey becomes: 
+    OP_0 <0x76A914010966776006953D5567439E5E39F86A0D273BEE88AC>
 Using 0x19 as the address version, the equivalent witness program address is:
     B4YZZ3nMBETWVF9ZSfotSwTxVnqhdkTi7r
 
-=== General witness program address ===
-With the same 26 bytes witness program in the last example:
-    0x0076A914010966776006953D5567439E5E39F86A0D273BEE88AC
-The witness program is transformed to z-base-32 with 53 digits:
-    yyyyyyyyyyyyyq4wteyejc35sybwi8iksqoh6mah9o4oprh767nfc
-Prepending with version digit b32 and length digit a32 (24 = 26 - 2)
-    bayyyyyyyyyyyyyq4wteyejc35sybwi8iksqoh6mah9o4oprh767nfc
-Split into 11 equal segments:
-    bayyy -yyyyy -yyyyy -q4wte -yejc3 -5sybw -i8iks -qoh6m -ah9o4 -oprh7 -67nfc
-Calculate the Damm checksum for each segment:
-    For example: Damm(bayyy) = h
-    bayyyh-yyyyyy-yyyyyy-q4wtey-yejc3w-5sybwu-i8iksj-qoh6mr-ah9o4h-oprh7t-67nfcs
-Calculate the Damm checksum for digits in the same position of different segments:
-    For example: Damm(byyqy5iqao6) = d
-    bayyyh-yyyyyy-yyyyyy-q4wtey-yejc3w-5sybwu-i8iksj-qoh6mr-ah9o4h-oprh7t-67nfcs-dmi1t
+=== General segwit address ===
+
+With the same 25 bytes version 0 witness program in the last example:
+    OP_0 <0x76A914010966776006953D5567439E5E39F86A0D273BEE88AC>
+The address version bits is 00001b
+    00001b
+The lengths bits is 11000b (24 = 25 - 1)
+    00001-11000b
+The witness program version bits is 0000
+    00001-11000-0000b
+Appended by the zero-padded witness program
+    00001-11000-0000-0-00000-00000-00000-00000-00000-00000-00000-00000-00000-00000-00000-00000-11101...01100
+The 270-bit string is transformed to z-base-32 with 54 digits and split into 9 equal segments:
+    bayyyy -yyyyyy -yyq4wt -eyejc3 -5sybwi -8iksqo -h6mah9 -o4oprh -767nfc
+Calculate the Damm checksum for each segment:
+    For example: Damm(bayyyy) = 7
+    bayyyy7-yyyyyyy-yyq4wte-eyejc3q-5sybwic-8iksqoo-h6mah9w-o4oprhm-767nfc4
+Calculate the Damm checksum for digits in the same position of different segments:
+    For example: Damm(byye58ho7) = j
+    bayyyy7-yyyyyyy-yyq4wte-eyejc3q-5sybwic-8iksqoo-h6mah9w-o4oprhm-767nfc4-jwk86o
+
+== Implementation ==
 
-==Reference Implementation==
 From arbitrary witness program to general segwit address: https://gist.github.com/jl2012/760b0f952715b8b6c608
 
-==See Also==
+== References ==
 
 * [[bip-0013.mediawiki|BIP 13: Address Format for pay-to-script-hash]]
 * [[bip-0016.mediawiki|BIP 16: Pay to Script Hash (aka "/P2SH/")]]
 * [[bip-xxxx.mediawiki|BIP x: Segregated Witness]] https://github.com/bitcoin/bips/pull/265
+
+== Copyright ==
+This work is placed in the public domain.

From 66ba4e6fcf6b8752ec38b78a85c7f2120148d856 Mon Sep 17 00:00:00 2001
From: Johnson Lau 
Date: Tue, 29 Dec 2015 11:11:16 +0800
Subject: [PATCH 098/259] Separating version byte and witness program

---
 bip-codeshark-jl2012-segwit.mediawiki | 35 ++++++++++++++-------------
 1 file changed, 18 insertions(+), 17 deletions(-)

diff --git a/bip-codeshark-jl2012-segwit.mediawiki b/bip-codeshark-jl2012-segwit.mediawiki
index 643b9d13..ce85c534 100644
--- a/bip-codeshark-jl2012-segwit.mediawiki
+++ b/bip-codeshark-jl2012-segwit.mediawiki
@@ -89,20 +89,19 @@ The new rule is sv <= 1 MB.
 
 === Witness program ===
 
-* A scriptPubKey (or redeemScript as defined in BIP16/P2SH) that consists of a single push of 2 to 41 bytes gets a new special meaning. The byte vector pushed by it is called the "witness program".
-** In case the scriptPubKey pushes a witness program directly, the scriptSig must be exactly empty.
-** In case the redeemScript pushes a witness program, the scriptSig must be exactly the single push of the redeemScript.
+* A scriptPubKey (or redeemScript as defined in BIP16/P2SH) that consists of a 1-byte push opcode (for 0 to 16) followed by a data push between 2 and 32 bytes gets a new special meaning. The value of the first push is called the "version byte". The following byte vector pushed is called the "witness program".
+** In case the scriptPubKey pushes a version byte and witness program directly, the scriptSig must be exactly empty.
+** In case the redeemScript pushes a version byte and witness program, the scriptSig must be exactly the single push of the redeemScript.
 
-* The first byte of a witness program is the "version byte", an unsigned integer.
-** If the version byte is 0, the rest of the witness program is the actual script.
+** If the version byte is 0, the WP is the actual script.
 *** The script is executed after normal script evaluation but with data from the witness rather than the scriptSig.
 *** The program must not fail, and result in exactly a single TRUE on the stack.
-** If the version byte is 1, the rest of the witness program must be 32 bytes, as a SHA256 hash of the actual script.
+** If the version byte is 1, the WP must be 32 bytes, as a SHA256 hash of the actual script.
 *** The witness must consist of an input stack to feed to the program, followed by the serialized program.
 *** The serialized program is popped off the initial witness stack. Hash of the serialized program must match the hash pushed in the witness program.
 *** The serialized program is deserialized, and executed after normal script evaluation with the remaining witness stack.
 *** The script must not fail, and result in exactly a single TRUE on the stack.
-** If the witness version byte is 2 or above, no further interpretation of the witness program or witness happens.
+** If the version byte is 2 to 16, no further interpretation of the witness program or witness happens.
 
 === Other consensus critical constraints ===
 
@@ -140,9 +139,9 @@ The following example is a version 0 witness program, equivalent to the existing
 
     witness:       
     scriptSig:    (empty)
-    scriptPubKey: <0x0076A914{20-byte-hash-value}88AC>
+    scriptPubKey: OP_0 <0x76A914{20-byte-hash-value}88AC>
 
-The version byte 0x00 is removed. The rest of the witness program is deserialized and becomes:
+The OP_0 indicates the following push is a version 0 witness program. The witness program is deserialized and becomes:
 
     DUP HASH160 <20byte-hash-value> EQUALVERIFY CHECKSIG
 
@@ -158,9 +157,9 @@ The following example is an 1-of-2 multi-signature version 1 witness program.
 
     witness:      0  <0x5121{33-byte-pubkey1}21{33-byte-pubkey2}52AE>
     scriptSig:    (empty)
-    scriptPubKey: <0x01{32-byte-hash-value}>
+    scriptPubKey: OP_1 <0x{32-byte-hash-value}>
 
-The last item in the witness is popped off, hashed with SHA256, compared against the 32-byte-hash-value in scriptPubKey, and deserialized:
+The OP_1 in scriptPubKey indicates the following push is a version 1 witness program. The last item in the witness is popped off, hashed with SHA256, compared against the 32-byte-hash-value in scriptPubKey, and deserialized:
 
     1 <33-byte-pubkey1> <33-byte-pubkey2> 2 CHECKMULTISIG
 
@@ -168,7 +167,7 @@ The script is executed with the remaining data from witness:
 
     0  1 <33-byte-pubkey1> <33-byte-pubkey2> 2 CHECKMULTISIG
 
-Since the actual program is larger than 40 bytes, it cannot be accommodated in a version 0 witness program. A version 1 witness program allows arbitrarily large script as the 520-byte push limit is bypassed.
+Since the actual program is larger than 32 bytes, it cannot be accommodated in a version 0 witness program. A version 1 witness program allows arbitrarily large script as the 520-byte push limit is bypassed.
 
 The scriptPubKey occupies 34 bytes, as opposed to 23 bytes of P2SH. The increased size improves security against possible collision attacks, as 2^80 work is not infeasible anymore (By the end of 2015, 2^84 hashes have been calculated in Bitcoin mining since the creation of Bitcoin). The spending script is same as the one for an equivalent P2SH output but is moved to witness.
 
@@ -177,12 +176,12 @@ The scriptPubKey occupies 34 bytes, as opposed to 23 bytes of P2SH. The increase
 The following example is the same 1-of-2 multi-signature version 1 witness program, but nested in a P2SH output.
 
     witness:      0  <0x5121{33-byte-pubkey1}21{33-byte-pubkey2}52AE>
-    scriptSig:    <0x2101{32-byte-hash-value}>
+    scriptSig:    <0x5120{32-byte-hash-value}>
     scriptPubKey: HASH160 <20-byte-hash-value> EQUAL
 
-The only item in scriptSig is hashed with HASH160, compared against the 20-byte-hash-value in scriptPubKey, and interpreted as a single push of:
+The only item in scriptSig is hashed with HASH160, compared against the 20-byte-hash-value in scriptPubKey, and interpreted as:
 
-    <0x01{32-byte-hash-value}>
+    OP_1 <0x{32-byte-hash-value}>
 
 The version 1 witness program is then executed as described in the last example
 
@@ -210,11 +209,11 @@ In the current Bitcoin protocol, it is possible to generate compact fraud proof
 It is possible to proof the first 2 types of fraud if a block is committed to a Merkle-sum-tree of the fee, size, and sigop count of each transaction. It is also possible to proof the last type of fraud if a block is committed to a Merkle tree with the originating block height and transaction index of all inputs. These commitments could be included in the extensible witness commitment through a soft fork and will be transparent to nodes that do not understand such new rules.
 
 === New script system ===
-Since all witness programs begin with a version byte, and programs with unknown versions are always considered as anyone-can-spend script, it is possible to introduce any new script system with a soft fork. The witness as a structure is not restricted by any existing script semantics and constraints, the 520-byte push limit in particular, and therefore allows arbitrarily large scripts and signatures.
+Since a version byte is pushed before a witness program, and programs with unknown versions are always considered as anyone-can-spend script, it is possible to introduce any new script system with a soft fork. The witness as a structure is not restricted by any existing script semantics and constraints, the 520-byte push limit in particular, and therefore allows arbitrarily large scripts and signatures.
 
 Examples of new script system include Schnorr signatures which reduce the size of multisig transactions dramatically, Lamport signature which is quantum computing resistance, and Merklized abstract syntax trees which allow very compact witness for conditional scripts with extreme complexity.
 
-The 41-byte limitation for witness programme could be easily extended through a soft fork in case a stronger hash function is needed in the future. The version byte is also expandable by introducing a secondary version byte for some specific primary version values.
+The 32-byte limitation for witness program could be easily extended through a soft fork in case a stronger hash function is needed in the future. The version byte is also expandable through a softfork.
 
 === Per-input lock-time and relative-lock-time ===
 Currently there is only one nLockTime field in a transaction and all inputs must share the same value. BIP68 enables per-input relative-lock-time using the nSequence field, however, with a limited lock-time period and resolution.
@@ -225,11 +224,13 @@ With a soft fork, it is possible to introduce a separate witness structure to al
 As a soft fork, older software will continue to operate without modification.  Non-upgraded nodes, however, will not see nor validate the witness data and will consider all witness programs as anyone-can-spend scripts (except a few edge cases in version 0 witness programs which are provably unspendable with original script semantics). Wallets should always be wary of anyone-can-spend scripts and treat them with suspicion. Non-upgraded nodes are strongly encouraged to upgrade in order to take advantage of the new features.
 
 '''What a non-upgraded wallet can do'''
+
 * Receiving bitcoin from non-upgraded and upgraded wallets
 * Sending bitcoin to non-upgraded wallets
 * Sending bitcoin to upgraded wallets using a P2SH address (a less efficient way to use segregated witness)
 
 '''What a non-upgraded wallet cannot do'''
+
 * Validating segregated witness transaction. It assumes such a transaction is always valid
 * Sending bitcoin to upgraded wallets using a native witness program (a more efficient way to use segregated witness)
 

From e36fba6978b72c4541a7288570ed623cf945294e Mon Sep 17 00:00:00 2001
From: Chris Priest 
Date: Wed, 30 Dec 2015 15:51:11 -0800
Subject: [PATCH 099/259] added coalesce bip to new branch

---
 bip-coalesc-wildcard.mediawiki => bip-coalesce-wildcard.mediawiki | 0
 1 file changed, 0 insertions(+), 0 deletions(-)
 rename bip-coalesc-wildcard.mediawiki => bip-coalesce-wildcard.mediawiki (100%)

diff --git a/bip-coalesc-wildcard.mediawiki b/bip-coalesce-wildcard.mediawiki
similarity index 100%
rename from bip-coalesc-wildcard.mediawiki
rename to bip-coalesce-wildcard.mediawiki

From 3a41325f81e50c4d90cc04c5dec4c6f8b9ac6233 Mon Sep 17 00:00:00 2001
From: Chris Priest 
Date: Wed, 30 Dec 2015 15:54:33 -0800
Subject: [PATCH 100/259] removed old bip

---
 bip-0122.mediawiki | 47 ----------------------------------------------
 1 file changed, 47 deletions(-)
 delete mode 100644 bip-0122.mediawiki

diff --git a/bip-0122.mediawiki b/bip-0122.mediawiki
deleted file mode 100644
index 7dceb073..00000000
--- a/bip-0122.mediawiki
+++ /dev/null
@@ -1,47 +0,0 @@
-
-  BIP: 122
-  Title: Creation of new testnet for scaling experiments
-  Author: Chris Priest 
-  Status: Draft
-  Type: Standards Track
-  Created: 2015-10-16
-

-
-==Abstract==
-
-This BIP defines the creation of a new parallel text network called "ScaleNet",
-which will be used to test the effects of massive scale upon the bitcoin
-consensus protocol.
-
-==Motivation==
-
-Bitcoin was originally designed to be an experiment. With the increase in the market
-cap, this experimental nature is decreased. There is considerable doubt whether
-the Bitcoin consensus protocol can handle transaction rates orders of magnitude
-higher than the network sees today.
-
-==Specification==
-
-The code for ScaleNet will resemble the current Bitcoin TestNet code in every way possible.
-The only difference will be the elimination of the blocksize limit.
-
-ScaleNet coins will have 0 monetary value, just like TestNet coins.
-
-There will also be a ScaleNet faucet that will be used to automatically get free ScaleNet coins.
-
-==ScaleNet Spammer==
-
-Along with the creation of the ScaleNet client, there will also be a piece of software
-called the "ScaleNet Spammer Client". The purpose of this software is to simply send large amounts
-of transactions to the network. This software works very much like how software used to "stress test"
-the main Bitcoin network.
-
-==Lessons Hopefully Learned==
-
-* What happens when the blockchain get too large to fit entirely onto a consumer grade hard drive?
-* How will it be possible to run a full node when there are hundreds of GB of unconfirmed transactions in the mempool?
-* What kind of special attention needs to go into mining gigantic blocks (>100MB) without through the roof orphan rates?
-
-Each of these questions will be answered by ScaleNet. At some point in time
-bitcoin will need to face these problems. Hopefully the insights learned
-from ScaleNet will help drive a more data-driven approach to Bitcoin Development.

From 2f06ee5006e5fa69d52f0d7c9d60ad510101ab38 Mon Sep 17 00:00:00 2001
From: alp-bitcoin 
Date: Thu, 31 Dec 2015 15:01:27 -0600
Subject: [PATCH 101/259] Fixed typos.

---
 bip-codeshark-jl2012-segwit.mediawiki | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/bip-codeshark-jl2012-segwit.mediawiki b/bip-codeshark-jl2012-segwit.mediawiki
index 3bddf8a6..8bdade79 100644
--- a/bip-codeshark-jl2012-segwit.mediawiki
+++ b/bip-codeshark-jl2012-segwit.mediawiki
@@ -203,11 +203,11 @@ Bitcoin right now only has two real security models. A user either runs a full-n
 
 In the current Bitcoin protocol, it is possible to generate compact fraud proof for almost all rules except a few:
 
-# It is not possible to proof a miner has introduced too many Bitcoins in the coinbase transaction outputs without showing the whole block itself and all input transactions.
+# It is not possible to prove a miner has introduced too many Bitcoins in the coinbase transaction outputs without showing the whole block itself and all input transactions.
 # It is not possible to prove the violation of any block specific constraints, such as size and sigop limits, without showing the whole block (and all input transactions in the case of sigop limit)
 # It is not possible to prove the spending of a non-existing input without showing all transaction IDs in the blockchain way back to the genesis block.
 
-It is possible to proof the first 2 types of fraud if a block is committed to a Merkle-sum-tree of the fee, size, and sigop count of each transaction. It is also possible to proof the last type of fraud if a block is committed to a Merkle tree with the originating block height and transaction index of all inputs. These commitments could be included in the extensible witness commitment through a soft fork and will be transparent to nodes that do not understand such new rules.
+It is possible to prove the first 2 types of fraud if a block is committed to a Merkle-sum-tree of the fee, size, and sigop count of each transaction. It is also possible to prove the last type of fraud if a block is committed to a Merkle tree with the originating block height and transaction index of all inputs. These commitments could be included in the extensible witness commitment through a soft fork and will be transparent to nodes that do not understand such new rules.
 
 === New script system ===
 Since all witness programs begin with a version byte, and programs with unknown versions are always considered as anyone-can-spend script, it is possible to introduce any new script system with a soft fork. The witness as a structure is not restricted by any existing script semantics and constraints, the 520-byte push limit in particular, and therefore allows arbitrarily large scripts and signatures.

From bada79afddc7cd70f7ad36d163aa7110964e03ee Mon Sep 17 00:00:00 2001
From: Bryan Bishop 
Date: Fri, 1 Jan 2016 11:04:23 -0600
Subject: [PATCH 102/259] BIP1: trivial formatting change

---
 bip-0001.mediawiki | 1 +
 1 file changed, 1 insertion(+)

diff --git a/bip-0001.mediawiki b/bip-0001.mediawiki
index faa80290..ad96dced 100644
--- a/bip-0001.mediawiki
+++ b/bip-0001.mediawiki
@@ -13,6 +13,7 @@ BIP stands for Bitcoin Improvement Proposal. A BIP is a design document providin
 We intend BIPs to be the primary mechanisms for proposing new features, for collecting community input on an issue, and for documenting the design decisions that have gone into Bitcoin. The BIP author is responsible for building consensus within the community and documenting dissenting opinions.
 
 Because the BIPs are maintained as text files in a versioned repository, their revision history is the historical record of the feature proposal.
+
 ==BIP Types==
 
 There are three kinds of BIP:

From c1261ac6473040ca6079fe4f9301102d0e518446 Mon Sep 17 00:00:00 2001
From: Bryan Bishop 
Date: Fri, 1 Jan 2016 11:06:47 -0600
Subject: [PATCH 103/259] BIP1: clarify "issue tracker" statement

This switches from specifying "Bitcoin issue tracker" to specifying
"Bitcoin Core issue tracker". Other issue trackers are useful for other
client development activities, although this does not seem necessary to
mention.
---
 bip-0001.mediawiki | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/bip-0001.mediawiki b/bip-0001.mediawiki
index ad96dced..9703409c 100644
--- a/bip-0001.mediawiki
+++ b/bip-0001.mediawiki
@@ -28,7 +28,7 @@ The BIP editors assign BIP numbers and change their status. Please send all BIP-
 
 Authors MUST NOT self assign numbers, but should use an alias such as "bip-johndoe-infinitebitcoins" which includes the author's name/nick and the BIP subject.
 
-The BIP process begins with a new idea for Bitcoin. It is highly recommended that a single BIP contain a single key proposal or new idea. Small enhancements or patches often don't need a BIP and can be injected into the Bitcoin development work flow with a patch submission to the Bitcoin issue tracker. The more focused the BIP, the more successful it tends to be. The BIP editor reserves the right to reject BIP proposals if they appear too unfocused or too broad. If in doubt, split your BIP into several well-focused ones.
+The BIP process begins with a new idea for Bitcoin. It is highly recommended that a single BIP contain a single key proposal or new idea. Small enhancements or patches often don't need a BIP and can be injected into the Bitcoin Core development work flow with a patch submission to the Bitcoin Core issue tracker. The more focused the BIP, the more successful it tends to be. The BIP editor reserves the right to reject BIP proposals if they appear too unfocused or too broad. If in doubt, split your BIP into several well-focused ones.
 
 Each BIP must have a champion -- someone who writes the BIP using the style and format described below, shepherds the discussions in the appropriate forums, and attempts to build community consensus around the idea. The BIP champion (a.k.a. Author) should first attempt to ascertain whether the idea is BIP-able. Posting to the [https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev bitcoin-dev] mailing list (and maybe the [https://bitcointalk.org/index.php?board=6.0 Development&Technical Discussion] forum) is the best way to go about this.
 

From ea1111226f3c66c14f22d48ce0d1fb94ce85fd1f Mon Sep 17 00:00:00 2001
From: Bryan Bishop 
Date: Fri, 1 Jan 2016 11:32:55 -0600
Subject: [PATCH 104/259] BIP1: clarify early stages of BIP championing

The previous BIP1 text was ambiguous regarding early steps for taking an
idea from concept and eventually into a BIP. The new text is intended to
make it more clear that the initial email to the bitcoin-dev mailing
list should not be a fully-formed BIP. There have been exceptions to
this in the past for ideas already widely known and implementation in
progress, but "you know it when you see it". Hopefully this will add
clarity to the BIP authoring process and work flow for new authors.
---
 bip-0001.mediawiki | 27 ++++++++++++---------------
 1 file changed, 12 insertions(+), 15 deletions(-)

diff --git a/bip-0001.mediawiki b/bip-0001.mediawiki
index 9703409c..41b3f616 100644
--- a/bip-0001.mediawiki
+++ b/bip-0001.mediawiki
@@ -24,30 +24,26 @@ There are three kinds of BIP:
 
 ==BIP Work Flow==
 
-The BIP editors assign BIP numbers and change their status. Please send all BIP-related email to the BIP editor, which is listed under [[#BIP_Editors|BIP Editors]] below. Also see [[#BIP_Editor_Responsibilities__Workflow|BIP Editor Responsibilities & Workflow]].
+The BIP process begins with a new idea for Bitcoin. Each potential BIP must have a champion -- someone who writes the BIP using the style and format described below, shepherds the discussions in the appropriate forums, and attempts to build community consensus around the idea. The BIP champion (a.k.a. Author) should first attempt to ascertain whether the idea is BIP-able. Posting to the [https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev bitcoin-dev@lists.linuxfoundation.org] mailing list (and maybe the [https://bitcointalk.org/index.php?board=6.0 Development & Technical Discussion] forum) is the best way to go about this.
 
-Authors MUST NOT self assign numbers, but should use an alias such as "bip-johndoe-infinitebitcoins" which includes the author's name/nick and the BIP subject.
+Vetting an idea publicly before going as far as writing a BIP is meant to both save the potential author and the wider community time. Many ideas have been brought forward for changing Bitcoin that have been rejected for various reasons. Asking the Bitcoin community first if an idea is original helps prevent too much time being spent on something that is guaranteed to be rejected based on prior discussions (searching the internet does not always do the trick). It also helps to make sure the idea is applicable to the entire community and not just the author. Just because an idea sounds good to the author does not mean it will work for most people in most areas where Bitcoin is used. Small enhancements or patches often don't need a BIP and can be injected into the Bitcoin Core development work flow with a patch submission to the Bitcoin Core issue tracker.
 
-The BIP process begins with a new idea for Bitcoin. It is highly recommended that a single BIP contain a single key proposal or new idea. Small enhancements or patches often don't need a BIP and can be injected into the Bitcoin Core development work flow with a patch submission to the Bitcoin Core issue tracker. The more focused the BIP, the more successful it tends to be. The BIP editor reserves the right to reject BIP proposals if they appear too unfocused or too broad. If in doubt, split your BIP into several well-focused ones.
+Once the champion has asked the Bitcoin community as to whether an idea has any chance of acceptance, a draft BIP should be presented to the [https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev bitcoin-dev] mailing list. This gives the author a chance to flesh out the draft BIP to make it properly formatted, of high quality, and to address additional concerns about the proposal. Following a discussion, the proposal should be sent to the bitcoin-dev list and the BIP editor with the draft BIP. This draft must be written in BIP style as described below, else it will be sent back without further regard until proper formatting rules are followed.
 
-Each BIP must have a champion -- someone who writes the BIP using the style and format described below, shepherds the discussions in the appropriate forums, and attempts to build community consensus around the idea. The BIP champion (a.k.a. Author) should first attempt to ascertain whether the idea is BIP-able. Posting to the [https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev bitcoin-dev] mailing list (and maybe the [https://bitcointalk.org/index.php?board=6.0 Development&Technical Discussion] forum) is the best way to go about this.
+BIP authors are responsible for collecting community feedback on both the initial idea and the BIP before submitting it for review. However, wherever possible, long open-ended discussions on public mailing lists should be avoided. Strategies to keep the discussions efficient include: setting up a separate SIG mailing list for the topic, having the BIP author accept private comments in the early design phases, setting up a wiki page or git repository, etc. BIP authors should use their discretion here.
 
-Vetting an idea publicly before going as far as writing a BIP is meant to save the potential author time. Many ideas have been brought forward for changing Bitcoin that have been rejected for various reasons. Asking the Bitcoin community first if an idea is original helps prevent too much time being spent on something that is guaranteed to be rejected based on prior discussions (searching the internet does not always do the trick). It also helps to make sure the idea is applicable to the entire community and not just the author. Just because an idea sounds good to the author does not mean it will work for most people in most areas where Bitcoin is used.
+It is highly recommended that a single BIP contain a single key proposal or new idea. The more focused the BIP, the more successful it tends to be. Small enhancements or patches often don't need a BIP and can be injected into the Bitcoin Core development work flow with a patch submission to the Bitcoin Core issue tracker. If in doubt, split your BIP into several well-focused ones.
 
-Once the champion has asked the Bitcoin community as to whether an idea has any chance of acceptance, a draft BIP should be presented to [https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev bitcoin-dev@lists.linuxfoundation.org]. This gives the author a chance to flesh out the draft BIP to make properly formatted, of high quality, and to address initial concerns about the proposal.
+The BIP editors assign BIP numbers and change their status. Please send all BIP-related email to the BIP editor, which is listed under [[#BIP_Editors|BIP Editors]] below. Also see [[#BIP_Editor_Responsibilities__Workflow|BIP Editor Responsibilities & Workflow]]. The BIP editor reserves the right to reject BIP proposals if they appear too unfocused or too broad.
 
-Following a discussion, the proposal should be sent to the Bitcoin-dev list and the BIP editor with the draft BIP. This draft must be written in BIP style as described below, else it will be sent back without further regard until proper formatting rules are followed.
+Authors MUST NOT self assign BIP numbers, but should use an alias such as "bip-johndoe-infinitebitcoins" which includes the author's name/nick and the BIP subject.
 
-If the BIP editor approves, he will assign the BIP a number, label it as Standards Track, Informational, or Process, give it status "Draft", and add it to the git repository. The BIP editor will not unreasonably deny a BIP. Reasons for denying BIP status include duplication of effort, being technically unsound, not providing proper motivation or addressing backwards compatibility, or not in keeping with the Bitcoin philosophy.
+If the BIP editor approves, he will assign the BIP a number, label it as Standards Track, Informational, or Process, give it status "Draft", and add it to the BIPs git repository. The BIP editor will not unreasonably deny a BIP. Reasons for denying BIP status include duplication of effort, disregard for formatting rules, being too unfocused or too broad, being technically unsound, not providing proper motivation or addressing backwards compatibility, or not in keeping with the Bitcoin philosophy. For a BIP to be accepted it must meet certain minimum criteria. It must be a clear and complete description of the proposed enhancement. The enhancement must represent a net improvement. The proposed implementation, if applicable, must be solid and must not complicate the protocol unduly.
 
 The BIP author may update the Draft as necessary in the git repository. Updates to drafts may also be submitted by the author as pull requests.
 
 Standards Track BIPs consist of two parts, a design document and a reference implementation. The BIP should be reviewed and accepted before a reference implementation is begun, unless a reference implementation will aid people in studying the BIP. Standards Track BIPs must include an implementation -- in the form of code, a patch, or a URL to same -- before it can be considered Final.
 
-BIP authors are responsible for collecting community feedback on a BIP before submitting it for review. However, wherever possible, long open-ended discussions on public mailing lists should be avoided. Strategies to keep the discussions efficient include: setting up a separate SIG mailing list for the topic, having the BIP author accept private comments in the early design phases, setting up a wiki page or git repository, etc. BIP authors should use their discretion here.
-
-For a BIP to be accepted it must meet certain minimum criteria. It must be a clear and complete description of the proposed enhancement. The enhancement must represent a net improvement. The proposed implementation, if applicable, must be solid and must not complicate the protocol unduly.
-
 Once a BIP has been accepted, the reference implementation must be completed. When the reference implementation is complete and accepted by the community, the status will be changed to "Final".
 
 A BIP can also be assigned status "Deferred". The BIP author or editor can assign the BIP this status when no progress is being made on the BIP. Once a BIP is deferred, the BIP editor can re-assign it to draft status.
@@ -168,11 +164,11 @@ The BIP editor will:
 
 * List the BIP in [[README.mediawiki]]
 
-* Send email back to the BIP author with next steps (post to bitcoin mailing list).
+* Send email back to the BIP author with next steps (post to bitcoin-dev mailing list).
 
-Many BIPs are written and maintained by developers with write access to the Bitcoin codebase. The BIP editors monitor BIP changes, and correct any structure, grammar, spelling, or markup mistakes we see.
+Many BIPs are written and maintained by developers with write access to the Bitcoin Core codebase. The BIP editors monitor BIP changes, and correct any structure, grammar, spelling, or markup mistakes we see.
 
-The editors don't pass judgement on BIPs. We merely do the administrative & editorial part. Except for times like this, there's relatively low volume.
+The BIP editors are intended to fulfill administrative and editorial responsibilities.
 
 ==History==
 
@@ -181,3 +177,4 @@ This document was derived heavily from Python's PEP-0001. In many places text wa
 ==Changelog==
 
 10 Oct 2015 - Added clarifications about sumission process and BIP number assignment.
+01 Jan 2016 - Clarified early stages of BIP idea championing, collecting community feedback, etc.

From e1628bb408f89769a99636c06ce9f440b8a2fda9 Mon Sep 17 00:00:00 2001
From: Bryan Bishop 
Date: Fri, 1 Jan 2016 11:54:17 -0600
Subject: [PATCH 105/259] BIP1: use "relevant Bitcoin issue tracker" instead

Also, remove an unnecessarily duplicated sentence.
---
 bip-0001.mediawiki | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/bip-0001.mediawiki b/bip-0001.mediawiki
index 41b3f616..6d5a8968 100644
--- a/bip-0001.mediawiki
+++ b/bip-0001.mediawiki
@@ -26,13 +26,13 @@ There are three kinds of BIP:
 
 The BIP process begins with a new idea for Bitcoin. Each potential BIP must have a champion -- someone who writes the BIP using the style and format described below, shepherds the discussions in the appropriate forums, and attempts to build community consensus around the idea. The BIP champion (a.k.a. Author) should first attempt to ascertain whether the idea is BIP-able. Posting to the [https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev bitcoin-dev@lists.linuxfoundation.org] mailing list (and maybe the [https://bitcointalk.org/index.php?board=6.0 Development & Technical Discussion] forum) is the best way to go about this.
 
-Vetting an idea publicly before going as far as writing a BIP is meant to both save the potential author and the wider community time. Many ideas have been brought forward for changing Bitcoin that have been rejected for various reasons. Asking the Bitcoin community first if an idea is original helps prevent too much time being spent on something that is guaranteed to be rejected based on prior discussions (searching the internet does not always do the trick). It also helps to make sure the idea is applicable to the entire community and not just the author. Just because an idea sounds good to the author does not mean it will work for most people in most areas where Bitcoin is used. Small enhancements or patches often don't need a BIP and can be injected into the Bitcoin Core development work flow with a patch submission to the Bitcoin Core issue tracker.
+Vetting an idea publicly before going as far as writing a BIP is meant to both save the potential author and the wider community time. Many ideas have been brought forward for changing Bitcoin that have been rejected for various reasons. Asking the Bitcoin community first if an idea is original helps prevent too much time being spent on something that is guaranteed to be rejected based on prior discussions (searching the internet does not always do the trick). It also helps to make sure the idea is applicable to the entire community and not just the author. Just because an idea sounds good to the author does not mean it will work for most people in most areas where Bitcoin is used. Small enhancements or patches often don't need a BIP and can be injected into the relevant Bitcoin development work flow with a patch submission to the relevant Bitcoin issue tracker.
 
 Once the champion has asked the Bitcoin community as to whether an idea has any chance of acceptance, a draft BIP should be presented to the [https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev bitcoin-dev] mailing list. This gives the author a chance to flesh out the draft BIP to make it properly formatted, of high quality, and to address additional concerns about the proposal. Following a discussion, the proposal should be sent to the bitcoin-dev list and the BIP editor with the draft BIP. This draft must be written in BIP style as described below, else it will be sent back without further regard until proper formatting rules are followed.
 
 BIP authors are responsible for collecting community feedback on both the initial idea and the BIP before submitting it for review. However, wherever possible, long open-ended discussions on public mailing lists should be avoided. Strategies to keep the discussions efficient include: setting up a separate SIG mailing list for the topic, having the BIP author accept private comments in the early design phases, setting up a wiki page or git repository, etc. BIP authors should use their discretion here.
 
-It is highly recommended that a single BIP contain a single key proposal or new idea. The more focused the BIP, the more successful it tends to be. Small enhancements or patches often don't need a BIP and can be injected into the Bitcoin Core development work flow with a patch submission to the Bitcoin Core issue tracker. If in doubt, split your BIP into several well-focused ones.
+It is highly recommended that a single BIP contain a single key proposal or new idea. The more focused the BIP, the more successful it tends to be. If in doubt, split your BIP into several well-focused ones.
 
 The BIP editors assign BIP numbers and change their status. Please send all BIP-related email to the BIP editor, which is listed under [[#BIP_Editors|BIP Editors]] below. Also see [[#BIP_Editor_Responsibilities__Workflow|BIP Editor Responsibilities & Workflow]]. The BIP editor reserves the right to reject BIP proposals if they appear too unfocused or too broad.
 

From 17dda103e950db9c7c1e2e3e40ba0fc38535fdc0 Mon Sep 17 00:00:00 2001
From: Bryan Bishop 
Date: Fri, 1 Jan 2016 11:57:55 -0600
Subject: [PATCH 106/259] BIP1: fix changelog formatting

---
 bip-0001.mediawiki | 1 +
 1 file changed, 1 insertion(+)

diff --git a/bip-0001.mediawiki b/bip-0001.mediawiki
index 6d5a8968..75294798 100644
--- a/bip-0001.mediawiki
+++ b/bip-0001.mediawiki
@@ -177,4 +177,5 @@ This document was derived heavily from Python's PEP-0001. In many places text wa
 ==Changelog==
 
 10 Oct 2015 - Added clarifications about sumission process and BIP number assignment.
+
 01 Jan 2016 - Clarified early stages of BIP idea championing, collecting community feedback, etc.

From d01ba11ecc1c38fabbd3aa3ae307f6b46039a783 Mon Sep 17 00:00:00 2001
From: Marco Pontello 
Date: Fri, 1 Jan 2016 22:30:07 +0100
Subject: [PATCH 107/259] Added clarification for forked chains.

---
 bip-MarcoPon-BlockchainURI.mediawiki | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/bip-MarcoPon-BlockchainURI.mediawiki b/bip-MarcoPon-BlockchainURI.mediawiki
index 2380f80c..5c0881fa 100644
--- a/bip-MarcoPon-BlockchainURI.mediawiki
+++ b/bip-MarcoPon-BlockchainURI.mediawiki
@@ -27,7 +27,7 @@ The URI follow this simple form:
 Where:
 
 ;chain:
-: (optional) to uniquely point to a specific chain, the hash of the corresponding genesis block is used (leading zeros included). In principle some kind of alias/mnemonic could also be used, but that is out of the scope of this BIP, and maybe could be developed in another subsequent one. If omitted (which would be the usual case), Bitcoin's mainnet is assumed. As a reference, see for example this code fragment from Bitcoin chainparams.cpp source:
+: (optional) to uniquely point to a specific chain, the hash of the corresponding genesis block is used (leading zeros included). For forked chains, the hash of the relevant first block after fork is used. In principle some kind of alias/mnemonic could also be used, but that is out of the scope of this BIP, and maybe could be developed in another subsequent one. If omitted (which would be the usual case), Bitcoin's mainnet is assumed. As a reference, see for example this code fragment from Bitcoin chainparams.cpp source:
   const std::map CChainParams::supportedChains =
       boost::assign::map_list_of
       ( "main", uint256S("0x000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f"))

From 66224130f03ffb94daae9692d1b8d25b1c35e6ba Mon Sep 17 00:00:00 2001
From: Bryan Bishop 
Date: Fri, 1 Jan 2016 15:37:47 -0600
Subject: [PATCH 108/259] BIP1: remove line about committers

https://github.com/bitcoin/bips/pull/269#issuecomment-168335009
---
 bip-0001.mediawiki | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/bip-0001.mediawiki b/bip-0001.mediawiki
index 75294798..8512b76c 100644
--- a/bip-0001.mediawiki
+++ b/bip-0001.mediawiki
@@ -166,9 +166,7 @@ The BIP editor will:
 
 * Send email back to the BIP author with next steps (post to bitcoin-dev mailing list).
 
-Many BIPs are written and maintained by developers with write access to the Bitcoin Core codebase. The BIP editors monitor BIP changes, and correct any structure, grammar, spelling, or markup mistakes we see.
-
-The BIP editors are intended to fulfill administrative and editorial responsibilities.
+The BIP editors are intended to fulfill administrative and editorial responsibilities. The BIP editors monitor BIP changes, and correct any structure, grammar, spelling, or markup mistakes we see.
 
 ==History==
 

From 6a08c9c76affe5608326d9b7f0d06d18dea6a6c4 Mon Sep 17 00:00:00 2001
From: Marco Pontello 
Date: Sat, 2 Jan 2016 02:53:41 +0100
Subject: [PATCH 109/259] Removed specific wallet examples.

---
 bip-MarcoPon-BlockchainURI.mediawiki | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/bip-MarcoPon-BlockchainURI.mediawiki b/bip-MarcoPon-BlockchainURI.mediawiki
index 5c0881fa..a60d2f2a 100644
--- a/bip-MarcoPon-BlockchainURI.mediawiki
+++ b/bip-MarcoPon-BlockchainURI.mediawiki
@@ -14,7 +14,7 @@ This BIP propose an URI scheme for looking up blocks, transactions, addresses on
 ==Motivation==
 
 The purpose of this URI scheme is to enable users to handle all the requests for details about blocks, transactions, etc. with their preferred tool (being that a web service or a local application).
-Currently a Bitcoin client usually points to an arbitrary blockchain explorer when the user looks for the details of a transaction (es. Bitcoin Wallet uses BitEasy, Mycelium or Electrum uses Blockchain.info, etc.).
+Currently a Bitcoin client usually points to an arbitrary blockchain explorer when the user looks for the details of a transaction, or let him choose from a limited list of possible alternatives.
 Other times resorting to cut&paste is needed.
 The same happens with posts and messages that reference some particular txs or blocks, if they provide links at all.
 

From d4130aa650191ca7963dc94f6b59798ec356eeb9 Mon Sep 17 00:00:00 2001
From: Marco Pontello 
Date: Sat, 2 Jan 2016 13:59:32 +0100
Subject: [PATCH 110/259] Added Post-History.

---
 bip-MarcoPon-BlockchainURI.mediawiki | 1 +
 1 file changed, 1 insertion(+)

diff --git a/bip-MarcoPon-BlockchainURI.mediawiki b/bip-MarcoPon-BlockchainURI.mediawiki
index a60d2f2a..8da74dbc 100644
--- a/bip-MarcoPon-BlockchainURI.mediawiki
+++ b/bip-MarcoPon-BlockchainURI.mediawiki
@@ -5,6 +5,7 @@
   Status: Draft
   Type: Standards Track
   Created: 29 August 2015
+  Post-History: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/010712.html
 

 
 ==Abstract==

From f03c7bb90ac854f711eaf03574cc210051164299 Mon Sep 17 00:00:00 2001
From: Marco Pontello 
Date: Tue, 5 Jan 2016 02:58:30 +0100
Subject: [PATCH 111/259] Reworked layout, clarified chain ID.

---
 bip-MarcoPon-BlockchainURI.mediawiki   |  69 +++++++++++++++++--------
 bip-MarcoPon-BlockchainURI/chainid.png | Bin 0 -> 2967 bytes
 2 files changed, 48 insertions(+), 21 deletions(-)
 create mode 100644 bip-MarcoPon-BlockchainURI/chainid.png

diff --git a/bip-MarcoPon-BlockchainURI.mediawiki b/bip-MarcoPon-BlockchainURI.mediawiki
index 8da74dbc..1897326b 100644
--- a/bip-MarcoPon-BlockchainURI.mediawiki
+++ b/bip-MarcoPon-BlockchainURI.mediawiki
@@ -21,45 +21,73 @@ The same happens with posts and messages that reference some particular txs or b
 
 ==Specification==
 
-The URI follow this simple form:
+The URI follow this form:
 
  blockchain:[//chain]
 
 Where:
 
-;chain:
-: (optional) to uniquely point to a specific chain, the hash of the corresponding genesis block is used (leading zeros included). For forked chains, the hash of the relevant first block after fork is used. In principle some kind of alias/mnemonic could also be used, but that is out of the scope of this BIP, and maybe could be developed in another subsequent one. If omitted (which would be the usual case), Bitcoin's mainnet is assumed. As a reference, see for example this code fragment from Bitcoin chainparams.cpp source:
-  const std::map CChainParams::supportedChains =
-      boost::assign::map_list_of
-      ( "main", uint256S("0x000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f"))
-      ( "test", uint256S("0x000000000933ea01ad0ee984209779baaec3ced90fa3f408719526f8d77f4943"))
-      ( "regtest", uint256S("0x0f9188f13cb7b2c71f2a335e3a4fc328bf5beb436012afca590b1a11466e2206"))
-      ;
+{| class="wikitable"
+! style="text-align: center;" | Element
+! colspan="2" style="text-align: center;" | Description
+! 
+|-
+| chain
+| colspan="2" | '''chain ID''' (see below) of the desired chain, leading 0s included. If omitted (which would be the usual case), Bitcoin main net is assumed.
+| optional
+|-
+| rowspan="3" | type
+| tx
+| for transactions.
+| rowspan="3" | 
+|-
+| block
+| for blocks (supports both hash or height).
+|-
+| address
+| for addresses.
+|-
+| hash
+| colspan="2" | the relevant hash to refer to (leading zeros included), or block height.
+| 
+|}
 
+----
+===Definition of chain ID===
 
+The '''chain ID''' of a chain is the block hash of the corresponding genesis block. For forked chains, it's the block hash of the first block after fork.
 
-;type: 
-: '''tx''': for transactions.
-: '''block''': for blocks (supports both hash or height).
-: '''address''': for addresses.
+So, for example:
+
+Bitcoin main   : 000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f 
+Bitcoin test   : 000000000933ea01ad0ee984209779baaec3ced90fa3f408719526f8d77f4943
+Bitcoin regtest: 0f9188f13cb7b2c71f2a335e3a4fc328bf5beb436012afca590b1a11466e2206 
+

+
+An example of forked chain (Feathercoin, that forked Litecoin):
+
+
+
+
+Litecoin   : 12a765e31ffd4059bada1e25190f6e98c99d9714d334efa41a195a7e7e04bfe2
+Feathercoin: fdbe99b90c90bae7505796461471d89ae8388ab953997aa06a355bbda8d915cb
+
  
 
-;hash: 
-: the relevant hash to refer to (leading zeros included), or block height.
 
 ==Examples==
 
-A transaction on Bitcoin's mainnet:
+A transaction on Bitcoin main net:
  blockchain:/tx/b462ae6eb8bdae2e060239a2a3ea5d9c3e0f9ef34d9717beb2dcf0ed42cee7da
 
-A block on Bitcoin's mainnet:
+A block on Bitcoin main net:
  blockchain:/block/00000000000000000119af5bcae2926df54ae262e9071a94a99c913cc217cc72
 or
  blockchain:/block/372338
 
-An address on Bitcoin's mainnet:
+An address on Bitcoin main net:
  blockchain:/address/16EW6Rv9P9AxFDBrZV816dD4sj1EAYUX3f
 
-A transaction on Bitcoin's testnet:
+A transaction on Bitcoin test net:
  blockchain://000000000933ea01ad0ee984209779baaec3ced90fa3f408719526f8d77f4943/tx/3b95a766d7a99b87188d6875c8484cb2b310b78459b7816d4dfc3f0f7e04281a
 
 ==Rationale==
@@ -77,5 +105,4 @@ Thanks to Richard Moore, Matt Whitlock, Andreas Schildbach for suggestions about
 
 ==Copyright==
 
-This document is placed in the public domain.
-
+This document is placed in the public domain.
\ No newline at end of file
diff --git a/bip-MarcoPon-BlockchainURI/chainid.png b/bip-MarcoPon-BlockchainURI/chainid.png
new file mode 100644
index 0000000000000000000000000000000000000000..ab6957ab2d059832433c70f106edaefa7aaf6ec1
GIT binary patch
literal 2967
zcmai$dpwhE1IO2aC(U$LjmTk%lA<}2Gus@t5lJQ{Y)(alAv_@u>T%pdj+xnVC}eU<
z<&b75&AF(@>ukixu$-pU_51v;>%RZ^-oH4cr737HcrO3|0Kv?R
z&;Yd|6Pdoh4rUrnrPVp(e*zK-wp$`C*KLm1}1^8O%rkTAz03gz|
zb?tcTOK}ANfM;Pw`Zhs>tZZKohrZ*jN~(v2qu=ja|MKkh`NP3e=~bvtOrK{3&lp0a
zz(I4%Yu!Bv7MXl*smWyMMsWkw0rw^=imEo)jf78|?Eh-e&>177`3&)zWO?&mN*QA@
z!N%I*w8s-^`ws&eD=+)H(_Ck!yBg4>iPxO*EE&IC!tjXB=5TZRvE5?|LXLn)@E)dK
zp5RXCeoEv?+@X{?yP%@_S-k)GohVZu()?R_1TJZi4iwV~cx{fSElKak3)x(Ns`$naU-8U{*UC)@
zxoUS!4m&(IKb)pD0hio-KWF?=x+?9csPm{By0Y--xs{I}6fk|vdImveR`Yc{&A1Op
zH`7)VTF=T*(Nn0qHGDIdN(q06Kb!G1*x|9si
z<1?79D;2uu-#y6y2L>weviF9Cq9mdTtF>fkK
z(o@(%iQ4!YCFvLBt@ICHv61d0^stR#otBG)=+@vGZT1sR^OXkX#a!Qc^<>HVn@R#5
z$d+Yg6O>9|j2|hoKxSM6b?8$aWAnvrO&g4RUfeISMCpj_$NoAWwb7ythWkX6i~**m
z4FAV&WlxP}f@T`llW!wygx_giGMWz2!>hI+c*x{V_p_<3?eEF0OBaQ@La^b)1n3G4
zLUr8OXrk%of7MS8i?vSzn|I%AHNe#i`{2#3Qoeb$T`6GPDkg-Eoi_x5Tw;`+W9Y}&
z*H(}i(MheMrkXZ!&lK9I3j$gFYGX*MYN2sPSqUQ8D34(I7ObLEZU}@_Qd{S`vh0g$
zgFRX7d>ce-Nz7P+rcUWN4Zq^?=}8*o8pu5%SQX#=9hr&VjCtW-RK^BF{IhbN^M-Ju
zvy0_ZhEm@%&rpZim1A1&!|m~zC3T-YR;2xTQdqa_>0S|~ar4YlwVR+;FkK~c`
zJ65$07~Eo~7J-qdA!h0Nz_|PSycVRr(N$e!cRwTITBB|rX+H-R?Wn&FcamUEs@t=#
za=ki5ZB=IcFd1i2pA*b*;(JIA3TyICkDWLl$)9Yeat>F+3u}r(qjNzMFbipaMhcDF
z<3bz^#zQtt!_ncZ=JPtNcCH@B!*N1+wCFKo;Edh_-kQr+d`nR^vBD9)6`d{q(h-PD
z_e)5Xi48wsRotK$@UU0$GT1cn!tv;OQ?Kb0P+Yr{@-HRJHBEN?2|
zxla$g$*$>!abogwUYD8GuX%3VBN)z1n@P;0Mi085)rQ?cC!V&)9;gK2e(-~sNfspY
z2x3}H2Rjh{Ro|%=(nLY!*!nw6OO!f1DLIEvC6yB9IgO29n4eZbPRrb3`?2}W#u0O`s(SG~smtAw6`|B2h+Wsgf%e~T$jY_q*Tco?<3Vh^sd8a;JRsJ0u
z^5fO06;CMnB-UogJnj*O0f5Vr*uub=$21?|X>7UzdG5@6N
zPsb0`^CK9Af|pJJwxY2j(AJTomzMYZz0dzVB|nQa{ZGylvkS(NDLn`-FDA3oSKnfa
zIxy<)Rjct#1G?~V+Qj_vsYk@Fx?dL%a@aibS<2TDBiHfL#YbEiPsZl}mD5JzG*422
z+gy%BA^^-(fi0A`l~gfWvaL*XO3##~T<~4FGp`W&+p}9L)PZgwaeeAEMLs^jqN80~
z*||>$^IWkOgLI27cV1Q@qY9c3q;-W}=-7qcpq0C=GLSF#m+Ow0)F)0@Mt6`;)e)B?
zVYB(dd96vNr2YZw(u&s7LW==azLw~q6n1^7a|o5j?1$9J^qGZy+^BL>yfAcpe5_67
zi~!o&OX;;p(boy6e9j^3BG>g4&N**(f&G%tMlN98XRwD`u$JZ7-j7vSggK*5{2&NaDG@UXZqKnPHh>1~!l8azLmgd6!Vd0Ugs4PKBrxZ-F)E&!Z@f
zGk+wX&Z_R!l|(Dy#V&)Zz#=rdRMMfDt)KTmVtRWhW^#x^LQmN>h3*@>5&6w6W|$Q|z_sn|K(-wB%_K#`*Mb+><-QJ
zX^6jmyYpXeVb@Wi5eifz@9~_)F>+lJSf_}?OqI9Fylv>Q;1d{WInkE*64~CT_Z?UmSvCEk54D{)s*>SMH*x4?BI^C;_^ix0yJKu_
zR2Nc;w$UCPw?pEETxjuIE~BQyf`1nD0k>%L+`8LIF?aPlUI6|jrB<_`UHitC@WuuP
z!K;Krh4IQrnJA+fFzTS`azLnRg;(RZyocwQWLvO7NB7e=Fy{Mbk87P5PnxFL!124F
zh2oylrlO~Y%}VaGq-v24=o<@EnBGasEjCrIA8h95U-#~ZlWbkt>$lu_-l>oKMUoLL
zJ4*<9P_s`^yA-i7rFPtr|HTD6kYZwo^)23Sl?DljnvZU8FeU*7Nuz+6srSHv9ko0i
zUBdugSy@V#ZeIy{NE>UNzTRon6F*2!<#ZdY@
Date: Tue, 5 Jan 2016 02:59:59 +0100
Subject: [PATCH 112/259] Fixed img link.

---
 bip-MarcoPon-BlockchainURI.mediawiki | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/bip-MarcoPon-BlockchainURI.mediawiki b/bip-MarcoPon-BlockchainURI.mediawiki
index 1897326b..372c0ef2 100644
--- a/bip-MarcoPon-BlockchainURI.mediawiki
+++ b/bip-MarcoPon-BlockchainURI.mediawiki
@@ -66,7 +66,7 @@ Bitcoin regtest: 0f9188f13cb7b2c71f2a335e3a4fc328bf5beb436012afca590b1a11466e220
 
 An example of forked chain (Feathercoin, that forked Litecoin):
 
-
+
 
 
 Litecoin   : 12a765e31ffd4059bada1e25190f6e98c99d9714d334efa41a195a7e7e04bfe2

From fd55dd92e60b1d664da63e2e01b58bab174090c4 Mon Sep 17 00:00:00 2001
From: Johnson Lau 
Date: Thu, 31 Dec 2015 21:59:10 +0800
Subject: [PATCH 113/259] Create bip-segwit-checksig.mediawiki

---
 bip-segwit-checksig.mediawiki | 132 ++++++++++++++++++++++++++++++++++
 1 file changed, 132 insertions(+)
 create mode 100644 bip-segwit-checksig.mediawiki

diff --git a/bip-segwit-checksig.mediawiki b/bip-segwit-checksig.mediawiki
new file mode 100644
index 00000000..d4075b2e
--- /dev/null
+++ b/bip-segwit-checksig.mediawiki
@@ -0,0 +1,132 @@
+
+  BIP: x
+  Title: Transaction signature verification for version 0 and version 1 witness program
+  Author: Johnson Lau 
+          Pieter Wuille 
+  Status: Draft
+  Type: Standards Track
+  Created: 2016-01-03
+

+
+== Abstract ==
+This proposal defines a new transaction digest algorithm for signature verification in version 0 and version 1 witness program, in order to minimize redundant data hashing in verification, and to cover the input value by the signature.
+
+== Motivation ==
+There are 4 ECDSA signature verification codes in the original Bitcoin script system: CHECKSIG, CHECKSIGVERIFY, CHECKMULTISIG, CHECKMULTISIGVERIFY (“sigops”). According to the sighash type (ALL, NONE, SINGLE, ANYONECANPAY), a transaction digest is generated with a double SHA256 of a serialized subset of the transaction, and the signature is verified against this digest with a given public key. The detailed procedure is described in a Bitcoin Wiki article. [https://en.bitcoin.it/wiki/OP_CHECKSIG]
+
+Unfortunately, there are at least 2 weaknesses in the original transaction digest algorithm:
+
+* For the verification of each signature, the amount of data hashing is proportional to the size of the transaction. Therefore, data hashing grows in O(n2) as the number of sigops in a transaction increases. While a 1 MB block would normally take 2 seconds to verify with an average computer in 2015, a 1MB transaction with 5569 sigops may take 25 seconds to verify. This could be fixed by optimizing the digest algorithm by introducing some reusable “midstate”, so the time complexity becomes O(n). [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2013-2292 CVE-2013-2292][https://bitcointalk.org/?topic=140078 New Bitcoin vulnerability: A transaction that takes at least 3 minutes to verify][http://rusty.ozlabs.org/?p=522 The Megatransaction: Why Does It Take 25 Seconds?]
+* The algorithm does not involve the amount of Bitcoin being spent by the input. This is usually not a problem for online network nodes as they could request for the specified transaction to acquire the output value. For an offline transaction signing device ("cold wallet"), however, the unknowing of input amount makes it impossible to calculate the exact amount being spent and the transaction fee. To cope with this problem a cold wallet must also acquire the full transaction being spent, which could be a big obstacle in the implementation of lightweight, air-gapped wallet. By including the input value of part of the transaction digest, a cold wallet may safely sign a transaction by learning the value from an untrusted source. In the case that a wrong value is provided and signed, the signature would be invalid and no funding might be lost. [https://bitcointalk.org/index.php?topic=181734.0 SIGHASH_WITHINPUTVALUE: Super-lightweight HW wallets and offline data]
+
+Deploying the aforementioned fixes in the original script system is not a simple task. That would be either a hardfork, or a softfork for new sigops without the ability to remove or insert stack items. However, the introduction of segregated witness softfork offers an opportunity to define a different set of script semantics without disrupting the original system, as the unupgraded nodes would always consider such a transaction output is spendable by arbitrary signature or no signature at all. [https://github.com/CodeShark/bips/blob/segwit/bip-codeshark-jl2012-segwit.mediawiki BIPx: Segregated Witness (Consensus layer)]
+
+== Specification ==
+A new transaction digest algorithm is defined, but only applicable to sigops in version 0 and version 1 witness program:
+  Double SHA256 of the serialization of:
+     1. nVersion of the transaction
+     2. hashPrevouts
+     3. hashSequence
+     4. transaction id and output index of the output spent by this input
+     5. subscript of the input
+     6. value of the output spent by this input
+     7. nSequence of the input
+     8. hashOutputs
+     9. nLocktime of the transaction
+    10. sighash type of the signature
+
+The items 1, 4, 5, 7, 9, 10 have the same meaning as the original algorithm. 
+
+The item 6 is a 8-byte value of the amount of bitcoin spent in this input.
+
+hashPrevouts:
+*If the ANYONECANPAY flag is not set, hashPrevouts is the double SHA256 of the serialization of all transaction ids and output indexes involved in this transaction;
+*Otherwise, hashPrevouts is a uint256 of 0x0000......0000.
+
+hashSequence:
+*If none of the ANYONECANPAY, SINGLE, NONE sighash type is set, hashSequence is the double SHA256 of the serialization of nSequence of all inputs;
+*Otherwise, hashSequence is a uint256 of 0x0000......0000.
+
+hashOutputs:
+*If the sighash type is neither SINGLE nor NONE, hashOutputs is the double SHA256 of the serialization of all output scriptPubKey with value;
+*If sighash type is SINGLE and the input index is not greater than the number of outputs, hashOutputs is the double SHA256 of the output scriptPubKey with value of the same index as the input;
+*Otherwise, hashOutputs is a uint256 of 0x0000......0000.
+
+The hashPrevouts, hashSequence, and hashOutputs calculated in an earlier verification may be reused in other inputs of the same transaction, so that the time complexity of the whole hashing process reduces from O(n2) to O(n).
+
+Refer to the reference implementation, reproduced below, for the precise algorithm:
+
+  
+  uint256 hashPrevouts;
+  uint256 hashSequence;
+  uint256 hashOutputs;
+  
+  if (!(nHashType & SIGHASH_ANYONECANPAY)) {
+      CHashWriter ss(SER_GETHASH, 0);
+      for (unsigned int n = 0; n < txTo.vin.size(); n++) {
+          ss << txTo.vin[n].prevout;
+      }
+      hashPrevouts = ss.GetHash();
+  }
+  
+  if (!(nHashType & SIGHASH_ANYONECANPAY) && (nHashType & 0x1f) != SIGHASH_SINGLE && (nHashType & 0x1f) != SIGHASH_NONE) {
+      CHashWriter ss(SER_GETHASH, 0);
+      for (unsigned int n = 0; n < txTo.vin.size(); n++) {
+          ss << txTo.vin[n].nSequence;
+      }
+      hashSequence = ss.GetHash();
+  }
+  
+  if ((nHashType & 0x1f) != SIGHASH_SINGLE && (nHashType & 0x1f) != SIGHASH_NONE) {
+      CHashWriter ss(SER_GETHASH, 0);
+      for (unsigned int n = 0; n < txTo.vout.size(); n++) {
+          ss << txTo.vout[n];
+      }
+      hashOutputs = ss.GetHash();
+  } else if ((nHashType & 0x1f) == SIGHASH_SINGLE && nIn < txTo.vout.size()) {
+      CHashWriter ss(SER_GETHASH, 0);
+      ss << txTo.vout[nIn];
+      hashOutputs = ss.GetHash();
+  }
+  
+  CHashWriter ss(SER_GETHASH, 0);
+  // Version
+  ss << txTo.nVersion;
+  // Input prevouts/nSequence (none/all, depending on flags)
+  ss << hashPrevouts;
+  ss << hashSequence;
+  // The input being signed (replacing the scriptSig with scriptCode + amount)
+  // The prevout may already be contained in hashPrevout, and the nSequence
+  // may already be contain in hashSequence.
+  ss << txTo.vin[nIn].prevout;
+  ss << static_cast(scriptCode);
+  ss << amount;
+  ss << txTo.vin[nIn].nSequence;
+  // Outputs (none/one/all, depending on flags)
+  ss << hashOutputs;
+  // Locktime
+  ss << txTo.nLockTime;
+  // Sighash type
+  ss << nHashType;
+  
+  return ss.GetHash();
+
+== Deployment ==
+
+This proposal is deployed with Segregated Witness softfork (BIP x) 
+
+== Backward compatibility ==
+
+As a soft fork, older software will continue to operate without modification. Non-upgraded nodes, however, will not see nor validate the witness data and will consider all witness programs, inculding the redefined sigops, as anyone-can-spend scripts.
+
+== Reference Implementation ==
+
+https://github.com/sipa/bitcoin/commits/segwit
+
+== References ==
+
+
+
+== Copyright ==
+
+This document is placed in the public domain.

From 1c5c149220ef9b0de95b9bed380a00abf61722f1 Mon Sep 17 00:00:00 2001
From: Luke Dashjr 
Date: Wed, 6 Jan 2016 20:35:36 +0000
Subject: [PATCH 114/259] BIP 0001: Change BIP editor to Luke Dashjr

Greg asked that I take over BIP number assignments
---
 bip-0001.mediawiki | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/bip-0001.mediawiki b/bip-0001.mediawiki
index faa80290..db7a6efd 100644
--- a/bip-0001.mediawiki
+++ b/bip-0001.mediawiki
@@ -143,7 +143,7 @@ If you are interested in assuming ownership of a BIP, send a message asking to t
 
 ==BIP Editors==
 
-The current BIP editor is Gregory Maxwell who can be contacted at [[mailto:gmaxwell@gmail.com|gmaxwell@gmail.com]].
+The current BIP editor is Luke Dashjr who can be contacted at [[mailto:luke_bipeditor@dashjr.org|luke_bipeditor@dashjr.org]].
 
 ==BIP Editor Responsibilities & Workflow==
 

From 627ffecd5ac7fbc28167dad72c1c9c33170965ef Mon Sep 17 00:00:00 2001
From: MarcoFalke 
Date: Thu, 7 Jan 2016 13:41:49 +0100
Subject: [PATCH 115/259] Fix syntax error 

---
 bip-segwit-checksig.mediawiki | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/bip-segwit-checksig.mediawiki b/bip-segwit-checksig.mediawiki
index d4075b2e..dc6c3df4 100644
--- a/bip-segwit-checksig.mediawiki
+++ b/bip-segwit-checksig.mediawiki
@@ -35,7 +35,7 @@ A new transaction digest algorithm is defined, but only applicable to sigops in
      9. nLocktime of the transaction
     10. sighash type of the signature
 
-The items 1, 4, 5, 7, 9, 10 have the same meaning as the original algorithm. 
+The items 1, 4, 5, 7, 9, 10 have the same meaning as the original algorithm. 
 
 The item 6 is a 8-byte value of the amount of bitcoin spent in this input.
 
@@ -56,7 +56,7 @@ The hashPrevouts, hashSequence, and hashOutputs calculated in an earlier verific
 
 Refer to the reference implementation, reproduced below, for the precise algorithm:
 
-  
+
   uint256 hashPrevouts;
   uint256 hashSequence;
   uint256 hashOutputs;
@@ -110,6 +110,7 @@ Refer to the reference implementation, reproduced below, for the precise algorit
   ss << nHashType;
   
   return ss.GetHash();
+
 
 == Deployment ==
 

From ca6cfc2192ce3ea8622edf30bb0d06c8ae1b8a26 Mon Sep 17 00:00:00 2001
From: Luke Dashjr 
Date: Thu, 7 Jan 2016 16:16:20 +0000
Subject: [PATCH 116/259] README: Update BIP editor

---
 README.mediawiki | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/README.mediawiki b/README.mediawiki
index b45c17a0..d8c2341b 100644
--- a/README.mediawiki
+++ b/README.mediawiki
@@ -1,4 +1,4 @@
-People wishing to submit BIPs, first should propose their idea or document to the mailing list. After discussion they should email Greg Maxwell <gmaxwell@gmail.com>. After copy-editing and acceptance, it will be published here.
+People wishing to submit BIPs, first should propose their idea or document to the mailing list. After discussion they should email Luke Dashjr <luke_bipeditor@dashjr.org>. After copy-editing and acceptance, it will be published here.
 
 We are fairly liberal with approving BIPs, and try not to be too involved in decision making on behalf of the community. The exception is in very rare cases of dispute resolution when a decision is contentious and cannot be agreed upon. In those cases, the conservative option will always be preferred.
 

From 2ea077022ef36859c38c3906a24558facc5091a7 Mon Sep 17 00:00:00 2001
From: Marco Pontello 
Date: Thu, 7 Jan 2016 23:11:32 +0100
Subject: [PATCH 117/259] Added Sample implementation section

---
 bip-MarcoPon-BlockchainURI.mediawiki | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/bip-MarcoPon-BlockchainURI.mediawiki b/bip-MarcoPon-BlockchainURI.mediawiki
index 372c0ef2..2a0a659c 100644
--- a/bip-MarcoPon-BlockchainURI.mediawiki
+++ b/bip-MarcoPon-BlockchainURI.mediawiki
@@ -98,6 +98,10 @@ Blockchain explorers in turn will simply offer to handle the blockchain: URI, th
 
 Users get the convenience of using always their preferred explorer, which can be especially handy on mobile devices, where juggling with cut&paste is far from ideal.
 
+== Sample implementation ==
+
+[https://github.com/MarcoPon/blockchain-exploration Demo Blockchain: URI handler on GitHub]
+
 ==Acknowledgements==
 Thanks to Btc Drak for suggesting to provide support for different networks.
 Thanks to Jorge Timon for the idea of using genesis blocks hashes to identify them.

From fddb05618de44b2728a53e4240efd8419bab1610 Mon Sep 17 00:00:00 2001
From: Luke Dashjr 
Date: Fri, 8 Jan 2016 17:42:27 +0000
Subject: [PATCH 118/259] Assign BIP 107

---
 README.mediawiki                                 | 6 ++++++
 dynamicblocksize.mediawiki => bip-0107.mediawiki | 2 +-
 2 files changed, 7 insertions(+), 1 deletion(-)
 rename dynamicblocksize.mediawiki => bip-0107.mediawiki (99%)

diff --git a/README.mediawiki b/README.mediawiki
index 1404eb67..5ab33cbe 100644
--- a/README.mediawiki
+++ b/README.mediawiki
@@ -308,6 +308,12 @@ Those proposing changes should consider that ultimately consent may rest with th
 | Standard
 | Draft
 |-
+| [[bip-0107.mediawiki|107]]
+| Dynamic limit on the block size
+| Washington Y. Sanchez
+| Standard
+| Draft
+|-
 | [[bip-0111.mediawiki|111]]
 | NODE_BLOOM service bit
 | Matt Corallo and Peter Todd
diff --git a/dynamicblocksize.mediawiki b/bip-0107.mediawiki
similarity index 99%
rename from dynamicblocksize.mediawiki
rename to bip-0107.mediawiki
index 7431a1c1..88a2c990 100644
--- a/dynamicblocksize.mediawiki
+++ b/bip-0107.mediawiki
@@ -1,5 +1,5 @@
 
-  BIP: XXX
+  BIP: 107
   Title: Dynamic limit on the block size
   Author: Dr Washington Y. Sanchez 
   Status: Draft

From 8380abd7eb1177365a131254e0c373e09d2b5371 Mon Sep 17 00:00:00 2001
From: Luke Dashjr 
Date: Fri, 8 Jan 2016 17:45:00 +0000
Subject: [PATCH 119/259] Assign BIP 122

---
 README.mediawiki                                    |  12 ++++++------
 ...on-BlockchainURI.mediawiki => bip-0122.mediawiki |   4 ++--
 .../chainid.png                                     | Bin
 3 files changed, 8 insertions(+), 8 deletions(-)
 rename bip-MarcoPon-BlockchainURI.mediawiki => bip-0122.mediawiki (96%)
 rename {bip-MarcoPon-BlockchainURI => bip-0122}/chainid.png (100%)

diff --git a/README.mediawiki b/README.mediawiki
index 9e68b022..389a7276 100644
--- a/README.mediawiki
+++ b/README.mediawiki
@@ -362,6 +362,12 @@ Those proposing changes should consider that ultimately consent may rest with th
 | Standard
 | Draft
 |-
+| [[bip-0122.mediawiki|121]]
+| URI scheme for Blockchain references / exploration
+| Marco Pontello
+| Standard
+| Draft
+|-
 | [[bip-0123.mediawiki|123]]
 | BIP Classification
 | Eric Lombrozo
@@ -373,12 +379,6 @@ Those proposing changes should consider that ultimately consent may rest with th
 | Suhas Daftuar
 | Standard
 | Draft
-|-
-| [[bip-MarcoPon-BlockchainURI.mediawiki| xx]]
-| URI scheme for Blockchain references / exploration
-| Marco Pontello
-| Standard
-| Draft
 |}
 
 
diff --git a/bip-MarcoPon-BlockchainURI.mediawiki b/bip-0122.mediawiki
similarity index 96%
rename from bip-MarcoPon-BlockchainURI.mediawiki
rename to bip-0122.mediawiki
index 2a0a659c..902aa02a 100644
--- a/bip-MarcoPon-BlockchainURI.mediawiki
+++ b/bip-0122.mediawiki
@@ -1,5 +1,5 @@
 
-  BIP: bip-MarcoPon-BlockchainURI
+  BIP: 122
   Title: URI scheme for Blockchain references / exploration
   Author: Marco Pontello 
   Status: Draft
@@ -66,7 +66,7 @@ Bitcoin regtest: 0f9188f13cb7b2c71f2a335e3a4fc328bf5beb436012afca590b1a11466e220
 
 An example of forked chain (Feathercoin, that forked Litecoin):
 
-
+
 
 
 Litecoin   : 12a765e31ffd4059bada1e25190f6e98c99d9714d334efa41a195a7e7e04bfe2
diff --git a/bip-MarcoPon-BlockchainURI/chainid.png b/bip-0122/chainid.png
similarity index 100%
rename from bip-MarcoPon-BlockchainURI/chainid.png
rename to bip-0122/chainid.png

From 5f59ac2d9d79b89031d2787d82c53162b28e03e0 Mon Sep 17 00:00:00 2001
From: Luke Dashjr 
Date: Fri, 8 Jan 2016 17:47:46 +0000
Subject: [PATCH 120/259] Assign BIP 140

---
 README.mediawiki                         | 6 ++++++
 bip-00nn.mediawiki => bip-0140.mediawiki | 2 +-
 2 files changed, 7 insertions(+), 1 deletion(-)
 rename bip-00nn.mediawiki => bip-0140.mediawiki (99%)

diff --git a/README.mediawiki b/README.mediawiki
index 1243d20c..d41afcd1 100644
--- a/README.mediawiki
+++ b/README.mediawiki
@@ -349,6 +349,12 @@ Those proposing changes should consider that ultimately consent may rest with th
 | Kalle Rosenbaum
 | Standard
 | Draft
+|-
+| [[bip-0140.mediawiki|140]]
+| Normalized TXID
+| Christian Decker
+| Standard
+| Draft
 |}
 
 
diff --git a/bip-00nn.mediawiki b/bip-0140.mediawiki
similarity index 99%
rename from bip-00nn.mediawiki
rename to bip-0140.mediawiki
index dfe48a53..b187a49b 100644
--- a/bip-00nn.mediawiki
+++ b/bip-0140.mediawiki
@@ -1,5 +1,5 @@
 
-  BIP: NN
+  BIP: 140
   Title: Normalized TXID
   Author: Christian Decker 
   Status: Draft

From 8fdd879cdc2635784848a951bbd81fb12cff0d0b Mon Sep 17 00:00:00 2001
From: Luke Dashjr 
Date: Fri, 8 Jan 2016 17:50:22 +0000
Subject: [PATCH 121/259] Assign BIP 125

---
 README.mediawiki                               | 12 ++++++------
 bip-opt-in-rbf.mediawiki => bip-0125.mediawiki |  2 +-
 2 files changed, 7 insertions(+), 7 deletions(-)
 rename bip-opt-in-rbf.mediawiki => bip-0125.mediawiki (99%)

diff --git a/README.mediawiki b/README.mediawiki
index 14d8a06c..bcc8b95b 100644
--- a/README.mediawiki
+++ b/README.mediawiki
@@ -374,17 +374,17 @@ Those proposing changes should consider that ultimately consent may rest with th
 | Informational
 | Draft
 |-
+| [[bip-0125.mediawiki|125]]
+| Opt-in Full Replace-by-Fee Signaling
+| David Harding, Peter Todd
+| Standard
+| Draft
+|-
 | [[bip-0130.mediawiki|130]]
 | sendheaders message 
 | Suhas Daftuar
 | Standard
 | Draft
-|-
-| [[bip-opt-in-rbf.mediawiki|FIXME]]
-| Opt-in Full Replace-by-Fee Signaling
-| David Harding, Peter Todd
-| Standard
-| Draft
 |}
 
 
diff --git a/bip-opt-in-rbf.mediawiki b/bip-0125.mediawiki
similarity index 99%
rename from bip-opt-in-rbf.mediawiki
rename to bip-0125.mediawiki
index 5bd24729..63788e9d 100644
--- a/bip-opt-in-rbf.mediawiki
+++ b/bip-0125.mediawiki
@@ -1,5 +1,5 @@
 
-  BIP: bip-harding-opt-in-replace-by-fee
+  BIP: 125
   Title: Opt-in Full Replace-by-Fee Signaling
   Author: David A. Harding , Peter Todd 
   Status: Draft

From b16a75072d11b367d97d2676d260a5cd6a907adf Mon Sep 17 00:00:00 2001
From: Luke Dashjr 
Date: Fri, 8 Jan 2016 17:53:59 +0000
Subject: [PATCH 122/259] Assign BIP 141

---
 README.mediawiki                                            | 6 ++++++
 bip-codeshark-jl2012-segwit.mediawiki => bip-0141.mediawiki | 2 +-
 2 files changed, 7 insertions(+), 1 deletion(-)
 rename bip-codeshark-jl2012-segwit.mediawiki => bip-0141.mediawiki (99%)

diff --git a/README.mediawiki b/README.mediawiki
index b45c17a0..af982a5e 100644
--- a/README.mediawiki
+++ b/README.mediawiki
@@ -379,6 +379,12 @@ Those proposing changes should consider that ultimately consent may rest with th
 | Suhas Daftuar
 | Standard
 | Draft
+|-
+| [[bip-0141.mediawiki|141]]
+| Segregated Witness (Consensus layer)
+| Eric Lombrozo, Johnson Lau, and Pieter Wuille
+| Standard
+| Draft
 |}
 
 
diff --git a/bip-codeshark-jl2012-segwit.mediawiki b/bip-0141.mediawiki
similarity index 99%
rename from bip-codeshark-jl2012-segwit.mediawiki
rename to bip-0141.mediawiki
index dd81c1d0..ac44d870 100644
--- a/bip-codeshark-jl2012-segwit.mediawiki
+++ b/bip-0141.mediawiki
@@ -1,5 +1,5 @@
 
-  BIP: x
+  BIP: 141
   Title: Segregated Witness (Consensus layer)
   Author: Eric Lombrozo 
           Johnson Lau 

From 1c879abccd4308006a565bc26d0ee58d13b6541a Mon Sep 17 00:00:00 2001
From: Luke Dashjr 
Date: Fri, 8 Jan 2016 17:56:02 +0000
Subject: [PATCH 123/259] Assign BIP 142

---
 README.mediawiki                                  | 6 ++++++
 bip-segwitaddress.mediawiki => bip-0142.mediawiki | 2 +-
 2 files changed, 7 insertions(+), 1 deletion(-)
 rename bip-segwitaddress.mediawiki => bip-0142.mediawiki (99%)

diff --git a/README.mediawiki b/README.mediawiki
index b45c17a0..a895342b 100644
--- a/README.mediawiki
+++ b/README.mediawiki
@@ -379,6 +379,12 @@ Those proposing changes should consider that ultimately consent may rest with th
 | Suhas Daftuar
 | Standard
 | Draft
+|-
+| [[bip-0142.mediawiki|142]]
+| Address Formats for Witness Program
+| Johnson Lau
+| Standard
+| Draft
 |}
 
 
diff --git a/bip-segwitaddress.mediawiki b/bip-0142.mediawiki
similarity index 99%
rename from bip-segwitaddress.mediawiki
rename to bip-0142.mediawiki
index f92e3680..7efeca74 100644
--- a/bip-segwitaddress.mediawiki
+++ b/bip-0142.mediawiki
@@ -1,5 +1,5 @@
 
-  BIP: x
+  BIP: 142
   Title: Address Formats for Witness Program
   Author: Johnson Lau 
   Status: Draft

From 1e9d6180fe2bf5233e3679d2155f954cd6412d8e Mon Sep 17 00:00:00 2001
From: Luke Dashjr 
Date: Fri, 8 Jan 2016 17:57:52 +0000
Subject: [PATCH 124/259] Assign BIP 143

---
 README.mediawiki                                    | 6 ++++++
 bip-segwit-checksig.mediawiki => bip-0143.mediawiki | 2 +-
 2 files changed, 7 insertions(+), 1 deletion(-)
 rename bip-segwit-checksig.mediawiki => bip-0143.mediawiki (99%)

diff --git a/README.mediawiki b/README.mediawiki
index b45c17a0..beb59e51 100644
--- a/README.mediawiki
+++ b/README.mediawiki
@@ -379,6 +379,12 @@ Those proposing changes should consider that ultimately consent may rest with th
 | Suhas Daftuar
 | Standard
 | Draft
+|-
+| [[bip-0143.mediawiki|143]]
+| Transaction signature verification for version 0 and version 1 witness program
+| Johnson Lau, Pieter Wuille
+| Standard
+| Draft
 |}
 
 
diff --git a/bip-segwit-checksig.mediawiki b/bip-0143.mediawiki
similarity index 99%
rename from bip-segwit-checksig.mediawiki
rename to bip-0143.mediawiki
index dc6c3df4..276e2cb1 100644
--- a/bip-segwit-checksig.mediawiki
+++ b/bip-0143.mediawiki
@@ -1,5 +1,5 @@
 
-  BIP: x
+  BIP: 143
   Title: Transaction signature verification for version 0 and version 1 witness program
   Author: Johnson Lau 
           Pieter Wuille 

From 8084782fa5d3143555db1e8ac13eda5a4ae82c52 Mon Sep 17 00:00:00 2001
From: Luke Dashjr 
Date: Fri, 8 Jan 2016 17:59:36 +0000
Subject: [PATCH 125/259] Assign BIP 144

---
 README.mediawiki                                    |   6 ++++++
 ...it-peer-services.mediawiki => bip-0144.mediawiki |   4 ++--
 .../witnesstx.png                                   | Bin
 3 files changed, 8 insertions(+), 2 deletions(-)
 rename bip-codeshark-segwit-peer-services.mediawiki => bip-0144.mediawiki (98%)
 rename {bip-codeshark-segwit-peer-services => bip-0144}/witnesstx.png (100%)

diff --git a/README.mediawiki b/README.mediawiki
index b45c17a0..ce44289c 100644
--- a/README.mediawiki
+++ b/README.mediawiki
@@ -379,6 +379,12 @@ Those proposing changes should consider that ultimately consent may rest with th
 | Suhas Daftuar
 | Standard
 | Draft
+|-
+| [[bip-0144.mediawiki|144]]
+| Segregated Witness (Peer Services)
+| Eric Lombrozo, Pieter Wuille
+| Standard
+| Draft
 |}
 
 
diff --git a/bip-codeshark-segwit-peer-services.mediawiki b/bip-0144.mediawiki
similarity index 98%
rename from bip-codeshark-segwit-peer-services.mediawiki
rename to bip-0144.mediawiki
index 78412c1d..ed8cf2be 100644
--- a/bip-codeshark-segwit-peer-services.mediawiki
+++ b/bip-0144.mediawiki
@@ -1,5 +1,5 @@
 
-  BIP: x
+  BIP: 144
   Title: Segregated Witness (Peer Services)
   Author: Eric Lombrozo 
           Pieter Wuille 
@@ -99,7 +99,7 @@ computed from the new witness serialization. (Note that transactions
 with an empty witness always use the old serialization,
 and therefore, they have witness hash equal to normal hash.)
 
-
+
 
 === Relay ===
 New inv types MSG_WITNESS_TX and MSG_WITNESS_BLOCK are added, only
diff --git a/bip-codeshark-segwit-peer-services/witnesstx.png b/bip-0144/witnesstx.png
similarity index 100%
rename from bip-codeshark-segwit-peer-services/witnesstx.png
rename to bip-0144/witnesstx.png

From 9bcd89a221a9b39e3f9bd9fa0eb669c2d52a6cce Mon Sep 17 00:00:00 2001
From: Luke Dashjr 
Date: Fri, 8 Jan 2016 18:00:58 +0000
Subject: [PATCH 126/259] README: Common formatting for name lists

---
 README.mediawiki | 14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/README.mediawiki b/README.mediawiki
index 6244ca79..7eba079a 100644
--- a/README.mediawiki
+++ b/README.mediawiki
@@ -153,7 +153,7 @@ Those proposing changes should consider that ultimately consent may rest with th
 |- style="background-color: #cfffcf"
 | [[bip-0037.mediawiki|37]]
 | Bloom filtering
-| Mike Hearn and Matt Corallo
+| Mike Hearn, Matt Corallo
 | Standard
 | Accepted
 |-
@@ -268,7 +268,7 @@ Those proposing changes should consider that ultimately consent may rest with th
 |-
 | [[bip-0068.mediawiki|68]]
 | Relative lock-time through consensus-enforced sequence numbers
-| Mark Friedenbach, BtcDrak and Nicolas Dorier
+| Mark Friedenbach, BtcDrak, Nicolas Dorier
 | Standard
 | Draft
 |-
@@ -346,19 +346,19 @@ Those proposing changes should consider that ultimately consent may rest with th
 |-
 | [[bip-0111.mediawiki|111]]
 | NODE_BLOOM service bit
-| Matt Corallo and Peter Todd
+| Matt Corallo, Peter Todd
 | Standard
 | Draft
 |-
 | [[bip-0112.mediawiki|112]]
 | CHECKSEQUENCEVERIFY
-| BtcDrak and Mark Friedenbach
+| BtcDrak, Mark Friedenbach
 | Standard
 | Draft
 |-
 | [[bip-0113.mediawiki|113]]
 | Median time-past as endpoint for lock-time calculations
-| Thomas Kerin and Mark Friedenbach
+| Thomas Kerin, Mark Friedenbach
 | Standard
 | Draft
 |-
@@ -393,7 +393,7 @@ Those proposing changes should consider that ultimately consent may rest with th
 | Draft
 |-
 | [[bip-0130.mediawiki|130]]
-| sendheaders message 
+| sendheaders message
 | Suhas Daftuar
 | Standard
 | Draft
@@ -406,7 +406,7 @@ Those proposing changes should consider that ultimately consent may rest with th
 |-
 | [[bip-0141.mediawiki|141]]
 | Segregated Witness (Consensus layer)
-| Eric Lombrozo, Johnson Lau, and Pieter Wuille
+| Eric Lombrozo, Johnson Lau, Pieter Wuille
 | Standard
 | Draft
 |-

From e516dc796b28d80902cd64a252fa6da43290e0e1 Mon Sep 17 00:00:00 2001
From: Luke Dashjr 
Date: Fri, 8 Jan 2016 18:04:01 +0000
Subject: [PATCH 127/259] BIP 0001: Update correspondance email

---
 bip-0001.mediawiki | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/bip-0001.mediawiki b/bip-0001.mediawiki
index db7a6efd..d8fab7b5 100644
--- a/bip-0001.mediawiki
+++ b/bip-0001.mediawiki
@@ -147,7 +147,7 @@ The current BIP editor is Luke Dashjr who can be contacted at [[mailto:luke_bipe
 
 ==BIP Editor Responsibilities & Workflow==
 
-A BIP editor must subscribe to the Bitcoin development mailing list. All BIP-related correspondence should be sent (or CC'd) to gmaxwell@gmail.com.
+The BIP editor subscribes to the Bitcoin development mailing list. All BIP-related correspondence should be sent (or CC'd) to luke_bipeditor@dashjr.org.
 
 For each new BIP that comes in an editor does the following:
 

From 0deca071e2c32b4f5ff1101253d94a8b871868c1 Mon Sep 17 00:00:00 2001
From: Luke Dashjr 
Date: Fri, 8 Jan 2016 18:48:34 +0000
Subject: [PATCH 128/259] README: Fix BIP 122 number

---
 README.mediawiki | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/README.mediawiki b/README.mediawiki
index 7eba079a..8e821185 100644
--- a/README.mediawiki
+++ b/README.mediawiki
@@ -374,7 +374,7 @@ Those proposing changes should consider that ultimately consent may rest with th
 | Standard
 | Draft
 |-
-| [[bip-0122.mediawiki|121]]
+| [[bip-0122.mediawiki|122]]
 | URI scheme for Blockchain references / exploration
 | Marco Pontello
 | Standard

From ceb4f76df7f989e3fc6aece14fa55cd3f8fe7419 Mon Sep 17 00:00:00 2001
From: Luke Dashjr 
Date: Fri, 8 Jan 2016 18:52:25 +0000
Subject: [PATCH 129/259] BIP 0001: Minor language nit

---
 bip-0001.mediawiki | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/bip-0001.mediawiki b/bip-0001.mediawiki
index 8512b76c..dbc6e042 100644
--- a/bip-0001.mediawiki
+++ b/bip-0001.mediawiki
@@ -26,7 +26,7 @@ There are three kinds of BIP:
 
 The BIP process begins with a new idea for Bitcoin. Each potential BIP must have a champion -- someone who writes the BIP using the style and format described below, shepherds the discussions in the appropriate forums, and attempts to build community consensus around the idea. The BIP champion (a.k.a. Author) should first attempt to ascertain whether the idea is BIP-able. Posting to the [https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev bitcoin-dev@lists.linuxfoundation.org] mailing list (and maybe the [https://bitcointalk.org/index.php?board=6.0 Development & Technical Discussion] forum) is the best way to go about this.
 
-Vetting an idea publicly before going as far as writing a BIP is meant to both save the potential author and the wider community time. Many ideas have been brought forward for changing Bitcoin that have been rejected for various reasons. Asking the Bitcoin community first if an idea is original helps prevent too much time being spent on something that is guaranteed to be rejected based on prior discussions (searching the internet does not always do the trick). It also helps to make sure the idea is applicable to the entire community and not just the author. Just because an idea sounds good to the author does not mean it will work for most people in most areas where Bitcoin is used. Small enhancements or patches often don't need a BIP and can be injected into the relevant Bitcoin development work flow with a patch submission to the relevant Bitcoin issue tracker.
+Vetting an idea publicly before going as far as writing a BIP is meant to save both the potential author and the wider community time. Many ideas have been brought forward for changing Bitcoin that have been rejected for various reasons. Asking the Bitcoin community first if an idea is original helps prevent too much time being spent on something that is guaranteed to be rejected based on prior discussions (searching the internet does not always do the trick). It also helps to make sure the idea is applicable to the entire community and not just the author. Just because an idea sounds good to the author does not mean it will work for most people in most areas where Bitcoin is used. Small enhancements or patches often don't need a BIP and can be injected into the relevant Bitcoin development work flow with a patch submission to the applicable Bitcoin issue tracker.
 
 Once the champion has asked the Bitcoin community as to whether an idea has any chance of acceptance, a draft BIP should be presented to the [https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev bitcoin-dev] mailing list. This gives the author a chance to flesh out the draft BIP to make it properly formatted, of high quality, and to address additional concerns about the proposal. Following a discussion, the proposal should be sent to the bitcoin-dev list and the BIP editor with the draft BIP. This draft must be written in BIP style as described below, else it will be sent back without further regard until proper formatting rules are followed.
 

From 4c1c02a94dc19b79e372c57a9020a6bb14bfc737 Mon Sep 17 00:00:00 2001
From: Luke Dashjr 
Date: Fri, 8 Jan 2016 18:55:01 +0000
Subject: [PATCH 130/259] BIP 0001: Clarification of when changes don't need a
 BIP

---
 bip-0001.mediawiki | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/bip-0001.mediawiki b/bip-0001.mediawiki
index aac6ba4e..e1abaddc 100644
--- a/bip-0001.mediawiki
+++ b/bip-0001.mediawiki
@@ -26,7 +26,7 @@ There are three kinds of BIP:
 
 The BIP process begins with a new idea for Bitcoin. Each potential BIP must have a champion -- someone who writes the BIP using the style and format described below, shepherds the discussions in the appropriate forums, and attempts to build community consensus around the idea. The BIP champion (a.k.a. Author) should first attempt to ascertain whether the idea is BIP-able. Posting to the [https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev bitcoin-dev@lists.linuxfoundation.org] mailing list (and maybe the [https://bitcointalk.org/index.php?board=6.0 Development & Technical Discussion] forum) is the best way to go about this.
 
-Vetting an idea publicly before going as far as writing a BIP is meant to save both the potential author and the wider community time. Many ideas have been brought forward for changing Bitcoin that have been rejected for various reasons. Asking the Bitcoin community first if an idea is original helps prevent too much time being spent on something that is guaranteed to be rejected based on prior discussions (searching the internet does not always do the trick). It also helps to make sure the idea is applicable to the entire community and not just the author. Just because an idea sounds good to the author does not mean it will work for most people in most areas where Bitcoin is used. Small enhancements or patches often don't need a BIP and can be injected into the relevant Bitcoin development work flow with a patch submission to the applicable Bitcoin issue tracker.
+Vetting an idea publicly before going as far as writing a BIP is meant to save both the potential author and the wider community time. Many ideas have been brought forward for changing Bitcoin that have been rejected for various reasons. Asking the Bitcoin community first if an idea is original helps prevent too much time being spent on something that is guaranteed to be rejected based on prior discussions (searching the internet does not always do the trick). It also helps to make sure the idea is applicable to the entire community and not just the author. Just because an idea sounds good to the author does not mean it will work for most people in most areas where Bitcoin is used. Small enhancements or patches often don't need standardisation between multiple projects; these don't need a BIP and should be injected into the relevant Bitcoin development work flow with a patch submission to the applicable Bitcoin issue tracker.
 
 Once the champion has asked the Bitcoin community as to whether an idea has any chance of acceptance, a draft BIP should be presented to the [https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev bitcoin-dev] mailing list. This gives the author a chance to flesh out the draft BIP to make it properly formatted, of high quality, and to address additional concerns about the proposal. Following a discussion, the proposal should be sent to the bitcoin-dev list and the BIP editor with the draft BIP. This draft must be written in BIP style as described below, else it will be sent back without further regard until proper formatting rules are followed.
 

From d1e0deef254d5e7ab1903e2088c8c4a6594ba9a1 Mon Sep 17 00:00:00 2001
From: Luke Dashjr 
Date: Fri, 8 Jan 2016 20:42:57 +0000
Subject: [PATCH 131/259] Fix markdown

---
 README.mediawiki   | 4 ++--
 bip-0099.mediawiki | 2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/README.mediawiki b/README.mediawiki
index 8e821185..dec53f94 100644
--- a/README.mediawiki
+++ b/README.mediawiki
@@ -303,9 +303,9 @@ Those proposing changes should consider that ultimately consent may rest with th
 | Draft
 |-
 | [[bip-0099.mediawiki|99]]
-| Motivation and deployment of consensus rule changes
+| Motivation and deployment of consensus rule changes ([soft/hard]forks)
 | Jorge Timón
-| Informational | Process
+| Informational / Process
 | Draft
 |-
 | [[bip-0101.mediawiki|101]]
diff --git a/bip-0099.mediawiki b/bip-0099.mediawiki
index c40bacb6..b416e686 100644
--- a/bip-0099.mediawiki
+++ b/bip-0099.mediawiki
@@ -3,7 +3,7 @@
   Title: Motivation and deployment of consensus rule changes ([soft/hard]forks)
   Author: Jorge Timón 
   Status: Draft
-  Type: Informational | Process
+  Type: Informational / Process
   Created: 2015-06-20
   Post-History: http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-June/008936.html
 


From 14ce2bcead9748d472730d33f140abaaaa3b28fa Mon Sep 17 00:00:00 2001
From: Peter Todd 
Date: Mon, 11 Jan 2016 05:02:19 -0500
Subject: [PATCH 132/259] Minor: Fix BIP65 status in README

---
 README.mediawiki | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/README.mediawiki b/README.mediawiki
index dec53f94..fdfb988d 100644
--- a/README.mediawiki
+++ b/README.mediawiki
@@ -252,7 +252,7 @@ Those proposing changes should consider that ultimately consent may rest with th
 | OP_CHECKLOCKTIMEVERIFY
 | Peter Todd
 | Standard
-| Draft
+| Accepted
 |-
 | [[bip-0066.mediawiki|66]]
 | Strict DER signatures

From 858a4a70ea2dfde140c22e5535d1eabb182663b2 Mon Sep 17 00:00:00 2001
From: Johnson Lau 
Date: Mon, 11 Jan 2016 19:08:33 +0800
Subject: [PATCH 133/259] New commitment structure, sigop limits, etc

---
 bip-0141.mediawiki | 204 ++++++++++++++++++++++-----------------------
 1 file changed, 102 insertions(+), 102 deletions(-)

diff --git a/bip-0141.mediawiki b/bip-0141.mediawiki
index ac44d870..7a5c28c1 100644
--- a/bip-0141.mediawiki
+++ b/bip-0141.mediawiki
@@ -21,7 +21,7 @@ The entirety of the transaction's effects are determined by output consumption (
 
 By removing this data from the transaction structure committed to the transaction merkle tree, several problems are fixed:
 
-# '''Nonintentional malleability becomes impossible'''. Since signature data is no longer part of the transaction hash, changes to how the transaction was authorized is no longer relevant to transaction identification. As a solution of transaction malleability, this is superior to the canonical signature approach (BIP62):
+# '''Nonintentional malleability becomes impossible'''. Since signature data is no longer part of the transaction hash, changes to how the transaction was signed are no longer relevant to transaction identification. As a solution of transaction malleability, this is superior to the canonical signature approach ([https://github.com/bitcoin/bips/edit/master/bip-0062.mediawiki BIP62]):
 #* It prevents involuntary transaction malleability for any type of scripts, as long as all inputs are signed (with at least one CHECKSIG or CHECKMULTISIG operation)
 #* In the case of an m-of-n CHECKMULTISIG script, a transaction is malleable only with agreement of m private key holders (as opposed to only 1 private key holder with BIP62)
 #* It prevents involuntary transaction malleability due to unknown ECDSA signature malleability
@@ -30,106 +30,67 @@ By removing this data from the transaction structure committed to the transactio
 # '''Some constraints could be bypassed with a soft fork''' by moving part of the transaction data to a structure unknown to current protocol, for example:
 #* Size of witness could be ignored / discounted when calculating the block size, effectively increasing the block size to some extent
 #* Hard coded constants, such as maximum data push size (520 bytes) or sigops limit could be reevaluated or removed
-#* New script system could be introduced without any limitation from the existing script semantic
-# '''Additional data required for fraud proofs can be added to witness'''. Extra data can be committed that allows short proofs of block invalidity that SPV nodes can quickly verify.
-#* Backlinks for the outputs spent by the transaction's inputs can be provided. These backlinks consist of a block hash and an offset that thin clients can easily query and check to verify that the outputs exist.
-#* Sum trees for transaction inputs and outputs can be committed making it possible to construct short proofs that no new coins are created in any noncoinbase transaction and that the miner does not add excessive fees to the coinbase transaction. 
+#* New script system could be introduced without any limitation from the existing script semantic. For example, a new transaction digest algorithm for transaction signature verification is described in [https://github.com/bitcoin/bips/blob/master/bip-0143.mediawiki BIP143]
 
 ==Specification==
 
 === Commitment structure ===
 
-!!!DRAFT ONLY!!!
-
-A new block rule is added which requires a commitment to the witness hashes in the coinbase (or an OP_RETURN output of a specific transaction, or somewhere else)
-
-(Hardfork after x year to move the commitment to block header?)
-
-Witness hash is the double SHA256 of a transaction including witnesses: http://blockhawk.net/diagrams/witnesstx.png. For the coinbase transaction, its witness hash is assumed to be 0x0000....0000.
+A new block rule is added which requires a commitment to the witness hashes, the double SHA256 of a transaction including witnesses. The witness hash of coinbase transaction is assumed to be 0x0000....0000.
 
 A witness root hash is calculated with all those witness hashes as leaves, in a way similar to the hashMerkleRoot in the block header.
 
-No witness data is allowed in blocks that don't commit to witness data, as this would otherwise leave room from spam.
+The commitment is recorded in a scriptPubKey of the coinbase transaction. It must be at least 38 bytes, with the first 6-byte of 0x6a24aa21a9ed, that is:
+  
+   1-byte - OP_RETURN (0x6a)
+   1-byte - Push the following 36 bytes (0x24)
+   4-byte - Commitment header (0xaa21a9ed)
+  32-byte - Commitment hash: Double-SHA256(witness root hash|witness nonce)
+  
+  39th byte onwards: Optional data with no consensus meaning
+  
+and the coinbase's input's witness must consist of a single 32-byte array for the witness nonce.
 
-==== Proposal 1: balance tree (the current implementation) ====
-The commitment is a push of exactly 41 bytes:
-*The first 4 bytes are commitment header: 0xaa21a9ed
-*The next 4 bytes describe a nonce
-*The next 1 byte is the "levels bytes", describes the number of levels in a Merkle tree (0 to 32)
-*The next 32 bytes is a commitment root hash (not the witness root hash)
-
-Locator of the witness root hash is defined as:
-
-
SHA256('WitnessV1\x00\x00\x00\x00\x00\x00\x00' || nonce)

-
-The first levels bits of locator, interpreted in little endian, are assumed to be the position in the leaves of the Merkle tree where the witness root hash goes.
-
-The coinbase's input's witness must consist of a single byte array of 32 * levels bytes, and are assumed to be the Merkle path to connect the witness root hash to the commitment root hash.
-
-====Proposal 2: imbalance tree====
-The commitment is a push of exactly 40 bytes:
-*The first 4 bytes are commitment header: 0xaa21a9ed
-*The next 4 bytes describe a nonce
-*The next 32 bytes is a commitment root hash (not the witness root hash)
-
-Locator of the witness root hash is defined as:
-
-
SHA256('WitnessV1\x00\x00\x00\x00\x00\x00\x00' || nonce)

-
-The first levels bits of locator, interpreted in little endian, are assumed to be the position in the leaves of the Merkle tree where the witness root hash goes.
-
-The coinbase's input's witness must consist of a single byte array, which the size must be a multiple of 32 bytes but not bigger than 32*32 bytes. These are assumed to be the Merkle path to connect the witness root hash to the commitment root hash. Depth of the commitment is determined by the length of the path. If the depth of the tree is 0, the path should be represented by 0x00, and the witness root hash will be same as the commitment root hash.
-
-=== Block size limit ===
-Blocks are currently limited to 1 MB total size. We change this restriction as follows:
-
-We define a base block size sb consisting of the existing header and transactions, a witness size sw consisting of only the size of the witness data, and a virtual block size sv = sb + sw/4.
-
-The new rule is sv <= 1 MB.
+If there are more than one scriptPubKey matching the pattern, the one with highest output index is assumed to be the commitment.
 
 === Witness program ===
 
-* A scriptPubKey (or redeemScript as defined in BIP16/P2SH) that consists of a 1-byte push opcode (for 0 to 16) followed by a data push between 2 and 32 bytes gets a new special meaning. The value of the first push is called the "version byte". The following byte vector pushed is called the "witness program".
-** In case the scriptPubKey pushes a version byte and witness program directly, the scriptSig must be exactly empty.
-** In case the redeemScript pushes a version byte and witness program, the scriptSig must be exactly the single push of the redeemScript.
+A scriptPubKey (or redeemScript as defined in BIP16/P2SH) that consists of a 1-byte push opcode (for 0 to 16) followed by a data push between 2 and 32 bytes gets a new special meaning. The value of the first push is called the "version byte". The following byte vector pushed is called the "witness program".
 
-** If the version byte is 0, the WP is the actual script.
-*** The script is executed after normal script evaluation but with data from the witness rather than the scriptSig.
-*** The program must not fail, and result in exactly a single TRUE on the stack.
-** If the version byte is 1, the WP must be 32 bytes, as a SHA256 hash of the actual script.
-*** The witness must consist of an input stack to feed to the program, followed by the serialized program.
-*** The serialized program is popped off the initial witness stack. Hash of the serialized program must match the hash pushed in the witness program.
-*** The serialized program is deserialized, and executed after normal script evaluation with the remaining witness stack.
-*** The script must not fail, and result in exactly a single TRUE on the stack.
-** If the version byte is 2 to 16, no further interpretation of the witness program or witness happens.
+New rules for scriptSig:
+* In case the scriptPubKey pushes a version byte and witness program directly, the scriptSig must be exactly empty.
+* In case the redeemScript pushes a version byte and witness program, the scriptSig must be exactly the single push of the redeemScript.
 
-=== Other consensus critical constraints ===
+If the version byte is 0, the witness program is the actual script:
+* The script is executed after normal script evaluation but with data from the witness rather than the scriptSig.
+* The program must not fail and must result in exactly a single TRUE on the stack.
 
-== Block size analysis ==
-WORK IN PROGRESS
+If the version byte is 1, the witness program must be 32 bytes, as a SHA256 hash of the actual script:
+* The witness must consist of an input stack to feed to the program, followed by the serialized program.
+* The serialized program is popped off the initial witness stack. SHA256 of the serialized program must match the hash pushed in the witness program.
+* The serialized program is deserialized, and executed after normal script evaluation with the remaining witness stack.
+* The script must not fail, and result in exactly a single TRUE on the stack.
+* If the witness program is between 2 and 31 bytes, the script must fail.
 
-Definitions:
-
- Core block size (CBS): The block size as seen by a non-upgrading full node
- Witness size (WS): The total size of witness data in a block
- Total block size (TBS): CBS + WS
- Witness discount (WD): A discount factor for witness data in VBS calculation (1 = no discount)
- Virtual block size (VBS): CBS + (WS * WD)
- Witness adoption (WA): Proportion (in size) of new format transactions among all transactions
- Prunable ratio (PR): Proportion of signature data size in a transaction
-

+If the version byte is 2 to 16, no further interpretation of the witness program or witness happens.
 
-With some transformation it could be shown that:
-
- TBS = CBS / (1 - WA * PR)
-     = VBS / (1 - WA * PR * (1 - WD))
-

+=== Other consensus critical limits ===
 
-In order to keep the proposal as a soft fork, the CBS must not have a upper limit higher than 1MB.
+==== Block size ====
 
-The PR heavily depends on the transaction script type and input-output ratio. For example, the PR of 1-in 2-out P2PKH and 1-in 1-out 2-of-2 multisig P2SH are about 47% and 72% respectively. According to the data presented by Pieter Wuille on 7 December 2015, the current average PR on the blockchain is about 60%.
+Blocks are currently limited to 1,000,000 bytes (1MB) total size. We change this restriction as follows:
 
+''Block cost'' is defined. The cost of each byte in the existing header and transactions is 4, while the cost of each byte in witness data is 1.
 
+The new rule is total ''block cost'' ≤ 4,000,000.
+
+==== Sigops ====
+
+Sigops per block is currently limited to 20,000. We change this restriction as follows:
+
+''Sigop cost'' is defined. The cost of a sigop in traditoinal script is 4, while the cost of a sigop in witness program is 1.
+
+The new rule is total ''sigop cost'' ≤ 80,000.
 
 == Examples ==
 
@@ -139,15 +100,16 @@ The following example is a version 0 witness program, equivalent to the existing
 
     witness:       
     scriptSig:    (empty)
-    scriptPubKey: OP_0 <0x76A914{20-byte-hash-value}88AC>
+    scriptPubKey: 0  EQUALVERIFY CHECKSIG>
+                  (0x001976A914{20-byte-hash}88AC)
 
-The OP_0 indicates the following push is a version 0 witness program. The witness program is deserialized and becomes:
+The '0' indicates the following push is a version 0 witness program. The witness program is deserialized and becomes:
 
-    DUP HASH160 <20byte-hash-value> EQUALVERIFY CHECKSIG
+    DUP HASH160 <20-byte-hash> EQUALVERIFY CHECKSIG
 
 The script is executed with the data from witness
 
-      DUP HASH160 <20byte-hash-value> EQUALVERIFY CHECKSIG
+      DUP HASH160 <20-byte-hash> EQUALVERIFY CHECKSIG
 
 Comparing with a P2PKH output, the witness program equivalent occupies 2 more bytes in the scriptPubKey, while moving the signature and public key from scriptSig to witness.
 
@@ -155,39 +117,57 @@ Comparing with a P2PKH output, the witness program equivalent occupies 2 more by
 
 The following example is an 1-of-2 multi-signature version 1 witness program.
 
-    witness:      0  <0x5121{33-byte-pubkey1}21{33-byte-pubkey2}52AE>
+    witness:      0  <1   2 CHECKMULTISIG>
     scriptSig:    (empty)
-    scriptPubKey: OP_1 <0x{32-byte-hash-value}>
+    scriptPubKey: 1 <32-byte-hash>
+                  (0x5120{32-byte-hash})
 
-The OP_1 in scriptPubKey indicates the following push is a version 1 witness program. The last item in the witness is popped off, hashed with SHA256, compared against the 32-byte-hash-value in scriptPubKey, and deserialized:
+The '1' in scriptPubKey indicates the following push is a version 1 witness program. The last item in the witness is popped off, hashed with SHA256, compared against the 32-byte-hash in scriptPubKey, and deserialized:
 
-    1 <33-byte-pubkey1> <33-byte-pubkey2> 2 CHECKMULTISIG
+    1   2 CHECKMULTISIG
 
 The script is executed with the remaining data from witness:
 
-    0  1 <33-byte-pubkey1> <33-byte-pubkey2> 2 CHECKMULTISIG
+    0  1   2 CHECKMULTISIG
 
 Since the actual program is larger than 32 bytes, it cannot be accommodated in a version 0 witness program. A version 1 witness program allows arbitrarily large script as the 520-byte push limit is bypassed.
 
-The scriptPubKey occupies 34 bytes, as opposed to 23 bytes of P2SH. The increased size improves security against possible collision attacks, as 2^80 work is not infeasible anymore (By the end of 2015, 2^84 hashes have been calculated in Bitcoin mining since the creation of Bitcoin). The spending script is same as the one for an equivalent P2SH output but is moved to witness.
+The scriptPubKey occupies 34 bytes, as opposed to 23 bytes of P2SH. The increased size improves security against possible collision attacks, as 280 work is not infeasible anymore (By the end of 2015, 284 hashes have been calculated in Bitcoin mining since the creation of Bitcoin). The spending script is same as the one for an equivalent P2SH output but is moved to witness.
 
 === Witness program nested in Pay-to-Script-Hash ===
 
 The following example is the same 1-of-2 multi-signature version 1 witness program, but nested in a P2SH output.
 
-    witness:      0  <0x5121{33-byte-pubkey1}21{33-byte-pubkey2}52AE>
-    scriptSig:    <0x5120{32-byte-hash-value}>
-    scriptPubKey: HASH160 <20-byte-hash-value> EQUAL
+    witness:      0  <1   2 CHECKMULTISIG>
+    scriptSig:    <1 <32-byte-hash>>
+                  (5120{32-byte-hash})
+    scriptPubKey: HASH160 <20-byte-hash> EQUAL
+                  (0x76A914{20-byte-hash}88AC)
 
-The only item in scriptSig is hashed with HASH160, compared against the 20-byte-hash-value in scriptPubKey, and interpreted as:
+The only item in scriptSig is hashed with HASH160, compared against the 20-byte-hash in scriptPubKey, and interpreted as:
 
-    OP_1 <0x{32-byte-hash-value}>
+    1 <32-byte-hash>
 
 The version 1 witness program is then executed as described in the last example
 
 Comparing with the last example, the scriptPubKey is 11 bytes smaller (with reduced security) while witness is the same. However, it also requires 35 bytes in scriptSig, which is not prunable in transmission. Although a nested witness program is less efficient in many ways, its payment address is fully transparent and backward compatible for all Bitcoin reference client since version 0.6.0.
 
+=== Extensible commitment structure ===
+
+The new commitment in coinbase transaction is a hash of the witness root hash and a witness nonce. The nonce which currently has no consensus meaning, serves two purposes:
+
+* It allows new commitment values for future softforks. For example, if a new consensus-critical commitment is required in the future, the commitment in coinbase becomes:
+  
+  Double-SHA256(Witness root hash|Hash(new commitment|witness nonce))
+
+:: For backward compatibility, the Hash(new commitment|witness nonce) will go to the coinbase witness, and the witness nonce will be recorded in another location specified by the future softfork. Any number of new commitment could be added in this way.
+
+* Any commitments that are not consensus-critical to Bitcoin, such as merge-mining, may utilize this witness nonce. However, they must not be committed directly as the nonce, or the external system may be forced to hardfork when Bitcoin introduces more consensus-critical commitments. Instead, they should use the nonce as the root of an extensible commitment tree, and should not make any assumption about the location and depth of their commitments in the tree. For example, in the external system, it may use a flag to indicate the actual location of the commitments with the Merkle paths provided.
+
+The optional data space following the commitment also leaves room for metadata of future softforks.
+
 === Trust-free unconfirmed transaction dependency chain ===
+
 Segregated witness fixes the problem of transaction malleability fundamentally, which enables the building of unconfirmed transaction dependency chains in a trust-free manner.
 
 Two parties, Alice and Bob, may agree to send certain amount of Bitcoin to a 2-of-2 multisig output (the "funding transaction"). Without signing the funding transaction, they may create another transaction, time-locked in the future, spending the 2-of-2 multisig output to third account(s) (the "spending transaction"). Alice and Bob will sign the spending transaction and exchange the signatures. After examining the signatures, they will sign and commit the funding transaction to the blockchain. Without further action, the spending transaction will be confirmed after the lock-time and release the funding according to the original contract. It also retains the flexibility of revoking the original contract before the lock-time, by another spending transaction with shorter lock-time, but only with mutual-agreement of both parties.
@@ -197,7 +177,9 @@ Such setups is not possible with BIP62 as the malleability fix, since the spendi
 Unconfirmed transaction dependency chain is a fundamental building block of more sophisticated payment networks, such as duplex micropayment channel and the Lightning Network, which have the potential to greatly improve the scalability and efficiency of the Bitcoin system.
 
 == Future extensions ==
+
 === Compact fraud proof for SPV nodes ===
+
 Bitcoin right now only has two real security models. A user either runs a full-node which validates every block with all rules in the system, or a SPV (Simple Payment Verification) client which only validates the headers as a proof of publication of some transactions. The Bitcoin whitepaper suggested that SPV nodes may accept alerts from full nodes when they detect an invalid block, prompting the SPV node to download the questioned blocks and transactions for validation. This approach, however, could become a DoS attack vector as there is virtually no cost to generate a false alarm. An alarm must come with a compact, yet deterministic fraud proof.
 
 In the current Bitcoin protocol, it is possible to generate compact fraud proof for almost all rules except a few:
@@ -206,9 +188,15 @@ In the current Bitcoin protocol, it is possible to generate compact fraud proof
 # It is not possible to prove the violation of any block specific constraints, such as size and sigop limits, without showing the whole block (and all input transactions in the case of sigop limit)
 # It is not possible to prove the spending of a non-existing input without showing all transaction IDs in the blockchain way back to the genesis block.
 
-It is possible to prove the first 2 types of fraud if a block is committed to a Merkle-sum-tree of the fee, size, and sigop count of each transaction. It is also possible to prove the last type of fraud if a block is committed to a Merkle tree with the originating block height and transaction index of all inputs. These commitments could be included in the extensible witness commitment through a soft fork and will be transparent to nodes that do not understand such new rules.
+Extra witness data can be committed that allows short proofs of block invalidity that SPV nodes can quickly verify:
+
+# Sum trees for transaction fee can be committed making it possible to construct short proofs that the miner does not add excessive fees to the coinbase transaction. Similar for the block size and sigop count limit.
+# Backlinks for the outputs spent by the transaction's inputs can be provided. These backlinks consist of a block hash and an offset that thin clients can easily query and check to verify that the outputs exist.
+
+These commitments could be included in the extensible commitment structure through a soft fork and will be transparent to nodes that do not understand such new rules.
 
 === New script system ===
+
 Since a version byte is pushed before a witness program, and programs with unknown versions are always considered as anyone-can-spend script, it is possible to introduce any new script system with a soft fork. The witness as a structure is not restricted by any existing script semantics and constraints, the 520-byte push limit in particular, and therefore allows arbitrarily large scripts and signatures.
 
 Examples of new script system include Schnorr signatures which reduce the size of multisig transactions dramatically, Lamport signature which is quantum computing resistance, and Merklized abstract syntax trees which allow very compact witness for conditional scripts with extreme complexity.
@@ -216,23 +204,26 @@ Examples of new script system include Schnorr signatures which reduce the size o
 The 32-byte limitation for witness program could be easily extended through a soft fork in case a stronger hash function is needed in the future. The version byte is also expandable through a softfork.
 
 === Per-input lock-time and relative-lock-time ===
-Currently there is only one nLockTime field in a transaction and all inputs must share the same value. BIP68 enables per-input relative-lock-time using the nSequence field, however, with a limited lock-time period and resolution.
 
-With a soft fork, it is possible to introduce a separate witness structure to allow per-input lock-time and relative-lock-time, and a new script system that could sign and manipulate the new data (like BIP65 and BIP112).
+Currently there is only one nLockTime field in a transaction and all inputs must share the same value. [https://github.com/bitcoin/bips/edit/master/bip-0068.mediawiki BIP68] enables per-input relative-lock-time using the nSequence field, however, with a limited lock-time period and resolution.
+
+With a soft fork, it is possible to introduce a separate witness structure to allow per-input lock-time and relative-lock-time, and a new script system that could sign and manipulate the new data (like [https://github.com/bitcoin/bips/edit/master/bip-0065.mediawiki BIP65] and [https://github.com/bitcoin/bips/edit/master/bip-0112.mediawiki BIP112]).
 
 == Backward compatibility ==
+
 As a soft fork, older software will continue to operate without modification.  Non-upgraded nodes, however, will not see nor validate the witness data and will consider all witness programs as anyone-can-spend scripts (except a few edge cases in version 0 witness programs which are provably unspendable with original script semantics). Wallets should always be wary of anyone-can-spend scripts and treat them with suspicion. Non-upgraded nodes are strongly encouraged to upgrade in order to take advantage of the new features.
 
 '''What a non-upgraded wallet can do'''
 
 * Receiving bitcoin from non-upgraded and upgraded wallets
 * Sending bitcoin to non-upgraded wallets
-* Sending bitcoin to upgraded wallets using a P2SH address (a less efficient way to use segregated witness)
+* Sending bitcoin to upgraded wallets using a P2SH address (less efficient)
+* Sending bitcoin to upgraded wallets using a native witness program (more efficient) through [https://github.com/bitcoin/bips/blob/master/bip-0070.mediawiki BIP70] payment protocol
 
 '''What a non-upgraded wallet cannot do'''
 
 * Validating segregated witness transaction. It assumes such a transaction is always valid
-* Sending bitcoin to upgraded wallets using a native witness program (a more efficient way to use segregated witness)
+* Sending bitcoin to upgraded wallets using a native witness program if BIP70 is not supported
 
 == Deployment ==
 
@@ -248,7 +239,6 @@ invalid, and all further blocks enforce the new rules.
 1 which results in nVersion >= all prior IsSuperMajority() soft-forks and thus
 no bits in nVersion are permanently lost.)
 
-
 === SPV Clients ===
 
 While SPV clients are unable to fully validate blocks,
@@ -258,10 +248,20 @@ nVersion >= 5 to prevent false confirmations from the remaining 5% of
 non-upgraded miners when the 95% threshold has been reached.
 
 == Credits ==
+
 Special thanks to Gregory Maxwell for originating many of the ideas in this BIP and Luke-Jr for figuring out how to deploy this as a soft fork.
 
 == Reference Implementation ==
-https://github.com/sipa/bitcoin/commits/segwit
+
+https://github.com/sipa/bitcoin/commits/segwit2
+
+== References ==
+
+*[https://github.com/bitcoin/bips/blob/master/bip-0016.mediawiki BIP16 Pay to Script Hash]
+*[https://github.com/bitcoin/bips/blob/master/bip-0142.mediawiki BIP142 Address Formats for Witness Program]
+*[https://github.com/bitcoin/bips/blob/master/bip-0143.mediawiki BIP143 Transaction signature verification for version 0 and version 1 witness program]
+*[https://github.com/bitcoin/bips/blob/master/bip-0144.mediawiki BIP144 Segregated Witness (Peer Services)]
 
 == Copyright ==
+
 This document is placed in the public domain.

From ae529c3f0488fec6ebc335f2bdb0e623af6a6a5c Mon Sep 17 00:00:00 2001
From: Johnson Lau 
Date: Tue, 12 Jan 2016 03:09:50 +0800
Subject: [PATCH 134/259] Fix links in BIP142-144. Corrections in BIP142.

---
 bip-0142.mediawiki | 6 +++---
 bip-0143.mediawiki | 6 +++---
 bip-0144.mediawiki | 2 +-
 3 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/bip-0142.mediawiki b/bip-0142.mediawiki
index 7efeca74..fdf52027 100644
--- a/bip-0142.mediawiki
+++ b/bip-0142.mediawiki
@@ -19,8 +19,8 @@ To define standard payment addresses for native segwit transactions to promote e
 
 === P2PKH segwit address ===
 
-The first new Bitcoin address format defined is specific to pay-to-public-key-hash segwit transaction. The scriptPubKey is a single push of version-0 witness program in this form,
-  <0x0076A914{20-byte-hash-value}88AC>
+The first new Bitcoin address format defined is specific to pay-to-public-key-hash segwit transaction. The scriptPubKey is an OP_0 followed by a push of version 0 witness program:
+  OP_0  EQUALVERIFY CHECKSIG>
 The new address is encoded exactly in the same way as the original pay-to-public-key-hash address:
   base58-encode: [1-byte version][20-byte-hash-value][4-byte checksum]
 Version byte is 0x19 for a main-network address, 0x41 for a testnet address. The following 20-byte is the public key hash. And the 4-byte checksum is the first four bytes of the double SHA256 hash of the version and public key hash.
@@ -151,7 +151,7 @@ From arbitrary witness program to general segwit address: https://gist.github.co
 
 * [[bip-0013.mediawiki|BIP 13: Address Format for pay-to-script-hash]]
 * [[bip-0016.mediawiki|BIP 16: Pay to Script Hash (aka "/P2SH/")]]
-* [[bip-xxxx.mediawiki|BIP x: Segregated Witness]] https://github.com/bitcoin/bips/pull/265
+* [[bip-0141.mediawiki|BIP 141: Segregated Witness]]
 
 == Copyright ==
 This work is placed in the public domain.
diff --git a/bip-0143.mediawiki b/bip-0143.mediawiki
index 276e2cb1..4aca2db6 100644
--- a/bip-0143.mediawiki
+++ b/bip-0143.mediawiki
@@ -19,7 +19,7 @@ Unfortunately, there are at least 2 weaknesses in the original transaction diges
 * For the verification of each signature, the amount of data hashing is proportional to the size of the transaction. Therefore, data hashing grows in O(n2) as the number of sigops in a transaction increases. While a 1 MB block would normally take 2 seconds to verify with an average computer in 2015, a 1MB transaction with 5569 sigops may take 25 seconds to verify. This could be fixed by optimizing the digest algorithm by introducing some reusable “midstate”, so the time complexity becomes O(n). [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2013-2292 CVE-2013-2292][https://bitcointalk.org/?topic=140078 New Bitcoin vulnerability: A transaction that takes at least 3 minutes to verify][http://rusty.ozlabs.org/?p=522 The Megatransaction: Why Does It Take 25 Seconds?]
 * The algorithm does not involve the amount of Bitcoin being spent by the input. This is usually not a problem for online network nodes as they could request for the specified transaction to acquire the output value. For an offline transaction signing device ("cold wallet"), however, the unknowing of input amount makes it impossible to calculate the exact amount being spent and the transaction fee. To cope with this problem a cold wallet must also acquire the full transaction being spent, which could be a big obstacle in the implementation of lightweight, air-gapped wallet. By including the input value of part of the transaction digest, a cold wallet may safely sign a transaction by learning the value from an untrusted source. In the case that a wrong value is provided and signed, the signature would be invalid and no funding might be lost. [https://bitcointalk.org/index.php?topic=181734.0 SIGHASH_WITHINPUTVALUE: Super-lightweight HW wallets and offline data]
 
-Deploying the aforementioned fixes in the original script system is not a simple task. That would be either a hardfork, or a softfork for new sigops without the ability to remove or insert stack items. However, the introduction of segregated witness softfork offers an opportunity to define a different set of script semantics without disrupting the original system, as the unupgraded nodes would always consider such a transaction output is spendable by arbitrary signature or no signature at all. [https://github.com/CodeShark/bips/blob/segwit/bip-codeshark-jl2012-segwit.mediawiki BIPx: Segregated Witness (Consensus layer)]
+Deploying the aforementioned fixes in the original script system is not a simple task. That would be either a hardfork, or a softfork for new sigops without the ability to remove or insert stack items. However, the introduction of segregated witness softfork offers an opportunity to define a different set of script semantics without disrupting the original system, as the unupgraded nodes would always consider such a transaction output is spendable by arbitrary signature or no signature at all. [https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki BIP141: Segregated Witness (Consensus layer)]
 
 == Specification ==
 A new transaction digest algorithm is defined, but only applicable to sigops in version 0 and version 1 witness program:
@@ -114,7 +114,7 @@ Refer to the reference implementation, reproduced below, for the precise algorit
 
 == Deployment ==
 
-This proposal is deployed with Segregated Witness softfork (BIP x) 
+This proposal is deployed with Segregated Witness softfork (BIP 141) 
 
 == Backward compatibility ==
 
@@ -122,7 +122,7 @@ As a soft fork, older software will continue to operate without modification. No
 
 == Reference Implementation ==
 
-https://github.com/sipa/bitcoin/commits/segwit
+https://github.com/sipa/bitcoin/commits/segwit2
 
 == References ==
 
diff --git a/bip-0144.mediawiki b/bip-0144.mediawiki
index ed8cf2be..e3843a8f 100644
--- a/bip-0144.mediawiki
+++ b/bip-0144.mediawiki
@@ -12,7 +12,7 @@
 This BIP defines new messages and serialization formats for propagation of transactions and blocks committing to segregated witness structures.
 
 ==Motivation==
-In addition to defining witness structures and requiring commitments in future blocks (BIPxxxx - Consensus segwit BIP), new mechanisms must be defined to allow peers to advertise support for segregated witness and to relay the witness structures and request them from other peers without breaking compatibility with older nodes.
+In addition to defining witness structures and requiring commitments in future blocks ([https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki BIP141] - Consensus segwit BIP), new mechanisms must be defined to allow peers to advertise support for segregated witness and to relay the witness structures and request them from other peers without breaking compatibility with older nodes.
 
 ==Specification==
 

From 63fcb73ab7a9e005ec996e2bd87631fc56655fbd Mon Sep 17 00:00:00 2001
From: Dr Washington Sanchez 
Date: Tue, 12 Jan 2016 13:37:03 +1000
Subject: [PATCH 135/259] Fixes

- Spelling mistakes
- Change in the deployment model
- Corrected my acknowledgement to Austin 'Williams'
---
 bip-0107.mediawiki | 16 ++++++++--------
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/bip-0107.mediawiki b/bip-0107.mediawiki
index 88a2c990..4e96173a 100644
--- a/bip-0107.mediawiki
+++ b/bip-0107.mediawiki
@@ -16,11 +16,11 @@ This BIP proposes a dynamic limit to the block size based on transaction volume.
 Over the next few years, large infrastructure investments will be made into:
 
 # Improving global network connectivity
-# Improving block propogation across the Bitcoin network
+# Improving block propagation across the Bitcoin network
 # Layer 2 services and networks for off-chain transactions
 # General efficiency improvements to transactions and the blockchain
 
-* While there is a consensus between Bitcoin developers, miners, businesses and users that the block size needs to be increased, there is a lingering concern over the potential unintended consequences that may agument the trend towards network and mining centralization (largely driven by mining hardware such as ASICs) and thereby threaten the security of the network. 
+* While there is a consensus between Bitcoin developers, miners, businesses and users that the block size needs to be increased, there is a lingering concern over the potential unintended consequences that may augment the trend towards network and mining centralization (largely driven by mining hardware such as ASICs) and thereby threaten the security of the network. 
 * In contrast, failing to respond to elevated on-chain transaction volume may lead to a consumer-failure of Bitcoin, where ordinary users - having enjoyed over 6 years of submitting transactions on-chain at relatively low cost - will be priced out of blockchain with the emergence of a prohibitive 'fee market'.
 * These two concerns must be delicately balanced so that all users can benefit from a robust, scalable, and neutral network.
 
@@ -44,7 +44,7 @@ Over the next few years, large infrastructure investments will be made into:
 ** limitfreerelay also helps counter attempts to trigger a block size increase by 'penny-flooding'
 
 For example:
-* When the dynamic rules for increasing the block size go live on January 1st 2020, the starting maximum block size wil be 6 MB
+* When the dynamic rules for increasing the block size go live on January 1st 2020, the starting maximum block size will be 6 MB
 * IF >=3025 blocks are >= 3.6 MB, the new maximum block size become 6.6 MB. 
 * The theoretical maximum block size at the end of 2020 would be ~20.7 MB, assuming all 13 increases are triggered every 4 weeks by the end of the year. 
 
@@ -59,7 +59,7 @@ For example:
 *** Setting the parameter too high may set the trigger sensitivity too low, causing transaction delays that are trying to be avoided in the first place
 *** Between September 2013-2015, the standard deviation measured from average block size (n=730 data points from blockchain.info) was ~ 0.13 MB or 13% of the maximum block size
 **** If blocks needed to be 90% full before an increase were triggered, normal variance in the average block size would mean some blocks would be full before an increase could be triggered
-*** Therefore, we need a ''safe distance'' away from the maximum block size to avoid normal block size variance hitting the limit. The 60% level represents a 3 standard deviation distrance from the limit. 
+*** Therefore, we need a ''safe distance'' away from the maximum block size to avoid normal block size variance hitting the limit. The 60% level represents a 3 standard deviation distance from the limit. 
 ** Why 3025 blocks?
 *** The assessment period is 4032 blocks or ~ 4 weeks, with the threshold set as 4032 blocks/0.75 + 1
 *** Increases in the maximum block size should only occur after a sustained trend can be observed in order to:
@@ -67,16 +67,16 @@ For example:
 ***# Increase the cost to trigger an increase by spam attacks or miner collusion with zero fee transactions   
 *** In other words, increases to the maximum block size must be conservative but meaningful to relieve transaction volume pressure in response to true market demand
 ** Why 10% increase in the block size?
-*** Increases in the block size are designed to be conservative and in balance with the number of theoretical opportunitites to increase the block size per year
+*** Increases in the block size are designed to be conservative and in balance with the number of theoretical opportunities  to increase the block size per year
 *** Makes any resources spent for spam attacks or miner collusion relatively expensive to achieve a minor increase in the block size. A sustained attack would need to be launched that may be too costly, and ideally detectable by the community 
 
 ==Deployment==
-''From BIP66:''
-We reuse the double-threshold switchover mechanism from BIP 34, with the same thresholds, but for nVersion = ''n''. The new rules are in effect for every block (at height H) with nVersion = ''n'' and at least 750 out of 1000 blocks preceding it (with heights H-1000..H-1) also have nVersion = ''n''. Furthermore, when 950 out of the 1000 blocks preceding a block do have nVersion = ''n'', nVersion = ''n-1'' blocks become invalid, and all further blocks enforce the new rules.
+Similar deployment model to BIP101:  
+
Activation is achieved when 750 of 1,000 consecutive blocks in the best chain have a version number with the first, second, third, and thirtieth bits set (0x20000007 in hex). The activation time will be the timestamp of the 750'th block plus a two week (1,209,600 second) grace period to give any remaining miners or services time to upgrade to support larger blocks.

 
 ==Acknowledgements==
 
-Thanks to Austin Hill, Brian Hoffman, Angel Leon, Bulukani Mlalazi, Chris Pacia, and Ryan Shea for their comments.
+Thanks to Austin Williams, Brian Hoffman, Angel Leon, Bulukani Mlalazi, Chris Pacia, and Ryan Shea for their comments.
 
 ==Copyright==
 

From 07b73c67dfa99cb13bf9e95dbbc3cad8d938936a Mon Sep 17 00:00:00 2001
From: Marco Pontello 
Date: Tue, 12 Jan 2016 16:46:52 +0100
Subject: [PATCH 136/259] added ABNF grammar

---
 bip-0122.mediawiki | 14 +++++++++++++-
 1 file changed, 13 insertions(+), 1 deletion(-)

diff --git a/bip-0122.mediawiki b/bip-0122.mediawiki
index 902aa02a..d0258738 100644
--- a/bip-0122.mediawiki
+++ b/bip-0122.mediawiki
@@ -23,7 +23,7 @@ The same happens with posts and messages that reference some particular txs or b
 
 The URI follow this form:
 
- blockchain:[//chain]
+ blockchain:[//]//
 
 Where:
 
@@ -52,6 +52,18 @@ Where:
 | 
 |}
 
+====ABNF grammar====
+
+
+blockchainuri = "blockchain:" ["//" chain] "/" object
+object = ("tx" "/" hash ) / ( "block" "/" (hash / blockheight ) ) /
+         ( "address" "/" address )
+chain = hash
+hash = 64HEXDIG
+blockheight = 1*15DIGIT ; 15 is somehow arbitrary, i.e. a "small" int.
+address = base58 ; https://en.wikipedia.org/wiki/Base58
+

+
 ----
 ===Definition of chain ID===
 

From 628a851062abbad73df8f48e3cd45dcffbdec914 Mon Sep 17 00:00:00 2001
From: MarcoPon 
Date: Tue, 12 Jan 2016 19:09:57 +0100
Subject: [PATCH 137/259] More consistent spacing.

---
 bip-0122.mediawiki | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/bip-0122.mediawiki b/bip-0122.mediawiki
index d0258738..d59e3537 100644
--- a/bip-0122.mediawiki
+++ b/bip-0122.mediawiki
@@ -56,8 +56,8 @@ Where:
 
 
 blockchainuri = "blockchain:" ["//" chain] "/" object
-object = ("tx" "/" hash ) / ( "block" "/" (hash / blockheight ) ) /
-         ( "address" "/" address )
+object = ("tx" "/" hash) / ("block" "/" (hash / blockheight)) /
+         ("address" "/" address)
 chain = hash
 hash = 64HEXDIG
 blockheight = 1*15DIGIT ; 15 is somehow arbitrary, i.e. a "small" int.
@@ -121,4 +121,4 @@ Thanks to Richard Moore, Matt Whitlock, Andreas Schildbach for suggestions about
 
 ==Copyright==
 
-This document is placed in the public domain.
\ No newline at end of file
+This document is placed in the public domain.

From a8ace6d608b2068ce949993d4dd048fd759820ce Mon Sep 17 00:00:00 2001
From: Eric Lombrozo 
Date: Tue, 12 Jan 2016 19:06:32 -0500
Subject: [PATCH 138/259] Added BIP 124

---
 README.mediawiki   |   6 +++
 bip-0124.mediawiki | 123 +++++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 129 insertions(+)
 create mode 100644 bip-0124.mediawiki

diff --git a/README.mediawiki b/README.mediawiki
index fdfb988d..d9d0e328 100644
--- a/README.mediawiki
+++ b/README.mediawiki
@@ -386,6 +386,12 @@ Those proposing changes should consider that ultimately consent may rest with th
 | Informational
 | Draft
 |-
+| [[bip-0124.mediawiki|124]]
+| Hierarchical Deterministic Script Templates
+| Eric Lombrozo, William Swanson
+| Informational
+| Draft
+|-
 | [[bip-0125.mediawiki|125]]
 | Opt-in Full Replace-by-Fee Signaling
 | David Harding, Peter Todd
diff --git a/bip-0124.mediawiki b/bip-0124.mediawiki
new file mode 100644
index 00000000..1c98db87
--- /dev/null
+++ b/bip-0124.mediawiki
@@ -0,0 +1,123 @@
+
+  BIP:     BIP-124
+  Title:   Hierarchical Deterministic Script Templates
+  Authors: Eric Lombrozo , William Swanson
+  Status:  Draft
+  Type:    Informational
+  Created: 2015-11-20
+
+  Post-History: http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-November/011795.html
+

+
+==Abstract==
+
+This BIP defines a script template format that can be used by wallets to deterministically generate scripts with specific authorization policies using the key derivation mechanism defined in BIP32.
+
+==Motivation==
+
+Currently existing wallets typically issue scripts in only a tiny handful of widely used formats. The most popular formats are pay-to-pubkey-hash and m-of-n pay-to-script-hash (BIP16). However, different wallets tend to use mutually incompatible derivation schemes to generate signing keys and construct scripts from them. Moreover, with the advent of hashlocked and timelocked contracts (BIP65, BIP112), it is necessary for different wallets to be able to cooperatively generate even more sophisticated scripts.
+
+In addition, there's a lot of ongoing work in the development of multilayered protocols that use the blockchain as a settlement layer (i.e. the Lightning Network). These efforts require sufficiently generalized templates to allow for rapidly evolving script designs.
+
+This BIP provides a generalized format for constructing a script template that guarantees that different wallets will all produce the same scripts for a given set of derivation paths according to BIP32.
+
+==Specification==
+
+===Keys===
+
+An individual key is determined by a BIP32 derivation path and an index. For convenience, we introduce the following notation:
+
+'''A'''k = (derivation path for A)/k
+
+===Key Groups===
+
+Let '''m'''i denote distinct BIP32 derivation paths. We define a key group of n keys as a set of key derivation paths with a free index k:
+
+{'''K'''k} = { '''m'''1/k, '''m'''2/k, '''m'''3/k, ..., '''m'''n/k }
+
+Key groups are useful for constructing scripts that are symmetric in a set of keys. Scripts are symmetric in a set of keys if the semantics of the script is unaffected by permutations of the keys. Key groups enforce a canonical form and can improve privacy.
+
+===Sorting===
+
+We define a lexicographic sorting of the keys. (TODO: specification of sorting conventions - compressed pubkeys, encoding, etc...)
+
+Define {'''K'''k}j to be the jth element of the sorted keys for derivation index k.
+
+===Script Templates===
+
+We construct script templates by inserting placeholders for data into a script. To denote a placeholder, we use the following notation:
+
+''Script''('''A''') = opcodes ['''A'''] opcodes
+
+We extend this notation to an arbitrary number of placeholders:
+
+''Script''('''X1''', '''X2''', ..., '''Xn''') = opcodes ['''X1'''] opcodes ['''X2'''] opcodes ... opcodes ['''Xn'''] opcodes
+
+We introduce the following convenient notation for sorted key groups:
+
+[{'''K'''k}] = [{'''K'''k}1] [{'''K'''k}2] ... [{'''K'''k}n]
+
+===Operations on Keys===
+
+In some applications, we might want to insert the result of some operation performed on a key rather than the key itself into the script. For example, we might want to insert a Hash160 of key '''A'''k. We can use the following notation:
+
+[''Hash160''('''A'''k)]
+
+===Encoding===
+
+TODO
+
+==Examples==
+
+===2-of-3 Multisig===
+
+The script template is defined by:
+
+''Script''('''X''') = 2 ['''X'''] 3 OP_CHECKMULTISIG
+
+Letting '''K'''k = { '''m'''1/k, '''m'''2/k, '''m'''3/k }, the ''k''th script for this key group is denoted by ''Script''({'''K'''k}).
+
+===1-of-1 or 2-of-3===
+
+The script template is defined by:
+
+''Script''('''A''', '''B''') = 

+        OP_DUP ['''A'''] OP_CHECKSIG

+        OP_NOTIF

+                2 ['''B'''] 3 OP_CHECKMULTISIGVERIFY 

+        OP_NOTIF

+        OP_ENDIF

+        OP_TRUE

+
+Let '''M'''k = '''m'''/k be a key of a superuser that can authorize all transactions and {'''K'''k} be a key group of three users that can only authorize transactions if at least two of them agree.
+
+The ''k''th script is given by ''Script''('''M'''k, {'''K'''k}).
+
+===Timelocked Contract===
+
+The output is payable to Alice immediately if she knows the private key for '''A'''k. Bob must know the private key for '''B'''k and also wait for a timeout '''t''' before being able to spend the output.
+
+The script template is defined by:
+
+''Script''('''A''', '''B''', '''T''') = 

+        OP_IF 

+                OP_DUP OP_HASH160 [''Hash160''('''A''')] OP_EQUALVERIFY OP_CHECKSIG 

+        OP_ELSE 

+                ['''T'''] OP_CHECKLOCKTIMEVERIFY OP_DROP 

+                OP_DUP OP_HASH160 [''Hash160''('''B''')] OP_EQUALVERIFY OP_CHECKSIG 

+        OP_ENDIF
+
+The ''k''th script with timeout '''t''' is given by ''Script''('''A'''k, '''B'''k, '''t''').
+
+==References==
+
+* [[bip-0016.mediawiki|BIP16 - Pay to Script Hash]]
+* [[bip-0032.mediawiki|BIP32 - Hierarchical Deterministic Wallets]]
+* [[bip-0065.mediawiki|BIP65 - OP_CHECKLOCKTIMEVERIFY]]
+* [[bip-0112.mediawiki|BIP112 - CHECKSEQUENCEVERIFY]]
+* [[https://lightning.network/lightning-network-paper.pdf|Lightning Network Whitepaper]]
+
+==Copyright==
+
+This document is placed in the public domain.
+

From fd6789cfc8674b1fd582dc7323b07abb2733b4e9 Mon Sep 17 00:00:00 2001
From: Eric Lombrozo 
Date: Tue, 12 Jan 2016 19:16:46 -0500
Subject: [PATCH 139/259] Added BIP 83

---
 README.mediawiki   |  6 +++
 bip-0083.mediawiki | 92 ++++++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 98 insertions(+)
 create mode 100644 bip-0083.mediawiki

diff --git a/README.mediawiki b/README.mediawiki
index fdfb988d..0df3d289 100644
--- a/README.mediawiki
+++ b/README.mediawiki
@@ -302,6 +302,12 @@ Those proposing changes should consider that ultimately consent may rest with th
 | Standard
 | Draft
 |-
+| [[bip-0083.mediawiki|83]]
+| Dynamic Hierarchical Deterministic Key Trees
+| Eric Lombrozo
+| Standard
+| Draft
+|-
 | [[bip-0099.mediawiki|99]]
 | Motivation and deployment of consensus rule changes ([soft/hard]forks)
 | Jorge Timón
diff --git a/bip-0083.mediawiki b/bip-0083.mediawiki
new file mode 100644
index 00000000..d1da6459
--- /dev/null
+++ b/bip-0083.mediawiki
@@ -0,0 +1,92 @@
+
+  BIP:     BIP-83
+  Title:   Dynamic Hierarchical Deterministic Key Trees
+  Author:  Eric Lombrozo 
+  Status:  Draft
+  Type:    Standard
+  Created: 2015-11-16
+

+
+==Abstract==
+
+This BIP defines a scheme for key derivation that allows for dynamic creation of key hierarchies based on the algorithm described in BIP32.
+
+==Motivation==
+
+Several proposals have been made to try to standardize a structure for hierarchical deterministic wallets for the sake of interoperability (reference BIP32, BIP44, BIP45). However, all proposals to date have tried to impose a specific structure upfront without providing any flexibility for dynamic creation of new hierarchical levels with different semantics or mapping between different applications that use distinct structures.
+
+Instead of attempting to impose a specific structure upfront, this BIP proposes that we design the derivation in such a way that we can continue extending hierarchies arbitrarily and indefinitely.
+
+==Specification==
+
+BIP32 provides a hierarchical derivation scheme where every node in the tree can be either used to derive child nodes or used as a signing key for ECDSA. This means that as soon as we choose to use a node as a signing key, we can no longer derive children from that node. To draw an analogy to file systems, each node is either a file or a directory but never both. However, given the need to predictably know the location of new children, it is generally not a good idea to mix both signing keys and parent nodes at the same level in the hierarchy. This means that as soon as we've decided that a particular level in the hierarchy is to be used for signing keys, we've lost the ability to nest deeper levels into the tree.
+
+At every level of the hierarchy, we reserve the child with index 0 to allow further nesting, and for signing key parent nodes use child indices 1 to MAX_INDEX (231 - 1) for signing keys. We can use either hardened or nonhardened derivation.
+
+Let p denote a specific signing key parent node and k be an index greater than 0. The children signing keys are then:
+
+p / k
+
+with k > 0.
+
+To create sublevels, we derive the nested nodes:
+
+p / 0 / n
+
+with n ≥ 0.
+
+Each of these nodes can now contain signing key children of their own, and again we reserve index 0 to allow deeper nesting.
+
+==Notation==
+
+We propose the following shorthand for writing nested node derivations:
+
+p // n instead of p / 0 / n
+
+p //' n instead of p / 0' / n
+
+==Mappings==
+
+Rather than specifying upfront which path is to be used for a specific purpose (i.e. external invoicing vs. internal change), different applications can specify arbitrary parent nodes and derivation paths. This allows for nesting of sublevels to arbitrary depth with application-specified semantics. Rather than trying to specify use cases upfront, we leave the design completely open-ended. Different applications can exchange these mappings for interoperability. Eventually, if certain mappings become popular, application user interfaces can provide convenient shortcuts or use them as defaults.
+
+Note that BIP32 suggests reserving child 0 for the derivation of signing keys rather than sublevels. It is not really necessary to reserve signing key parents, however, as each key's parent's path can be explicitly stated. But unless we reserve a child for sublevel derivation, we lose the ability to nest deeper levels into the hierarchy. While we could reserve any arbitrary index for nesting sublevels, reserving child 0 seems simplest to implement, leaving all indices > 0 for contiguously indexed signing keys. We could also use MAX_INDEX (231 - 1) for this purpose. However, we believe doing so introduces more ideosyncracies into the semantics and will present a problem if we ever decide to extend the scheme to use indices larger than 31 bits.
+
+==Use Cases==
+
+===Account Hierarchies===
+
+For all that follows, we assume that key indices k > 0 and parent node indices n ≥ 0.
+
+From a master seed m, we can construct a default account using the following derivations for nonhardened signing keys:
+
+m / 1 / k (for change/internal outputs)
+
+m / 2 / k (for invoice/external outputs)
+
+To create subaccount an, we use:
+
+an = m // n
+
+To generate keys for subaccount an, we use:
+
+an / 1 / k (for change/internal outputs)
+
+an / 2 / k (for invoice/external outputs)
+
+We can continue creating subaccounts indefinitely using this scheme.
+
+===Bidirectional Payment Channels===
+
+In order to create a bidirectional payment channel, it is necessary that previous commitments be revokable. In order to revoke previous commitments, each party reveals a secret to the other that would allow them to steal the funds in the channel if a transaction for a previous commitment is inserted into the blockchain.
+
+By allowing for arbitrary nesting of sublevels, we can construct decision trees of arbitrary depth and revoke an entire branch by revealing a parent node used to derive all the children. 
+
+==References==
+
+* [[bip-0032.mediawiki|BIP32 - Hierarchical Deterministic Wallets]]
+* [[https://lightning.network/lightning-network-paper.pdf|Lightning Network Whitepaper]]
+
+==Copyright==
+
+This document is placed in the public domain.
+

From 5574301656f61142e45540e33dbe88b397a89a93 Mon Sep 17 00:00:00 2001
From: Peter Todd 
Date: Wed, 13 Jan 2016 14:52:18 -0500
Subject: [PATCH 140/259] Remove merge-mining suggest re: witness nonce

---
 bip-0141.mediawiki | 7 +++----
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/bip-0141.mediawiki b/bip-0141.mediawiki
index 7a5c28c1..64742564 100644
--- a/bip-0141.mediawiki
+++ b/bip-0141.mediawiki
@@ -154,15 +154,14 @@ Comparing with the last example, the scriptPubKey is 11 bytes smaller (with redu
 
 === Extensible commitment structure ===
 
-The new commitment in coinbase transaction is a hash of the witness root hash and a witness nonce. The nonce which currently has no consensus meaning, serves two purposes:
+The new commitment in coinbase transaction is a hash of the witness root hash and a witness nonce. The nonce currently has no consensus meaning, but in the future allows new commitment values for future softforks. For example, if a new consensus-critical commitment is required in the future, the commitment in
+coinbase becomes:
 
-* It allows new commitment values for future softforks. For example, if a new consensus-critical commitment is required in the future, the commitment in coinbase becomes:
-  
   Double-SHA256(Witness root hash|Hash(new commitment|witness nonce))
 
 :: For backward compatibility, the Hash(new commitment|witness nonce) will go to the coinbase witness, and the witness nonce will be recorded in another location specified by the future softfork. Any number of new commitment could be added in this way.
 
-* Any commitments that are not consensus-critical to Bitcoin, such as merge-mining, may utilize this witness nonce. However, they must not be committed directly as the nonce, or the external system may be forced to hardfork when Bitcoin introduces more consensus-critical commitments. Instead, they should use the nonce as the root of an extensible commitment tree, and should not make any assumption about the location and depth of their commitments in the tree. For example, in the external system, it may use a flag to indicate the actual location of the commitments with the Merkle paths provided.
+Any commitments that are not consensus-critical to Bitcoin, such as merge-mining, MUST NOT use the witness nonce to preserve the ability to do upgrades of the Bitcoin consensus protocol.
 
 The optional data space following the commitment also leaves room for metadata of future softforks.
 

From d6dfcf167b8d568be2d671014ca7377356d1a74e Mon Sep 17 00:00:00 2001
From: BtcDrak 
Date: Fri, 15 Jan 2016 22:14:45 +0000
Subject: [PATCH 141/259] Update reference implementation for BIP68

---
 bip-0068.mediawiki | 279 ++++++++++++++++++++++++---------------------
 1 file changed, 150 insertions(+), 129 deletions(-)

diff --git a/bip-0068.mediawiki b/bip-0068.mediawiki
index 55905afc..e93d7488 100644
--- a/bip-0068.mediawiki
+++ b/bip-0068.mediawiki
@@ -49,139 +49,160 @@ The block produced time is equal to the median-time-past of its previous block.
 
 When the relative lock-time is block-based, it is interpreted as a minimum block-height constraint over the input's age. A relative block-based lock-time of zero indicates an input which can be included in any block. More generally, a relative block lock-time n can be included n blocks after the mining date of the output it is spending, or any block thereafter.
 
-This is proposed to be accomplished by replacing IsFinalTx() and CheckFinalTx(), existing consensus and non-consensus code functions that return true if a transaction's lock-time constraints are satisfied and false otherwise, with LockTime() and CheckLockTime(), new functions that return a non-zero value if a transaction's lock-time or sequence number constraints are not satisfied and zero otherwise:
-
-
-    enum {
-        /* Interpret sequence numbers as relative lock-time constraints. */
-        LOCKTIME_VERIFY_SEQUENCE = (1 << 0),
-    };
-    
-    /* Setting nSequence to this value for every input in a transaction
-     * disables nLockTime. */
-    static const uint32_t SEQUENCE_FINAL = 0xffffffff;
-    
-    /* If this flag set, CTxIn::nSequence is NOT interpreted as a
-     * relative lock-time. Setting the most significant bit of a
-     * sequence number disabled relative lock-time. */
-    static const uint32_t SEQUENCE_LOCKTIME_DISABLE_FLAG = (1 << 31);
-    
-    /* If CTxIn::nSequence encodes a relative lock-time and this flag
-     * is set, the relative lock-time has units of 512 seconds,
-     * otherwise it specifies blocks with a granularity of 1. */
-    static const uint32_t SEQUENCE_LOCKTIME_TYPE_FLAG = (1 << 22);
-    
-    /* If CTxIn::nSequence encodes a relative lock-time, this mask is
-     * applied to extract that lock-time from the sequence field. */
-    static const uint32_t SEQUENCE_LOCKTIME_MASK = 0x0000ffff;
-    
-    /* In order to use the same number of bits to encode roughly the
-     * same wall-clock duration, and because blocks are naturally
-     * limited to occur every 600s on average, the minimum granularity
-     * for time-based relative lock-time is fixed at 512 seconds.
-     * Converting from CTxIn::nSequence to seconds is performed by
-     * multiplying by 512 = 2^9, or equivalently shifting up by
-     * 9 bits. */
-    static const int SEQUENCE_LOCKTIME_GRANULARITY = 9;
-    
-    int64_t LockTime(const CTransaction &tx, int flags, const std::vector* prevHeights, const CBlockIndex& block)
-    {
-        assert(prevHeights == NULL || prevHeights->size() == tx.vin.size());
-        int64_t nBlockTime = (flags & LOCKTIME_MEDIAN_TIME_PAST)
-                                        ? block.GetAncestor(std::max(block.nHeight-1, 0))->GetMedianTimePast()
-                                        : block.GetBlockTime();
-
-        bool fEnforceBIP68 = static_cast(tx.nVersion) >= 2
-                          && flags & LOCKTIME_VERIFY_SEQUENCE;
-        
-        // Will be set to the equivalent height- and time-based nLockTime
-        // values that would be necessary to satisfy all relative lock-
-        // time constraints given our view of block chain history.
-        int nMinHeight = 0;
-        int64_t nMinTime = 0;
-        // Will remain equal to true if all inputs are finalized
-        // (CTxIn::SEQUENCE_FINAL).
-        bool fFinalized = true;
-        for (size_t txinIndex = 0; txinIndex < tx.vin.size(); txinIndex++) {
-            const CTxIn& txin = tx.vin[txinIndex];
-            // Set a flag if we witness an input that isn't finalized.
-            if (txin.nSequence == CTxIn::SEQUENCE_FINAL)
-                continue;
-            else
-                fFinalized = false;
-    
-            // Do not enforce sequence numbers as a relative lock time
-            // unless we have been instructed to, and a view has been
-            // provided.
-            if (!fEnforceBIP68)
-                continue;
-    
-            // Sequence numbers with the most significant bit set are not
-            // treated as relative lock-times, nor are they given any
-            // consensus-enforced meaning at this point.
-            if (txin.nSequence & CTxIn::SEQUENCE_LOCKTIME_DISABLE_FLAG)
-                continue;
-    
-            if (prevHeights == NULL)
-                continue;
-        
-            int nCoinHeight = (*prevHeights)[txinIndex];
-        
-            if (txin.nSequence & CTxIn::SEQUENCE_LOCKTIME_TYPE_FLAG) {
-            
-                int64_t nCoinTime = block.GetAncestor(std::max(nCoinHeight-1, 0))->GetMedianTimePast();
-            
-                // Time-based relative lock-times are measured from the
-                // smallest allowed timestamp of the block containing the
-                // txout being spent, which is the median time past of the
-                // block prior.
-                nMinTime = std::max(nMinTime, nCoinTime + (int64_t)((txin.nSequence & CTxIn::SEQUENCE_LOCKTIME_MASK) << CTxIn::SEQUENCE_LOCKTIME_GRANULARITY) - 1);
-            } else {
-                // We subtract 1 from relative lock-times because a lock-
-                // time of 0 has the semantics of "same block," so a lock-
-                // time of 1 should mean "next block," but nLockTime has
-                // the semantics of "last invalid block height."
-                nMinHeight = std::max(nMinHeight, nCoinHeight + (int)(txin.nSequence & CTxIn::SEQUENCE_LOCKTIME_MASK) - 1);
-            }
-        }
-    
-        // If all sequence numbers are CTxIn::SEQUENCE_FINAL, the
-        // transaction is considered final and nLockTime constraints
-        // are not enforced.
-        if (fFinalized)
-            return 0;
-
-        if ((int64_t)tx.nLockTime < LOCKTIME_THRESHOLD)
-            nMinHeight = std::max(nMinHeight, (int)tx.nLockTime);
-        else
-            nMinTime = std::max(nMinTime, (int64_t)tx.nLockTime);
-    
-        if (nMinHeight >= block.nHeight)
-            return nMinHeight;
-            
-        if (nMinTime >= nBlockTime)
-            return nMinTime;
-    
-        return 0;
-    }

-
-Code conditional on the return value of IsFinalTx() / CheckLockTime() has to be updated as well, since the semantics of the return value has been inverted.
-
-==Example: Bidirectional payment channel==
-
-A bidirectional payment channel can be established by two parties funding a single output in the following way: Alice funds a 1 BTC output which is the 2-of-2 multisig of Alice AND Bob, or Alice's key only after a sufficiently long timeout, e.g. 30 days or 4320 blocks. The channel-generating transaction is signed by Alice and broadcast to the network.
-
-Alice desires to send Bob a payment of 0.1 BTC. She does so by constructing a transaction spending the 1 BTC output and sending 0.1 BTC to Bob and 0.9 BTC back to herself. She provides her signature for the 2-of-2 multisig constraint, and sets a relative lock-time using the sequence number field such that the transaction will become valid 24-hours or 144 blocks before the refund timeout. Two more times Alice sends Bob a payment of 0.1 BTC, each time generating and signing her half of a transaction spending the 1btc output and sending 0.2 BTC, then 0.3 BTC to Bob with a relative lock-time of 29 days from creation of the channel.
-
-Bob now desires to send Alice a refund of 0.25 BTC. He does so by constructing a transaction spending the 1btc output and sending 0.95 BTC (= 0.7 BTC + 0.25 BTC) to Alice and 0.05 BTC to himself. Since Bob will still have in his logs the transaction giving him 0.7 BTC 29 days after the creation of the channel, Alice demands that this new transaction have a relative lock-time of 28 days so she has a full day to broadcast it before the next transaction matures.
-
-Alice and Bob continue to make payments to each other, decrementing the relative lock-time by one day each time the channel switches direction, until the present time is reached or either party desires to close out the channel. A close-out is performed by finalizing the input (nSequence = MAX_INT) and both parties signing.
-
 ==Implementation==
 
 A reference implementation is provided by the following pull request
 
-https://github.com/bitcoin/bitcoin/pull/6312
+https://github.com/bitcoin/bitcoin/pull/7184
+
+
+enum {
+    /* Interpret sequence numbers as relative lock-time constraints. */
+    LOCKTIME_VERIFY_SEQUENCE = (1 << 0),
+};
+    
+/* Setting nSequence to this value for every input in a transaction
+ * disables nLockTime. */
+static const uint32_t SEQUENCE_FINAL = 0xffffffff;
+    
+/* If this flag set, CTxIn::nSequence is NOT interpreted as a
+ * relative lock-time. Setting the most significant bit of a
+ * sequence number disabled relative lock-time. */
+static const uint32_t SEQUENCE_LOCKTIME_DISABLE_FLAG = (1 << 31);
+    
+/* If CTxIn::nSequence encodes a relative lock-time and this flag
+ * is set, the relative lock-time has units of 512 seconds,
+ * otherwise it specifies blocks with a granularity of 1. */
+static const uint32_t SEQUENCE_LOCKTIME_TYPE_FLAG = (1 << 22);
+    
+/* If CTxIn::nSequence encodes a relative lock-time, this mask is
+ * applied to extract that lock-time from the sequence field. */
+static const uint32_t SEQUENCE_LOCKTIME_MASK = 0x0000ffff;
+    
+/* In order to use the same number of bits to encode roughly the
+ * same wall-clock duration, and because blocks are naturally
+ * limited to occur every 600s on average, the minimum granularity
+ * for time-based relative lock-time is fixed at 512 seconds.
+ * Converting from CTxIn::nSequence to seconds is performed by
+ * multiplying by 512 = 2^9, or equivalently shifting up by
+ * 9 bits. */
+static const int SEQUENCE_LOCKTIME_GRANULARITY = 9;
+    
+/**
+ * Calculates the block height and time which the transaction must be later than
+ * in order to be considered final in the context of BIP 68.  It also removes
+ * from the vector of input heights any entries which did not correspond to sequence
+ * locked inputs as they do not affect the calculation.
+ */
+static std::pair CalculateSequenceLocks(const CTransaction &tx, int flags, std::vector* prevHeights, const CBlockIndex& block)
+{
+    assert(prevHeights->size() == tx.vin.size());
+
+    // Will be set to the equivalent height- and time-based nLockTime
+    // values that would be necessary to satisfy all relative lock-
+    // time constraints given our view of block chain history.
+    // The semantics of nLockTime are the last invalid height/time, so
+    // use -1 to have the effect of any height or time being valid.
+    int nMinHeight = -1;
+    int64_t nMinTime = -1;
+
+    // tx.nVersion is signed integer so requires cast to unsigned otherwise
+    // we would be doing a signed comparison and half the range of nVersion
+    // wouldn't support BIP 68.
+    bool fEnforceBIP68 = static_cast(tx.nVersion) >= 2
+                      && flags & LOCKTIME_VERIFY_SEQUENCE;
+
+    // Do not enforce sequence numbers as a relative lock time
+    // unless we have been instructed to
+    if (!fEnforceBIP68) {
+        return std::make_pair(nMinHeight, nMinTime);
+    }
+
+    for (size_t txinIndex = 0; txinIndex < tx.vin.size(); txinIndex++) {
+        const CTxIn& txin = tx.vin[txinIndex];
+
+        // Sequence numbers with the most significant bit set are not
+        // treated as relative lock-times, nor are they given any
+        // consensus-enforced meaning at this point.
+        if (txin.nSequence & CTxIn::SEQUENCE_LOCKTIME_DISABLE_FLAG) {
+            // The height of this input is not relevant for sequence locks
+            (*prevHeights)[txinIndex] = 0;
+            continue;
+        }
+
+        int nCoinHeight = (*prevHeights)[txinIndex];
+
+        if (txin.nSequence & CTxIn::SEQUENCE_LOCKTIME_TYPE_FLAG) {
+            int64_t nCoinTime = block.GetAncestor(std::max(nCoinHeight-1, 0))->GetMedianTimePast();
+
+            // Time-based relative lock-times are measured from the
+            // smallest allowed timestamp of the block containing the
+            // txout being spent, which is the median time past of the
+            // block prior.
+            nMinTime = std::max(nMinTime, nCoinTime + (int64_t)((txin.nSequence & CTxIn::SEQUENCE_LOCKTIME_MASK) << CTxIn::SEQUENCE_LOCKTIME_GRANULARITY) - 1);
+        } else {
+            // We subtract 1 from relative lock-times because a lock-
+            // time of 0 has the semantics of "same block," so a lock-
+            // time of 1 should mean "next block," but nLockTime has
+            // the semantics of "last invalid block height."
+            nMinHeight = std::max(nMinHeight, nCoinHeight + (int)(txin.nSequence & CTxIn::SEQUENCE_LOCKTIME_MASK) - 1);
+        }
+    }
+
+    return std::make_pair(nMinHeight, nMinTime);
+}
+
+static bool EvaluateSequenceLocks(const CBlockIndex& block, std::pair lockPair)
+{
+    int64_t nBlockTime = block.pprev ? block.pprev->GetMedianTimePast() : 0;
+    if (lockPair.first >= block.nHeight || lockPair.second >= nBlockTime)
+        return false;
+
+    return true;
+}
+
+bool SequenceLocks(const CTransaction &tx, int flags, std::vector* prevHeights, const CBlockIndex& block)
+{
+    return EvaluateSequenceLocks(block, CalculateSequenceLocks(tx, flags, prevHeights, block));
+}
+
+bool CheckSequenceLocks(const CTransaction &tx, int flags)
+{
+    AssertLockHeld(cs_main);
+
+    CBlockIndex* tip = chainActive.Tip();
+    CBlockIndex index;
+    index.pprev = tip;
+    // CheckSequenceLocks() uses chainActive.Height()+1 to evaluate
+    // height based locks because when SequenceLocks() is called within
+    // CBlock::AcceptBlock(), the height of the block *being*
+    // evaluated is what is used. Thus if we want to know if a
+    // transaction can be part of the *next* block, we need to call
+    // SequenceLocks() with one more than chainActive.Height().
+    index.nHeight = tip->nHeight + 1;
+
+    // pcoinsTip contains the UTXO set for chainActive.Tip()
+    CCoinsViewMemPool viewMemPool(pcoinsTip, mempool);
+    std::vector prevheights;
+    prevheights.resize(tx.vin.size());
+    for (size_t txinIndex = 0; txinIndex < tx.vin.size(); txinIndex++) {
+        const CTxIn& txin = tx.vin[txinIndex];
+        CCoins coins;
+        if (!viewMemPool.GetCoins(txin.prevout.hash, coins)) {
+            return  error("%s: Missing input", __func__);
+        }
+        if (coins.nHeight == MEMPOOL_HEIGHT) {
+            // Assume all mempool transaction confirm in the next block
+            prevheights[txinIndex] = tip->nHeight + 1;
+        } else {
+            prevheights[txinIndex] = coins.nHeight;
+        }
+    }
+
+    std::pair lockPair = CalculateSequenceLocks(tx, flags, &prevheights, index);
+    return EvaluateSequenceLocks(index, lockPair);
+}
+

 
 ==Acknowledgments==
 

From 752e73c4205c981951df3feb7a7ed23eb3d5ef8b Mon Sep 17 00:00:00 2001
From: Chris Priest 
Date: Sat, 16 Jan 2016 08:02:18 -0800
Subject: [PATCH 142/259] added copyright

---
 bip-coalesce-wildcard.mediawiki | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/bip-coalesce-wildcard.mediawiki b/bip-coalesce-wildcard.mediawiki
index c729d069..4c3a557a 100644
--- a/bip-coalesce-wildcard.mediawiki
+++ b/bip-coalesce-wildcard.mediawiki
@@ -76,3 +76,7 @@ then the UTXO has been spent and the transaction is invalid.
 the user when their wallet contains many UTXOs that qualify it to benefit from
 a coalescing transaction. Wallets should not simply replace non-coalescing transactions
 with coalescing transactions in all instances.
+
+==Copyright==
+
+This document is placed in the public domain.

From ea49ecb4fbf05b5f9dec3d79cbea47fa35ed27dc Mon Sep 17 00:00:00 2001
From: Johnson Lau 
Date: Thu, 14 Jan 2016 12:38:17 +0800
Subject: [PATCH 143/259] New witness program definition

---
 bip-0141.mediawiki | 86 ++++++++++++++++++++++++----------------------
 1 file changed, 44 insertions(+), 42 deletions(-)

diff --git a/bip-0141.mediawiki b/bip-0141.mediawiki
index 7a5c28c1..a12151b5 100644
--- a/bip-0141.mediawiki
+++ b/bip-0141.mediawiki
@@ -61,18 +61,22 @@ New rules for scriptSig:
 * In case the scriptPubKey pushes a version byte and witness program directly, the scriptSig must be exactly empty.
 * In case the redeemScript pushes a version byte and witness program, the scriptSig must be exactly the single push of the redeemScript.
 
-If the version byte is 0, the witness program is the actual script:
-* The script is executed after normal script evaluation but with data from the witness rather than the scriptSig.
-* The program must not fail and must result in exactly a single TRUE on the stack.
+If the version byte is 0, and the witness program is 20 bytes,
+* It is interpreted as a pay-to-witness-public-key-hash (P2WPKH) program.
+* The witness must consist of exactly 2 items. The first one is a signature, and the second one is a public key.
+* HASH160 of the public key must match the 20-byte witness program.
+* After normal script evaluation, the signature is verified against the public key with CHECKSIG operation. The verification must result in a single TRUE on the stack.
 
-If the version byte is 1, the witness program must be 32 bytes, as a SHA256 hash of the actual script:
-* The witness must consist of an input stack to feed to the program, followed by the serialized program.
-* The serialized program is popped off the initial witness stack. SHA256 of the serialized program must match the hash pushed in the witness program.
-* The serialized program is deserialized, and executed after normal script evaluation with the remaining witness stack.
+If the version byte is 0, and the witness program is 32 bytes,
+* It is interpreted as a pay-to-witness-script-hash (P2WSH) program.
+* The witness must consist of an input stack to feed to the script, followed by a serialized script.
+* The serialized script is popped off the initial witness stack. SHA256 of the serialized script must match the 32-byte witness program.
+* The serialized script is deserialized, and executed after normal script evaluation with the remaining witness stack.
 * The script must not fail, and result in exactly a single TRUE on the stack.
-* If the witness program is between 2 and 31 bytes, the script must fail.
 
-If the version byte is 2 to 16, no further interpretation of the witness program or witness happens.
+If the version byte is 0, but the witness program is neither 20 nor 32 bytes, the script must fail.
+
+If the version byte is 1 to 16, no further interpretation of the witness program or witness happens.
 
 === Other consensus critical limits ===
 
@@ -94,35 +98,33 @@ The new rule is total ''sigop cost'' ≤ 80,000.
 
 == Examples ==
 
-=== Version 0 witness program ===
+=== P2WPKH witness program ===
 
-The following example is a version 0 witness program, equivalent to the existing Pay-to-Pubkey-Hash (P2PKH) output.
+The following example is a version 0 pay-to-witness-public-key-hash (P2WPKH) witness program:
 
     witness:       
     scriptSig:    (empty)
-    scriptPubKey: 0  EQUALVERIFY CHECKSIG>
-                  (0x001976A914{20-byte-hash}88AC)
+    scriptPubKey: 0 <20-byte-hash>
+                  (0x0014{20-byte-hash})
 
-The '0' indicates the following push is a version 0 witness program. The witness program is deserialized and becomes:
+The '0' in scriptPubKey indicates the following push is a version 0 witness program. The length of the witness program indicates that it is a P2WPKH type. The witness must consist of exactly 2 items. The HASH160 of the pubkey in witness must match the witness program.
 
-    DUP HASH160 <20-byte-hash> EQUALVERIFY CHECKSIG
+The signature is verified as
 
-The script is executed with the data from witness
+      CHECKSIG
 
-      DUP HASH160 <20-byte-hash> EQUALVERIFY CHECKSIG
+Comparing with a traditional P2PKH output, the P2WPKH equivalent occupies 3 less bytes in the scriptPubKey, and moves the signature and public key from scriptSig to witness.
 
-Comparing with a P2PKH output, the witness program equivalent occupies 2 more bytes in the scriptPubKey, while moving the signature and public key from scriptSig to witness.
+=== P2WSH witness program ===
 
-=== Version 1 witness program ===
-
-The following example is an 1-of-2 multi-signature version 1 witness program.
+The following example is an 1-of-2 multi-signature version 0 pay-to-witness-script-hash (P2WSH) witness program.
 
     witness:      0  <1   2 CHECKMULTISIG>
     scriptSig:    (empty)
-    scriptPubKey: 1 <32-byte-hash>
-                  (0x5120{32-byte-hash})
+    scriptPubKey: 0 <32-byte-hash>
+                  (0x0020{32-byte-hash})
 
-The '1' in scriptPubKey indicates the following push is a version 1 witness program. The last item in the witness is popped off, hashed with SHA256, compared against the 32-byte-hash in scriptPubKey, and deserialized:
+The '0' in scriptPubKey indicates the following push is a version 0 witness program. The length of the witness program indicates that it is a P2WSH type. The last item in the witness is popped off, hashed with SHA256, compared against the 32-byte-hash in scriptPubKey, and deserialized:
 
     1   2 CHECKMULTISIG
 
@@ -130,27 +132,27 @@ The script is executed with the remaining data from witness:
 
     0  1   2 CHECKMULTISIG
 
-Since the actual program is larger than 32 bytes, it cannot be accommodated in a version 0 witness program. A version 1 witness program allows arbitrarily large script as the 520-byte push limit is bypassed.
+A P2WSH witness program allows arbitrarily large script as the 520-byte push limit is bypassed.
 
-The scriptPubKey occupies 34 bytes, as opposed to 23 bytes of P2SH. The increased size improves security against possible collision attacks, as 280 work is not infeasible anymore (By the end of 2015, 284 hashes have been calculated in Bitcoin mining since the creation of Bitcoin). The spending script is same as the one for an equivalent P2SH output but is moved to witness.
+The scriptPubKey occupies 34 bytes, as opposed to 23 bytes of BIP16 P2SH. The increased size improves security against possible collision attacks, as 280 work is not infeasible anymore (By the end of 2015, 284 hashes have been calculated in Bitcoin mining since the creation of Bitcoin). The spending script is same as the one for an equivalent BIP16 P2SH output but is moved to witness.
 
-=== Witness program nested in Pay-to-Script-Hash ===
+=== Witness program nested in BIP16 P2SH ===
 
-The following example is the same 1-of-2 multi-signature version 1 witness program, but nested in a P2SH output.
+The following example is the same 1-of-2 multi-signature P2WSH witness program, but nested in a BIP16 P2SH output.
 
     witness:      0  <1   2 CHECKMULTISIG>
-    scriptSig:    <1 <32-byte-hash>>
-                  (5120{32-byte-hash})
+    scriptSig:    <0 <32-byte-hash>>
+                  (0x0020{32-byte-hash})
     scriptPubKey: HASH160 <20-byte-hash> EQUAL
-                  (0x76A914{20-byte-hash}88AC)
+                  (0xA914{20-byte-hash}87)
 
 The only item in scriptSig is hashed with HASH160, compared against the 20-byte-hash in scriptPubKey, and interpreted as:
 
-    1 <32-byte-hash>
+    0 <32-byte-hash>
 
-The version 1 witness program is then executed as described in the last example
+The P2WSH witness program is then executed as described in the previous example
 
-Comparing with the last example, the scriptPubKey is 11 bytes smaller (with reduced security) while witness is the same. However, it also requires 35 bytes in scriptSig, which is not prunable in transmission. Although a nested witness program is less efficient in many ways, its payment address is fully transparent and backward compatible for all Bitcoin reference client since version 0.6.0.
+Comparing with the previous example, the scriptPubKey is 11 bytes smaller (with reduced security) while witness is the same. However, it also requires 35 bytes in scriptSig, which is not prunable in transmission. Although a nested witness program is less efficient in many ways, its payment address is fully transparent and backward compatible for all Bitcoin reference client since version 0.6.0.
 
 === Extensible commitment structure ===
 
@@ -160,11 +162,11 @@ The new commitment in coinbase transaction is a hash of the witness root hash an
   
   Double-SHA256(Witness root hash|Hash(new commitment|witness nonce))
 
-:: For backward compatibility, the Hash(new commitment|witness nonce) will go to the coinbase witness, and the witness nonce will be recorded in another location specified by the future softfork. Any number of new commitment could be added in this way.
+For backward compatibility, the Hash(new commitment|witness nonce) will go to the coinbase witness, and the witness nonce will be recorded in another location specified by the future softfork. Any number of new commitment could be added in this way.
 
 * Any commitments that are not consensus-critical to Bitcoin, such as merge-mining, may utilize this witness nonce. However, they must not be committed directly as the nonce, or the external system may be forced to hardfork when Bitcoin introduces more consensus-critical commitments. Instead, they should use the nonce as the root of an extensible commitment tree, and should not make any assumption about the location and depth of their commitments in the tree. For example, in the external system, it may use a flag to indicate the actual location of the commitments with the Merkle paths provided.
 
-The optional data space following the commitment also leaves room for metadata of future softforks.
+The optional data space following the commitment also leaves room for metadata of future softforks, and MUST NOT be used for other purpose.
 
 === Trust-free unconfirmed transaction dependency chain ===
 
@@ -211,7 +213,7 @@ With a soft fork, it is possible to introduce a separate witness structure to al
 
 == Backward compatibility ==
 
-As a soft fork, older software will continue to operate without modification.  Non-upgraded nodes, however, will not see nor validate the witness data and will consider all witness programs as anyone-can-spend scripts (except a few edge cases in version 0 witness programs which are provably unspendable with original script semantics). Wallets should always be wary of anyone-can-spend scripts and treat them with suspicion. Non-upgraded nodes are strongly encouraged to upgrade in order to take advantage of the new features.
+As a soft fork, older software will continue to operate without modification.  Non-upgraded nodes, however, will not see nor validate the witness data and will consider all witness programs as anyone-can-spend scripts (except a few edge cases where the witness programs are equal to 0, which the script must fail). Wallets should always be wary of anyone-can-spend scripts and treat them with suspicion. Non-upgraded nodes are strongly encouraged to upgrade in order to take advantage of the new features.
 
 '''What a non-upgraded wallet can do'''
 
@@ -253,14 +255,14 @@ Special thanks to Gregory Maxwell for originating many of the ideas in this BIP
 
 == Reference Implementation ==
 
-https://github.com/sipa/bitcoin/commits/segwit2
+https://github.com/sipa/bitcoin/commits/segwit3
 
 == References ==
 
-*[https://github.com/bitcoin/bips/blob/master/bip-0016.mediawiki BIP16 Pay to Script Hash]
-*[https://github.com/bitcoin/bips/blob/master/bip-0142.mediawiki BIP142 Address Formats for Witness Program]
-*[https://github.com/bitcoin/bips/blob/master/bip-0143.mediawiki BIP143 Transaction signature verification for version 0 and version 1 witness program]
-*[https://github.com/bitcoin/bips/blob/master/bip-0144.mediawiki BIP144 Segregated Witness (Peer Services)]
+*[[bip-0016.mediawiki|BIP16 Pay to Script Hash]]
+*[[bip-0142.mediawiki|BIP142 Address Formats for Segregated Witness]]
+*[[bip-0143.mediawiki|BIP143 Transaction Signature Verification for Version 0 Witness Program]]
+*[[bip-0144.mediawiki|BIP144 Segregated Witness (Peer Services)]]
 
 == Copyright ==
 

From 8e22af1d0a5de646b8f6cf4e9a78aa5792fcf7a5 Mon Sep 17 00:00:00 2001
From: Johnson Lau 
Date: Thu, 14 Jan 2016 13:15:10 +0800
Subject: [PATCH 144/259] Title change and links update

---
 README.mediawiki   | 2 +-
 bip-0143.mediawiki | 8 ++++----
 bip-0144.mediawiki | 2 +-
 3 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/README.mediawiki b/README.mediawiki
index fdfb988d..63fc568e 100644
--- a/README.mediawiki
+++ b/README.mediawiki
@@ -417,7 +417,7 @@ Those proposing changes should consider that ultimately consent may rest with th
 | Draft
 |-
 | [[bip-0143.mediawiki|143]]
-| Transaction signature verification for version 0 and version 1 witness program
+| Transaction Signature Verification for Version 0 Witness Program
 | Johnson Lau, Pieter Wuille
 | Standard
 | Draft
diff --git a/bip-0143.mediawiki b/bip-0143.mediawiki
index 4aca2db6..3d7e8563 100644
--- a/bip-0143.mediawiki
+++ b/bip-0143.mediawiki
@@ -1,6 +1,6 @@
 
   BIP: 143
-  Title: Transaction signature verification for version 0 and version 1 witness program
+  Title: Transaction Signature Verification for Version 0 Witness Program
   Author: Johnson Lau 
           Pieter Wuille 
   Status: Draft
@@ -9,7 +9,7 @@
 

 
 == Abstract ==
-This proposal defines a new transaction digest algorithm for signature verification in version 0 and version 1 witness program, in order to minimize redundant data hashing in verification, and to cover the input value by the signature.
+This proposal defines a new transaction digest algorithm for signature verification in version 0 witness program, in order to minimize redundant data hashing in verification, and to cover the input value by the signature.
 
 == Motivation ==
 There are 4 ECDSA signature verification codes in the original Bitcoin script system: CHECKSIG, CHECKSIGVERIFY, CHECKMULTISIG, CHECKMULTISIGVERIFY (“sigops”). According to the sighash type (ALL, NONE, SINGLE, ANYONECANPAY), a transaction digest is generated with a double SHA256 of a serialized subset of the transaction, and the signature is verified against this digest with a given public key. The detailed procedure is described in a Bitcoin Wiki article. [https://en.bitcoin.it/wiki/OP_CHECKSIG]
@@ -22,7 +22,7 @@ Unfortunately, there are at least 2 weaknesses in the original transaction diges
 Deploying the aforementioned fixes in the original script system is not a simple task. That would be either a hardfork, or a softfork for new sigops without the ability to remove or insert stack items. However, the introduction of segregated witness softfork offers an opportunity to define a different set of script semantics without disrupting the original system, as the unupgraded nodes would always consider such a transaction output is spendable by arbitrary signature or no signature at all. [https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki BIP141: Segregated Witness (Consensus layer)]
 
 == Specification ==
-A new transaction digest algorithm is defined, but only applicable to sigops in version 0 and version 1 witness program:
+A new transaction digest algorithm is defined, but only applicable to sigops in version 0 witness program:
   Double SHA256 of the serialization of:
      1. nVersion of the transaction
      2. hashPrevouts
@@ -122,7 +122,7 @@ As a soft fork, older software will continue to operate without modification. No
 
 == Reference Implementation ==
 
-https://github.com/sipa/bitcoin/commits/segwit2
+https://github.com/sipa/bitcoin/commits/segwit3
 
 == References ==
 
diff --git a/bip-0144.mediawiki b/bip-0144.mediawiki
index e3843a8f..736fadd4 100644
--- a/bip-0144.mediawiki
+++ b/bip-0144.mediawiki
@@ -116,7 +116,7 @@ MSG_WITNESS_BLOCK requests will return a block message with transactions that ha
 Special thanks to Gregory Maxwell for originating many of the ideas in this BIP and Luke-Jr for figuring out how to deploy this as a soft fork.
 
 == Reference Implementation ==
-https://github.com/sipa/bitcoin/commits/segwit
+https://github.com/sipa/bitcoin/commits/segwit3
 
 == Copyright ==
 This document is placed in the public domain.

From b38742b8f45d886d236deb22e9530523af8994fc Mon Sep 17 00:00:00 2001
From: Johnson Lau 
Date: Thu, 14 Jan 2016 13:26:33 +0800
Subject: [PATCH 145/259] Title change and new address format

---
 README.mediawiki   |   2 +-
 bip-0142.mediawiki | 176 ++++++++++++++++++++++-----------------------
 2 files changed, 86 insertions(+), 92 deletions(-)

diff --git a/README.mediawiki b/README.mediawiki
index 63fc568e..75c6eeb5 100644
--- a/README.mediawiki
+++ b/README.mediawiki
@@ -411,7 +411,7 @@ Those proposing changes should consider that ultimately consent may rest with th
 | Draft
 |-
 | [[bip-0142.mediawiki|142]]
-| Address Formats for Witness Program
+| Address Format for Segregated Witness
 | Johnson Lau
 | Standard
 | Draft
diff --git a/bip-0142.mediawiki b/bip-0142.mediawiki
index fdf52027..7d7b1d26 100644
--- a/bip-0142.mediawiki
+++ b/bip-0142.mediawiki
@@ -1,6 +1,6 @@
 
   BIP: 142
-  Title: Address Formats for Witness Program
+  Title: Address Format for Segregated Witness
   Author: Johnson Lau 
   Status: Draft
   Type: Standards Track
@@ -9,148 +9,142 @@
 
 == Abstract ==
 
-This BIP describes 2 new types of Bitcoin address to support native Segregated Witness (segwit) transactions. The first type resembles the original P2PKH base-58 address. The second type is a z-base-32 representation of a witness program with Damm algorithm checksum, which supports arbitrarily complex transactions, and is forward compatible to new version witness programs in the future.
+This BIP describes new types of Bitcoin address to support native segregated witness transactions with 20-byte and 32-byte program.
 
 == Motivation ==
 
-To define standard payment addresses for native segwit transactions to promote early adoption of the more efficient transaction method.
+To define standard payment address for native segregated witness (segwit) transactions to promote early adoption of the more efficient transaction method.
 
 == Specification ==
 
-=== P2PKH segwit address ===
+The new Bitcoin address format defined is for the Pay-to-Witness-Public-Key-Hash (P2WPKH) and Pay-to-Witness-Script-Hash (P2WSH) transaction described in segregated witness soft fork (BIP141). The scriptPubKey is an OP_0 followed by a push of 20-byte-hash (P2WPKH) or 32-byte hash (P2WSH).
 
-The first new Bitcoin address format defined is specific to pay-to-public-key-hash segwit transaction. The scriptPubKey is an OP_0 followed by a push of version 0 witness program:
-  OP_0  EQUALVERIFY CHECKSIG>
-The new address is encoded exactly in the same way as the original pay-to-public-key-hash address:
-  base58-encode: [1-byte version][20-byte-hash-value][4-byte checksum]
-Version byte is 0x19 for a main-network address, 0x41 for a testnet address. The following 20-byte is the public key hash. And the 4-byte checksum is the first four bytes of the double SHA256 hash of the version and public key hash.
+The new address is encoded in a simlar way as existing address formats:
+  
+  base58-encode:
+    [1-byte address version]
+    [1-byte witness program version]
+    [0x00]
+    [20/32-byte-hash]
+    [4-byte checksum]
+  
+For P2WPKH address, the address version is 6 (0x06) for a main-network address or 3 (0x03) for a testnet address.
 
-All addresses generated with this scheme will a constant length of 34 characters, with a "B" prefix for main-network and "T" prefix for testnet.
+For P2WSH address, the address version is 10 (0x0A) for a main-network address or 40 (0x28) for a testnet address.
 
-=== General segwit address ===
+The witness program version is an 1-byte value between 0 (0x00) and 16 (0x10). Only version 0 is defined in BIP141. Versions 1 to 16 are reserved for future extensions.
 
-The second new bitcoin address format defined is applicable to witness program of version 0 to 15 with a length of 2 to 32 bytes.
+Following the witness program version is a 0x00 padding to make sure that each witness program version will have an unique prefix.
 
-The z-base-32 character set is used:
-{|class="wikitable" style="width:40ex; text-align: center; margin: 0 auto 0 auto;"
-!width="12%"|Value
-!width="12%"|Symbol
-!width="12%"|Value
-!width="12%"|Symbol
-!width="12%"|Value
-!width="12%"|Symbol
-!width="12%"|Value
-!width="12%"|Symbol
+Following the padding is the program hash, 20 byte for a P2WPKH address and 32 byte for a P2WSH address.
+
+The 4-byte checksum is the first four bytes of the double SHA256 hash of the serialization of the previous items.
+
+All addresses generated with this scheme will have a constant length, with 36 digits for 20-byte and 53 digits for 32-byte. Different witness program version will have an unique prefix shown in the following table:
+
+{|class="wikitable" style="text-align: center;"
 |-
-| 0 || y ||  8 || e || 16 || o || 24 || a
+!rowspan=3 style=""|Witness program version
+!colspan=4 style=""|Hash size
 |-
-| 1 || b ||  9 || j || 17 || t || 25 || 2
+!colspan=2 style=""|20-byte (36 digits)
+!colspan=2 style=""|32-byte (53 digits)
 |-
-| 2 || n || 10 || k || 18 || 1 || 26 || 4
+!Mainnet
+!Testnet
+!Mainnet
+!Testnet
 |-
-| 3 || d || 11 || m || 19 || u || 27 || 5
+|0||p2||QW||7Xh||T7n
 |-
-| 4 || r || 12 || c || 20 || w || 28 || h
+|1||p4||QY||7Xq||T7w
 |-
-| 5 || f || 13 || p || 21 || i || 29 || 7
+|2||p6||Qa||7Xz||T85
 |-
-| 6 || g || 14 || q || 22 || s || 30 || 6
+|3||p7||Qc||7Y9||T8E
+|-
+|4||pA||Qe||7YH||T8N
+|-
+|5||pB||Qf||7YS||T8X
+|-
+|6||pD||Qh||7Ya||T8g
+|-
+|7||pF||Qj||7Yj||T8p
+|-
+|8||pG||Qm||7Yt||T8y
+|-
+|9||pJ||Qn||7Z2||T97
+|-
+|10||pL||Qp||7ZB||T9G
+|-
+|11||pN||Qr||7ZK||T9Q
+|-
+|12||pQ||Qt||7ZU||T9Z
+|-
+|13||pS||Qv||7Zc||T9i
+|-
+|14||pT||Qw||7Zm||T9r
+|-
+|15||pV||Qy||7Zv||TA1
+|-
+|16||pX||R1||7a4||TA9
 |-
-| 7 || 8 || 15 || x || 23 || z || 31 || 9
 |}
 
-It is case-insensitive and includes all alphanumeric characters excluding 0, 2, l, v. The order of alphabet is chosen so that less ambiguous alphabet characters will appear more frequently than others.
-
-An address is a 270-bit string in z-base-32 with the following components:
-
-  5 address version bits
-  5 length bits
-  4 witness program version bits
-  256 witness program bits
-
-The address version bits is 00001b for the main-network and 11001b for the testnet.
-
-Value of the length bits is the length of the witness program in byte minus 1.
-
-Witness program version bits indicates version of the witness program (v0 to v15).
-
-The witness program is padded with leading 0b to 256 bits.
-
-The 270-bit string is transformed to z-base-32 with 54 digits.
-
-The 54-digit raw address is then divided into 9 equal segments. For each segment, a checksum is calculated with Damm algorithm and appended to the end of the segment. This makes the length increases to 63 digits.
-
-A second round of checksum is calculated by taking the digits in the same position of the 9 segments, and appended to the end of the address. This is the final address with 69 digits.
-
 
 == Rationale ==
 
-The segregated witness soft fork (BIP x) defines 2 ways of encoding "witness program", a data push of 2 to 32 bytes:
+The BIP141 defines 2 ways of encoding "witness program", a data push of 2 to 32 bytes:
 
 * A native witness program output is a scriptPubKey with a push of version byte followed by a push of witness program, and nothing else;
-* A witness program in P2SH is a P2SH redeemScript with a push of version byte followed by a push of witness program, while the scriptPubKey looks like a normal P2SH output.
+* Segwit-in-P2SH is a BIP16 P2SH redeemScript with a push of version byte followed by a push of witness program, while the scriptPubKey looks like a normal P2SH output.
 
-As the P2SH address has been defined in 2012, using witness program in P2SH allows most existing wallets to pay a segwit-compatible wallet without any upgrade. However, this method requires more block space and is less collision-resistance than a native witness program, and is only a short-term solution to make the transition smoother. Eventually, all users are expected to use the more efficient native witness program as the primary payment method.
+As the BIP13 P2SH address has been defined in 2012, using segwit-in-P2SH allows most existing wallets to pay a segwit-compatible wallet without any upgrade. However, this method requires more block space and is only a short-term solution to make the transition smoother. Eventually, all users are expected to use the more efficient native witness program as the primary payment method.
 
 The drawbacks of Bitcoin addresses have been extensively discussed in BIP13. Since then, better payment methods have been proposed or deployed, for example:
 *BIP47 Reusable Payment Codes for Hierarchical Deterministic Wallets
 *BIP63 Stealth Addresses
 *BIP70 Payment protocol
 
-However, none of these are as widely adopted as the suboptimal base-58 scriptPubKey template addresses, which is still a standard for the whole eco-system, from wallets, block explorers, merchants, exchanges, to end users. As P2PKH transactions are still dominating the blockchain, the author believes that the proposed P2PKH segwit addresses is the easiest way for wallets and services to adopt native witness program, which is particularly important in the context of scaling the capacity of the blockchain.
+However, none of these are as widely adopted as the suboptimal base-58 scriptPubKey template addresses, which is still a standard for the whole eco-system, from wallets, block explorers, merchants, exchanges, to end users. It is believed that the proposed P2WPKH and P2WSH address format is the easiest way for wallets and services to adopt native witness program, which is particularly important in the context of scaling the capacity of the blockchain.
 
-The P2PKH segwit addresses only allow simple payment to a single public key. For arbitrarily complex segwit transactions, the general segwit address is used. The use of z-base-32 eliminates case-sensitiveness and simplifies transformation to and from hexadecimals. The Damm algorithm checksum allows detection of all single-digit errors and all adjacent transposition errors. With the excellent upgradability of witness program, this proposal is also forward compatible to new version witness programs that is not longer than 32 bytes.
+While P2WPKH address is specific for simple payment to a single public key, P2WSH address allows arbitrarily complex segwit transactions, resemble to the BIP13 P2SH address.
 
 == Compatibility ==
 
-This proposal is not backward compatible, but it fails gracefully -- if an older implementation is given one of these new Bitcoin addresses, it will report the address as invalid and will refuse to create a transaction.
+This proposal is not backward compatible. However, an older implementation will report the new address type as invalid and will refuse to create a transaction.
 
-This proposal is forward compatible to any new witness program format with version 2 to 15 and length of 2 to 32 bytes.
+This proposal is forward compatible to the future versions of witness program of 20 and 32 bytes.
 
 == Example ==
 
-=== P2PKH segwit address ===
-
 The following public key,
+  
     0450863AD64A87AE8A2FE83C1AF1A8403CB53F53E486D8511DAD8A04887E5B23522CD470243453A299FA9E77237716103ABC11A1DF38855ED6F2EE187E9C582BA6
+ 
 when encoded as a P2PKH template, would become:
+  
     DUP HASH160 <010966776006953D5567439E5E39F86A0D273BEE> EQUALVERIFY CHECKSIG
+
 And the corresponding version 1 Bitcoin address is
+  
     16UwLL9Risc3QfPqBUvKofHmBQ7wMtjvM
-When the same script is encoded as a version 0 witness program, the scriptPubKey becomes: 
-    OP_0 <0x76A914010966776006953D5567439E5E39F86A0D273BEE88AC>
-Using 0x19 as the address version, the equivalent witness program address is:
-    B4YZZ3nMBETWVF9ZSfotSwTxVnqhdkTi7r
+ 
+When the same public key is encoded as P2WPKH, the scriptPubKey becomes: 
+  
+    OP_0 <010966776006953D5567439E5E39F86A0D273BEE>
 
-=== General segwit address ===
-
-With the same 25 bytes version 0 witness program in the last example:
-    OP_0 <0x76A914010966776006953D5567439E5E39F86A0D273BEE88AC>
-The address version bits is 00001b
-    00001b
-The lengths bits is 11000b (24 = 25 - 1)
-    00001-11000b
-The witness program version bits is 0000
-    00001-11000-0000b
-Appended by the zero-padded witness program
-    00001-11000-0000-0-00000-00000-00000-00000-00000-00000-00000-00000-00000-00000-00000-00000-11101...01100
-The 270-bit string is transformed to z-base-32 with 54 digits and split into 9 equal segments:
-    bayyyy -yyyyyy -yyq4wt -eyejc3 -5sybwi -8iksqo -h6mah9 -o4oprh -767nfc
-Calculate the Damm checksum for each segment:
-    For example: Damm(bayyyy) = 7
-    bayyyy7-yyyyyyy-yyq4wte-eyejc3q-5sybwic-8iksqoo-h6mah9w-o4oprhm-767nfc4
-Calculate the Damm checksum for digits in the same position of different segments:
-    For example: Damm(byye58ho7) = j
-    bayyyy7-yyyyyyy-yyq4wte-eyejc3q-5sybwic-8iksqoo-h6mah9w-o4oprhm-767nfc4-jwk86o
-
-== Implementation ==
-
-From arbitrary witness program to general segwit address: https://gist.github.com/jl2012/760b0f952715b8b6c608
+Using 0x06 as witness version, followed 0x00 as witness version, and a 0x00 padding, the equivalent P2WPKH address is:
+  
+    p2xtZoXeX5X8BP8JfFhQK2nD3emtjch7UeFm
+ 
+== Reference implementation ==
 
 == References ==
 
 * [[bip-0013.mediawiki|BIP 13: Address Format for pay-to-script-hash]]
-* [[bip-0016.mediawiki|BIP 16: Pay to Script Hash (aka "/P2SH/")]]
+* [[bip-0016.mediawiki|BIP 16: Pay to Script Hash]]
+* [[bip-0070.mediawiki|BIP 70: Payment Protocal]]
 * [[bip-0141.mediawiki|BIP 141: Segregated Witness]]
 
 == Copyright ==

From 0ee385bac444a6080b96b307036e7d265fb3d5e2 Mon Sep 17 00:00:00 2001
From: Andy Chase 
Date: Mon, 18 Jan 2016 17:34:06 -0800
Subject: [PATCH 146/259] Add Committee-based BIP Acceptance Process

---
 bip-andychase.mediawiki | 116 ++++++++++++++++++++++++++++++++++++++++
 1 file changed, 116 insertions(+)
 create mode 100644 bip-andychase.mediawiki

diff --git a/bip-andychase.mediawiki b/bip-andychase.mediawiki
new file mode 100644
index 00000000..cf095728
--- /dev/null
+++ b/bip-andychase.mediawiki
@@ -0,0 +1,116 @@
+
+  Title: Committee-based BIP Acceptance Process
+  Author: Andy Chase 
+  Status: Draft 
+  Type: Process 
+  Created: 2015-08-31
+

+
+== Abstract ==
+
+The current process for accepting a BIP is not clearly defined. While [https://github.com/bitcoin/bips/blob/master/bip-0001.mediawiki BIP-0001] defines the process for writing and submitting a Bitcoin Improvement Proposal to the community it does not specify the precise method for which BIPs are considered accepted or rejected.
+
+This proposal sets up a method for determining BIP acceptance.
+
+This BIP has two parts:
+
+* It sets up a '''process''' which a BIP goes through for comments and acceptance. The Process is:
+** BIP Draft
+** Submitted for comments (2 weeks)
+** Waiting on opinion (2 weeks)
+** BIP becomes either Accepted or Deferred
+* It sets up '''committees''' for reviewing comments and indicating acceptance under precise conditions.
+** Committees are authorized groups that represent client authors, miners, merchants, and users (each as a segment). Each one must represent at least 1% stake in the Bitcoin ecosystem.
+
+BIP acceptance is defined as at least 70% of the represented percentage stake in 3 out of the 4 Bitcoin segments.
+
+== Copyright ==
+
+This document is placed into the public domain.
+
+== Motivation ==
+
+BIPs represent important improvements to Bitcoin infrastructure, and in order to foster continued innovation, the BIP process must have clearly defined stages and acceptance acknowledgement.
+
+== Rationale ==
+
+A committee system is used to organize the essential concerns of each segment of the Bitcoin ecosystem. Although each segment may have many different viewpoints on each BIP, in order to seek a decisive yes/no on a BIP, a representational authoritative structure is sought. This structure should be fluid, allowing people to move away from committees that do not reflect their views and should be re-validated on each BIP evaluation.
+
+== Weaknesses ==
+
+Each committee submits a declaration including their claim to represent a certain percentage of the Bitcoin ecosystem in some way. Though guidelines are given, it's up to each committee to prove their stake, and it's up to the reader of the opinions to decide if a BIP was truly accepted or rejected.
+
+The author doesn't believe this is a problem because a BIP cannot be forced on client authors, miners, merchants, or users. Ultimately this BIP is a tool for determining whether a BIP is overwhelmingly accepted. If one committee's validity claim becomes the factor that decides whether the BIP will succeed or fail, this process simply didn't return a clear answer and the BIP should be considered deferred.
+
+== Process ==
+
+* '''Submit for Comments.''' The first BIP champion named in the proposal can call a "submit for comments" at any time by posting to the [https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev Dev Mailing List] mailling with the BIP number and a statement that the champion intends to immediately submit the BIP for comments.
+** The BIP must have been assigned BIP-number (i.e. been approved by the BIP editor) to be submitted for comments.
+* '''Comments.'''
+** After a BIP has been submitted for comments, a two-week waiting period begins in which the community should transition from making suggestions about a proposal to publishing their opinions or concerns on the proposal.
+* '''Reported Opinions.'''
+** After the waiting period has past, committees must submit a summary of the comments which they have received from their represented communities.
+** The deadline for this opinion is four weeks after the BIP was submitted for comments.
+** Committees cannot reverse their decision after the deadline, but at their request may flag their decision as "likely to change if another submit for comments is called". Committees can change their decision if a resubmit is called.
+** Opinions must include:
+*** One of the following statements: "Intend to accept", "Intent to implement", "Decline to accept", "Intend to accept, but decline to implement".
+*** If rejected, the opinion must cite clear and specific reasons for rejecting including a checklist for what must happen or be change for their committee to accept the proposal.
+*** If accepted, the committee must list why they accepted the proposal and also include concerns they have or what about the BIP that, if things changed, would cause the committee to likely reverse their decision if another submit for comments was called.
+* '''Accepted.'''
+** If at least 70% of the represented percentage stake in 3 out of 4 segments accept a proposal, the BIP is considered accepted.
+** If a committee fails to submit an opinion, consider the opinion "Decline to accept".
+** The BIP cannot be substantially changed at this point, but can be replaced. Minor changes or clarifications are allowed but must be recorded in the document.
+* '''Deferred.'''
+** If the acceptance test above is not met, the BIP is sent back into suggestions.
+** BIP can be modified and re-submitted for a comments no sooner than two months after the date of the previous submit for comments is called.
+** The BIP is marked rejected after two failed submission attempts. A rejected BIP can still be modified and re-submitted.
+
+== Committees ==
+
+'''BIP Committees.'''
+
+* BIP Committees are representational structures that represent critical segments of the Bitcoin ecosystem.
+* Each committee must prove and maintain a clear claim that they represent at least 1% of the Bitcoin ecosystem in some form.
+* If an organization or community does not meet that requirement, it should conglomerate itself with other communities and organizations so that it does.
+* The segments that committees can be based around are:
+** Bitcoin software
+** Exchanges/Merchants/services/payment processors
+** Mining operators
+** User communities
+* A person may be represented by any number of segments, but a committee cannot re-use the same resource as another committee in the same segment.
+
+'''Committee Declarations.''' 
+* At any point, a Committee Declaration can be posted.
+* This Declaration must contain details about:
+** The segment the Committee is representing
+** Who the committee claim to represent and it's compositional makeup (if made up of multiple miner orgs, user orgs, companies, clients, etc).
+** Proof of claim and minimum 1% stake via:
+*** Software: proof of ownership and user base (Min 1% of Bitcoin userbase)
+*** Merchant: proof of economic activity (Min 1% of Bitcoin economic activity)
+*** Mining: proof of work (Min 1% of Hashpower)
+*** For a user organization, auditable signatures qualifies for a valid committee (Min 1% of Bitcoin userbase)
+** Who is running the committee, their names and roles
+** How represented members can submit comments to the committee
+** A code of conduct and code of ethics which the committee promises to abide by
+* A committee declaration is accepted if:
+** The declaration includes all of the required elements
+** The stake is considered valid
+** Committee validation is considered when considering the results of opinions submitted by committee on a BIP. A committee must have met the required stake percentage before a BIP is submitted for comments, and have maintained that stake until a valid opinion is submitted.
+* Committees can dissolve at any time or submit a declaration at any time
+* Declaration must have been submitted no later than the third day following a BIP's request for comments to be eligible for inclusion in a BIP
+
+== BIP Process Management Role ==
+
+BIPs, Opinions, and Committee Declaration must be public at all times.
+
+A BIP Process Manager should be chosen who is in charge of:
+
+* Declaring where and how BIPs, Opinions, and Committee Declaration should be posted and updated officially.
+* Maintaining the security and authenticity of BIPs, Opinions, and Committee Declarations
+* Publishing advisory documents about what kinds of proof of stakes are valid and what kinds should be rejected.
+* Naming a series of successors for the roles of the BIP Process Manager and BIP Editor (BIP-001) as needed.
+
+== Conditions for activation ==
+
+In order for this process BIP to become active, it must succeed by its own rules. At least a 4% sample of the Bitcoin community must be represented, with at least one committee in each segment included. Once at least one committee has submitted a declaration, a request for comments will be called and the process should be completed from there.
+

From bcf0ea37840d9feba5fd6c16285e034f9a8e2688 Mon Sep 17 00:00:00 2001
From: Luke Dashjr 
Date: Tue, 19 Jan 2016 01:37:57 +0000
Subject: [PATCH 147/259] Assign BIP 131

---
 README.mediawiki                                      | 6 ++++++
 bip-coalesce-wildcard.mediawiki => bip-0131.mediawiki | 2 +-
 2 files changed, 7 insertions(+), 1 deletion(-)
 rename bip-coalesce-wildcard.mediawiki => bip-0131.mediawiki (99%)

diff --git a/README.mediawiki b/README.mediawiki
index 1ce3a76f..75841029 100644
--- a/README.mediawiki
+++ b/README.mediawiki
@@ -410,6 +410,12 @@ Those proposing changes should consider that ultimately consent may rest with th
 | Standard
 | Draft
 |-
+| [[bip-0131.mediawiki|131]]
+| "Coalescing Transaction" Specification (wildcard inputs)
+| Chris Priest
+| Standard
+| Draft
+|-
 | [[bip-0140.mediawiki|140]]
 | Normalized TXID
 | Christian Decker
diff --git a/bip-coalesce-wildcard.mediawiki b/bip-0131.mediawiki
similarity index 99%
rename from bip-coalesce-wildcard.mediawiki
rename to bip-0131.mediawiki
index 4c3a557a..c30ef54c 100644
--- a/bip-coalesce-wildcard.mediawiki
+++ b/bip-0131.mediawiki
@@ -1,5 +1,5 @@
 
-  BIP: (no number)
+  BIP: 131
   Title: "Coalescing Transaction" Specification (wildcard inputs)
   Author: Chris Priest 
   Status: Draft

From 4ee32820b9da4e1c4aee43187ecc54e1835291e8 Mon Sep 17 00:00:00 2001
From: Andreas Schildbach 
Date: Tue, 19 Jan 2016 14:38:09 +0100
Subject: [PATCH 148/259] Fix typo in proposed BIP144.

---
 bip-0144.mediawiki | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/bip-0144.mediawiki b/bip-0144.mediawiki
index 736fadd4..5503044a 100644
--- a/bip-0144.mediawiki
+++ b/bip-0144.mediawiki
@@ -73,7 +73,7 @@ The serialization has the following structure:
 | The block number or timestamp until which the transaction is locked
 |}
 
-Parsers supporting this BIP will be able to distinguish between the old serialization format (without the witness) and this one. The marker byte is set to zero so that this structure will never parse as a valid transaction in a parser that does not support this BIP. If parsing were to succeeded, such a transaction would contain no inputs and a single output.
+Parsers supporting this BIP will be able to distinguish between the old serialization format (without the witness) and this one. The marker byte is set to zero so that this structure will never parse as a valid transaction in a parser that does not support this BIP. If parsing were to succeed, such a transaction would contain no inputs and a single output.
 
 If the witness is empty, the old serialization format should be used. 
 

From 144dbaa9557e04625f188e19cc8334515de5b597 Mon Sep 17 00:00:00 2001
From: Johnson Lau 
Date: Tue, 19 Jan 2016 20:54:35 +0800
Subject: [PATCH 149/259] Introducing the term "witnessScript" in BIP141

---
 bip-0141.mediawiki | 18 +++++++++++-------
 1 file changed, 11 insertions(+), 7 deletions(-)

diff --git a/bip-0141.mediawiki b/bip-0141.mediawiki
index 74fbf0f6..4614822f 100644
--- a/bip-0141.mediawiki
+++ b/bip-0141.mediawiki
@@ -57,9 +57,13 @@ If there are more than one scriptPubKey matching the pattern, the one with highe
 
 A scriptPubKey (or redeemScript as defined in BIP16/P2SH) that consists of a 1-byte push opcode (for 0 to 16) followed by a data push between 2 and 32 bytes gets a new special meaning. The value of the first push is called the "version byte". The following byte vector pushed is called the "witness program".
 
+Witness verification logic is either
+# triggered by a scriptPubKey that is exactly a push of a version byte, plus a push of a witness program, or
+# triggered when a scriptPubKey is a P2SH script, and the BIP16 redeemScript pushed in the scriptSig is exactly a push of a version byte plus a push of a witness program.
+
 New rules for scriptSig:
-* In case the scriptPubKey pushes a version byte and witness program directly, the scriptSig must be exactly empty.
-* In case the redeemScript pushes a version byte and witness program, the scriptSig must be exactly the single push of the redeemScript.
+* In case 1, the scriptSig must be exactly empty.
+* In case 2, the scriptSig must be exactly a push of the BIP16 redeemScript.
 
 If the version byte is 0, and the witness program is 20 bytes,
 * It is interpreted as a pay-to-witness-public-key-hash (P2WPKH) program.
@@ -69,9 +73,9 @@ If the version byte is 0, and the witness program is 20 bytes,
 
 If the version byte is 0, and the witness program is 32 bytes,
 * It is interpreted as a pay-to-witness-script-hash (P2WSH) program.
-* The witness must consist of an input stack to feed to the script, followed by a serialized script.
-* The serialized script is popped off the initial witness stack. SHA256 of the serialized script must match the 32-byte witness program.
-* The serialized script is deserialized, and executed after normal script evaluation with the remaining witness stack.
+* The witness must consist of an input stack to feed to the script, followed by a serialized script ("witnessScript").
+* The witnessScript is popped off the initial witness stack. SHA256 of the witnessScript must match the 32-byte witness program.
+* The witnessScript is deserialized, and executed after normal script evaluation with the remaining witness stack.
 * The script must not fail, and result in exactly a single TRUE on the stack.
 
 If the version byte is 0, but the witness program is neither 20 nor 32 bytes, the script must fail.
@@ -124,7 +128,7 @@ The following example is an 1-of-2 multi-signature version 0 pay-to-witness-scri
     scriptPubKey: 0 <32-byte-hash>
                   (0x0020{32-byte-hash})
 
-The '0' in scriptPubKey indicates the following push is a version 0 witness program. The length of the witness program indicates that it is a P2WSH type. The last item in the witness is popped off, hashed with SHA256, compared against the 32-byte-hash in scriptPubKey, and deserialized:
+The '0' in scriptPubKey indicates the following push is a version 0 witness program. The length of the witness program indicates that it is a P2WSH type. The last item in the witness (the "witnessScript") is popped off, hashed with SHA256, compared against the 32-byte-hash in scriptPubKey, and deserialized:
 
     1   2 CHECKMULTISIG
 
@@ -150,7 +154,7 @@ The only item in scriptSig is hashed with HASH160, compared against the 20-byte-
 
     0 <32-byte-hash>
 
-The P2WSH witness program is then executed as described in the previous example
+The P2WSH witness program is then executed as described in the previous example.
 
 Comparing with the previous example, the scriptPubKey is 11 bytes smaller (with reduced security) while witness is the same. However, it also requires 35 bytes in scriptSig, which is not prunable in transmission. Although a nested witness program is less efficient in many ways, its payment address is fully transparent and backward compatible for all Bitcoin reference client since version 0.6.0.
 

From 7f68752bee6b259878f81c29dab4e9d1ec5f738f Mon Sep 17 00:00:00 2001
From: Gregory Sanders 
Date: Tue, 19 Jan 2016 11:48:15 -0500
Subject: [PATCH 150/259] Tidy up Witness Program section

---
 bip-0141.mediawiki | 18 +++++++-----------
 1 file changed, 7 insertions(+), 11 deletions(-)

diff --git a/bip-0141.mediawiki b/bip-0141.mediawiki
index 4614822f..c769abda 100644
--- a/bip-0141.mediawiki
+++ b/bip-0141.mediawiki
@@ -57,21 +57,17 @@ If there are more than one scriptPubKey matching the pattern, the one with highe
 
 A scriptPubKey (or redeemScript as defined in BIP16/P2SH) that consists of a 1-byte push opcode (for 0 to 16) followed by a data push between 2 and 32 bytes gets a new special meaning. The value of the first push is called the "version byte". The following byte vector pushed is called the "witness program".
 
-Witness verification logic is either
-# triggered by a scriptPubKey that is exactly a push of a version byte, plus a push of a witness program, or
-# triggered when a scriptPubKey is a P2SH script, and the BIP16 redeemScript pushed in the scriptSig is exactly a push of a version byte plus a push of a witness program.
+There are two cases in which witness validation logic are triggered. Each case determines the location of the witness version byte and program, as well as the form of the scriptSig:
+# Triggered by a scriptPubKey that is exactly a push of a version byte, plus a push of a witness program. The scriptSig must be exactly empty.
+# Triggered when a scriptPubKey is a P2SH script, and the BIP16 redeemScript pushed in the scriptSig is exactly a push of a version byte plus a push of a witness program. The scriptSig must be exactly a push of the BIP16 redeemScript.
 
-New rules for scriptSig:
-* In case 1, the scriptSig must be exactly empty.
-* In case 2, the scriptSig must be exactly a push of the BIP16 redeemScript.
-
-If the version byte is 0, and the witness program is 20 bytes,
+If the version byte is 0, and the witness program is 20 bytes:
 * It is interpreted as a pay-to-witness-public-key-hash (P2WPKH) program.
-* The witness must consist of exactly 2 items. The first one is a signature, and the second one is a public key.
-* HASH160 of the public key must match the 20-byte witness program.
+* The witness must consist of exactly 2 items. The first one a signature, and the second one a public key.
+* The HASH160 of the public key must match the 20-byte witness program.
 * After normal script evaluation, the signature is verified against the public key with CHECKSIG operation. The verification must result in a single TRUE on the stack.
 
-If the version byte is 0, and the witness program is 32 bytes,
+If the version byte is 0, and the witness program is 32 bytes:
 * It is interpreted as a pay-to-witness-script-hash (P2WSH) program.
 * The witness must consist of an input stack to feed to the script, followed by a serialized script ("witnessScript").
 * The witnessScript is popped off the initial witness stack. SHA256 of the witnessScript must match the 32-byte witness program.

From d6af2d163c69bafea5c4252280b4b4a08a301a98 Mon Sep 17 00:00:00 2001
From: Luke Dashjr 
Date: Tue, 19 Jan 2016 17:59:41 +0000
Subject: [PATCH 151/259] Assign BIP 132

---
 README.mediawiki                              | 6 ++++++
 bip-andychase.mediawiki => bip-0132.mediawiki | 7 ++++---
 2 files changed, 10 insertions(+), 3 deletions(-)
 rename bip-andychase.mediawiki => bip-0132.mediawiki (99%)

diff --git a/README.mediawiki b/README.mediawiki
index 1ce3a76f..fb6e8a31 100644
--- a/README.mediawiki
+++ b/README.mediawiki
@@ -410,6 +410,12 @@ Those proposing changes should consider that ultimately consent may rest with th
 | Standard
 | Draft
 |-
+| [[bip-0132.mediawiki|132]]
+| Committee-based BIP Acceptance Process
+| Andy Chase
+| Process
+| Draft
+|-
 | [[bip-0140.mediawiki|140]]
 | Normalized TXID
 | Christian Decker
diff --git a/bip-andychase.mediawiki b/bip-0132.mediawiki
similarity index 99%
rename from bip-andychase.mediawiki
rename to bip-0132.mediawiki
index cf095728..814e20a5 100644
--- a/bip-andychase.mediawiki
+++ b/bip-0132.mediawiki
@@ -1,8 +1,9 @@
 
+  BIP: 132
   Title: Committee-based BIP Acceptance Process
-  Author: Andy Chase 
-  Status: Draft 
-  Type: Process 
+  Author: Andy Chase
+  Status: Draft
+  Type: Process
   Created: 2015-08-31
 

 

From 9d99270419bd9ce114ac19a1f77886077f0b50aa Mon Sep 17 00:00:00 2001
From: Sam Wood 
Date: Tue, 19 Jan 2016 21:37:47 -0800
Subject: [PATCH 152/259] Adds a missing BIP 141 segwit BIP reference

Adding a missing reference to BIP 141 for clarity.
---
 bip-0144.mediawiki | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/bip-0144.mediawiki b/bip-0144.mediawiki
index 5503044a..1106c393 100644
--- a/bip-0144.mediawiki
+++ b/bip-0144.mediawiki
@@ -77,7 +77,7 @@ Parsers supporting this BIP will be able to distinguish between the old serializ
 
 If the witness is empty, the old serialization format should be used. 
 
-Witness objects can be extended to contain other kinds of witness data not yet specified. This BIP is agnostic to the witness data structure, defined in BIPxxxx (Consensus Segwit BIP), and treats it as an arbitrary byte array.
+Witness objects can be extended to contain other kinds of witness data not yet specified. This BIP is agnostic to the witness data structure, defined in [https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki BIP141] (Consensus segwit BIP), and treats it as an arbitrary byte array.
 
 * '''Rationale for not having an independent message type with its own serialization''': this would require separate "tx" and "block" messages, and all RPC calls operating on raw transactions would need to be duplicated, or need inefficinent or nondeterministic guesswork to know which type is to be used.
 

From e9f9be266f8f79ab0442b7cf528892db60a17cb8 Mon Sep 17 00:00:00 2001
From: Jonas Schnelli 
Date: Wed, 20 Jan 2016 13:43:31 +0100
Subject: [PATCH 153/259] Fix little typo in p2wpkh address creation

---
 bip-0142.mediawiki | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/bip-0142.mediawiki b/bip-0142.mediawiki
index 7d7b1d26..7e09a2eb 100644
--- a/bip-0142.mediawiki
+++ b/bip-0142.mediawiki
@@ -134,7 +134,7 @@ When the same public key is encoded as P2WPKH, the scriptPubKey becomes:
   
     OP_0 <010966776006953D5567439E5E39F86A0D273BEE>
 
-Using 0x06 as witness version, followed 0x00 as witness version, and a 0x00 padding, the equivalent P2WPKH address is:
+Using 0x06 as address version, followed 0x00 as witness program version, and a 0x00 padding, the equivalent P2WPKH address is:
   
     p2xtZoXeX5X8BP8JfFhQK2nD3emtjch7UeFm
  

From 4866fcd392d86244fe96d3b13852b74db0f1760f Mon Sep 17 00:00:00 2001
From: Jorn Cruijsen 
Date: Wed, 20 Jan 2016 17:19:58 +0100
Subject: [PATCH 154/259] Typos and grammar

---
 bip-0142.mediawiki | 26 +++++++++++++-------------
 1 file changed, 13 insertions(+), 13 deletions(-)

diff --git a/bip-0142.mediawiki b/bip-0142.mediawiki
index 7e09a2eb..ce7d5f5d 100644
--- a/bip-0142.mediawiki
+++ b/bip-0142.mediawiki
@@ -19,7 +19,7 @@ To define standard payment address for native segregated witness (segwit) transa
 
 The new Bitcoin address format defined is for the Pay-to-Witness-Public-Key-Hash (P2WPKH) and Pay-to-Witness-Script-Hash (P2WSH) transaction described in segregated witness soft fork (BIP141). The scriptPubKey is an OP_0 followed by a push of 20-byte-hash (P2WPKH) or 32-byte hash (P2WSH).
 
-The new address is encoded in a simlar way as existing address formats:
+The new address is encoded in a way similar to existing address formats:
   
   base58-encode:
     [1-byte address version]
@@ -32,23 +32,23 @@ For P2WPKH address, the address version is 6 (0x06) for a main-network address o
 
 For P2WSH address, the address version is 10 (0x0A) for a main-network address or 40 (0x28) for a testnet address.
 
-The witness program version is an 1-byte value between 0 (0x00) and 16 (0x10). Only version 0 is defined in BIP141. Versions 1 to 16 are reserved for future extensions.
+The witness program version is a 1-byte value between 0 (0x00) and 16 (0x10). Only version 0 is defined in BIP141. Versions 1 to 16 are reserved for future extensions.
 
-Following the witness program version is a 0x00 padding to make sure that each witness program version will have an unique prefix.
+Following the witness program version is a 0x00 padding to make sure that each witness program version will have a unique prefix.
 
 Following the padding is the program hash, 20 byte for a P2WPKH address and 32 byte for a P2WSH address.
 
 The 4-byte checksum is the first four bytes of the double SHA256 hash of the serialization of the previous items.
 
-All addresses generated with this scheme will have a constant length, with 36 digits for 20-byte and 53 digits for 32-byte. Different witness program version will have an unique prefix shown in the following table:
+All addresses generated with this scheme will have a constant length, with 36 digits for 20-byte and 53 digits for 32-byte. Different witness program versions will have a unique prefix, as shown in the following table:
 
 {|class="wikitable" style="text-align: center;"
 |-
 !rowspan=3 style=""|Witness program version
 !colspan=4 style=""|Hash size
 |-
-!colspan=2 style=""|20-byte (36 digits)
-!colspan=2 style=""|32-byte (53 digits)
+!colspan=2 style=""|20-byte (36 characters)
+!colspan=2 style=""|32-byte (53 characters)
 |-
 !Mainnet
 !Testnet
@@ -94,12 +94,12 @@ All addresses generated with this scheme will have a constant length, with 36 di
 
 == Rationale ==
 
-The BIP141 defines 2 ways of encoding "witness program", a data push of 2 to 32 bytes:
+BIP141 defines 2 ways of encoding a "witness program", a data push of 2 to 32 bytes:
 
 * A native witness program output is a scriptPubKey with a push of version byte followed by a push of witness program, and nothing else;
 * Segwit-in-P2SH is a BIP16 P2SH redeemScript with a push of version byte followed by a push of witness program, while the scriptPubKey looks like a normal P2SH output.
 
-As the BIP13 P2SH address has been defined in 2012, using segwit-in-P2SH allows most existing wallets to pay a segwit-compatible wallet without any upgrade. However, this method requires more block space and is only a short-term solution to make the transition smoother. Eventually, all users are expected to use the more efficient native witness program as the primary payment method.
+Considering the BIP13 P2SH address has been defined in 2012, using segwit-in-P2SH allows most existing wallets to pay a segwit-compatible wallet without any upgrade. However, this method requires more block space and is only a short-term solution to make the transition smoother. Eventually, all users are expected to use the more efficient native witness program as the primary method of payment.
 
 The drawbacks of Bitcoin addresses have been extensively discussed in BIP13. Since then, better payment methods have been proposed or deployed, for example:
 *BIP47 Reusable Payment Codes for Hierarchical Deterministic Wallets
@@ -108,13 +108,13 @@ The drawbacks of Bitcoin addresses have been extensively discussed in BIP13. Sin
 
 However, none of these are as widely adopted as the suboptimal base-58 scriptPubKey template addresses, which is still a standard for the whole eco-system, from wallets, block explorers, merchants, exchanges, to end users. It is believed that the proposed P2WPKH and P2WSH address format is the easiest way for wallets and services to adopt native witness program, which is particularly important in the context of scaling the capacity of the blockchain.
 
-While P2WPKH address is specific for simple payment to a single public key, P2WSH address allows arbitrarily complex segwit transactions, resemble to the BIP13 P2SH address.
+While P2WPKH address is specific for simple payment to a single public key, P2WSH address allows arbitrarily complex segwit transactions, similar to the BIP13 P2SH address.
 
 == Compatibility ==
 
-This proposal is not backward compatible. However, an older implementation will report the new address type as invalid and will refuse to create a transaction.
+This proposal is not backward-compatible. However, an older implementation will report the new address type as invalid, and refuse to create a transaction.
 
-This proposal is forward compatible to the future versions of witness program of 20 and 32 bytes.
+This proposal is forward-compatible with future versions of witness programs of 20 and 32 bytes.
 
 == Example ==
 
@@ -126,7 +126,7 @@ when encoded as a P2PKH template, would become:
   
     DUP HASH160 <010966776006953D5567439E5E39F86A0D273BEE> EQUALVERIFY CHECKSIG
 
-And the corresponding version 1 Bitcoin address is
+With the corresponding version 1 Bitcoin address being:
   
     16UwLL9Risc3QfPqBUvKofHmBQ7wMtjvM
  
@@ -134,7 +134,7 @@ When the same public key is encoded as P2WPKH, the scriptPubKey becomes:
   
     OP_0 <010966776006953D5567439E5E39F86A0D273BEE>
 
-Using 0x06 as address version, followed 0x00 as witness program version, and a 0x00 padding, the equivalent P2WPKH address is:
+Using 0x06 as address version, followed by 0x00 as witness program version, and a 0x00 padding, the equivalent P2WPKH address is:
   
     p2xtZoXeX5X8BP8JfFhQK2nD3emtjch7UeFm
  

From 6fccd1ee05e593815e7b7f4db0f45f19604fe99d Mon Sep 17 00:00:00 2001
From: Justus Ranvier 
Date: Fri, 19 Jun 2015 18:14:36 -0500
Subject: [PATCH 155/259] Draft Bitcoin Improvement Proposals for voting pool
 HD wallets

Two informational BIPs are submitted for voting pool HD wallets.

This wallet format follows the BIP43 recommendation to use reserved
BIP numbers to avoid namespace collisions.

The purpose of the wallet formats is to efficiently implement
multisig, FIFO cold storage for bulk bitcoins and for colored
bitcoins.
---
 bip-0080.mediawiki | 71 ++++++++++++++++++++++++++++++++++++++++++++++
 bip-0081.mediawiki | 68 ++++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 139 insertions(+)
 create mode 100644 bip-0080.mediawiki
 create mode 100644 bip-0081.mediawiki

diff --git a/bip-0080.mediawiki b/bip-0080.mediawiki
new file mode 100644
index 00000000..e2f25654
--- /dev/null
+++ b/bip-0080.mediawiki
@@ -0,0 +1,71 @@
+
+  BIP:     80
+  Title:   Hierarchy for Non-Colored Voting Pool Deterministic Multisig Wallets
+  Authors: Justus Ranvier 
+           Jimmy Song 
+  Status:  Draft
+  Type:    Informational
+  Created: 2014-08-11
+

+
+==Abstract==
+
+This BIP defines a logical hierarchy for non-colored voting pool deterministic multisig wallets based on an algorithm described in BIP-0032 (BIP32 from now on) and purpose scheme described in BIP-0043 (BIP43 from now on).
+
+This BIP is a particular application of BIP43 and is based on BIP44.
+
+==Motivation==
+
+The hierarchy proposed in this paper allows the handling of multiple coins and multiple series from a single seed.
+
+==Path levels==
+
+We define the following 4 levels in BIP32 path:
+
+
+m / purpose' / coin_type' / series' / address_index
+

+
+Apostrophe in the path indicates that BIP32 hardened derivation is used.
+
+Each level has a special meaning, described in the chapters below.
+
+===Purpose===
+
+Purpose is a constant set following the BIP43 recommendation to: the ASCII value of "80" with the most signifigant bit set to indicate hardened derivation (0x80000050). It indicates that the subtree of this node is used according to this specification.
+
+Hardened derivation is used at this level.
+
+===Coin type===
+
+One master node (seed) can be used for unlimited number of independent cryptocoins such as Bitcoin, Litecoin or Namecoin. However, sharing the same space for various cryptocoins has some disadvantages.
+
+This level creates a separate subtree for every cryptocoin, avoiding reusing addresses across cryptocoins and improving privacy issues.
+
+Coin type is a constant, set for each cryptocoin. The list of registered coin type constants should be obtained from BIP44.
+
+Hardened derivation is used at this level.
+
+===Series===
+
+Series are used by voting pools in order to implement FIFO cold storage. By directing deposits into multiple series, the private keys for most of the deposits can be kept offline, and a limited portion can be brought online to process withdrawals.
+
+Hardened derivation is used at this level.
+
+===Index===
+
+Public/private keypairs are numbered from index 0 in sequentially increasing manner. This number is used as child index in BIP32 derivation.
+
+Public keys obtained at this level of the heirarchy are used to construct multisig deposit scripts, using a schema that is shared between the members as an out-of-band contract.
+
+Public derivation is used at this level.
+
+==Compatible wallets==
+
+* [[https://github.com/conformal/btcd|btcd]] is the reference Bitcoin wallet for voting pools.
+
+==Reference==
+
+* [[bip-0032.mediawiki|BIP32 - Hierarchical Deterministic Wallets]]
+* [[bip-0043.mediawiki|BIP43 - Purpose Field for Deterministic Wallets]]
+* [[bip-0044.mediawiki|BIP44 - Multi-Account Hierarchy for Deterministic Wallets]]
diff --git a/bip-0081.mediawiki b/bip-0081.mediawiki
new file mode 100644
index 00000000..ee3e0ac0
--- /dev/null
+++ b/bip-0081.mediawiki
@@ -0,0 +1,68 @@
+
+  BIP:     81
+  Title:   Hierarchy for Colored Voting Pool Deterministic Multisig Wallets
+  Authors: Justus Ranvier 
+           Jimmy Song 
+  Status:  Draft
+  Type:    Informational
+  Created: 2014-08-11
+

+
+==Abstract==
+
+This BIP defines a logical hierarchy for colored coin voting pool deterministic multisig wallets based on an algorithm described in BIP-0032 (BIP32 from now on) and purpose scheme described in BIP-0043 (BIP43 from now on).
+
+This BIP is a particular application of BIP43 and is based on BIP44.
+
+==Motivation==
+
+The hierarchy proposed in this paper allows the handling of multiple color definitions from a single seed.
+
+==Path levels==
+
+We define the following 8 levels in BIP32 path:
+
+
+m / purpose' / series' / (5 color definition levels) / address_index
+

+
+Apostrophe in the path indicates that BIP32 hardened derivation is used.
+
+Each level has a special meaning, described in the chapters below.
+
+===Purpose===
+
+Purpose is a constant set following the BIP43 recommendation to: the ASCII value of "81" with the most signifigant bit set to indicate hardened derivation (0x80000051). It indicates that the subtree of this node is used according to this specification.
+
+Hardened derivation is used at this level.
+
+===Color Definition===
+
+Index values which can be applied to a BIP32 node are limited to 4 bytes (32 bits).
+
+Since this is not sufficient to identify color definitions without a risk of collision, multiple levels are used.
+
+Color definitions are first shortened to 20 bytes using the Bitcoin hash160 function.
+
+The resulting 20 bytes are split into five groups in little endian format, and where each group is used as the seed for the five levels of color definition levels
+
+Public derivation is used at these levels, even when the index exceeds 2^31.
+
+===Index===
+
+Public/private keypairs are numbered from index 0 in sequentially increasing manner. This number is used as child index in BIP32 derivation.
+
+Public keys obtained at this level of the heirarchy are used to construct multisig deposit scripts, using a schema that is shared between the members as an out-of-band contract.
+
+Public derivation is used at this level.
+
+==Compatible wallets==
+
+* [[https://github.com/conformal/btcd|btcd]] is the reference Bitcoin wallet for voting pools.
+
+==Reference==
+
+* [[bip-0032.mediawiki|BIP32 - Hierarchical Deterministic Wallets]]
+* [[bip-0043.mediawiki|BIP43 - Purpose Field for Deterministic Wallets]]
+* [[bip-0044.mediawiki|BIP44 - Multi-Account Hierarchy for Deterministic Wallets]]
+* [[bip-0080.mediawiki|BIP44 - Hierarchy for Non-Colored Voting Pool Deterministic Multisig Wallets]]

From 6d963a9d5469ed61148496e2901e31fc948ca02a Mon Sep 17 00:00:00 2001
From: Justus Ranvier 
Date: Fri, 10 Jul 2015 12:24:18 -0500
Subject: [PATCH 156/259] update readme

---
 README.mediawiki | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/README.mediawiki b/README.mediawiki
index 87e6117b..045fd28f 100644
--- a/README.mediawiki
+++ b/README.mediawiki
@@ -302,6 +302,18 @@ Those proposing changes should consider that ultimately consent may rest with th
 | Standard
 | Draft
 |-
+| [[bip-0080.mediawiki|80]]
+| Hierarchy for Non-Colored Voting Pool Deterministic Multisig Wallets
+| Monetas
+| Informational
+| Draft
+|-
+| [[bip-0081.mediawiki|81]]
+| Hierarchy for Colored Voting Pool Deterministic Multisig Wallets
+| Monetas
+| Informational
+| Draft
+|-
 | [[bip-0083.mediawiki|83]]
 | Dynamic Hierarchical Deterministic Key Trees
 | Eric Lombrozo

From b079e559fbc41bd52f5d8d7d7d07c790f53421bc Mon Sep 17 00:00:00 2001
From: Justus Ranvier 
Date: Fri, 10 Jul 2015 13:15:06 -0500
Subject: [PATCH 157/259] update btcwallet links

---
 bip-0080.mediawiki | 2 +-
 bip-0081.mediawiki | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/bip-0080.mediawiki b/bip-0080.mediawiki
index e2f25654..2d150755 100644
--- a/bip-0080.mediawiki
+++ b/bip-0080.mediawiki
@@ -62,7 +62,7 @@ Public derivation is used at this level.
 
 ==Compatible wallets==
 
-* [[https://github.com/conformal/btcd|btcd]] is the reference Bitcoin wallet for voting pools.
+* [[https://github.com/btcsuite/btcwallet|btcwallet]] is the reference Bitcoin wallet for voting pools.
 
 ==Reference==
 
diff --git a/bip-0081.mediawiki b/bip-0081.mediawiki
index ee3e0ac0..eba33ec2 100644
--- a/bip-0081.mediawiki
+++ b/bip-0081.mediawiki
@@ -58,7 +58,7 @@ Public derivation is used at this level.
 
 ==Compatible wallets==
 
-* [[https://github.com/conformal/btcd|btcd]] is the reference Bitcoin wallet for voting pools.
+* [[https://github.com/btcsuite/btcwallet|btcwallet]] is the reference Bitcoin wallet for voting pools.
 
 ==Reference==
 

From 558ee51faf06d47e2b6ec57444159ba11e3c6802 Mon Sep 17 00:00:00 2001
From: Justus Ranvier 
Date: Fri, 10 Jul 2015 14:02:55 -0500
Subject: [PATCH 158/259] correct link description

---
 bip-0081.mediawiki | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/bip-0081.mediawiki b/bip-0081.mediawiki
index eba33ec2..bc8d7fbb 100644
--- a/bip-0081.mediawiki
+++ b/bip-0081.mediawiki
@@ -65,4 +65,4 @@ Public derivation is used at this level.
 * [[bip-0032.mediawiki|BIP32 - Hierarchical Deterministic Wallets]]
 * [[bip-0043.mediawiki|BIP43 - Purpose Field for Deterministic Wallets]]
 * [[bip-0044.mediawiki|BIP44 - Multi-Account Hierarchy for Deterministic Wallets]]
-* [[bip-0080.mediawiki|BIP44 - Hierarchy for Non-Colored Voting Pool Deterministic Multisig Wallets]]
+* [[bip-0080.mediawiki|BIP80 - Hierarchy for Non-Colored Voting Pool Deterministic Multisig Wallets]]

From 7bf68e9f2cc90431e27ae2cef491eafdb1b4e0fb Mon Sep 17 00:00:00 2001
From: Johnson Lau 
Date: Tue, 19 Jan 2016 12:35:35 +0800
Subject: [PATCH 159/259] Add example

---
 bip-0143.mediawiki | 63 ++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 63 insertions(+)

diff --git a/bip-0143.mediawiki b/bip-0143.mediawiki
index 3d7e8563..a377736f 100644
--- a/bip-0143.mediawiki
+++ b/bip-0143.mediawiki
@@ -112,6 +112,69 @@ Refer to the reference implementation, reproduced below, for the precise algorit
   return ss.GetHash();
 
 
+== Example ==
+
+  
+  The following is an unsigned transaction:
+    0100000002fff7f7881a8099afa6940d42d1e7f6362bec38171ea3edf433541db4e4ad969f0000000000eeffffffef51e1b804cc89d182d279655c3aa89e815b1b309fe287d9b2b55d57b90ec68a0100000000ffffffff02202cb206000000001976a9148280b37df378db99f66f85c95a783a76ac7a6d5988ac9093510d000000001976a9143bde42dbee7e4dbe6a21b2d50ce2f0167faa815988ac11000000
+    
+    nVersion:  01000000
+    txin:      02 fff7f7881a8099afa6940d42d1e7f6362bec38171ea3edf433541db4e4ad969f 00000000 00 eeffffff
+                  ef51e1b804cc89d182d279655c3aa89e815b1b309fe287d9b2b55d57b90ec68a 01000000 00 ffffffff
+    txout:     02 202cb20600000000 1976a9148280b37df378db99f66f85c95a783a76ac7a6d5988ac
+                  9093510d00000000 1976a9143bde42dbee7e4dbe6a21b2d50ce2f0167faa815988ac
+    nLockTime: 11000000
+  
+  The first input comes from an ordinary P2PK:
+    scriptPubKey: 2103c9f4836b9a4f77fc0d81f7bcb01b7f1b35916864b9476c241ce9fc198bd25432ac value: 6.25
+    
+  The second input comes from a P2WPKH witness program:
+    scriptPubKey: 00141d0f172a0ecb48aee1be1f2687d2963ae33f71a1, value: 6
+    
+  To sign it with a nHashType of 1 (SIGHASH_ALL):
+  
+  hashPrevouts:
+    dSHA256(fff7f7881a8099afa6940d42d1e7f6362bec38171ea3edf433541db4e4ad969f00000000ef51e1b804cc89d182d279655c3aa89e815b1b309fe287d9b2b55d57b90ec68a01000000)
+  = 96b827c8483d4e9b96712b6713a7b68d6e8003a781feba36c31143470b4efd37
+  
+  hashSequence:
+    dSHA256(eeffffffffffffff)
+  = 52b0a642eea2fb7ae638c36f6252b6750293dbe574a806984b8e4d8548339a3b
+  
+  hashOutputs:
+    dSHA256(202cb206000000001976a9148280b37df378db99f66f85c95a783a76ac7a6d5988ac9093510d000000001976a9143bde42dbee7e4dbe6a21b2d50ce2f0167faa815988ac)
+  = 863ef3e1a92afbfdb97f31ad0fc7683ee943e9abcf2501590ff8f6551f47e5e5
+  
+  hash preimage: 0100000096b827c8483d4e9b96712b6713a7b68d6e8003a781feba36c31143470b4efd3752b0a642eea2fb7ae638c36f6252b6750293dbe574a806984b8e4d8548339a3bef51e1b804cc89d182d279655c3aa89e815b1b309fe287d9b2b55d57b90ec68a010000001976a9141d0f172a0ecb48aee1be1f2687d2963ae33f71a188ac0046c32300000000ffffffff863ef3e1a92afbfdb97f31ad0fc7683ee943e9abcf2501590ff8f6551f47e5e51100000001000000
+  
+    nVersion:     01000000
+    hashPrevouts: 96b827c8483d4e9b96712b6713a7b68d6e8003a781feba36c31143470b4efd37
+    hashSequence: 52b0a642eea2fb7ae638c36f6252b6750293dbe574a806984b8e4d8548339a3b
+    outpoint:     ef51e1b804cc89d182d279655c3aa89e815b1b309fe287d9b2b55d57b90ec68a01000000
+    scriptCode:   1976a9141d0f172a0ecb48aee1be1f2687d2963ae33f71a188ac
+    amount:       0046c32300000000
+    nSequence:    ffffffff
+    hashOutputs:  863ef3e1a92afbfdb97f31ad0fc7683ee943e9abcf2501590ff8f6551f47e5e5
+    nLockTime:    11000000
+    nHashType:    01000000
+    
+  sigHash:      c37af31116d1b27caf68aae9e3ac82f1477929014d5b917657d0eb49478cb670
+  signature:    304402203609e17b84f6a7d30c80bfa610b5b4542f32a8a0d5447a12fb1366d7f01cc44a0220573a954c4518331561406f90300e8f3358f51928d43c212a8caed02de67eebee
+    
+  The serialized signed transaction is: 01000000000102fff7f7881a8099afa6940d42d1e7f6362bec38171ea3edf433541db4e4ad969f00000000494830450221008b9d1dc26ba6a9cb62127b02742fa9d754cd3bebf337f7a55d114c8e5cdd30be022040529b194ba3f9281a99f2b1c0a19c0489bc22ede944ccf4ecbab4cc618ef3ed01eeffffffef51e1b804cc89d182d279655c3aa89e815b1b309fe287d9b2b55d57b90ec68a0100000000ffffffff02202cb206000000001976a9148280b37df378db99f66f85c95a783a76ac7a6d5988ac9093510d000000001976a9143bde42dbee7e4dbe6a21b2d50ce2f0167faa815988ac000247304402203609e17b84f6a7d30c80bfa610b5b4542f32a8a0d5447a12fb1366d7f01cc44a0220573a954c4518331561406f90300e8f3358f51928d43c212a8caed02de67eebee0121025476c2e83188368da1ff3e292e7acafcdb3566bb0ad253f62fc70f07aeee635711000000
+  
+    nVersion:  01000000
+    marker:    00
+    flag:      01
+    txin:      02 fff7f7881a8099afa6940d42d1e7f6362bec38171ea3edf433541db4e4ad969f 00000000 494830450221008b9d1dc26ba6a9cb62127b02742fa9d754cd3bebf337f7a55d114c8e5cdd30be022040529b194ba3f9281a99f2b1c0a19c0489bc22ede944ccf4ecbab4cc618ef3ed01 eeffffff
+                  ef51e1b804cc89d182d279655c3aa89e815b1b309fe287d9b2b55d57b90ec68a 01000000 00 ffffffff
+    txout:     02 202cb20600000000 1976a9148280b37df378db99f66f85c95a783a76ac7a6d5988ac
+                  9093510d00000000 1976a9143bde42dbee7e4dbe6a21b2d50ce2f0167faa815988ac
+    witness    00
+               02 47304402203609e17b84f6a7d30c80bfa610b5b4542f32a8a0d5447a12fb1366d7f01cc44a0220573a954c4518331561406f90300e8f3358f51928d43c212a8caed02de67eebee01 21025476c2e83188368da1ff3e292e7acafcdb3566bb0ad253f62fc70f07aeee6357
+    nLockTime: 11000000
+
+The new serialization format is described in BIP144 [[bip-0144.mediawiki|BIP144: Segregated Witness (Peer Services)]]
 == Deployment ==
 
 This proposal is deployed with Segregated Witness softfork (BIP 141) 

From c25f1e7b5f548a2cbda63dbf2ebdf946cf30a527 Mon Sep 17 00:00:00 2001
From: Johnson Lau 
Date: Tue, 19 Jan 2016 17:18:59 +0800
Subject: [PATCH 160/259] Clarify scriptCode

---
 bip-0143.mediawiki | 48 ++++++++++++++++++++++++++--------------------
 1 file changed, 27 insertions(+), 21 deletions(-)

diff --git a/bip-0143.mediawiki b/bip-0143.mediawiki
index a377736f..093e477e 100644
--- a/bip-0143.mediawiki
+++ b/bip-0143.mediawiki
@@ -24,35 +24,41 @@ Deploying the aforementioned fixes in the original script system is not a simple
 == Specification ==
 A new transaction digest algorithm is defined, but only applicable to sigops in version 0 witness program:
   Double SHA256 of the serialization of:
-     1. nVersion of the transaction
-     2. hashPrevouts
-     3. hashSequence
-     4. transaction id and output index of the output spent by this input
-     5. subscript of the input
-     6. value of the output spent by this input
-     7. nSequence of the input
-     8. hashOutputs
-     9. nLocktime of the transaction
-    10. sighash type of the signature
+     1. nVersion of the transaction (4-byte little endian)
+     2. hashPrevouts (32-byte hash)
+     3. hashSequence (32-byte hash)
+     4. outpoint (32-byte hash + 4-byte little endian) 
+     5. scriptCode of the input (varInt for the length + script)
+     6. value of the output spent by this input (8-byte little endian)
+     7. nSequence of the input (4-byte little endian)
+     8. hashOutputs (32-byte hash)
+     9. nLocktime of the transaction (4-byte little endian)
+    10. sighash type of the signature (4-byte little endian)
 
-The items 1, 4, 5, 7, 9, 10 have the same meaning as the original algorithm. 
+The items 1, 4, 7, 9, 10 have the same meaning as the original algorithm. 
+
+The item 5:
+*For P2WPKH witness program, the scriptCode is 0x1976a914{20-byte-pubkey-hash}88ac.
+*For P2WSH witness program,
+**if the witnessScript does not contain any OP_CODESEPERATOR, the scriptCode is a varInt for the length of the witnessScript, followed by the witnessScript.
+**if the witnessScript contains any OP_CODESEPERATOR, the scriptCode is the evaluated script, with all OP_CODESEPARATOR and everything up to the last OP_CODESEPARATOR before the signature checking opcode being executed removed, and prepended by a varInt for the length of the trancated script.
 
 The item 6 is a 8-byte value of the amount of bitcoin spent in this input.
 
-hashPrevouts:
-*If the ANYONECANPAY flag is not set, hashPrevouts is the double SHA256 of the serialization of all transaction ids and output indexes involved in this transaction;
-*Otherwise, hashPrevouts is a uint256 of 0x0000......0000.
+hashPrevouts:
+*If the ANYONECANPAY flag is not set, hashPrevouts is the double SHA256 of the serialization of all input outpoints;
+*Otherwise, hashPrevouts is a uint256 of 0x0000......0000.
 
-hashSequence:
+hashSequence:
 *If none of the ANYONECANPAY, SINGLE, NONE sighash type is set, hashSequence is the double SHA256 of the serialization of nSequence of all inputs;
-*Otherwise, hashSequence is a uint256 of 0x0000......0000.
+*Otherwise, hashSequence is a uint256 of 0x0000......0000.
 
-hashOutputs:
-*If the sighash type is neither SINGLE nor NONE, hashOutputs is the double SHA256 of the serialization of all output scriptPubKey with value;
-*If sighash type is SINGLE and the input index is not greater than the number of outputs, hashOutputs is the double SHA256 of the output scriptPubKey with value of the same index as the input;
-*Otherwise, hashOutputs is a uint256 of 0x0000......0000.
+hashOutputs:
+*If the sighash type is neither SINGLE nor NONE, hashOutputs is the double SHA256 of the serialization of all output value (8-byte little endian) with scriptPubKey (varInt for the length + script);
+*If sighash type is SINGLE and the input index is not greater than the number of outputs, hashOutputs is the double SHA256 of the output value with scriptPubKey of the same index as the input;
+*Otherwise, hashOutputs is a uint256 of 0x0000......0000.
 
-The hashPrevouts, hashSequence, and hashOutputs calculated in an earlier verification may be reused in other inputs of the same transaction, so that the time complexity of the whole hashing process reduces from O(n2) to O(n).
+The hashPrevouts, hashSequence, and hashOutputs calculated in an earlier verification may be reused in other inputs of the same transaction, so that the time complexity of the whole hashing process reduces from O(n2) to O(n).
 
 Refer to the reference implementation, reproduced below, for the precise algorithm:
 

From 7e4dec0d9368a3b8c795fa25fe813932e16a57fb Mon Sep 17 00:00:00 2001
From: Johnson Lau 
Date: Thu, 21 Jan 2016 22:53:32 +0800
Subject: [PATCH 161/259] Links to reference implementation

---
 bip-0141.mediawiki | 2 +-
 bip-0142.mediawiki | 2 ++
 bip-0143.mediawiki | 6 +++---
 bip-0144.mediawiki | 2 +-
 4 files changed, 7 insertions(+), 5 deletions(-)

diff --git a/bip-0141.mediawiki b/bip-0141.mediawiki
index 74fbf0f6..dc497434 100644
--- a/bip-0141.mediawiki
+++ b/bip-0141.mediawiki
@@ -254,7 +254,7 @@ Special thanks to Gregory Maxwell for originating many of the ideas in this BIP
 
 == Reference Implementation ==
 
-https://github.com/sipa/bitcoin/commits/segwit3
+https://github.com/sipa/bitcoin/commits/segwit
 
 == References ==
 
diff --git a/bip-0142.mediawiki b/bip-0142.mediawiki
index 7d7b1d26..6e90757b 100644
--- a/bip-0142.mediawiki
+++ b/bip-0142.mediawiki
@@ -140,6 +140,8 @@ Using 0x06 as witness version, followed 0x00 as witness version, and a 0x00 padd
  
 == Reference implementation ==
 
+https://github.com/theuni/bitcoin/commit/ede1b57058ac8efdefe61f67395affb48f2c0d80
+
 == References ==
 
 * [[bip-0013.mediawiki|BIP 13: Address Format for pay-to-script-hash]]
diff --git a/bip-0143.mediawiki b/bip-0143.mediawiki
index 093e477e..29e5e07e 100644
--- a/bip-0143.mediawiki
+++ b/bip-0143.mediawiki
@@ -1,4 +1,4 @@
-
+
   BIP: 143
   Title: Transaction Signature Verification for Version 0 Witness Program
   Author: Johnson Lau 
@@ -41,7 +41,7 @@ The item 5:
 *For P2WPKH witness program, the scriptCode is 0x1976a914{20-byte-pubkey-hash}88ac.
 *For P2WSH witness program,
 **if the witnessScript does not contain any OP_CODESEPERATOR, the scriptCode is a varInt for the length of the witnessScript, followed by the witnessScript.
-**if the witnessScript contains any OP_CODESEPERATOR, the scriptCode is the evaluated script, with all OP_CODESEPARATOR and everything up to the last OP_CODESEPARATOR before the signature checking opcode being executed removed, and prepended by a varInt for the length of the trancated script.
+**if the witnessScript contains any OP_CODESEPERATOR, the scriptCode is the evaluated script, with all OP_CODESEPARATOR and everything up to the last OP_CODESEPARATOR before the signature checking opcode being executed removed, and prepended by a varInt for the length of the truncated script.
 
 The item 6 is a 8-byte value of the amount of bitcoin spent in this input.
 
@@ -191,7 +191,7 @@ As a soft fork, older software will continue to operate without modification. No
 
 == Reference Implementation ==
 
-https://github.com/sipa/bitcoin/commits/segwit3
+https://github.com/sipa/bitcoin/commits/segwit
 
 == References ==
 
diff --git a/bip-0144.mediawiki b/bip-0144.mediawiki
index 736fadd4..e3843a8f 100644
--- a/bip-0144.mediawiki
+++ b/bip-0144.mediawiki
@@ -116,7 +116,7 @@ MSG_WITNESS_BLOCK requests will return a block message with transactions that ha
 Special thanks to Gregory Maxwell for originating many of the ideas in this BIP and Luke-Jr for figuring out how to deploy this as a soft fork.
 
 == Reference Implementation ==
-https://github.com/sipa/bitcoin/commits/segwit3
+https://github.com/sipa/bitcoin/commits/segwit
 
 == Copyright ==
 This document is placed in the public domain.

From ec5b1c097e55ebb01d75c2253987e5772d98d112 Mon Sep 17 00:00:00 2001
From: Johnson Lau 
Date: Thu, 21 Jan 2016 23:24:10 +0800
Subject: [PATCH 162/259] Clarifying the behavior of OP_CODESEPERATOR

---
 bip-0143.mediawiki | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/bip-0143.mediawiki b/bip-0143.mediawiki
index 29e5e07e..72ef22d7 100644
--- a/bip-0143.mediawiki
+++ b/bip-0143.mediawiki
@@ -35,6 +35,8 @@ A new transaction digest algorithm is defined, but only applicable to sigops in
      9. nLocktime of the transaction (4-byte little endian)
     10. sighash type of the signature (4-byte little endian)
 
+All components in the original algorithm, including the behavior OP_CODESEPERATOR, remains unchanged. The only difference is the way of serialization and the inclusion of amount being spent.
+
 The items 1, 4, 7, 9, 10 have the same meaning as the original algorithm. 
 
 The item 5:

From 1ae904c0115a109ee78c9d8c9ca6cb88b9bdfde4 Mon Sep 17 00:00:00 2001
From: Guilherme Salgado 
Date: Thu, 21 Jan 2016 12:32:11 +0000
Subject: [PATCH 163/259] Add Copyright sections to bip-0080 and bip-0081

---
 bip-0080.mediawiki | 4 ++++
 bip-0081.mediawiki | 4 ++++
 2 files changed, 8 insertions(+)

diff --git a/bip-0080.mediawiki b/bip-0080.mediawiki
index 2d150755..f28bb70f 100644
--- a/bip-0080.mediawiki
+++ b/bip-0080.mediawiki
@@ -64,6 +64,10 @@ Public derivation is used at this level.
 
 * [[https://github.com/btcsuite/btcwallet|btcwallet]] is the reference Bitcoin wallet for voting pools.
 
+==Copyright==
+
+This document is placed in the public domain.
+
 ==Reference==
 
 * [[bip-0032.mediawiki|BIP32 - Hierarchical Deterministic Wallets]]
diff --git a/bip-0081.mediawiki b/bip-0081.mediawiki
index bc8d7fbb..5157c094 100644
--- a/bip-0081.mediawiki
+++ b/bip-0081.mediawiki
@@ -60,6 +60,10 @@ Public derivation is used at this level.
 
 * [[https://github.com/btcsuite/btcwallet|btcwallet]] is the reference Bitcoin wallet for voting pools.
 
+==Copyright==
+
+This document is placed in the public domain.
+
 ==Reference==
 
 * [[bip-0032.mediawiki|BIP32 - Hierarchical Deterministic Wallets]]

From 5bb4115c11d06bd4324ac9c0ffa859e17f7c2286 Mon Sep 17 00:00:00 2001
From: Thomas Kerin 
Date: Sat, 23 Jan 2016 01:31:45 +0000
Subject: [PATCH 164/259] typo in references

---
 bip-0142.mediawiki | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/bip-0142.mediawiki b/bip-0142.mediawiki
index 112a4729..ff831cbe 100644
--- a/bip-0142.mediawiki
+++ b/bip-0142.mediawiki
@@ -146,7 +146,7 @@ https://github.com/theuni/bitcoin/commit/ede1b57058ac8efdefe61f67395affb48f2c0d8
 
 * [[bip-0013.mediawiki|BIP 13: Address Format for pay-to-script-hash]]
 * [[bip-0016.mediawiki|BIP 16: Pay to Script Hash]]
-* [[bip-0070.mediawiki|BIP 70: Payment Protocal]]
+* [[bip-0070.mediawiki|BIP 70: Payment Protocol]]
 * [[bip-0141.mediawiki|BIP 141: Segregated Witness]]
 
 == Copyright ==

From 174845b3cd8de3978f321386a713d77e9d6cf08c Mon Sep 17 00:00:00 2001
From: Kirill Fomichev 
Date: Sat, 23 Jan 2016 13:40:03 +0500
Subject: [PATCH 165/259] BIP 141: fix URLs

---
 bip-0141.mediawiki | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/bip-0141.mediawiki b/bip-0141.mediawiki
index 7266e9d7..ecfb5622 100644
--- a/bip-0141.mediawiki
+++ b/bip-0141.mediawiki
@@ -21,7 +21,7 @@ The entirety of the transaction's effects are determined by output consumption (
 
 By removing this data from the transaction structure committed to the transaction merkle tree, several problems are fixed:
 
-# '''Nonintentional malleability becomes impossible'''. Since signature data is no longer part of the transaction hash, changes to how the transaction was signed are no longer relevant to transaction identification. As a solution of transaction malleability, this is superior to the canonical signature approach ([https://github.com/bitcoin/bips/edit/master/bip-0062.mediawiki BIP62]):
+# '''Nonintentional malleability becomes impossible'''. Since signature data is no longer part of the transaction hash, changes to how the transaction was signed are no longer relevant to transaction identification. As a solution of transaction malleability, this is superior to the canonical signature approach ([https://github.com/bitcoin/bips/blob/master/bip-0062.mediawiki BIP62]):
 #* It prevents involuntary transaction malleability for any type of scripts, as long as all inputs are signed (with at least one CHECKSIG or CHECKMULTISIG operation)
 #* In the case of an m-of-n CHECKMULTISIG script, a transaction is malleable only with agreement of m private key holders (as opposed to only 1 private key holder with BIP62)
 #* It prevents involuntary transaction malleability due to unknown ECDSA signature malleability
@@ -206,9 +206,9 @@ The 32-byte limitation for witness program could be easily extended through a so
 
 === Per-input lock-time and relative-lock-time ===
 
-Currently there is only one nLockTime field in a transaction and all inputs must share the same value. [https://github.com/bitcoin/bips/edit/master/bip-0068.mediawiki BIP68] enables per-input relative-lock-time using the nSequence field, however, with a limited lock-time period and resolution.
+Currently there is only one nLockTime field in a transaction and all inputs must share the same value. [https://github.com/bitcoin/bips/blob/master/bip-0068.mediawiki BIP68] enables per-input relative-lock-time using the nSequence field, however, with a limited lock-time period and resolution.
 
-With a soft fork, it is possible to introduce a separate witness structure to allow per-input lock-time and relative-lock-time, and a new script system that could sign and manipulate the new data (like [https://github.com/bitcoin/bips/edit/master/bip-0065.mediawiki BIP65] and [https://github.com/bitcoin/bips/edit/master/bip-0112.mediawiki BIP112]).
+With a soft fork, it is possible to introduce a separate witness structure to allow per-input lock-time and relative-lock-time, and a new script system that could sign and manipulate the new data (like [https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki BIP65] and [https://github.com/bitcoin/bips/blob/master/bip-0112.mediawiki BIP112]).
 
 == Backward compatibility ==
 

From b915ba5378df097644d3d2b66aca86c3a5f09112 Mon Sep 17 00:00:00 2001
From: Johnson Lau 
Date: Sun, 24 Jan 2016 19:10:39 +0800
Subject: [PATCH 166/259] Clarify txid and wtxid

---
 bip-0141.mediawiki | 28 +++++++++++++++++++++++++---
 1 file changed, 25 insertions(+), 3 deletions(-)

diff --git a/bip-0141.mediawiki b/bip-0141.mediawiki
index 7266e9d7..9a5068ef 100644
--- a/bip-0141.mediawiki
+++ b/bip-0141.mediawiki
@@ -34,13 +34,35 @@ By removing this data from the transaction structure committed to the transactio
 
 ==Specification==
 
+=== Transaction ID ===
+
+A new data structure, witness, is defined. Each transaction will have 2 IDs.
+
+Definition of txid remains unchanged: the double SHA256 of the traditional serialization format:
+  
+  [nVersion][txins][txouts][nLockTime]
+  
+A new wtxid is defined: the double SHA256 of the new serialization with witness data:
+  
+  [nVersion][marker][flag][txins][txouts][witness][nLockTime]
+  
+Format of nVersion, txins, txouts, and nLockTime are same as traditional serialization.
+
+The marker MUST be 0x00.
+
+The flag MUST be a 1-byte non-zero value. Currently, 0x01 MUST be used.
+
+The witness is a serialization of all witness data of the transaction. Each txin is associated with a witness field. A witness field starts with a var_int to indicate the number of stack items for the txin. It is followed by stack items, with each item starts with a var_int to indicate the length. Witness data is NOT script and is not restricted by the 520-byte push limit.
+
+A non-witness program (defined hereinafter) txin MUST be associated with an empty witness field, represented by a 0x00. If all txins are not witness program, a transaction's wtxid is equal to its txid.
+
 === Commitment structure ===
 
-A new block rule is added which requires a commitment to the witness hashes, the double SHA256 of a transaction including witnesses. The witness hash of coinbase transaction is assumed to be 0x0000....0000.
+A new block rule is added which requires a commitment to the wtxid. The wtxid of coinbase transaction is assumed to be 0x0000....0000.
 
-A witness root hash is calculated with all those witness hashes as leaves, in a way similar to the hashMerkleRoot in the block header.
+A witness root hash is calculated with all those wtxid as leaves, in a way similar to the hashMerkleRoot in the block header.
 
-The commitment is recorded in a scriptPubKey of the coinbase transaction. It must be at least 38 bytes, with the first 6-byte of 0x6a24aa21a9ed, that is:
+The commitment is recorded in a scriptPubKey of the coinbase transaction. It must be at least 38 bytes, with the first 6-byte of 0x6a24aa21a9ed, that is:
   
    1-byte - OP_RETURN (0x6a)
    1-byte - Push the following 36 bytes (0x24)

From ecdfa0a029b7dc25a1a10dbf773e73f8c2b01769 Mon Sep 17 00:00:00 2001
From: Eric Lombrozo 
Date: Sun, 24 Jan 2016 04:41:29 -0800
Subject: [PATCH 167/259] Script witness encoding.

---
 bip-0144.mediawiki | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/bip-0144.mediawiki b/bip-0144.mediawiki
index 233fbc33..9b2422bb 100644
--- a/bip-0144.mediawiki
+++ b/bip-0144.mediawiki
@@ -63,8 +63,8 @@ The serialization has the following structure:
 | A list of one or more transaction outputs
 |-
 | 1+
-| witness
-| witness
+| script_witnesses
+| script_witnesses[]
 | The witness structure as a serialized byte array
 |-
 | 4
@@ -77,7 +77,7 @@ Parsers supporting this BIP will be able to distinguish between the old serializ
 
 If the witness is empty, the old serialization format should be used. 
 
-Witness objects can be extended to contain other kinds of witness data not yet specified. This BIP is agnostic to the witness data structure, defined in [https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki BIP141] (Consensus segwit BIP), and treats it as an arbitrary byte array.
+Currently, the only witness objects type supported are script witnesses which consist of a stack of byte arrays. It is encoded as a var_int item count followed by each item encoded as a var_int length followed by a string of bytes. Each txin has its own script witness. The number of script witnesses is not explicitly encoded as it is implied by txin_count. Empty script witnesses are encoded as a zero byte. The order of the script witnesses follows the same order as the associated txins.
 
 * '''Rationale for not having an independent message type with its own serialization''': this would require separate "tx" and "block" messages, and all RPC calls operating on raw transactions would need to be duplicated, or need inefficinent or nondeterministic guesswork to know which type is to be used.
 

From 6d701a3ea852e908ef2d308fb5bf8ef14bd2d6e8 Mon Sep 17 00:00:00 2001
From: Jonathan Cross 
Date: Sun, 24 Jan 2016 16:47:40 +0100
Subject: [PATCH 168/259] Improvements to BIP 122

Grammar, punctuation and labeling improvements meant to clarify the BIP and improve readability.
---
 bip-0122.mediawiki | 24 ++++++++++++------------
 1 file changed, 12 insertions(+), 12 deletions(-)

diff --git a/bip-0122.mediawiki b/bip-0122.mediawiki
index d59e3537..17003aa5 100644
--- a/bip-0122.mediawiki
+++ b/bip-0122.mediawiki
@@ -10,13 +10,13 @@
 
 ==Abstract==
 
-This BIP propose an URI scheme for looking up blocks, transactions, addresses on a Blockchain explorer, or in general to make proper Blockchain references
+This BIP proposes a URI scheme for looking up blocks, transactions and addresses on a Blockchain explorer, or in general to make proper Blockchain references.
 
 ==Motivation==
 
 The purpose of this URI scheme is to enable users to handle all the requests for details about blocks, transactions, etc. with their preferred tool (being that a web service or a local application).
-Currently a Bitcoin client usually points to an arbitrary blockchain explorer when the user looks for the details of a transaction, or let him choose from a limited list of possible alternatives.
-Other times resorting to cut&paste is needed.
+Currently a Bitcoin client usually points to an arbitrary blockchain explorer when the user looks for the details of a transaction or allows the user to choose from a set of alternatives.
+Resorting to copy + paste into a browser is often required.
 The same happens with posts and messages that reference some particular txs or blocks, if they provide links at all.
 
 ==Specification==
@@ -30,7 +30,7 @@ Where:
 {| class="wikitable"
 ! style="text-align: center;" | Element
 ! colspan="2" style="text-align: center;" | Description
-! 
+! Required?
 |-
 | chain
 | colspan="2" | '''chain ID''' (see below) of the desired chain, leading 0s included. If omitted (which would be the usual case), Bitcoin main net is assumed.
@@ -39,7 +39,7 @@ Where:
 | rowspan="3" | type
 | tx
 | for transactions.
-| rowspan="3" | 
+| rowspan="3" | required 
 |-
 | block
 | for blocks (supports both hash or height).
@@ -49,7 +49,7 @@ Where:
 |-
 | hash
 | colspan="2" | the relevant hash to refer to (leading zeros included), or block height.
-| 
+| required
 |}
 
 ====ABNF grammar====
@@ -104,20 +104,20 @@ A transaction on Bitcoin test net:
 
 ==Rationale==
 
-From the point of view of a wallet (or other Blockchain related tool) developer that need to show any kind of Blockchain references, using this scheme mean that he can simply make it a blockchain: link and be done with it, without having to worry about any specific Blockchain explorer or provide a means for the user to select one.
+From the point of view of a wallet (or other Blockchain related tool) developers which need to reference Blockchain data, using this scheme mean that he can simply make it a `blockchain:` link without having to worry about any specific Blockchain explorer or provide a means for the user to select one.
 
-Blockchain explorers in turn will simply offer to handle the blockchain: URI, the first time the user visit their website, or launch/install the application, or even set themselves if there isn't already one.
+Blockchain explorers in turn will simply offer to handle the `blockchain:` URI schema, the first time the user visit their website, or launch/install the application, or even set themselves if there isn't already one.
 
-Users get the convenience of using always their preferred explorer, which can be especially handy on mobile devices, where juggling with cut&paste is far from ideal.
+Users can link directly to their preferred block explorer (avoiding copy + paste which can be awkward on mobile devices).
 
 == Sample implementation ==
 
 [https://github.com/MarcoPon/blockchain-exploration Demo Blockchain: URI handler on GitHub]
 
 ==Acknowledgements==
-Thanks to Btc Drak for suggesting to provide support for different networks.
-Thanks to Jorge Timon for the idea of using genesis blocks hashes to identify them.
-Thanks to Richard Moore, Matt Whitlock, Andreas Schildbach for suggestions about the structure and hierarchy of the URI scheme.
+
+Thanks to Btc Drak for suggesting support for different networks and Jorge Timon for the suggestion that we could identify each network by its genesis block hash.
+Thanks to Richard Moore, Matt Whitlock, Andreas Schildbach for help with the structure and hierarchy of the URI scheme.
 
 ==Copyright==
 

From 64a7c45e84dbfcd6c36620f3e72258bf78b9d937 Mon Sep 17 00:00:00 2001
From: Thomas Kerin 
Date: Sun, 24 Jan 2016 17:21:17 +0000
Subject: [PATCH 169/259] typo

---
 bip-0141.mediawiki | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/bip-0141.mediawiki b/bip-0141.mediawiki
index 7266e9d7..1c8abc9c 100644
--- a/bip-0141.mediawiki
+++ b/bip-0141.mediawiki
@@ -92,7 +92,7 @@ The new rule is total ''block cost'' ≤ 4,000,000.
 
 Sigops per block is currently limited to 20,000. We change this restriction as follows:
 
-''Sigop cost'' is defined. The cost of a sigop in traditoinal script is 4, while the cost of a sigop in witness program is 1.
+''Sigop cost'' is defined. The cost of a sigop in traditional script is 4, while the cost of a sigop in witness program is 1.
 
 The new rule is total ''sigop cost'' ≤ 80,000.
 

From 6a315c023f13d83c58aab98cf8668d74cf7566c7 Mon Sep 17 00:00:00 2001
From: Johnson Lau 
Date: Tue, 26 Jan 2016 01:59:00 +0800
Subject: [PATCH 170/259] BIP141 Non-upgraded wallet description

---
 bip-0141.mediawiki | 8 +++-----
 1 file changed, 3 insertions(+), 5 deletions(-)

diff --git a/bip-0141.mediawiki b/bip-0141.mediawiki
index 7114ddd2..b62d54d2 100644
--- a/bip-0141.mediawiki
+++ b/bip-0141.mediawiki
@@ -239,14 +239,13 @@ As a soft fork, older software will continue to operate without modification.  N
 '''What a non-upgraded wallet can do'''
 
 * Receiving bitcoin from non-upgraded and upgraded wallets
-* Sending bitcoin to non-upgraded wallets
-* Sending bitcoin to upgraded wallets using a P2SH address (less efficient)
-* Sending bitcoin to upgraded wallets using a native witness program (more efficient) through [https://github.com/bitcoin/bips/blob/master/bip-0070.mediawiki BIP70] payment protocol
+* Sending bitcoin to non-upgraded and upgraded wallets with traditional P2PKH address (without any benefit of segregated witness)
+* Sending bitcoin to upgraded wallets using a P2SH address
+* Sending bitcoin to upgraded wallets using a native witness program through [https://github.com/bitcoin/bips/blob/master/bip-0070.mediawiki BIP70] payment protocol
 
 '''What a non-upgraded wallet cannot do'''
 
 * Validating segregated witness transaction. It assumes such a transaction is always valid
-* Sending bitcoin to upgraded wallets using a native witness program if BIP70 is not supported
 
 == Deployment ==
 
@@ -281,7 +280,6 @@ https://github.com/sipa/bitcoin/commits/segwit
 == References ==
 
 *[[bip-0016.mediawiki|BIP16 Pay to Script Hash]]
-*[[bip-0142.mediawiki|BIP142 Address Formats for Segregated Witness]]
 *[[bip-0143.mediawiki|BIP143 Transaction Signature Verification for Version 0 Witness Program]]
 *[[bip-0144.mediawiki|BIP144 Segregated Witness (Peer Services)]]
 

From 4bf562569e43e7521d3bf3c91cb4cb11f5365bd4 Mon Sep 17 00:00:00 2001
From: Johnson Lau 
Date: Tue, 26 Jan 2016 11:48:30 +0800
Subject: [PATCH 171/259] BIP141: Add 520 bytes witness stack limit

@sipa
---
 bip-0141.mediawiki | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/bip-0141.mediawiki b/bip-0141.mediawiki
index b62d54d2..ec6b1467 100644
--- a/bip-0141.mediawiki
+++ b/bip-0141.mediawiki
@@ -52,7 +52,7 @@ The marker MUST be 0x00.
 
 The flag MUST be a 1-byte non-zero value. Currently, 0x01 MUST be used.
 
-The witness is a serialization of all witness data of the transaction. Each txin is associated with a witness field. A witness field starts with a var_int to indicate the number of stack items for the txin. It is followed by stack items, with each item starts with a var_int to indicate the length. Witness data is NOT script and is not restricted by the 520-byte push limit.
+The witness is a serialization of all witness data of the transaction. Each txin is associated with a witness field. A witness field starts with a var_int to indicate the number of stack items for the txin. It is followed by stack items, with each item starts with a var_int to indicate the length. Witness data is NOT script.
 
 A non-witness program (defined hereinafter) txin MUST be associated with an empty witness field, represented by a 0x00. If all txins are not witness program, a transaction's wtxid is equal to its txid.
 
@@ -85,20 +85,20 @@ There are two cases in which witness validation logic are triggered. Each case d
 
 If the version byte is 0, and the witness program is 20 bytes:
 * It is interpreted as a pay-to-witness-public-key-hash (P2WPKH) program.
-* The witness must consist of exactly 2 items. The first one a signature, and the second one a public key.
+* The witness must consist of exactly 2 items (≤ 520 bytes each). The first one a signature, and the second one a public key.
 * The HASH160 of the public key must match the 20-byte witness program.
 * After normal script evaluation, the signature is verified against the public key with CHECKSIG operation. The verification must result in a single TRUE on the stack.
 
 If the version byte is 0, and the witness program is 32 bytes:
 * It is interpreted as a pay-to-witness-script-hash (P2WSH) program.
 * The witness must consist of an input stack to feed to the script, followed by a serialized script ("witnessScript").
-* The witnessScript is popped off the initial witness stack. SHA256 of the witnessScript must match the 32-byte witness program.
-* The witnessScript is deserialized, and executed after normal script evaluation with the remaining witness stack.
+* The witnessScript (≤ 10,000 bytes) is popped off the initial witness stack. SHA256 of the witnessScript must match the 32-byte witness program.
+* The witnessScript is deserialized, and executed after normal script evaluation with the remaining witness stack (≤ 520 bytes for each stack item).
 * The script must not fail, and result in exactly a single TRUE on the stack.
 
 If the version byte is 0, but the witness program is neither 20 nor 32 bytes, the script must fail.
 
-If the version byte is 1 to 16, no further interpretation of the witness program or witness happens.
+If the version byte is 1 to 16, no further interpretation of the witness program or witness happens, and there is no size restriction for the witness. These versions are reserved for future extensions.
 
 === Other consensus critical limits ===
 

From e327e501676884f1366199439ef2d716b557fe13 Mon Sep 17 00:00:00 2001
From: Paolo Agazzone 
Date: Tue, 26 Jan 2016 18:20:11 +0100
Subject: [PATCH 172/259] Added bip39 Italian wordlist

---
 bip-0039/bip-0039-wordlists.md | 24 ++++++++++++++++++++++++
 1 file changed, 24 insertions(+)

diff --git a/bip-0039/bip-0039-wordlists.md b/bip-0039/bip-0039-wordlists.md
index 203ba06f..aef1a230 100644
--- a/bip-0039/bip-0039-wordlists.md
+++ b/bip-0039/bip-0039-wordlists.md
@@ -6,6 +6,7 @@
 * [Chinese (Simplified)](chinese_simplified.txt)
 * [Chinese (Traditional)](chinese_traditional.txt)
 * [French](french.txt)
+* [Italian](italian.txt)
 
 ##Wordlists (Special Considerations)
 
@@ -57,3 +58,26 @@ Credits: @Kirvx @NicolasDorier @ecdsa @EricLarch
 15. No words in conflict with the spelling corrections of 1990 (http://goo.gl/Y8DU4z).
 16. No embarrassing words (in a very, very large scope) or belonging to a particular religion.
 17. No identical words with the Spanish wordlist (as Y75QMO wants).
+
+### Italian
+
+Credits: @paoloaga @Polve
+
+Words chosen using the following rules:
+
+1. Simple and common italian words.
+2. Length between 4 and 8 characters.
+3. First 4 letters must be unique between all words.
+4. No accents or special characters.
+5. No complex verb forms.
+6. No plural words.
+7. No words that remind negative/sad/bad things.
+8. If both female/male words are available, choose male version.
+9. No words with double vocals (like: lineetta).
+10. No words already used in other language mnemonic sets.
+11. If 3 of the first 4 letters are already used in the same sequence in another mnemonic word, there must be at least other 3 different letters.
+12. If 3 of the first 4 letters are already used in the same sequence in another mnemonic word, there not must be the same sequence of 3 or more letters.
+
+Rules 11 and 12 prevent the selection words that are not different enough. This makes each word more recognizable among others and less error prone. For example: the wordlist contains "atono", then "atomo" is rejected, but "atomico" is good. 
+
+All the words have been manually selected and automatically checked against the rules.

From d3f34b99d05a45fe8ed9ac53cd0fabc4532fe4a3 Mon Sep 17 00:00:00 2001
From: Paolo Agazzone 
Date: Tue, 26 Jan 2016 18:20:11 +0100
Subject: [PATCH 173/259] Added bip39 Italian wordlist

---
 bip-0039/bip-0039-wordlists.md |   24 +
 bip-0039/italian.txt           | 2048 ++++++++++++++++++++++++++++++++
 2 files changed, 2072 insertions(+)
 create mode 100644 bip-0039/italian.txt

diff --git a/bip-0039/bip-0039-wordlists.md b/bip-0039/bip-0039-wordlists.md
index 203ba06f..aef1a230 100644
--- a/bip-0039/bip-0039-wordlists.md
+++ b/bip-0039/bip-0039-wordlists.md
@@ -6,6 +6,7 @@
 * [Chinese (Simplified)](chinese_simplified.txt)
 * [Chinese (Traditional)](chinese_traditional.txt)
 * [French](french.txt)
+* [Italian](italian.txt)
 
 ##Wordlists (Special Considerations)
 
@@ -57,3 +58,26 @@ Credits: @Kirvx @NicolasDorier @ecdsa @EricLarch
 15. No words in conflict with the spelling corrections of 1990 (http://goo.gl/Y8DU4z).
 16. No embarrassing words (in a very, very large scope) or belonging to a particular religion.
 17. No identical words with the Spanish wordlist (as Y75QMO wants).
+
+### Italian
+
+Credits: @paoloaga @Polve
+
+Words chosen using the following rules:
+
+1. Simple and common italian words.
+2. Length between 4 and 8 characters.
+3. First 4 letters must be unique between all words.
+4. No accents or special characters.
+5. No complex verb forms.
+6. No plural words.
+7. No words that remind negative/sad/bad things.
+8. If both female/male words are available, choose male version.
+9. No words with double vocals (like: lineetta).
+10. No words already used in other language mnemonic sets.
+11. If 3 of the first 4 letters are already used in the same sequence in another mnemonic word, there must be at least other 3 different letters.
+12. If 3 of the first 4 letters are already used in the same sequence in another mnemonic word, there not must be the same sequence of 3 or more letters.
+
+Rules 11 and 12 prevent the selection words that are not different enough. This makes each word more recognizable among others and less error prone. For example: the wordlist contains "atono", then "atomo" is rejected, but "atomico" is good. 
+
+All the words have been manually selected and automatically checked against the rules.
diff --git a/bip-0039/italian.txt b/bip-0039/italian.txt
new file mode 100644
index 00000000..c47370f4
--- /dev/null
+++ b/bip-0039/italian.txt
@@ -0,0 +1,2048 @@
+abaco
+abbaglio
+abbinato
+abete
+abisso
+abolire
+abrasivo
+abrogato
+accadere
+accenno
+accusato
+acetone
+achille
+acido
+acqua
+acre
+acrilico
+acrobata
+acuto
+adagio
+addebito
+addome
+adeguato
+aderire
+adipe
+adottare
+adulare
+affabile
+affetto
+affisso
+affranto
+aforisma
+afoso
+africano
+agave
+agente
+agevole
+aggancio
+agire
+agitare
+agonismo
+agricolo
+agrumeto
+aguzzo
+alabarda
+alato
+albatro
+alberato
+albo
+albume
+alce
+alcolico
+alettone
+alfa
+algebra
+aliante
+alibi
+alimento
+allagato
+allegro
+allievo
+allodola
+allusivo
+almeno
+alogeno
+alpaca
+alpestre
+altalena
+alterno
+alticcio
+altrove
+alunno
+alveolo
+alzare
+amalgama
+amanita
+amarena
+ambito
+ambrato
+ameba
+america
+ametista
+amico
+ammasso
+ammenda
+ammirare
+ammonito
+amore
+ampio
+ampliare
+amuleto
+anacardo
+anagrafe
+analista
+anarchia
+anatra
+anca
+ancella
+ancora
+andare
+andrea
+anello
+angelo
+angolare
+angusto
+anima
+annegare
+annidato
+anno
+annuncio
+anonimo
+anticipo
+anzi
+apatico
+apertura
+apode
+apparire
+appetito
+appoggio
+approdo
+appunto
+aprile
+arabica
+arachide
+aragosta
+araldica
+arancio
+aratura
+arazzo
+arbitro
+archivio
+ardito
+arenile
+argento
+argine
+arguto
+aria
+armonia
+arnese
+arredato
+arringa
+arrosto
+arsenico
+arso
+artefice
+arzillo
+asciutto
+ascolto
+asepsi
+asettico
+asfalto
+asino
+asola
+aspirato
+aspro
+assaggio
+asse
+assoluto
+assurdo
+asta
+astenuto
+astice
+astratto
+atavico
+ateismo
+atomico
+atono
+attesa
+attivare
+attorno
+attrito
+attuale
+ausilio
+austria
+autista
+autonomo
+autunno
+avanzato
+avere
+avvenire
+avviso
+avvolgere
+azione
+azoto
+azzimo
+azzurro
+babele
+baccano
+bacino
+baco
+badessa
+badilata
+bagnato
+baita
+balcone
+baldo
+balena
+ballata
+balzano
+bambino
+bandire
+baraonda
+barbaro
+barca
+baritono
+barlume
+barocco
+basilico
+basso
+batosta
+battuto
+baule
+bava
+bavosa
+becco
+beffa
+belgio
+belva
+benda
+benevole
+benigno
+benzina
+bere
+berlina
+beta
+bibita
+bici
+bidone
+bifido
+biga
+bilancia
+bimbo
+binocolo
+biologo
+bipede
+bipolare
+birbante
+birra
+biscotto
+bisesto
+bisnonno
+bisonte
+bisturi
+bizzarro
+blando
+blatta
+bollito
+bonifico
+bordo
+bosco
+botanico
+bottino
+bozzolo
+braccio
+bradipo
+brama
+branca
+bravura
+bretella
+brevetto
+brezza
+briglia
+brillante
+brindare
+broccolo
+brodo
+bronzina
+brullo
+bruno
+bubbone
+buca
+budino
+buffone
+buio
+bulbo
+buono
+burlone
+burrasca
+bussola
+busta
+cadetto
+caduco
+calamaro
+calcolo
+calesse
+calibro
+calmo
+caloria
+cambusa
+camerata
+camicia
+cammino
+camola
+campale
+canapa
+candela
+cane
+canino
+canotto
+cantina
+capace
+capello
+capitolo
+capogiro
+cappero
+capra
+capsula
+carapace
+carcassa
+cardo
+carisma
+carovana
+carretto
+cartolina
+casaccio
+cascata
+caserma
+caso
+cassone
+castello
+casuale
+catasta
+catena
+catrame
+cauto
+cavillo
+cedibile
+cedrata
+cefalo
+celebre
+cellulare
+cena
+cenone
+centesimo
+ceramica
+cercare
+certo
+cerume
+cervello
+cesoia
+cespo
+ceto
+chela
+chiaro
+chicca
+chiedere
+chimera
+china
+chirurgo
+chitarra
+ciao
+ciclismo
+cifrare
+cigno
+cilindro
+ciottolo
+circa
+cirrosi
+citrico
+cittadino
+ciuffo
+civetta
+civile
+classico
+clinica
+cloro
+cocco
+codardo
+codice
+coerente
+cognome
+collare
+colmato
+colore
+colposo
+coltivato
+colza
+coma
+cometa
+commando
+comodo
+computer
+comune
+conciso
+condurre
+conferma
+congelare
+coniuge
+connesso
+conoscere
+consumo
+continuo
+convegno
+coperto
+copione
+coppia
+copricapo
+corazza
+cordata
+coricato
+cornice
+corolla
+corpo
+corredo
+corsia
+cortese
+cosmico
+costante
+cottura
+covato
+cratere
+cravatta
+creato
+credere
+cremoso
+crescita
+creta
+criceto
+crinale
+crisi
+critico
+croce
+cronaca
+crostata
+cruciale
+crusca
+cucire
+cuculo
+cugino
+cullato
+cupola
+curatore
+cursore
+curvo
+cuscino
+custode
+dado
+daino
+dalmata
+damerino
+daniela
+dannoso
+danzare
+datato
+davanti
+davvero
+debutto
+decennio
+deciso
+declino
+decollo
+decreto
+dedicato
+definito
+deforme
+degno
+delegare
+delfino
+delirio
+delta
+demenza
+denotato
+dentro
+deposito
+derapata
+derivare
+deroga
+descritto
+deserto
+desiderio
+desumere
+detersivo
+devoto
+diametro
+dicembre
+diedro
+difeso
+diffuso
+digerire
+digitale
+diluvio
+dinamico
+dinnanzi
+dipinto
+diploma
+dipolo
+diradare
+dire
+dirotto
+dirupo
+disagio
+discreto
+disfare
+disgelo
+disposto
+distanza
+disumano
+dito
+divano
+divelto
+dividere
+divorato
+doblone
+docente
+doganale
+dogma
+dolce
+domato
+domenica
+dominare
+dondolo
+dono
+dormire
+dote
+dottore
+dovuto
+dozzina
+drago
+druido
+dubbio
+dubitare
+ducale
+duna
+duomo
+duplice
+duraturo
+ebano
+eccesso
+ecco
+eclissi
+economia
+edera
+edicola
+edile
+editoria
+educare
+egemonia
+egli
+egoismo
+egregio
+elaborato
+elargire
+elegante
+elencato
+eletto
+elevare
+elfico
+elica
+elmo
+elsa
+eluso
+emanato
+emblema
+emesso
+emiro
+emotivo
+emozione
+empirico
+emulo
+endemico
+enduro
+energia
+enfasi
+enoteca
+entrare
+enzima
+epatite
+epilogo
+episodio
+epocale
+eppure
+equatore
+erario
+erba
+erboso
+erede
+eremita
+erigere
+ermetico
+eroe
+erosivo
+errante
+esagono
+esame
+esanime
+esaudire
+esca
+esempio
+esercito
+esibito
+esigente
+esistere
+esito
+esofago
+esortato
+esoso
+espanso
+espresso
+essenza
+esso
+esteso
+estimare
+estonia
+estroso
+esultare
+etilico
+etnico
+etrusco
+etto
+euclideo
+europa
+evaso
+evidenza
+evitato
+evoluto
+evviva
+fabbrica
+faccenda
+fachiro
+falco
+famiglia
+fanale
+fanfara
+fango
+fantasma
+fare
+farfalla
+farinoso
+farmaco
+fascia
+fastoso
+fasullo
+faticare
+fato
+favoloso
+febbre
+fecola
+fede
+fegato
+felpa
+feltro
+femmina
+fendere
+fenomeno
+fermento
+ferro
+fertile
+fessura
+festivo
+fetta
+feudo
+fiaba
+fiducia
+fifa
+figurato
+filo
+finanza
+finestra
+finire
+fiore
+fiscale
+fisico
+fiume
+flacone
+flamenco
+flebo
+flemma
+florido
+fluente
+fluoro
+fobico
+focaccia
+focoso
+foderato
+foglio
+folata
+folclore
+folgore
+fondente
+fonetico
+fonia
+fontana
+forbito
+forchetta
+foresta
+formica
+fornaio
+foro
+fortezza
+forzare
+fosfato
+fosso
+fracasso
+frana
+frassino
+fratello
+freccetta
+frenata
+fresco
+frigo
+frollino
+fronde
+frugale
+frutta
+fucilata
+fucsia
+fuggente
+fulmine
+fulvo
+fumante
+fumetto
+fumoso
+fune
+funzione
+fuoco
+furbo
+furgone
+furore
+fuso
+futile
+gabbiano
+gaffe
+galateo
+gallina
+galoppo
+gambero
+gamma
+garanzia
+garbo
+garofano
+garzone
+gasdotto
+gasolio
+gastrico
+gatto
+gaudio
+gazebo
+gazzella
+geco
+gelatina
+gelso
+gemello
+gemmato
+gene
+genitore
+gennaio
+genotipo
+gergo
+ghepardo
+ghiaccio
+ghisa
+giallo
+gilda
+ginepro
+giocare
+gioiello
+giorno
+giove
+girato
+girone
+gittata
+giudizio
+giurato
+giusto
+globulo
+glutine
+gnomo
+gobba
+golf
+gomito
+gommone
+gonfio
+gonna
+governo
+gracile
+grado
+grafico
+grammo
+grande
+grattare
+gravoso
+grazia
+greca
+gregge
+grifone
+grigio
+grinza
+grotta
+gruppo
+guadagno
+guaio
+guanto
+guardare
+gufo
+guidare
+ibernato
+icona
+identico
+idillio
+idolo
+idra
+idrico
+idrogeno
+igiene
+ignaro
+ignorato
+ilare
+illeso
+illogico
+illudere
+imballo
+imbevuto
+imbocco
+imbuto
+immane
+immerso
+immolato
+impacco
+impeto
+impiego
+importo
+impronta
+inalare
+inarcare
+inattivo
+incanto
+incendio
+inchino
+incisivo
+incluso
+incontro
+incrocio
+incubo
+indagine
+india
+indole
+inedito
+infatti
+infilare
+inflitto
+ingaggio
+ingegno
+inglese
+ingordo
+ingrosso
+innesco
+inodore
+inoltrare
+inondato
+insano
+insetto
+insieme
+insonnia
+insulina
+intasato
+intero
+intonaco
+intuito
+inumidire
+invalido
+invece
+invito
+iperbole
+ipnotico
+ipotesi
+ippica
+iride
+irlanda
+ironico
+irrigato
+irrorare
+isolato
+isotopo
+isterico
+istituto
+istrice
+italia
+iterare
+labbro
+labirinto
+lacca
+lacerato
+lacrima
+lacuna
+laddove
+lago
+lampo
+lancetta
+lanterna
+lardoso
+larga
+laringe
+lastra
+latenza
+latino
+lattuga
+lavagna
+lavoro
+legale
+leggero
+lembo
+lentezza
+lenza
+leone
+lepre
+lesivo
+lessato
+lesto
+letterale
+leva
+levigato
+libero
+lido
+lievito
+lilla
+limatura
+limitare
+limpido
+lineare
+lingua
+liquido
+lira
+lirica
+lisca
+lite
+litigio
+livrea
+locanda
+lode
+logica
+lombare
+londra
+longevo
+loquace
+lorenzo
+loto
+lotteria
+luce
+lucidato
+lumaca
+luminoso
+lungo
+lupo
+luppolo
+lusinga
+lusso
+lutto
+macabro
+macchina
+macero
+macinato
+madama
+magico
+maglia
+magnete
+magro
+maiolica
+malafede
+malgrado
+malinteso
+malsano
+malto
+malumore
+mana
+mancia
+mandorla
+mangiare
+manifesto
+mannaro
+manovra
+mansarda
+mantide
+manubrio
+mappa
+maratona
+marcire
+maretta
+marmo
+marsupio
+maschera
+massaia
+mastino
+materasso
+matricola
+mattone
+maturo
+mazurca
+meandro
+meccanico
+mecenate
+medesimo
+meditare
+mega
+melassa
+melis
+melodia
+meninge
+meno
+mensola
+mercurio
+merenda
+merlo
+meschino
+mese
+messere
+mestolo
+metallo
+metodo
+mettere
+miagolare
+mica
+micelio
+michele
+microbo
+midollo
+miele
+migliore
+milano
+milite
+mimosa
+minerale
+mini
+minore
+mirino
+mirtillo
+miscela
+missiva
+misto
+misurare
+mitezza
+mitigare
+mitra
+mittente
+mnemonico
+modello
+modifica
+modulo
+mogano
+mogio
+mole
+molosso
+monastero
+monco
+mondina
+monetario
+monile
+monotono
+monsone
+montato
+monviso
+mora
+mordere
+morsicato
+mostro
+motivato
+motosega
+motto
+movenza
+movimento
+mozzo
+mucca
+mucosa
+muffa
+mughetto
+mugnaio
+mulatto
+mulinello
+multiplo
+mummia
+munto
+muovere
+murale
+musa
+muscolo
+musica
+mutevole
+muto
+nababbo
+nafta
+nanometro
+narciso
+narice
+narrato
+nascere
+nastrare
+naturale
+nautica
+naviglio
+nebulosa
+necrosi
+negativo
+negozio
+nemmeno
+neofita
+neretto
+nervo
+nessuno
+nettuno
+neutrale
+neve
+nevrotico
+nicchia
+ninfa
+nitido
+nobile
+nocivo
+nodo
+nome
+nomina
+nordico
+normale
+norvegese
+nostrano
+notare
+notizia
+notturno
+novella
+nucleo
+nulla
+numero
+nuovo
+nutrire
+nuvola
+nuziale
+oasi
+obbedire
+obbligo
+obelisco
+oblio
+obolo
+obsoleto
+occasione
+occhio
+occidente
+occorrere
+occultare
+ocra
+oculato
+odierno
+odorare
+offerta
+offrire
+offuscato
+oggetto
+oggi
+ognuno
+olandese
+olfatto
+oliato
+oliva
+ologramma
+oltre
+omaggio
+ombelico
+ombra
+omega
+omissione
+ondoso
+onere
+onice
+onnivoro
+onorevole
+onta
+operato
+opinione
+opposto
+oracolo
+orafo
+ordine
+orecchino
+orefice
+orfano
+organico
+origine
+orizzonte
+orma
+ormeggio
+ornativo
+orologio
+orrendo
+orribile
+ortensia
+ortica
+orzata
+orzo
+osare
+oscurare
+osmosi
+ospedale
+ospite
+ossa
+ossidare
+ostacolo
+oste
+otite
+otre
+ottagono
+ottimo
+ottobre
+ovale
+ovest
+ovino
+oviparo
+ovocito
+ovunque
+ovviare
+ozio
+pacchetto
+pace
+pacifico
+padella
+padrone
+paese
+paga
+pagina
+palazzina
+palesare
+pallido
+palo
+palude
+pandoro
+pannello
+paolo
+paonazzo
+paprica
+parabola
+parcella
+parere
+pargolo
+pari
+parlato
+parola
+partire
+parvenza
+parziale
+passivo
+pasticca
+patacca
+patologia
+pattume
+pavone
+peccato
+pedalare
+pedonale
+peggio
+peloso
+penare
+pendice
+penisola
+pennuto
+penombra
+pensare
+pentola
+pepe
+pepita
+perbene
+percorso
+perdonato
+perforare
+pergamena
+periodo
+permesso
+perno
+perplesso
+persuaso
+pertugio
+pervaso
+pesatore
+pesista
+peso
+pestifero
+petalo
+pettine
+petulante
+pezzo
+piacere
+pianta
+piattino
+piccino
+picozza
+piega
+pietra
+piffero
+pigiama
+pigolio
+pigro
+pila
+pilifero
+pillola
+pilota
+pimpante
+pineta
+pinna
+pinolo
+pioggia
+piombo
+piramide
+piretico
+pirite
+pirolisi
+pitone
+pizzico
+placebo
+planare
+plasma
+platano
+plenario
+pochezza
+poderoso
+podismo
+poesia
+poggiare
+polenta
+poligono
+pollice
+polmonite
+polpetta
+polso
+poltrona
+polvere
+pomice
+pomodoro
+ponte
+popoloso
+porfido
+poroso
+porpora
+porre
+portata
+posa
+positivo
+possesso
+postulato
+potassio
+potere
+pranzo
+prassi
+pratica
+precluso
+predica
+prefisso
+pregiato
+prelievo
+premere
+prenotare
+preparato
+presenza
+pretesto
+prevalso
+prima
+principe
+privato
+problema
+procura
+produrre
+profumo
+progetto
+prolunga
+promessa
+pronome
+proposta
+proroga
+proteso
+prova
+prudente
+prugna
+prurito
+psiche
+pubblico
+pudica
+pugilato
+pugno
+pulce
+pulito
+pulsante
+puntare
+pupazzo
+pupilla
+puro
+quadro
+qualcosa
+quasi
+querela
+quota
+raccolto
+raddoppio
+radicale
+radunato
+raffica
+ragazzo
+ragione
+ragno
+ramarro
+ramingo
+ramo
+randagio
+rantolare
+rapato
+rapina
+rappreso
+rasatura
+raschiato
+rasente
+rassegna
+rastrello
+rata
+ravveduto
+reale
+recepire
+recinto
+recluta
+recondito
+recupero
+reddito
+redimere
+regalato
+registro
+regola
+regresso
+relazione
+remare
+remoto
+renna
+replica
+reprimere
+reputare
+resa
+residente
+responso
+restauro
+rete
+retina
+retorica
+rettifica
+revocato
+riassunto
+ribadire
+ribelle
+ribrezzo
+ricarica
+ricco
+ricevere
+riciclato
+ricordo
+ricreduto
+ridicolo
+ridurre
+rifasare
+riflesso
+riforma
+rifugio
+rigare
+rigettato
+righello
+rilassato
+rilevato
+rimanere
+rimbalzo
+rimedio
+rimorchio
+rinascita
+rincaro
+rinforzo
+rinnovo
+rinomato
+rinsavito
+rintocco
+rinuncia
+rinvenire
+riparato
+ripetuto
+ripieno
+riportare
+ripresa
+ripulire
+risata
+rischio
+riserva
+risibile
+riso
+rispetto
+ristoro
+risultato
+risvolto
+ritardo
+ritegno
+ritmico
+ritrovo
+riunione
+riva
+riverso
+rivincita
+rivolto
+rizoma
+roba
+robotico
+robusto
+roccia
+roco
+rodaggio
+rodere
+roditore
+rogito
+rollio
+romantico
+rompere
+ronzio
+rosolare
+rospo
+rotante
+rotondo
+rotula
+rovescio
+rubizzo
+rubrica
+ruga
+rullino
+rumine
+rumoroso
+ruolo
+rupe
+russare
+rustico
+sabato
+sabbiare
+sabotato
+sagoma
+salasso
+saldatura
+salgemma
+salivare
+salmone
+salone
+saltare
+saluto
+salvo
+sapere
+sapido
+saporito
+saraceno
+sarcasmo
+sarto
+sassoso
+satellite
+satira
+satollo
+saturno
+savana
+savio
+saziato
+sbadiglio
+sbalzo
+sbancato
+sbarra
+sbattere
+sbavare
+sbendare
+sbirciare
+sbloccato
+sbocciato
+sbrinare
+sbruffone
+sbuffare
+scabroso
+scadenza
+scala
+scambiare
+scandalo
+scapola
+scarso
+scatenare
+scavato
+scelto
+scenico
+scettro
+scheda
+schiena
+sciarpa
+scienza
+scindere
+scippo
+sciroppo
+scivolo
+sclerare
+scodella
+scolpito
+scomparto
+sconforto
+scoprire
+scorta
+scossone
+scozzese
+scriba
+scrollare
+scrutinio
+scuderia
+scultore
+scuola
+scuro
+scusare
+sdebitare
+sdoganare
+seccatura
+secondo
+sedano
+seggiola
+segnalato
+segregato
+seguito
+selciato
+selettivo
+sella
+selvaggio
+semaforo
+sembrare
+seme
+seminato
+sempre
+senso
+sentire
+sepolto
+sequenza
+serata
+serbato
+sereno
+serio
+serpente
+serraglio
+servire
+sestina
+setola
+settimana
+sfacelo
+sfaldare
+sfamato
+sfarzoso
+sfaticato
+sfera
+sfida
+sfilato
+sfinge
+sfocato
+sfoderare
+sfogo
+sfoltire
+sforzato
+sfratto
+sfruttato
+sfuggito
+sfumare
+sfuso
+sgabello
+sgarbato
+sgonfiare
+sgorbio
+sgrassato
+sguardo
+sibilo
+siccome
+sierra
+sigla
+signore
+silenzio
+sillaba
+simbolo
+simpatico
+simulato
+sinfonia
+singolo
+sinistro
+sino
+sintesi
+sinusoide
+sipario
+sisma
+sistole
+situato
+slitta
+slogatura
+sloveno
+smarrito
+smemorato
+smentito
+smeraldo
+smilzo
+smontare
+smottato
+smussato
+snellire
+snervato
+snodo
+sobbalzo
+sobrio
+soccorso
+sociale
+sodale
+soffitto
+sogno
+soldato
+solenne
+solido
+sollazzo
+solo
+solubile
+solvente
+somatico
+somma
+sonda
+sonetto
+sonnifero
+sopire
+soppeso
+sopra
+sorgere
+sorpasso
+sorriso
+sorso
+sorteggio
+sorvolato
+sospiro
+sosta
+sottile
+spada
+spalla
+spargere
+spatola
+spavento
+spazzola
+specie
+spedire
+spegnere
+spelatura
+speranza
+spessore
+spettrale
+spezzato
+spia
+spigoloso
+spillato
+spinoso
+spirale
+splendido
+sportivo
+sposo
+spranga
+sprecare
+spronato
+spruzzo
+spuntino
+squillo
+sradicare
+srotolato
+stabile
+stacco
+staffa
+stagnare
+stampato
+stantio
+starnuto
+stasera
+statuto
+stelo
+steppa
+sterzo
+stiletto
+stima
+stirpe
+stivale
+stizzoso
+stonato
+storico
+strappo
+stregato
+stridulo
+strozzare
+strutto
+stuccare
+stufo
+stupendo
+subentro
+succoso
+sudore
+suggerito
+sugo
+sultano
+suonare
+superbo
+supporto
+surgelato
+surrogato
+sussurro
+sutura
+svagare
+svedese
+sveglio
+svelare
+svenuto
+svezia
+sviluppo
+svista
+svizzera
+svolta
+svuotare
+tabacco
+tabulato
+tacciare
+taciturno
+tale
+talismano
+tampone
+tannino
+tara
+tardivo
+targato
+tariffa
+tarpare
+tartaruga
+tasto
+tattico
+taverna
+tavolata
+tazza
+teca
+tecnico
+telefono
+temerario
+tempo
+temuto
+tendone
+tenero
+tensione
+tentacolo
+teorema
+terme
+terrazzo
+terzetto
+tesi
+tesserato
+testato
+tetro
+tettoia
+tifare
+tigella
+timbro
+tinto
+tipico
+tipografo
+tiraggio
+tiro
+titanio
+titolo
+titubante
+tizio
+tizzone
+toccare
+tollerare
+tolto
+tombola
+tomo
+tonfo
+tonsilla
+topazio
+topologia
+toppa
+torba
+tornare
+torrone
+tortora
+toscano
+tossire
+tostatura
+totano
+trabocco
+trachea
+trafila
+tragedia
+tralcio
+tramonto
+transito
+trapano
+trarre
+trasloco
+trattato
+trave
+treccia
+tremolio
+trespolo
+tributo
+tricheco
+trifoglio
+trillo
+trincea
+trio
+tristezza
+triturato
+trivella
+tromba
+trono
+troppo
+trottola
+trovare
+truccato
+tubatura
+tuffato
+tulipano
+tumulto
+tunisia
+turbare
+turchino
+tuta
+tutela
+ubicato
+uccello
+uccisore
+udire
+uditivo
+uffa
+ufficio
+uguale
+ulisse
+ultimato
+umano
+umile
+umorismo
+uncinetto
+ungere
+ungherese
+unicorno
+unificato
+unisono
+unitario
+unte
+uovo
+upupa
+uragano
+urgenza
+urlo
+usanza
+usato
+uscito
+usignolo
+usuraio
+utensile
+utilizzo
+utopia
+vacante
+vaccinato
+vagabondo
+vagliato
+valanga
+valgo
+valico
+valletta
+valoroso
+valutare
+valvola
+vampata
+vangare
+vanitoso
+vano
+vantaggio
+vanvera
+vapore
+varano
+varcato
+variante
+vasca
+vedetta
+vedova
+veduto
+vegetale
+veicolo
+velcro
+velina
+velluto
+veloce
+venato
+vendemmia
+vento
+verace
+verbale
+vergogna
+verifica
+vero
+verruca
+verticale
+vescica
+vessillo
+vestale
+veterano
+vetrina
+vetusto
+viandante
+vibrante
+vicenda
+vichingo
+vicinanza
+vidimare
+vigilia
+vigneto
+vigore
+vile
+villano
+vimini
+vincitore
+viola
+vipera
+virgola
+virologo
+virulento
+viscoso
+visione
+vispo
+vissuto
+visura
+vita
+vitello
+vittima
+vivanda
+vivido
+viziare
+voce
+voga
+volatile
+volere
+volpe
+voragine
+vulcano
+zampogna
+zanna
+zappato
+zattera
+zavorra
+zefiro
+zelante
+zelo
+zenzero
+zerbino
+zibetto
+zinco
+zircone
+zitto
+zolla
+zotico
+zucchero
+zufolo
+zulu
+zuppa

From c7cc74d523f0d8750115e58fa84648a8c76998f3 Mon Sep 17 00:00:00 2001
From: Daniel Cousens 
Date: Fri, 29 Jan 2016 11:16:44 +1100
Subject: [PATCH 174/259] Add BIP38 Javascript implementation

---
 bip-0038.mediawiki | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/bip-0038.mediawiki b/bip-0038.mediawiki
index 4fc3207b..d87c5cf4 100644
--- a/bip-0038.mediawiki
+++ b/bip-0038.mediawiki
@@ -210,6 +210,9 @@ Added to alpha version of Casascius Bitcoin Address Utility for Windows availabl
 
 Click "Tools" then "PPEC Keygen" (provisional name)
 
+==Other implementations==
+* Javascript - https://github.com/bitcoinjs/bip38
+
 ==Test vectors==
 
 ===No compression, no EC multiply===

From 736fb3057fd4d7c6eda30df6b790b97269503c8d Mon Sep 17 00:00:00 2001
From: Eric Lombrozo 
Date: Thu, 28 Jan 2016 16:39:15 -0800
Subject: [PATCH 175/259] Updated BIP table

---
 bip-0123.mediawiki | 182 +++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 182 insertions(+)

diff --git a/bip-0123.mediawiki b/bip-0123.mediawiki
index 776529a7..348c6c06 100644
--- a/bip-0123.mediawiki
+++ b/bip-0123.mediawiki
@@ -82,6 +82,13 @@ The applications layer specifies high level structures, abstractions, and conven
 | Standard
 | Active
 |-
+| [[bip-0009.mediawiki|9]]
+| Consensus (soft fork)
+| Version bits with timeout and delay
+| Pieter Wuille, Peter Todd, Greg Maxwell, Rusty Russell
+| Informational
+| Draft
+|- 
 | [[bip-0010.mediawiki|10]]
 | Applications
 | Multi-Sig Transaction Distribution
@@ -391,11 +398,186 @@ The applications layer specifies high level structures, abstractions, and conven
 | Standard
 | Draft
 |-
+| [[bip-0080.mediawiki|80]]
+| Applications
+| Hierarchy for Non-Colored Voting Pool Deterministic Multisig Wallets
+| Monetas
+| Informational
+| Draft
+|-
+| [[bip-0083.mediawiki|83]]
+| Applications
+| Dynamic Hierarchical Deterministic Key Trees
+| Eric Lombrozo
+| Standard
+| Draft
+|-
+| [[bip-0099.mediawiki|99]]
+| Informational
+| Motivation and deployment of consensus rule changes ([soft/hard]forks)
+| Jorge Timón
+| Informational / Process
+| Draft
+|-
 | [[bip-0101.mediawiki|101]]
 | Consensus (hard fork)
 | Increase maximum block size
 | Gavin Andresen
 | Standard
 | Draft
+|-
+| [[bip-0102.mediawiki|102]]
+| Consensus (hard fork)
+| Block size increase to 2MB
+| Jeff Garzik
+| Standard
+| Draft
+|-
+| [[bip-0103.mediawiki|103]]
+| Consensus (hard fork)
+| Block size following technological growth
+| Pieter Wuille
+| Standard
+| Draft
+|-
+| [[bip-0105.mediawiki|105]]
+| Consensus (hard fork)
+| Consensus based block size retargetting algorithm
+| BtcDrak
+| Standard
+| Draft
+|-
+| [[bip-0106.mediawiki|106]]
+| Consensus (hard fork)
+| Dynamically Controlled Bitcoin Block Size Max Cap
+| Upal Chakraborty
+| Standard
+| Draft
+|-
+| [[bip-0107.mediawiki|107]]
+| Consensus (hard fork)
+| Dynamic limit on the block size
+| Washington Y. Sanchez
+| Standard
+| Draft
+|-
+| [[bip-0111.mediawiki|111]]
+| Peer Services
+| NODE_BLOOM service bit
+| Matt Corallo, Peter Todd
+| Standard
+| Draft
+|-
+| [[bip-0112.mediawiki|112]]
+| Consensus (soft fork)
+| CHECKSEQUENCEVERIFY
+| BtcDrak, Mark Friedenbach, Eric Lombrozo
+| Standard
+| Draft
+|-
+| [[bip-0113.mediawiki|113]]
+| Consensus (soft fork)
+| Median time-past as endpoint for locktime calculations
+| Thomas Kerin, Mark Friedenbach
+| Standard
+| Draft
+|-
+| [[bip-0120.mediawiki|120]]
+| Applications
+| Proof of Payment
+| Kalle Rosenbaum
+| Standard
+| Draft
+|-
+| [[bip-0121.mediawiki|121]]
+| Applications
+| Proof of Payment URI scheme
+| Kalle Rosenbaum
+| Standard
+| Draft
+|-
+| [[bip-0122.mediawiki|122]]
+| Applications
+| URI scheme for Blockchain references / exploration
+| Marco Pontello
+| Standard
+| Draft
+|-
+| [[bip-0123.mediawiki|123]]
+| Process
+| BIP Classification
+| Eric Lombrozo
+| Standard
+| Draft
+|-
+| [[bip-0124.mediawiki|124]]
+| Applications
+| Hierarchical Deterministic Script Templates
+| Eric Lombrozo, William Swanson
+| Standard
+| Draft
+|-
+| [[bip-0125.mediawiki|125]]
+| Peer Services
+| Opt-in Full Replace-by-Fee Signaling
+| David Harding, Peter Todd
+| Standard
+| Draft
+|-
+| [[bip-0130.mediawiki|130]]
+| Peer Services
+| sendheaders message
+| Suhas Daftuar
+| Standard
+| Draft
+|-
+| [[bip-0131.mediawiki|131]]
+| Consensus (hard fork)
+| "Coalescing Transaction" Specification (wildcard inputs)
+| Chris Priest
+| Standard
+| Draft
+|-
+| [[bip-0132.mediawiki|132]]
+| Process
+| Committee-based BIP Acceptance Process
+| Andy Chase
+| Process
+| Draft
+|-
+| [[bip-0140.mediawiki|140]]
+| Consensus (soft fork)
+| Normalized TXID
+| Christian Decker
+| Standard
+| Draft
+|-
+| [[bip-0141.mediawiki|141]]
+| Consensus (soft fork)
+| Segregated Witness (Consensus layer)
+| Eric Lombrozo, Johnson Lau, Pieter Wuille
+| Standard
+| Draft
+|-
+| [[bip-0142.mediawiki|142]]
+| Applications
+| Address Format for Segregated Witness
+| Johnson Lau
+| Standard
+| Draft
+|-
+| [[bip-0143.mediawiki|143]]
+| Consensus (soft fork)
+| Transaction Signature Verification for Version 0 Witness Program
+| Johnson Lau, Pieter Wuille
+| Standard
+| Draft
+|-
+| [[bip-0144.mediawiki|144]]
+| Peer Services
+| Segregated Witness (Peer Services)
+| Eric Lombrozo, Pieter Wuille
+| Standard
+| Draft 
 |}
 

From 6edf4efed8a8691b80ad4c19de93e6c4e0d844a3 Mon Sep 17 00:00:00 2001
From: Toby Padilla 
Date: Thu, 28 Jan 2016 17:38:40 -0800
Subject: [PATCH 176/259] BIP74 Draft

---
 README.mediawiki   |  6 +++++
 bip-0074.mediawiki | 59 ++++++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 65 insertions(+)
 create mode 100644 bip-0074.mediawiki

diff --git a/README.mediawiki b/README.mediawiki
index 045fd28f..eda7fbfd 100644
--- a/README.mediawiki
+++ b/README.mediawiki
@@ -302,6 +302,12 @@ Those proposing changes should consider that ultimately consent may rest with th
 | Standard
 | Draft
 |-
+| [[bip-0074.mediawiki|74]]
+| Support zero value OP_RETURN in Payment Requests
+| Toby Padilla
+| Standard
+| Draft
+|-
 | [[bip-0080.mediawiki|80]]
 | Hierarchy for Non-Colored Voting Pool Deterministic Multisig Wallets
 | Monetas
diff --git a/bip-0074.mediawiki b/bip-0074.mediawiki
new file mode 100644
index 00000000..0790b12f
--- /dev/null
+++ b/bip-0074.mediawiki
@@ -0,0 +1,59 @@
+
+  BIP: 74
+  Title: Allow zero value OP_RETURN in Payment Protocol
+  Author: Toby Padilla 
+

+
+==Abstract==
+
+This BIP alters the Payment Protocol to allow for zero value OP_RETURN outputs in serialized PaymentRequests.
+
+==Motivation==
+
+The Payment Protocol (defined in BIP70) gives merchants a way to build sophisticated transactions by serializing one or more outputs in the form of a PaymentRequest. The PaymentRequest is then served over http/https to a customer's wallet where the serialized transaction can be executed.
+
+While the Payment Protocol allows for any valid script in its outputs, it also ignores outputs with zero value. This means BIP70 implementations can encode an OP_RETURN script but must provide a greater than dust value for that output. The end result is a successful PaymentRequest transaction with an OP_RETURN but the value assigned to that output is lost forever.
+
+This BIP allows for zero value OP_RETURN outputs in serialized PaymentRequests. The change means that OP_RETURN scripts will work as they were originally intended from within PaymentRequests without permanently destroying Bitcoin value. Zero value non-OP_RETURN scripts should continue to be ignored.
+
+In addition to fixing the issue of destroyed value, this change opens up new use cases that were previously impossible.
+
+While storing data on the blockchain is controversial, when used responsibly OP_RETURN provides a powerful mechanism for attaching metadata to a transaction. This BIP effectively decouples the creation of transactions containing OP_RETURN data from the execution of those transactions. The result are positive benefits for both merchants and wallets/customers.
+
+By supporting this BIP, wallets can participate in current and future, unforeseen use cases that benefit from metadata stored in OP_RETURN. Until now OP_RETURN transactions have typically been created and submitted by custom software. If a wallet can process a PaymentRequest with OP_RETURN data as proposed by this BIP, it will support potentially sophisticated Bitcoin applications without the wallet developer having to have prior knowledge of that application.
+
+An example might be a merchant that adds the hash of a plain text invoice to the checkout transaction. The merchant could construct the PaymentRequest with the invoice hash in an OP_RETURN and pass it to the customer's wallet. The wallet could then submit the transaction, including the invoice hash from the PaymentRequest. The wallet will have encoded a proof of purchase to the blockchain without the wallet developer having to coordinate with the merchant software or add features beyond this BIP.
+
+Merchants and Bitcoin application developers benefit from this BIP because they can now construct transactions that include OP_RETURN data in a keyless environment. Again, prior to this BIP, transactions that used OP_RETURN (with zero value) needed to be constructed and executed in the same software. By separating the two concerns, this BIP allows merchant software to create transactions with OP_RETURN metadata on a server without storing public or private Bitcoin keys. This greatly enhances security where OP_RETURN applications currently need access to a private key to sign transactions.
+
+==Specification==
+
+The specification for this BIP is straightforward. BIP70 should be fully implemented with the following changes:
+
+* Outputs where the script is an OP_RETURN and the value is zero should be accepted by the wallet.
+
+BIP70 has special handling for the case with multiple zero value outputs:
+
+

+If the sum of outputs.amount is zero, the customer will be asked how much to pay, and the bitcoin client may choose any or all of the Outputs (if there are more than one) for payment. If the sum of outputs.amount is non-zero, then the customer will be asked to pay the sum, and the payment shall be split among the Outputs with non-zero amounts (if there are more than one; Outputs with zero amounts shall be ignored).
+

+
+This behavior should be retained with the exception of OP_RETURN handling. In the case of a multiple output transaction where the sum of the output values is zero, the user should be prompted for a value and that value should be distributed over any or all outputs ''except'' the OP_RETURN output. In the case where the sum of outputs.amount is non-zero then any OP_RETURN outputs should not be ignored but no value should be assigned to them.
+
+Payment requests also must contain at least one payable output (i.e. no payment requests with ''just'' an OP_RETURN).
+
+==Rationale==
+
+As with the discussion around vanilla OP_RETURN, the practice of storing data on the blockchain is controversial. While blockchain and network bloat is an undeniable issue, the benefits that come from attaching metadata to transactions has proven to be too powerful to dismiss entirely. In the absence of OP_RETURN support the Bitcoin ecosystem has seen alternative, less elegant and more wasteful methods employed for Blockchain data storage.
+
+As it exists today, BIP70 allows for OP_RETURN data storage at the expense of permanently destroyed Bitcoin. Even fully removing support for OP_RETURN values in the Payment Protocol would still leave the door open to suboptimal data encoding via burning a larger than dust value to an output with a false address designed to encode data.
+
+This BIP offers all of the same benefits that come from the OP_RETURN compromise. Mainly that OP_RETURN scripts are provably unspendable and thus can be pruned from the UTXO pool. Without supporting this BIP, wallets that support BIP70 will allow for wasteful data storage.
+
+==Compatibility==
+
+Since this BIP still supports OP_RETURN statements with a greater than zero value, it should be fully backwards compatible with any existing implementations.
+
+==Copyright==
+
+This document is placed in the public domain.

From 3b058bba32645a834c6da306db1a68d4a24ca236 Mon Sep 17 00:00:00 2001
From: Luke Dashjr 
Date: Sat, 30 Jan 2016 18:46:54 +0000
Subject: [PATCH 177/259] Initial draft of GBT updated for SegWit

---
 bip-segwit-gbt.mediawiki | 94 ++++++++++++++++++++++++++++++++++++++++
 1 file changed, 94 insertions(+)
 create mode 100644 bip-segwit-gbt.mediawiki

diff --git a/bip-segwit-gbt.mediawiki b/bip-segwit-gbt.mediawiki
new file mode 100644
index 00000000..75b5097a
--- /dev/null
+++ b/bip-segwit-gbt.mediawiki
@@ -0,0 +1,94 @@
+
+  BIP: x
+  Title: getblocktemplate Updates for Segregated Witness
+  Author: Luke Dashjr 
+  Status: Draft
+  Type: Standards Track
+  Created: 2016-01-30
+

+
+==Abstract==
+
+This BIP describes modifications to the getblocktemplate JSON-RPC call ([[bip-0022.mediawiki|BIP 22]]) to support segregated witness as defined by [[bip-0141.mediawiki|BIP 141]].
+
+==Specification==
+
+The notion of "cost" is introduced 
+
+===Block Template===
+
+The template Object is revised to include these keys:
+
+{| class="wikitable"
+!colspan=4| template
+|-
+! Key !! Required !! Type !! Description
+|-
+| costlimit || {{No}} || Number || total cost allowed in blocks
+|-
+| sigoplimit || {{No}} || Number || total sigop cost allowed in blocks divided by 4
+|-
+| version || {{Yes}} || Number || block version; clients MUST understand the implications of the version they use (eg, comply with [[bip-0141.mediawiki|BIP 141]] for version 5)
+|}
+
+====Transactions Object Format====
+
+The Objects listed in the response's "transactions" key is revised to include these keys:
+
+{| class="wikitable"
+!colspan=3|template "transactions" element
+|-
+! Key !! Type !! Description
+|-
+| txid || String || transaction id encoded in hexadecimal; required for transactions with witness data
+|-
+| cost || Number || numeric cost of the transaction, as counted for purposes of the block's costlimit; if key is not present, cost is unknown and clients MUST NOT assume it is zero, although they MAY choose to calculate it themselves
+|-
+| hash || String || reversed hash of complete transaction (with witness data included) encoded in hexadecimal
+|}
+
+Transactions with witness data may only be included if the template's block version is at least 5.
+
+===Block Assembly with Witness Transactions===
+
+When block assembly is done without witness transactions, no changes are made by this BIP, and it should be assembled as previously.
+
+When witness transactions are included in the block, the primary merkle root MUST be calculated with those transactions' "txid" field instead of "hash". A secondary merkle root MUST be calculated as per [[bip-0141.mediawiki#Commitment_structure|BIP 141's commitment structure specification]] to be inserted into the generation (coinbase) transaction.
+
+Servers MUST NOT include a commitment in the "coinbasetxn" key on the template. Clients MUST insert the commitment as an additional output at the end of the final generation (coinbase) transaction. Only if the template includes a "mutable" key (see [[bip-0023.mediawiki#Mutations|BIP 23 Mutations]]) including "generation", the client MAY in that case place the commitment output in any position it chooses, provided that no later output matches the commitment pattern.
+
+==Motivation==
+
+Segregated witness substatially changes the structure of blocks, so the previous getblocktemplate specification is no longer sufficient.
+It additionally also adds a new way of counting resource limits, and so GBT must be extended to convey this information correctly as well.
+
+==Rationale==
+
+Why doesn't "costlimit" simply redefine the existing "sizelimit"?
+* "sizelimit" is already enforced by clients by counting the sum of bytes in transactions' "data" keys.
+* Servers may wish to limit the overall size of a block, independently from the "cost" of the block.
+
+Why is "sigoplimit" redefined instead of a new "sigopcostlimit" being added?
+* The old limit was already arbitrarily defined, and could not be counted by clients on their own anyway. The concept of "sigop cost" is merely a change in the arbitrary formula used.
+
+Why is "sigoplimit" divided by 4?
+* To resemble the previous values. (FIXME: is this a good reason? maybe we shouldn't divide it?)
+
+Why is the witness commitment required to be added to the end of the generation transaction rather than anywhere else?
+* Servers which do not allow modification of the generation outputs ought to be checking this as part of the validity of submissions. By requiring a specific placement, they can simply strip the commitment and do a byte-for-byte comparison of the outputs. Placing it at the end avoids the possibility of a later output matching the pattern and overriding it.
+
+Why shouldn't the server simply add the commitment upfront in the "coinbasetxn", and simply send the client stripped transaction data?
+* It would become impossible for servers to specify only "coinbasevalue", since clients would no longer have the information required to construct the commitment.
+* getblocktemplate is intended to be a *decentralised* mining protocol, and allowing clients to be blinded to the content of the block works contrary to that purpose.
+* BIP 23's "transactions" mutations allow the client to modify the transaction-set on their own, which is impossible without the complete transaction data.
+
+==Reference Implementation==
+
+* [https://github.com/bitcoin/libblkmaker/tree/segwit libblkmaker]
+* [https://github.com/luke-jr/eloipool/tree/segwit Eloipool]
+* [https://github.com/bitcoin/bitcoin/pull/7404/files Bitcoin Core]
+
+==See Also==
+* [[bip-0022.mediawiki|BIP 22: getblocktemplate - Fundamentals]]
+* [[bip-0023.mediawiki|BIP 23: getblocktemplate - Pooled Mining]]
+* [[bip-0141.mediawiki|BIP 141: Segregated Witness (Consensus layer)]]

From 8235f61042deff2c3aa18ba2e1dd613d0c123803 Mon Sep 17 00:00:00 2001
From: Pavol Rusnak 
Date: Mon, 1 Feb 2016 16:10:40 +0100
Subject: [PATCH 178/259] update location of slip-0044

---
 bip-0044.mediawiki | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/bip-0044.mediawiki b/bip-0044.mediawiki
index f9d12549..ef7254c1 100644
--- a/bip-0044.mediawiki
+++ b/bip-0044.mediawiki
@@ -149,10 +149,10 @@ All these constants are used as hardened derivation.
 This BIP is not a central directory for the registered coin types, please
 visit SatoshiLabs that maintains the full list:
 
-[[http://doc.satoshilabs.com/slips/slip-0044.html|SLIP-0044 : Registered coin types for BIP-0044]]
+[[https://github.com/satoshilabs/slips/blob/master/slip-0044.md|SLIP-0044 : Registered coin types for BIP-0044]]
 
 To register a new coin type, an existing wallet that implements the standard
-is required. This can be done [[https://github.com/satoshilabs/docs/blob/master/slips/slip-0044.rst|here]].
+is required and a pull request to the above file should be created.
 
 ==Examples==
 

From d3aa9b3f5759c7899ef2d9f11e5287d026507e6e Mon Sep 17 00:00:00 2001
From: Luke Dashjr 
Date: Mon, 1 Feb 2016 20:02:03 +0000
Subject: [PATCH 179/259] Fix typo

---
 bip-segwit-gbt.mediawiki | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/bip-segwit-gbt.mediawiki b/bip-segwit-gbt.mediawiki
index 75b5097a..0ad10c28 100644
--- a/bip-segwit-gbt.mediawiki
+++ b/bip-segwit-gbt.mediawiki
@@ -59,7 +59,7 @@ Servers MUST NOT include a commitment in the "coinbasetxn" key on the template.
 
 ==Motivation==
 
-Segregated witness substatially changes the structure of blocks, so the previous getblocktemplate specification is no longer sufficient.
+Segregated witness substantially changes the structure of blocks, so the previous getblocktemplate specification is no longer sufficient.
 It additionally also adds a new way of counting resource limits, and so GBT must be extended to convey this information correctly as well.
 
 ==Rationale==

From f31f7d43473fadcfafbc886b15e8c488654839c2 Mon Sep 17 00:00:00 2001
From: Luke Dashjr 
Date: Mon, 1 Feb 2016 20:14:22 +0000
Subject: [PATCH 180/259] Promote Accepted->Final BIPs 11, 14, 21, 22, 23, 31,
 32, 34, 35, 37, 65

---
 README.mediawiki   | 22 +++++++++++-----------
 bip-0011.mediawiki |  2 +-
 bip-0014.mediawiki |  2 +-
 bip-0021.mediawiki |  2 +-
 bip-0022.mediawiki |  2 +-
 bip-0023.mediawiki |  2 +-
 bip-0031.mediawiki |  2 +-
 bip-0032.mediawiki |  2 +-
 bip-0034.mediawiki |  2 +-
 bip-0035.mediawiki |  2 +-
 bip-0037.mediawiki |  2 +-
 bip-0065.mediawiki |  2 +-
 12 files changed, 22 insertions(+), 22 deletions(-)

diff --git a/README.mediawiki b/README.mediawiki
index eda7fbfd..4bfdc548 100644
--- a/README.mediawiki
+++ b/README.mediawiki
@@ -35,7 +35,7 @@ Those proposing changes should consider that ultimately consent may rest with th
 | M-of-N Standard Transactions
 | Gavin Andresen
 | Standard
-| Accepted
+| Final
 |- style="background-color: #ffcfcf"
 | [[bip-0012.mediawiki|12]]
 | OP_EVAL
@@ -53,7 +53,7 @@ Those proposing changes should consider that ultimately consent may rest with th
 | Protocol Version and User Agent
 | Amir Taaki, Patrick Strateman
 | Standard
-| Accepted
+| Final
 |- style="background-color: #ffcfcf"
 | [[bip-0015.mediawiki|15]]
 | Aliases
@@ -95,19 +95,19 @@ Those proposing changes should consider that ultimately consent may rest with th
 | URI Scheme
 | Nils Schneider, Matt Corallo
 | Standard
-| Accepted
+| Final
 |- style="background-color: #cfffcf"
 | [[bip-0022.mediawiki|22]]
 | getblocktemplate - Fundamentals
 | Luke Dashjr
 | Standard
-| Accepted
+| Final
 |- style="background-color: #cfffcf"
 | [[bip-0023.mediawiki|23]]
 | getblocktemplate - Pooled Mining
 | Luke Dashjr
 | Standard
-| Accepted
+| Final
 |- style="background-color: #cfffcf"
 | [[bip-0030.mediawiki|30]]
 | Duplicate transactions
@@ -119,13 +119,13 @@ Those proposing changes should consider that ultimately consent may rest with th
 | Pong message
 | Mike Hearn
 | Standard
-| Accepted
+| Final
 |- style="background-color: #cfffcf"
 | [[bip-0032.mediawiki|32]]
 | Hierarchical Deterministic Wallets
 | Pieter Wuille
 | Informational
-| Accepted
+| Final
 |-
 | [[bip-0033.mediawiki|33]]
 | Stratized Nodes
@@ -137,13 +137,13 @@ Those proposing changes should consider that ultimately consent may rest with th
 | Block v2, Height in coinbase
 | Gavin Andresen
 | Standard
-| Accepted
+| Final
 |- style="background-color: #cfffcf"
 | [[bip-0035.mediawiki|35]]
 | mempool message
 | Jeff Garzik
 | Standard
-| Accepted
+| Final
 |-
 | [[bip-0036.mediawiki|36]]
 | Custom Services
@@ -155,7 +155,7 @@ Those proposing changes should consider that ultimately consent may rest with th
 | Bloom filtering
 | Mike Hearn, Matt Corallo
 | Standard
-| Accepted
+| Final
 |-
 | [[bip-0038.mediawiki|38]]
 | Passphrase-protected private key
@@ -252,7 +252,7 @@ Those proposing changes should consider that ultimately consent may rest with th
 | OP_CHECKLOCKTIMEVERIFY
 | Peter Todd
 | Standard
-| Accepted
+| Final
 |-
 | [[bip-0066.mediawiki|66]]
 | Strict DER signatures
diff --git a/bip-0011.mediawiki b/bip-0011.mediawiki
index 2499ac03..4b12340d 100644
--- a/bip-0011.mediawiki
+++ b/bip-0011.mediawiki
@@ -2,7 +2,7 @@
   BIP: 11
   Title: M-of-N Standard Transactions
   Author: Gavin Andresen 
-  Status: Accepted
+  Status: Final
   Type: Standards Track
   Created: 2011-10-18
   Post-History: 2011-10-02
diff --git a/bip-0014.mediawiki b/bip-0014.mediawiki
index 111eb78b..cf7594b2 100644
--- a/bip-0014.mediawiki
+++ b/bip-0014.mediawiki
@@ -3,7 +3,7 @@
   Title: BIP Protocol Version and User Agent
   Author: Amir Taaki 
           Patrick Strateman 
-  Status: Accepted
+  Status: Final
   Type: Standards Track
   Created: 2011-11-10
   Post-History: 2011-11-02
diff --git a/bip-0021.mediawiki b/bip-0021.mediawiki
index 27069264..4cbbc034 100644
--- a/bip-0021.mediawiki
+++ b/bip-0021.mediawiki
@@ -3,7 +3,7 @@
   Title: URI Scheme
   Author: Nils Schneider 
           Matt Corallo 
-  Status: Accepted
+  Status: Final
   Type: Standards Track
   Created: 2012-01-29
 

diff --git a/bip-0022.mediawiki b/bip-0022.mediawiki
index b39f9573..35b59be7 100644
--- a/bip-0022.mediawiki
+++ b/bip-0022.mediawiki
@@ -2,7 +2,7 @@
   BIP: 22
   Title: getblocktemplate - Fundamentals
   Author: Luke Dashjr 
-  Status: Accepted
+  Status: Final
   Type: Standards Track
   Created: 2012-02-28
 

diff --git a/bip-0023.mediawiki b/bip-0023.mediawiki
index a53b00bf..874e60a1 100644
--- a/bip-0023.mediawiki
+++ b/bip-0023.mediawiki
@@ -2,7 +2,7 @@
   BIP: 23
   Title: getblocktemplate - Pooled Mining
   Author: Luke Dashjr 
-  Status: Accepted
+  Status: Final
   Type: Standards Track
   Created: 2012-02-28
 

diff --git a/bip-0031.mediawiki b/bip-0031.mediawiki
index 8adcd295..1bfe143c 100644
--- a/bip-0031.mediawiki
+++ b/bip-0031.mediawiki
@@ -2,7 +2,7 @@
   BIP: 31
   Title: Pong message
   Author: Mike Hearn 
-  Status: Accepted
+  Status: Final
   Type: Standards Track
   Created: 2012-04-11
 

diff --git a/bip-0032.mediawiki b/bip-0032.mediawiki
index ac0ed991..52e20320 100644
--- a/bip-0032.mediawiki
+++ b/bip-0032.mediawiki
@@ -8,7 +8,7 @@ RECENT CHANGES:
   BIP: 32
   Title: Hierarchical Deterministic Wallets
   Author: Pieter Wuille
-  Status: Accepted
+  Status: Final
   Type: Informational
   Created: 2012-02-11
 

diff --git a/bip-0034.mediawiki b/bip-0034.mediawiki
index 245985c7..1d88781d 100644
--- a/bip-0034.mediawiki
+++ b/bip-0034.mediawiki
@@ -2,7 +2,7 @@
   BIP: 34
   Title: Block v2, Height in Coinbase
   Author: Gavin Andresen 
-  Status: Accepted
+  Status: Final
   Type: Standards Track
   Created: 2012-07-06
 

diff --git a/bip-0035.mediawiki b/bip-0035.mediawiki
index cdadd1d7..c66735ca 100644
--- a/bip-0035.mediawiki
+++ b/bip-0035.mediawiki
@@ -2,7 +2,7 @@
   BIP: 35
   Title: mempool message
   Author: Jeff Garzik 
-  Status: Accepted
+  Status: Final
   Type: Standards Track
   Created: 2012-08-16
 

diff --git a/bip-0037.mediawiki b/bip-0037.mediawiki
index 77b917b3..93296b5d 100644
--- a/bip-0037.mediawiki
+++ b/bip-0037.mediawiki
@@ -2,7 +2,7 @@
   BIP: 37
   Title: Connection Bloom filtering
   Author: Mike Hearn , Matt Corallo 
-  Status: Accepted
+  Status: Final
   Type: Standards Track
   Created: 2012-10-24
 

diff --git a/bip-0065.mediawiki b/bip-0065.mediawiki
index df995deb..99298bf1 100644
--- a/bip-0065.mediawiki
+++ b/bip-0065.mediawiki
@@ -2,7 +2,7 @@
   BIP: 65
   Title: OP_CHECKLOCKTIMEVERIFY
   Author: Peter Todd 
-  Status: Accepted
+  Status: Final
   Type: Standards Track
   Created: 2014-10-01
 


From e22ad0cd715af88cabecffe1afcc4258740dc85f Mon Sep 17 00:00:00 2001
From: Luke Dashjr 
Date: Mon, 1 Feb 2016 20:36:37 +0000
Subject: [PATCH 181/259] Revert "Update BIP-21 URI scheme for payment code
 support"

This reverts commit 2e6e5cf9589778ea55c7e71aa27e2b9ff122b737.
---
 bip-0021.mediawiki | 9 ---------
 1 file changed, 9 deletions(-)

diff --git a/bip-0021.mediawiki b/bip-0021.mediawiki
index 27069264..00d9a537 100644
--- a/bip-0021.mediawiki
+++ b/bip-0021.mediawiki
@@ -56,7 +56,6 @@ The scheme component ("bitcoin:") is case-insensitive, and implementations must
 *address: bitcoin address
 *message: message that describes the transaction to the user ([[#Examples|see examples below]])
 *size: amount of base bitcoin units ([[#Transfer amount/size|see below]])
-*paycode: payment code (BIP-47)
 *(others): optional, for future extensions
 
 ==== Transfer amount/size ====
@@ -68,11 +67,6 @@ I.e. amount=50.00 or amount=50 is treated as 50 BTC, and amount=50,000.00 is inv
 Bitcoin clients MAY display the amount in any format that is not intended to deceive the user.
 They SHOULD choose a format that is foremost least confusing, and only after that most reasonable given the amount requested.
 For example, so long as the majority of users work in BTC units, values should always be displayed in BTC by default, even if mBTC or TBC would otherwise be a more logical interpretation of the amount.
-
-==== Payment code ====
-
-If a URI provides a payment code, and if the client supports BIP-47, then the resulting transaction SHOULD construct a transaction per BIP-47 instead of using the address provided in the URI.
-
 == Rationale ==
 
 ===Payment identifiers, not person identifiers===
@@ -128,6 +122,3 @@ Characters must be URI encoded properly.
 === Bitcoin clients ===
 * Bitcoin-Qt supports the old version of Bitcoin URIs (ie without the req- prefix), with Windows and KDE integration as of commit 70f55355e29c8e45b607e782c5d76609d23cc858.
 
-==References==
-
-* [[bip-0047.mediawiki|BIP47 - Reusable Payment Codes for Hierarchical Deterministic Wallets]]

From ebba30aa86452590f2d505e0ed058f0b64586258 Mon Sep 17 00:00:00 2001
From: Luke Dashjr 
Date: Mon, 1 Feb 2016 22:34:17 +0000
Subject: [PATCH 182/259] New BIP to revise BIP 1

---
 bip-biprevised.mediawiki | 91 ++++++++++++++++++++++++++++++++++++++++
 1 file changed, 91 insertions(+)
 create mode 100644 bip-biprevised.mediawiki

diff --git a/bip-biprevised.mediawiki b/bip-biprevised.mediawiki
new file mode 100644
index 00000000..7b3c00b4
--- /dev/null
+++ b/bip-biprevised.mediawiki
@@ -0,0 +1,91 @@
+
+  BIP: x
+  Title: BIP Status and Comments
+  Status: Draft
+  Type: Process
+  Created: 2016-02-01
+

+
+==Abstract==
+
+BIP 1 defines an ambiguous criteria for the Status field of BIPs, which is often a source of confusion.
+Additionally, some BIPs have been adopted which are deemed unadvisable or unsafe by experts in the field, and there is no indication of this at present.
+Finally, BIP 1 only allows a single copyright license generally considered deprecated, or publication under the public domain (which is not legally recognised in all jurisdictions).
+This BIP intends to address these problems by more specifically defining the Status field, recommending a forum for people to comment on BIPs, and expanding the list of allowable BIP licenses.
+
+==Copyright==
+
+This BIP is dual-licensed under the Open Publication License and BSD 2-clause license.
+
+==Specification==
+
+===BIP status field===
+
+Champions of a BIP may decide on their own to change the status between Draft, Deferred, or Withdrawn.
+
+A BIP may only change status from Draft (or Rejected) to Accepted, when the author deems it is complete, has a working implementation (where applicable), and has community plans to progress it to the Final status.
+
+BIPs should be changed from Draft or Accepted status, to Rejected status, upon request by any person, if they have not made progress in three years. Such a BIP may be changed to Draft status if the champion provides revisions that meaningfully address public criticism of the proposal, or to Accepted status if it meets the criteria required as described in the previous paragraph.
+
+An Accepted BIP may progress to Final only when specific criteria reflecting real-world adoption has occurred. This is different for each BIP depending on the nature of its proposed changes, which will be expanded on below. Evaluation of this status change should be objectively verifiable, and/or be discussed on the development mailing list.
+
+When a Final BIP is no longer relevant, its status may be changed to Replaced or Obsolete (which is equivalent to Replaced). This change must also be objectively verifiable and/or discussed.
+
+A process BIP may change status from Draft to Active when it achieves consensus on the mailing list.
+
+====Progression to Final status====
+
+See BIP 123 for definitions of the various BIP layers. Activation of this BIP implies activation of BIP 123.
+
+A soft-fork BIP strictly requires a clear miner majority expressed by blockchain voting (eg, using BIP 9), as well as not meeting the inverse criteria for a hard-fork BIP (that is, economic consensus may reject a soft-fork BIP despite miner adoption). Because of the possibility of changes to miner dynamics, especially in light of delegated voting (mining pools), it is highly recommended that a supermajority vote around 95% be required by the BIP itself, unless rationale is given for a lower threshold.
+
+A hard-fork BIP requires consensus from the entire Bitcoin economy, particularly including those selling desirable goods and services in exchange for bitcoin payments, as well as Bitcoin holders who wish to spend or would spend their bitcoins (including selling for other currencies) differently in the event of such a hard-fork. Consensus must be expressed by de facto usage of the hard-fork in practice (ie, not merely expressing public support, although that is a good step to establish pre-Final status consensus to adopt a BIP). This consensus cannot be reached merely by a super-majority, except by literally forcing the minority to accept the hard-fork (whether this is viable or not is outside the scope of this document).
+
+Peer services BIPs should be observed to be adopted by at least 1% of public listening nodes for one month.
+
+API/RPC and application layer BIPs must be implemented by at least two independent and compatible software applications.
+
+Software authors are encouraged to publish summaries of what BIPs their software supports to aid in verification of status changes. Good examples of this at the time of writing this BIP, can be observed in [Bitcoin Core's doc/bips.md file](https://github.com/bitcoin/bitcoin/blob/master/doc/bips.md) as well as [Bitcoin Wallet for Android's wallet/README.specs file](https://github.com/schildbach/bitcoin-wallet/blob/master/wallet/README.specs).
+
+====Formally defining consensus====
+
+A proposal is said to have achieved consensus if it has been open to discussion in applicable forums for communication for at least one month, and has not maintained any substantiated objection by any person. Should objections to be made on a strictly obstructive basis, those obstructing may be ignored/overruled by agreement that they are merely being obstructive from all other persons involved in the discussion.
+
+===BIP comments===
+
+Each BIP should, in its preamble, link to a Bitcoin Wiki page with a summary tone of the comments on that page.
+
+Pages must be named after the full BIP number (eg, "BIP 0001") and placed in the "BIP Comments" namespace. For example, the link for BIP 1 will be https://en.bitcoin.it/wiki/BIP_Comments:BIP_0001 .
+
+Summary tones may be chosen from the following, but this BIP does not intend to cover all possible nuances:
+
+* Unanimously Recommended for implementation
+* Unanimously Discourage for implementation
+* Mostly Recommended for implementation, with some Discouragement
+* Mostly Discouraged for implementation, with some Recommendation
+
+To avoid doubt: comments and status are unrelated metrics to judge a BIP, and neither should be directly influencing the other.
+
+===BIP licensing===
+
+New BIPs may be accepted with the following licenses:
+
+====Recommended licenses====
+
+* OSI-approved BSD 1, 2, or 3 clause licenses
+* Creative Commons CC0 1.0 Universal
+* GNU All-Permissive License
+
+====Not recommented, but acceptable licenses====
+
+* Apache License, version 2.0
+* Apple's Common Documentation License, version 1.0
+* Boost Software License, version 1.0
+* Creative Commons Attribution 4.0 International
+* Creative Commons Attribution-ShareAlike 4.0 International
+* Expat/MIT/X11 license
+* GNU Affero General Public License (AGPL), version 3
+* GNU Free Documentation License
+* GNU General Public License (GPL), version 2 or 3
+* GNU Lesser General Public License (LGPL), version 2.1 or 3
+* Open Publication License, version 1.0

From 6e34af58f9923f1af64c7a0b3d1920ad0ef69d25 Mon Sep 17 00:00:00 2001
From: Luke Dashjr 
Date: Mon, 1 Feb 2016 23:18:33 +0000
Subject: [PATCH 183/259] bip-biprevised: See Also links

---
 bip-biprevised.mediawiki | 7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/bip-biprevised.mediawiki b/bip-biprevised.mediawiki
index 7b3c00b4..39853af3 100644
--- a/bip-biprevised.mediawiki
+++ b/bip-biprevised.mediawiki
@@ -35,7 +35,7 @@ A process BIP may change status from Draft to Active when it achieves consensus
 
 ====Progression to Final status====
 
-See BIP 123 for definitions of the various BIP layers. Activation of this BIP implies activation of BIP 123.
+See [[bip-0123.mediawiki|BIP 123]] for definitions of the various BIP layers. Activation of this BIP implies activation of BIP 123.
 
 A soft-fork BIP strictly requires a clear miner majority expressed by blockchain voting (eg, using BIP 9), as well as not meeting the inverse criteria for a hard-fork BIP (that is, economic consensus may reject a soft-fork BIP despite miner adoption). Because of the possibility of changes to miner dynamics, especially in light of delegated voting (mining pools), it is highly recommended that a supermajority vote around 95% be required by the BIP itself, unless rationale is given for a lower threshold.
 
@@ -89,3 +89,8 @@ New BIPs may be accepted with the following licenses:
 * GNU General Public License (GPL), version 2 or 3
 * GNU Lesser General Public License (LGPL), version 2.1 or 3
 * Open Publication License, version 1.0
+
+==See Also==
+
+* [[bip-0001.mediawiki|BIP 1: BIP Purpose and Guidelines]]
+* [[bip-0123.mediawiki|BIP 123: BIP Classification]]

From c61f4d83009fa11bc72203e0ecdface08f4626f2 Mon Sep 17 00:00:00 2001
From: Luke Dashjr 
Date: Mon, 1 Feb 2016 23:20:58 +0000
Subject: [PATCH 184/259] Bugfix: bip-biprevised: MediaWiki linking

---
 bip-biprevised.mediawiki | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/bip-biprevised.mediawiki b/bip-biprevised.mediawiki
index 39853af3..efbfa78a 100644
--- a/bip-biprevised.mediawiki
+++ b/bip-biprevised.mediawiki
@@ -45,7 +45,7 @@ Peer services BIPs should be observed to be adopted by at least 1% of public lis
 
 API/RPC and application layer BIPs must be implemented by at least two independent and compatible software applications.
 
-Software authors are encouraged to publish summaries of what BIPs their software supports to aid in verification of status changes. Good examples of this at the time of writing this BIP, can be observed in [Bitcoin Core's doc/bips.md file](https://github.com/bitcoin/bitcoin/blob/master/doc/bips.md) as well as [Bitcoin Wallet for Android's wallet/README.specs file](https://github.com/schildbach/bitcoin-wallet/blob/master/wallet/README.specs).
+Software authors are encouraged to publish summaries of what BIPs their software supports to aid in verification of status changes. Good examples of this at the time of writing this BIP, can be observed in [https://github.com/bitcoin/bitcoin/blob/master/doc/bips.md Bitcoin Core's doc/bips.md file] as well as [https://github.com/schildbach/bitcoin-wallet/blob/master/wallet/README.specs Bitcoin Wallet for Android's wallet/README.specs file].
 
 ====Formally defining consensus====
 

From cfbde44a3c7020ee26be39205ab685c383a3b4d1 Mon Sep 17 00:00:00 2001
From: Luke Dashjr 
Date: Mon, 1 Feb 2016 23:29:07 +0000
Subject: [PATCH 185/259] bip-biprevised: Link licenses, and remove obsolete
 Apple licence and non-existent OSI-approved 1-clause BSD license

---
 bip-biprevised.mediawiki | 28 ++++++++++++++--------------
 1 file changed, 14 insertions(+), 14 deletions(-)

diff --git a/bip-biprevised.mediawiki b/bip-biprevised.mediawiki
index efbfa78a..07749629 100644
--- a/bip-biprevised.mediawiki
+++ b/bip-biprevised.mediawiki
@@ -72,23 +72,23 @@ New BIPs may be accepted with the following licenses:
 
 ====Recommended licenses====
 
-* OSI-approved BSD 1, 2, or 3 clause licenses
-* Creative Commons CC0 1.0 Universal
-* GNU All-Permissive License
+* [https://opensource.org/licenses/BSD-2-Clause OSI-approved BSD 2-clause license]
+* [https://opensource.org/licenses/BSD-3-Clause OSI-approved BSD 3-clause license]
+* [https://creativecommons.org/publicdomain/zero/1.0/ Creative Commons CC0 1.0 Universal]
+* [http://www.gnu.org/prep/maintain/html_node/License-Notices-for-Other-Files.html GNU All-Permissive License]
 
 ====Not recommented, but acceptable licenses====
 
-* Apache License, version 2.0
-* Apple's Common Documentation License, version 1.0
-* Boost Software License, version 1.0
-* Creative Commons Attribution 4.0 International
-* Creative Commons Attribution-ShareAlike 4.0 International
-* Expat/MIT/X11 license
-* GNU Affero General Public License (AGPL), version 3
-* GNU Free Documentation License
-* GNU General Public License (GPL), version 2 or 3
-* GNU Lesser General Public License (LGPL), version 2.1 or 3
-* Open Publication License, version 1.0
+* [http://www.apache.org/licenses/LICENSE-2.0 Apache License, version 2.0]
+* [http://www.boost.org/LICENSE_1_0.txt Boost Software License, version 1.0]
+* [https://creativecommons.org/licenses/by/4.0/ Creative Commons Attribution 4.0 International]
+* [https://creativecommons.org/licenses/by-sa/4.0/ Creative Commons Attribution-ShareAlike 4.0 International]
+* [https://opensource.org/licenses/MIT Expat/MIT/X11 license]
+* [http://www.gnu.org/licenses/agpl-3.0.en.html GNU Affero General Public License (AGPL), version 3 or newer]
+* [http://www.gnu.org/licenses/fdl-1.3.en.html GNU Free Documentation License]
+* [http://www.gnu.org/licenses/old-licenses/gpl-2.0.en.html GNU General Public License (GPL), version 2 or newer]
+* [http://www.gnu.org/licenses/old-licenses/lgpl-2.1.en.html GNU Lesser General Public License (LGPL), version 2.1 or newer]
+* [http://opencontent.org/openpub/ Open Publication License, version 1.0]
 
 ==See Also==
 

From 97655c211a7454b4bcc01acefd4b88f979e7853f Mon Sep 17 00:00:00 2001
From: Luke Dashjr 
Date: Mon, 1 Feb 2016 23:49:37 +0000
Subject: [PATCH 186/259] bip-biprevised: Clarify licensing of literal code
 inclusion in BIPs

---
 bip-biprevised.mediawiki | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/bip-biprevised.mediawiki b/bip-biprevised.mediawiki
index 07749629..18ec1ddd 100644
--- a/bip-biprevised.mediawiki
+++ b/bip-biprevised.mediawiki
@@ -77,6 +77,8 @@ New BIPs may be accepted with the following licenses:
 * [https://creativecommons.org/publicdomain/zero/1.0/ Creative Commons CC0 1.0 Universal]
 * [http://www.gnu.org/prep/maintain/html_node/License-Notices-for-Other-Files.html GNU All-Permissive License]
 
+In addition, it is recommended that literal code included in the BIP be available under the same license terms as the project it modifies, when that license is acceptable within a BIP. For example, literal code intended for Bitcoin Core would ideally be dual-licensed under the MIT license terms (listed below, as not recommended but acceptable) as well as one of the above with the rest of the BIP text.
+
 ====Not recommented, but acceptable licenses====
 
 * [http://www.apache.org/licenses/LICENSE-2.0 Apache License, version 2.0]

From fe0870ed0630f663c6d2df8626780b5800241a56 Mon Sep 17 00:00:00 2001
From: Luke Dashjr 
Date: Tue, 2 Feb 2016 00:37:08 +0000
Subject: [PATCH 187/259] bip-biprevised: Add Rationales and clarify literal
 code licensing

---
 bip-biprevised.mediawiki | 43 +++++++++++++++++++++++++++++++++++-----
 1 file changed, 38 insertions(+), 5 deletions(-)

diff --git a/bip-biprevised.mediawiki b/bip-biprevised.mediawiki
index 18ec1ddd..93af1b8d 100644
--- a/bip-biprevised.mediawiki
+++ b/bip-biprevised.mediawiki
@@ -17,9 +17,9 @@ This BIP intends to address these problems by more specifically defining the Sta
 
 This BIP is dual-licensed under the Open Publication License and BSD 2-clause license.
 
-==Specification==
+==BIP status field==
 
-===BIP status field===
+===Specification===
 
 Champions of a BIP may decide on their own to change the status between Draft, Deferred, or Withdrawn.
 
@@ -51,7 +51,24 @@ Software authors are encouraged to publish summaries of what BIPs their software
 
 A proposal is said to have achieved consensus if it has been open to discussion in applicable forums for communication for at least one month, and has not maintained any substantiated objection by any person. Should objections to be made on a strictly obstructive basis, those obstructing may be ignored/overruled by agreement that they are merely being obstructive from all other persons involved in the discussion.
 
-===BIP comments===
+===Rationale===
+
+Why can the economic consensus veto a soft-fork?
+
+* The group of miners is determined by the consensus rules for the dynamic-membership multi-party signature (for Bitcoin, the proof-of-work algorithm), which can be modified with a hard-fork. Thus, if the same conditions required to modify this group are met in opposition to a soft-fork, the miner majority supporting the soft-fork is effectively void because the economic consensus can decide to replace them with another group of would-be miners who do not support the soft-fork.
+
+What is the ideal percentage of listening nodes needed to adopt peer services proposals?
+
+* This is unknown, and set rather arbitrarily at this time. For a random selection of peers to have at least one other peer implementing the extension, 13% or more would be necessary, but nodes could continue to scan the network for such peers with perhaps some reasonable success. Furthermore, service bits exist to help identification upfront.
+
+Should two software projects need to release an implementation of API/RPC and application layer BIPs?
+
+* With only one implementation of these, there is no other program for which a standard interface is used with or needed.
+* Even if there are only two projects, some standard coordination between them exists.
+
+==BIP comments==
+
+===Specification===
 
 Each BIP should, in its preamble, link to a Bitcoin Wiki page with a summary tone of the comments on that page.
 
@@ -66,10 +83,19 @@ Summary tones may be chosen from the following, but this BIP does not intend to
 
 To avoid doubt: comments and status are unrelated metrics to judge a BIP, and neither should be directly influencing the other.
 
-===BIP licensing===
+===Rationale===
+
+Will BIP comments be censored or limited to particular participants/"experts"?
+
+* The Bitcoin Wiki moderators have control over that venue and may make reasonable moderation attempts. Admitted non-experts should refrain from commenting outside of their area of knowledge. However, comments should not be censored, and participation should be open to the public.
+* If the Bitcoin Wiki were to abuse its position, the venue for comments can always be changed.
+
+==BIP licensing==
 
 New BIPs may be accepted with the following licenses:
 
+===Specification===
+
 ====Recommended licenses====
 
 * [https://opensource.org/licenses/BSD-2-Clause OSI-approved BSD 2-clause license]
@@ -77,7 +103,7 @@ New BIPs may be accepted with the following licenses:
 * [https://creativecommons.org/publicdomain/zero/1.0/ Creative Commons CC0 1.0 Universal]
 * [http://www.gnu.org/prep/maintain/html_node/License-Notices-for-Other-Files.html GNU All-Permissive License]
 
-In addition, it is recommended that literal code included in the BIP be available under the same license terms as the project it modifies, when that license is acceptable within a BIP. For example, literal code intended for Bitcoin Core would ideally be dual-licensed under the MIT license terms (listed below, as not recommended but acceptable) as well as one of the above with the rest of the BIP text.
+In addition, it is recommended that literal code included in the BIP be dual-licensed under the same license terms as the project it modifies. For example, literal code intended for Bitcoin Core would ideally be dual-licensed under the MIT license terms as well as one of the above with the rest of the BIP text.
 
 ====Not recommented, but acceptable licenses====
 
@@ -92,6 +118,13 @@ In addition, it is recommended that literal code included in the BIP be availabl
 * [http://www.gnu.org/licenses/old-licenses/lgpl-2.1.en.html GNU Lesser General Public License (LGPL), version 2.1 or newer]
 * [http://opencontent.org/openpub/ Open Publication License, version 1.0]
 
+===Rationale===
+
+Why are there software licenses included?
+
+* Some BIPs, especially consensus layer, may include literal code in the BIP itself which may not be available under the exact license terms of the BIP.
+* Despite this, not all software licenses would be acceptable for content included in BIPs.
+
 ==See Also==
 
 * [[bip-0001.mediawiki|BIP 1: BIP Purpose and Guidelines]]

From 81741909838adc2e2c0f4d7f3c66f54a01e6e010 Mon Sep 17 00:00:00 2001
From: Luke Dashjr 
Date: Tue, 2 Feb 2016 04:14:26 +0000
Subject: [PATCH 188/259] bip-biprevised: Add Rationale for defining of the
 economy

---
 bip-biprevised.mediawiki | 11 +++++++++++
 1 file changed, 11 insertions(+)

diff --git a/bip-biprevised.mediawiki b/bip-biprevised.mediawiki
index 93af1b8d..a4746de2 100644
--- a/bip-biprevised.mediawiki
+++ b/bip-biprevised.mediawiki
@@ -53,6 +53,17 @@ A proposal is said to have achieved consensus if it has been open to discussion
 
 ===Rationale===
 
+How is the entire Bitcoin economy defined by people selling goods/services and holders?
+
+* For Bitcoin to function as a currency, it must be accepted as payment. Bitcoins have no value if you cannot acquire anything in exchange for them. If everyone accepting such payments requires a particular set of consensus rules, "bitcoins" are de facto defined by that set of rules - this is already the case today. If those consensus rules are expected to broaden (as with a hard-fork), those merchants need to accept payments made under the new set of rules, or they will reject "bitcoins" as invalid. Holders are relevant to the degree in that they choose the merchants they wish to spend their bitcoins with, and could also as a whole decide to sell under one set of consensus rules or the other, thus flooding the market with bitcoins and crashing the price.
+
+Why aren't  included in the economy?
+
+* Some entities may, to some degree, also be involved in offering goods and/or services in exchange for bitcoins, thus in that capacity (but not their capacity as ) be involved in the economy.
+* Miners are not included in the economy, because they merely *rely on* others to sell/spend their otherwise-worthless mined produce. Therefore, they must accept everyone else's direction in deciding the consensus rules.
+* Exchanges are not included in the economy, because they merely provide services of connecting the merchants and users who wish to trade. Even if all exchanges were to defect from Bitcoin, those merchants and users can always trade directly and/or establish their own exchanges.
+* Developers are not included in the economy, since they merely write code, and it is up to others to decide to use that code or not.
+
 Why can the economic consensus veto a soft-fork?
 
 * The group of miners is determined by the consensus rules for the dynamic-membership multi-party signature (for Bitcoin, the proof-of-work algorithm), which can be modified with a hard-fork. Thus, if the same conditions required to modify this group are met in opposition to a soft-fork, the miner majority supporting the soft-fork is effectively void because the economic consensus can decide to replace them with another group of would-be miners who do not support the soft-fork.

From 9906db4b7a1ee58f688431f02af500de3ac351df Mon Sep 17 00:00:00 2001
From: Luke Dashjr 
Date: Tue, 2 Feb 2016 06:10:52 +0000
Subject: [PATCH 189/259] bip-biprevised: Add Rationale explaining how-it-is

---
 bip-biprevised.mediawiki | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/bip-biprevised.mediawiki b/bip-biprevised.mediawiki
index a4746de2..29de31a5 100644
--- a/bip-biprevised.mediawiki
+++ b/bip-biprevised.mediawiki
@@ -64,6 +64,10 @@ Why aren't  included in the economy?
 * Exchanges are not included in the economy, because they merely provide services of connecting the merchants and users who wish to trade. Even if all exchanges were to defect from Bitcoin, those merchants and users can always trade directly and/or establish their own exchanges.
 * Developers are not included in the economy, since they merely write code, and it is up to others to decide to use that code or not.
 
+But they're doing something important and have invested a lot in Bitcoin! Shouldn't they be included in such an important decision?
+
+* This BIP does not aim to address what "should" be the basis of decisions. Such a statement, no matter how perfect in its justification, would be futile without some way to enforce it. The BIP process does not aim to be a kind of "governance" of Bitcoin, merely to provide a collaborative repository for proposing and providing information on standards. It can only hope to achieve accuracy in regard to the "Status" field by striving to reflect the reality of *how things actually are*, rather than *how they should be*.
+
 Why can the economic consensus veto a soft-fork?
 
 * The group of miners is determined by the consensus rules for the dynamic-membership multi-party signature (for Bitcoin, the proof-of-work algorithm), which can be modified with a hard-fork. Thus, if the same conditions required to modify this group are met in opposition to a soft-fork, the miner majority supporting the soft-fork is effectively void because the economic consensus can decide to replace them with another group of would-be miners who do not support the soft-fork.

From ae7cc37fe00e17e433a3b2d536737be5439c7ac0 Mon Sep 17 00:00:00 2001
From: Luke Dashjr 
Date: Tue, 2 Feb 2016 07:51:09 +0000
Subject: [PATCH 190/259] bip-biprevised: Address comments by Dave Scotese and
 Ryan Grant

---
 bip-biprevised.mediawiki | 19 ++++++++++++++-----
 1 file changed, 14 insertions(+), 5 deletions(-)

diff --git a/bip-biprevised.mediawiki b/bip-biprevised.mediawiki
index 29de31a5..b9efbc64 100644
--- a/bip-biprevised.mediawiki
+++ b/bip-biprevised.mediawiki
@@ -49,7 +49,7 @@ Software authors are encouraged to publish summaries of what BIPs their software
 
 ====Formally defining consensus====
 
-A proposal is said to have achieved consensus if it has been open to discussion in applicable forums for communication for at least one month, and has not maintained any substantiated objection by any person. Should objections to be made on a strictly obstructive basis, those obstructing may be ignored/overruled by agreement that they are merely being obstructive from all other persons involved in the discussion.
+A proposal is said to have achieved consensus if it has been open to discussion in applicable forums for communication for at least one month, and has not maintained any substantiated objection by any person. Should objections to be made on a strictly obstructive basis, those obstructing may be ignored/overruled by agreement that they are merely being obstructive from all other persons involved in the discussion. Objections are assumed to be either substantiated or obstructive, and when giving a determination of an objection being obstructive, clear reasoning must be offered.
 
 ===Rationale===
 
@@ -76,26 +76,35 @@ What is the ideal percentage of listening nodes needed to adopt peer services pr
 
 * This is unknown, and set rather arbitrarily at this time. For a random selection of peers to have at least one other peer implementing the extension, 13% or more would be necessary, but nodes could continue to scan the network for such peers with perhaps some reasonable success. Furthermore, service bits exist to help identification upfront.
 
-Should two software projects need to release an implementation of API/RPC and application layer BIPs?
+Why is it necessary for at least two software projects to release an implementation of API/RPC and application layer BIPs, before they become Final?
 
-* With only one implementation of these, there is no other program for which a standard interface is used with or needed.
-* Even if there are only two projects, some standard coordination between them exists.
+* If there is only one implementation of a specification, there is no other program for which a standard interface is used with or needed.
+* Even if there are only two projects rather than more, some standard coordination between them exists.
+
+What if a BIP is proposed that only makes sense for a single specific project?
+
+* The BIP process exists for standardisation between independent projects. If something only affects one project, it should be done through that project's own internal processes, and never be proposed as a BIP in the first place.
 
 ==BIP comments==
 
 ===Specification===
 
-Each BIP should, in its preamble, link to a Bitcoin Wiki page with a summary tone of the comments on that page.
+Each BIP should, in its preamble, link to a Bitcoin Wiki page with a summary tone of the comments on that page. Reviewers of the BIP who consider themselves qualified, should post their own comments on this wiki page in [https://www.mediawiki.org/wiki/Help:Talk_pages#Editing_conventions_on_talk_pages standard "Talk page" format]. If a BIP is not yet completed, reviewers should plan to review the new version and remove or revise their comments as applicable, updating the timestamp in the review. Reviews made prior to the complete version may be removed if they are no longer applicable and have not been updated in a timely manner (eg, within one month).
 
 Pages must be named after the full BIP number (eg, "BIP 0001") and placed in the "BIP Comments" namespace. For example, the link for BIP 1 will be https://en.bitcoin.it/wiki/BIP_Comments:BIP_0001 .
 
 Summary tones may be chosen from the following, but this BIP does not intend to cover all possible nuances:
 
+* No comments yet.
 * Unanimously Recommended for implementation
 * Unanimously Discourage for implementation
 * Mostly Recommended for implementation, with some Discouragement
 * Mostly Discouraged for implementation, with some Recommendation
 
+For example, the preamble to BIP 1 would be updated to include the (markup) line:
+
+    Comments: [https://en.bitcoin.it/wiki/BIP_Comments:BIP_0001 No comments yet.]
+
 To avoid doubt: comments and status are unrelated metrics to judge a BIP, and neither should be directly influencing the other.
 
 ===Rationale===

From ddd34bf496f2cbd1fad7e2ac14c080ffa1b88e0a Mon Sep 17 00:00:00 2001
From: Luke Dashjr 
Date: Tue, 2 Feb 2016 07:54:03 +0000
Subject: [PATCH 191/259] Bugfix: bip-biprevised: Preamble cannot use links due
 to 

---
 bip-biprevised.mediawiki | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/bip-biprevised.mediawiki b/bip-biprevised.mediawiki
index b9efbc64..7c759954 100644
--- a/bip-biprevised.mediawiki
+++ b/bip-biprevised.mediawiki
@@ -103,7 +103,8 @@ Summary tones may be chosen from the following, but this BIP does not intend to
 
 For example, the preamble to BIP 1 would be updated to include the (markup) line:
 
-    Comments: [https://en.bitcoin.it/wiki/BIP_Comments:BIP_0001 No comments yet.]
+    Comments-Summary: No comments yet.
+    Comments-URI: https://en.bitcoin.it/wiki/BIP_Comments:BIP_0001
 
 To avoid doubt: comments and status are unrelated metrics to judge a BIP, and neither should be directly influencing the other.
 

From c79db0a9eced8e6baa76a7f16153572e5749321b Mon Sep 17 00:00:00 2001
From: emeth- 
Date: Tue, 2 Feb 2016 06:19:47 -0600
Subject: [PATCH 192/259] fix typo

---
 bip-biprevised.mediawiki | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/bip-biprevised.mediawiki b/bip-biprevised.mediawiki
index 7c759954..094d156f 100644
--- a/bip-biprevised.mediawiki
+++ b/bip-biprevised.mediawiki
@@ -130,7 +130,7 @@ New BIPs may be accepted with the following licenses:
 
 In addition, it is recommended that literal code included in the BIP be dual-licensed under the same license terms as the project it modifies. For example, literal code intended for Bitcoin Core would ideally be dual-licensed under the MIT license terms as well as one of the above with the rest of the BIP text.
 
-====Not recommented, but acceptable licenses====
+====Not recommended, but acceptable licenses====
 
 * [http://www.apache.org/licenses/LICENSE-2.0 Apache License, version 2.0]
 * [http://www.boost.org/LICENSE_1_0.txt Boost Software License, version 1.0]

From 56eb7958bd380010117a68bb438c5683026ee6a5 Mon Sep 17 00:00:00 2001
From: Luke Dashjr 
Date: Tue, 2 Feb 2016 19:03:28 +0000
Subject: [PATCH 193/259] bip-biprevised: Clarify informational nature of Final
 status change criteria

---
 bip-biprevised.mediawiki | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/bip-biprevised.mediawiki b/bip-biprevised.mediawiki
index 7c759954..174c9f9b 100644
--- a/bip-biprevised.mediawiki
+++ b/bip-biprevised.mediawiki
@@ -47,6 +47,8 @@ API/RPC and application layer BIPs must be implemented by at least two independe
 
 Software authors are encouraged to publish summaries of what BIPs their software supports to aid in verification of status changes. Good examples of this at the time of writing this BIP, can be observed in [https://github.com/bitcoin/bitcoin/blob/master/doc/bips.md Bitcoin Core's doc/bips.md file] as well as [https://github.com/schildbach/bitcoin-wallet/blob/master/wallet/README.specs Bitcoin Wallet for Android's wallet/README.specs file].
 
+These criteria are considered objective ways to observe the de facto adoption of the BIP, and are not to be used as reasons to oppose or reject a BIP. Should a BIP become actually and unambiguously adopted despite not meeting the criteria outlined here, it should still be updated to Final status.
+
 ====Formally defining consensus====
 
 A proposal is said to have achieved consensus if it has been open to discussion in applicable forums for communication for at least one month, and has not maintained any substantiated objection by any person. Should objections to be made on a strictly obstructive basis, those obstructing may be ignored/overruled by agreement that they are merely being obstructive from all other persons involved in the discussion. Objections are assumed to be either substantiated or obstructive, and when giving a determination of an objection being obstructive, clear reasoning must be offered.

From c5f9a101111276b5e27cbe2bca1cd4942ebca508 Mon Sep 17 00:00:00 2001
From: Luke Dashjr 
Date: Tue, 2 Feb 2016 19:07:14 +0000
Subject: [PATCH 194/259] bip-biprevised: Allow for a second forum for BIP
 comments

---
 bip-biprevised.mediawiki | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/bip-biprevised.mediawiki b/bip-biprevised.mediawiki
index 174c9f9b..4e30f242 100644
--- a/bip-biprevised.mediawiki
+++ b/bip-biprevised.mediawiki
@@ -95,6 +95,8 @@ Each BIP should, in its preamble, link to a Bitcoin Wiki page with a summary ton
 
 Pages must be named after the full BIP number (eg, "BIP 0001") and placed in the "BIP Comments" namespace. For example, the link for BIP 1 will be https://en.bitcoin.it/wiki/BIP_Comments:BIP_0001 .
 
+In order to avoid possible abuse of Bitcoin Wiki moderation, BIPs may also choose to list a second forum for BIP comments.
+
 Summary tones may be chosen from the following, but this BIP does not intend to cover all possible nuances:
 
 * No comments yet.

From 4edd6d2badd9a6ad2ff09bb6792fe0d0e365a7de Mon Sep 17 00:00:00 2001
From: Luke Dashjr 
Date: Wed, 3 Feb 2016 07:02:36 +0000
Subject: [PATCH 195/259] Lots of formatting fixes

---
 README.mediawiki   | 98 +++++++++++++++++++++++-----------------------
 bip-0001.mediawiki |  1 +
 bip-0009.mediawiki |  7 +++-
 bip-0010.mediawiki |  4 +-
 bip-0014.mediawiki |  2 +-
 bip-0015.mediawiki |  2 +-
 bip-0032.mediawiki |  2 +-
 bip-0037.mediawiki |  3 +-
 bip-0038.mediawiki |  4 +-
 bip-0039.mediawiki | 16 ++++----
 bip-0043.mediawiki | 12 +++---
 bip-0044.mediawiki | 12 +++---
 bip-0045.mediawiki | 14 +++----
 bip-0047.mediawiki | 13 +++---
 bip-0067.mediawiki |  5 ++-
 bip-0069.mediawiki | 12 +++---
 bip-0070.mediawiki |  3 +-
 bip-0074.mediawiki |  3 ++
 bip-0080.mediawiki | 12 +++---
 bip-0081.mediawiki | 12 +++---
 bip-0083.mediawiki | 10 ++---
 bip-0099.mediawiki |  2 +-
 bip-0107.mediawiki |  2 +-
 bip-0111.mediawiki |  3 +-
 bip-0112.mediawiki |  6 +--
 bip-0113.mediawiki |  2 +-
 bip-0122.mediawiki |  2 +-
 bip-0123.mediawiki |  2 +-
 bip-0124.mediawiki | 12 +++---
 bip-0125.mediawiki |  3 +-
 bip-0132.mediawiki |  2 +-
 bip-0144.mediawiki |  2 +-
 32 files changed, 147 insertions(+), 138 deletions(-)

diff --git a/README.mediawiki b/README.mediawiki
index eda7fbfd..8067faee 100644
--- a/README.mediawiki
+++ b/README.mediawiki
@@ -24,13 +24,13 @@ Those proposing changes should consider that ultimately consent may rest with th
 | Pieter Wuille, Peter Todd, Greg Maxwell, Rusty Russell
 | Informational
 | Draft
-|-
+|- style="background-color: #ffcfcf"
 | [[bip-0010.mediawiki|10]]
 | Multi-Sig Transaction Distribution
 | Alan Reiner
 | Informational
 | Withdrawn
-|- style="background-color: #cfffcf"
+|- style="background-color: #ffffcf"
 | [[bip-0011.mediawiki|11]]
 | M-of-N Standard Transactions
 | Gavin Andresen
@@ -48,13 +48,13 @@ Those proposing changes should consider that ultimately consent may rest with th
 | Gavin Andresen
 | Standard
 | Final
-|- style="background-color: #cfffcf"
+|- style="background-color: #ffffcf"
 | [[bip-0014.mediawiki|14]]
 | Protocol Version and User Agent
 | Amir Taaki, Patrick Strateman
 | Standard
 | Accepted
-|- style="background-color: #ffcfcf"
+|-
 | [[bip-0015.mediawiki|15]]
 | Aliases
 | Amir Taaki
@@ -62,7 +62,7 @@ Those proposing changes should consider that ultimately consent may rest with th
 | Deferred
 |- style="background-color: #cfffcf"
 | [[bip-0016.mediawiki|16]]
-| Pay To Script Hash
+| Pay to Script Hash
 | Gavin Andresen
 | Standard
 | Final
@@ -90,19 +90,19 @@ Those proposing changes should consider that ultimately consent may rest with th
 | Luke Dashjr
 | Standard
 | Replaced
-|- style="background-color: #cfffcf"
+|- style="background-color: #ffffcf"
 | [[bip-0021.mediawiki|21]]
 | URI Scheme
 | Nils Schneider, Matt Corallo
 | Standard
 | Accepted
-|- style="background-color: #cfffcf"
+|- style="background-color: #ffffcf"
 | [[bip-0022.mediawiki|22]]
 | getblocktemplate - Fundamentals
 | Luke Dashjr
 | Standard
 | Accepted
-|- style="background-color: #cfffcf"
+|- style="background-color: #ffffcf"
 | [[bip-0023.mediawiki|23]]
 | getblocktemplate - Pooled Mining
 | Luke Dashjr
@@ -114,13 +114,13 @@ Those proposing changes should consider that ultimately consent may rest with th
 | Pieter Wuille
 | Standard
 | Final
-|- style="background-color: #cfffcf"
+|- style="background-color: #ffffcf"
 | [[bip-0031.mediawiki|31]]
 | Pong message
 | Mike Hearn
 | Standard
 | Accepted
-|- style="background-color: #cfffcf"
+|- style="background-color: #ffffcf"
 | [[bip-0032.mediawiki|32]]
 | Hierarchical Deterministic Wallets
 | Pieter Wuille
@@ -132,13 +132,13 @@ Those proposing changes should consider that ultimately consent may rest with th
 | Amir Taaki
 | Standard
 | Draft
-|- style="background-color: #cfffcf"
+|- style="background-color: #ffffcf"
 | [[bip-0034.mediawiki|34]]
-| Block v2, Height in coinbase
+| Block v2, Height in Coinbase
 | Gavin Andresen
 | Standard
 | Accepted
-|- style="background-color: #cfffcf"
+|- style="background-color: #ffffcf"
 | [[bip-0035.mediawiki|35]]
 | mempool message
 | Jeff Garzik
@@ -150,34 +150,34 @@ Those proposing changes should consider that ultimately consent may rest with th
 | Stefan Thomas
 | Standard
 | Draft
-|- style="background-color: #cfffcf"
+|- style="background-color: #ffffcf"
 | [[bip-0037.mediawiki|37]]
-| Bloom filtering
+| Connection Bloom filtering
 | Mike Hearn, Matt Corallo
 | Standard
 | Accepted
 |-
 | [[bip-0038.mediawiki|38]]
 | Passphrase-protected private key
-| Mike Caldwell
+| Mike Caldwell, Aaron Voisine
 | Standard
 | Draft
 |-
 | [[bip-0039.mediawiki|39]]
 | Mnemonic code for generating deterministic keys
-| Slush
+| Marek Palatinus, Pavol Rusnak, Aaron Voisine, Sean Bowe
 | Standard
 | Draft
 |-
 | 40
 | Stratum wire protocol
-| Slush
+| Marek Palatinus
 | Standard
 | BIP number allocated
 |-
 | 41
 | Stratum mining protocol
-| Slush
+| Marek Palatinus
 | Standard
 | BIP number allocated
 |-
@@ -189,19 +189,19 @@ Those proposing changes should consider that ultimately consent may rest with th
 |-
 | [[bip-0043.mediawiki|43]]
 | Purpose Field for Deterministic Wallets
-| Slush
+| Marek Palatinus, Pavol Rusnak
 | Standard
 | Draft
 |-
 | [[bip-0044.mediawiki|44]]
 | Multi-Account Hierarchy for Deterministic Wallets
-| Slush
+| Marek Palatinus, Pavol Rusnak
 | Standard
 | Draft
 |-
 | [[bip-0045.mediawiki|45]]
 | Structure for Deterministic P2SH Multisignature Wallets
-| Manuel Araoz
+| Manuel Araoz, Ryan X. Charles, Matias Alejo Garcia
 | Standard
 | Draft
 |-
@@ -223,13 +223,13 @@ Those proposing changes should consider that ultimately consent may rest with th
 | Amir Taaki
 | Standard
 | Draft
-|-
+|- style="background-color: #cfffcf"
 | [[bip-0061.mediawiki|61]]
-| "reject" P2P message
+| Reject P2P message
 | Gavin Andresen
 | Standard
 | Final
-|-
+|- style="background-color: #ffcfcf"
 | [[bip-0062.mediawiki|62]]
 | Dealing with malleability
 | Pieter Wuille
@@ -243,80 +243,80 @@ Those proposing changes should consider that ultimately consent may rest with th
 | BIP number allocated
 |-
 | [[bip-0064.mediawiki|64]]
-| getutxos message
+| getutxo message
 | Mike Hearn
 | Standard
 | Draft
-|-
+|- style="background-color: #ffffcf"
 | [[bip-0065.mediawiki|65]]
 | OP_CHECKLOCKTIMEVERIFY
 | Peter Todd
 | Standard
 | Accepted
-|-
+|- style="background-color: #cfffcf"
 | [[bip-0066.mediawiki|66]]
 | Strict DER signatures
 | Pieter Wuille
 | Standard
-| Draft
+| Final
 |-
 | [[bip-0067.mediawiki|67]]
-| Deterministic P2SH multi-signature addresses
-| Thomas Kerin
+| Deterministic Pay-to-script-hash multi-signature addresses through public key sorting
+| Thomas Kerin, Jean-Pierre Rupp, Ruben de Vries
 | Standard
 | Draft
 |-
 | [[bip-0068.mediawiki|68]]
-| Relative lock-time through consensus-enforced sequence numbers
-| Mark Friedenbach, BtcDrak, Nicolas Dorier
+| Relative lock-time using consensus-enforced sequence numbers
+| Mark Friedenbach, BtcDrak, Nicolas Dorier, kinoshitajona
 | Standard
 | Draft
 |-
 | [[bip-0069.mediawiki|69]]
 | Lexicographical Indexing of Transaction Inputs and Outputs
 | Kristov Atlas
-| Standard
+| Informational
 | Draft
-|-
+|- style="background-color: #cfffcf"
 | [[bip-0070.mediawiki|70]]
-| Payment protocol
-| Gavin Andresen
+| Payment Protocol
+| Gavin Andresen, Mike Hearn
 | Standard
 | Final
-|-
+|- style="background-color: #cfffcf"
 | [[bip-0071.mediawiki|71]]
-| Payment protocol MIME types
+| Payment Protocol MIME types
 | Gavin Andresen
 | Standard
 | Final
-|-
+|- style="background-color: #cfffcf"
 | [[bip-0072.mediawiki|72]]
-| Payment protocol URIs
+| bitcoin: uri extensions for Payment Protocol
 | Gavin Andresen
 | Standard
 | Final
 |-
 | [[bip-0073.mediawiki|73]]
-| Use "Accept" header with Payment Request URLs
+| Use "Accept" header for response type negotiation with Payment Request URLs
 | Stephen Pair
 | Standard
 | Draft
 |-
 | [[bip-0074.mediawiki|74]]
-| Support zero value OP_RETURN in Payment Requests
+| Allow zero value OP_RETURN in Payment Protocol
 | Toby Padilla
 | Standard
 | Draft
 |-
 | [[bip-0080.mediawiki|80]]
 | Hierarchy for Non-Colored Voting Pool Deterministic Multisig Wallets
-| Monetas
+| Justus Ranvier, Jimmy Song
 | Informational
 | Draft
 |-
 | [[bip-0081.mediawiki|81]]
 | Hierarchy for Colored Voting Pool Deterministic Multisig Wallets
-| Monetas
+| Justus Ranvier, Jimmy Song
 | Informational
 | Draft
 |-
@@ -329,7 +329,7 @@ Those proposing changes should consider that ultimately consent may rest with th
 | [[bip-0099.mediawiki|99]]
 | Motivation and deployment of consensus rule changes ([soft/hard]forks)
 | Jorge Timón
-| Informational / Process
+| Informational
 | Draft
 |-
 | [[bip-0101.mediawiki|101]]
@@ -376,7 +376,7 @@ Those proposing changes should consider that ultimately consent may rest with th
 |-
 | [[bip-0112.mediawiki|112]]
 | CHECKSEQUENCEVERIFY
-| BtcDrak, Mark Friedenbach
+| BtcDrak, Mark Friedenbach, Eric Lombrozo
 | Standard
 | Draft
 |-
@@ -407,7 +407,7 @@ Those proposing changes should consider that ultimately consent may rest with th
 | [[bip-0123.mediawiki|123]]
 | BIP Classification
 | Eric Lombrozo
-| Informational
+| Process
 | Draft
 |-
 | [[bip-0124.mediawiki|124]]
@@ -418,7 +418,7 @@ Those proposing changes should consider that ultimately consent may rest with th
 |-
 | [[bip-0125.mediawiki|125]]
 | Opt-in Full Replace-by-Fee Signaling
-| David Harding, Peter Todd
+| David A. Harding, Peter Todd
 | Standard
 | Draft
 |-
diff --git a/bip-0001.mediawiki b/bip-0001.mediawiki
index e1abaddc..4f91a394 100644
--- a/bip-0001.mediawiki
+++ b/bip-0001.mediawiki
@@ -1,6 +1,7 @@
 
   BIP: 1
   Title: BIP Purpose and Guidelines
+  Author: Amir Taaki 
   Status: Active
   Type: Process
   Created: 2011-08-19
diff --git a/bip-0009.mediawiki b/bip-0009.mediawiki
index b160810f..78298f09 100644
--- a/bip-0009.mediawiki
+++ b/bip-0009.mediawiki
@@ -1,9 +1,12 @@
 
   BIP: 9
   Title: Version bits with timeout and delay
-  Author: Pieter Wuille , Peter Todd , Greg Maxwell , Rusty Russell 
+  Author: Pieter Wuille 
+          Peter Todd 
+          Greg Maxwell 
+          Rusty Russell 
   Status: Draft
-  Type: Informational Track
+  Type: Informational
   Created: 2015-10-04
 

 
diff --git a/bip-0010.mediawiki b/bip-0010.mediawiki
index 4307f3e4..d15cd77e 100644
--- a/bip-0010.mediawiki
+++ b/bip-0010.mediawiki
@@ -1,8 +1,8 @@
 
   BIP: 10
   Title: Multi-Sig Transaction Distribution
-  Author: Alan Reiner
-  Status: Withdrawn 
+  Author: Alan Reiner 
+  Status: Withdrawn
   Type: Informational
   Created: 2011-10-28
 

diff --git a/bip-0014.mediawiki b/bip-0014.mediawiki
index 111eb78b..2cfb3277 100644
--- a/bip-0014.mediawiki
+++ b/bip-0014.mediawiki
@@ -1,6 +1,6 @@
 
   BIP: 14
-  Title: BIP Protocol Version and User Agent
+  Title: Protocol Version and User Agent
   Author: Amir Taaki 
           Patrick Strateman 
   Status: Accepted
diff --git a/bip-0015.mediawiki b/bip-0015.mediawiki
index c08498f1..b90539da 100644
--- a/bip-0015.mediawiki
+++ b/bip-0015.mediawiki
@@ -1,6 +1,6 @@
 
   BIP: 15
-  Title: BIP Aliases
+  Title: Aliases
   Author: Amir Taaki 
   Status: Deferred
   Type: Standards Track
diff --git a/bip-0032.mediawiki b/bip-0032.mediawiki
index ac0ed991..ec5ddf4e 100644
--- a/bip-0032.mediawiki
+++ b/bip-0032.mediawiki
@@ -7,7 +7,7 @@ RECENT CHANGES:
 
   BIP: 32
   Title: Hierarchical Deterministic Wallets
-  Author: Pieter Wuille
+  Author: Pieter Wuille 
   Status: Accepted
   Type: Informational
   Created: 2012-02-11
diff --git a/bip-0037.mediawiki b/bip-0037.mediawiki
index 77b917b3..224fef52 100644
--- a/bip-0037.mediawiki
+++ b/bip-0037.mediawiki
@@ -1,7 +1,8 @@
 
   BIP: 37
   Title: Connection Bloom filtering
-  Author: Mike Hearn , Matt Corallo 
+  Author: Mike Hearn 
+          Matt Corallo 
   Status: Accepted
   Type: Standards Track
   Created: 2012-10-24
diff --git a/bip-0038.mediawiki b/bip-0038.mediawiki
index 4fc3207b..6107e0a5 100644
--- a/bip-0038.mediawiki
+++ b/bip-0038.mediawiki
@@ -1,8 +1,8 @@
 
   BIP: 38
   Title: Passphrase-protected private key
-  Authors: Mike Caldwell
-           Aaron Voisine 
+  Author: Mike Caldwell 
+          Aaron Voisine 
   Status: Draft (Some confusion applies: The announcements for this never made it to the list, so it hasn't had public discussion)
   Type: Standards Track
   Created: 2012-11-20
diff --git a/bip-0039.mediawiki b/bip-0039.mediawiki
index da59124c..c44ad3e8 100644
--- a/bip-0039.mediawiki
+++ b/bip-0039.mediawiki
@@ -1,12 +1,12 @@
 
-  BIP:     BIP-0039
-  Title:   Mnemonic code for generating deterministic keys
-  Authors: Marek Palatinus 
-           Pavol Rusnak 
-           Aaron Voisine 
-           Sean Bowe 
-  Status:  Draft
-  Type:    Standards Track
+  BIP: 39
+  Title: Mnemonic code for generating deterministic keys
+  Author: Marek Palatinus 
+          Pavol Rusnak 
+          Aaron Voisine 
+          Sean Bowe 
+  Status: Draft
+  Type: Standards Track
   Created: 2013-09-10
 

 
diff --git a/bip-0043.mediawiki b/bip-0043.mediawiki
index 8f20fc8c..4c57935e 100644
--- a/bip-0043.mediawiki
+++ b/bip-0043.mediawiki
@@ -1,10 +1,10 @@
 
-  BIP:     BIP-0043
-  Title:   Purpose Field for Deterministic Wallets
-  Authors: Marek Palatinus 
-           Pavol Rusnak 
-  Status:  Draft
-  Type:    Standards Track
+  BIP: 43
+  Title: Purpose Field for Deterministic Wallets
+  Author: Marek Palatinus 
+          Pavol Rusnak 
+  Status: Draft
+  Type: Standards Track
   Created: 2014-04-24
 

 
diff --git a/bip-0044.mediawiki b/bip-0044.mediawiki
index ef7254c1..6012ff52 100644
--- a/bip-0044.mediawiki
+++ b/bip-0044.mediawiki
@@ -1,10 +1,10 @@
 
-  BIP:     BIP-0044
-  Title:   Multi-Account Hierarchy for Deterministic Wallets
-  Authors: Marek Palatinus 
-           Pavol Rusnak 
-  Status:  Draft
-  Type:    Standards Track
+  BIP: 44
+  Title: Multi-Account Hierarchy for Deterministic Wallets
+  Author: Marek Palatinus 
+          Pavol Rusnak 
+  Status: Draft
+  Type: Standards Track
   Created: 2014-04-24
 

 
diff --git a/bip-0045.mediawiki b/bip-0045.mediawiki
index f93319d4..1550467d 100644
--- a/bip-0045.mediawiki
+++ b/bip-0045.mediawiki
@@ -1,11 +1,11 @@
 
-  BIP:     BIP-0045
-  Title:   Structure for Deterministic P2SH Multisignature Wallets
-  Authors: Manuel Araoz 
-           Ryan X. Charles 
-           Matias Alejo Garcia 
-  Status:  Draft
-  Type:    Standards Track
+  BIP: 45
+  Title: Structure for Deterministic P2SH Multisignature Wallets
+  Author: Manuel Araoz 
+          Ryan X. Charles 
+          Matias Alejo Garcia 
+  Status: Draft
+  Type: Standards Track
   Created: 2014-04-25
 

 
diff --git a/bip-0047.mediawiki b/bip-0047.mediawiki
index c3c50586..1a05730d 100644
--- a/bip-0047.mediawiki
+++ b/bip-0047.mediawiki
@@ -1,17 +1,14 @@
 RECENT CHANGES:
-
 * (18 Dec 2015) Update explanations to resolve FAQs
-
 * (12 Oct 2015) Revise blinding method for notification transactions
-
 * (21 Sep 2015) Correct base58check version byte
 
 
-  BIP:     47
-  Title:   Reusable Payment Codes for Hierarchical Deterministic Wallets
-  Authors: Justus Ranvier 
-  Status:  Draft
-  Type:    Informational
+  BIP: 47
+  Title: Reusable Payment Codes for Hierarchical Deterministic Wallets
+  Author: Justus Ranvier 
+  Status: Draft
+  Type: Informational
   Created: 2015-04-24
 

 
diff --git a/bip-0067.mediawiki b/bip-0067.mediawiki
index 8be5c9b2..d26df9c5 100644
--- a/bip-0067.mediawiki
+++ b/bip-0067.mediawiki
@@ -1,8 +1,9 @@
-
 
   BIP: 67
   Title: Deterministic Pay-to-script-hash multi-signature addresses through public key sorting
-  Author: Thomas Kerin, Jean-Pierre Rupp, Ruben de Vries
+  Author: Thomas Kerin 
+          Jean-Pierre Rupp 
+          Ruben de Vries 
   Status: Draft
   Type: Standards Track
   Created: 2015-02-08
diff --git a/bip-0069.mediawiki b/bip-0069.mediawiki
index e23ff042..0eca369f 100644
--- a/bip-0069.mediawiki
+++ b/bip-0069.mediawiki
@@ -1,10 +1,10 @@
 
-  BIP:     BIP: 69
-  Title:   Lexicographical Indexing of Transaction Inputs and Outputs
-  Authors: Kristov Atlas 
-  Editors: Daniel Cousens 
-  Status:  Draft
-  Type:    Informational
+  BIP: 69
+  Title: Lexicographical Indexing of Transaction Inputs and Outputs
+  Author: Kristov Atlas 
+  Editor: Daniel Cousens 
+  Status: Draft
+  Type: Informational
   Created: 2015-06-12
 

 
diff --git a/bip-0070.mediawiki b/bip-0070.mediawiki
index 36427849..e3c17cf0 100644
--- a/bip-0070.mediawiki
+++ b/bip-0070.mediawiki
@@ -1,7 +1,8 @@
 
   BIP: 70
   Title: Payment Protocol
-  Authors: Gavin Andresen , Mike Hearn 
+  Author: Gavin Andresen 
+          Mike Hearn 
   Status: Final
   Type: Standards Track
   Created: 2013-07-29
diff --git a/bip-0074.mediawiki b/bip-0074.mediawiki
index 0790b12f..a860b381 100644
--- a/bip-0074.mediawiki
+++ b/bip-0074.mediawiki
@@ -2,6 +2,9 @@
   BIP: 74
   Title: Allow zero value OP_RETURN in Payment Protocol
   Author: Toby Padilla 
+  Status: Draft
+  Type: Standards Track
+  Created: 2016-01-29
 

 
 ==Abstract==
diff --git a/bip-0080.mediawiki b/bip-0080.mediawiki
index f28bb70f..7c13a6ed 100644
--- a/bip-0080.mediawiki
+++ b/bip-0080.mediawiki
@@ -1,10 +1,10 @@
 
-  BIP:     80
-  Title:   Hierarchy for Non-Colored Voting Pool Deterministic Multisig Wallets
-  Authors: Justus Ranvier 
-           Jimmy Song 
-  Status:  Draft
-  Type:    Informational
+  BIP: 80
+  Title: Hierarchy for Non-Colored Voting Pool Deterministic Multisig Wallets
+  Author: Justus Ranvier 
+          Jimmy Song 
+  Status: Draft
+  Type: Informational
   Created: 2014-08-11
 

 
diff --git a/bip-0081.mediawiki b/bip-0081.mediawiki
index 5157c094..774166ea 100644
--- a/bip-0081.mediawiki
+++ b/bip-0081.mediawiki
@@ -1,10 +1,10 @@
 
-  BIP:     81
-  Title:   Hierarchy for Colored Voting Pool Deterministic Multisig Wallets
-  Authors: Justus Ranvier 
-           Jimmy Song 
-  Status:  Draft
-  Type:    Informational
+  BIP: 81
+  Title: Hierarchy for Colored Voting Pool Deterministic Multisig Wallets
+  Author: Justus Ranvier 
+          Jimmy Song 
+  Status: Draft
+  Type: Informational
   Created: 2014-08-11
 

 
diff --git a/bip-0083.mediawiki b/bip-0083.mediawiki
index d1da6459..f6aa8e77 100644
--- a/bip-0083.mediawiki
+++ b/bip-0083.mediawiki
@@ -1,9 +1,9 @@
 
-  BIP:     BIP-83
-  Title:   Dynamic Hierarchical Deterministic Key Trees
-  Author:  Eric Lombrozo 
-  Status:  Draft
-  Type:    Standard
+  BIP: 83
+  Title: Dynamic Hierarchical Deterministic Key Trees
+  Author: Eric Lombrozo 
+  Status: Draft
+  Type: Standards Track
   Created: 2015-11-16
 

 
diff --git a/bip-0099.mediawiki b/bip-0099.mediawiki
index b416e686..3e0a43a8 100644
--- a/bip-0099.mediawiki
+++ b/bip-0099.mediawiki
@@ -3,7 +3,7 @@
   Title: Motivation and deployment of consensus rule changes ([soft/hard]forks)
   Author: Jorge Timón 
   Status: Draft
-  Type: Informational / Process
+  Type: Informational
   Created: 2015-06-20
   Post-History: http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-June/008936.html
 

diff --git a/bip-0107.mediawiki b/bip-0107.mediawiki
index 4e96173a..86edd995 100644
--- a/bip-0107.mediawiki
+++ b/bip-0107.mediawiki
@@ -1,7 +1,7 @@
 
   BIP: 107
   Title: Dynamic limit on the block size
-  Author: Dr Washington Y. Sanchez 
+  Author: Washington Y. Sanchez 
   Status: Draft
   Type: Standards Track
   Created: 2015-09-11
diff --git a/bip-0111.mediawiki b/bip-0111.mediawiki
index d3bd630b..e0ae9e85 100644
--- a/bip-0111.mediawiki
+++ b/bip-0111.mediawiki
@@ -1,7 +1,8 @@
 
   BIP: 111
   Title: NODE_BLOOM service bit
-  Author: Matt Corallo , Peter Todd 
+  Author: Matt Corallo 
+          Peter Todd 
   Status: Draft
   Type: Standards Track
   Created: 2015-08-20
diff --git a/bip-0112.mediawiki b/bip-0112.mediawiki
index 643c6176..9c2d199a 100644
--- a/bip-0112.mediawiki
+++ b/bip-0112.mediawiki
@@ -1,9 +1,9 @@
 
   BIP: 112
   Title: CHECKSEQUENCEVERIFY
-  Authors: BtcDrak 
-           Mark Friedenbach 
-           Eric Lombrozo 
+  Author: BtcDrak 
+          Mark Friedenbach 
+          Eric Lombrozo 
   Status: Draft
   Type: Standards Track
   Created: 2015-08-10
diff --git a/bip-0113.mediawiki b/bip-0113.mediawiki
index 190fb4cc..15fa4f3f 100644
--- a/bip-0113.mediawiki
+++ b/bip-0113.mediawiki
@@ -2,7 +2,7 @@
   BIP: 113
   Title: Median time-past as endpoint for lock-time calculations
   Author: Thomas Kerin 
-          Mark Friedenbach 	
+          Mark Friedenbach 
   Status: Draft
   Type: Standards Track
   Created: 2015-08-10
diff --git a/bip-0122.mediawiki b/bip-0122.mediawiki
index 17003aa5..5386dd27 100644
--- a/bip-0122.mediawiki
+++ b/bip-0122.mediawiki
@@ -4,7 +4,7 @@
   Author: Marco Pontello 
   Status: Draft
   Type: Standards Track
-  Created: 29 August 2015
+  Created: 2015-08-29
   Post-History: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/010712.html
 

 
diff --git a/bip-0123.mediawiki b/bip-0123.mediawiki
index 348c6c06..3d40326b 100644
--- a/bip-0123.mediawiki
+++ b/bip-0123.mediawiki
@@ -2,7 +2,7 @@
   BIP: 123
   Layer: Process
   Title: BIP Classification
-  Author: Eric Lombrozo
+  Author: Eric Lombrozo 
   Status: Draft
   Type: Process
   Created: 2015-08-26
diff --git a/bip-0124.mediawiki b/bip-0124.mediawiki
index 1c98db87..2f9f4ad7 100644
--- a/bip-0124.mediawiki
+++ b/bip-0124.mediawiki
@@ -1,11 +1,11 @@
 
-  BIP:     BIP-124
-  Title:   Hierarchical Deterministic Script Templates
-  Authors: Eric Lombrozo , William Swanson
-  Status:  Draft
-  Type:    Informational
+  BIP: 124
+  Title: Hierarchical Deterministic Script Templates
+  Author: Eric Lombrozo 
+          William Swanson 
+  Status: Draft
+  Type: Informational
   Created: 2015-11-20
-
   Post-History: http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-November/011795.html
 

 
diff --git a/bip-0125.mediawiki b/bip-0125.mediawiki
index 63788e9d..7d884690 100644
--- a/bip-0125.mediawiki
+++ b/bip-0125.mediawiki
@@ -1,7 +1,8 @@
 
   BIP: 125
   Title: Opt-in Full Replace-by-Fee Signaling
-  Author: David A. Harding , Peter Todd 
+  Author: David A. Harding 
+          Peter Todd 
   Status: Draft
   Type: Standards Track
   Created: 2015-12-04
diff --git a/bip-0132.mediawiki b/bip-0132.mediawiki
index 814e20a5..90c09b1b 100644
--- a/bip-0132.mediawiki
+++ b/bip-0132.mediawiki
@@ -1,7 +1,7 @@
 
   BIP: 132
   Title: Committee-based BIP Acceptance Process
-  Author: Andy Chase
+  Author: Andy Chase 
   Status: Draft
   Type: Process
   Created: 2015-08-31
diff --git a/bip-0144.mediawiki b/bip-0144.mediawiki
index 9b2422bb..2da222cf 100644
--- a/bip-0144.mediawiki
+++ b/bip-0144.mediawiki
@@ -5,7 +5,7 @@
           Pieter Wuille 
   Status: Draft
   Type: Standards Track
-  Created: 2015-12
+  Created: 2016-01-08
 

 
 ==Abstract==

From 3cc727b99fddc8af5a64fa32edeaeb571ccb5b4b Mon Sep 17 00:00:00 2001
From: Luke Dashjr 
Date: Wed, 3 Feb 2016 19:07:55 +0000
Subject: [PATCH 196/259] BIP 67: Update email for Thomas Kerin

---
 bip-0067.mediawiki | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/bip-0067.mediawiki b/bip-0067.mediawiki
index d26df9c5..3864c63c 100644
--- a/bip-0067.mediawiki
+++ b/bip-0067.mediawiki
@@ -1,7 +1,7 @@
 
   BIP: 67
   Title: Deterministic Pay-to-script-hash multi-signature addresses through public key sorting
-  Author: Thomas Kerin 
+  Author: Thomas Kerin 
           Jean-Pierre Rupp 
           Ruben de Vries 
   Status: Draft

From 37ef0f9f79295ae8f1cb1a5c7950e59c1302fef9 Mon Sep 17 00:00:00 2001
From: Luke Dashjr 
Date: Wed, 3 Feb 2016 19:20:12 +0000
Subject: [PATCH 197/259] bip-biprevised: Avoid "consensus" outside of
 "consensus rules", and move formal definition thereof to the only location it
 matters (Process BIPs becoming Active)

---
 bip-biprevised.mediawiki | 15 ++++++---------
 1 file changed, 6 insertions(+), 9 deletions(-)

diff --git a/bip-biprevised.mediawiki b/bip-biprevised.mediawiki
index 4e30f242..a7de3a1e 100644
--- a/bip-biprevised.mediawiki
+++ b/bip-biprevised.mediawiki
@@ -31,15 +31,15 @@ An Accepted BIP may progress to Final only when specific criteria reflecting rea
 
 When a Final BIP is no longer relevant, its status may be changed to Replaced or Obsolete (which is equivalent to Replaced). This change must also be objectively verifiable and/or discussed.
 
-A process BIP may change status from Draft to Active when it achieves consensus on the mailing list.
+A process BIP may change status from Draft to Active when it achieves rough consensus on the mailing list. Such a proposal is said to have rough consensus if it has been open to discussion on the development mailing list for at least one month, and no person maintains any unaddressed substantiated objections to it. Addressed or obstructive objections may be ignored/overruled by general agreement that they have been sufficiently addressed, but clear reasoning must be given in such circumstances.
 
 ====Progression to Final status====
 
 See [[bip-0123.mediawiki|BIP 123]] for definitions of the various BIP layers. Activation of this BIP implies activation of BIP 123.
 
-A soft-fork BIP strictly requires a clear miner majority expressed by blockchain voting (eg, using BIP 9), as well as not meeting the inverse criteria for a hard-fork BIP (that is, economic consensus may reject a soft-fork BIP despite miner adoption). Because of the possibility of changes to miner dynamics, especially in light of delegated voting (mining pools), it is highly recommended that a supermajority vote around 95% be required by the BIP itself, unless rationale is given for a lower threshold.
+A soft-fork BIP strictly requires a clear miner majority expressed by blockchain voting (eg, using BIP 9), as well as not meeting the inverse criteria for a hard-fork BIP (that is, economic agreement to block the soft-fork with a hard-fork, may be cause to reject that soft-fork BIP despite miner adoption). Because of the possibility of changes to miner dynamics, especially in light of delegated voting (mining pools), it is highly recommended that a supermajority vote around 95% be required by the BIP itself, unless rationale is given for a lower threshold.
 
-A hard-fork BIP requires consensus from the entire Bitcoin economy, particularly including those selling desirable goods and services in exchange for bitcoin payments, as well as Bitcoin holders who wish to spend or would spend their bitcoins (including selling for other currencies) differently in the event of such a hard-fork. Consensus must be expressed by de facto usage of the hard-fork in practice (ie, not merely expressing public support, although that is a good step to establish pre-Final status consensus to adopt a BIP). This consensus cannot be reached merely by a super-majority, except by literally forcing the minority to accept the hard-fork (whether this is viable or not is outside the scope of this document).
+A hard-fork BIP requires adoption from the entire Bitcoin economy, particularly including those selling desirable goods and services in exchange for bitcoin payments, as well as Bitcoin holders who wish to spend or would spend their bitcoins (including selling for other currencies) differently in the event of such a hard-fork. Adoption must be expressed by de facto usage of the hard-fork in practice (ie, not merely expressing public support, although that is a good step to establish agreement before adoption of the BIP). This economic adoption cannot be established merely by a super-majority, except by literally forcing the minority to accept the hard-fork (whether this is viable or not is outside the scope of this document).
 
 Peer services BIPs should be observed to be adopted by at least 1% of public listening nodes for one month.
 
@@ -49,10 +49,6 @@ Software authors are encouraged to publish summaries of what BIPs their software
 
 These criteria are considered objective ways to observe the de facto adoption of the BIP, and are not to be used as reasons to oppose or reject a BIP. Should a BIP become actually and unambiguously adopted despite not meeting the criteria outlined here, it should still be updated to Final status.
 
-====Formally defining consensus====
-
-A proposal is said to have achieved consensus if it has been open to discussion in applicable forums for communication for at least one month, and has not maintained any substantiated objection by any person. Should objections to be made on a strictly obstructive basis, those obstructing may be ignored/overruled by agreement that they are merely being obstructive from all other persons involved in the discussion. Objections are assumed to be either substantiated or obstructive, and when giving a determination of an objection being obstructive, clear reasoning must be offered.
-
 ===Rationale===
 
 How is the entire Bitcoin economy defined by people selling goods/services and holders?
@@ -70,9 +66,9 @@ But they're doing something important and have invested a lot in Bitcoin! Should
 
 * This BIP does not aim to address what "should" be the basis of decisions. Such a statement, no matter how perfect in its justification, would be futile without some way to enforce it. The BIP process does not aim to be a kind of "governance" of Bitcoin, merely to provide a collaborative repository for proposing and providing information on standards. It can only hope to achieve accuracy in regard to the "Status" field by striving to reflect the reality of *how things actually are*, rather than *how they should be*.
 
-Why can the economic consensus veto a soft-fork?
+How can economic agreement veto a soft-fork?
 
-* The group of miners is determined by the consensus rules for the dynamic-membership multi-party signature (for Bitcoin, the proof-of-work algorithm), which can be modified with a hard-fork. Thus, if the same conditions required to modify this group are met in opposition to a soft-fork, the miner majority supporting the soft-fork is effectively void because the economic consensus can decide to replace them with another group of would-be miners who do not support the soft-fork.
+* The group of miners is determined by the consensus rules for the dynamic-membership multi-party signature (for Bitcoin, the proof-of-work algorithm), which can be modified with a hard-fork. Thus, if the same conditions required to modify this group are met in opposition to a soft-fork, the miner majority supporting the soft-fork is effectively void because the economy can decide to replace them with another group of would-be miners who do not support the soft-fork.
 
 What is the ideal percentage of listening nodes needed to adopt peer services proposals?
 
@@ -158,3 +154,4 @@ Why are there software licenses included?
 
 * [[bip-0001.mediawiki|BIP 1: BIP Purpose and Guidelines]]
 * [[bip-0123.mediawiki|BIP 123: BIP Classification]]
+* [https://tools.ietf.org/html/rfc7282 RBF 7282: On Consensus and Humming in the IETF]

From 3f859450dd209796bf50bf344cb8bf0a212c5417 Mon Sep 17 00:00:00 2001
From: Luke Dashjr 
Date: Wed, 3 Feb 2016 21:09:08 +0000
Subject: [PATCH 198/259] BIP 80/81: Update email for Justus Ranvier

BIP 47/69 are fine as-is
---
 bip-0080.mediawiki | 2 +-
 bip-0081.mediawiki | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/bip-0080.mediawiki b/bip-0080.mediawiki
index 7c13a6ed..13d8597d 100644
--- a/bip-0080.mediawiki
+++ b/bip-0080.mediawiki
@@ -1,7 +1,7 @@
 
   BIP: 80
   Title: Hierarchy for Non-Colored Voting Pool Deterministic Multisig Wallets
-  Author: Justus Ranvier 
+  Author: Justus Ranvier 
           Jimmy Song 
   Status: Draft
   Type: Informational
diff --git a/bip-0081.mediawiki b/bip-0081.mediawiki
index 774166ea..b3060751 100644
--- a/bip-0081.mediawiki
+++ b/bip-0081.mediawiki
@@ -1,7 +1,7 @@
 
   BIP: 81
   Title: Hierarchy for Colored Voting Pool Deterministic Multisig Wallets
-  Author: Justus Ranvier 
+  Author: Justus Ranvier 
           Jimmy Song 
   Status: Draft
   Type: Informational

From 04fce4aa75f6c69b57850070c2e837cd7671f233 Mon Sep 17 00:00:00 2001
From: Luke Dashjr 
Date: Thu, 4 Feb 2016 04:10:30 +0000
Subject: [PATCH 199/259] bip-biprevised: Clarify soft-fork blocking by ec.
 consensus

---
 bip-biprevised.mediawiki | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/bip-biprevised.mediawiki b/bip-biprevised.mediawiki
index a7de3a1e..b496149a 100644
--- a/bip-biprevised.mediawiki
+++ b/bip-biprevised.mediawiki
@@ -37,7 +37,7 @@ A process BIP may change status from Draft to Active when it achieves rough cons
 
 See [[bip-0123.mediawiki|BIP 123]] for definitions of the various BIP layers. Activation of this BIP implies activation of BIP 123.
 
-A soft-fork BIP strictly requires a clear miner majority expressed by blockchain voting (eg, using BIP 9), as well as not meeting the inverse criteria for a hard-fork BIP (that is, economic agreement to block the soft-fork with a hard-fork, may be cause to reject that soft-fork BIP despite miner adoption). Because of the possibility of changes to miner dynamics, especially in light of delegated voting (mining pools), it is highly recommended that a supermajority vote around 95% be required by the BIP itself, unless rationale is given for a lower threshold.
+A soft-fork BIP strictly requires a clear miner majority expressed by blockchain voting (eg, using BIP 9). In addition, if the economy seems willing to make a "no confidence" hard-fork (such as a change in proof-of-work algorithm), the soft-fork does not become Final for as long as such a hard-fork has potentially-majority support, or at most three months. Soft-fork BIPs may also set additional requirements for their adoption. Because of the possibility of changes to miner dynamics, especially in light of delegated voting (mining pools), it is highly recommended that a supermajority vote around 95% be required by the BIP itself, unless rationale is given for a lower threshold.
 
 A hard-fork BIP requires adoption from the entire Bitcoin economy, particularly including those selling desirable goods and services in exchange for bitcoin payments, as well as Bitcoin holders who wish to spend or would spend their bitcoins (including selling for other currencies) differently in the event of such a hard-fork. Adoption must be expressed by de facto usage of the hard-fork in practice (ie, not merely expressing public support, although that is a good step to establish agreement before adoption of the BIP). This economic adoption cannot be established merely by a super-majority, except by literally forcing the minority to accept the hard-fork (whether this is viable or not is outside the scope of this document).
 
@@ -70,6 +70,10 @@ How can economic agreement veto a soft-fork?
 
 * The group of miners is determined by the consensus rules for the dynamic-membership multi-party signature (for Bitcoin, the proof-of-work algorithm), which can be modified with a hard-fork. Thus, if the same conditions required to modify this group are met in opposition to a soft-fork, the miner majority supporting the soft-fork is effectively void because the economy can decide to replace them with another group of would-be miners who do not support the soft-fork.
 
+What happens if the economy decides to hard-fork away from a controversial soft-fork, more than three months later?
+
+* The controversial soft-fork, in this circumstance, changes from Final to Replaced status to reflect the nature of the hard-fork replacing the previous (final) soft-fork.
+
 What is the ideal percentage of listening nodes needed to adopt peer services proposals?
 
 * This is unknown, and set rather arbitrarily at this time. For a random selection of peers to have at least one other peer implementing the extension, 13% or more would be necessary, but nodes could continue to scan the network for such peers with perhaps some reasonable success. Furthermore, service bits exist to help identification upfront.

From a2e87c208f45072f266f9d5788664209aaeccfcc Mon Sep 17 00:00:00 2001
From: Luke Dashjr 
Date: Thu, 4 Feb 2016 04:12:03 +0000
Subject: [PATCH 200/259] Assign BIP 2: BIP Status and Comments

---
 README.mediawiki                               | 6 ++++++
 bip-biprevised.mediawiki => bip-0002.mediawiki | 5 +++--
 2 files changed, 9 insertions(+), 2 deletions(-)
 rename bip-biprevised.mediawiki => bip-0002.mediawiki (99%)

diff --git a/README.mediawiki b/README.mediawiki
index eda7fbfd..389d21e5 100644
--- a/README.mediawiki
+++ b/README.mediawiki
@@ -19,6 +19,12 @@ Those proposing changes should consider that ultimately consent may rest with th
 | Process
 | Active
 |-
+| [[bip-0002.mediawiki|2]]
+| BIP Status and Comments
+| Luke Dashjr
+| Process
+| Draft
+|-
 | [[bip-0009.mediawiki|9]]
 | Version bits with timeout and delay
 | Pieter Wuille, Peter Todd, Greg Maxwell, Rusty Russell
diff --git a/bip-biprevised.mediawiki b/bip-0002.mediawiki
similarity index 99%
rename from bip-biprevised.mediawiki
rename to bip-0002.mediawiki
index b496149a..ee3ae3a0 100644
--- a/bip-biprevised.mediawiki
+++ b/bip-0002.mediawiki
@@ -1,9 +1,10 @@
 
-  BIP: x
+  BIP: 2
   Title: BIP Status and Comments
+  Author: Luke Dashjr 
   Status: Draft
   Type: Process
-  Created: 2016-02-01
+  Created: 2016-02-03
 

 
 ==Abstract==

From 2d909ad98a999a77bfcf8393a60166f1eabd22a4 Mon Sep 17 00:00:00 2001
From: Johnson Lau 
Date: Fri, 5 Feb 2016 02:13:31 +0800
Subject: [PATCH 201/259] BIP34 correction

---
 bip-0034.mediawiki | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/bip-0034.mediawiki b/bip-0034.mediawiki
index 245985c7..3c0e770f 100644
--- a/bip-0034.mediawiki
+++ b/bip-0034.mediawiki
@@ -19,7 +19,7 @@ Bitcoin blocks and transactions are versioned binary structures. Both currently
 ==Specification==
 
 # Treat transactions with a version greater than 1 as non-standard (official Satoshi client will not mine or relay them).
-# Add height as the first item in the coinbase transaction's scriptSig, and increase block version to 2. The format of the height is "serialized CScript" -- first byte is number of bytes in the number (will be 0x03 on main net for the next 300 or so years), following bytes are little-endian representation of the number.  Height is the height of the mined block in the block chain, where the genesis block is height zero (0).
+# Add height as the first item in the coinbase transaction's scriptSig, and increase block version to 2. The format of the height is "serialized CScript" -- first byte is number of bytes in the number (will be 0x03 on main net for the next 150 or so years with 223-1 blocks), following bytes are little-endian representation of the number (including a sign bit).  Height is the height of the mined block in the block chain, where the genesis block is height zero (0).
 # 75% rule: If 750 of the last 1,000 blocks are version 2 or greater, reject invalid version 2 blocks. (testnet3: 51 of last 100)
 # 95% rule ("Point of no return"): If 950 of the last 1,000 blocks are version 2 or greater, reject all version 1 blocks. (testnet3: 75 of last 100)
 

From 4a515ee2dc5917066a8b126187cd733f4d252a82 Mon Sep 17 00:00:00 2001
From: BtcDrak 
Date: Thu, 4 Feb 2016 20:38:33 +0000
Subject: [PATCH 202/259] Minor update of implementation for BIP68

This patch syncronised latest implementation
Adds comments, adds assert()
---
 bip-0068.mediawiki | 25 +++++++++++++++----------
 1 file changed, 15 insertions(+), 10 deletions(-)

diff --git a/bip-0068.mediawiki b/bip-0068.mediawiki
index e93d7488..3183cff6 100644
--- a/bip-0068.mediawiki
+++ b/bip-0068.mediawiki
@@ -89,10 +89,10 @@ static const uint32_t SEQUENCE_LOCKTIME_MASK = 0x0000ffff;
 static const int SEQUENCE_LOCKTIME_GRANULARITY = 9;
     
 /**
- * Calculates the block height and time which the transaction must be later than
- * in order to be considered final in the context of BIP 68.  It also removes
- * from the vector of input heights any entries which did not correspond to sequence
- * locked inputs as they do not affect the calculation.
+ * Calculates the block height and previous block's median time past at
+ * which the transaction will be considered final in the context of BIP 68.
+ * Also removes from the vector of input heights any entries which did not
+ * correspond to sequence locked inputs as they do not affect the calculation.
  */
 static std::pair CalculateSequenceLocks(const CTransaction &tx, int flags, std::vector* prevHeights, const CBlockIndex& block)
 {
@@ -134,6 +134,14 @@ static std::pair CalculateSequenceLocks(const CTransaction &tx, in
 
         if (txin.nSequence & CTxIn::SEQUENCE_LOCKTIME_TYPE_FLAG) {
             int64_t nCoinTime = block.GetAncestor(std::max(nCoinHeight-1, 0))->GetMedianTimePast();
+            // NOTE: Subtract 1 to maintain nLockTime semantics
+            // BIP 68 relative lock times have the semantics of calculating
+            // the first block or time at which the transaction would be
+            // valid. When calculating the effective block time or height
+            // for the entire transaction, we switch to using the
+            // semantics of nLockTime which is the last invalid block
+            // time or height.  Thus we subtract 1 from the calculated
+            // time or height.
 
             // Time-based relative lock-times are measured from the
             // smallest allowed timestamp of the block containing the
@@ -141,10 +149,6 @@ static std::pair CalculateSequenceLocks(const CTransaction &tx, in
             // block prior.
             nMinTime = std::max(nMinTime, nCoinTime + (int64_t)((txin.nSequence & CTxIn::SEQUENCE_LOCKTIME_MASK) << CTxIn::SEQUENCE_LOCKTIME_GRANULARITY) - 1);
         } else {
-            // We subtract 1 from relative lock-times because a lock-
-            // time of 0 has the semantics of "same block," so a lock-
-            // time of 1 should mean "next block," but nLockTime has
-            // the semantics of "last invalid block height."
             nMinHeight = std::max(nMinHeight, nCoinHeight + (int)(txin.nSequence & CTxIn::SEQUENCE_LOCKTIME_MASK) - 1);
         }
     }
@@ -154,7 +158,8 @@ static std::pair CalculateSequenceLocks(const CTransaction &tx, in
 
 static bool EvaluateSequenceLocks(const CBlockIndex& block, std::pair lockPair)
 {
-    int64_t nBlockTime = block.pprev ? block.pprev->GetMedianTimePast() : 0;
+    assert(block.pprev);
+    int64_t nBlockTime = block.pprev->GetMedianTimePast();
     if (lockPair.first >= block.nHeight || lockPair.second >= nBlockTime)
         return false;
 
@@ -189,7 +194,7 @@ bool CheckSequenceLocks(const CTransaction &tx, int flags)
         const CTxIn& txin = tx.vin[txinIndex];
         CCoins coins;
         if (!viewMemPool.GetCoins(txin.prevout.hash, coins)) {
-            return  error("%s: Missing input", __func__);
+            return error("%s: Missing input", __func__);
         }
         if (coins.nHeight == MEMPOOL_HEIGHT) {
             // Assume all mempool transaction confirm in the next block

From d21c27b96efc0072d4884fb321b3b171c340c4ac Mon Sep 17 00:00:00 2001
From: Luke Dashjr 
Date: Fri, 5 Feb 2016 00:04:55 +0000
Subject: [PATCH 203/259] bip-0002: Clarify that BIP comments are intended for
 final reviews, not suggestions to drafts

---
 bip-0002.mediawiki | 7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/bip-0002.mediawiki b/bip-0002.mediawiki
index bf0a768f..6690bc28 100644
--- a/bip-0002.mediawiki
+++ b/bip-0002.mediawiki
@@ -92,7 +92,12 @@ What if a BIP is proposed that only makes sense for a single specific project?
 
 ===Specification===
 
-Each BIP should, in its preamble, link to a Bitcoin Wiki page with a summary tone of the comments on that page. Reviewers of the BIP who consider themselves qualified, should post their own comments on this wiki page in [https://www.mediawiki.org/wiki/Help:Talk_pages#Editing_conventions_on_talk_pages standard "Talk page" format]. If a BIP is not yet completed, reviewers should plan to review the new version and remove or revise their comments as applicable, updating the timestamp in the review. Reviews made prior to the complete version may be removed if they are no longer applicable and have not been updated in a timely manner (eg, within one month).
+Each BIP should, in its preamble, link to a Bitcoin Wiki page with a summary tone of the comments on that page.
+Reviewers of the BIP who consider themselves qualified, should post their own comments on this wiki page in [https://www.mediawiki.org/wiki/Help:Talk_pages#Editing_conventions_on_talk_pages standard "Talk page" format].
+The comments page should generally only be used to post final comments for a completed BIP.
+If a BIP is not yet completed, reviewers should instead post on the applicable development mailing list thread to allow the BIP author(s) to address any concerns or problems pointed out by the review.
+
+Some BIPs receive exposure outside the development community prior to completion, and other BIPs might not be completed at all. To avoid a situation where critical BIP reviews may go unnoticed during this period, reviewers may, at their option, still cross-post their review on the comments page, provided they plan to review any new versions and remove or revise their comments as applicable. Such revisions should be made by editing the previous review and updating the timestamp. Reviews made prior to the complete version may be removed if they are no longer applicable and have not been updated in a timely manner (eg, within one month).
 
 Pages must be named after the full BIP number (eg, "BIP 0001") and placed in the "BIP Comments" namespace. For example, the link for BIP 1 will be https://en.bitcoin.it/wiki/BIP_Comments:BIP_0001 .
 

From 8c50a8012ea4fcabf35f06683d7859c0bcef8e6c Mon Sep 17 00:00:00 2001
From: Luke Dashjr 
Date: Fri, 5 Feb 2016 00:18:02 +0000
Subject: [PATCH 204/259] bip-0002: Rewrite Abstract, and move rationale
 previously included in it to the applicable Rationale sections

---
 bip-0002.mediawiki | 21 ++++++++++++++++-----
 1 file changed, 16 insertions(+), 5 deletions(-)

diff --git a/bip-0002.mediawiki b/bip-0002.mediawiki
index 6690bc28..4d3bab0b 100644
--- a/bip-0002.mediawiki
+++ b/bip-0002.mediawiki
@@ -9,10 +9,7 @@
 
 ==Abstract==
 
-BIP 1 defines an ambiguous criteria for the Status field of BIPs, which is often a source of confusion.
-Additionally, some BIPs have been adopted which are deemed unadvisable or unsafe by experts in the field, and there is no indication of this at present.
-Finally, BIP 1 only allows a single copyright license generally considered deprecated, or publication under the public domain (which is not legally recognised in all jurisdictions).
-This BIP intends to address these problems by more specifically defining the Status field, recommending a forum for people to comment on BIPs, and expanding the list of allowable BIP licenses.
+This BIP describes objective criteria that can be used to determine when a BIP Status should be changed, to ensure it is a reliable metric documenting actual usage of the proposal. It also adds a way for final comment on completed BIPs, by adding to them a reference to a wiki page and summary of the tone thereof. Finally, it extends the list of allowable BIP licenses to include many more popular options.
 
 ==Copyright==
 
@@ -52,6 +49,10 @@ These criteria are considered objective ways to observe the de facto adoption of
 
 ===Rationale===
 
+Why is this necessary at all?
+
+* BIP 1 defines an ambiguous criteria for the Status field of BIPs, which is often a source of confusion. As a result, many BIPs with significant real-world use have been left as Draft or Accepted status longer than appropriate. By giving objective criteria to judge the progression of BIPs, this proposal aims to help keep the Status accurate and up-to-date.
+
 How is the entire Bitcoin economy defined by people selling goods/services and holders?
 
 * For Bitcoin to function as a currency, it must be accepted as payment. Bitcoins have no value if you cannot acquire anything in exchange for them. If everyone accepting such payments requires a particular set of consensus rules, "bitcoins" are de facto defined by that set of rules - this is already the case today. If those consensus rules are expected to broaden (as with a hard-fork), those merchants need to accept payments made under the new set of rules, or they will reject "bitcoins" as invalid. Holders are relevant to the degree in that they choose the merchants they wish to spend their bitcoins with, and could also as a whole decide to sell under one set of consensus rules or the other, thus flooding the market with bitcoins and crashing the price.
@@ -65,7 +66,7 @@ Why aren't  included in the economy?
 
 But they're doing something important and have invested a lot in Bitcoin! Shouldn't they be included in such an important decision?
 
-* This BIP does not aim to address what "should" be the basis of decisions. Such a statement, no matter how perfect in its justification, would be futile without some way to enforce it. The BIP process does not aim to be a kind of "governance" of Bitcoin, merely to provide a collaborative repository for proposing and providing information on standards. It can only hope to achieve accuracy in regard to the "Status" field by striving to reflect the reality of *how things actually are*, rather than *how they should be*.
+* This BIP does not aim to address what "should" be the basis of decisions. Such a statement, no matter how perfect in its justification, would be futile without some way to force others to use it. The BIP process does not aim to be a kind of forceful "governance" of Bitcoin, merely to provide a collaborative repository for proposing and providing information on standards, which people may voluntarily adopt or not. It can only hope to achieve accuracy in regard to the "Status" field by striving to reflect the reality of *how things actually are*, rather than *how they should be*.
 
 How can economic agreement veto a soft-fork?
 
@@ -120,6 +121,10 @@ To avoid doubt: comments and status are unrelated metrics to judge a BIP, and ne
 
 ===Rationale===
 
+What is the purpose of BIP comments?
+
+* Various BIPs have been adopted (the criteria required for "Final" Status) despite being considered generally inadvisable. Some presently regard BIPs as a "good idea" simply by virtue of them being assigned a BIP number. Due to the low barrier of entry for submission of new BIPs, it seems advisable for a way for reviewers to express their opinions on them in a way that is consumable to the public without needing to review the entire development discussion.
+
 Will BIP comments be censored or limited to particular participants/"experts"?
 
 * The Bitcoin Wiki moderators have control over that venue and may make reasonable moderation attempts. Admitted non-experts should refrain from commenting outside of their area of knowledge. However, comments should not be censored, and participation should be open to the public.
@@ -155,6 +160,12 @@ In addition, it is recommended that literal code included in the BIP be dual-lic
 
 ===Rationale===
 
+BIP 1 allowed the Open Publication License or releasing into the public domain; was this insufficient?
+
+* The OPL is generally regarded as obsolete, and not a license suitable for new publications.
+* Many are unfamiliar with the OPL terms, and may just prefer to use the public domain rather than license under uncertain terms.
+* Public domain is not universally recognised as a legitimate action, thus it is inadvisable.
+
 Why are there software licenses included?
 
 * Some BIPs, especially consensus layer, may include literal code in the BIP itself which may not be available under the exact license terms of the BIP.

From 438bb6bbab2822b1a093957b006f9f109b8a13e0 Mon Sep 17 00:00:00 2001
From: Luke Dashjr 
Date: Fri, 5 Feb 2016 00:22:05 +0000
Subject: [PATCH 205/259] bip-0002: Be more specific on how additional comments
 forums can be specified

---
 bip-0002.mediawiki | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/bip-0002.mediawiki b/bip-0002.mediawiki
index 4d3bab0b..2558f205 100644
--- a/bip-0002.mediawiki
+++ b/bip-0002.mediawiki
@@ -102,7 +102,7 @@ Some BIPs receive exposure outside the development community prior to completion
 
 Pages must be named after the full BIP number (eg, "BIP 0001") and placed in the "BIP Comments" namespace. For example, the link for BIP 1 will be https://en.bitcoin.it/wiki/BIP_Comments:BIP_0001 .
 
-In order to avoid possible abuse of Bitcoin Wiki moderation, BIPs may also choose to list a second forum for BIP comments.
+In order to avoid possible abuse of Bitcoin Wiki moderation, BIPs may choose to list a second forum for BIP comments, in addition to the Bitcoin Wiki. In this case, the second forum's URI should be listed below the Bitcoin Wiki's URI.
 
 Summary tones may be chosen from the following, but this BIP does not intend to cover all possible nuances:
 
@@ -112,10 +112,11 @@ Summary tones may be chosen from the following, but this BIP does not intend to
 * Mostly Recommended for implementation, with some Discouragement
 * Mostly Discouraged for implementation, with some Recommendation
 
-For example, the preamble to BIP 1 would be updated to include the (markup) line:
+For example, the preamble to BIP 1 might be updated to include the line:
 
     Comments-Summary: No comments yet.
     Comments-URI: https://en.bitcoin.it/wiki/BIP_Comments:BIP_0001
+                  https://some-other-wiki.org/BIP_1_Comments
 
 To avoid doubt: comments and status are unrelated metrics to judge a BIP, and neither should be directly influencing the other.
 

From fc352d54e825c04527d5573bed90fb8a3463fe2f Mon Sep 17 00:00:00 2001
From: Luke Dashjr 
Date: Fri, 5 Feb 2016 01:06:08 +0000
Subject: [PATCH 206/259] bip-0002: Be more explicit on the need for review to
 primarily occur on the ML during drafting

---
 bip-0002.mediawiki | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/bip-0002.mediawiki b/bip-0002.mediawiki
index 2558f205..571361c1 100644
--- a/bip-0002.mediawiki
+++ b/bip-0002.mediawiki
@@ -98,7 +98,7 @@ Reviewers of the BIP who consider themselves qualified, should post their own co
 The comments page should generally only be used to post final comments for a completed BIP.
 If a BIP is not yet completed, reviewers should instead post on the applicable development mailing list thread to allow the BIP author(s) to address any concerns or problems pointed out by the review.
 
-Some BIPs receive exposure outside the development community prior to completion, and other BIPs might not be completed at all. To avoid a situation where critical BIP reviews may go unnoticed during this period, reviewers may, at their option, still cross-post their review on the comments page, provided they plan to review any new versions and remove or revise their comments as applicable. Such revisions should be made by editing the previous review and updating the timestamp. Reviews made prior to the complete version may be removed if they are no longer applicable and have not been updated in a timely manner (eg, within one month).
+Some BIPs receive exposure outside the development community prior to completion, and other BIPs might not be completed at all. To avoid a situation where critical BIP reviews may go unnoticed during this period, reviewers may, at their option, still post their review on the comments page, provided they first post it to the mailing list and plan to later remove or revise it as applicable based on the completed version. Such revisions should be made by editing the previous review and updating the timestamp. Reviews made prior to the complete version may be removed if they are no longer applicable and have not been updated in a timely manner (eg, within one month).
 
 Pages must be named after the full BIP number (eg, "BIP 0001") and placed in the "BIP Comments" namespace. For example, the link for BIP 1 will be https://en.bitcoin.it/wiki/BIP_Comments:BIP_0001 .
 

From 54a753d6c913077acd5621989fa51c04b88ea4ad Mon Sep 17 00:00:00 2001
From: Luke Dashjr 
Date: Fri, 5 Feb 2016 01:08:39 +0000
Subject: [PATCH 207/259] bip-0002: Note that the comments must address the
 proposal itself

---
 bip-0002.mediawiki | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/bip-0002.mediawiki b/bip-0002.mediawiki
index 571361c1..e5e50ba0 100644
--- a/bip-0002.mediawiki
+++ b/bip-0002.mediawiki
@@ -95,7 +95,7 @@ What if a BIP is proposed that only makes sense for a single specific project?
 
 Each BIP should, in its preamble, link to a Bitcoin Wiki page with a summary tone of the comments on that page.
 Reviewers of the BIP who consider themselves qualified, should post their own comments on this wiki page in [https://www.mediawiki.org/wiki/Help:Talk_pages#Editing_conventions_on_talk_pages standard "Talk page" format].
-The comments page should generally only be used to post final comments for a completed BIP.
+The comments page should generally only be used to post final comments for a completed BIP, and must address the proposal itself (explicitly *not* including the merits of the author(s) nor discussions/processes involved in the drafting of it).
 If a BIP is not yet completed, reviewers should instead post on the applicable development mailing list thread to allow the BIP author(s) to address any concerns or problems pointed out by the review.
 
 Some BIPs receive exposure outside the development community prior to completion, and other BIPs might not be completed at all. To avoid a situation where critical BIP reviews may go unnoticed during this period, reviewers may, at their option, still post their review on the comments page, provided they first post it to the mailing list and plan to later remove or revise it as applicable based on the completed version. Such revisions should be made by editing the previous review and updating the timestamp. Reviews made prior to the complete version may be removed if they are no longer applicable and have not been updated in a timely manner (eg, within one month).

From 32231cddc6db33f2557a0bd0e6a143b90c99203f Mon Sep 17 00:00:00 2001
From: Luke Dashjr 
Date: Fri, 5 Feb 2016 01:32:59 +0000
Subject: [PATCH 208/259] Revert "bip-0002: Note that the comments must address
 the proposal itself"

This reverts commit 54a753d6c913077acd5621989fa51c04b88ea4ad.
---
 bip-0002.mediawiki | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/bip-0002.mediawiki b/bip-0002.mediawiki
index e5e50ba0..571361c1 100644
--- a/bip-0002.mediawiki
+++ b/bip-0002.mediawiki
@@ -95,7 +95,7 @@ What if a BIP is proposed that only makes sense for a single specific project?
 
 Each BIP should, in its preamble, link to a Bitcoin Wiki page with a summary tone of the comments on that page.
 Reviewers of the BIP who consider themselves qualified, should post their own comments on this wiki page in [https://www.mediawiki.org/wiki/Help:Talk_pages#Editing_conventions_on_talk_pages standard "Talk page" format].
-The comments page should generally only be used to post final comments for a completed BIP, and must address the proposal itself (explicitly *not* including the merits of the author(s) nor discussions/processes involved in the drafting of it).
+The comments page should generally only be used to post final comments for a completed BIP.
 If a BIP is not yet completed, reviewers should instead post on the applicable development mailing list thread to allow the BIP author(s) to address any concerns or problems pointed out by the review.
 
 Some BIPs receive exposure outside the development community prior to completion, and other BIPs might not be completed at all. To avoid a situation where critical BIP reviews may go unnoticed during this period, reviewers may, at their option, still post their review on the comments page, provided they first post it to the mailing list and plan to later remove or revise it as applicable based on the completed version. Such revisions should be made by editing the previous review and updating the timestamp. Reviews made prior to the complete version may be removed if they are no longer applicable and have not been updated in a timely manner (eg, within one month).

From 04bc8408cf146995470efbe03863316da53477c8 Mon Sep 17 00:00:00 2001
From: Olaoluwa Osuntokun 
Date: Fri, 5 Feb 2016 20:30:12 -0800
Subject: [PATCH 209/259] BIP 68 Nit: fix spelling Contrats -> Contracts

---
 bip-0068.mediawiki | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/bip-0068.mediawiki b/bip-0068.mediawiki
index 3183cff6..b7bb0db1 100644
--- a/bip-0068.mediawiki
+++ b/bip-0068.mediawiki
@@ -249,5 +249,5 @@ BIP112: https://github.com/bitcoin/bips/blob/master/bip-0112.mediawiki
 
 BIP113: https://github.com/bitcoin/bips/blob/master/bip-0113.mediawiki
 
-Hashed Timelock Contrats (HTLCs): https://github.com/ElementsProject/lightning/raw/master/doc/deployable-lightning.pdf
+Hashed Timelock Contracts (HTLCs): https://github.com/ElementsProject/lightning/raw/master/doc/deployable-lightning.pdf
 

From 072173f3c5290a355e5696b669c3703fcdd47ae3 Mon Sep 17 00:00:00 2001
From: Luke Dashjr 
Date: Tue, 9 Feb 2016 04:56:36 +0000
Subject: [PATCH 210/259] bip-0050: Final update to what actually occurred

---
 bip-0050.mediawiki | 26 ++++++++++++++++----------
 1 file changed, 16 insertions(+), 10 deletions(-)

diff --git a/bip-0050.mediawiki b/bip-0050.mediawiki
index 9ff29d6f..31070700 100644
--- a/bip-0050.mediawiki
+++ b/bip-0050.mediawiki
@@ -8,27 +8,29 @@
 

 
 ==What went wrong==
-A block that had a larger number of total transaction inputs than previously seen was mined and broadcasted. Bitcoin 0.8 nodes were able to handle this, but some pre-0.8 Bitcoin nodes rejected it, causing an unexpected hard fork of the chain. The pre-0.8 incompatible chain at that point had around 60% of the hash power ensuring the split did not automatically resolve.
+A block that had a larger number of total transaction inputs than previously seen was mined and broadcasted. Bitcoin 0.8 nodes were able to handle this, but some pre-0.8 Bitcoin nodes rejected it, causing an unexpected fork of the blockchain. The pre-0.8-incompatible chain (from here on, the 0.8 chain) at that point had around 60% of the mining hash power ensuring the split did not automatically resolve (as would have occurred if the pre-0.8 chain outpaced the 0.8 chain in total work, forcing 0.8 nodes to reorganise to the pre-0.8 chain).
 
-In order to restore a canonical chain as soon as possible, BTCGuild and Slush downgraded their Bitcoin 0.8 nodes to 0.7 so their pools would also reject the larger block. This placed majority hashpower on the chain without the larger block.
+In order to restore a canonical chain as soon as possible, BTCGuild and Slush downgraded their Bitcoin 0.8 nodes to 0.7 so their pools would also reject the larger block. This placed majority hashpower on the chain without the larger block, thus eventually causing the 0.8 nodes to reorganise to the pre-0.8 chain.
 
 During this time there was at least [https://bitcointalk.org/index.php?topic=152348.0 one large double spend].  However, it was done by someone experimenting to see if it was possible and was not intended to be malicious.
 
 ==What went right==
 * The split was detected very quickly.
-* The right people were online and available in IRC or could be raised via Skype.
-* Marek Palatinus and Michael Marsee quickly downgraded their nodes to restore a pre-0.8 chain as canonical, despite the fact that this caused them to sacrifice significant amounts of money and they were the ones running the bug-free version.
+* The right people were online and available in IRC or could be contacted directly.
+* Marek Palatinus (Slush) and Michael Marsee (Eleuthria of BTCGuild) quickly downgraded their nodes to restore a pre-0.8 chain as canonical, despite the fact that this caused them to sacrifice significant amounts of money.
 * Deposits to the major exchanges and payments via BitPay were also suspended (and then un-suspended) very quickly.
-* Fortunately, the only attack on a merchant was done by someone who was not intending to actually steal money
+* Fortunately, the only attack on a merchant was done by someone who was not intending to actually steal money.
 
 ==Root cause==
-Bitcoin versions prior to 0.8 configure an insufficient number of Berkeley DB locks to process large but technically valid blocks. Berkeley DB locks have to be manually configured by API users depending on anticipated load. The manual says this:
+Bitcoin versions prior to 0.8 configure an insufficient number of Berkeley DB locks to process large but otherwise valid blocks. Berkeley DB locks have to be manually configured by API users depending on anticipated load. The manual says this:
 
 :The recommended algorithm for selecting the maximum number of locks, lockers, and lock objects is to run the application under stressful conditions and then review the lock system's statistics to determine the maximum number of locks, lockers, and lock objects that were used. Then, double these values for safety.
 
+With the insufficiently high BDB lock configuration, it implicitly had become a network consensus rule determining block validity (albeit an inconsistent and unsafe rule, since the lock usage could vary from node to node).
+
 Because max-sized blocks had been successfully processed on the testnet, it did not occur to anyone that there could be blocks that were smaller but require more locks than were available. Prior to 0.7 unmodified mining nodes self-imposed a maximum block size of 500,000 bytes, which further prevented this case from being triggered. 0.7 made the target size configurable and miners had been encouraged to increase this target in the week prior to the incident.
 
-Bitcoin 0.8 does not use Berkeley DB. It uses LevelDB instead, which does not require this kind of pre-configuration. Therefore it was able to process the forking block successfully.
+Bitcoin Core 0.8 did not use Berkeley DB. It switched to LevelDB instead, which did not implement the same locking limits as BDB. Therefore it was able to process the forking block successfully.
 
 Note that BDB locks are also required during processing of re-organizations. Versions prior to 0.8 may be unable to process some valid re-orgs.
 
@@ -39,10 +41,10 @@ This would be an issue even if the entire network was running version 0.7.2. It
 ===Immediately===
 
 '''Done''': Release a version 0.8.1, forked directly from 0.8.0, that, for the next two months has the following new rules:
-# Reject blocks that could cause more than 10,000 locks to be taken.
+# Reject blocks that would probably could cause more than 10,000 locks to be taken.
 # Limit the maximum block-size created to 500,000 bytes
-# Release a patch for older versions that implements the same rules, but also increases the maximum number of locks to 120,000
-# Create a web page on bitcoin.org that will urge users to upgrade to 0.8.1, but will tell them how to set DB_CONFIG to 120,000 locks if they absolutely cannot.
+# Release a patch for older versions that implements the same rules, but also increases the maximum number of locks to 537,000
+# Create a web page on bitcoin.org that will urge users to upgrade to 0.8.1, but will tell them how to set DB_CONFIG to 537,000 locks if they absolutely cannot.
 # Over the next 2 months, send a series of alerts to users of older versions, pointing to the web page.
 
 ===Alert system===
@@ -70,3 +72,7 @@ A double spend attack was successful, despite that both sides of the chain heard
 ===Resolution===
 
 On 16 August, 2013 block 252,451 (0x0000000000000024b58eeb1134432f00497a6a860412996e7a260f47126eed07) was accepted by the main network, forking unpatched nodes off the network.
+
+==Copyright==
+
+This document is placed in the public domain.

From 421577d6cf26bb21bebcb4da5f04e183d2859d0a Mon Sep 17 00:00:00 2001
From: Luke Dashjr 
Date: Tue, 9 Feb 2016 05:12:38 +0000
Subject: [PATCH 211/259] Assign BIP 145: getblocktemplate Updates for
 Segregated Witness

---
 README.mediawiki                               | 6 ++++++
 bip-segwit-gbt.mediawiki => bip-0145.mediawiki | 6 +++++-
 2 files changed, 11 insertions(+), 1 deletion(-)
 rename bip-segwit-gbt.mediawiki => bip-0145.mediawiki (97%)

diff --git a/README.mediawiki b/README.mediawiki
index 045fd28f..b6e8fa49 100644
--- a/README.mediawiki
+++ b/README.mediawiki
@@ -463,6 +463,12 @@ Those proposing changes should consider that ultimately consent may rest with th
 | Eric Lombrozo, Pieter Wuille
 | Standard
 | Draft
+|-
+| [[bip-0145.mediawiki|145]]
+| getblocktemplate Updates for Segregated Witness
+| Luke Dashjr
+| Standard
+| Draft
 |}
 
 
diff --git a/bip-segwit-gbt.mediawiki b/bip-0145.mediawiki
similarity index 97%
rename from bip-segwit-gbt.mediawiki
rename to bip-0145.mediawiki
index 0ad10c28..9274b6cf 100644
--- a/bip-segwit-gbt.mediawiki
+++ b/bip-0145.mediawiki
@@ -1,5 +1,5 @@
 
-  BIP: x
+  BIP: 145
   Title: getblocktemplate Updates for Segregated Witness
   Author: Luke Dashjr 
   Status: Draft
@@ -92,3 +92,7 @@ Why shouldn't the server simply add the commitment upfront in the "coinbasetxn",
 * [[bip-0022.mediawiki|BIP 22: getblocktemplate - Fundamentals]]
 * [[bip-0023.mediawiki|BIP 23: getblocktemplate - Pooled Mining]]
 * [[bip-0141.mediawiki|BIP 141: Segregated Witness (Consensus layer)]]
+
+==Copyright==
+
+This BIP is dual-licensed under the Open Publication License and BSD 2-clause license.

From ebf5c289882d7128e71a91e0a5bd90c1e8e90464 Mon Sep 17 00:00:00 2001
From: Luke Dashjr 
Date: Wed, 3 Feb 2016 21:47:48 +0000
Subject: [PATCH 212/259] Travis: Initial formatting tests

---
 .travis.yml           |   7 +++
 scripts/buildtable.pl | 136 ++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 143 insertions(+)
 create mode 100644 .travis.yml
 create mode 100755 scripts/buildtable.pl

diff --git a/.travis.yml b/.travis.yml
new file mode 100644
index 00000000..ed99de0f
--- /dev/null
+++ b/.travis.yml
@@ -0,0 +1,7 @@
+os: linux
+language: generic
+sudo: false
+script:
+    - scripts/buildtable.pl >/tmp/table.mediawiki || exit 1
+    - diff README.mediawiki /tmp/table.mediawiki | grep '^[<>] |' >/tmp/after.diff || true
+    - if git checkout HEAD^ && scripts/buildtable.pl >/tmp/table.mediawiki 2>/dev/null; then diff README.mediawiki /tmp/table.mediawiki | grep '^[<>] |' >/tmp/before.diff || true; newdiff=$(diff -s /tmp/before.diff /tmp/after.diff -u | grep '^+'); if [ -n "$newdiff" ]; then echo "$newdiff"; exit 1; fi; else echo 'Cannot build previous commit table for comparison'; fi
diff --git a/scripts/buildtable.pl b/scripts/buildtable.pl
new file mode 100755
index 00000000..568b8eb0
--- /dev/null
+++ b/scripts/buildtable.pl
@@ -0,0 +1,136 @@
+#!/usr/bin/perl
+use strict;
+use warnings;
+
+my $topbip = 9999;
+
+my %RequiredFields = (
+	BIP => undef,
+	Title => undef,
+	Author => undef,
+	Status => undef,
+	Type => undef,
+	Created => undef,
+);
+my %MayHaveMulti = (
+	Author => undef,
+	'Post-History' => undef,
+);
+my %DateField = (
+	Created => undef,
+);
+my %EmailField = (
+	Author => undef,
+	Editor => undef,
+);
+my %MiscField = (
+	'Post-History' => undef,
+);
+
+my %ValidLayer = (
+	Process => undef,
+);
+my %ValidStatus = (
+	Draft => undef,
+	Deferred => undef,
+	Accepted => "background-color: #ffffcf",
+	Rejected => "background-color: #ffcfcf",
+	Withdrawn => "background-color: #ffcfcf",
+	Final => "background-color: #cfffcf",
+	Active => "background-color: #cfffcf",
+	Replaced => "background-color: #ffcfcf",
+);
+my %ValidType = (
+	'Standards Track' => 'Standard',
+	'Informational' => undef,
+	'Process' => undef,
+);
+
+my %emails;
+
+my $bipnum = 0;
+while (++$bipnum <= $topbip) {
+	my $fn = sprintf "bip-%04d.mediawiki", $bipnum;
+	-e $fn || next;
+	open my $F, "<$fn";
+	while (<$F> !~ m[^(?:\xef\xbb\xbf)?
$]) {
+			die "No 
 in $fn" if eof $F;
+	}
+	my %found;
+	my ($title, $author, $status, $type);
+	my ($field, $val);
+	while (<$F>) {
+		m[^
$] && last;
+		if (m[^  ([\w-]+)\: (.*\S)$]) {
+			$field = $1;
+			$val = $2;
+			die "Duplicate $field field in $fn" if exists $found{$field};
+		} elsif (m[^  ( +)(.*\S)$]) {
+			die "Continuation of non-field in $fn" unless defined $field;
+			die "Too many spaces in $fn" if length $1 != 2 + length $field;
+			die "Not allowed for multi-value in $fn" unless exists $MayHaveMulti{$field};
+			$val = $2;
+		} else {
+			die "Bad line in $fn preamble";
+		}
+		++$found{$field};
+		die "Extra spaces in $fn" if $val =~ /^\s/;
+		if ($field eq 'BIP') {
+			die "$fn claims to be BIP $val" if $val ne $bipnum;
+		} elsif ($field eq 'Title') {
+			$title = $val;
+		} elsif ($field eq 'Author') {
+			$val =~ m/^(\S[^<@>]*\S) \<([^@>]*\@[\w.]+\.\w+)\>$/ or die "Malformed Author line in $fn";
+			my ($authorname, $authoremail) = ($1, $2);
+			$authoremail =~ s/(?<=\D)$bipnum(?=\D)//g;
+			$emails{$authorname}->{$authoremail} = undef;
+			if (defined $author) {
+				$author .= ", $authorname";
+			} else {
+				$author = $authorname;
+			}
+		} elsif ($field eq 'Status') {
+			if ($bipnum == 38) {  # HACK
+				$val =~ s/\s+\(.*\)$//;
+			}
+			die "Invalid status in $fn" unless exists $ValidStatus{$val};
+			$status = $val;
+		} elsif ($field eq 'Type') {
+			die "Invalid type in $fn" unless exists $ValidType{$val};
+			if (defined $ValidType{$val}) {
+				$type = $ValidType{$val};
+			} else {
+				$type = $val;
+			}
+		} elsif ($field eq 'Layer') {  # BIP 123
+			die "Invalid layer $val in $fn" unless exists $ValidLayer{$val};
+		} elsif (exists $DateField{$field}) {
+			die "Invalid date format in $fn" unless $val =~ /^20\d{2}\-(?:0\d|1[012])\-(?:[012]\d|30|31)$/;
+		} elsif (exists $EmailField{$field}) {
+			$val =~ m/^(\S[^<@>]*\S) \<[^@>]*\@[\w.]+\.\w+\>$/ or die "Malformed $field line in $fn";
+		} elsif (not exists $MiscField{$field}) {
+			die "Unknown field $field in $fn";
+		}
+	}
+	for my $field (keys %RequiredFields) {
+		die "Missing $field in $fn" unless $found{$field};
+	}
+	print "|-";
+	if (defined $ValidStatus{$status}) {
+		print " style=\"" . $ValidStatus{$status} . "\"";
+	}
+	print "\n";
+	print "| [[${fn}|${bipnum}]]\n";
+	print "| ${title}\n";
+	print "| ${author}\n";
+	print "| ${type}\n";
+	print "| ${status}\n";
+	close $F;
+}
+
+for my $author (sort keys %emails) {
+	my @emails = sort keys %{$emails{$author}};
+	my $email_count = @emails;
+	next unless $email_count > 1;
+	warn "NOTE: $author has $email_count email addresses: @emails\n";
+}

From 42777fed36a9482fc0d35733204b2fdaecec36b1 Mon Sep 17 00:00:00 2001
From: Luke Dashjr 
Date: Tue, 9 Feb 2016 05:26:28 +0000
Subject: [PATCH 213/259] bip-0145: Remove incomplete thought

---
 bip-0145.mediawiki | 2 --
 1 file changed, 2 deletions(-)

diff --git a/bip-0145.mediawiki b/bip-0145.mediawiki
index 9274b6cf..b90725e0 100644
--- a/bip-0145.mediawiki
+++ b/bip-0145.mediawiki
@@ -13,8 +13,6 @@ This BIP describes modifications to the getblocktemplate JSON-RPC call ([[bip-00
 
 ==Specification==
 
-The notion of "cost" is introduced 
-
 ===Block Template===
 
 The template Object is revised to include these keys:

From 37b988a035b25b75fb0c8cf0a36030a5756cb0e2 Mon Sep 17 00:00:00 2001
From: Dan Gershony 
Date: Wed, 10 Feb 2016 17:23:28 +0000
Subject: [PATCH 214/259] Adding crypzo to BIP44 supported wallets

---
 bip-0044.mediawiki | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/bip-0044.mediawiki b/bip-0044.mediawiki
index 6012ff52..64358d8c 100644
--- a/bip-0044.mediawiki
+++ b/bip-0044.mediawiki
@@ -267,7 +267,7 @@ is required and a pull request to the above file should be created.
 * [[https://play.google.com/store/apps/details?id=com.mycelium.wallet|Mycelium Bitcoin Wallet (Android)]] ([[https://github.com/mycelium-com/wallet|source]])
 * [[https://copay.io/|Copay]] ([[https://github.com/bitpay/copay|source]])
 * [[https://maza.club/encompass|Encompass]] ([[https://github.com/mazaclub/encompass|source]])
-
+* [[https://www.crypzo.com/|Crypzo]] 
 ==Reference==
 
 * [[bip-0032.mediawiki|BIP32 - Hierarchical Deterministic Wallets]]

From 0c0ac09ccf8586335ea93cd1d0ae550862a370e4 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?=E0=B8=BFtcDrak?= 
Date: Wed, 10 Feb 2016 17:25:52 +0000
Subject: [PATCH 215/259] Correct typo

Bitcoin Core didn't exist until 0.9.
---
 bip-0050.mediawiki | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/bip-0050.mediawiki b/bip-0050.mediawiki
index 31070700..a5953216 100644
--- a/bip-0050.mediawiki
+++ b/bip-0050.mediawiki
@@ -30,7 +30,7 @@ With the insufficiently high BDB lock configuration, it implicitly had become a
 
 Because max-sized blocks had been successfully processed on the testnet, it did not occur to anyone that there could be blocks that were smaller but require more locks than were available. Prior to 0.7 unmodified mining nodes self-imposed a maximum block size of 500,000 bytes, which further prevented this case from being triggered. 0.7 made the target size configurable and miners had been encouraged to increase this target in the week prior to the incident.
 
-Bitcoin Core 0.8 did not use Berkeley DB. It switched to LevelDB instead, which did not implement the same locking limits as BDB. Therefore it was able to process the forking block successfully.
+Bitcoin 0.8 did not use Berkeley DB. It switched to LevelDB instead, which did not implement the same locking limits as BDB. Therefore it was able to process the forking block successfully.
 
 Note that BDB locks are also required during processing of re-organizations. Versions prior to 0.8 may be unable to process some valid re-orgs.
 

From 6cf43331706934e6e5c97e4a57e0f6be8eb0899e Mon Sep 17 00:00:00 2001
From: Gavin Andresen 
Date: Thu, 28 Jan 2016 10:53:43 -0500
Subject: [PATCH 216/259] BIP102 variation for a 2mb block size bump

---
 README.mediawiki   |  6 ++++
 bip-0109.mediawiki | 78 ++++++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 84 insertions(+)
 create mode 100644 bip-0109.mediawiki

diff --git a/README.mediawiki b/README.mediawiki
index 3e9215de..13012595 100644
--- a/README.mediawiki
+++ b/README.mediawiki
@@ -374,6 +374,12 @@ Those proposing changes should consider that ultimately consent may rest with th
 | Standard
 | Draft
 |-
+| [[bip-0109.mediawiki|109]]
+| 2MB size limit with sigop and sighash limits
+| Gavin Andresen
+| Standard
+| Draft
+|-
 | [[bip-0111.mediawiki|111]]
 | NODE_BLOOM service bit
 | Matt Corallo, Peter Todd
diff --git a/bip-0109.mediawiki b/bip-0109.mediawiki
new file mode 100644
index 00000000..e7cf9e73
--- /dev/null
+++ b/bip-0109.mediawiki
@@ -0,0 +1,78 @@
+
+  BIP: 109
+  Title: Block size increase to 2MB
+  Author: Gavin Andresen 
+  Status: Draft
+  Type: Standards Track
+  Created: 2016-01-28
+

+
+==Abstract==
+
+One-time increase in total amount of transaction data permitted in a block from 1MB to 2MB, with limits on signature operations and hashing.
+
+==Motivation==
+
+# Continue current economic policy.
+# Exercise hard fork network upgrade.
+# Mitigate potential CPU exhaustion attacks
+
+==Specification==
+
+=== MAX_BLOCK_SIZE increased to 2,000,000 bytes ===
+
+The maximum number of bytes in a canonically serialized block shall be increased from
+1,000,000 bytes to 2,000,000 bytes.
+
+=== Switch to accurately-counted sigop limit of 20,000 per block ===
+
+The existing MAX_SIGOPS limit of 20,000 signature operations per block shall be retained,
+but only ECDSA verifications actually performed to validate the block shall be counted.
+
+In particular:
+
+* The coinbase scriptSig is not counted
+* Signature operations in un-executed branches of a Script are not counted
+* OP_CHECKMULTISIG evaluations are counted accurately; if the signature for a 1-of-20 OP_CHECKMULTISIG is satisified by the public key nearest the top of the execution stack, it is counted as one signature operation. If it is satisfied by the public key nearest the bottom of the execution stack, it is counted as twenty signature operations.
+* Signature operations involving invalidly encoded signatures or public keys are not counted towards the limit
+
+=== Add a new limit of 1,300,000,000 bytes hashed to compute transaction signatures per block ===
+
+The amount of data hashed to compute signature hashes is limited to 1,300,000,000 bytes per block. The same rules for counting are used as for counting signature operations.
+
+=== Activation: 75% hashpower support trigger, followed by 28-day 'grace period' ===
+
+Solo miners or mining pool operators express their support for this BIP by setting the fourth-highest-bit in the block's 32-bit version number (0x10000000 in hex). The first block with that bit set, a timestamp less than or equal to the expiration time, and with at least 750 out of 1000 blocks preceding it (with heights H-1000..H-1) with that bit set, shall define the beginning of a grace period. Blocks with timestamps greater than or equal to the triggering block's timestamp plus 28 days (60*60*24*28 seconds) shall be subject to the new limits.
+
+As always, miners are expected to use their best judgement for what is best for the entire Bitcoin ecosystem when making decisions about what consensus-level changes to support.
+
+=== Expiration: 1-Jan-2018 ===
+
+If this BIP is not triggered before 1-Jan-2018 00:00:00 GMT it should be considered withdrawn.
+
+Miners that support this BIP should set bit 0x10000000 in the block version until 1-Jan-2018. After that date, that bit can be safely re-used for future consensus rule upgrades.
+
+==Backward compatibility==
+
+Fully validating older clients are not compatible with this change.
+The first block exceeding the old limits on block size or inaccurately counted signature operations will partition older clients off the new network.
+
+SPV (simple payment validation) wallets are compatible with this change.
+
+==Rationale==
+
+In the short term, an increase is needed to handle increasing transaction volume. 
+
+The limits on signature operations and amount of signature hashing done prevent possible CPU exhaustion attacks by "rogue miners" producing very expensive-to-validate two megabyte blocks. The signature hashing limit is chosen to be impossible to reach with any non-attack transaction or block, to minimize the impact on existing mining or wallet software.
+
+The choices of constants for the deployment scheme were motivated by prior experience with upgrades to the Bitcoin consensus rules:
+
+* 0x10000000 was chosen to be compatible with the BIP 9 proposal for parallel deployment of soft forks
+* 75% was chosen instead of 95% to minimize the opportunity for a single large mining pool or miner to be able to veto an increase, either because of ideological opposition or threat of violence or extortion.
+* A four-week grace period after the voting period was chosen as a balance between giving people sufficient time to upgrade and keeping people's attention on the urgent need to upgrade.
+
+==Implementation==
+
+https://github.com/gavinandresen/bitcoin-git/tree/two_mb_bump
+
+See also http://gavinandresen.ninja/a-guided-tour-of-the-2mb-fork

From c469bd930b3caca250f885785375474aacc55759 Mon Sep 17 00:00:00 2001
From: Gavin Andresen 
Date: Thu, 11 Feb 2016 09:27:01 -0500
Subject: [PATCH 217/259] Add copyright

---
 bip-0109.mediawiki | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/bip-0109.mediawiki b/bip-0109.mediawiki
index e7cf9e73..5e67e395 100644
--- a/bip-0109.mediawiki
+++ b/bip-0109.mediawiki
@@ -76,3 +76,7 @@ The choices of constants for the deployment scheme were motivated by prior exper
 https://github.com/gavinandresen/bitcoin-git/tree/two_mb_bump
 
 See also http://gavinandresen.ninja/a-guided-tour-of-the-2mb-fork
+
+==Copyright==
+
+This work is placed in the public domain.

From 0e7466abc281aaf9b6f620b0c6004f8fae592df5 Mon Sep 17 00:00:00 2001
From: Gavin Andresen 
Date: Thu, 11 Feb 2016 11:37:13 -0500
Subject: [PATCH 218/259] Tweaked BIP 109 title

---
 README.mediawiki   | 2 +-
 bip-0109.mediawiki | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/README.mediawiki b/README.mediawiki
index 13012595..5a01d4d2 100644
--- a/README.mediawiki
+++ b/README.mediawiki
@@ -375,7 +375,7 @@ Those proposing changes should consider that ultimately consent may rest with th
 | Draft
 |-
 | [[bip-0109.mediawiki|109]]
-| 2MB size limit with sigop and sighash limits
+| Two million byte size limit with sigop and sighash limits
 | Gavin Andresen
 | Standard
 | Draft
diff --git a/bip-0109.mediawiki b/bip-0109.mediawiki
index 5e67e395..667ef5f5 100644
--- a/bip-0109.mediawiki
+++ b/bip-0109.mediawiki
@@ -1,6 +1,6 @@
 
   BIP: 109
-  Title: Block size increase to 2MB
+  Title: Two million byte size limit with sigop and sighash limits
   Author: Gavin Andresen 
   Status: Draft
   Type: Standards Track

From 0c956f8f64288b5a1a7c4c7c7d9f2beac74bb7cc Mon Sep 17 00:00:00 2001
From: Gavin Andresen 
Date: Thu, 11 Feb 2016 15:25:06 -0500
Subject: [PATCH 219/259] Withdraw BIP 101 proposal

---
 README.mediawiki   | 2 +-
 bip-0101.mediawiki | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/README.mediawiki b/README.mediawiki
index 3e9215de..d723f007 100644
--- a/README.mediawiki
+++ b/README.mediawiki
@@ -342,7 +342,7 @@ Those proposing changes should consider that ultimately consent may rest with th
 | Increase maximum block size
 | Gavin Andresen
 | Standard
-| Draft
+| Withdrawn
 |-
 | [[bip-0102.mediawiki|102]]
 | Block size increase to 2MB
diff --git a/bip-0101.mediawiki b/bip-0101.mediawiki
index a76db0f9..cc8cfd5f 100644
--- a/bip-0101.mediawiki
+++ b/bip-0101.mediawiki
@@ -2,7 +2,7 @@
   BIP: 101
   Title: Increase maximum block size
   Author: Gavin Andresen 
-  Status: Draft
+  Status: Withdrawn
   Type: Standards Track
   Created: 2015-06-22
 


From 0e48a2466c18de67fa0e1c80facb9b7cdf598f3e Mon Sep 17 00:00:00 2001
From: BtcDrak 
Date: Fri, 12 Feb 2016 04:10:24 +0000
Subject: [PATCH 220/259] Update BIP68 implementation to match spec

---
 bip-0068.mediawiki | 23 ++++++++++++-----------
 1 file changed, 12 insertions(+), 11 deletions(-)

diff --git a/bip-0068.mediawiki b/bip-0068.mediawiki
index b7bb0db1..fd17ea5d 100644
--- a/bip-0068.mediawiki
+++ b/bip-0068.mediawiki
@@ -64,21 +64,21 @@ enum {
 /* Setting nSequence to this value for every input in a transaction
  * disables nLockTime. */
 static const uint32_t SEQUENCE_FINAL = 0xffffffff;
-    
+
+/* Below flags apply in the context of BIP 68*/
 /* If this flag set, CTxIn::nSequence is NOT interpreted as a
- * relative lock-time. Setting the most significant bit of a
- * sequence number disabled relative lock-time. */
+ * relative lock-time. */
 static const uint32_t SEQUENCE_LOCKTIME_DISABLE_FLAG = (1 << 31);
-    
+
 /* If CTxIn::nSequence encodes a relative lock-time and this flag
  * is set, the relative lock-time has units of 512 seconds,
  * otherwise it specifies blocks with a granularity of 1. */
 static const uint32_t SEQUENCE_LOCKTIME_TYPE_FLAG = (1 << 22);
-    
+
 /* If CTxIn::nSequence encodes a relative lock-time, this mask is
  * applied to extract that lock-time from the sequence field. */
 static const uint32_t SEQUENCE_LOCKTIME_MASK = 0x0000ffff;
-    
+
 /* In order to use the same number of bits to encode roughly the
  * same wall-clock duration, and because blocks are naturally
  * limited to occur every 600s on average, the minimum granularity
@@ -87,7 +87,7 @@ static const uint32_t SEQUENCE_LOCKTIME_MASK = 0x0000ffff;
  * multiplying by 512 = 2^9, or equivalently shifting up by
  * 9 bits. */
 static const int SEQUENCE_LOCKTIME_GRANULARITY = 9;
-    
+
 /**
  * Calculates the block height and previous block's median time past at
  * which the transaction will be considered final in the context of BIP 68.
@@ -174,16 +174,17 @@ bool SequenceLocks(const CTransaction &tx, int flags, std::vector* prevHeig
 bool CheckSequenceLocks(const CTransaction &tx, int flags)
 {
     AssertLockHeld(cs_main);
+    AssertLockHeld(mempool.cs);
 
     CBlockIndex* tip = chainActive.Tip();
     CBlockIndex index;
     index.pprev = tip;
     // CheckSequenceLocks() uses chainActive.Height()+1 to evaluate
     // height based locks because when SequenceLocks() is called within
-    // CBlock::AcceptBlock(), the height of the block *being*
-    // evaluated is what is used. Thus if we want to know if a
-    // transaction can be part of the *next* block, we need to call
-    // SequenceLocks() with one more than chainActive.Height().
+    // ConnectBlock(), the height of the block *being*
+    // evaluated is what is used.
+    // Thus if we want to know if a transaction can be part of the
+    // *next* block, we need to use one more than chainActive.Height()
     index.nHeight = tip->nHeight + 1;
 
     // pcoinsTip contains the UTXO set for chainActive.Tip()

From e51082150c8948aa08a5ebac998c581a81d1f0e4 Mon Sep 17 00:00:00 2001
From: Bryan Bishop 
Date: Fri, 12 Feb 2016 09:00:21 -0600
Subject: [PATCH 221/259] BIP1: fix typo in old changelog line

---
 bip-0001.mediawiki | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/bip-0001.mediawiki b/bip-0001.mediawiki
index 4f91a394..df4e3cd2 100644
--- a/bip-0001.mediawiki
+++ b/bip-0001.mediawiki
@@ -175,6 +175,6 @@ This document was derived heavily from Python's PEP-0001. In many places text wa
 
 ==Changelog==
 
-10 Oct 2015 - Added clarifications about sumission process and BIP number assignment.
+10 Oct 2015 - Added clarifications about submission process and BIP number assignment.
 
 01 Jan 2016 - Clarified early stages of BIP idea championing, collecting community feedback, etc.

From aa7719688c535803f47a860b1f400a91adeefcd4 Mon Sep 17 00:00:00 2001
From: Bryan Bishop 
Date: Fri, 12 Feb 2016 09:04:11 -0600
Subject: [PATCH 222/259] BIP1: formatfix for auxiliary file subsection

---
 bip-0001.mediawiki | 9 +++++----
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/bip-0001.mediawiki b/bip-0001.mediawiki
index df4e3cd2..44fbe8b2 100644
--- a/bip-0001.mediawiki
+++ b/bip-0001.mediawiki
@@ -85,9 +85,9 @@ Each BIP should have the following parts:
 
 ==BIP Formats and Templates==
 
-BIPs should be written in mediawiki or markdown format. Image files should be included in a subdirectory for that BIP.
+BIPs should be written in mediawiki or markdown format.
 
-==BIP Header Preamble==
+===BIP Header Preamble===
 
 Each BIP must begin with an RFC 822 style header preamble. The headers must appear in the following order. Headers marked with "*" are optional and are described below. All other headers are required.
 
@@ -129,9 +129,10 @@ The Created header records the date that the BIP was assigned a number, while Po
 BIPs may have a Requires header, indicating the BIP numbers that this BIP depends on.
 
 BIPs may also have a Superseded-By header indicating that a BIP has been rendered obsolete by a later document; the value is the number of the BIP that replaces the current document. The newer BIP must have a Replaces header containing the number of the BIP that it rendered obsolete.
-Auxiliary Files
 
-BIPs may include auxiliary files such as diagrams. Such files must be named BIP-XXXX-Y.ext, where "XXXX" is the BIP number, "Y" is a serial number (starting at 1), and "ext" is replaced by the actual file extension (e.g. "png").
+===Auxiliary Files===
+
+BIPs may include auxiliary files such as diagrams. Image files should be included in a subdirectory for that BIP. Auxiliary files must be named BIP-XXXX-Y.ext, where "XXXX" is the BIP number, "Y" is a serial number (starting at 1), and "ext" is replaced by the actual file extension (e.g. "png").
 
 ==Transferring BIP Ownership==
 

From cde1e50d9d3cd522463216889485fe5324a4df3d Mon Sep 17 00:00:00 2001
From: paveljanik 
Date: Fri, 12 Feb 2016 18:52:13 +0100
Subject: [PATCH 223/259] ISM: Proper case

---
 bip-0112.mediawiki | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/bip-0112.mediawiki b/bip-0112.mediawiki
index 9c2d199a..71fbc2a1 100644
--- a/bip-0112.mediawiki
+++ b/bip-0112.mediawiki
@@ -350,7 +350,7 @@ https://github.com/bitcoin/bitcoin/pull/6564
 
 ==Deployment==
 
-This BIP is to be deployed by either version-bits BIP9 or by isSuperMajority(). Exact details TDB.
+This BIP is to be deployed by either version-bits BIP9 or by IsSuperMajority(). Exact details TDB.
 
 It is recommended to deploy BIP68 and BIP113 at the same time as this BIP.
 

From 545017feb4bcb9ad00c435c528643a483d6ffa16 Mon Sep 17 00:00:00 2001
From: paveljanik 
Date: Fri, 12 Feb 2016 19:01:52 +0100
Subject: [PATCH 224/259] PR 6564 -> 7524

New PR number.
---
 bip-0112.mediawiki | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/bip-0112.mediawiki b/bip-0112.mediawiki
index 71fbc2a1..cb9f2066 100644
--- a/bip-0112.mediawiki
+++ b/bip-0112.mediawiki
@@ -345,7 +345,7 @@ semantics and detailed rationale for those semantics.
 
 A reference implementation is provided by the following pull request:
 
-https://github.com/bitcoin/bitcoin/pull/6564
+https://github.com/bitcoin/bitcoin/pull/7524
 
 
 ==Deployment==

From 92586a1e3891bffd58046ea3eaa2fc682a82ecf4 Mon Sep 17 00:00:00 2001
From: Gavin Andresen 
Date: Fri, 12 Feb 2016 17:33:05 -0500
Subject: [PATCH 225/259] Set background to withdrawn color

---
 README.mediawiki | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/README.mediawiki b/README.mediawiki
index d723f007..32333af8 100644
--- a/README.mediawiki
+++ b/README.mediawiki
@@ -337,7 +337,7 @@ Those proposing changes should consider that ultimately consent may rest with th
 | Jorge Timón
 | Informational
 | Draft
-|-
+|- style="background-color: #ffcfcf"
 | [[bip-0101.mediawiki|101]]
 | Increase maximum block size
 | Gavin Andresen

From a712fe5e22eb05968a5862fe4efebed9fb0c5ce7 Mon Sep 17 00:00:00 2001
From: BtcDrak 
Date: Sat, 13 Feb 2016 12:14:03 +0000
Subject: [PATCH 226/259] Update BIP112 reference example

---
 bip-0112.mediawiki | 204 ++++++++++++++++++++++-----------------------
 1 file changed, 98 insertions(+), 106 deletions(-)

diff --git a/bip-0112.mediawiki b/bip-0112.mediawiki
index cb9f2066..336f9fc3 100644
--- a/bip-0112.mediawiki
+++ b/bip-0112.mediawiki
@@ -229,117 +229,109 @@ The 2-way pegged sidechain requires a new REORGPROOFVERIFY opcode, the semantics
 Refer to the reference implementation, reproduced below, for the precise 
 semantics and detailed rationale for those semantics.
 
-    
-    /* If this flag set, CTxIn::nSequence is NOT interpreted as a
-     * relative lock-time. */
-    static const uint32_t SEQUENCE_LOCKTIME_DISABLE_FLAG = (1 << 31);
-    
-    /* If CTxIn::nSequence encodes a relative lock-time and this flag
-     * is set, the relative lock-time has units of 512 seconds,
-     * otherwise it specifies blocks with a granularity of 1. */
-    static const uint32_t SEQUENCE_LOCKTIME_TYPE_FLAG = (1 << 22);
-    
-    /* If CTxIn::nSequence encodes a relative lock-time, this mask is
-     * applied to extract that lock-time from the sequence field. */
-    static const uint32_t SEQUENCE_LOCKTIME_MASK = 0x0000ffff;
+
+/* Below flags apply in the context of BIP 68 */
+/* If this flag set, CTxIn::nSequence is NOT interpreted as a
+ * relative lock-time. */
+static const uint32_t SEQUENCE_LOCKTIME_DISABLE_FLAG = (1 << 31);
+
+/* If CTxIn::nSequence encodes a relative lock-time and this flag
+ * is set, the relative lock-time has units of 512 seconds,
+ * otherwise it specifies blocks with a granularity of 1. */
+static const uint32_t SEQUENCE_LOCKTIME_TYPE_FLAG = (1 << 22);
+
+/* If CTxIn::nSequence encodes a relative lock-time, this mask is
+ * applied to extract that lock-time from the sequence field. */
+static const uint32_t SEQUENCE_LOCKTIME_MASK = 0x0000ffff;
    
-    case OP_NOP3:
-    {
-        if (!(flags & SCRIPT_VERIFY_CHECKSEQUENCEVERIFY)) {
-            // not enabled; treat as a NOP3
-            if (flags & SCRIPT_VERIFY_DISCOURAGE_UPGRADABLE_NOPS) {
-                return set_error(serror, SCRIPT_ERR_DISCOURAGE_UPGRADABLE_NOPS);
-            }
-            break;
+case OP_NOP3:
+{
+    if (!(flags & SCRIPT_VERIFY_CHECKSEQUENCEVERIFY)) {
+        // not enabled; treat as a NOP3
+        if (flags & SCRIPT_VERIFY_DISCOURAGE_UPGRADABLE_NOPS) {
+            return set_error(serror, SCRIPT_ERR_DISCOURAGE_UPGRADABLE_NOPS);
         }
-    
-        if (stack.size() < 1)
-            return set_error(serror, SCRIPT_ERR_INVALID_STACK_OPERATION);
-     
-        // Note that elsewhere numeric opcodes are limited to
-        // operands in the range -2**31+1 to 2**31-1, however it is
-        // legal for opcodes to produce results exceeding that
-        // range. This limitation is implemented by CScriptNum's
-        // default 4-byte limit.
-        //
-        // Thus as a special case we tell CScriptNum to accept up
-        // to 5-byte bignums, which are good until 2**39-1, well
-        // beyond the 2**32-1 limit of the nSequence field itself.
-        const CScriptNum nSequence(stacktop(-1), fRequireMinimal, 5);
-    
-        // In the rare event that the argument may be < 0 due to
-        // some arithmetic being done first, you can always use
-        // 0 MAX CHECKSEQUENCEVERIFY.
-        if (nSequence < 0)
-            return set_error(serror, SCRIPT_ERR_NEGATIVE_LOCKTIME);
-    
-        // To provide for future soft-fork extensibility, if the
-        // operand has the disabled lock-time flag set,
-        // CHECKSEQUENCEVERIFY behaves as a NOP.
-        if ((nSequence & CTxIn::SEQUENCE_LOCKTIME_DISABLE_FLAG) != 0)
-            break;
-    
-        // Compare the specified sequence number with the input.
-        if (!checker.CheckSequence(nSequence))
-            return set_error(serror, SCRIPT_ERR_UNSATISFIED_LOCKTIME);
-    
         break;
     }
-    
-    bool TransactionSignatureChecker::CheckSequence(const CScriptNum& nSequence) const
-    {
-        // Relative lock times are supported by comparing the passed
-        // in operand to the sequence number of the input.
-        const int64_t txToSequence = (int64_t)txTo->vin[nIn].nSequence;
-    
-        // Fail if the transaction's version number is not set high
-        // enough to trigger BIP 68 rules.
-        if (static_cast(txTo->nVersion) < 2)
-            return false;
-    
-        // Sequence numbers with their most significant bit set are not
-        // defined by BIP68. Testing that the transaction's sequence
-        // number do not have this bit set prevents using this property
-        // to get around a CHECKSEQUENCEVERIFY check.
-        if (txToSequence & CTxIn::SEQUENCE_LOCKTIME_DISABLE_FLAG)
-            return false;
-    
-        // Mask off any bits that do not have BIP68 consensus-enforced meaning
-        // before doing the integer comparisons of ::VerifySequence.
-        const uint32_t nLockTimeMask = CTxIn::SEQUENCE_LOCKTIME_TYPE_FLAG
-                                     | CTxIn::SEQUENCE_LOCKTIME_MASK;
-        
-        if (!::VerifySequence(txToSequence & nLockTimeMask,
-                              CTxIn::SEQUENCE_LOCKTIME_TYPE_FLAG,
-                              nSequence & nLockTimeMask))
-            return false;
-    
-        return true;
-    }
-    
-    static bool VerifySequence(int64_t txToSequence, int64_t nThreshold, const CScriptNum& nSequence)
-    {
-        // There are two kinds of nLockTime: lock-by-blockheight
-        // and lock-by-blocktime, distinguished by whether
-        // nSequence < nThreshold (CTxIn::SEQUENCE_LOCKTIME_TYPE_FLAG).
-        //
-        // We want to compare apples to apples, so fail the script
-        // unless the type of nSequence being tested is the same as
-        // the nSequence in the transaction.
-        if (!(
-            (txToSequence <  nThreshold && nSequence <  nThreshold) ||
-            (txToSequence >= nThreshold && nSequence >= nThreshold)
-        ))
-            return false;
-    
-        // Now that we know we're comparing apples-to-apples, the
-        // comparison is a simple numeric one.
-        if (nSequence > txToSequence)
-            return false;
-    
-        return true;
-    }
 
+    if (stack.size() < 1)
+       return set_error(serror, SCRIPT_ERR_INVALID_STACK_OPERATION);
+
+    // Note that elsewhere numeric opcodes are limited to
+    // operands in the range -2**31+1 to 2**31-1, however it is
+    // legal for opcodes to produce results exceeding that
+    // range. This limitation is implemented by CScriptNum's
+    // default 4-byte limit.
+    //
+    // Thus as a special case we tell CScriptNum to accept up
+    // to 5-byte bignums, which are good until 2**39-1, well
+    // beyond the 2**32-1 limit of the nSequence field itself.
+    const CScriptNum nSequence(stacktop(-1), fRequireMinimal, 5);
+
+    // In the rare event that the argument may be < 0 due to
+    // some arithmetic being done first, you can always use
+    // 0 MAX CHECKSEQUENCEVERIFY.
+    if (nSequence < 0)
+        return set_error(serror, SCRIPT_ERR_NEGATIVE_LOCKTIME);
+
+    // To provide for future soft-fork extensibility, if the
+    // operand has the disabled lock-time flag set,
+    // CHECKSEQUENCEVERIFY behaves as a NOP.
+    if ((nSequence & CTxIn::SEQUENCE_LOCKTIME_DISABLE_FLAG) != 0)
+        break;
+
+    // Compare the specified sequence number with the input.
+    if (!checker.CheckSequence(nSequence))
+        return set_error(serror, SCRIPT_ERR_UNSATISFIED_LOCKTIME);
+
+    break;
+}
+    
+bool TransactionSignatureChecker::CheckSequence(const CScriptNum& nSequence) const
+{
+    // Relative lock times are supported by comparing the passed
+    // in operand to the sequence number of the input.
+    const int64_t txToSequence = (int64_t)txTo->vin[nIn].nSequence;
+
+    // Fail if the transaction's version number is not set high
+    // enough to trigger BIP 68 rules.
+    if (static_cast(txTo->nVersion) < 2)
+        return false;
+
+    // Sequence numbers with their most significant bit set are not
+    // consensus constrained. Testing that the transaction's sequence
+    // number do not have this bit set prevents using this property
+    // to get around a CHECKSEQUENCEVERIFY check.
+    if (txToSequence & CTxIn::SEQUENCE_LOCKTIME_DISABLE_FLAG)
+        return false;
+
+    // Mask off any bits that do not have consensus-enforced meaning
+    // before doing the integer comparisons
+    const uint32_t nLockTimeMask = CTxIn::SEQUENCE_LOCKTIME_TYPE_FLAG | CTxIn::SEQUENCE_LOCKTIME_MASK;
+    const int64_t txToSequenceMasked = txToSequence & nLockTimeMask;
+    const CScriptNum nSequenceMasked = nSequence & nLockTimeMask;
+
+    // There are two kinds of nSequence: lock-by-blockheight
+    // and lock-by-blocktime, distinguished by whether
+    // nSequenceMasked < CTxIn::SEQUENCE_LOCKTIME_TYPE_FLAG.
+    //
+    // We want to compare apples to apples, so fail the script
+    // unless the type of nSequenceMasked being tested is the same as
+    // the nSequenceMasked in the transaction.
+    if (!(
+        (txToSequenceMasked <  CTxIn::SEQUENCE_LOCKTIME_TYPE_FLAG && nSequenceMasked <  CTxIn::SEQUENCE_LOCKTIME_TYPE_FLAG) ||
+        (txToSequenceMasked >= CTxIn::SEQUENCE_LOCKTIME_TYPE_FLAG && nSequenceMasked >= CTxIn::SEQUENCE_LOCKTIME_TYPE_FLAG)
+    ))
+        return false;
+
+    // Now that we know we're comparing apples-to-apples, the
+    // comparison is a simple numeric one.
+    if (nSequenceMasked > txToSequenceMasked)
+        return false;
+
+    return true;
+}
+

 
 ==Reference Implementation==
 

From 7f12be52d34e16c4acfdec59ec84b136a800af44 Mon Sep 17 00:00:00 2001
From: MarcoFalke 
Date: Sat, 13 Feb 2016 22:56:50 +0100
Subject: [PATCH 227/259] [BIP 2] License header in preamble

---
 bip-0002.mediawiki | 40 ++++++++++++++++++++++++----------------
 1 file changed, 24 insertions(+), 16 deletions(-)

diff --git a/bip-0002.mediawiki b/bip-0002.mediawiki
index 571361c1..e6477e69 100644
--- a/bip-0002.mediawiki
+++ b/bip-0002.mediawiki
@@ -133,31 +133,39 @@ Will BIP comments be censored or limited to particular participants/"experts"?
 
 ==BIP licensing==
 
-New BIPs may be accepted with the following licenses:
-
 ===Specification===
 
+New BIPs may be accepted with the following licenses. Each new BIP must identify at least one acceptable license in its preamble. The License header in the preamble must be placed after the Created header. Each license must be referenced by their respecitve abbreviation given below.
+
+For example, a preamble might include the following License header:
+
+    License: PD
+             CC-0
+             MIT
+
 ====Recommended licenses====
 
-* [https://opensource.org/licenses/BSD-2-Clause OSI-approved BSD 2-clause license]
-* [https://opensource.org/licenses/BSD-3-Clause OSI-approved BSD 3-clause license]
-* [https://creativecommons.org/publicdomain/zero/1.0/ Creative Commons CC0 1.0 Universal]
-* [http://www.gnu.org/prep/maintain/html_node/License-Notices-for-Other-Files.html GNU All-Permissive License]
+* BSD-2-Clause: [https://opensource.org/licenses/BSD-2-Clause OSI-approved BSD 2-clause license]
+* BSD-3-Clause: [https://opensource.org/licenses/BSD-3-Clause OSI-approved BSD 3-clause license]
+* CC-0: [https://creativecommons.org/publicdomain/zero/1.0/ Creative Commons CC0 1.0 Universal]
+* GNU-ALL-PERMISSIVE: [http://www.gnu.org/prep/maintain/html_node/License-Notices-for-Other-Files.html GNU All-Permissive License]
 
 In addition, it is recommended that literal code included in the BIP be dual-licensed under the same license terms as the project it modifies. For example, literal code intended for Bitcoin Core would ideally be dual-licensed under the MIT license terms as well as one of the above with the rest of the BIP text.
 
 ====Not recommended, but acceptable licenses====
 
-* [http://www.apache.org/licenses/LICENSE-2.0 Apache License, version 2.0]
-* [http://www.boost.org/LICENSE_1_0.txt Boost Software License, version 1.0]
-* [https://creativecommons.org/licenses/by/4.0/ Creative Commons Attribution 4.0 International]
-* [https://creativecommons.org/licenses/by-sa/4.0/ Creative Commons Attribution-ShareAlike 4.0 International]
-* [https://opensource.org/licenses/MIT Expat/MIT/X11 license]
-* [http://www.gnu.org/licenses/agpl-3.0.en.html GNU Affero General Public License (AGPL), version 3 or newer]
-* [http://www.gnu.org/licenses/fdl-1.3.en.html GNU Free Documentation License]
-* [http://www.gnu.org/licenses/old-licenses/gpl-2.0.en.html GNU General Public License (GPL), version 2 or newer]
-* [http://www.gnu.org/licenses/old-licenses/lgpl-2.1.en.html GNU Lesser General Public License (LGPL), version 2.1 or newer]
-* [http://opencontent.org/openpub/ Open Publication License, version 1.0]
+* ALv2: [http://www.apache.org/licenses/LICENSE-2.0 Apache License, version 2.0]
+* BSL-1.0 [http://www.boost.org/LICENSE_1_0.txt Boost Software License, version 1.0]
+* CC-BY-4.0 [https://creativecommons.org/licenses/by/4.0/ Creative Commons Attribution 4.0 International]
+* CC-BY-SA-4.0 [https://creativecommons.org/licenses/by-sa/4.0/ Creative Commons Attribution-ShareAlike 4.0 International]
+* MIT [https://opensource.org/licenses/MIT Expat/MIT/X11 license]
+* AGPL-3.0 [http://www.gnu.org/licenses/agpl-3.0.en.html GNU Affero General Public License (AGPL), version 3 or newer]
+* FDL-1.3 [http://www.gnu.org/licenses/fdl-1.3.en.html GNU Free Documentation License]
+* GPL-2.0 [http://www.gnu.org/licenses/old-licenses/gpl-2.0.en.html GNU General Public License (GPL), version 2 or newer]
+* LGPL-2.1 [http://www.gnu.org/licenses/old-licenses/lgpl-2.1.en.html GNU Lesser General Public License (LGPL), version 2.1 or newer]
+* OPL-1.0 [http://opencontent.org/openpub/ Open Publication License, version 1.0]
+
+Additionally, PD is used to express that the work is placed in the public domain.
 
 ===Rationale===
 

From d5762820c122cd71dd6fb989a8bf6182fcb60de2 Mon Sep 17 00:00:00 2001
From: Sjors Provoost 
Date: Mon, 22 Feb 2016 14:57:35 +0800
Subject: [PATCH 228/259] BIP69: Add link to Blockchain.info implementation

We might switch to the BitcoinJS implementation in the future.

cc @kristovatlas
---
 bip-0069.mediawiki | 1 +
 1 file changed, 1 insertion(+)

diff --git a/bip-0069.mediawiki b/bip-0069.mediawiki
index 0eca369f..414fef94 100644
--- a/bip-0069.mediawiki
+++ b/bip-0069.mediawiki
@@ -162,6 +162,7 @@ Outputs:
 * [[https://github.com/bitcoinjs/bip69/blob/master/index.js|BitcoinJS]]
 * [[https://github.com/bitcoinjs/bip69/blob/master/test/fixtures.json|BitcoinJS Test Fixtures]]
 * [[https://www.npmjs.com/package/bip69|NodeJS]]
+* [[https://github.com/blockchain/My-Wallet-V3/blob/v3.8.0/src/transaction.js#L120-L142|Blockchain.info public beta]]
 
 ==Acknowledgements==
 

From a74ea14bc66d6be699f3e3d5aae2fa308ad7adad Mon Sep 17 00:00:00 2001
From: Luke Dashjr 
Date: Mon, 1 Feb 2016 21:17:02 +0000
Subject: [PATCH 229/259] Promote Draft->Final BIPs: 50 and 73

BIP 50: Proposed action items, including the hardfork, are completed.

BIP 73: Implemented by at least Bitcoin Core and BitPay.
---
 README.mediawiki   | 8 ++++----
 bip-0050.mediawiki | 2 +-
 bip-0073.mediawiki | 2 +-
 3 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/README.mediawiki b/README.mediawiki
index ce40a649..3c6b227d 100644
--- a/README.mediawiki
+++ b/README.mediawiki
@@ -216,12 +216,12 @@ Those proposing changes should consider that ultimately consent may rest with th
 | Justus Ranvier
 | Informational
 | Draft
-|-
+|- style="background-color: #cfffcf"
 | [[bip-0050.mediawiki|50]]
 | March 2013 Chain Fork Post-Mortem
 | Gavin Andresen
 | Informational
-| Draft
+| Final
 
 |-
 | [[bip-0060.mediawiki|60]]
@@ -301,12 +301,12 @@ Those proposing changes should consider that ultimately consent may rest with th
 | Gavin Andresen
 | Standard
 | Final
-|-
+|- style="background-color: #cfffcf"
 | [[bip-0073.mediawiki|73]]
 | Use "Accept" header for response type negotiation with Payment Request URLs
 | Stephen Pair
 | Standard
-| Draft
+| Final
 |-
 | [[bip-0074.mediawiki|74]]
 | Allow zero value OP_RETURN in Payment Protocol
diff --git a/bip-0050.mediawiki b/bip-0050.mediawiki
index a5953216..4f48fcac 100644
--- a/bip-0050.mediawiki
+++ b/bip-0050.mediawiki
@@ -2,7 +2,7 @@
   BIP: 50
   Title: March 2013 Chain Fork Post-Mortem
   Author: Gavin Andresen 
-  Status: Draft
+  Status: Final
   Type: Informational
   Created: 2013-03-20
 

diff --git a/bip-0073.mediawiki b/bip-0073.mediawiki
index a020fb56..41c89a30 100644
--- a/bip-0073.mediawiki
+++ b/bip-0073.mediawiki
@@ -2,7 +2,7 @@
   BIP: 73
   Title: Use "Accept" header for response type negotiation with Payment Request URLs
   Author: Stephen Pair 
-  Status: Draft
+  Status: Final
   Type: Standards Track
   Created: 2013-08-27
 


From feb11160c2eff1cf381a7086d977017ffdf94cae Mon Sep 17 00:00:00 2001
From: Alex Morcos 
Date: Thu, 25 Feb 2016 13:29:01 -0500
Subject: [PATCH 230/259] Submit feefilter message as BIP 133

---
 README.mediawiki   |  6 ++++++
 bip-0133.mediawiki | 45 +++++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 51 insertions(+)
 create mode 100644 bip-0133.mediawiki

diff --git a/README.mediawiki b/README.mediawiki
index 3c6b227d..02a5a767 100644
--- a/README.mediawiki
+++ b/README.mediawiki
@@ -452,6 +452,12 @@ Those proposing changes should consider that ultimately consent may rest with th
 | Process
 | Draft
 |-
+| [[bip-0133.mediawiki|133]]
+| feefilter message
+| Alex Morcos
+| Standard
+| Draft
+|-
 | [[bip-0140.mediawiki|140]]
 | Normalized TXID
 | Christian Decker
diff --git a/bip-0133.mediawiki b/bip-0133.mediawiki
new file mode 100644
index 00000000..d6d7437a
--- /dev/null
+++ b/bip-0133.mediawiki
@@ -0,0 +1,45 @@
+
+  BIP: 133
+  Title: feefilter message
+  Author: Alex Morcos 
+  Status: Draft
+  Type: Standards Track
+  Created: 2016-02-13
+

+
+==Abstract==
+
+Add a new message, "feefilter", which serves to instruct peers not to send "inv"'s to the node for transactions with fees below the specified fee rate.
+
+==Motivation==
+
+The concept of a limited mempool was introduced in Bitcoin Core 0.12 to provide protection against attacks or spam transactions of low fees that are not being mined. A reject filter was also introduced to help prevent repeated requests for the same transaction that might have been recently rejected for insufficient fee. These methods help keep resource utilization on a node from getting out of control.
+
+However, there are limitations to the effectiveness of these approaches.  The reject filter is reset after every block which means transactions that are inv'ed over a longer time period will be rerequested and there is no method to prevent requesting the transaction the first time.  Furthermore, inv data is sent at least once either to or from each peer for every transaction accepted to the mempool and there is no mechanism by which to know that an inv sent to a given peer would not result in a getdata request because it represents a transaction with too little fee.
+
+After receiving a feefilter message, a node can know before sending an inv that a given transaction's fee rate is below the minimum currently required by a given peer, and therefore the node can skip relaying an inv for that transaction to that peer.
+
+==Specification==
+
+# The feefilter message is defined as a message containing an int64_t where pchCommand == "feefilter"
+# Upon receipt of a "feefilter" message, the node will be permitted, but not required, to filter transaction invs for transactions that fall below the feerate provided in the feefilter message interpreted as satoshis per kilobyte.
+# The fee filter is additive with a bloom filter for transactions so if an SPV client were to load a bloom filter and send a feefilter message, transactions would only be relayed if they passed both filters.
+# Inv's generated from a mempool message are also subject to a fee filter if it exists.
+# Feature discovery is enabled by checking protocol version >= 70013
+
+==Considerations==
+The propagation efficiency of transactions across the network should not be adversely affected by this change. In general, transactions which are not accepted to your mempool are not relayed and the funcionality implemented with this message is meant only to filter those transactions.  There could be a small number of edge cases where a node's mempool min fee is actually less than the filter value a peer is aware of and transactions with fee rates between these values will now be newly inhibited.
+
+Feefilter messages are not sent to whitelisted peers if the "-whitelistforcerelay" option is set. In that case, transactions are intended to be relayed even if they are not accepted to the mempool.
+
+There are privacy concerns with deanonymizing a node by the fact that it is broadcasting identifying information about its mempool min fee. To help ameliorate this concern, the implementaion quantizes the filter value broadcast with a small amount of randomness, in addition, the messages are broadcast to different peers at individually randomly distributed times.
+
+If a node is using prioritisetransaction to accept transactions whose actual fee rates might fall below the node's mempool min fee, it may want to consider setting "-nofeefilter" to make sure it is exposed to all possible txid's.
+
+==Backward compatibility==
+
+Older clients remain fully compatible and interoperable after this change.  The sending of feefilter messages can be disabled by unsetting the "-feefilter" option.
+
+==Implementation==
+
+https://github.com/bitcoin/bitcoin/pull/7542

From 56bea488cbee7a3b89a34d916b283cd5fe03b64b Mon Sep 17 00:00:00 2001
From: MarcoFalke 
Date: Sat, 27 Feb 2016 14:12:08 +0100
Subject: [PATCH 231/259] [BIP 2] Allow optional License-Code header

---
 bip-0002.mediawiki | 11 +++++++++--
 1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/bip-0002.mediawiki b/bip-0002.mediawiki
index e6477e69..0d94792b 100644
--- a/bip-0002.mediawiki
+++ b/bip-0002.mediawiki
@@ -139,10 +139,17 @@ New BIPs may be accepted with the following licenses. Each new BIP must identify
 
 For example, a preamble might include the following License header:
 
-    License: PD
-             CC-0
+    License: CC-0
              MIT
 
+It is also possible to license source code differently from the BIP text. A optional License-Code header is placed after the License header. Again, each license must be referenced by their respective abbreviation given below.
+
+For example, a preamble specifying the optional License-Code header might look like:
+
+    License: CC-0
+             MIT
+    License-Code: GPL-2.0
+
 ====Recommended licenses====
 
 * BSD-2-Clause: [https://opensource.org/licenses/BSD-2-Clause OSI-approved BSD 2-clause license]

From c52eba239c3c2676a6aa30eb97a5875ecb824c9c Mon Sep 17 00:00:00 2001
From: Alex Morcos 
Date: Mon, 29 Feb 2016 14:30:32 -0500
Subject: [PATCH 232/259] Clarify non-dependence on BIP113

---
 bip-0068.mediawiki | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/bip-0068.mediawiki b/bip-0068.mediawiki
index fd17ea5d..8c566b09 100644
--- a/bip-0068.mediawiki
+++ b/bip-0068.mediawiki
@@ -220,7 +220,7 @@ This BIP was edited by BtcDrak, Nicolas Dorier and kinoshitajona.
 
 This BIP is to be deployed by either version-bits BIP9 or by isSuperMajority(). Exact details TDB.
 
-BIP68 MUST be deployed together with BIP113. It is also recommended to deploy BIP112 at the same time.
+It is recommended to deploy BIP112 and BIP113 at the same time.
 
 ==Compatibility==
 

From ab9b17b7f5a22e2e22aa0f8f239f3dd6aa337ad0 Mon Sep 17 00:00:00 2001
From: Alex Morcos 
Date: Mon, 29 Feb 2016 16:10:14 -0500
Subject: [PATCH 233/259] add copyright

---
 bip-0133.mediawiki | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/bip-0133.mediawiki b/bip-0133.mediawiki
index d6d7437a..b5146e33 100644
--- a/bip-0133.mediawiki
+++ b/bip-0133.mediawiki
@@ -43,3 +43,6 @@ Older clients remain fully compatible and interoperable after this change.  The
 ==Implementation==
 
 https://github.com/bitcoin/bitcoin/pull/7542
+
+==Copyright==
+This document is placed in the public domain.

From 8d7748e6fb044d6055d3448b2028212677d1d90b Mon Sep 17 00:00:00 2001
From: Alex Morcos 
Date: Mon, 29 Feb 2016 15:59:43 -0500
Subject: [PATCH 234/259] Remove BIP68's dependence on this BIP.  Remove
 deployment details.

---
 bip-0113.mediawiki | 43 ++++++++++---------------------------------
 1 file changed, 10 insertions(+), 33 deletions(-)

diff --git a/bip-0113.mediawiki b/bip-0113.mediawiki
index 15fa4f3f..d21054bf 100644
--- a/bip-0113.mediawiki
+++ b/bip-0113.mediawiki
@@ -34,8 +34,9 @@ value to monotonically advance, thereby removing the capability for
 miners to claim more transaction fees by lying about the timestamps of
 their block.
 
-This proposal seeks to ensure reliable behaviour in locktime calculations as 
-required by BIP65 (CHECKLOCKTIMEVERIFY), BIP68 (sequence numbers), and BIP112 (CHECKSEQUENCEVERIFY).
+This proposal seeks to ensure reliable behaviour in locktime calculations
+as required by BIP65 (CHECKLOCKTIMEVERIFY) and matching the behavior of
+BIP68 (sequence numbers) and BIP112 (CHECKSEQUENCEVERIFY).
 
 
 ==Specification==
@@ -58,11 +59,10 @@ block time for the purpose of checking lock-time constraints:
         return pbegin[(pend - pbegin)/2];
     }
 
-Lock-time constraints are checked by the consensus method IsFinalTx(),
-or LockTime() under BIP68. These methods take the block time as one
-parameter. This BIP proposes that after activation calls to
-IsFinalTx() or LockTime() within consensus code use the return value
-of `GetMedianTimePast(pindexPrev)` instead.
+Lock-time constraints are checked by the consensus method IsFinalTx().
+This method takes the block time as one parameter. This BIP proposes
+that after activation calls to IsFinalTx() within consensus code use
+the return value of `GetMedianTimePast(pindexPrev)` instead.
 
 A reference implementation of this proposal is provided by the
 following pull request:
@@ -72,33 +72,10 @@ https://github.com/bitcoin/bitcoin/pull/6566
 
 ==Deployment==
 
-We reuse the double-threshold switchover mechanism from BIPs 34 and
-66, with the same thresholds, but for nVersion = 8. The new rules are
-in effect for every block (at height H) with nVersion = 8 and at least
-750 out of 1000 blocks preceding it (with heights H-1000..H-1) also
-have nVersion = 8. Furthermore, when 950 out of the 1000 blocks
-preceding a block do have nVersion = 8, nVersion = 3 blocks become
-invalid, and all further blocks enforce the new rules.
+This BIP is to be deployed by either version-bits BIP9 or by isSuperMajority().
+Exact details TBD.
 
-When assessing the block version as mask of ~0x20000007 must be applied
-to work around the complications caused by
-[http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/010396.html BIP101's premature use]
-of the [https://gist.github.com/sipa/bf69659f43e763540550 undecided version bits proposal].
-
-By applying ~0x20000007 with nVersion = 8, the thresholds should be tested
-comparing block nVersion >= 4 as this will save a bit for future use.
-
-It is recommended that this soft-fork deployment trigger include other related 
-proposals for improving Bitcoin's lock-time capabilities, including:
-
-[https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki BIP 65]: 
-CHECKLOCKTIMEVERIFY, 
-
-[https://github.com/bitcoin/bips/blob/master/bip-0068.mediawiki BIP 68]: 
-Consensus-enforced transaction replacement signalled via sequence numbers,
-
-and [https://github.com/bitcoin/bips/blob/master/bip-0112.mediawiki BIP 112]: 
-CHECKSEQUENCEVERIFY.
+It is recommended to deploy BIP68 and BIP112 at the same time as this BIP.
 
 
 ==Acknowledgements==

From 226bd097a9d5e03a9cdb1b3b00c79cd017c8983a Mon Sep 17 00:00:00 2001
From: Pieter Wuille 
Date: Tue, 1 Mar 2016 01:06:16 +0100
Subject: [PATCH 235/259] Add start time

---
 bip-0009.mediawiki | 22 ++++++++++++++++------
 1 file changed, 16 insertions(+), 6 deletions(-)

diff --git a/bip-0009.mediawiki b/bip-0009.mediawiki
index ff91ffdc..052c9da5 100644
--- a/bip-0009.mediawiki
+++ b/bip-0009.mediawiki
@@ -22,11 +22,12 @@ In addition, BIP 34 made the integer comparison (nVersion >= 2) a consensus rule
 
 ==Specification==
 
-Each soft fork deployment is specified by the following parameters (further elaborated below):
+Each soft fork deployment is specified by the following per-chain parameters (further elaborated below):
 
 # The '''bit''' determines which bit in the nVersion field of the block is to be used to signal the soft fork lock-in and activation.
 # The '''threshold''' specifies how many blocks within a single retarget period (2016 blocks) must have the bit set before we lock in the deployment.
-# The '''timeout''' specifies a time at which the deployment is considered failed. If the median time of a block >= timeout and the soft fork has not yet locked in (including this block's bit state), the deployment is considered failed on all descendants of the block.
+# The '''starttime''' specifies a minimum median time past of a block at which the bit gains its meaning.
+# The '''timeout''' specifies a time at which the deployment is considered failed. If the median time past of a block >= timeout and the soft fork has not yet locked in (including this block's bit state), the deployment is considered failed on all descendants of the block.
 
 ===Mechanism===
 
@@ -38,7 +39,7 @@ The highest 3 bits are set to 001, so the range of actually possible nVersion va
 
 '''States'''
 With every softfork proposal we associate a state BState, which begins
-at ''defined'', and can be ''locked-in'', ''activated'',
+at ''defined'', and can be ''started'', ''locked-in'', ''activated'',
 or ''failed''.  Transitions are considered after each
 retarget period.
 
@@ -46,10 +47,19 @@ retarget period.
 Software which supports the change should begin by setting B in all blocks
 mined until it is resolved.
 
-    if (BState != activated && BState != failed) {
+    if (BState == started || BState == locked-in) {
         SetBInBlock();
     }
 
+'''Start time'''
+If a block's median time past is at least the starttime, and it is consider ''started''.
+
+    if (NextBlockHeight % 2016 == 0) {
+        if (BState == defined && GetMedianTimePast(nextblock) >= starttime) {
+            BState = started;
+        }
+    }
+
 '''Success: Lock-in Threshold'''
 If bit B is set in 1916 (1512 on testnet) or
 more of the 2016 blocks within a retarget period, it is considered
@@ -57,7 +67,7 @@ more of the 2016 blocks within a retarget period, it is considered
 visible.
 
     if (NextBlockHeight % 2016 == 0) {
-        if (BState == defined && Previous2016BlocksCountB() >= 1916) {
+        if (BState == started && Previous2016BlocksCountB() >= threshold) {
             BState = locked-in;
             BActiveHeight = NextBlockHeight + 2016;
         }
@@ -132,7 +142,7 @@ GetMedianTimePast() of a block following a retarget period is at or
 past this timeout, miners should cease setting this bit.
 
     if (NextBlockHeight % 2016 == 0) {
-        if (BState == defined && GetMedianTimePast(nextblock) >= BFinalYear) {
+        if (BState == started && GetMedianTimePast(nextblock) >= BFinalYear) {
              BState = failed;
         }
     }

From 737bf29de2338d6f612533bbb9860a85169a3c33 Mon Sep 17 00:00:00 2001
From: Pieter Wuille 
Date: Tue, 1 Mar 2016 01:24:34 +0100
Subject: [PATCH 236/259] Update former BIP references and consistency

---
 bip-0009.mediawiki | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/bip-0009.mediawiki b/bip-0009.mediawiki
index 052c9da5..b10a91c1 100644
--- a/bip-0009.mediawiki
+++ b/bip-0009.mediawiki
@@ -18,7 +18,7 @@ This document specifies a proposed change to the semantics of the 'version' fiel
 
 BIP 34 introduced a mechanism for doing soft-forking changes without a predefined flag timestamp (or flag block height), instead relying on measuring miner support indicated by a higher version number in block headers. As it relies on comparing version numbers as integers however, it only supports one single change being rolled out at once, requiring coordination between proposals, and does not allow for permanent rejection: as long as one soft fork is not fully rolled out, no future one can be scheduled.
 
-In addition, BIP 34 made the integer comparison (nVersion >= 2) a consensus rule after its 95% threshold was reached, removing 231+2 values from the set of valid version numbers (all negative numbers, as nVersion is interpreted as a signed integer, as well as 0 and 1). This indicates another downside this approach: every upgrade permanently restricts the set of allowed nVersion field values. This approach was later reused in BIP 66, which further removed nVersion = 2 as valid option. As will be shown further, this is unnecessary. 
+In addition, BIP 34 made the integer comparison (nVersion >= 2) a consensus rule after its 95% threshold was reached, removing 231+2 values from the set of valid version numbers (all negative numbers, as nVersion is interpreted as a signed integer, as well as 0 and 1). This indicates another downside this approach: every upgrade permanently restricts the set of allowed nVersion field values. This approach was later reused in BIP 66 and BIP 65, which further removed nVersions 2 and 3 as valid options. As will be shown further, this is unnecessary.
 
 ==Specification==
 
@@ -35,7 +35,7 @@ Each soft fork deployment is specified by the following per-chain parameters (fu
 We are permitting several independent soft forks to be deployed in parallel. For each, a bit B is chosen from the set {0,1,2,...,28}, which is not currently in use for any other ongoing soft fork. Miners signal intent to enforce the new rules associated with the proposed soft fork by setting bit 1B in nVersion to 1 in their blocks.
 
 '''High bits'''
-The highest 3 bits are set to 001, so the range of actually possible nVersion values is [0x20000000...0x3FFFFFFF], inclusive. This leaves two future upgrades for different mechanisms (top bits 010 and 011), while complying to the constraints set by BIP34 and BIP66. Having more than 29 available bits for parallel soft forks does not add anything anyway, as the (nVersion >= 3) requirement already makes that impossible.
+The highest 3 bits are set to 001, so the range of actually possible nVersion values is [0x20000000...0x3FFFFFFF], inclusive. This leaves two future upgrades for different mechanisms (top bits 010 and 011), while complying to the constraints set by BIP 34 and BIP 66. Having more than 29 available bits for parallel soft forks does not add anything anyway, as the (nVersion >= 3) requirement already makes that impossible.
 
 '''States'''
 With every softfork proposal we associate a state BState, which begins

From 8315dfd3faf8c2af74ac6185269fcebc89d41c26 Mon Sep 17 00:00:00 2001
From: Pieter Wuille 
Date: Tue, 1 Mar 2016 04:05:48 +0100
Subject: [PATCH 237/259] Rewrite state transition logic

---
 bip-0009.mediawiki  | 224 +++++++++++++++++++++-----------------------
 bip-0009/states.png | Bin 0 -> 24827 bytes
 2 files changed, 107 insertions(+), 117 deletions(-)
 create mode 100644 bip-0009/states.png

diff --git a/bip-0009.mediawiki b/bip-0009.mediawiki
index b10a91c1..856db7a9 100644
--- a/bip-0009.mediawiki
+++ b/bip-0009.mediawiki
@@ -24,140 +24,130 @@ In addition, BIP 34 made the integer comparison (nVersion >= 2) a consensus rule
 
 Each soft fork deployment is specified by the following per-chain parameters (further elaborated below):
 
-# The '''bit''' determines which bit in the nVersion field of the block is to be used to signal the soft fork lock-in and activation.
-# The '''threshold''' specifies how many blocks within a single retarget period (2016 blocks) must have the bit set before we lock in the deployment.
+# The '''bit''' determines which bit in the nVersion field of the block is to be used to signal the soft fork lock-in and activation. It is chosen from the set {0,1,2,...,28}.
+# The '''threshold''' specifies how many blocks within a single retarget period (2016 blocks) must have the bit set before we lock in the deployment. The recommended value is 1916 (95%) for mainnet and 1512 (75%) for testnets.
 # The '''starttime''' specifies a minimum median time past of a block at which the bit gains its meaning.
 # The '''timeout''' specifies a time at which the deployment is considered failed. If the median time past of a block >= timeout and the soft fork has not yet locked in (including this block's bit state), the deployment is considered failed on all descendants of the block.
 
-===Mechanism===
+No two deployments may use the same bit if they have overlapping starttime-timeout periods.
 
-'''Bit flags'''
-We are permitting several independent soft forks to be deployed in parallel. For each, a bit B is chosen from the set {0,1,2,...,28}, which is not currently in use for any other ongoing soft fork. Miners signal intent to enforce the new rules associated with the proposed soft fork by setting bit 1B in nVersion to 1 in their blocks.
+The starttime should be set to some date in the future, coordinates with software release date. This is to prevent
+triggers as a result of parties running pre-release software. The timeout should be set a reasonable time after the
+starttime. Setting it to 3 years after the starttime would allow around 9 deployments to be initiated every year.
 
-'''High bits'''
-The highest 3 bits are set to 001, so the range of actually possible nVersion values is [0x20000000...0x3FFFFFFF], inclusive. This leaves two future upgrades for different mechanisms (top bits 010 and 011), while complying to the constraints set by BIP 34 and BIP 66. Having more than 29 available bits for parallel soft forks does not add anything anyway, as the (nVersion >= 3) requirement already makes that impossible.
+====States====
 
-'''States'''
-With every softfork proposal we associate a state BState, which begins
-at ''defined'', and can be ''started'', ''locked-in'', ''activated'',
-or ''failed''.  Transitions are considered after each
-retarget period.
+With each block and soft fork, we associate a deployment state. The possible states are:
 
-'''Soft Fork Support'''
-Software which supports the change should begin by setting B in all blocks
-mined until it is resolved.
+# '''DEFINED''' is the first state that each soft fork starts out as. The genesis block is by definition in this state for each deployment.
+# '''STARTED''' for blocks past the starttime.
+# '''LOCKED_IN''' for one retarget period after the first retarget period with STARTED blocks of which at least threshold have the associated bit set in nVersion.
+# '''ACTIVE''' for all blocks after the LOCKED_IN retarget period.
+# '''FAILED''' for one retarget period past the timeout time, if LOCKED_IN was not reached.
+# '''ABANDONED''' for all blocks after the FAILED retarget period.
 
-    if (BState == started || BState == locked-in) {
-        SetBInBlock();
-    }
+====Bit flags====
 
-'''Start time'''
-If a block's median time past is at least the starttime, and it is consider ''started''.
+Blocks in the STARTED state get an nVersion whose bit position bit is set to 1. The top 3 bits of such blocks must be
+001, so the range of actually possible nVersion values is [0x20000000...0x3FFFFFFF], inclusive. This leaves two future
+upgrades for different mechanisms (top bits 010 and 011), while complying to the constraints set by BIP 34 and others.
+Having more than 29 available bits for parallel soft forks does not add anything anyway, as the (nVersion >= 3)
+requirement already makes that impossible. When a block nVersion does not have top bits 001, it is treated as if all
+bits are 0 for the purposes of deployments in the context of this BIP. Miners should continue setting the bit in
+LOCKED_IN phase, so uptake is visible
 
-    if (NextBlockHeight % 2016 == 0) {
-        if (BState == defined && GetMedianTimePast(nextblock) >= starttime) {
-            BState = started;
+====New consensus rules====
+
+The new consensus rules for each soft fork are enforced for each block that has ACTIVE state.
+
+====State transitions====
+
+
+
+The genesis block has state DEFINED for each deployment, by definition.
+
+    State GetStateForBlock(block) {
+        if (block.height == 0) {
+            return DEFINED;
+        }
+
+All blocks within a retarget period have the same state. This means that if
+floor(block1.height / 2016) = floor(block2.height / 2016), they are guaranteed to have the same state for every
+deployment.
+
+        if ((block.height % 2016) != 0) {
+            return GetStateForBlock(GetParent(block));
+        }
+
+Otherwise, the next state depends on the previous state:
+
+        switch (GetStateForBlock(GetAncestorAtHeight(block, block.height - 2016))) {
+
+We remain in the initial state until either we pass the start time or the timeout. GetMedianTimePast in the code below
+refers to the median nTime of the 11 blocks preceeding a given block.
+
+        case DEFINED:
+            if (GetMedianTimePast(block) >= timeout) {
+                return FAILED;
+            }
+            if (GetMedianTimePast(block) >= starttime) {
+                return STARTED;
+            }
+            return DEFINED;
+
+When in STARTED state, we tally the bits set, and can transition to LOCKED_IN if we pass the threshold. Alternatively,
+the timeout can trigger. Note that a block's state never depends on its own nVersion; only on that of its ancestors.
+
+        case STARTED: {
+            int count = 0;
+            walk = block;
+            for (i = 0; i < 2016; i++) {
+                walk = walk.parent;
+                if (walk.nVersion & 0xE0000000 == 0x2000000 && (walk.nVersion >> bit) & 1 == 1) {
+                    count++;
+                }
+            }
+            if (count >= threshold) {
+                return LOCKED_IN;
+            }
+            if (GetMedianTimePast(block) >= timeout) {
+                return FAILED;
+            }
+        }
+
+After a retarget period of LOCKED_IN or FAILED, we automatically transition to ACTIVE and ABANDONED, respectively.
+
+        case LOCKED_IN:
+            return ACTIVE;
+
+        case FAILED:
+            return ABANDONED;
+
+And ACTIVE and ABANDONED are terminal states, which a deployment stays in once they're reached.
+
+        case ACTIVE:
+            return ACTIVE;
+
+        case ABANDONED:
+            return ABANDONED;
         }
     }
 
-'''Success: Lock-in Threshold'''
-If bit B is set in 1916 (1512 on testnet) or
-more of the 2016 blocks within a retarget period, it is considered
-''locked-in''.  Miners should continue setting bit B, so uptake is
-visible.
-
-    if (NextBlockHeight % 2016 == 0) {
-        if (BState == started && Previous2016BlocksCountB() >= threshold) {
-            BState = locked-in;
-            BActiveHeight = NextBlockHeight + 2016;
-        }
-    }
-
-'''Success: Activation Delay'''
-The consensus rules related to ''locked-in'' soft fork will be enforced in
-the second retarget period; ie. there is a one retarget period in
-which the remaining 5% can upgrade.  At the that activation block and
-after, miners should stop setting bit B, which may be reused for a different soft fork.
-
-    if (BState == locked-in && NextBlockHeight == BActiveHeight) {
-        BState = activated;
-        ApplyRulesForBFromNextBlock();
-        /* B can be reused, immediately */
-     }
-
-'''Failure: Timeout'''
-A soft fork proposal should include a ''timeout''.  This is measured
-as the beginning of a calendar year as per this table (suggest
-adding three to the current calendar year when drafting the soft fork proposal):
-
-{|
-! Timeout Year
-! >= Seconds
-! Timeout Year
-! >= Seconds
-|-
-|2018
-|1514764800
-|2026
-|1767225600
-|-
-|2019
-|1546300800
-|2027
-|1798761600
-|-
-|2020
-|1577836800
-|2028
-|1830297600
-|-
-|2021
-|1609459200
-|2029
-|1861920000
-|-
-|2022
-|1640995200
-|2030
-|1893456000
-|-
-|2023
-|1672531200
-|2031
-|1924992000
-|-
-|2024
-|1704067200
-|2032
-|1956528000
-|-
-|2025
-|1735689600
-|2033
-|1988150400
-|}
-
-If the soft fork still not ''locked-in'' and the
-GetMedianTimePast() of a block following a retarget period is at or
-past this timeout, miners should cease setting this bit.
-
-    if (NextBlockHeight % 2016 == 0) {
-        if (BState == started && GetMedianTimePast(nextblock) >= BFinalYear) {
-             BState = failed;
-        }
-    }
-
-After another retarget period (to allow detection of buggy miners),
-the bit may be reused.
-
-'''Warning system'''
-To support upgrade warnings, an extra "unknown upgrade" is tracked, using the "implicit bit" mask = (block.nVersion & ~expectedVersion) != 0. Mask will be non-zero whenever an unexpected bit is set in nVersion.  Whenever lock-in for the unknown upgrade is detected, the software should warn loudly about the upcoming soft fork.  It should warn even more loudly after the next retarget period.
-
 '''Forks'''
 It should be noted that the states are maintained along block chain
 branches, but may need recomputation when a reorganization happens.
 
-===Support for future changes===
+'''Implementation'''
+Given that the state for a specific block/deployment combination is completely determined by its ancestry before the
+current retarget period (i.e. up to and including its ancestor with height block.height - 1 - (block.height % 2016)),
+it is possible to implement the mechanism above efficiently by caching the resulting state of every multiple-of-2016
+block, indexed by its parent.
+
+====Warning mechanism====
+
+To support upgrade warnings, an extra "unknown upgrade" is tracked, using the "implicit bit" mask = (block.nVersion & ~expectedVersion) != 0. Mask will be non-zero whenever an unexpected bit is set in nVersion.  Whenever LOCKED_IN for the unknown upgrade is detected, the software should warn loudly about the upcoming soft fork. It should warn even more loudly after the next retarget period (when the unknown upgrade is in the ACTIVE state).
+
+==Support for future changes==
 
 The mechanism described above is very generic, and variations are possible for future soft forks. Here are some ideas that can be taken into account.
 
diff --git a/bip-0009/states.png b/bip-0009/states.png
new file mode 100644
index 0000000000000000000000000000000000000000..7b3139efe40652d75d9a93408eb2466544823ca5
GIT binary patch
literal 24827
zcmdSBXH-*P^eq~i2qH+4A_5vI(m`6l0G6P1L~07N@FI(=f}X3E
zgN3Wd3ukkfhlhudwY{y2=?h15AqQv6)HUQa80-d233Xo^leRMEk)}Pjd$8H3FC$Qj
z4N=s+!k~SHOjCR1&y)9XD*-)t_4A_pw|=8~bhDKP^FwK`ekn5vy~
zJ3f`M?cus)d2Q?7L}%
zQbNdkSa`rVbfi^0BO3IHbBKu9l(IkTp6z6W5&28XXfAeBRlW<4Pih$6#wC*2XCSB@2E}
z`K$WWW?lwns(L^4mBl3ri5l4}wvTCf$)d>jh-FCF0#(B>~>p1+<%?S5}ITxtd*DQea33Or^kJ6LwqO0&DSkx`vuzXvTMLc8rOj)|!n3*rHqhv#}}r!Bz-PN5xHxIl3lG4ccQjU1>rT;?nQ7m2%<
z>FZBSt&KOgZZp}!N>s6!(#7;X{J4w_4`@X1uK!XZzlY9)mKJdi0iW61|FGp9_A(F^
zg7HMT{`{C4MEfhbIy}BrM+~cBY(YEiL@O_fzZd_IqnK7|(gl<)cqFoyGMZ0VreY_Sa!R9`7
zJ+D+8xqZ8HYJuMi5wY*-?Y@RGlBY1L*#F)SRpgl57RYQ9qW~XiSYeMAAP$k!?xJ;Cu8!E$@nCq{sIN69w+__PSEKeN5mWX<)}4s$I|r_C?)If*Oab
zHS1UeL(J%Np*i>+B7}@hyqn1Fdjy~O^|to>Eng~Az|d=TN%l4^iA`6=7=t~e#)~pz
zySBKHAKZII@7lhLJw|^qTQY$=U)bP?Mz5mXoN{|j%lr7)X9{z20)6)**A&fEeV+TD
zN?g5qHCb+jE_3d)(<40*vTtFi`0yx6
zplofhE$KlSU7n?3rK-lTN%;@DXwlpo`7RHS$fMCZn+(h<;AS68<3}y7Y6K7>1TUv?
z`o*GYUJ=3_1br`@F8i)!LhuF3P+i@+wt&Yk`d@~&Gixa}6zjA2n{=2Z5<|ahSRM}Cg{SFE
zTjY;qF`jwJ>_?H))8WGNO~-55#*JQ6bAPMt!oN6JeR&7w-8yDDTyEa9@TbPDNeQ%nyk?Svoowc#Q+deVvWJ$8#?xTOC>_!;Q&LMQ+bems~#Lz~b{AuXK>6(XA
z^s{?K1)nbxzO+!c#Q6RD_agphK46|?_Y@S!qLEt{`E`mW<8_TU$7*bcidV|Jh0qB@
zpACmxj{EzcdhM;~n|me-70?tTZ3b`49sSGB+5hX(C);1;RFK>bvZp%(u1kXy*u{Z7m&H$s
zcdYw4VaC3@Xk*M28L-q+-8!4c=vQ0-3B8rLI8?Hrkd
zeu>ZhJfEVKTi#ygZ#_F&E^%qSs#|Iny4}$&STp*qATJ|Dhpy+=??D|>5UqJH%6jcg
zrhAMRXj7bQM*IJGfjV2l7e21A=z%RXssD5_zRWCwb((3@EYuN%Rlgek23D8Vib~&1
z%}xPF7tPBY$tpGf`jXJa=1f^{Ny8fZ-BI_Qf4_E?hf4ZwXFFn=+B4++{o+@TcbD7W
z^J>LLRj8-Sj5@Yl#%dKbZhX6>w0b`IhDIlJ2KcJR67$#>kA;8P9_qiPP1_=J_WDdC
zkqLHNdKOzr5>?5s>4uFeeUIJeeyH)bS3m;%!ovHqYi*INhqG}Skihv|;-H0h
z6IiE%<>%*J{hw4=WWB`ST)3=^nIOBwSZeb1wQ{#XrB#e8)w6onDRARNlYbqW)x6G;
z_+O^OA3wYiSp<8Lvg>GfnZMCtuw$7-q|yc-*5BW++&xm`ue!uAJ
zfzYW0L;I4l#b0z5FN`&KZs(YWoES^I`XjPb|-rYolq>N)!
zLFRr?%|J?@oCBZeFMf8nZsMIRl6)^W?`D>=H!@l9JD3VimUgi?@NM!hp&O)Lr|C|>P)4AE1AaEB3LB}i
z6>}Izj(aY!fq4d0~GC}xxFEC~DT@NAC_Ncj5rsq^86Q#CC7JR
zmwXaZk>;W8vx3bUi(Fh>qaG8!qM0fzqAvp%wk$J!6JE5uHRo(Xgarzd4Z^*-2C
zG#ow~_kR@sI-CbPC+~T)UqD91qsVJi*Aef){O?S8tB~Oerw{efQl#vmO5p^Pfc+S1
zXkW*5(gZFX1a|P+UHVmRXISsCt`1_6?7rP-tK-rnjK4xZTm_ba>q$k3rtV(m?C48?56t!NbL+d2pq
zN{wE-`Oll>(q-H}dhf4gJiKrf0V4Xo2jx4`Q|&5VD)^l*U^k`@6+cT|exgdm$IovH
z9Kl6f;?~Sgh$2NPofTu%k~R8Njl1{7Yg0nre(*CKQX)6;`5BP3L&%*Bujzdfnpv$F
zxNrTJTmp2b50%l0o&r*yy&y$#mxOi{;{wLT!uu~GewpGi=rKlDB)1r0RH!3+;kcOenzulWMK!TSXnPW}6tnq~
zTRkmlSp@c{+K!dv0@dWN#~eM@*X^rZ;@ctT$trA%D2v%GCT0!z9oBzFU)=4E$wKK)
zrRb$y)%e_3{(OyMyNg2QqYHId
zXtX~XT@q+U8OX&xql7XhlbMx?LJnp?YVym9c1LqE_gHT@|NDo>^=lJ%zZ(nqx2W!a
z!B2Tg?-E*KbNB#Wi|>8#!FmvKHlaa(mT?H=WtLRT-+aGBmi;HR!xmQnsvaHuKrFJi
z7{T=WNV717IInOiui$a=HQGA%gNk-&9ie(n17O1MJA|kZId~U1gfXQ
z{4tG(MTaUnR^V5~$u?47PD85tGn9?#}_y3bT(qpx3Hjq9CqpH>;nL*_&(|b1Qs5?FB}c!oAN(@)WOGjRNto7_%WVC#Vl~N1
z>#2zP=>3gL0abh<(!xJH|owz26UGZ^FM2Y0QY1aZT%*WE>k%zMtOFS*CIguUNM*
z34xko3@W)Z!KUG+7*3t+;A!1$kC5y<_J6j)C
zax;SijB17^zCD2UU_y71O7%*Ne7IuzB%H)8;;ZNHe>!Opcbo+**s!119&D%1htLtH
zqfoCewXlSvSBn}`%yW
zX%(XCd9SzW|M(C)N^Lyv`NdK5mtxA%L^v%hpZ+JE-W#!_JsT6D4G2>2Q;6WMA$((?
z5obn-OD1+;@dKJT)&Gsy_aECtQMc_>AApl;5^)yfK=RD#!mo%tRuRU7`=~Q+xG(1z
z%W_2L6;R_cTtPp}gBD15rnDtCSKf-%^eo^W)bJSXziP8mMFJD>-h+;wo5-hGGz-&>
zerCJt{jG;F=I@wt2X~-&Ksne20nV8Pp3l%UZ7gb&Z#do8sUq460{v)Xq)@Zxp^6Q(
zWD!cKpcD?nLVo#BJ8>g+XoG#bN8{n7*<=ZB2wrZ4%D4*RLXK_1{Fo>{Y1c-Ko1$(7
zpFl-B%*Om$3}#tRlXOPuL#9fSTYuiGgKmzw8WGwFd{622`|tEhC>hwpfES4UpgT9;
zM?47ah>cN70$&&VBqWq4He@AIi!5FJg!W_HF26{6dZ-njNPBEdC?Vu=GI&jga>Bn%
zyDDF79I>1dXLaJs7Iup5cbzmuk0k`TBon{*?=r3FP;R*Q6KUGj*iTw^t)3UGy}sM#
zLiRuU4^=bD&W_udVcNUiY4`7*&+VBllkT`aC$BAe#DYMthRg(MhjbwMc(O~hcNeJA
z`es?c8CL0ms4jA|_TieVnI)X^)G(oSKSI+G
zveMa$Vo-jhCgwWwdu{oB$o47KNuRG8EO%Ho``b%!ZdA(ey{d5sl_PtXUXx}Y4_C?K
zC(oVa%%Z@d(9cpoxg=AShP5-tIYIRo^++488*sw~o#>u;xN~RAVqG8i6bFl)_f4%G
zQ_>#N9SCnQis0*A7nleWeT_yYbHO7W=`_vmjF9KYe;qiXYKV*r9Ivpsy-#pGQWfMd
z54_5W-9A$F(J{#<7Q~5rT7c#R@%R(``W;8rI8NYVoL}iQ>}zG0>WPAhe8+TCsjhon
z+u+AmPMD(D&uPQ{u3mb>(OT=VF$
zf-iOkOCKP_%Wfl~?y<>(c2j=)O^o(c#${7g%_sO>=%^Sn&W5~ac9OnOE%>Q>(goYh
zuSw~nnrLHO>=J(e06rVRs|?jYL7!(qJTu6jUc?))(i@>Iu4Eao`LK>w`*!j;Zo={J
zV;+=>-ep5KK1JW1R*l-HnM@?5`9*|b(7OTG4O47<)oQ>-IM!+3g=F;6!XyU7mavi;
zSCNoBi47@}tPmp}c=EsLXRCy3a!@GBriVe0JsPj8y{rA<>c-u)x;N9-L?;}jdMH00
zxI{UNWf{mSP?gcBxX@cx{F;k|KYh%r$Yw?a`cxl%o(stayul7(F=KwI#QP-l3Y=O4
zVN9~1Vy*w8ff8bfQKkMht%R}(?Fhp84$JAnj$n39DFtCskUAP4fVjooaPd3q^6Cu}
zC}i{|+^wA5Bmkg2(3d={Kaop$JQhyZdwt(X!~E#Fw8)=R4@LFtjyvd619b58jy>z8
zm5?$|!Ab5(ep+eqkORtiE_SWY1xwm#3rLxFQ>3#ojxv+TtMU?KrVFuue@J%tdh3Zw
z)EsK!haoTOpDdV&KWw!1u*}d7lHZ3oLO7WG9diDd`@^NDbsV?g5(=}#d_31nT&_ZL
zh{i9ty0;AGE~!lDXCEM@sUP2u3?kIXYOg18!P`mcjED$EY7BvRo|30&RJ$mcq2Lr9
zYKU9dy0s>@kCMCxHtiCKC0|Xc8c$6;*P85y`?zxE)M~PE+L-Rwp+zEp^z7PTaOWGn
z0ttRiMLS?924#O{6-$wcd1jlEuRguo{ZH{OpeQ4eP}azcW4BK2(v#k;ajz
zjHl|D)v-!V*%E{X5n4}r1aGfJGx23QJ;qf*kADfTx#7XE^KCu1Wa#WxZ0`E%{?q6wcaUmBF+^3i|>&vK7&s;{hI5OPBA}uepJz#)gbW
zZ@)9Ij7IM&X8P`t3K2b;MDEjdYp0QmJ=etR$#!hTrW!e1C?+{cvCJdM%U_BPAWN_W
zTZ#VWSBOWy_30``q9RD!+MYgU%<011b;T9#+rksDyaJm$Bwq8EX{8wtXnuBB#&HD1
zp?3=>KX!5auEQmD*$ciio&WX~!^7rS%#{~BUOU#&?3T!t>WWLYb1e_K9{;ULIuBYW
z35JFHN?HdE%*hOJI8(j`>j^*Daa4I+wqy1NKtE6sQ;Z~hi>S9Ts?9p1gmYHXdj1M4g9&n@B#P$%_kk
z&P7&A@vjgXppTTwtkt@WR6{8+o0B-Aviy7tKv+w<%~IqQRxq-twvt2AyUVH5uOBfm
z=i`AMdx+N1#@|9$UH-|0nXqg=!r8*hZOiX3ke~(IJ;xV}Gu5sUJA^A16(1lE@F=1fHAF5wp6~ij@TR7jIjPl=kk;N%c%T
zIk7OgsM=#8{Z>;|DqbB~1+7(BNJk@1f(0>{h*QC-Y-aR1EmZ1b2UZbJHMM17@GXR6
zQ{Pe7^(_JLWLDa(($r!z@uej%&CI5L$gD
z4;!Jg=h&NMZNMx}ocg;AhE)TsN$=+dd_u*#7yRLIPb3PwmPk0J#4R8FrMzwwF;=t+
z5YWxBluve-?q8vCV8^=jnMQ={To%;E3*yGu{|>>W-AuNzD1^zic!pF~LF~m44QH&Y(fOvnv9@Vi!ICXTzL|8x
zf!3PV3^`1|W+}q7b{WuBBsbuf0`_>p^bT?D7UB$%OuvF)Ruglzw~C2n=Nq&Vc)2b
zBTmxZ%eodqW;yla$F)^bTHXWuSwcB)HkLA3{y>WJ>*|BfdFK!4w{dEmCEv9!A>b_w
zoznXce+bGIu3w26x!)Fd8B}XZue~)79KL@%XEdyu33Kz$BR&Z1>YTq>@>O2!AAQ<_
z!AG{#R+styOeZ?8$~|0%$-_?Mmv&Rt*pFV`yE^#Jx(J>DAFqlanTvsI!)9Wg2d%rJ
zX#O;PXhiUz-s>CiF)WL=;1!*zh@Hlp2l;ne0J0rB%bil=WWUFV?sp1G8GaDoV~&Vd
zYliWq>d9^BRoC3zQT?Tfcfj(<>Z}qQF*zbw%&$goa>B*1y>(HyqJ!irJ$pVs{bw`%
zgU(>;EEST5>isPq5YtMNtQX@~wcV6*d*d`vIT9i?`K(n-x+WUvXS6=ri~L<0l-#$L
z046xNI9LE!8xbTKS2+aD%5@sVW8LnTk<|qm_pLc@Z*iCHVlkIOV<%ksM6#
ztTg%W3t}bMyHiNn71l6l*~EA&FOa1LKh92Pa=dO0vL(Q-
zC6Ec|)bH64>n3~Sln8ABlPj_S6hd3SbJbEy$!l3s3)
z02@4{k!A3c2jE(+Mkc$T|A=*-)Bc!;_u5?(9BjTf-OySefLVXshMrlE)k|2WyD_%2
zd0dCNEcBY=utc3c!#+ogd9Nm#(gBpsw^lvV9-Rkp1z5y2iLfDK@5?aSEcexs|Akcp
zzz@}zAzUaQp@k+(j
z1)8q?D(5+6G@4D?*=*GA)^mV(T+Fom^-+Nj9{*d)epIi!yIXc<>Gx;D(V0x|wK@or
zahd;-Gflh$0Np`_a7M1m)o($UTAb2ddZnFe97ZY&HK$mGkpAs#AKUj)@NmkQO|WYlNvS_^D?&ps2V(x3GlG%0Ad6_92|6sX{(bbQ^c}2
zZR4nMZzTLy)E{XH6;Ds;IG**iEEBK;^0&R!zeE@?CV=cn?Z6Znm~as+VizMlhZ;Oxzxk~)@&}UXz#j@dxIlpRBESA~0wXJ}=+UL7J#&kC8{x2)o%U;ZFNqYh^1L%Le
z+^H`>IGYv#NUDYT0xps|Ij2`ge04eQ2wNZ^)x!SZF8R~9zmjw8jGpIbM^QS6VKz+q
z>^|~m0NMjDb@r|!EbnnN`_$ZB_m!VuF^p0rY#EK4yM?|47Pj6nE1Rx+17+?cS{xw{
z&xqf8`EW4&i&_3d=c&Iy9LFT-Fn;~)93ap9XsMgB-g`Tz-!t<=>3Qw|R26nj+zK}n
zEzfSeKkmI==Hof-lC}#tl9=?KmDRsB8vNC&yu7?qC)<4soje{K3-X(`%GE&viwl@oc^H
z>Eg|EoD3i@pYS^-Dm87V&hVU14veY*>&fo3@%3k(2JpV_n8)nNG0a5v^^4p9s?}X|
z1JnbzTST0?OsLQ^_g-ZY0L4eNCO*6@n_#!6r!zR1OgZHpjb=&32&W1FPjlS)_1FdA
z#b^VtWhXWVwKSa04i^R>G{1erX4{5ry!NZ%@*pPTKhkz8|1#Q3U$lJdhSSF-mYKFc
z)zNu0kgIms!f^(>x6qsJx!$;cXT~&;1U~``bfRk${ls(({q7%xf=K
zxKAF#Gw&^6dlkdL3lPYywj@zg%v`)K0x(X6M&D~3CVHQFjI|PYsIATRNLHq%&I!Od
zsUxOHVZF%kxyGgctp(Wru^|cQJ-1KxzkdNQ@2YoO&d>kjDSuqkd@2}xJ$9JrwPBTw
z0+<n`^SFdJXVr2)#^FVmJFXqfaLh;P={^nepC
zf!$*-Y)DCi-f+k!073y6CairnsDqL?ja>YAXR&4CY)`5f(3KloX7*=~4a#1Utv4Op
zADj+7_wVV5xz$qgq@M@_wySUIPQCkT*Y42szU7kU-nqo}w6!zftC9M=bKd}LtzTt>
zKJd*gEWd6QydCH#u7bQPK_4R%@HiG6#JPn}wlmLXfeX%lt{I11e@&E`l4ts#c^>$-
zM;QwWZpv=|5TlsjFsO6pa%etvA6*3=o3U}580@pjHdY5!UP)mPEX)tL=FrA5jpuN?
zztxd|ZrEO}nb_*$FL7KcYj^IG-47hv2WWnmY$fsReoM`FE&c9$*@^*N>~Tzde0-SW
z)f#EQ1{DApoxt$`8YByl1P$kB$5X57a)-0;qd11GO}>ZF0s<+wYk8xEW`A^CgOFkX
zUDmQb;kl5mOjDLS19o8^U>VWISvQ?O`fm3~RlXXI1q6t58;d1a2#&xZ!qSPFwmo_J
zbi;qmnC%jdPNTBH!JhwM0;P2wq%npj5qoe4(k}BNPSYq!Kthhs=ftTiFP`;+7|A!b
zj972jzRk~HxOGj=2ZKqKn(&E}ux-foD_8-P(npX2ruJ*b+ztCT%~b#+fY={(Ib13%
z`8QhUQryx>S`ubi1r_h>8M9&BgkbqHvkDnyy=2_NX}){IJL?mffJ;f_)yf6oKv}26
zSPgL0ASX@(o-9f_!~$%n+PMV7Z|iqm|6Msd2l2gS*=DF%ZK7$s@6Tm+WD>abpotQ_
zve(>dDUKi{yj>?^bHowF?-l5lu!E2=6)xNaOZzGVxK-@}-Epvx-7kXKE`Y;G!~6Jn
zbl8N38F>KM3~!s&X|pVPQU(ikqX9cp@4EP4e{C%M6OUnt?sP#ho*JibvtemKeG!e>-5^ms71zuu~qo%cv8W?00JZsTu1;kN=D7VUymRpJ?)&mqleeaJ1
zYCydsYQ1G+@%N(YMVWWVf!~&g!U2zBhzTP$aKS$zu4+_nLMi+Ecgl+z+sjvR{n#1B
z6hdt#_l5ZOwx01=>M-u^rhq2CAu|R~7hS;E7Qxa|HDsK+EaLObd$lS)*Sg~q+g*1N
ztDheN+X}n6X{|3}PJdRz#^3x#3$My12vW&}X#eRTBS;x8$beb`F_e{KxBUC_`@}?&
z-UD;D<=;I{sCc{ahGalA!+NhEt89mQt&wwcbFaphBHEtT*gsnuRPuX&3a%u|k#G(O
zIUzd8ZimRxyJ6bVh5{%v#!`*J>2~eik4E3)s8|bo4i4GBF}-{6oB5C6jzxEZAc*O6
zOp^32xO93e23}CEhDCXQ
zJ(D_9vMhy~*sY$hk1}7F$@Dp6Guv`{EG~E9eBqutS#G#ui9qlcVqA9k%o?wr1o*S7
zNsDF3b>L?TTDCnimO+*R0Sm_t|xd$LSPNLrYG
zdjL5aZ@ZRk^BA>6a_n7ng#4%X6qND|WVF(W#E|PpF1^DvRug16wh6~1DtVXoKpk~9
zJ)WqP9AZS(KsC6bCwsNS`Z4g^OY2cDKv7Q-=6&BU?T?bBQK=?ZU!F^wz&@_4ZGa#pn{e}eD
zXT4Z;&YI3eu7=>o64;}Bn-49NAswAK`g;|KRQqp>UZ)Jb7@Mnd?Y1;j#!`l))mOMAMgr!M8dI;_k9{_
zN%Zzw3f|V&o=di{fRu2Y67KRfEytZ!IV2>4tT)QQh+141-7LDd6$?`2KH&2Z&pc0K
zd!L{MYc+feuEYf3E*Zfm=}D%DJWMISSdqq(;;t5{OFR3LqkR}g?`TPa-WU85y#
zx6gX)HEJisw2XvuZTg8UD}!H~UXAWFOmIEXpVRUUQ4}@3n|J*dV03=49AbitE3$;+;AAUN
z!aeA*B|9v7P#n_1g4+f#*Ih@xOv~4iU7Qb5HY9+H1ELw29pExIG|i)cn7~qC(Jc5_
zcKgeM7D=HG<<}>KRP~rrb`j{_xF3TzGtqKEDyUpy*=$A!vXO$Nt?PmBHNkXnp&gFk
z?Pss!`!-Cn?`(#2+|*W+feAA{>?a6^OxA+dcu(SbMO0*xXZ(bNr!svq%4g#|>^Jn!
z_U~nPzyW|5pd_+*!t*B|BBx~`MF#s<{FR1|2}Gk
z?$dFDxwv)|3fp{8)Fj`bR}RS7P8nL3w_NFIDk6temn8Y=hpZr>`nr+MnDr|2_|YpjhCd~3r|l$#CIy=F-vX%xsvuJqS2z_qF&IgVG__%|UdmsInX
zCb|tiWJAT&a?lF!O*2(ur3C>MnZx$elIw{xW1MG?MEUm;k%mq4Z-TS~UzrnV`(T)tQMynuI2o*~b=O?Z*2CPxc1nmO!v
z64xhY&6%kcPz>*v#UE__%)p`H{oFB;3OSgVhQQE&djR6KdR~S$$n_z8}Be$Mb(aFS=KvTMLa<_N0gmv;xN%@Lq{0~
zfge8a4+$pfva?v8ZThV6y2p-IHdA0xn`Eu;j`3WaRjUtQ@A|cSd2nm{W#&!)ugxv@
z@@0+^`<9xu6LUxsFi^$6aD~zEVDA7=;9_`X;?9L((m0JB$=08vzeSf$W8lu^ebpW?
zZ;U`D$!Nx}{H-*uj3xe~=(9h1jeqI#U3;r@v>HY;SBG=-4r`kY+aC!EwS6bq@P|KL
z)W1!;NOsa|YDgvo(B$EZLeKT53*L@$N2zOu`=Kp`POczanqvz86ypP(*w;}uE^R6!
zVKoX!ZLeEDdrVWgIL}WsG)s-`@J~<<)mDZ9^HBZxSnq{s@r+m&Djn1{B6*T3*=oT*
z<96_;mu|Nod&3-gdIP-&HqJ&gp5Q&o8H|l9!tzo!tt~DUT&8lYQ86nf*ya6k#rfs4
z_`Zs@^(%;GEn_C*+bi?cdj~vh*h0r#^39`>cAcRdl5wW1TBFkvc2smRf`3R~a8sjw
z)loR_wNFpBh|a+ce#Pms(1;v2c;zcV|T~v|bezCTWDzd22
zQzHLh8X#G7=q3;{=VDTRSH`Uh$jk96{ifx0?yv>Deo?&Y~D&
zG3l3{a^2&42eNwgHYG_O
znA-qy*2KiC-iho!%7A#c0ux4qwMDx!Do!M>ge;-AXCBt1&{q3ICb~2;)TH2pW!&egupPB
zggCWI5^ag~LUvkdCJg*duo1;56*3nxZX^j08=EO$f4bU}kne?C#BJlW_Xj@k60h|+
z^Y#7|&Wjt%AsIe@*7IJqiv9fz)#m|CG{RO8Zv}Rhc{r*$DeE!l~s_)t&!1f)X9YlyX3>G7Flk$ij+c>;m
z3`DlCpFWPDczNZg0dKTMPfaINe9o^`bb3`?ZC3SrO~sX(h!qwX
z)|OxE^Pv+_LKSn}Rk9KpZsbX(D9}c_ILc5r#4MUnMxv1lLL`mDemEuZgjW$I`N~!z
zKe;1Y=G@jLJyL?*lvcLH99cK=A^Sdc?VwgV4O*3K&^ZAV>iXrPN}-Am9y;=6X~#Yp
zm#nFq>Ei0&winxwn(X~~UAGOOi>-pm7S&J6Jt>mRI@@yiAnCPhY2G)p=4(-LPvoR(
zT5az?Ni)VuK}*xHXYp2tQ3Hx>Zin63I5xwAWl96NF6ApKs2gXYI-g49|x8TvR=12o1%|Rp7
z1d1KXC?Etb>Coo@mo`kFQTtK*2*Gt{(gQD$cqU@LDKj03)=X9EjWR;*wuhJwV@G
zkO}eOgu7rF>!Pw#@}mb#1>+YvwuTwdvXUY6WW$5MuUL%&m;{^Iq|$G{
z>)mXRkMHn086e)6z6rc$8bR?MoPr}n3924&uKrI>*hbm~NWiwFdjxGFGyQGC8QheZ
zKuwscet^uUhru9S$B>P|F{`Pno33NF77eRp#Nt5uuQLq*=&d!MpVb};|w%JCNtz78cI)+@5z`{vA2h
z5-bM9@X9JGM2NZfT1iq4?65cFH1kn+*Di8c0x>!jhg@2n%L4IFAZ*R>-O~q@z;}ru
zqZT0Hyt=)N0H{{o?r%dPy;2h*o^;ozm}g2#6qm1we*pM40P6ayY;`YCG2?)Uopt|s
zCeQ!;Y>HG3$Vp&#(q;lOm7oQo;MpG@2#>L4*_g8
zUF5|BfN%hUA%o$sVttv0Qqtry!-*lk*{E7Vn~q{5XxSgm|7tKf-`3s#x6Y)@q2a0
zYhMaq5g=<%c7GrykFREx_w&Jw4QR*%x~Nb7{JPk00Mg6Z7XdR+I-DOaWVVkPqjsd4
z4QX9~<*8(YfLB8XK7`xv^EDwXJKdGfkswRotGa*}Xq4rnc=wKdd^nkyv9lJbKEmXu2$nhqHWI8f=XjdwKJ&_Zxel(`6*9g6&H01`+&;DD{$o~CnaT*tEr+G(u$-ql5M=GtS_5lGX_)F`~$zDzK
zCxAvz?Q6&#njM@+%kJsbKDGJzfe8FXXnQDj&M=LVe!DjI#k;N4qUTx^xBy_Kq=>6S
z2b(j}8#ofJ^KW#ez&-B(fQ}k5iQOodKV8(wqJgmt<*Kp5&OpP(pNsw6b}|0J1UYn3
zMemkT;yOU#ImW$~KPwAfjoJ4ptoW#g1pJNNr~P*JW!YxU*{u%WCV*6LoYTmkI0Dss
zvMUu~>9ulIi9UdU<^$NT3^l7?O{aT?1U_d@!t~K}1#GBDKaRho;m(O4=nNrHtxEov
zLzzKy1Yp_-{0u?l&c7hi`U2P>qxmmjB8g1Eav}ldJhd83&DKTWZPw*aHXbGjJ-en@
z6vv~n7vc8xH5mm5p))7qy7Zm@iAJFRr1McN*(a;@O&>tX#*YWf#Xk-=B1rT>q-(SP
zvZ}*N(P}fGHVC-6cE97*#GlomTVx?lL$09QXLV%O;?L@6-IiH8SP-Z`A%lY8=wQw>
zATmvX_7!L_ydy~wEX?l77-%#gncR76)aWHKIeKYzqFEl`oEFWed!}Gp1EOBUeMQf{
zcIs_W`w`$6F>UogJD(FZ03`X!>&=JrtkmFsDqr%uDx_lIU-pOrdOGmo{u{o(@gTem
zYoKlm3SKVx3wFfFrjb+Y)fE8If{rHswQ7Kxe(o2z$my#kvD1Ei8n2zi3&Pc1(0c&~
zHk$!dM$usFVA4Bae{a8wMTRv(PwIH>CUF6S#m`tB*|`99!#(MWya?YExB3YyVR^PZ
zSP(bp1oGDNMPJEt>Prg0xIvy7&g(x0jIGyRtwF8hi-U6zF>+r#wA>rAAFB__lqK{w
zDT{(ur&Pc&l)A4P{4Rdh?bOc3R3T-k2r%|!gwspqg$RbRnPMQ0x8@k=WA|S93YfT#
z78>~c@zzd3VQ*?a*Q@l>M=>y#j1cou%r3c-d`0B>@u7n4&rQ6=iq>lNg{pK*z)R
zCx#Z#S$4(G#12p_*F8p^Sd{oS1&nIn$%D`{wGR>tQ%{OS_mVVVT-l1d9xzdv((Qug
zmoh;9Y#f99mKJmC@g0!*)*7~ZmH#p-^Sl8aEt?>%y`9)!85Ua%D`39rIz8OrDb}4R
zT(V{G#a$2((JuhOGi67JZaT_xpf}9qU}FjpJ{KJ4uhYmT(>Q|cGyt06Hjc&mka1uq
zmG&R{A1(3-HJ@xHWrh(tyLb7$Wy^YDf0
zEZetWryK@xsU&OwL4(tPn$)jCU15NlQz7u`vn~O6gD0oeo!?xLekDXC7xJMc(7sj)
z_ILd6RZvKbeDQDqQz~B1hu!?u2ZMn@RRDurLI}VLsGFewujyn<1=zv*(*iv~Hn4Go
zdL;A@q!G+9>aoy`C8cFE&ZFynIZAQgmI2+GO=wxE9M703TfjVMzU0@p`6ET5uz&rB
z|M~IrXB8G|pN3Y3EBIv%_W@g9Xye?sdC&+tiOA7vuV!ESogM{6XLfXuWeox1HNJJ-
z*{gH`b0-h1lWMADB#8T>4J)9E0G)hI7yT&-%pAx}4xgM6vmoZZJUQ5mUtnXvYKcEO7l&Yk&4*nzm>T4*Ru{TBln)X^sy@owE9WeKwRb_FCjx0~JkC`Yi)}
zef>|OH4#cEvjP27NxOd_449jn#~Y{L^_T~KyFJR2NnoxT4(C&Wz=LlnYc}%rvXSFg
zGA74Sr}oxS?ydP};B%Pe&ovl8KqpDsU8}I{vjD`r>&l-P(8c5Oje_TAldt!LDVy7%
zCXlPVAux3WF9d{l83_FbHTG&X_G8R<%q|KVR9J73P4%CZ1fW=%c0)S>o9`ASgGsJoHM8WeMGXpzb47q+(l$
zM`bZTTW>D&&?S@ZP%ru9)>b-9WB`{fD$38dqV->1%FD?yQvfl~<8maoz3QD&)Oirp
z)?3f=bP)6&F`I5_dBd#iF&I1%^cwMBd
zrAb65kVWHvJU`n?GzvC}D3~YoJ^z244FHY?4iwsxjU(>hUO#}-3J#QRY0Fo(#(}j>
z{GaFEAWg<35QXa&>CsN|UV0$*LEL880(2~+_4hWjAQkPZ(dE_j%>S(gIBSBehz27K
zs%bYeO>>S67zaa%0q=#OkKw_(WHb7Igic>aw&Iw=$p&?OlRx9huvwdX@o)^%ZsGz`qAYcTlFv+#5-REmnk_%h#
zO&AZ6UBE3DHpP0>tUE0WC!Fr*VH9mlGr60bsk6d$f2J5yV&udP+B(^gZS&z6#L%BO
zXSR#88q+M-cO7neU&T-)#q^NQa;NoS_XB9q=n5xx)2*Q6yJt5ynnHXMK9e#iBXCq{
z&2zdHP8rxayoBUJXuII)1AUB1mQ+o_lB>z}Qel0?dzut^!W;44a;DH5Cq(nMZ>J;i
zmLlSqcxJSD@%5as7J0pcMpy8Bbs7(QS`Piuqm>7=;x$Ay3McZnC^~LU1@@WaqY8vZ
zCw4oUODgH#X?&xo>+vpm?abL*bv4b_t~d4X*3C^+qMxTGW$vwyOQ8(O*b6)Q3Z%
zS1&bO{J{`&)9-G0hZB5Deo}VwNwbSy71%t{5Kn&=&KthftTz@s*4&tk@DKk*!ILvt
zn4S+XyfmpAC1^;H)|zIAScW*=QMvYT&6av22wDqqiTH|;Kd@>qSUTn82bs3YPb7)i)8(bF67bK3ziZkzrV(>xYXFn{JV9k>xbtW&$o@!?BX0
zQO|C|OGx}R@f4k;@s6#x;O4jiPJdIIyS+@9c&Io8VeD(d^%G~BiN2?T9?O`m+fsjx
z)+jF;5yczRfj`1NjTBG_m|C{KR%|Bz0xji+tQx}hXE;BZg~!%lE6{Fsa8@4I=*Osf
z;y9(xQYbYO=8exGY4l|$sD?Od290&ej$R&~LU+|FrUhdS88BSvN)O{_qFxDR*#5|g
zU~iR7y!Q$ZQQVjjt?nrJR~o)pCB(i{|1Sp2Q`ES-N*zX)-+6o+PVeJY`>DmNoTVa8
zm!_sNN|#f1_(p(jQOJrA+<`=6+9-SA7e&(Sd_>Yq$*NFARujsf@HSCNqHwJ92iczj
z0Wg2!6xi;|S6Zq)cCwBsq<3C?fSMArOj)!xP_yE9r0Q`*t?w|?;uS&fNo=uW^oUuT
zv}GSz@F+5N;>W(x-X(9o?8DE#&;DcifG3>=cjZGCE@TT}EQM5U<#G7lwqXV2$_9aicIbvvQ52_FMj$Ee{|6aG(w=rBow&7JI^tUW!
z#J=S`cdP}$vdV@29AcCOg`?fXd$F!VM5(4}w=zCj*}Is390O`Eda-lrH1P7cm+Lg
zbrBp_vb^qSOGhNp%F;Eh`vKlNZyc6e*Aw5%!&m4Yu^AHpWD87-}{XLF1om%G%4oAWU4sg&BLUh$naVZ|!82e=M{EVTxOi4^zlb
z)P>+`3TA;J4I~2OXP2*Q94V29S*}#S)0WfMuQFA=Zmmra5k;dfZ{&ONp^@+Z@&Uu~J>p5PetrUCgrHXuKi5oCEb(lg5kMn%+UnH??SU8X40KFo+7R(6V@KJM&qZU~{p0TOeIOLY%vTWKl>DMg5us&X+kf`W
zWAw|I+ZH@IGiFUUI_7%=I$B>@_K+>SbJb4?tyLYGq*cyy$mb<0Y<7xbd%1OIF}C&N
zo8l^wVHRg;z7+Atp^_n{x)B{raUX3ffIhYt<)Hd?u3S@9TQK
z%mjnxgePGrgnxy%_XKrVm<`sX*Xu^C_h1_IBm9)qye*`VU$pHDCH^TzSP7|4$dCF<&xud9M%I2GZs3<
zKgVCp7Dh_C7S{RYIneASrxs_}ssyTMg`
zk8l?Km9Tb|DaJh~9fR(hz2m8Lu^AhMSL$u;N|NXukr%mtA^Iib0wAwaz2jtIaPwx$
zk8@cV59CfXrusr32}|VLf*WrNtGbVG_z*4pEu$uBeKh<;Hqg|C!F0e)-Gbh3+Dx)0
zcPU`CTxuQvySe@mkoD+iu_;Mc8X26%=aH$+8Vvj$x=(+3SY9RmK}EQVQ)-c$ej!nZ
zwQ~N_^(t!a3t{aH>Ar)W((9|^~TPtT|&C{T}S=I#{FzQ%krTg*2
z#AEx*UwQQjDoqGiOv*y9hClr_*7B>F;VlRpSq&m(o;a0X;&xJhG&0{UvWL{)Szo=F
z5Cg(al*b4Dw@2=pDHrK!5S@v3hfgGjt^@FSaJur|*OS4Z8XNevG$sf^o}z+^xkyZQ
zMbjzY$#Za1FHU>AACW%l*x~5MrwtAYTQrt$*
z=swcA*naNY`768xaT9wQUT+Fl$KS6CJ61J#ETv+q#|?iP>72!!np0J?#bVdFhAx?PGk7WAFq(h|sZO(xS
zp4m&$C<~eoV9(@Er^$(h75w*sMY*0@VO0DEy!!^FSMZ&ZNf0S(R?AGZ$;O~&_+>e{B&cr?NuzTAvp
zX@rgxd0i=Jw3=!GanoxWyY;C?Vq)S-Cl?%AV0p4`T#@sN6#_JL
z`t!#_MFA}@h`gCdkMaFV0BmsPw5<0}0z@sT4Mxo)FMl2d&_M|_PmmP3coEgtcMpW^
zH;_mMsBZZ#T?!7NQW6`i0&opR+ti<-(b3bB4c>(^r||@+TqS`GF)4SL)3aS3Enfav
zGop9`dRGzm`MEjcLLL#3ND!qWTDR(5f2&4IctN!bxMp&jdCk+TbS&8lf6zr<-XQqO
z^U{u*uw=C~H7{~;HCn&-CWsdmAdo$ynX}>~aLJ&G;1p|=vRKb6Df#_CCT8dFNFvOi
zr|CTK3vcP@=tSq(zcx3k8Jn3ci$^<*7hAtZ>*1!RthOfLt_ftJH}i|?OJQ$aMak?xC!h4?g%vbWwXzh@^XY1
ztE#FJwqb@+9#b-l3L6fmr(dkHY9ur^F+^Po*
z#dJW-y!w%rvgeL+DvigkzU;S36Kpc-VVNW4yC={FTw2!^3W4
zu(GgXDBrLqwZ?sp;_>6h0GJM3S^?7PlAPQRsixzjBNlm2em6I_iCW*cFr-qizxT2G
z=Y5w1{<>=)|JtVRj+BXUC^IHKEm4HX4A3(dJc{f#6!sq{XFTo&TnYph{
z$Wc&GfIj{VY^{aFhNGtv_SYX^_*F`a_-n=x^-Tsmb*5CwYxU(mz~$K>k!aszpf4o$UY}*1
zjyr|*Py)EIZ5rH#4(K#gGuzqG5et2v?pGX)|2i2KzQD%z_r7#|3r`lhsQwV+TMuws
zNoHoVo-(d_>
z2)A(gSD>9zUXrAp$)S6v{Xix;@H+)eNo~;=Tvk8Gd4xbDFdhKvzAQ%#pkPzH6Gjn7$Jou9l-E|C-@r{97
zV#YX-H;=MQlCtS~sQ@Tumj~Q80l@Q{%;TG)Op7YG
z)m81UQhHea_GzNxkVk(wJzDVm(?@W{`R)Q+TR#CoL}Opg9Zydw9mS0x-{oBUD0aDT
zK%aJ5d;fIA2j>i(57!c$fJqzTDVtAwo1E;hO2aA<1a!~$;*8>NbxRiBd`e31p+QmX
zyLb5LC?FvIY-whCnnlV!rfnApUzJ2r^U&yM!|eQbQjg;f&OwK)r&&r}5QN&M8eer=
zYmkQHW6wW;;C1D10b`4GUp8uu1rU^$m6aTuD(6w@)%kB{0cdx#w2o`f57&Vm_A@8N
z8?1!eqDG!E!)eLQ7E_=ZT4-UsdVzwHQY4KV3`8h{Bw0Z|6tHZQ6EtLG>AoJ`Lbs4&
zQTKa6=6`4Ht3N)qW@Com6`R*H9mHU6ZE8DW;f&cBds0LY68w9VO;?v)
zq!cW59{+ZofT^%4uE(L@OTww}b(<4{V{^eoQNxKm;<8TK?D5{OJ*}GycJ9Cnre0ea
z*S-o!WMl7IRO9dc$?9;(4=SkI^>`Icy1z}xIF6NduzQ}Rp}8zBPKUBf^KI?&n8Ffx
z&@x7>R!Y1H4}X4`oTq&=n)8n9mty_}_(H8)w}?K!u>)qBliAl{qEZ|l2`l{?Pr80t
zX6ys}SqXf!m25PcYFJ_NFDVV@_Pz}}2ge<4Z3>>75$RfQ`A{GGAX?0As;8x;Ig1{#
zFfcR&5r(iHQ~g1?0g;zU<_RM`-|Z{$Env#1g6J?Z^7+%UFDV%{H6I+;C=>!{6`M4%
zf1w`PWo3h#wXZ{}*VrL9Nd4g<0iL(btvbuctp`aFVPPKuMz=^LwZ>>9sZ-p81^xkN
zNQX((N>Fxa*$SoQMh>H{`m#5ybMx?sJfFlrt^Ydtj1s$?jEK>5Umg{g_g?i+
zV(a{lJG||z~k*XY+2Ccf<5<8zh07iH|;76%&P&$N>`O$)!;+*d}I;M)-irrzQ
zKODgv#)cPGz|p(DJMQ9l=>t4WZ{e8Pi|Eq<{*EvF&KyMh5rvBvrJQ2UeU7a`7JD~6
zUl@7{chD0|Vjyzf<%rNvZ&b4^Ml9lUo2?;NTz#zdhgN<9j^c
z0dfP9h(1oRdWI$4Pb(+7`Lzi@jtbmUJNs2J;02#7KHX4rb{54O>Z%Uh-Q9(^e!YD4
zs=F`;7Ew#;9R&aOW
zU=X&Jhuwcz_pWW`?(0V{#2a(S3=6i~1cw9m-nY!`U)qB_*aXtwA)D~%XqhcV(AL=g
zsI655e$S)Rg^8VAxW;=;RKa`IF<|8qAD`fOp0
z1Ot`-(barrs3&@+7e|XT4u0KDl2G?8QV1xH=2RLJ{=1(Ft|Xn-=H~W4f9w~2J%qY6&>B91%JV22b&r+T}i-uGp5onvT
z)FShmimslX3bdEqhNeJ#KdpbH8Nx_d*M*xI;SRoITbD?MT+Z-?XbRsqh?G0p#&5<-
zS3Yt+n5^+GYGHH-l|)c*aFrvNtHiftX?j+FHGBX?NXo0d;NW0j-(G`fZun?yi{V8&
z=3dn;{Au*%%NGY1Q;*Y`Wp?0Oo88xTx>ID{CMGWEjX(t?`)oVc=4`WVskr~X>vxY%
z-+)d~Cd98O0Uv0a21y>|U{&r#E#``HF2z3_c`scmw(I4Dg|HBJ0@1wqVGD(%dmGS<
zqosDya-1aV;2kRoJPr76KE}o*Y&6y1kt1(ERwjT~D?wIK>htxdI#Qn3RNHvTMY)|Y
zbw*rq(A)_IUkfHi)bB(17#*8>STmi(0}~TwTiK3-xpW{bnFWQ-WgebaJQ`6k@$u?V
zY{5o?gRH};4%nej*NLpD>fz+7iQfW#S$sjXk_{CZ8HtZoOfK&s8xY*0;OhFj8|0w+
zdA@NL-Z>x0$-?qyw}C_HS(y#tV_5eO9z4KPkq~Q)HYvEsXlVXl`vvJk@?*n7Gx2c<
zNunN>I7q{D=PYV{Hn@S7w%(lWuw`BFs|Ru#L}n8MD|l&*M*~=I6XcJNkI5m-Lx}_)
zZV(kPNB5@CzRc6liGwoG#N<3&GdEgn4RcCIPv6uVuqz2lD75w?5a?{Lj5A+BzvY2^
zzZR%arnx144S)Yy!``g!r
z#F1Rge2^_hlxm(5KzLqLAfK17l6Lxn3QY}pcK^N_M5cYn7R12AKKT}Ob)Ur$);s<3ceU2E1wM%Bf524Icp>(#Md2&*{#;)|
z!z`kw=K9$_Pt&9HR<3Ph{wwDlkkuK)H%3_AXlVPA?B{T2JXyblf4{wA#sJ4@+28Y>
zCghg<5>IJWeb%Z!Lb;!OKGNLI^B!-Ke70f>(b&>|2*6(DcUJ9|Qs&CpWW(q!Jjl@c
z1SvmrE+mS8ogw-;_v7kMDwbS9X<@new?~h9savY+RhzdV3jaRHuO3%L{WAFI_#bj0
zd%zLWJ#KO|ggJ8c0QDv-OthT4$t`v{{OB!*;)Mbh@{;v$ARzvi{M
zMs2#LU~``cAN0V~!wIQ|?lA`cB@`np&EthNxLI}k`gHXRzd2VwG+pSL%&XGOlFAWt3IU
zH)Vo?RH1byu4d|VKaw|R1Rqs}(aj9nBK-spZZ>ioMP4AG}hgTIfs0Ws3-B)M~^M3e45k@b|3gzHayJHC{yhWzk`!)Q#S`
z&8#Z*Imp$5D~OCi^@z26fWX@P^&5LnJSbyS8N4Bi6gMQ>u;Ws*@}hh&Lf&&dyRnap
z(!d4{^Pfa1Y{(l-cmau2aiLW$YbE2|W0NspK0cO?z9Yc
zWY^olYm*?v+10knJh5_0qScy@te-_TZ0zc)w;s-0P%uj&h*khgF-U|&9AGsC=IXqD
z^}z!AN6giXm}<~%I3g${>eUiZE)1!#L?j5tQK0w*=1A0&#|x#GNhXXL!-Hru{1XPK
zR6`F{LupVum4@<(DB=Q7{79&Gy&n=TwM$yn>W@%zUHhUyfFys)@umF^bQ48W`+V_P
zW+Wx3c_FLrF0j6)hokVW`@u|^e5Q*)v6~)89G8jK5E@H>m8953#`O>-lAD++IwROR
zdJt$}8>_?BjGR&$Z0)?3{uMn?uuyCoPKvc~ypaO^eL1RmY-Bch_g?-RflVYw|y)=
zVd0{gAorzvN8@;}sz+{+o-(41g*Kc&=Lh$cawb{`$9NBqwehKjE}%}E-!069m10dU
z8fYKXy*^AvWV|p|;gR{F{o;ilj$;nD5IJ2eqsU|w{BSi|zloJ4p^Gu%dI4FwNFR0R
zCPrMAFd{*Zb5o)LzpL44RXqu%t!n-1e)G20?6HKXVkiemABrcG>^|aPBs%5GGMkBa
zoD}3la5Y;^(VOv*BN>CS3Rr&uo9kE0@%#TOA(t9iNc<+@(7(yM33|>VGImL3_55&w
znqtV~VO-A3v{>x<2z%n3{4W-;?D96qxJ(c(2x|h}U;{hruKXiqONs-jFT_?Z=|rvS
z6Wisr9$r}L^c1vv?R|NO0s1?d0y?(@+K7H$nXIZeW-pv*W*J$V${%<^VWgPwO|`7?
z%1j91jz9k)QAlvLv{|K
Date: Wed, 2 Mar 2016 05:37:51 +0100
Subject: [PATCH 238/259] Remove ABANDONED and fix ambiguity

---
 bip-0009.mediawiki  |  33 ++++++++++++++++-----------------
 bip-0009/states.png | Bin 24827 -> 29300 bytes
 2 files changed, 16 insertions(+), 17 deletions(-)

diff --git a/bip-0009.mediawiki b/bip-0009.mediawiki
index 856db7a9..e6be63a1 100644
--- a/bip-0009.mediawiki
+++ b/bip-0009.mediawiki
@@ -29,11 +29,11 @@ Each soft fork deployment is specified by the following per-chain parameters (fu
 # The '''starttime''' specifies a minimum median time past of a block at which the bit gains its meaning.
 # The '''timeout''' specifies a time at which the deployment is considered failed. If the median time past of a block >= timeout and the soft fork has not yet locked in (including this block's bit state), the deployment is considered failed on all descendants of the block.
 
-No two deployments may use the same bit if they have overlapping starttime-timeout periods.
-
 The starttime should be set to some date in the future, coordinates with software release date. This is to prevent
 triggers as a result of parties running pre-release software. The timeout should be set a reasonable time after the
-starttime. Setting it to 3 years after the starttime would allow around 9 deployments to be initiated every year.
+starttime. A later deployment using the same bit is possible as long as its starttime is after the previous one's
+timeout. This means that by setting it to 3 years after the starttime would allow around 9 deployments to be initiated
+every year.
 
 ====States====
 
@@ -44,7 +44,6 @@ With each block and soft fork, we associate a deployment state. The possible sta
 # '''LOCKED_IN''' for one retarget period after the first retarget period with STARTED blocks of which at least threshold have the associated bit set in nVersion.
 # '''ACTIVE''' for all blocks after the LOCKED_IN retarget period.
 # '''FAILED''' for one retarget period past the timeout time, if LOCKED_IN was not reached.
-# '''ABANDONED''' for all blocks after the FAILED retarget period.
 
 ====Bit flags====
 
@@ -84,7 +83,7 @@ Otherwise, the next state depends on the previous state:
         switch (GetStateForBlock(GetAncestorAtHeight(block, block.height - 2016))) {
 
 We remain in the initial state until either we pass the start time or the timeout. GetMedianTimePast in the code below
-refers to the median nTime of the 11 blocks preceeding a given block.
+refers to the median nTime of the 11 blocks preceeding a given block (referred to as MTP in the diagram above).
 
         case DEFINED:
             if (GetMedianTimePast(block) >= timeout) {
@@ -95,10 +94,16 @@ refers to the median nTime of the 11 blocks preceeding a given block.
             }
             return DEFINED;
 
-When in STARTED state, we tally the bits set, and can transition to LOCKED_IN if we pass the threshold. Alternatively,
-the timeout can trigger. Note that a block's state never depends on its own nVersion; only on that of its ancestors.
+After a period in the STARTED state, if we're past the timeout, we switch to FAILED. If not, we tally the bits set,
+and transition to LOCKED_IN if we pass the threshold. The transaction to FAILED takes precendence, as otherwise there
+could be two non-overlapping deployments on the same bit, where the first one transitions to LOCKED_IN and the other
+to STARTED, which would mean both would demand setting the bit. Note that a block's state never depends on its own
+nVersion; only on that of its ancestors.
 
         case STARTED: {
+            if (GetMedianTimePast(block) >= timeout) {
+                return FAILED;
+            }
             int count = 0;
             walk = block;
             for (i = 0; i < 2016; i++) {
@@ -110,26 +115,20 @@ the timeout can trigger. Note that a block's state never depends on its own nVer
             if (count >= threshold) {
                 return LOCKED_IN;
             }
-            if (GetMedianTimePast(block) >= timeout) {
-                return FAILED;
-            }
         }
 
-After a retarget period of LOCKED_IN or FAILED, we automatically transition to ACTIVE and ABANDONED, respectively.
+After a retarget period of LOCKED_IN, we automatically transition to ACTIVE.
 
         case LOCKED_IN:
             return ACTIVE;
 
-        case FAILED:
-            return ABANDONED;
-
-And ACTIVE and ABANDONED are terminal states, which a deployment stays in once they're reached.
+And ACTIVE and FAILED are terminal states, which a deployment stays in once they're reached.
 
         case ACTIVE:
             return ACTIVE;
 
-        case ABANDONED:
-            return ABANDONED;
+        case FAILED:
+            return FAILED;
         }
     }
 
diff --git a/bip-0009/states.png b/bip-0009/states.png
index 7b3139efe40652d75d9a93408eb2466544823ca5..e058c8da130b6d47bafb4aa834dab23a2743a627 100644
GIT binary patch
literal 29300
zcmaHSbyyT%+%KKdC8@;Hy?}s}NG&BLAzh10cSs{B0uoCuEiNV94Xe^DAc%A+-5@D>
zhu?eO`{(6(=3#es=FB-~PJF+g_@JY$N_X^O3w`Zvv+g+G7Mh+?OGxufK!tXJZ6LTFin|LMdxGv
z$rR3yo$e^{t4};O*(0J2O#Z+?l=1~|tz!`XKgMs^uWAY%uE3l}zIIt+N
zHSmpM$Eeq%^<1xgDW3x|ud=djg8{UAb`UE}@JHznPsv|tH^aL(ip0Mq8zW-u%NxGJYimmCDI=;M_O^ZNKYeB+fpem+=?&oA*%t
z)Z@<7$MY;lk$4%nOfp`d*}ZVUgQ?GhiHpPx=6V024}xu!`QHbRaiEy{GalJu|NqO9
zO{K--1CG~^e!h^$eEi|f>GoK)^>c|CJ1U8#pyT=~E#;lb3fNqu0LDIhGa-R70}i7LxSVNzb})y^}b`Kw;D-aoZqV+G1BUQ+QZ
z6Vhljnfza03@_6rSC`a*4_vvg6~;f?52Z~Ozj(wb9}+a~baj4^_jh*MF2L1c%
zxrX69S#F{{b+Yx7Ypr>*!gNlgkI9ybQ?q~DPgfU@gn>HQUcL+~&sP5W@H-jU>pWY(
z?c(?QNB+0}Hnx71(P870+I@dV5=F}c(n#a~y`JSJ*gv}ze9mm!7hf27zJL91G_)5@
z9QZVTr8#h;@>I=!~zMW1oROvBY>N;r!6N&3A3yYjpS;4;T=R$On-s2Ehg4V>-CJ&svkV_tnbaP*NRc0Rp?SqO&_EOyHS+pTX{V3i(
zxGsx`-J~aJ0`Fo59l}@7KM=hd3%hGV%+yBS-h}0%UO;`{BdNmoh7f1$;6UARafO8v
z7ja=a{~mPO`Yv8}#EN>de%b4pTG03RWI{w}iv~v;p{{FDU?hf=)^y!o^8GB*;`_DO
z;^iQ*=)ZzI9?h0Yrr}d>$G#s{>clThn0zL5;~1aBU+uRg#0qsb8|e6(@V}}rN!cY~
zl+X-}Z*-aan|F8pzT<3`m|$=&l8{Q&kj)FV0MEtg&6?Rr?eNbFSBX7H~-&0WMJ`KwWU+OzOz%9q>jB_%@YbP)xM&ozl
zWnx`nbg4;?pe=?^KT1Y@P30_}tocs*^halKVCO&1_H?~H>8p#CgcE^w_VOZdD&~d*0
zolG8Rk?i?=^7?QV-5#f=gP#S-}5ydsekmJSQrT$ed$~19G62DY!)o@d3FA!RnDMa89*ZPU{?LxM1o@
zE;4FN`aLLV!x?g*V#}$%o%JI$cr_%(ZH_I|?fvHU$C91d=0HdDaEIfkknaSBW%~$=
zJWlqo8x9x7DPP`0R-M^)GfecZ=`zGh1ES?6QmpSkKfXGl4js;Xd2-x1=bGh>mY8!+
z7E_Z+W8|T~yWWt80Sm;3MsvS~h6ufP(*=DjfpNdejJ$rmG%DO%XOwh*9C*;-_n}eq
z?Z9xk66u${#yP>yJI9)`%ZZ!KkZ~;aSDy@1d^~8DMe-THQi||8#s+hrb2V?;?Bbo^
zrD6MF=Y(kxTD~FUXujyh4#mFZgZc3-?q5i{3m*y}lKyz~P^h#Rp@k8h^63*wA2p2n
zhpK~XOVss!4)En{F8l+-VZw1{$XQ~^>B4DeY!G;{VXZW{$TK!Z=uh*IdYFc>j=fq#
zO20z9uK1_1r^MF+Z|UDH6gNSPiSu!0B8`}nn0#K6#rg`sF5<{s)&7@ABb~MnS~N>C
z1@S!jzdm`GZLs9wVt1pbA%=Q
zY~g}rQT@r&#yrE7!`jE`&6x3n2uh{o^QZNwKV~i@w30j|gBYpqxIOa^nc>zF;Ba{n
z4cpd;PI$A3p0o#Edz3q{l$ZH$t!%K2HpoUqGcb|w?UyG^fN^p7y*u|0n!t#lkhJddS`
z(+I8$M(@T`6H!5Zn-DH0BQ^SXHrI5oRopRiNoCUCUX*%;m!ht4Vi&%n5cU?o4fyWI
z?Q7^r_Q3MjxBrg%9wDTCc$2wa2#(1+Pgkdao&!U=2lz>&!L94&EH$(4_3`kN4Y-D&
zb$=o&%o6N4QG$H7biaS4o2v&(7HQ`U-WPOxb?|SytV*57flTHQLo3VB!dOKUf}_p3
z%dtblybz`(n(a!woV{txzU303cL+yl4SzuWa|rqNkJn21n}!^eHtxpUjo2CEHp8y-
z16%^jMsBVlu>gKE&|3G-f9qLDsrc<*Wqrd>me7yxGIoRY&KhLj
zoRpj>CD2(0iJZ@Sku8PZ1;1Lc4Ebko5%OXaBj;rM
z7oXQBuSkTz<6VU}3VO2NXb&w=6bhVaxCDkJu45i`$N=g-#SSPml|HZ*Q-@_E4_gdJ
zP_#~J08i?^N0xN-;8EcKY%?!z;WfuJ50hI2b;7uJS40}hii!M6~S3&Zi(%QYN4
zoNsibWuLS0sV&Lke^ox`{JNd`+NF$uZ`j#`blpSUGYd6;m?C0i`pkuXps(g48Rti2JQny~@JQBak$G{ED*?yr+
zbOt9MQewc38J`V?8e&L9=Cv`WTr56YBmbB@MSFwLYIFi;Vnu)%|gX*7&(j?*8N5lR&{&ZcEJ`
zQxv{vS-J)NSR%PBmx313!6WdJEc_ozw0E8itvz;5FD#+F^lJIiEL7X^>REKl70pHY
zkJ=1G+Xho#DSgHa!}957v*tK$N?g>S7(tLmMC!VXRRgk#Abe^?0N)i09H=sG7|CpC
zN@?+cJmRx_45M^Jet-9|+%wD=2VB~o?Mkl
z8^`^+g`R~p9xKljhQ5e?yN$b>v6kW$9WfC8f!4;Gsc%38eoNe4yK3nIeL}6rk^rO-
z#l5yrC-kllxNYKFv!iN;Yi#ukxVY_lfR$ku(?u2!ws!N2uQ@vg=%+fhw)NUwL26EY04
zH&o@t1%lW3m2PY3F?zSNpQwSJRp-i(7aHY=!K6LyA@O`%6XK`7{c@pP2Ywy=+khd-
zX}_Pte2rHNP8$6Mqg`Mt(2D0U2Wb!Igj^;d7kJsy@3?@x3i8Y@D$@#@-fi+}glo6@
zOEk?F;zK$`jDM66A;@JcQuCOYCZZ0Mnw~W0;n_ox;yv6mEiiLO2hrll;o1T#dTe_U
zWXb<2%XTB$#mvSGqFl3oDn|9`zq|~R+)w0Fg*avHR_rO)`N=D6{`{ME=TkylUkA0;
z=X#^YlmooIHp{~$Wy`}p<&{@z
zZ&JuZrz;DFC_E!RYW3Og4+!M6*E#;;Rf&73`&uO1vD?V9a8SV5N2IPLa`pYW`fP?y
zmq3~s_-8FY3E}<+b_|Z;{AQKKEa;hOe780uIEx)d|AX3JWn2Nw_;SWmvLV7EQggX<
z+I;*7htFk)sUkp3Sbf~XPz6ilh3nQT4aAF3%7dwxZIz?N{!`Kf!UlI+2j1t19I8So
zv4MEyy!<+oPB?pdf=HUD(XLhHr#Z9XND&m_+5=P7nRk!aQy#o|zuao7H9hm@0qZ0W
zP3V)lPdxTsg#!azaBVyZo_eO2ai6(e-rUCPWPalrFa}?B{!mhGrUDqM`Ymb0H_f@SjBCdCeIgFhfo`t=78?C|$+Z&{3N
z2PmUwORoM^;)&{VDUro3sk@5w=@y3zsSGhwA~I0A+O~GI4nG3O2dT-yS+>yc=v{6_
zi<0kzGd+BI8TAxj;Q?gAs^bQbCiQI=ljhpBpVWH}*e}*!lN9^vC+YFvJ-~lcXbRLV
z1m_ZCV18~6lZ&%$L;$GdKy%>$gbre=%S4=7LE{JlRp=b^J|69jd=*@31F^u5m#DMk
zqfm4$8L!4xqXKZ#g4Zshwd1Da65_N%W
zd>ExjADH508F#26Var@Es_@54TbvJh{j@Ux4!
zM=x|TLlRGr$dv+WJcvl$Xt-*!x62E-m3Nbvls0H3jgyN`$*{y&_#bPe7%q)H?pO5_
zN^8}{Ytcz&!t7TgLEtbJni{B710Ccu)nJp(EpUc#LS=i_i59Fy3mf_J#qV
z-7Av65`j6^gkXk5M{Pq=%-gYkinDh6&Eun!PYRKt8q#7PXttBZ*5_#bjmEWU5_?Lc
zluQnfQ^gu6SPi!!F#;-v(qz7Z#)_y`wb=ry>}!F``3##&Bdu;4Z$<^bYWF4UxK+sG%{6*qvy5F8PPA6Th$F%(IrJrki_E
zmZ&Le5X6joMVfou4e31NjY1%hQ)&daoZ2u?jbs3w!cM7HJZ0PMe;Q#Gm6`h8z7p=8
z#}RrbDKcet@IcT+yM%EH|Fu1|7%|iAOj9Ijp*23KJf60!et&N=(2w>|AP-Ok&t;Mi
zrF@A~FUrQ2NpjWGDppC3cXE|t1u0lY6o{eF7X6J@S3Yl0MDouR7iqnO>wHxQXTbK$FX^HjlWRi^EPtbhT4Ii1%F!e$ToYt#j$)QBY4Dj7~q|a=<~_`GVD8+MDhgwwD76PUXQdw
zn>W7}b{MuAi>`&PH1=o0(+_`kIQD28p0GQE;*RJK&u5E-mFuxcu?(q#+FtZZbBN;z
zf}DxtX&zsbXE6KS{KCQAYG`hZimWBVS3VBLs>h7S6il1|*3$mI;cgG1L$_~F;`}Sw
zR|iX6#Xv#6WSGD{`9&5^imyVhhr1f#Mi{<&)TaraBM;t^^g3VgbC|BSmU=Z(N@C{G
zL(>kVpDno(FTZZbE350DeA;`!4>`}OMYbvgMg+K6NNo+^I^){yHpTNl;;DE9m&RD)
znn;3SiGk~)*36nl(6kP``tX)*@|48UR;=3AE^9ku!8ERpfwE;rqp?!%535rE!K;PFzJ}P1}e+l2hnO2i~TY2@Z}uY#A*zbp#J1f#o}SR_$k^bq9lO?mxAj*aKNv
z849lLQV0OB|1x|rtx|5k{iumYx^Ubi=olaAFSl(nL7FIiHFwzu3RdDv4jz1avMq%&
zuqs4mQEx=1h^dX+K>DyW2r0JShC{{@>Bq7)I8Hf`r}!6Aj(H5j;K$NN-kqV|At}g~
zF%rR4G2`)Gc4F<=Y>U+|
z?ZLu
zXLKOk^+of3zS_P3sDYC^3xjH9pC|nTCUdb~V!iAqNw*cTcU5f0O^+}}u+Q)%MC$g2
z%exRaLud<#scnc~nWU#>a_F`Qt5aixlVt5VIjr#iic@l^}wkc8Fz
zpWV06%Fam16d{6Aw5_uW0h>(LpSx%`r9O*D$xITQ^Kp+zbZ!oTQ0w26a8rW);ydNL
zMWyKOP{s>zwGgZ8#&ro9q=RtoVHImeZWh)Qw$ObTZkSfb37@4PBF-h+CAyYhz6;|T
zc81J1%PWhf^q7I$YTCsKmu5SoC);^y;Xe3ym|Yqxm!3)WBG&Iw*`578^70%2y!+=FaI5_?c
zMXku%YYG|`sWTSeQzh&?`AJ}sB!pLq8}hiB{O9kh*YR7Cqf1Z89YYEOI#vt_IU2Zv
z{y8Nfukh7dC*?4q&GwU}pU_-EEeXXdDmXoBFTq)42eSNJS_pZ0+b+Jq9;Q2wZoOQDh)Px$)|f>yR!&!}ayV
zT^y2(P-r--pz#wb3+fx}-6=fFESivi(Sxr_N6`_Pz|KvuKp?cz7Zw6dQy(Z%{bx@g
zAy_P*OMxXxMVHr1SIpGJ^Ub=S|5BRlY=|#
z+`@rv2nwmxJFGyM)84czSf^{fu<`?6iNSYRts;?=V-Eh0e^6{fp*7ize(FH7rj(Fc
zPyFnt9fej=wyjL@#$Yw%7bxUW?|5|8Ua5AR%T%mR5lr|d>hNyeiSkbZ+F2K~$18gf
zDp&ZCh4~3v#>)e}>B3VnVbLOm)F`AO&W<*jqM5#|BGFqO!sk
F>Y>-m{P~(*#e`
z+5HoHB$c$r?|HCC5X8F`q9_)`9I@ny%PK5O)5UI}bxSWfgYHe?%0|d4_;sLpkpE7rBj-z6`!3vC@1=c{*VD#v1vxswM7ylr7!?Y*1iP`@e;B9)g(ts&*7J;M4ZfOv
zoiAtER?srgFnjZ%XzjQX?fa|nE0Bw_`wMf7c>sEjz&edX^mL&aDX52PxvSQ-+1LqQ
z=H!Xh<%zaSI29~7Bv4WJNuVG&xZ7_a2Nb#AlVKdi{HHC0B0mWS7mk74y(eROztc6+
z8&iaoYnSa~Pw|Z=jBoWT;YN+Id{yBZ5I5aGwx5+IH?Kthahu6f*>J;rsuZIamq#d~
z@DxjJHoDrYz&!JtCJ4zQ`S{b#^KV03HL~gR#7rDp#t`K>7|7)j?$`9#`>=Zl?aa7L
z7HJ+1>;NpT%un`Nz)x$k*?(%btq@?2IoSJ~kBHRuKz+*)d!*hV90f~4ez^B*sq`+A
zUB)gAfxb94XTgUIJbnslrsPfff3X#vXJ_Ej$~W&RQ%Wd2yn->A9^wx4`qG^ySn|i%
zUS>1lt^qlTBra&C4HnG2OadVW0ckjPL?Hmc#`bV_K&C-8#^W-O=V)i_XOL#aaR;2j
z-&lG$x?Ge!s0Y}$0$WcZc}ja-l)leod0|P&pl-zlJQ=lqzk1{GGI$Y{MckVGxL_2b
z!vVTMRj~VlZPXqE?fe!otX2J*h6#N24K2te^W8!r;MwN{%s}#S4Rpop!S|x82-Rw_
zQyd^Yj7KIARL+14M0N-SxAwxTKw7LEm^n(*y7Viqis-rd*Jz~LtHwWo&yUk880zyo4(
zvEY{j!_LvjP>eRJjd9^R;sXCqvfT0d0l1PJg3A{gitB6L^N(%_q_Y0B#5OMkjm7@W
z<~|t7jZ7hkC3w2cYj(gtxO1qfTqX2&is1ZJ8lNk9=}+)U{s}ldQS=YFdf&C3GEyhK
zY&Ub}E=&OAqEW5W>)Y(}*)Hu6GqPgjNJe4HK{nZ4Uinw)@U9fZje~?F4G$XFo0%0
zFK0-@0s8QG+7{HMY7W4m=nRq1o7dB}32Q0(+K@NFT_HEo9g8Ef=Voutb_r1chWhoF
zk)^rVes19Yr{JqIp0(z)Sto=j$V12wf=9}v27u%k8N$|BeoN-rWG$`>tzyp8i7Fo%
z#tJp)&Zce2NM%oSwkLR~?z
zQ%)0~lkyl%n!0r~yuN-;CTp;NkIhf(zmR?TwKzTW@@$VWx#8p588|=-z9I764+8*=
zB(*aEnkxQ{5Fdi+f3*Oo>W1kv0M@FJEq}TB8F4GS!$@h|%WON)kIB}1sA@$L_IF%EDAmzvvYg%_
zH-HoPZ;j6Qqeudj!{)O+@f+a(SK^=UV?^k^q*wnLflCZ;-EeK&YphS@49oGIEmebE
z{)rXxzcU$n`Ee7DbV<91B7wA%
z6JSYv2Ne$er{)0`aA>;5Hg@E`gJWp;jN5z#KC33I3x)DjwLAIVO9fUG4(+XCshuu^!4i^ItXmSp^
z?rw2YivA`}z*l{&7yhTeW<=kdyq>Josv6!jNHfc|CJW=Hso0`JlsU#9D`16%sql0_yA2@|L-8
zAV#2R9?tsw9d!=Z+-V~q=O_?ibZZy67ez>IlO
z)A9QDi4z#cK0lt}AN4Z2QNLm;X7B*!?=hgrz^oUq>uJf*A7{&VQ9KSs@A3of#%1*!
z-ebsNu~aju?Lix2KEccZLjEdH4ye>(#;E8$@&?p_)vlqFA?Fzd2!OcG)n-%2iKtLl
ziS3OsD+YLdJvTua$P@huL#=)6&V-PC92pFBqW3!_QOj4*9^aPz@*Sq^pH>-CG;p*0
ziRRd?C;%-}$NTT-$>zI#!WqDYp7FVRDITYxLIF?<<(2
zD-BE-2&70%OQg;XP#P6ua5S&m7&y_HcMC7S=h({$e;>95zg3F4^Mjwk#Yiv6H&bms
z?s&46tZ=aLn25^vm5M9f;ghP3zf5VE0NPB?3M00%wA$HxO@PKJQtjj53-$Zz0h#@B
zBPb0v<=LWL?xlX-h{b{zqCP&wa#4~Ek`t-hs3RZq7_@PKd=95a6?^n~gH0`U1^~=W
zGG+On8j}0n1R$jn;MgNE!(+mp5U|~JhLDjrE^*bhDtH!_vbc*0voT7QVVq;6W7)r4
zan3~wIu@srYg~VxBx_#
z@)p?(?C~qWo$?}OBZWvlhw-3@AjurE99u&0+sCCa
z(jK2LB7j~h9}ohSo3+$hi7FWub#ZRJ!j0n-ne1wp{-8FSoiFTS(p#NJ2wO9vieYTj
zw%wMB%(1f7di1xx+cUok
z(UDaAFNas99=3d^`$`uxgN(@)`jZ!u<`o{8?7aYm(s4<=(M;BlM5>_Hcv|mZ(DbzQ
zsvfjN#>}3A(ef!#jNbj5(zeNxNgLpi)OG1ujLhFRJ7#vT=F@D5w?|F!TsC4Xrg`gh
zMn!j$n<0=+G>27oQ^0)h_7eQT3%Qb9-uC87s+V;a{ZSj?>7Aa!pRVh(>iXC=*(35G
z!|MwUv@uR++`)phIERGE3Yxd-u3gMPzIGvvxCPTYl6Lo0e%n4|45aZ~`nRcvBUf^eybYLVjAZ)i)8&0g
zq43%>-Ixu@d=+jj1Aez;V0J~2r>buQ3I#PG(_qea?32n7P;xdv^e~2baok{-rP@q?
zLKVXW#p<}cYATVR!>{zcmk{dKSOCsXZGwPeyHK{On;`y{bNA@m`i?yVSjQ$&sZ^DE
z+cPq1KJ}+-9xZg?D+Q7~eLRZedEs+v7FPnjPf^OyGY{IGY!&YO-162Qd{j8Jk@MFn
z%gHLAoC;b#%4kns^f8CLBtN5jcoscfX*&(Szgp{Z?=G@&~_1JA`w!>XciiKSqaXy%(y0u(rLSC2b9`{E1WVo&
zfcnB1ruz7FR53q#aWB5g|A-J6{+*4>KHRRAn?5i=2$!b(()j3EwAL&~?3N*>8~L`o
z07mY>@@yG;_pa7>t~5%mH7pVAz9J^{k2K>Mf%weB*QDN9jY1o(FHuKOiOOt`XM#qV
zj!)q6kGttPJo6D9Ils+F2t)G|*!_qm=%Husr0b=WDYh=2e98LOl;x0){!Z6b&1FzT
z!O1(s4Q+)N=b;tDlpDqfxDLNI<$GzN+U&bTp;F7-G-H+Nl*F^Pk<_AB@krC~SjtQz
ztl?p27uw@q>XHoNssbVdEw8au`}?AkDRiN08Ssgmd6Q&7@Q0>$S|qt{$!?j%;6j*u
zk&%f{mVk%6P@`^tL0Wu+Be{Ssvg3&5(`sOZ=yNkqQ+~}fa7}DP`mxdL)kKgV-n>eymC~lr#oVGIV5B`m+kD9j
zcOoFf9Ziv@(@-;1+CJPI~mUE?V1}*2m#2P>GI$mtTb6V6qI;s>A{Zuq1nVSW3kyb9V4>oO~
zLez$A#ffT;F9xQO&J_?hN?Z>IM=f4r0QJ7p8W&H^7ZyPOdKIrvb0o^!kY#5oVmVs)
zjk<+){3bh?oOz0}QSA{X(*rS#k(88V>dTkW?+KN4R+uAN#7u8#n8lN%
zqGf{eYK1KE8CW-UVW_dqssp0IgN%s8nM(wRq;Z`V01lm{&pY+R)_@k~bpsZ(}
zZw{}_&YEHrd#wPdX1!!9^xytlO@0AnS8b~QBe7T!du|l0K>7=KrtKRsQpK4u)DeL5o_@(^0zXSxp@;R6Pd-(XOA!pyG
z{!HqwpA{ywKP&JS3#K#01Of^99vNjY^#LOz4oJzUDE2tD;XDcpxu>elNjpw2`b?2lNo4;d$=Msr$a=wHE3qiVF
zS`ou%v756wH%&mfYf=ZT0dy9x0CC}aQs&Ls2EO|Q1%pw-*=jI_hkkgj!O3WQk|Y5J
zBzfpu*|w4@AT_<$h(oGOtF16K(o*<`UpBd#19E&XppchhTqrJlVJB?m9EyO$t)yk90d0D225QPBJ`n-EkrrZRaDKQM?3bu|ehg|7qM?D4lOD3iQ
zQnfao$+4x9--5_V{?Wiy%|8Ho$pRUrDtB$7dzD5#fy=2PZ%Hzr_#;%}@L+R;6GcDP
zT@s~CK5cnyRfV52LuZ1ssb`$V__hs7i-ozEkL~1IB0iq_E>$tX`e<1~e>vBj?}UYJowy7%my0+3!@ouN8`2qIus49(PHH6%
zd;z@RATfR@?r89#QQT?Lpu`Lfh-3ZtTQ&e8K0Yz6K@LeAF)hE<
zYJbvh+d=0%fH_6c783vp=Ns+uQ#dDug*toKO87cWhNqmn{13X<*3gCFUD~1KD-wnA
zu}J1Ob7~9>%=pT|TpH36uFgUbY*0he$rA{f#-;uV)3%y4WE>mr3ZIZ3cxBE(l5|pn
z428_{3}pDiE0e_3$K^qLNk2lPk;lnqep=4u$YTPc-A8}+VRJ+>S*`FlY79JEe>JOK
zB=?02a4?fM?OUKEB85^+tf4#TU7BwjUr4HL8@;4oV*8E$vT(H1{E1B_0~k42BbW2v
zlKy#gcYzQ1LD&KJgEfFd$=qEZD_2$n-60xuaY#7@B+?6-nPPH5DY{YbFl`b-#t7;?iT@!7EH~^j}4%iXsG|~mvqUbER_3G33O}+s@jMPEX5qW2H=9FK9!x9j;-EXdPV$4-aC^Y^|hs-8)v_C
zR^8#jIiJ@b3lNI<^+z;f?az~C`N)Vl7eeuU3;YqBOSRbn^dz>Lbc~L%pWLCM*k}~|
z5v@rye0D*$d5*8`uEx`kg<^-p(9+aJ;%!`FhIh%6>p#^+4*!kw-
z6?PWp3R{cK4P)}+!Oi>WoAj@g%K^*Y5rH2!H#~GLE2C+^m1m)*Injz)t=HUWOc^EE
zRCjEEak1WlSKEH8)7Z`RdDq?W#U%g-(U>m*C{@aew(RLdfk)`&&%AQrtn$XaCqi6q
zQML)dE2$f*EIMWZfqPv+C*UOD*m@IudBVf+v&^UpX-m1_1ps{(E$55}xoyi4#Of!&
zda?ijf=1uWn>^PBJvY#}bQb>B&I|9u6T(R#a#aYXlV+e^~~^gouN7CT{Cdt2-3Uf}~kv=tAD)KOD%K-yys!^@ofag0pMFL?^
z)q%cXGj5hf%&r~;XN
zZ0+Bl`t551n$udiKrYn_nHqyRLayvY-T9a2`wJS`FA$M}>%r4^QtzF3;a(q+!v9qK9kB6Eqc963Av_50UNCo4zH?1Q
z3K@0JCk=(IDFldLNRXQ)uUW5=VS-JCVANj)nlg1v-OT&db*wuvT#F>vP}E@4)Zs|&
zU*CWTU}%@a#Z>)^?JvoyegF+O2Ecj%O1IyeZBX6=#>L72SKcac*e#>NWlnxPr?FT`
zQf1+}lq$-&H$wq@NuB4KIxW93s`~?#KCgn;I{H)S-7RPq&{*@|W7Gv1rC$^Qmm3TK
zm%DCg7hewiY5w~xi0GZDF>(8IAchk<<~2B7dB3@|59Einm~aM)lsIO}R-3PXVn2sY
zVS?ncb+b*PmRO;a=Hn8mQq&qM2X4XIOqSO)9u-H%)l4#E%crQj>irPYOx+*Ps4zgw
zgunKWq;N4F5K00O+_*s=xvg*&+%lzv9^%v;`Y?@8o5ueK_TLIjhT@xch(F@!Oi>HKxZ>retv+T`Cp
z>U@3!YNmBh>Pq3aBopAe(ZLQ>>FIr#i%2c#ApT_r!+JedfQyayzzP+HS#H^t3oJk3
zw((M&wD|)7%x=b72%9L;RrXT*Gi@8|`>xI#=CRdToEMTAxZm;~K%P@F?|qibfCX{=
z{s2H%`@gFL=sfv6fGRldp|ku^ZXy9Gi`|;4dUTH(8+ysyUaWvd+5lYtR}hUAGsv$s
zSa$|%H7Py340J=4q1~^OQ%Bc?2via7n^iax)NT%+MQrKr&_-wunP);KtS?
z;Mug^UX+Kp5ufss7N;Y_sp>!%o;;EvP}gr*1KgGyfXz*C%n*nM-<^XmuRy%yt8u~tSrpqbg8_pr?*H?9ftWpl>Z86;F7jF;64Z>cU=XhlWn9W>Hu46I6`?@v`8zr4P0Q
zlX(}&*X-f3;Vy(Vip)bHIE5m0zo2I+h*R9k(UZ%+MO-pXZi5exwE#|FHlh@T&r_L&
zW0y9#RO;JYSej-7u=&Byx8xmvy@Fj%b=@l8-QGz3j-;9fs=qm2NPN$I%r|?0eB<}p
zk4NZ7Zvc8l#I`rC;21nAQ)jR{tokUp8yMT+`Bp&u0ka>O0Z7Ub`Mc|a)g-|3_}IuI
z00b-wL&lv-t^oZrTMyI!a#K4bsKN01K7t3N^j3i7gt15yq4&pPXR2y6nu2}$^=I|F
zWL?|0uRl+Jr7K|XyorfCZiAa$5q=#{o?aA!%o$rb+XQ~g@Q7qmw*SZj;`>@bCl3X&
za&FbsuB)dv=Y&grRlF^FJ4Ao{;7~KB^Nw$&wXTkGq?8sI`E3X-SRt%TkpQj{a&v0*
zj_i>I?=!nN;LWxxR<`)_{gk`f{r;9r&e#zRtnHG!)rTwyAeK7b7(5#OuwN~%sl9*=lUoiRP&W{Bao7q0bc>DYNlor4G=)IMpAl?L%2Z9e*LWP
zsZIRQ}!%FH0o#8sk|5>QBC4n@zM~U8VNqhVkA0!K40|9RWz&BcGk2hu^
z>+3G>2@h=-fa-7viaE#Gh?7lEq9+a97h4pHcadI>A{Ht=fT;T|pO!WS{2k^7XiIt&y+U
zMO#>*MI2r+%x^NUUuoY=(2T1S!`hcI1OAuBp7;Oc@^f?w_pRpA0*so+l(
zM?3fO6m4k$j!1c2Doqu4#
z+a>G?=(Mzd9^RO8!u^$bsv_=_8)jhUj026y{Uba)0UwLD9(tGEN+)K&2;~LO)#x+l
zg0VwX)fuogv9&o*_nS#jr>IZR#uBW8|LSjX7`Lpgj@}J{n1>DNJ=nrNNjt$5rp+L_
z#<^CU_Gluhrg9hi+F-=8gjt+16X|U42RtX+?B4jy3H5D37Dk%;43Jk_dfR;mqy9k~
zC5Hn3>tG=Oc;}%5w^2wkmgw-LdR`Dn{y@ij+;fC|rGr4HA)^qo1iM)6X`gvEFu5?V
zGH2$bGJoE;;_o}46|)&L-ryb56MU$FRm@9NvVx@*Bbd>}qVK+;rJVkn$;l#63A~3?
zYfjR%7woK3_63x;jKWkIq;c52nKOR}Q-1x|BT+zEQ6D_HgH^a|^zdKf)niCtcjD4E
zgZ`@s4^WX+9Pk_l|3}jQ3ibdBzVCNQZH9ZC3HT77jJKcbmF*aVtPAgi`r3JSf?0(_
zNe)N5{Y4?Fn1PsY2Odhy|(1DDg~lWr=|GBaa#xQmDJmR+8DkV`xGpd=W=Ztj^#i{@)m6N0?vO
z-mtT4npcjNe{WVQc;9?k0Nf^;b^7-MGC2GRVOuucD(s^&YH4`)cJo?%nF7p+NI3Nb
z`YB$YB*}p6g3&#|>=>X3P+@+Ap(i#gxbwK)SQeNp*k_oH(QUU1R+z$Em3v;x?_V#D
zhAT%F47Xv$a`*r-Q%idjM-b6G)_mrVTg=1Y+^G@#EGh|gCL+x^@yr=-2sn&5d}kb?
zriZ;O_l+}79CZhJFcWv!_Ex88Q{E%kR5|#C?lluWCL>kI)M@xgvh)=)+B{AUa+5=GlxfnNX2^lC(YBYGYZnh9*x
z_^)+-`3)#wN^`T-FTOvOfGnA!wg_GDDYox|DFJacCe+t`_i?-TqXai_UGd8LMHAvw
ztZpH!631!4WoAASd6`7RW{WOwLv&;eU%pIy8vYEPiInPm^dsZ&+dqB!m36G=Y@jk3
zPNlAm=fmaT|5MtRheO$hZ;zdu^37s|Dj+QMx=sXHy0xQ!KjOX5X6S&x-o_8td&E5&u9ZkF<
zz3$Haf3+nDWmoA
zWejHCwxnr$%)}dXibU#+o#-B4YgkclP`S}UQ0aVu9;Z+?{`v=rHLtCQ)b{wMqHiR(
z2IWl$1~<=Gqf?wQ&X`qyg_$IqHAi&dSBjwSIDq=ImX$+w6q-D-0;5z&(sg>@kl?{z{6N-tc(@YPWX9!1XCB3
zTbtC!KH{mJ;K3|zxSAjDC&?$T_!IXEzc#0c9zc)2IKc6-;UU>u`@xM2f=HToi#>i#
zqFvD3Aq6qa|KQz0=EB0BVxAv{*my?uWB#THIid*1*`PIDx2$HAPpPZ4lm9AeAcA7A
zph-LNl6k`HV@@FdgDV<(M*^edWIZ)BtB0@xQDVA6m=Huc%LLnCf_IQl-Nu>%tj78L
zCD*UivMoziWrw1;L}~>%D=E25^Lky|`s981k}(VPU0#6)kGG9%o~((Yr$y9UoQ8Up
z9htm&obq};2(pY#CiPj9Q}BN=iOAn3>N-NGe9AVywcm?Flc~^;1|kox+H?b()Bd>x
zZlm(j1EV{*VWv>#8b*5)E-M*IdW!C!5PS9)2qR{Td*9A;)MxKy^a%@<*ggrV1!E^p
zjQwNFJv?ILBi=_br~bgBPO&wtyT`F}H?VTaGLQN|
z?)>=d#AX?L?VZw`x@o&znL&J1V@c?t%_7e@v+wbI^V`S!Yx!)h*lTn1e`VL=nhNEZtyy!W
zjDBf+q>fu>GuiroiF+tB%vu>MC#`Yx9v^$K?pLcI4)+_FT8Yh$L1r6me?3KfE;=a*x|%Ha@SkU!nIls
z@$zYtuZ`PJ=Gm@Xy)1w(-n*gs!SIepyLsDTi;difZEEbi7)C{u_9-AvPNt3RPr7h%
zAdi#YM=`kx6=N55${AWYLa_`3KElLNPBm+
zR#kV$dbxlm%TXV5p-|3Qv$R-eim&-e{FVnty?f4Z*?qD*0-KI(?)-a5T60R$2c2nZFl<+TI&60hj_=?=!*a_Le?DYg$
ze%ce^a|*(OEEg`vQd6_{RLd5=TA*_D&FcJQ->1nwS6?3g(??(I^p^zE+nFT?xn0RR
zH`99^98>k|MGtmY<10k-D*`XSz3%tykSREb_
zzdONzhk*HB{bRqsSg&HVT~NY&(?nMn(`u(kL?_3Rd{iVOJH?%Igni^bp3>Jq7H^k5
zO37uACOmT~$DAb8hVEfC#+0heyVV87X+>V{N>{Y1+9ao%Z-nNIy!fW3zH{b*bUR;v
z?ag-%eco%b?ATJOF!iGk|0wP4qtl#E9aqQLVn-X^xYP}
zHikw&Ha;Sj|
zDN4y0%cVYZwIz5DnW0I~3$Bv|Hx+iHcl$R{v#sV6av2|70$>P#8
zQE_G+W4*M2+lMB_UN3qI#yz;k&H*9%gsJkbMpmLo3cT3q2A>Tb~~^T5P~
z&Y)@u>5altVdZ{Gl;ma+^|9P_l}G8{>nfx8%Kakkr;QwKmirFf+>qz5ITh2OCuDMG
z4cnZ{=B+CJHh7o+SE@jwiT}fSAHpB|WpRr5#=cQjyk*#-oYUTwQ3Y4DVkd4m?H6aC
z)cJb4`rIO_>?|$}ueM^qp|$0C24+dkBYDT2v+P$(rI@PJFEdOCiQ!G#}
zMxiW-@vi(xB=TE$xFr0GkvZb>fA=xwrabX=^9&dIeaz=gN^Tk9>D$Os9i3lN@CJD2
z#W<>B?9)869K>P@tNLZG(jE@pgL{xM`!iqaXC@DBsg3Nf>l~Ro$ZVQDcGO>--T@u?x_!_*eW(U@4mgLqf_*9R3%3E_L?Gj
zCVHk*X}kdZ8cKU8=ZpT+3Pk!YivY|jL``0rpSohNzfyApZ#=?
zD>6c%bk9J9JpI+FRNqz-8H0Ld6sMQ=>&QT+Ok9Lsj9HfcVbj~sJS-CQbuuH4z%QTg
zrYK1_9Y$H`K!<*Nee-%syfZ&iTAqH1zH^xWUbF$?;!XEH?N
zMtNwMG=0G63HC`k6LfSQ(VMCGHuk?}8bLGnTWS5*%xq{T_v0dC=QHo|KeT9hFX`=r
zJGZFsxSld(Nrnb)LIb4{Xg95|N**km9n^+BrRU*c?1O9UB2zC46dBJQb>v6ph{U_b
zR>>39!;Cqp(Wq{&39hP(6H&Vhc{4_hkTKzwZHMndrb;%sPkY#Psd{j$SsSaZ!~D|e
zmD)jH2O_3f87gDDsN6Za_IJnjfM=rlgl9y=Vd%5FJz!P|)R_wto_fcD#NZ7nq{STt
zH&vSi9mGF*xB?!fXqjGyd^a*Dj%vn
z;Jo)`jV@a#9S#Z9`1?yBLDs?EY2&g-$sRg013|Z=gc4??*ueETW0(G7Y0$&G$;`yV
zO**e6%l`#C%Ol5+Kb@O{$_L$h6hW_&1Bs#`y2N830mKthcA7U@gljfvY6!nxCpJ0}
z>BDwJ#BLF6Pu6j-17_A17C*Y7{OF*}Hw+vQ%Spxbpv6dD(bLM4mA&8Laf&J4j0djF
ziJvQ`>MQYOZapVvSKwxsp@w%lgr+k7LO>HlHzbK}A{bZ>gN5Ob1^~EkfXM0)9X^oJ5iIQ;E8vrSw5?Ln6n1eLvc@ICwk3Y~ZBf+SL)tE;O;s%4f@q!?)|;c{%$
z%4BEu;0oxd9*c>Am)5xzaSRj_3M*HaP=AEo=z0{Ao4?6aT8~3$YD=mb8b(2J!$l~X
z%#YTqjNq6+_v6uV5<3n`rE6_3wc?*Ye^VVoCkDJwF6;<_+GxZ*9@U5npK(TUpQXlQ
z`Jd3|E0&?oDDU&z=tRXYe!3bC3R2ZC%3>zyim=T;3wJ%v>SXr1z*XacxD*4ntH9T?
zW*Du&o*E89KNJl(0_^r*P(H6^LU%TX7q;kPotQ)C
zJ3d@KMKAJze1;6{7He0{#>U187+|O8`+a-t2nw$Jz+JHGUotc>pxcHuKF7}Vp1gJ-
z(LO*LDlzKL&dx?qss~;GLjgSaDD_nvu=v}7qA1Z|qp}d(NUyH1%|#Q&K5!#ru4cT{
zpNfZGI__%U0%g^6P>W;eg=%>DWLAnzb$}vxHHaZDUb)4Ro$9yWqrcec^P@eRlcu4M
z90ovF2L5vU(|4>aEVLVL#i>dpcrd_}ay#v4a0fUG4Yk`~Yi5*b6efsm|%|!cV_#a`_1+<
zhz|gLq_V2`5X!=Rw}O7EeBkQLpB@-@hJh`4BwDgU<}yq%#`)o$?NgIgAosgau{G9|
z2$Q+Pe*=_rS(%xc9nv&^WF$>hC4;C8_Mf_|wr(tSKvV>I>!6Uv6dQK*%5UA}@
zpD!svpp6Na%(2wiTJHSQLnzXEx?eE^j3gGeY@Wd+iuLb<0hD&9<%4kZxd?nI
zztsAz{c&q55in5>gZi8Zu1U7`bWIm7LeDNs#n>Vn>S`xyR?V*>o=<>`%(RhAH-4RT
zV4qeChKswGbX#AzSqs&`h0%BVagy{R-U0~4tX0JWQ#?vXA$lCUD9UM6q!_xrnOQRf
z71;}w8kbYti#VXhNatDvfedUD1{lRq4TbuwqZQXB4J4*xAVX8)`+bBSA;EC>a4H%&
zNts(9%Q`+eoCISv5_E!j2D8|yuE;nO)yT&uD%o-0;-q{)O}Pjq{R>IH{Z}6!7gD|B
z^1R=G-W8e7f~vk#IzTjgf8mC1$loT1qMhvxv`4=Joh^2$*d?Y679)?s9*k$2sDQ8U
zPX}3;%)l9tn*0N7F%Y)t1l7X4T%PF@zyU8t%~c-HNfFn(!)8Uic(XF`Y;92Sy|UZsiC#P5y>UsLttJR|^wcii1lB2+m`2r=y91>j6~OrFD7^)ZCqnd;hgmjscU;6e@5(;S
zQu@;aee9F1rsqKZliRM;(V42!metSu;OX^i^yE=O>8+n%Do7i^9jOK`(et!Wxb1Zy
z0XCML0)n3x)adW`fJRp#Bt$pbd>;@cJA8qIvI@_*BG50|d~&EduqyA7=W2-*#r
zz=}Rv+uEmb&N;t&)u58LwKj}J8&+CJo402fU$z@mI4$LC0&#?J@)|3h|KbAe?~gfIx-yhn-E!5DG1@1wvUkKX
zdCo6;1>raJ&`jR-F7U;RW0=4ff-|6ovGcgenUFTrQF;xykhIqQ0Zk-QA
z>E5IH`VuIMVOWjl{5(;;Z1KA#_423+JW=a5SVD2Yip6&jCb-??y->O#_StGAGN&3A
zw_UgBbiX@$q5GJRs~kk3P_ZoVW%#o-gERlPk8L{M-$>9sCm{rAW6$1`czTS#wNx?htmTv@Mkn
z$-v#JpH{IE%1M0)e38jC`^|f#*0&2S5fOUd|G$=2|4-|%|MAPv?*l!QOM5HDP$=Ip
z$Sp2WC?;s4G)76eUfPSX_U$)~NSLOrwjO#
zID&3sI^VBM>FV4}qBr*|C7J17*v23=j4cdEWiP{<>{+3t>)E~?LRNK@LJz1MRYSNi
z8%3?wvWD;~u$3aBSXmK!naVeM$o0@+TLWUfBISpU?&m3Hs3dJTYkb`SD(6l}#D1O7kf*fg>`G+4z8Awjorb62aC`+w7F;tG^_6LIH2{
z%x&~^d7&?iW)!Q&>KL3dZexcX%E
znx_P_{wc&3ZWZrT(xvwFqn0NEfo!Jl5#Z&;6!myY9cg1KRLVrAilK}yg|aHMLY67o
z8<8lBviKLr97aCq%VXGnUSPLRMDta+n*-}5#!%)2$mvH)-nt8k_uf?;-F%I^Jh(OF
z@|I@#(lj|hjH!m{0pEk)qJC@Lky7P>1d_uq8i}ESNh;YkTE>AGq4&`>6}t0q@`O6G
ze;xJw8GGlDvMD%el)O&TB~1vos};|ISQ=r*pt7%>Ds6!
zP&u#cDn>acwNcg)maoONaeLZpj}!g-AY;^mRILAvSb@mA*@K_F3{=X@jXhlp@}r*R
zk*ma1vm+#BJ*T{br{vV=Y>$J0*y8*Y1+Ep;;A
zLRM)(if3etQ|a~JHNhDqI4j0Q(N`IlrOR45oXeQ1QS(tbKLk$H(SQ-;4W;>#5B0jIAsb(Ef;*%8^Xi`7#!!(G&U$e18V<51l{
zXhilfNQYCiNaO!Q(zfeM_)ktMFCZK4M_gjHr*!>UFMYsZj5*sdamk)=n>CO}-d7Ns
zaK)(YsXWx(1%w$zBF|q>m~Vu>yX2L>o`yO)vC=NF;c{rE5RqA)6W1MXkGQ^+k{h7V
zP7+gns5pY6B2g2VEIo{`eW(v2BCL$G;&wNNka^mBN>p7I=VdZ>4&?@}syRjxs2-Tv
z_m{D|Ww@o74SSd*$elC|BBU=7dfoKq>2t-eo+OHJevcazV%j{lUMW5wI0AM)os|9y
zCGu#utC)KBj~$vgC60%(`Sureb*^87)AlFIE9|u#AQ~UQA*DZahgoub?3{4_?Mdj%
z!uavXi3#c6E?}O2LaI%FtURoqpV<0%*MZ|@8uQ{2U$dGd7LrG=bTBwaQ$cl;|};3oQRZj#oyWR@Qhab3$N
zIa3?+oh3<2NVV~|XMv5<)ZLL_^uVz!{VRv1^zzhDI9qz>W`
zL}J9qamU1`xmS5dJkX@0PAt=pB!lKIv(Yk`{PA*D1jEqQTmL{ZyOIwdM{n$z-`$px
zd_fU$f_eKICXlhg>UPM7n#VkgvHwCY>@Fs8@z*faFju_((Bvk2mCo0!O~f6>)y&0F
z(j2ZatTzES
zb+7f$^$bUh6eF({F?oD&>+O~0^Ex{3&e!|IPVslJ84V*~X}@Ew0P}qR6j3${f1@KuH4<%V)KGZ(u
zxh-F&??Xp%BElv0m!&#dRrZh4Ofi;W1P>=nHo}zg22&|=t5+)Jd{h^I_cx_2^@m%0
z$e5cQFC-br6aySfJa4iflL$4~gQdq)%O=HD&ReMM2%B9cnVR3ErOr|oXzq|NJ<>S#m@VcH1nB^uq*%
z$W<-NGCGMQe>?kzGBzYv=xu2^S)qgaw-2FsXk9+6vQZLN!KD|Z-
z4vdn(M4Cla{4?iu@p{Dpfdp0|E+E`U23`Cuf*qFPT@lnt_z%R256=oXu^*)Ve_xJk
zV{0XwR2TQ1DZ#E434gyRXPd{L*Ilct^C(DEjPvUju6A8f1`PvgQZAne1iBe%mv_TFO=f9J
zFQsEhvbWc!1sLCQ;>wPdXPU4WyA~P${0A8fN$#|YCiGp44^^f$(1u=}*>Y_#^?4bP
zC7g$b=N{x~DP6!hkH&`PlkNDCF$P_q81GwDb+DX|^XbD8xDU!aB7Be_bDwc@)U0D(
z^<#Ez#bNU=?E&7_
zfAunFyI;e&?*>$;pRU0>BU8|<%_{UwlY*;@3BY|!EXFGrD~;mlV0a7{{bJl5@xhiq
ztNCDkEkXZ0-4XwWGZW5)P`J{!uHgI+UMS!8BVi>`-k1!=I{v`N{<#6x1;2BNE$@~q
z>1*t}i`NYd4GHRjO0Wybb1b_n!WNEf*&cJ|&wRjjE1e&Ya;K4!4
z)CsuCmuRt8NDi3E;HC2waFEo}DEg)q|7flt0lN)*HPCaACD^^@V(+SCihEtfcv_0D
zgRah$1h&VT_tc0J*|Jn>vCYI*Uq5p1dvKbUTT!0}Tc+1_ZnWB+5LszyX{??5bRRLB
zM4E$>_qFPmsY8ZFqYb^g@ZP@2
zF%J^3Rx1JweXi0WxSH8<-T9>qz#%m%nB-1@=
zz}{sZwqf|()L-gh2#_Zb{*ip546$x>_a#sWGK_%F&nReJj$&IbIs|_PSE9Yc^aRpp
zh!+{No@>7q8-I8u#GeNH;b0~^3J?JR{{9#P@K6Z0^f_Cxlx;+)10Naw;W;p)0gCOl
zZ?O^p%YL~>fJBQ42N_uu3#Z_xG7zsRgm?g^5EpeEa9OxD=NUHua`!2FI|l85mCO-r
z3#ep%Yz=`!5nYYgUkN*75N><4rfX_m8$hA>T}&*uF3d@VOJU+4@Q5@5_}9GocgeQm
zwgmj@&!lTn`l_IwYi*!1^af0SpzAn5Ecryt3+@=UX?VhR3cxpyjuqHz$)Mk>C(rKr
zy4v-xe4>FfClQh+FTUPL4?d@_ufOSk^}GB0$VUZ$J3Q3sr#v4JL?U54+EyBMViboS
zGui@L2m2E}odXPVLBX{He=M(@k)7ef)wW{LK>>`hXIK+9#fW3fN^Z+{&;(k1Jvd3(
zfcFM?8L`9OJ8X`lb@!{l7i_`jA=kdx!Za{-3J0`R>Nz+&MV{qRIjkuHtGPq;DRHbb
zz9fIae)m^EMqA2;LpaaSm9Tw8Dd_#DY{spcJE!TJO96t!;0RkZ*Qa6(=nr`17C>Fi
zxwoFKWg_?={*Kbz_D6u74;HMNcHt=&KRnjy{z;V~#O7Ub@rIOx)!=9a-Oc#ztk2m8
zTpuYntGpmGq|ze;l`?GnmaQ)fqKAF(O81`-5N+F*y6>Yah$0R}MI=hGTBoXEP2L?U
z#aI|m4^^uH${aDL`Df%_)!IA>m^A8;T0f5(W
zy>sIr8^-|Dz7X>1!9E5a)X3*@g{oua+se3vCbCf@TVI$d@;hzGL{2
z-^84gr=+nCUKq}>DCvhsO)R@^gU6IJpy3N!YI9ZeErz60(aw##Y2`n84qm@a2io>4
zxR4?Aw8oigd;_?dn+%ZxjLC%AguM|kX;tWx4dggUwn5>38t%kqCE;72kf%3hh=_#}
z0^P_A_9Hn~y$vHkk0ksNWM<~B2?jcu8kTKVwawXSEXI+xS@b{w#&0EqDzMAPK`0tX
z(Y4iJ*;WPaV9RsE>3}H8`OVn0K#}3k(iDBW6bby6bBuyKRH7SN=DbfZ2t0T!xv
zT>5=37rP+6%24+!51Hv?mKJ>CD6{~k;az&k(k<-6;8u!oi8&Nmis*)Jx6M<#1Yi!1
ze>vdAJTXS|60Fojp99yw9ueElV0hn2`|V2p^;f|es2hp<=OO`%K|;DS87^s73e~N{k+804p(ZjCJA`48
z4A{^at++Gm?wt&nQr&;wj(Wfw&=XToWZgFFgtY}y+Im+q^N6pbZt|iNrqtOOE7=Ya
z(SP**-d%kxaQsZPIg(86N$%5xROBH&Ti(8ux=t53AkPb%k4+28+8epLO4AWz^}toi
zRK-n;Q*;Qv%?@Dw^KdePlFMSo>i+z;i(*>~wRZ4pKof46*GwSih3IR@aL;PReIoRI
zCVy3Un0IIG@u{Mg=A3@H0)~qW+1VdMe|bgXUv
z%W6_+%=l^w;~JvjhO#sFJSR3(F&);QNd5ByA0=9-7nyppRl0=BCDJ`oY%h+8$g>$a
zARZopT4ap2c@}*E?^8FJ)#WZguAqfjiuRvo`oq?yP%r%$S5FN#$)m^MZwd0ov7e|t
zh@R`pL8*k5rVE!brEdu8JcA~`ag()YyjY;JYvBUuunOioUlNz_v)}X4`8-_Tj)p0r}A3lVh<~9;vLcMh+e}>$0+k<6ghLMZGBx6xA#Tt=azCpY&3we~D
z1|+n*2z`ZQCj5C{>(0k^*4Kvv==0qVa^+H$SP4X+|W8>JaqP)
zKc%t%rgfR95a%7=HJ{ybkr8?xFOA}?2!vUKB!mW^i|u{GVJ1;#QQx&Y*xxWrcLS@p
zsGX8~(pzZW?IouZN0>EPkSy=$SKQ2Ce`l?aWeSo}y^<}>EDn~^r^PvyutOw5U)Mw@
JPuns4e*w4@!z};+

literal 24827
zcmdSBXH-*P^eq~i2qH+4A_5vI(m`6l0G6P1L~07N@FI(=f}X3E
zgN3Wd3ukkfhlhudwY{y2=?h15AqQv6)HUQa80-d233Xo^leRMEk)}Pjd$8H3FC$Qj
z4N=s+!k~SHOjCR1&y)9XD*-)t_4A_pw|=8~bhDKP^FwK`ekn5vy~
zJ3f`M?cus)d2Q?7L}%
zQbNdkSa`rVbfi^0BO3IHbBKu9l(IkTp6z6W5&28XXfAeBRlW<4Pih$6#wC*2XCSB@2E}
z`K$WWW?lwns(L^4mBl3ri5l4}wvTCf$)d>jh-FCF0#(B>~>p1+<%?S5}ITxtd*DQea33Or^kJ6LwqO0&DSkx`vuzXvTMLc8rOj)|!n3*rHqhv#}}r!Bz-PN5xHxIl3lG4ccQjU1>rT;?nQ7m2%<
z>FZBSt&KOgZZp}!N>s6!(#7;X{J4w_4`@X1uK!XZzlY9)mKJdi0iW61|FGp9_A(F^
zg7HMT{`{C4MEfhbIy}BrM+~cBY(YEiL@O_fzZd_IqnK7|(gl<)cqFoyGMZ0VreY_Sa!R9`7
zJ+D+8xqZ8HYJuMi5wY*-?Y@RGlBY1L*#F)SRpgl57RYQ9qW~XiSYeMAAP$k!?xJ;Cu8!E$@nCq{sIN69w+__PSEKeN5mWX<)}4s$I|r_C?)If*Oab
zHS1UeL(J%Np*i>+B7}@hyqn1Fdjy~O^|to>Eng~Az|d=TN%l4^iA`6=7=t~e#)~pz
zySBKHAKZII@7lhLJw|^qTQY$=U)bP?Mz5mXoN{|j%lr7)X9{z20)6)**A&fEeV+TD
zN?g5qHCb+jE_3d)(<40*vTtFi`0yx6
zplofhE$KlSU7n?3rK-lTN%;@DXwlpo`7RHS$fMCZn+(h<;AS68<3}y7Y6K7>1TUv?
z`o*GYUJ=3_1br`@F8i)!LhuF3P+i@+wt&Yk`d@~&Gixa}6zjA2n{=2Z5<|ahSRM}Cg{SFE
zTjY;qF`jwJ>_?H))8WGNO~-55#*JQ6bAPMt!oN6JeR&7w-8yDDTyEa9@TbPDNeQ%nyk?Svoowc#Q+deVvWJ$8#?xTOC>_!;Q&LMQ+bems~#Lz~b{AuXK>6(XA
z^s{?K1)nbxzO+!c#Q6RD_agphK46|?_Y@S!qLEt{`E`mW<8_TU$7*bcidV|Jh0qB@
zpACmxj{EzcdhM;~n|me-70?tTZ3b`49sSGB+5hX(C);1;RFK>bvZp%(u1kXy*u{Z7m&H$s
zcdYw4VaC3@Xk*M28L-q+-8!4c=vQ0-3B8rLI8?Hrkd
zeu>ZhJfEVKTi#ygZ#_F&E^%qSs#|Iny4}$&STp*qATJ|Dhpy+=??D|>5UqJH%6jcg
zrhAMRXj7bQM*IJGfjV2l7e21A=z%RXssD5_zRWCwb((3@EYuN%Rlgek23D8Vib~&1
z%}xPF7tPBY$tpGf`jXJa=1f^{Ny8fZ-BI_Qf4_E?hf4ZwXFFn=+B4++{o+@TcbD7W
z^J>LLRj8-Sj5@Yl#%dKbZhX6>w0b`IhDIlJ2KcJR67$#>kA;8P9_qiPP1_=J_WDdC
zkqLHNdKOzr5>?5s>4uFeeUIJeeyH)bS3m;%!ovHqYi*INhqG}Skihv|;-H0h
z6IiE%<>%*J{hw4=WWB`ST)3=^nIOBwSZeb1wQ{#XrB#e8)w6onDRARNlYbqW)x6G;
z_+O^OA3wYiSp<8Lvg>GfnZMCtuw$7-q|yc-*5BW++&xm`ue!uAJ
zfzYW0L;I4l#b0z5FN`&KZs(YWoES^I`XjPb|-rYolq>N)!
zLFRr?%|J?@oCBZeFMf8nZsMIRl6)^W?`D>=H!@l9JD3VimUgi?@NM!hp&O)Lr|C|>P)4AE1AaEB3LB}i
z6>}Izj(aY!fq4d0~GC}xxFEC~DT@NAC_Ncj5rsq^86Q#CC7JR
zmwXaZk>;W8vx3bUi(Fh>qaG8!qM0fzqAvp%wk$J!6JE5uHRo(Xgarzd4Z^*-2C
zG#ow~_kR@sI-CbPC+~T)UqD91qsVJi*Aef){O?S8tB~Oerw{efQl#vmO5p^Pfc+S1
zXkW*5(gZFX1a|P+UHVmRXISsCt`1_6?7rP-tK-rnjK4xZTm_ba>q$k3rtV(m?C48?56t!NbL+d2pq
zN{wE-`Oll>(q-H}dhf4gJiKrf0V4Xo2jx4`Q|&5VD)^l*U^k`@6+cT|exgdm$IovH
z9Kl6f;?~Sgh$2NPofTu%k~R8Njl1{7Yg0nre(*CKQX)6;`5BP3L&%*Bujzdfnpv$F
zxNrTJTmp2b50%l0o&r*yy&y$#mxOi{;{wLT!uu~GewpGi=rKlDB)1r0RH!3+;kcOenzulWMK!TSXnPW}6tnq~
zTRkmlSp@c{+K!dv0@dWN#~eM@*X^rZ;@ctT$trA%D2v%GCT0!z9oBzFU)=4E$wKK)
zrRb$y)%e_3{(OyMyNg2QqYHId
zXtX~XT@q+U8OX&xql7XhlbMx?LJnp?YVym9c1LqE_gHT@|NDo>^=lJ%zZ(nqx2W!a
z!B2Tg?-E*KbNB#Wi|>8#!FmvKHlaa(mT?H=WtLRT-+aGBmi;HR!xmQnsvaHuKrFJi
z7{T=WNV717IInOiui$a=HQGA%gNk-&9ie(n17O1MJA|kZId~U1gfXQ
z{4tG(MTaUnR^V5~$u?47PD85tGn9?#}_y3bT(qpx3Hjq9CqpH>;nL*_&(|b1Qs5?FB}c!oAN(@)WOGjRNto7_%WVC#Vl~N1
z>#2zP=>3gL0abh<(!xJH|owz26UGZ^FM2Y0QY1aZT%*WE>k%zMtOFS*CIguUNM*
z34xko3@W)Z!KUG+7*3t+;A!1$kC5y<_J6j)C
zax;SijB17^zCD2UU_y71O7%*Ne7IuzB%H)8;;ZNHe>!Opcbo+**s!119&D%1htLtH
zqfoCewXlSvSBn}`%yW
zX%(XCd9SzW|M(C)N^Lyv`NdK5mtxA%L^v%hpZ+JE-W#!_JsT6D4G2>2Q;6WMA$((?
z5obn-OD1+;@dKJT)&Gsy_aECtQMc_>AApl;5^)yfK=RD#!mo%tRuRU7`=~Q+xG(1z
z%W_2L6;R_cTtPp}gBD15rnDtCSKf-%^eo^W)bJSXziP8mMFJD>-h+;wo5-hGGz-&>
zerCJt{jG;F=I@wt2X~-&Ksne20nV8Pp3l%UZ7gb&Z#do8sUq460{v)Xq)@Zxp^6Q(
zWD!cKpcD?nLVo#BJ8>g+XoG#bN8{n7*<=ZB2wrZ4%D4*RLXK_1{Fo>{Y1c-Ko1$(7
zpFl-B%*Om$3}#tRlXOPuL#9fSTYuiGgKmzw8WGwFd{622`|tEhC>hwpfES4UpgT9;
zM?47ah>cN70$&&VBqWq4He@AIi!5FJg!W_HF26{6dZ-njNPBEdC?Vu=GI&jga>Bn%
zyDDF79I>1dXLaJs7Iup5cbzmuk0k`TBon{*?=r3FP;R*Q6KUGj*iTw^t)3UGy}sM#
zLiRuU4^=bD&W_udVcNUiY4`7*&+VBllkT`aC$BAe#DYMthRg(MhjbwMc(O~hcNeJA
z`es?c8CL0ms4jA|_TieVnI)X^)G(oSKSI+G
zveMa$Vo-jhCgwWwdu{oB$o47KNuRG8EO%Ho``b%!ZdA(ey{d5sl_PtXUXx}Y4_C?K
zC(oVa%%Z@d(9cpoxg=AShP5-tIYIRo^++488*sw~o#>u;xN~RAVqG8i6bFl)_f4%G
zQ_>#N9SCnQis0*A7nleWeT_yYbHO7W=`_vmjF9KYe;qiXYKV*r9Ivpsy-#pGQWfMd
z54_5W-9A$F(J{#<7Q~5rT7c#R@%R(``W;8rI8NYVoL}iQ>}zG0>WPAhe8+TCsjhon
z+u+AmPMD(D&uPQ{u3mb>(OT=VF$
zf-iOkOCKP_%Wfl~?y<>(c2j=)O^o(c#${7g%_sO>=%^Sn&W5~ac9OnOE%>Q>(goYh
zuSw~nnrLHO>=J(e06rVRs|?jYL7!(qJTu6jUc?))(i@>Iu4Eao`LK>w`*!j;Zo={J
zV;+=>-ep5KK1JW1R*l-HnM@?5`9*|b(7OTG4O47<)oQ>-IM!+3g=F;6!XyU7mavi;
zSCNoBi47@}tPmp}c=EsLXRCy3a!@GBriVe0JsPj8y{rA<>c-u)x;N9-L?;}jdMH00
zxI{UNWf{mSP?gcBxX@cx{F;k|KYh%r$Yw?a`cxl%o(stayul7(F=KwI#QP-l3Y=O4
zVN9~1Vy*w8ff8bfQKkMht%R}(?Fhp84$JAnj$n39DFtCskUAP4fVjooaPd3q^6Cu}
zC}i{|+^wA5Bmkg2(3d={Kaop$JQhyZdwt(X!~E#Fw8)=R4@LFtjyvd619b58jy>z8
zm5?$|!Ab5(ep+eqkORtiE_SWY1xwm#3rLxFQ>3#ojxv+TtMU?KrVFuue@J%tdh3Zw
z)EsK!haoTOpDdV&KWw!1u*}d7lHZ3oLO7WG9diDd`@^NDbsV?g5(=}#d_31nT&_ZL
zh{i9ty0;AGE~!lDXCEM@sUP2u3?kIXYOg18!P`mcjED$EY7BvRo|30&RJ$mcq2Lr9
zYKU9dy0s>@kCMCxHtiCKC0|Xc8c$6;*P85y`?zxE)M~PE+L-Rwp+zEp^z7PTaOWGn
z0ttRiMLS?924#O{6-$wcd1jlEuRguo{ZH{OpeQ4eP}azcW4BK2(v#k;ajz
zjHl|D)v-!V*%E{X5n4}r1aGfJGx23QJ;qf*kADfTx#7XE^KCu1Wa#WxZ0`E%{?q6wcaUmBF+^3i|>&vK7&s;{hI5OPBA}uepJz#)gbW
zZ@)9Ij7IM&X8P`t3K2b;MDEjdYp0QmJ=etR$#!hTrW!e1C?+{cvCJdM%U_BPAWN_W
zTZ#VWSBOWy_30``q9RD!+MYgU%<011b;T9#+rksDyaJm$Bwq8EX{8wtXnuBB#&HD1
zp?3=>KX!5auEQmD*$ciio&WX~!^7rS%#{~BUOU#&?3T!t>WWLYb1e_K9{;ULIuBYW
z35JFHN?HdE%*hOJI8(j`>j^*Daa4I+wqy1NKtE6sQ;Z~hi>S9Ts?9p1gmYHXdj1M4g9&n@B#P$%_kk
z&P7&A@vjgXppTTwtkt@WR6{8+o0B-Aviy7tKv+w<%~IqQRxq-twvt2AyUVH5uOBfm
z=i`AMdx+N1#@|9$UH-|0nXqg=!r8*hZOiX3ke~(IJ;xV}Gu5sUJA^A16(1lE@F=1fHAF5wp6~ij@TR7jIjPl=kk;N%c%T
zIk7OgsM=#8{Z>;|DqbB~1+7(BNJk@1f(0>{h*QC-Y-aR1EmZ1b2UZbJHMM17@GXR6
zQ{Pe7^(_JLWLDa(($r!z@uej%&CI5L$gD
z4;!Jg=h&NMZNMx}ocg;AhE)TsN$=+dd_u*#7yRLIPb3PwmPk0J#4R8FrMzwwF;=t+
z5YWxBluve-?q8vCV8^=jnMQ={To%;E3*yGu{|>>W-AuNzD1^zic!pF~LF~m44QH&Y(fOvnv9@Vi!ICXTzL|8x
zf!3PV3^`1|W+}q7b{WuBBsbuf0`_>p^bT?D7UB$%OuvF)Ruglzw~C2n=Nq&Vc)2b
zBTmxZ%eodqW;yla$F)^bTHXWuSwcB)HkLA3{y>WJ>*|BfdFK!4w{dEmCEv9!A>b_w
zoznXce+bGIu3w26x!)Fd8B}XZue~)79KL@%XEdyu33Kz$BR&Z1>YTq>@>O2!AAQ<_
z!AG{#R+styOeZ?8$~|0%$-_?Mmv&Rt*pFV`yE^#Jx(J>DAFqlanTvsI!)9Wg2d%rJ
zX#O;PXhiUz-s>CiF)WL=;1!*zh@Hlp2l;ne0J0rB%bil=WWUFV?sp1G8GaDoV~&Vd
zYliWq>d9^BRoC3zQT?Tfcfj(<>Z}qQF*zbw%&$goa>B*1y>(HyqJ!irJ$pVs{bw`%
zgU(>;EEST5>isPq5YtMNtQX@~wcV6*d*d`vIT9i?`K(n-x+WUvXS6=ri~L<0l-#$L
z046xNI9LE!8xbTKS2+aD%5@sVW8LnTk<|qm_pLc@Z*iCHVlkIOV<%ksM6#
ztTg%W3t}bMyHiNn71l6l*~EA&FOa1LKh92Pa=dO0vL(Q-
zC6Ec|)bH64>n3~Sln8ABlPj_S6hd3SbJbEy$!l3s3)
z02@4{k!A3c2jE(+Mkc$T|A=*-)Bc!;_u5?(9BjTf-OySefLVXshMrlE)k|2WyD_%2
zd0dCNEcBY=utc3c!#+ogd9Nm#(gBpsw^lvV9-Rkp1z5y2iLfDK@5?aSEcexs|Akcp
zzz@}zAzUaQp@k+(j
z1)8q?D(5+6G@4D?*=*GA)^mV(T+Fom^-+Nj9{*d)epIi!yIXc<>Gx;D(V0x|wK@or
zahd;-Gflh$0Np`_a7M1m)o($UTAb2ddZnFe97ZY&HK$mGkpAs#AKUj)@NmkQO|WYlNvS_^D?&ps2V(x3GlG%0Ad6_92|6sX{(bbQ^c}2
zZR4nMZzTLy)E{XH6;Ds;IG**iEEBK;^0&R!zeE@?CV=cn?Z6Znm~as+VizMlhZ;Oxzxk~)@&}UXz#j@dxIlpRBESA~0wXJ}=+UL7J#&kC8{x2)o%U;ZFNqYh^1L%Le
z+^H`>IGYv#NUDYT0xps|Ij2`ge04eQ2wNZ^)x!SZF8R~9zmjw8jGpIbM^QS6VKz+q
z>^|~m0NMjDb@r|!EbnnN`_$ZB_m!VuF^p0rY#EK4yM?|47Pj6nE1Rx+17+?cS{xw{
z&xqf8`EW4&i&_3d=c&Iy9LFT-Fn;~)93ap9XsMgB-g`Tz-!t<=>3Qw|R26nj+zK}n
zEzfSeKkmI==Hof-lC}#tl9=?KmDRsB8vNC&yu7?qC)<4soje{K3-X(`%GE&viwl@oc^H
z>Eg|EoD3i@pYS^-Dm87V&hVU14veY*>&fo3@%3k(2JpV_n8)nNG0a5v^^4p9s?}X|
z1JnbzTST0?OsLQ^_g-ZY0L4eNCO*6@n_#!6r!zR1OgZHpjb=&32&W1FPjlS)_1FdA
z#b^VtWhXWVwKSa04i^R>G{1erX4{5ry!NZ%@*pPTKhkz8|1#Q3U$lJdhSSF-mYKFc
z)zNu0kgIms!f^(>x6qsJx!$;cXT~&;1U~``bfRk${ls(({q7%xf=K
zxKAF#Gw&^6dlkdL3lPYywj@zg%v`)K0x(X6M&D~3CVHQFjI|PYsIATRNLHq%&I!Od
zsUxOHVZF%kxyGgctp(Wru^|cQJ-1KxzkdNQ@2YoO&d>kjDSuqkd@2}xJ$9JrwPBTw
z0+<n`^SFdJXVr2)#^FVmJFXqfaLh;P={^nepC
zf!$*-Y)DCi-f+k!073y6CairnsDqL?ja>YAXR&4CY)`5f(3KloX7*=~4a#1Utv4Op
zADj+7_wVV5xz$qgq@M@_wySUIPQCkT*Y42szU7kU-nqo}w6!zftC9M=bKd}LtzTt>
zKJd*gEWd6QydCH#u7bQPK_4R%@HiG6#JPn}wlmLXfeX%lt{I11e@&E`l4ts#c^>$-
zM;QwWZpv=|5TlsjFsO6pa%etvA6*3=o3U}580@pjHdY5!UP)mPEX)tL=FrA5jpuN?
zztxd|ZrEO}nb_*$FL7KcYj^IG-47hv2WWnmY$fsReoM`FE&c9$*@^*N>~Tzde0-SW
z)f#EQ1{DApoxt$`8YByl1P$kB$5X57a)-0;qd11GO}>ZF0s<+wYk8xEW`A^CgOFkX
zUDmQb;kl5mOjDLS19o8^U>VWISvQ?O`fm3~RlXXI1q6t58;d1a2#&xZ!qSPFwmo_J
zbi;qmnC%jdPNTBH!JhwM0;P2wq%npj5qoe4(k}BNPSYq!Kthhs=ftTiFP`;+7|A!b
zj972jzRk~HxOGj=2ZKqKn(&E}ux-foD_8-P(npX2ruJ*b+ztCT%~b#+fY={(Ib13%
z`8QhUQryx>S`ubi1r_h>8M9&BgkbqHvkDnyy=2_NX}){IJL?mffJ;f_)yf6oKv}26
zSPgL0ASX@(o-9f_!~$%n+PMV7Z|iqm|6Msd2l2gS*=DF%ZK7$s@6Tm+WD>abpotQ_
zve(>dDUKi{yj>?^bHowF?-l5lu!E2=6)xNaOZzGVxK-@}-Epvx-7kXKE`Y;G!~6Jn
zbl8N38F>KM3~!s&X|pVPQU(ikqX9cp@4EP4e{C%M6OUnt?sP#ho*JibvtemKeG!e>-5^ms71zuu~qo%cv8W?00JZsTu1;kN=D7VUymRpJ?)&mqleeaJ1
zYCydsYQ1G+@%N(YMVWWVf!~&g!U2zBhzTP$aKS$zu4+_nLMi+Ecgl+z+sjvR{n#1B
z6hdt#_l5ZOwx01=>M-u^rhq2CAu|R~7hS;E7Qxa|HDsK+EaLObd$lS)*Sg~q+g*1N
ztDheN+X}n6X{|3}PJdRz#^3x#3$My12vW&}X#eRTBS;x8$beb`F_e{KxBUC_`@}?&
z-UD;D<=;I{sCc{ahGalA!+NhEt89mQt&wwcbFaphBHEtT*gsnuRPuX&3a%u|k#G(O
zIUzd8ZimRxyJ6bVh5{%v#!`*J>2~eik4E3)s8|bo4i4GBF}-{6oB5C6jzxEZAc*O6
zOp^32xO93e23}CEhDCXQ
zJ(D_9vMhy~*sY$hk1}7F$@Dp6Guv`{EG~E9eBqutS#G#ui9qlcVqA9k%o?wr1o*S7
zNsDF3b>L?TTDCnimO+*R0Sm_t|xd$LSPNLrYG
zdjL5aZ@ZRk^BA>6a_n7ng#4%X6qND|WVF(W#E|PpF1^DvRug16wh6~1DtVXoKpk~9
zJ)WqP9AZS(KsC6bCwsNS`Z4g^OY2cDKv7Q-=6&BU?T?bBQK=?ZU!F^wz&@_4ZGa#pn{e}eD
zXT4Z;&YI3eu7=>o64;}Bn-49NAswAK`g;|KRQqp>UZ)Jb7@Mnd?Y1;j#!`l))mOMAMgr!M8dI;_k9{_
zN%Zzw3f|V&o=di{fRu2Y67KRfEytZ!IV2>4tT)QQh+141-7LDd6$?`2KH&2Z&pc0K
zd!L{MYc+feuEYf3E*Zfm=}D%DJWMISSdqq(;;t5{OFR3LqkR}g?`TPa-WU85y#
zx6gX)HEJisw2XvuZTg8UD}!H~UXAWFOmIEXpVRUUQ4}@3n|J*dV03=49AbitE3$;+;AAUN
z!aeA*B|9v7P#n_1g4+f#*Ih@xOv~4iU7Qb5HY9+H1ELw29pExIG|i)cn7~qC(Jc5_
zcKgeM7D=HG<<}>KRP~rrb`j{_xF3TzGtqKEDyUpy*=$A!vXO$Nt?PmBHNkXnp&gFk
z?Pss!`!-Cn?`(#2+|*W+feAA{>?a6^OxA+dcu(SbMO0*xXZ(bNr!svq%4g#|>^Jn!
z_U~nPzyW|5pd_+*!t*B|BBx~`MF#s<{FR1|2}Gk
z?$dFDxwv)|3fp{8)Fj`bR}RS7P8nL3w_NFIDk6temn8Y=hpZr>`nr+MnDr|2_|YpjhCd~3r|l$#CIy=F-vX%xsvuJqS2z_qF&IgVG__%|UdmsInX
zCb|tiWJAT&a?lF!O*2(ur3C>MnZx$elIw{xW1MG?MEUm;k%mq4Z-TS~UzrnV`(T)tQMynuI2o*~b=O?Z*2CPxc1nmO!v
z64xhY&6%kcPz>*v#UE__%)p`H{oFB;3OSgVhQQE&djR6KdR~S$$n_z8}Be$Mb(aFS=KvTMLa<_N0gmv;xN%@Lq{0~
zfge8a4+$pfva?v8ZThV6y2p-IHdA0xn`Eu;j`3WaRjUtQ@A|cSd2nm{W#&!)ugxv@
z@@0+^`<9xu6LUxsFi^$6aD~zEVDA7=;9_`X;?9L((m0JB$=08vzeSf$W8lu^ebpW?
zZ;U`D$!Nx}{H-*uj3xe~=(9h1jeqI#U3;r@v>HY;SBG=-4r`kY+aC!EwS6bq@P|KL
z)W1!;NOsa|YDgvo(B$EZLeKT53*L@$N2zOu`=Kp`POczanqvz86ypP(*w;}uE^R6!
zVKoX!ZLeEDdrVWgIL}WsG)s-`@J~<<)mDZ9^HBZxSnq{s@r+m&Djn1{B6*T3*=oT*
z<96_;mu|Nod&3-gdIP-&HqJ&gp5Q&o8H|l9!tzo!tt~DUT&8lYQ86nf*ya6k#rfs4
z_`Zs@^(%;GEn_C*+bi?cdj~vh*h0r#^39`>cAcRdl5wW1TBFkvc2smRf`3R~a8sjw
z)loR_wNFpBh|a+ce#Pms(1;v2c;zcV|T~v|bezCTWDzd22
zQzHLh8X#G7=q3;{=VDTRSH`Uh$jk96{ifx0?yv>Deo?&Y~D&
zG3l3{a^2&42eNwgHYG_O
znA-qy*2KiC-iho!%7A#c0ux4qwMDx!Do!M>ge;-AXCBt1&{q3ICb~2;)TH2pW!&egupPB
zggCWI5^ag~LUvkdCJg*duo1;56*3nxZX^j08=EO$f4bU}kne?C#BJlW_Xj@k60h|+
z^Y#7|&Wjt%AsIe@*7IJqiv9fz)#m|CG{RO8Zv}Rhc{r*$DeE!l~s_)t&!1f)X9YlyX3>G7Flk$ij+c>;m
z3`DlCpFWPDczNZg0dKTMPfaINe9o^`bb3`?ZC3SrO~sX(h!qwX
z)|OxE^Pv+_LKSn}Rk9KpZsbX(D9}c_ILc5r#4MUnMxv1lLL`mDemEuZgjW$I`N~!z
zKe;1Y=G@jLJyL?*lvcLH99cK=A^Sdc?VwgV4O*3K&^ZAV>iXrPN}-Am9y;=6X~#Yp
zm#nFq>Ei0&winxwn(X~~UAGOOi>-pm7S&J6Jt>mRI@@yiAnCPhY2G)p=4(-LPvoR(
zT5az?Ni)VuK}*xHXYp2tQ3Hx>Zin63I5xwAWl96NF6ApKs2gXYI-g49|x8TvR=12o1%|Rp7
z1d1KXC?Etb>Coo@mo`kFQTtK*2*Gt{(gQD$cqU@LDKj03)=X9EjWR;*wuhJwV@G
zkO}eOgu7rF>!Pw#@}mb#1>+YvwuTwdvXUY6WW$5MuUL%&m;{^Iq|$G{
z>)mXRkMHn086e)6z6rc$8bR?MoPr}n3924&uKrI>*hbm~NWiwFdjxGFGyQGC8QheZ
zKuwscet^uUhru9S$B>P|F{`Pno33NF77eRp#Nt5uuQLq*=&d!MpVb};|w%JCNtz78cI)+@5z`{vA2h
z5-bM9@X9JGM2NZfT1iq4?65cFH1kn+*Di8c0x>!jhg@2n%L4IFAZ*R>-O~q@z;}ru
zqZT0Hyt=)N0H{{o?r%dPy;2h*o^;ozm}g2#6qm1we*pM40P6ayY;`YCG2?)Uopt|s
zCeQ!;Y>HG3$Vp&#(q;lOm7oQo;MpG@2#>L4*_g8
zUF5|BfN%hUA%o$sVttv0Qqtry!-*lk*{E7Vn~q{5XxSgm|7tKf-`3s#x6Y)@q2a0
zYhMaq5g=<%c7GrykFREx_w&Jw4QR*%x~Nb7{JPk00Mg6Z7XdR+I-DOaWVVkPqjsd4
z4QX9~<*8(YfLB8XK7`xv^EDwXJKdGfkswRotGa*}Xq4rnc=wKdd^nkyv9lJbKEmXu2$nhqHWI8f=XjdwKJ&_Zxel(`6*9g6&H01`+&;DD{$o~CnaT*tEr+G(u$-ql5M=GtS_5lGX_)F`~$zDzK
zCxAvz?Q6&#njM@+%kJsbKDGJzfe8FXXnQDj&M=LVe!DjI#k;N4qUTx^xBy_Kq=>6S
z2b(j}8#ofJ^KW#ez&-B(fQ}k5iQOodKV8(wqJgmt<*Kp5&OpP(pNsw6b}|0J1UYn3
zMemkT;yOU#ImW$~KPwAfjoJ4ptoW#g1pJNNr~P*JW!YxU*{u%WCV*6LoYTmkI0Dss
zvMUu~>9ulIi9UdU<^$NT3^l7?O{aT?1U_d@!t~K}1#GBDKaRho;m(O4=nNrHtxEov
zLzzKy1Yp_-{0u?l&c7hi`U2P>qxmmjB8g1Eav}ldJhd83&DKTWZPw*aHXbGjJ-en@
z6vv~n7vc8xH5mm5p))7qy7Zm@iAJFRr1McN*(a;@O&>tX#*YWf#Xk-=B1rT>q-(SP
zvZ}*N(P}fGHVC-6cE97*#GlomTVx?lL$09QXLV%O;?L@6-IiH8SP-Z`A%lY8=wQw>
zATmvX_7!L_ydy~wEX?l77-%#gncR76)aWHKIeKYzqFEl`oEFWed!}Gp1EOBUeMQf{
zcIs_W`w`$6F>UogJD(FZ03`X!>&=JrtkmFsDqr%uDx_lIU-pOrdOGmo{u{o(@gTem
zYoKlm3SKVx3wFfFrjb+Y)fE8If{rHswQ7Kxe(o2z$my#kvD1Ei8n2zi3&Pc1(0c&~
zHk$!dM$usFVA4Bae{a8wMTRv(PwIH>CUF6S#m`tB*|`99!#(MWya?YExB3YyVR^PZ
zSP(bp1oGDNMPJEt>Prg0xIvy7&g(x0jIGyRtwF8hi-U6zF>+r#wA>rAAFB__lqK{w
zDT{(ur&Pc&l)A4P{4Rdh?bOc3R3T-k2r%|!gwspqg$RbRnPMQ0x8@k=WA|S93YfT#
z78>~c@zzd3VQ*?a*Q@l>M=>y#j1cou%r3c-d`0B>@u7n4&rQ6=iq>lNg{pK*z)R
zCx#Z#S$4(G#12p_*F8p^Sd{oS1&nIn$%D`{wGR>tQ%{OS_mVVVT-l1d9xzdv((Qug
zmoh;9Y#f99mKJmC@g0!*)*7~ZmH#p-^Sl8aEt?>%y`9)!85Ua%D`39rIz8OrDb}4R
zT(V{G#a$2((JuhOGi67JZaT_xpf}9qU}FjpJ{KJ4uhYmT(>Q|cGyt06Hjc&mka1uq
zmG&R{A1(3-HJ@xHWrh(tyLb7$Wy^YDf0
zEZetWryK@xsU&OwL4(tPn$)jCU15NlQz7u`vn~O6gD0oeo!?xLekDXC7xJMc(7sj)
z_ILd6RZvKbeDQDqQz~B1hu!?u2ZMn@RRDurLI}VLsGFewujyn<1=zv*(*iv~Hn4Go
zdL;A@q!G+9>aoy`C8cFE&ZFynIZAQgmI2+GO=wxE9M703TfjVMzU0@p`6ET5uz&rB
z|M~IrXB8G|pN3Y3EBIv%_W@g9Xye?sdC&+tiOA7vuV!ESogM{6XLfXuWeox1HNJJ-
z*{gH`b0-h1lWMADB#8T>4J)9E0G)hI7yT&-%pAx}4xgM6vmoZZJUQ5mUtnXvYKcEO7l&Yk&4*nzm>T4*Ru{TBln)X^sy@owE9WeKwRb_FCjx0~JkC`Yi)}
zef>|OH4#cEvjP27NxOd_449jn#~Y{L^_T~KyFJR2NnoxT4(C&Wz=LlnYc}%rvXSFg
zGA74Sr}oxS?ydP};B%Pe&ovl8KqpDsU8}I{vjD`r>&l-P(8c5Oje_TAldt!LDVy7%
zCXlPVAux3WF9d{l83_FbHTG&X_G8R<%q|KVR9J73P4%CZ1fW=%c0)S>o9`ASgGsJoHM8WeMGXpzb47q+(l$
zM`bZTTW>D&&?S@ZP%ru9)>b-9WB`{fD$38dqV->1%FD?yQvfl~<8maoz3QD&)Oirp
z)?3f=bP)6&F`I5_dBd#iF&I1%^cwMBd
zrAb65kVWHvJU`n?GzvC}D3~YoJ^z244FHY?4iwsxjU(>hUO#}-3J#QRY0Fo(#(}j>
z{GaFEAWg<35QXa&>CsN|UV0$*LEL880(2~+_4hWjAQkPZ(dE_j%>S(gIBSBehz27K
zs%bYeO>>S67zaa%0q=#OkKw_(WHb7Igic>aw&Iw=$p&?OlRx9huvwdX@o)^%ZsGz`qAYcTlFv+#5-REmnk_%h#
zO&AZ6UBE3DHpP0>tUE0WC!Fr*VH9mlGr60bsk6d$f2J5yV&udP+B(^gZS&z6#L%BO
zXSR#88q+M-cO7neU&T-)#q^NQa;NoS_XB9q=n5xx)2*Q6yJt5ynnHXMK9e#iBXCq{
z&2zdHP8rxayoBUJXuII)1AUB1mQ+o_lB>z}Qel0?dzut^!W;44a;DH5Cq(nMZ>J;i
zmLlSqcxJSD@%5as7J0pcMpy8Bbs7(QS`Piuqm>7=;x$Ay3McZnC^~LU1@@WaqY8vZ
zCw4oUODgH#X?&xo>+vpm?abL*bv4b_t~d4X*3C^+qMxTGW$vwyOQ8(O*b6)Q3Z%
zS1&bO{J{`&)9-G0hZB5Deo}VwNwbSy71%t{5Kn&=&KthftTz@s*4&tk@DKk*!ILvt
zn4S+XyfmpAC1^;H)|zIAScW*=QMvYT&6av22wDqqiTH|;Kd@>qSUTn82bs3YPb7)i)8(bF67bK3ziZkzrV(>xYXFn{JV9k>xbtW&$o@!?BX0
zQO|C|OGx}R@f4k;@s6#x;O4jiPJdIIyS+@9c&Io8VeD(d^%G~BiN2?T9?O`m+fsjx
z)+jF;5yczRfj`1NjTBG_m|C{KR%|Bz0xji+tQx}hXE;BZg~!%lE6{Fsa8@4I=*Osf
z;y9(xQYbYO=8exGY4l|$sD?Od290&ej$R&~LU+|FrUhdS88BSvN)O{_qFxDR*#5|g
zU~iR7y!Q$ZQQVjjt?nrJR~o)pCB(i{|1Sp2Q`ES-N*zX)-+6o+PVeJY`>DmNoTVa8
zm!_sNN|#f1_(p(jQOJrA+<`=6+9-SA7e&(Sd_>Yq$*NFARujsf@HSCNqHwJ92iczj
z0Wg2!6xi;|S6Zq)cCwBsq<3C?fSMArOj)!xP_yE9r0Q`*t?w|?;uS&fNo=uW^oUuT
zv}GSz@F+5N;>W(x-X(9o?8DE#&;DcifG3>=cjZGCE@TT}EQM5U<#G7lwqXV2$_9aicIbvvQ52_FMj$Ee{|6aG(w=rBow&7JI^tUW!
z#J=S`cdP}$vdV@29AcCOg`?fXd$F!VM5(4}w=zCj*}Is390O`Eda-lrH1P7cm+Lg
zbrBp_vb^qSOGhNp%F;Eh`vKlNZyc6e*Aw5%!&m4Yu^AHpWD87-}{XLF1om%G%4oAWU4sg&BLUh$naVZ|!82e=M{EVTxOi4^zlb
z)P>+`3TA;J4I~2OXP2*Q94V29S*}#S)0WfMuQFA=Zmmra5k;dfZ{&ONp^@+Z@&Uu~J>p5PetrUCgrHXuKi5oCEb(lg5kMn%+UnH??SU8X40KFo+7R(6V@KJM&qZU~{p0TOeIOLY%vTWKl>DMg5us&X+kf`W
zWAw|I+ZH@IGiFUUI_7%=I$B>@_K+>SbJb4?tyLYGq*cyy$mb<0Y<7xbd%1OIF}C&N
zo8l^wVHRg;z7+Atp^_n{x)B{raUX3ffIhYt<)Hd?u3S@9TQK
z%mjnxgePGrgnxy%_XKrVm<`sX*Xu^C_h1_IBm9)qye*`VU$pHDCH^TzSP7|4$dCF<&xud9M%I2GZs3<
zKgVCp7Dh_C7S{RYIneASrxs_}ssyTMg`
zk8l?Km9Tb|DaJh~9fR(hz2m8Lu^AhMSL$u;N|NXukr%mtA^Iib0wAwaz2jtIaPwx$
zk8@cV59CfXrusr32}|VLf*WrNtGbVG_z*4pEu$uBeKh<;Hqg|C!F0e)-Gbh3+Dx)0
zcPU`CTxuQvySe@mkoD+iu_;Mc8X26%=aH$+8Vvj$x=(+3SY9RmK}EQVQ)-c$ej!nZ
zwQ~N_^(t!a3t{aH>Ar)W((9|^~TPtT|&C{T}S=I#{FzQ%krTg*2
z#AEx*UwQQjDoqGiOv*y9hClr_*7B>F;VlRpSq&m(o;a0X;&xJhG&0{UvWL{)Szo=F
z5Cg(al*b4Dw@2=pDHrK!5S@v3hfgGjt^@FSaJur|*OS4Z8XNevG$sf^o}z+^xkyZQ
zMbjzY$#Za1FHU>AACW%l*x~5MrwtAYTQrt$*
z=swcA*naNY`768xaT9wQUT+Fl$KS6CJ61J#ETv+q#|?iP>72!!np0J?#bVdFhAx?PGk7WAFq(h|sZO(xS
zp4m&$C<~eoV9(@Er^$(h75w*sMY*0@VO0DEy!!^FSMZ&ZNf0S(R?AGZ$;O~&_+>e{B&cr?NuzTAvp
zX@rgxd0i=Jw3=!GanoxWyY;C?Vq)S-Cl?%AV0p4`T#@sN6#_JL
z`t!#_MFA}@h`gCdkMaFV0BmsPw5<0}0z@sT4Mxo)FMl2d&_M|_PmmP3coEgtcMpW^
zH;_mMsBZZ#T?!7NQW6`i0&opR+ti<-(b3bB4c>(^r||@+TqS`GF)4SL)3aS3Enfav
zGop9`dRGzm`MEjcLLL#3ND!qWTDR(5f2&4IctN!bxMp&jdCk+TbS&8lf6zr<-XQqO
z^U{u*uw=C~H7{~;HCn&-CWsdmAdo$ynX}>~aLJ&G;1p|=vRKb6Df#_CCT8dFNFvOi
zr|CTK3vcP@=tSq(zcx3k8Jn3ci$^<*7hAtZ>*1!RthOfLt_ftJH}i|?OJQ$aMak?xC!h4?g%vbWwXzh@^XY1
ztE#FJwqb@+9#b-l3L6fmr(dkHY9ur^F+^Po*
z#dJW-y!w%rvgeL+DvigkzU;S36Kpc-VVNW4yC={FTw2!^3W4
zu(GgXDBrLqwZ?sp;_>6h0GJM3S^?7PlAPQRsixzjBNlm2em6I_iCW*cFr-qizxT2G
z=Y5w1{<>=)|JtVRj+BXUC^IHKEm4HX4A3(dJc{f#6!sq{XFTo&TnYph{
z$Wc&GfIj{VY^{aFhNGtv_SYX^_*F`a_-n=x^-Tsmb*5CwYxU(mz~$K>k!aszpf4o$UY}*1
zjyr|*Py)EIZ5rH#4(K#gGuzqG5et2v?pGX)|2i2KzQD%z_r7#|3r`lhsQwV+TMuws
zNoHoVo-(d_>
z2)A(gSD>9zUXrAp$)S6v{Xix;@H+)eNo~;=Tvk8Gd4xbDFdhKvzAQ%#pkPzH6Gjn7$Jou9l-E|C-@r{97
zV#YX-H;=MQlCtS~sQ@Tumj~Q80l@Q{%;TG)Op7YG
z)m81UQhHea_GzNxkVk(wJzDVm(?@W{`R)Q+TR#CoL}Opg9Zydw9mS0x-{oBUD0aDT
zK%aJ5d;fIA2j>i(57!c$fJqzTDVtAwo1E;hO2aA<1a!~$;*8>NbxRiBd`e31p+QmX
zyLb5LC?FvIY-whCnnlV!rfnApUzJ2r^U&yM!|eQbQjg;f&OwK)r&&r}5QN&M8eer=
zYmkQHW6wW;;C1D10b`4GUp8uu1rU^$m6aTuD(6w@)%kB{0cdx#w2o`f57&Vm_A@8N
z8?1!eqDG!E!)eLQ7E_=ZT4-UsdVzwHQY4KV3`8h{Bw0Z|6tHZQ6EtLG>AoJ`Lbs4&
zQTKa6=6`4Ht3N)qW@Com6`R*H9mHU6ZE8DW;f&cBds0LY68w9VO;?v)
zq!cW59{+ZofT^%4uE(L@OTww}b(<4{V{^eoQNxKm;<8TK?D5{OJ*}GycJ9Cnre0ea
z*S-o!WMl7IRO9dc$?9;(4=SkI^>`Icy1z}xIF6NduzQ}Rp}8zBPKUBf^KI?&n8Ffx
z&@x7>R!Y1H4}X4`oTq&=n)8n9mty_}_(H8)w}?K!u>)qBliAl{qEZ|l2`l{?Pr80t
zX6ys}SqXf!m25PcYFJ_NFDVV@_Pz}}2ge<4Z3>>75$RfQ`A{GGAX?0As;8x;Ig1{#
zFfcR&5r(iHQ~g1?0g;zU<_RM`-|Z{$Env#1g6J?Z^7+%UFDV%{H6I+;C=>!{6`M4%
zf1w`PWo3h#wXZ{}*VrL9Nd4g<0iL(btvbuctp`aFVPPKuMz=^LwZ>>9sZ-p81^xkN
zNQX((N>Fxa*$SoQMh>H{`m#5ybMx?sJfFlrt^Ydtj1s$?jEK>5Umg{g_g?i+
zV(a{lJG||z~k*XY+2Ccf<5<8zh07iH|;76%&P&$N>`O$)!;+*d}I;M)-irrzQ
zKODgv#)cPGz|p(DJMQ9l=>t4WZ{e8Pi|Eq<{*EvF&KyMh5rvBvrJQ2UeU7a`7JD~6
zUl@7{chD0|Vjyzf<%rNvZ&b4^Ml9lUo2?;NTz#zdhgN<9j^c
z0dfP9h(1oRdWI$4Pb(+7`Lzi@jtbmUJNs2J;02#7KHX4rb{54O>Z%Uh-Q9(^e!YD4
zs=F`;7Ew#;9R&aOW
zU=X&Jhuwcz_pWW`?(0V{#2a(S3=6i~1cw9m-nY!`U)qB_*aXtwA)D~%XqhcV(AL=g
zsI655e$S)Rg^8VAxW;=;RKa`IF<|8qAD`fOp0
z1Ot`-(barrs3&@+7e|XT4u0KDl2G?8QV1xH=2RLJ{=1(Ft|Xn-=H~W4f9w~2J%qY6&>B91%JV22b&r+T}i-uGp5onvT
z)FShmimslX3bdEqhNeJ#KdpbH8Nx_d*M*xI;SRoITbD?MT+Z-?XbRsqh?G0p#&5<-
zS3Yt+n5^+GYGHH-l|)c*aFrvNtHiftX?j+FHGBX?NXo0d;NW0j-(G`fZun?yi{V8&
z=3dn;{Au*%%NGY1Q;*Y`Wp?0Oo88xTx>ID{CMGWEjX(t?`)oVc=4`WVskr~X>vxY%
z-+)d~Cd98O0Uv0a21y>|U{&r#E#``HF2z3_c`scmw(I4Dg|HBJ0@1wqVGD(%dmGS<
zqosDya-1aV;2kRoJPr76KE}o*Y&6y1kt1(ERwjT~D?wIK>htxdI#Qn3RNHvTMY)|Y
zbw*rq(A)_IUkfHi)bB(17#*8>STmi(0}~TwTiK3-xpW{bnFWQ-WgebaJQ`6k@$u?V
zY{5o?gRH};4%nej*NLpD>fz+7iQfW#S$sjXk_{CZ8HtZoOfK&s8xY*0;OhFj8|0w+
zdA@NL-Z>x0$-?qyw}C_HS(y#tV_5eO9z4KPkq~Q)HYvEsXlVXl`vvJk@?*n7Gx2c<
zNunN>I7q{D=PYV{Hn@S7w%(lWuw`BFs|Ru#L}n8MD|l&*M*~=I6XcJNkI5m-Lx}_)
zZV(kPNB5@CzRc6liGwoG#N<3&GdEgn4RcCIPv6uVuqz2lD75w?5a?{Lj5A+BzvY2^
zzZR%arnx144S)Yy!``g!r
z#F1Rge2^_hlxm(5KzLqLAfK17l6Lxn3QY}pcK^N_M5cYn7R12AKKT}Ob)Ur$);s<3ceU2E1wM%Bf524Icp>(#Md2&*{#;)|
z!z`kw=K9$_Pt&9HR<3Ph{wwDlkkuK)H%3_AXlVPA?B{T2JXyblf4{wA#sJ4@+28Y>
zCghg<5>IJWeb%Z!Lb;!OKGNLI^B!-Ke70f>(b&>|2*6(DcUJ9|Qs&CpWW(q!Jjl@c
z1SvmrE+mS8ogw-;_v7kMDwbS9X<@new?~h9savY+RhzdV3jaRHuO3%L{WAFI_#bj0
zd%zLWJ#KO|ggJ8c0QDv-OthT4$t`v{{OB!*;)Mbh@{;v$ARzvi{M
zMs2#LU~``cAN0V~!wIQ|?lA`cB@`np&EthNxLI}k`gHXRzd2VwG+pSL%&XGOlFAWt3IU
zH)Vo?RH1byu4d|VKaw|R1Rqs}(aj9nBK-spZZ>ioMP4AG}hgTIfs0Ws3-B)M~^M3e45k@b|3gzHayJHC{yhWzk`!)Q#S`
z&8#Z*Imp$5D~OCi^@z26fWX@P^&5LnJSbyS8N4Bi6gMQ>u;Ws*@}hh&Lf&&dyRnap
z(!d4{^Pfa1Y{(l-cmau2aiLW$YbE2|W0NspK0cO?z9Yc
zWY^olYm*?v+10knJh5_0qScy@te-_TZ0zc)w;s-0P%uj&h*khgF-U|&9AGsC=IXqD
z^}z!AN6giXm}<~%I3g${>eUiZE)1!#L?j5tQK0w*=1A0&#|x#GNhXXL!-Hru{1XPK
zR6`F{LupVum4@<(DB=Q7{79&Gy&n=TwM$yn>W@%zUHhUyfFys)@umF^bQ48W`+V_P
zW+Wx3c_FLrF0j6)hokVW`@u|^e5Q*)v6~)89G8jK5E@H>m8953#`O>-lAD++IwROR
zdJt$}8>_?BjGR&$Z0)?3{uMn?uuyCoPKvc~ypaO^eL1RmY-Bch_g?-RflVYw|y)=
zVd0{gAorzvN8@;}sz+{+o-(41g*Kc&=Lh$cawb{`$9NBqwehKjE}%}E-!069m10dU
z8fYKXy*^AvWV|p|;gR{F{o;ilj$;nD5IJ2eqsU|w{BSi|zloJ4p^Gu%dI4FwNFR0R
zCPrMAFd{*Zb5o)LzpL44RXqu%t!n-1e)G20?6HKXVkiemABrcG>^|aPBs%5GGMkBa
zoD}3la5Y;^(VOv*BN>CS3Rr&uo9kE0@%#TOA(t9iNc<+@(7(yM33|>VGImL3_55&w
znqtV~VO-A3v{>x<2z%n3{4W-;?D96qxJ(c(2x|h}U;{hruKXiqONs-jFT_?Z=|rvS
z6Wisr9$r}L^c1vv?R|NO0s1?d0y?(@+K7H$nXIZeW-pv*W*J$V${%<^VWgPwO|`7?
z%1j91jz9k)QAlvLv{|K
Date: Wed, 2 Mar 2016 19:17:04 +0100
Subject: [PATCH 239/259] Add missing arrow to diagram

---
 bip-0009/states.png | Bin 29300 -> 30632 bytes
 1 file changed, 0 insertions(+), 0 deletions(-)

diff --git a/bip-0009/states.png b/bip-0009/states.png
index e058c8da130b6d47bafb4aa834dab23a2743a627..09312a1c0381845d10afe2ffbbec912ee1b1b1e0 100644
GIT binary patch
literal 30632
zcmXtg2RK~a_x0$}GkTYdgb=+3(PAVKq+o=oQ6t*u(G9_f7ST%(QLj!gQAZLbdJ3YC
z7KvV>x9@m=-{14#F>~kMbN1P1@3YrhTjaz0cW9|Ns9-P{t>#^%E(}I&1cMPJUmyps
zXq6{7f?uTWw>0%HfG__G)>!a2CHk(BI}Ap?a{f)k<9R~{yvXjMVd$afV(a1k)XfIw
z?d>gU@9f}i^%QL*>f&aXv38RK2D=2)M5^h($XuE9PGv$3<7cKX(`k}ZhES?el52OB
z=jN6Y!5QyK=akAXHlSU62+C5dge=bE>CBRB5J!!uby8;1+MbBgM9w5A*zymFh4pST-TBJB}6zO
z?p7leNomg@xagy9ekrGg5FNajJd=crl#8HL2b(5|!iZt^^gZn|A>aK(Pk4Mf)F2+L?jh$XEiV3T4c~>CF~++hs#&Y-;KR}G6TkvrIc52K
zuIL~|+ha;z*W`3wLHFv0EV{bBms@=e@q
zG&GNflAeyN68$49ho$F#dnux-j+#uo&3$gfVK6cVenb+64A-lVOH!3Xy=59e)x7vBGsDx45KwNGKliD~^pT?y0oY=m|x#)!6c9V7ZArNL6}2`AVv
zFz`j?<3B=&w?lUHN$wLhkl2xg2};{h58g$|6`;$`mz=R~wo&sZ*}h#>2e?ra9%2-&
zRG==(ur((3lAQ7gxMThmt0ZR&=Cx_a*X;NQ
zSn<^Ar)k0oSn5ccN?1o2x#3e&%;M_QGi;6nQ@slvthk|sfNA03}+P1DQQ@EK3911
zSIN!H6}??|1QAOxRIWR;sK0Y1hZ4=4)`Mn-+1cj&H`_Vj%a0=OGMnrQPW;qgqNc>%
z=XWPc@nq)!ORqI-`Yd;AS1@zI{o4ESu@|PVOkGW13A`~$$^HKqfQMA=dol}&9wkbc
zg*!aE8@_zcf+Nxf_rFbGR(+}Gi`$zAqg<#HC1W`nO580w!TTg$UvRzuGZ6Q(sB{Z5
zkEN2lh{Nm8WmNNfnz0|Sk^EoW^>mN_+-fk!gx84|16%uBswHn;Mcg6EKH^e9q4YTR
z*WBqZ*P>>YNlek>J05s4lN92!eq^Ke#~LG4eUc|1SjtQ?qmC4;N4v_i(FdrY?m;Cg
z*HKBU@2<6wvhi??ct@01=bBu^x9~7l`~rcj*>m4zypOcfWbDYs{{Le
zuAh5|TX%>sV~n}?J1`L7$|1nm-wgSC&I3{?2uLAVed67J^44m}=PP!Jx;i?$11Wlo
zYD24>(-M3>@iB`vyGrf*#Bu)K|NDGkuE-CI3f6N^RogAFKVFH}HIpwa69?~iOBhH0
z+>cED3SCqi9xgK;ZSZv1@Tq-1RAf|Rduzmbye_6ML$32?q1!_D&tg4+egBig9VS-R
z&ZYu`vM2gwOW|$I%*<6bJuEQf%LY%aI`4@lAF1)WB*!21!DEPC{wdY+SnCB#+EtGEzceK_>5jT)3!Dpx(c)X8Wy|IBO(Ha^m(8(ZF
zefo3@dR%cIJnY#7PJ&y}D=+Bm^!RYOLi3C^TEh0R1@Nbuo|vyfqN29I483Vm5h-TA
zk-Mwo?qEc^`uh6AI#GXTB6w}VROOo&!5c%XBkab#+#;JNhWt@l)#+568l
z?2<2+D_XPob<(eRPB!mN89!e!ya~)G%-pM!E*&}5>_^e*Wa_`!-kTvOHnZu(uM96H
z<{}n07#h5)pAPE@*25Ire5>=o-levPf<#4@>yUhiNlXH|^#~j213yqi!!}x=Sl0L;
z;!SelSRxh}$*pc#kRUgq21&jcIiL5Ryv|ZTAbYG)`y*Ol+U!cc(lXC~!c635d&F8z
zI?A@Z=i~1n5ROw#X-Dg=DvNt6C;xuLyVXJS0%D*}g@j(cSosAH!1l&+DRuzq+|ICIo<}bq!c&;(T
z`yg}`LcA7D`4HR9?kw0Y+IK`L*kg61+2+SJKDhkAQ6Ljqd{AoMPC+hgdH{ovytq%f
z|G0WY;OPytrlFB}#Z5l_oyQhb=w}5>(g$rF)@jdJ=B6rdtxBp5SKIW2Oh<^lzqm9T
zB^G;4aTd#$n-v6{=sSoQx;7ZkQr&OWHd=?ft3BHTDg(c&tPVO=PUAOfSxwMtUz*jW
zUPKz!JDV2Q)?1#GcdMcZVpCR?*kfYtU7q!b7}xGQ%fY932fP&CvBIBk@Zt@c3*7o6
zbPdW<2__^CF@{$9HYGCuS
zwk=X{dp!K<9zn~Q{1d;o-LEJ%M>2i1w?5Dn&v%|cbUjtJd!;mK{r9At#y;o{d>$F?
zE_kc>o|ZdW==DMa@h?#XFHu79S4ctSbDvfQP0
zM9#!xB})QRwY0&7$h>z@IYWFuUQl)M^;+p)M711RZX+D~lhnD>GstxI?RGhKh4fSu
z5y#K*!57m_ZejFifGGyc1hXR!2>yX4IlV)|S^}A$d0bt$i(RBNdCgMM+@mpXY9i|p
zySJl+I+5u!`w^fqkDf3rAx`-E$R5k-*2^+b;LYKDU^cVc5D8teB=6?t6I3t4$jbl<)M<4A6L0H9q}=rHXpP;^W%Ga?)b!Tc
zWTW0kw>5(%9LNyt3Le)$-qzYr2UB|+5)y*lDmQJ^ZT8*4Zjn*5h=cnji<$QyA8fPB
zJl8L7f07+|XwM;iS9Vy_w9Bxv5pxE6i}`_}Q=O-0$uLiLkQ5i>tuc`hruJ)LHsoPR
zblhwqKRui7QCug@KAhT0j=ymH^mF4*%Vx`Mb1u<<&#pBa3M93`5{RvIsC-v(bXhcd
zr87?Y4r=l0uW&icV$&U)iQaw>(^tmdpJqTEQ{FvSu4ca>I-hz=oNgeD`C8ZEYW?(|
z$;SHiDzDWs36DR6sUvq9cUNi#=tN24sn3H`{gm%@kjTL#L5Mm`t}yxd-CJ!al2Jg?
zHTTS~r>uU8W5+w58afo&5E1{fJhp`O(_5pFj`J*w8x$VNk?eOPoAR%b*R-d+q`Lmh
zMH>X*y;WEI;^hcpj1eK>tF6gz;eTT+I2-C)%n5{nJcthyKQ$i~g;v|qGh>}%v&e`d9Hkgw+DaV7F
zEQQvKmOP;bmGbM${1e*E`cpq|*$JOsMx4RpjWy<9_tuVOL#O1&ug)yCw0)>qNl!%l
z?aASkjzpEDdqKAz!;5FQONcTljG37oS@X?yy-7J|(}Nsh>yP|IB*=Mb3nfuP
z4;$*_JEw#61>AjP$DE|j9U=`?R@9^*Vua+3JQ>?nqWU0*XHXqQ;t!fbvj_NxsFMdFt0Lr66jQA64#DN~gwMd#+T4!xyFL)Q6uV=;=Lt%*vpF0^JDghbzrh
zChzJou>J6-bVXmIhx}hvP8g
z>diZ8#0#rv7i|gxd2>+A_|iheYj?Vi81LtF$FOJ`-jOQ^9apWJD@6V@HpbC0#
z?fs^}jJ&!R)bNZ^)4s4Iw8Ijc-aGxgDwB?tTw>EOB6uUqd^-4e@&k;F^1@s9$%|HQ
zI;d9E&}C?hQciZ0hG0K&X~UYV!;O}>Wvi~4T?k>Saiy90X^aHXlHInm%M;36H`Q!yjejT&NGxAT{@AxUQCbEO{cQep5+z<9m?vGSKNR4oc
zgpWW|$;F977uOmiM0G26;xgiMb6;-|V>~a?8p7V>L!`VISG?K>62|}&-o@*S{YQWu
z9duQj?l+*GI$_kMrAl3@)vvbC!YfXvVhHENtB1uK@hx
zcm{X6I2eF7)IfZuqc65yH!j}svdb-bImPYu!V`*K26&HGMke+l0=XKQ!jQNIFN2%7EIO{DPUR7V>#immWSMucdM~3m<`SGeQU$^MATx$%LkGCi?Qw
z`&HKk)MWhq1yIV(f;|}-WSI);HTQ+2$JGPMM;jZT>8-3by+z(#A5UR5G7LCHu1nlS
zChJyz*=Q=Eb=(MW(Zyl###rfIUjiNu4+C1GkFv0~p=<+|#e()08MEq|n
zYmKyAe~8t6l)T1a!zlP?9PxPYl0-jIJ^dorx`XG0Gby)~Nj=FQCI_u+z{a++Ii5nJ!s`jgT7uGrbZFv-*GrGJE*&Hqo)$-+MW+s+jnh)Un>`$|x0%FhcYj*i
zmhW?m>~g}ZKW+Cedj29!!hUo2-#^apZ;C7lIt2EK;RpF42$!S6am?~2Z(}XTGuB^I
zLb(ATO(EO6Y@2-?<{AvpUREv+mdITI~|dt5X-!OCj_8
z=}+IA0?v+iyM4KESC3M?X}1w&o-OpPXe?;=+tQn764K(6hKkIRmu_RBx2UfEeKsxWEOb`qY|EjBJjA@xroCC|V=f0V9F<4%|w>EgotinPAUv
zIc<@v)=t*E9qq`1*MStSeBN^)YPz?={QHc|qylPBYw|V%;FTsSx!Oc8SQCE)H7G~c
zY4h*qw)4&@vyINPCcKeuq*8ZkvvKPrap^p)6h$PVdlI>ryt?Ev005(zj=f30Uk0z{
z#u=i_zv7i3q7kCKi%NcE=n7~mVeMoq5`+=GZa3i+>`g4EI9JaIZq%r?;G1X-^}Y8c
z;#oLQN&LeH?9;PK$o2rJQhNQzmH_^pas)FDh2qtDf69Xo{c_6G!kp6F{Y1{jsOnOW
zwK_|U35d!0)h3AVjAt`sGl8V{QA6wB9pgsBtStZk|~{oEhd
zWjhK0OKH?3O(u2ej=V6Q4NCgJAm&P+wp@sg7U28`6=NS8uDd1GmTkznQpRN>U+t7e~OzCIwGTL9Wk#9FkpEZ>kV7*YKbg=3SWbMXIw
z?=IvHKs(rlIaEN|!K~hYdl1BVe$az(Q(L~{tc3L3mY-$`>5jwHJ)m0tDgTUI}=-S@NSqajTYK}s3o$#KqM0q7cv@C4Trp
zV%KI@5D|z708b=A=1Dj|{h?It5oHz3j&KvK6w%rfKUfu7UzVJ3a1yE%M-TSo@>`Zb
zfeCG1I((8{&nW@S1i;J$?9X-)<@CMY+C!cppR9qZtTU!Em=P{F;g&4qV>
z7;Xg>F`g;_5?yiiMUN5uR48P5^QSjz@E^G7i^_E+#{HkJN
zX0~Y<%YW1@(j^IC)#}CInuHtXt|UoXHih~!V;PAO3vKr%ZnSN%hx>u!1DLoyfDv%g
z9fHQLR;ZS|D>>$e~uBNXRc
z-SrzpMWju$tBgt2q=BqM!Jjs6p#s1=1@7yT`jmSdqH;!-=d8!JU+cJ$1`>k3Mf<69
zhh)6k$3V*05rwm|dm>En0!>jZ21Be(B21#hu^r9wVnpG^OQou-h-zLmCaMsf;t8+jVOJa$MX_t}OXlyY=nW8-U8
z{Q%o#yRtW!ZGs#lN+Be-oDs1tC0xFjishO)QSQI$XOudl8U#PcfXG=6acn7Vhb+&M
z?k_-3qQ~njZw%7!HKt{2bDLRsG7M6rFe_f~_UVKvVY)9@lx6GhxWeT*{**)YFBWAf
zoMGg|i*wapD#QatOSdZgKFB#U6E-0Q#EKaTJucyaZ{AfV;?WxtdAhhm+K+d#R_at-
zjC(!jJ=2k`O(p0M-ov#^;RPdUQh)s7ED+y(I^2FR1h%GN>+u_db`&}-z6~e0;fj-k
zcyP{nWmE6j43|xr{J1WU+-SWO^q6fHc!i`Pqea1)NEqTsFo80BLR9e6$=i4HF3sPL#>jCzxOTr5)~gloZ%vSYU?sMD
z(Y9NIXEWJ-hQopqTf(dnBKhHJe60zyEZ54;+I1!`zN?MQA}uFT{-Pt_3dbRlu?9o<
z;EonmqKh=ux5i}I4As9nywK|!NZMQoi;*}eEGoi^7$5t_+|w`C4I8U1F0)YF2ISowYL&(Wt7R#O<@?NtIzM-Aq67!0_haAma5G3*2Zmw2}qWhEL+M3dK~c
zo1^?j>0SV{No5mF%GFY?LQ@?yX3(S}peDEkbGR88H?@;OGCrF$XOLh(NP1m8oJhJ9
zc6ot!PO=KKSU*GlZ=F$hn2oi`d{Ie-i}k`JhueKVlZ*S7cSrZ|Cr_P}L^tXweFCIY
zpydD40tljg5v`%uT2n%Rl+-gLISvp*Ln=GphV
zFQXP%Gr#}i-jrX!vY4o-sOOaXfD-G?-F8;0Uz
zyHin7eE>-O*hhD}fTiL>4?wioACuQq0Osk{xXz^?6+L(S168I`pH^vy0I9ttd!UVl
zAguJocxvRl7yKhd{p??ia$#$^@;IM0URXrQbDwd28TYz6ZEEDCxq=&QWee*5VGM;R
z^^i7_1KF5{{nu_Y%hSGk91soF=@0p#JY5re6y`$W4dbX84(;F0s0zUCLzdSviy((L
zxTy!`aHA;B<5N*l^xraxVH`ZZ5N%rf7*;VC(rbm*$
zbI(QBk45yz==!`1H(TMZ-Fjwh@Cy|R7}UU!LZm4FStV4WgH$I~{GC2I6#?KTqVI>V
zxB$HG_}`BQ+F3W#mdhJsL+O=M2UO0QN;6O_$C5_vs9;6cQRp3Rt!^Y(K!2ykur{(Q
z4flYlCm8VYcbIcxvHEm=p;-%h8vOq3yZ$oe%TAhijR>@@_@f3DQHMv*Ct~f$%1f5L
zv#ki#ycmlr$%iN;vRPdA)zUuw27MCR`^`BDeSnL8qWZjWPsHI6aItTSAARX;N(
zf}7S5b?ewBo_?Wrnm#Bwz?-<1HOZS2kh!L3PVlT2tCU>vBoV!#D1&LO0z9a0jjc|3
z>**nO%eF5)$yeDDIdA+8z@Gw>+ffkS2WB;$vNR0o2$}hknKNn*eg^
z0Pt<9lAo-~*|8Mt{D*0S$J5i}18GM?vqiD|FD}}{{X)7Q
zsJSsiWzw;oeq&LZDgL$@`E`OgVed7}LDAVK@}Z8@h`yD!#v_29@%a9Em%1oyTo(mQ;YRF$M#oZeu>-!B&0i32iVy7+r@@
zk2epO;XMil)-6`mA@M1Yv;NQsx~9_Wv(5rV{qG0raLVcZN@eF`t)g;G>1Pto(edU7
zQ<^^$N>x*4HHuA2A!C$h6O=`{LU}WMSvOq(VII}x^fV=tL^^64cjc>XH1TZ`@Ajqd
zJ+i11byT*&(0f-YPJub{xHDk{FSg6a6*7$OArG%eNYdmb0uYX6G4`T4LDH?QT+JnU
z{wuC3h)BzIvhSU5xRQCya!2oPhhJ=ZM9~~FuVyVr;$2s&I=A*(&y-#`PT*W!DZVX6
z385e~AW7Y4!dS_BPEXc@Y64FVB^^=y2VSfO4DoTu`Fn8rwq;`f3v%j9K~tJ~u029c
zR}drEE_<_sX9OYmK?(NXu7ULfTb7|l)d%puVu;5+Qai*8tk|weGoPlUo`hT|3Qh7e
z9NX2Zk(YtZyn+BY2dCz6?LE|4v9rxqXs{gRxHt-xQnD21%5y!y<>FCGO3~7Wb$Ji}
zc}20_5fib5rOug+kvX~`N9|ICHCZhCmt}tz(PPrj9FIYKS3@?u>Z+NtEGk;kH!;}q
zfwK!E7Uvpry-C(6iydyFaoFP?zsV*{h79LCS@SxH+^a69DF>V_OQ5KgHji=bb7nv?
z!sFhlN01Ltt_rOTm9TOvc;sj%@WV>YTeIY*?k^UvJq-1;p6$1J(KTFI6
zC!WyP>m3;I-r@SpFi8V>D(q&cpZZ}GK#g;p1BzP-%I(>Az6u;rxXz`okvg~Ql(bUG
zktq*0SNHp^vBs*za#9adjVyeKczi037DHD)=3&DsGs>M_Cr}d_D-}{6Ne(KhHp`Y?
zU@4l4&4``8Sl^4kYtr$TJKKvN=wP6ww|O58P)sFg74_1CI%?NeMip~dplKSRI)1uf
z>cjUYN-in=9m$F1tHU41(GJi1KGQx_X;=Jr-5KVm`eEc-kgG#x*kRafiQuVA$Lg*X
z12wLgjn6oGx_5JQjf9S?Sr|VjQHt21?+%5{SmTmq>4}K=bytk_{`7C#iPrr0t`$##
z++vgr2p%+U5^Kr$pB^l>UCINx1dsKpw}A8f_Wn*BVJC2|wptApFwW6ceHHTA{tZlL
z#^t1J81{3b(9x9{)qHs>2~v1liTMnGJzS69OJA}1OfnqV-IFB~5}IwEcMCy;sa`Xh
z>+4**$M>=o1PCGRgVk>XogUW5erIc~%je@H$s2NVaktEL=fS$JKy00}o`3U&%8MpWRAPu&^zN`*Qm386(@$|ai+DAKs
z@h66cT_B%wKbrbr@1}k~=wxR^cVKU<#|8N?Y=PH$p^5!meM0uQ@IH4qJ@1;IBf#mK
zwz{vkEdorw@NtD%+ae+ass_g(0KT`YoNmUI)_JZs@5PP{TWi04;>$CvM!}uv^>zV+
zU5P#04W0h4?CO{w1iW|O(ojk0z~Vsm!12MUVrmSV1Y%jufM5Hqf=nugWdBF@>4)ng
zGnGM!ZlK&g=0~8aKfDHFuEfZ}@=xGtWE71QMMB%ZKVF5g3LD~AMr-7kir&9z==57}
zUR2~?%1gNa>O$afxoHoebNTwq^a|-f2G}eM0#wWS4lxfr2z#J%k_dPr@;GKDChIFw
z2C)D&J%>QDeFT54;oWT}S%4PmC5WODK3nsI?ZWIp1xo`S{L=_-7Mc&YquJs;UJq56
zt4wdPOW7hxjkHok^S#%n;EOzHJkg`j(zZ~FqhwYlrj74fVy*;CU`DIHVW8SD2g-D=
z{#LQXLGE>Dz701Wqsbpy4HPN92yond>>;U3~`EIzT0g&csU72@C4pcY>W>M=)Xl+#xzeR?GlzBP%?k
zFrhxqEc0Wxy0`qJkiL^Q=q79k3agl2&2;M)^ar8|*ts4DP&NBm-aA8&-FqcENwZym
zVhBQ&kXMjB8-lFca{z6VtiaOuE`o;&A0s#QCqs=IRb%^gNeblNYp5V_yuAh-53Gu`
z^TdnC96<|(We-LzVO1id+R6;^hjyH&L&?qqNZtErEie!{z$f8
zAu=L2M*P7H?a3pGdrqQ_LbZyNM+=T1t%V2OXFi3sEnJM&)K^m@($LU|(wE^A$EK0(=3o-%&yPaWhFkr@M_EhVM@yVe1xth(wD&E!5v3k
zne*@74)Eye_l)sGEO_aSX_>K9|BD=ko?Tm~;YN#nuemPj>a*4t{fz_US9M#m+;2$0
z`RdtYjQTCQ)IL|F@;+mCCno6MTydU?iEaCAgk$1h}@_0__XT9YR_rvMJ
zo4DH%z-O(H^A>O)U1UL2m+k~%RRpmWgKZK-kZ4?qZ`V5}h8Vm3Qr_7y#gCRg^mNTA
zKl&K^M&j|eiG*7j(V87+!974u;)#&_apWCTjO7wU4E5jwI_6)QKfa7l#LLya4AsoQ
za#2i>dt7#dS)g)~_HHoZ)RD@hS!8C9hgP3@%D@y3CkiA*Kkqo&8fP0r4eChpi**vd
z;paoQeP?DB0@Rz>OzLBbJ+ni-B+G0_)kjPORQ}b+D(0(b>!oD}lqtsxOQ5Zk
zbnzcN!P5|Ej_nNh<%wR9?du|ADHT~1O2kd#5;@X?W^HP8Js+?vN%Mz5&ZPG#T6W}3
z$WmNaNp6NycNj!<#UZxBu@ig;Vv;5d=ZCjT
zxM&g#I51Gcix-mGIs8y-cI>w%s*H-Og_FMuqE5Kw{_KsAirG_T#u$H^r=75l8$xVh
zus8V;0m%7>@Z$7*{tPOM(P|r@rc3dZ!Z*jBSQhE3C3~`_=K*o01u9WJd&i!qn9s{_wYyvv(+pFF93-ahF)tuq9D?VL-yFbD>Oclmg%
zfse@VuVtRrsYY5~K&waVvCNX6p1|}wSC{{>PT)!n>xju*`_syyD&i_Pb>tzjm`x6}
zr(df_z9hka72zf<&b%?r$1fH5sjqx8`%jHSj3)BQ^_HlvR#$c7Po_oCd#$$)0F}R;
zi6=as2=rkbS`532;Kn#?oRPjRvb1=BGL65@?bFtCAyEBrv~;)5F;o!XL1ZJeseL?e
zobau|xx!PQ=d&Tz2No5TTS@pE7J6@X%Jhdib?vcOE+T)mdGR!t;80YpKGX}=N*q2)
zoAP#Sa&f~BFAp``#Q5GPGlT7FRtYWyihT~Iv91x0vH`1YLK=N($2Gmm@yiMCb|A}=
ztdBPGl+1*CVS|C7kLv5NMzq#7MP>-{t`VcS8O@%NOzTKG<5loah%>Y929xDL>oav2
zAHH_4#G^1x_2@4rr@+I)$DV4B>3d#5Yq3D5-1|{vhK;3u!Sat{Whj*4@y{F#Y@)Fq
z=QqKQWBATf$7M5?W!r4^j9@7gDAAYYO^`e=Tav}RUzv1>?>E{Vw(q4&(N5Pm-%5z+
zAYQkwY%vd>L+xzS4BL0ZQKpd@T$^f%dK|<6FQ0MjyU!dSu8J(^b~k?^_jE%6NM<81
z#s}h0lq1NCmz-S7m1ycaP~JHj;prZ4A?3I48oCqZWF6pZj7E~NwJ|w5M%#7$3gmxQ
zl;{N9C&Q>+P1UsKvh0O!y2xQ9zD)J(wyKJuP9#G2%AzxRJ*x+1!tj>?BAwXI7FA36
ztN<$UFPBezgNJNb(sw{blp5yS^RnK*JxbF=5`{XE<(J`KM&?mE*Djyyd7iR3Z=2_6
zb2xq>TCv4t!W|JU}J9m9h1LBev)XM3w`#rlb=E5Tjnx
zoy!{v&Xfoh64Xw)q31cxoUr$MU5>?pdgHEP+H6R+iEyVeWxcq47$IQH_fp%B!Y9Et
z)jG&@>|Jv>dj#hTWyX4+1Gu#u-j__S{|B)!V-iG1tN>H#yivvsBuW0)5O$GwYmrO4
zbX~YnjrzGC9I0&HEdbSbnmp#us1^lQf`X3H4R_lBB`w*?x
ztJd5o+b~`vba>jEfTb{J8Ah!(qbK%
z5_^pvIj=jxVfjrP2*=%qc=W1lUN|Pr*5T7ul#*dRZ*Zq)`a>>;Arb(Oqs4!|!upeS
zhUHs%sNbqU_3JgRoEo_~iNHo6PzDd7A?#PqR_N~xGA%pke8rU+W-~E(Hbcru7~id1
z#G}GJmT8GLg2pn;sifMJ+sr@MPA7T1P54GFQ1P
z6a0WHl1AuKr2d(TUtbo|=X;PMw)9d|D6h_o@b?ZE@9!Wxn*R`bpge?e?8)6Tgz5$-+#Xn7tE3ru=>-
z;r}A}sTpM0N37m_uTuj4Uxb{8BkH@Z5qmuz>N9FuZv*D0;74nQElHAIjPD6vRDb1Y
zD$Iy7vMHJUU{Cbz?4pvFhh9WDXVy>zwg%xSh2vSfOLb42fTaS5Qj^qh5@$gaw1JSJuOb?
z=chcP%cG@&(AdY)ajR|vmKsz-@B_WC1{!>bpigDLc$}37HBkv^p3k&DCUtpe)Hpnk
zJQJ8>Piw%Wl>L1(Z{yz7*@CZ9^|Npxn8DLBi|ZC5WpJu{Du_2rwquPUAJZlZh0W*v
z>V#rH2Xrg9IVIHaNA1b*R{)XwK0~}2E-B^nYFe?{@2O<6UEXrdks)TA!=U79R00}<
zx?O_;z9xl7UDimzIFEAm*lQ~T2KhfdzLRQ)%E?;m*{R8knXt6-VSTjwV!zGom&Cd&
zJ)A~e24!t!#z|3*DB*W$rQcM|QIlr3og@l+0Sl8m+F9smFI(4mgAh!DTg>v4G%YJ8
zfU?C*G_+LMy5#iES8aTzO-U|1{+_Bu)$C<_U!6|uC<@T%=gNIcr!V%=n~yLxsBa%g
zpA&l*FX5}5qa|$4WwSB=6Y^il$+at)eMVyP4jSlG`jJZ2fBv3Lb+qQ7XlmIjn>UcN
z(DH4z1bVPEaAY1wWyHW`P-||k%#K1u!g$Gom!KP9AZtH}>g?(WtpvZhwS=(@<%@bS
zsAvgF!1wP**2UZEHpX%4O&Qg7vn9}-HwHXA+dNuTx77}d&v!)q5n8_f-8oO9VB-Ap
zQF#7Dh_K#F;)r7sR-3|1e<*&mDCn^OqAys5#8_X(QcV^vPjlm<;X4QbF<(_fZwv)i
zKs6e9oLARd$Aft>6^?DguYjy)PTS_P_v1qc@l&cW|;Q$@oTfcUbAJV``1f{Fuqw7Yt+JMLmsX`$BZzC2Pfu-VDW
z>wnt8=|b9Cp0XWvp)^jymODDCm*p@^{XzoP@DK`;)o0jH@Z
zpP$>uJYp^TmK$TBe3YKu=Zm{JJ6^EfawKZo3}35I}jRD#sh29gmAGIb*zeSW9e;f}X@emEK2cA9KR0=SavY@~oB+Tv7rO$3poF@FQ@
zql)|u>p>euuH_ALth-QC1bH5T5B5
ziv7nFUx(O=#%eRg_cU91YRun<)DG^`yV$U-F@JOYC=35hb^CSp-zKIYl~v@tCZR;X{J|iafDj|$7-UUpK9rd3
zMtK%Orxa`?(v0x|bEa0^^x*guD71p#0|1Yni3tr}qLb@0wOEsCi9y*lAtB4n+4d$N
zne{(dNNL*!s_2g2eOE_MLGMWntGPcsxI5|kHt^LHs8uIJ76zzh39pr37CsBzNuwX#
z1%URJ83d{YpqCOz2C*mheXPPO02^(B7XVaQUTAr|ze&R>8x8s}&;ZdSA2^$fQ@Q6<
z9WY|*?K(FYa4k+`s6-EV_S$_nRUq
ziZu?gAzqu_tU>59-=H5+lHuIHjxNP=6_^3Rp(vj0-5E&%On^vABM(?@TygOtL4Dm!
zY^GW)1z@6(0{*%RDUN90_}9QUl9U~v$s?mWAC)@-3>cqQxr;3dX)YJYPsbWz4>Oy6&BjoUx)hmM>^ChwH#4IoM<
zRM}AT6W^RA<#?Qm~a<-G~_{MewQ)%u42+J*o;
zH3hV_!?+#WPXIP&!>wCe(3KzYzjekB;SC9v7W93gK~d1RM(WQ!u5Gs^28Ht+L-uMW
z8Fjr19(#RAK2|&?*|#%15rb(FZDzHS9FzW}lV8ln8(8qJALQfdvg`Uuv#3fGXVz|6
z$eEz`F?&*?ur<>3+wwtb#6jzi=O&~EO>vy!G;GUB-bBN59lAPKPS!p>$N!z0-p;5F
zY#!yS`Jb;k@|S>p*R~EuY<7CO*D7VzK?8zv_P3*#UevoQqY3A|IN5PLO6lB+xjS9A
zK|zSxI8vvRe+gItySx}huN49aF)=Sn4dX$R6o|X%>3}`Z4`kXPy@o&3ru-_NMb4$R
z6*`jirV7t?{cDlkYvG|-q0z|wb+8)C7e*dJ3fy$ZV-vZIbvmg`v
z-}-mkR5{A!eigxQazqGv6A_ZF&G)5j6t9}*C1G0(-HM)1@g-X~EZ7n{c1)==!>Dik
z*pU@|Uq4xLq*&W-f1L}Ql1Wh_Eb+V;mZuSP*Ft|={{*dZyp;fFi`k|92zw_bQuCduF-Fsa57kmTCMy5_EyX;>J4`3>f?_Z1;!h!aT
zN_C1k$q9@?9Z3=r2soWL%b6|ACsIrEikI9Gk_=)HJMb4D#-)q3o{yIyMY^I3&3FKx!ck9D>u=i-Xlz@MNqes`bv3=TI~_B-kAO
z`Q1;t^`nsLS8{qLJuR68m?DR-?!1%+3pwan>=l9kr4X0{Q
zQLd9-qg#Ta!3}ILKCP3YCNCq*XUT&i6#9-1!}dG{%g1+Lm~>p6(EhZ+?jGeDy39E1
z*%w39fxQcqrcZctva!8n;U!D2Uu)gx59Gf-8dDlER~?v;(A2;3>AcBPcvrCGq8f|p
z&eG7|@A=fG4LJ5c=ZOKp(Nwne%10|Ti6NyRF-Ul?O%S#Pvi;ux3Wu1Kgg+Rx0)Uia
zSpM-h$Fwj1gRI_1cevYu1B94*pRXS1$hsy&F2oI#?u&1*0pT_CAAVY7-&EGJ4Y6rFf}Y8&wXeV7o%`ms~Wl-*9TbB4CBk68lu~Nw6kjOK{_Y
zC}AmzQ5b%t)UEm}wv
zZoIgpev6nFwHjy4^6ugb2DUKcEDPN(dA(pgS1Z}g*6XM)QL!cNon1D{wb~)Gfm>iP3NAMHZI+Z{7x&4!3JUg?}
zA=4|L7S}O2IH7n*_KSWb$xsv!86lv_=Dc^~TT6f+2+A6+t`eYq)DG;^wrx7amCC&3
zsVXZ9z%$V)tE_(b0Wfw{vHN*rkCs?7Db8_JZrWcR(D+uvegjH-;{N++S?7r^(1*%?
z18spWEB63QXgoN;3FS6{JpvjwzbsP8Nx6ZHa846fv>d)N4;1u?t1zw?6>I*di`L5J
z66)Teb^ppKAk*vjGC7-j_ok)6OQss$;oPKG>i(NxD;$34
z@=JcH_Ij>U@y1fmH59G&ZL7ELkE5*uEV+6XS6^zApVv*1yMoKGZr9gj&aaOE%a|(u
zG-Q1f^uW4<1~UQEbzKHd;vJNQNYXa^&b&J>Gx+S81o11#~mh@rr|HSoL#_^)iZkdV;q$HlCu^D@HV=OqVV!2FPJ!JsvD19(f-fbwXj
zwQaP-LKJ{op9SLkdZ|*jTXM7;W?x;uadx~N@L07%H=ioS#Env~K>Hm~5NM8YkDYjf
zVq#)?2-e8Kaadn{5wM=8mpRfggMN7Dz7rwefWWm$qrT-~1|9fS2
z(^#P3JvOiI$@zZ-sEGo#;+MG*8$(!T>YUg4#};0lV{m7L)?BX?6S*(oCBX+EdPx9f
z=q0yE7u;Rs(!zgoKW(3<0P1}?jVqlD&TyN2jn+yQehQ{$Gf4w(!yh7Y`#FOI1CG9k
z+aT~g_GUTc@T1rtz~MB!$~XTm2Occ2o@Z?;YU+>RXf1f{+TB9-|JT}=M?)R{ZO@Q3
z*|YD3EZHXeRwzp%QmAanh=`DVETzywc0(vxvLsPiModbiL1f7?mSks87#Yj^nSSqi
z&v~EsJm)-ryqzOW^PTV9-+TXDpX<8rq9;`HMteQeXFjeJ?=n|T2?;i2&0nE<_t_P%{)Zg=k7uF8sO!mzanVWmF+^*OTvtOHE#9(wh|23E}2yOy2r)LI2;v{Xxt*ZT_(
zhYaG~rqFy@=|}$&A$S;>Dqzs^Cn5wf?LHhynCcK$juKgk#PKT4Zklq+*RUwyc^3Vo
zvhvN(M>6DYXxcC~OyAmbgX9|>nx+QvbKuzcsq;HcUL#{rpZ|PE?7OS%msUiLQ+YTv
z88$^%W{wmuBDP+5eqQzlk$=HQK)1OSv-|YhC*)54^58I~+>(^&IC)h_2^sfpc8=$1
zS!se9IfB~kMKIcui%JubuTE-)A5c1FG+$s{69*dG)~LJ3$$Z5T``_61)tswKr1}YX
z1Bhj_b8u6t{dF#0U7`oo-Tp5*#BRqj!tzOAOqKasS*btQOKLg4s9tLRP+)F!k@kDE
z?v*DS!b&2+w3~D_o3pG>Wxmm92+dAm9=W4@b3m{0zVB~Wx-aP7?|*=j!!sc=nHMuY
zxwRb5JGryBLDIG;o!{NtTrjjh?q!lBar?+oW@er>ccd!wl|4`HmaNUUkK@LiuUN8k
zTYca>BhK^bwjH~T5xZ;Zr+xdM(tF5SB{BXuemw3?*K(r2`x9&q)*Gc={gv`JnBYnV
zL0FwT+C4~*qB)bR&8yK$4ZTEXV4y_26v`Y^hep>jhE;zBZO*?
z?z5ASuns%YmMrT}?qWJEKSJ--ZdH9fS}@9jv|EYu>9E2{NJ#VCB@BG~x{1cMVf8L34vwV!jJb`&5@|n4528e~2NR>dM}23Cww1aRZ5b_te@@cV
z-h0o@!SO|(&OVu!)QGS{jBpbNDvy3+xyHO`RNLdLyz&gUSK};v5H8|^i-Jgv+;$gd
zBjP|AAl>nWlLP*rmd+lEA`t?Ql5~+kh+u1&BPE_1X5ivU*!e^pGdZ_s=gd3q6hkr0
zbxio)U}2}To*7g17H>>ytTnTIdY`c9=zIs~biOU(S2FehVyl)?cuar*iQp5$;p{;{1OHJi9BB<&TJa>@jxjz5t6zqG0T3?ULxkLIKwO@$j2k*#q
zr)XP?8#5j}x-Fk{QFhC4tqC6&^AiA!=q^Gz=I54cckCQ@Gv<&Ff<(``S1VX~Xu?o+
zm2Ef#Pzsufccy~TInng!4S@;6HwL1O2i?$?$gw)gT^U>;UE|l8x<4(1PFj*Ld0GbN
zh!jz&*2ht_r@XF9kJCLB_obh>U>kptDN4io-DnsEkC`2n8fU6VB9jXJqC?Z+-3u?{05be2e8&$a7|g&z?~v(|fD`Q&qG+$+pG
z|HTuVci5CPUXKv-EU!&^1^Jk^`CX=26PLHXB#FLI^HBEDb7RgR{X=KQ&!0Ocb~!%#
z6S3*=KHUM^r!T7+zZMc`s@{t@(biT5?=6G2%!AlxN!D2i1sjxo64z|P~eDzT{?a*zFcU^=|%NJo)SO+)s%Z^1gR9H8m
z0#&_qwDuDrSGjr>-G8W~?jm;31eJ|OCuR>?_Vf;R5-QZIWzZWoz37~noukk7-ks4T
z9YzUqVj`7%rOv8PXdWti{xa0j)
zRQxe+n2?ov^T%7fE2)w7XIBW~tn^3!&xF8Z)h=i?B4O7HEo{BPrd<7YSj$+
z{zU9hR{+6l-~}lFh3g|+OuuCwFyf2S*3z2UL8~2g8AGBs!cbv@1QM#6_FMu{H+0WZ
zt=cw!;EnseKP(R&YnrkK?e?GBZ@nPofo8)F?niI@3HVTt&2d8~8oe6xMyF?$Kvz|&
zj_>Yz+PiG`i{q)}V~~
z!eTHgjMEM|V#e58~$W!!FI@iMA0UV&r7zq%xl!
zqY&e^?kerEtre_sX7PrC`1iG1EHU}4dziD@%J7T515Ab$T~ce$_~l
ztWGIUXudr2f+8Z0x^*pmK(fF1J(GP=EK_uUP>lF!z%(+E_G3qRguQq1eHE4(c9lW~
zbg4V~5#z^4{+#!lir4%dGb)?*Wg>;>8)%;(8V>HymvE=GMJgiCFdBNJ(XA(2g_s&n
z@QGl)5EM)`HhA%OVkTCKqY`CykfYqeX-d87q8hxJSWY7+j`ctI*(WnJ%UOdb>>U%)
zR!)ji+bpaPJF788uAG-ySR}V6e|4`KA%E&Kz526&AI0l;EEdGL?#23^exr#uZ*K1P
z!47gTVNj?rky_EsbfrRP;le#r?cB#M4rewUwuP1Cr$Q1KK66%eRx_PgZ{nmi+wVV?
zdzhsp!ko{d@yNOo^@(k4aRqG
z=yh-G%6LDbAGPoZb4{Pw=1?jXdew2Q`BDFZ(J+}-w4irRi1L@?cGq&WQ^B?un?=ac
zB6kg^;upJ9_FHd!Y-YZt{?0>YfA4KlDUCd1FgR*8h>xinv>F^`ay!5%+HYC(M)Nj1
zyO*eUB+KQD!Y;CrcV61retlVO`Jo#YjQ93f>}>k^HrY4Bnr{Xnm!-TCCHD2de;hCC)z3GN_mW(=_c;AYkS>pN+sq>
zZ>JTL+j`U#UX&|hxsf&^@2tD@xLiJ;-c$ou)Ij@|@R47JSox%(5;+&r`HLdE2D&tt
z`P}3?#Y1kGyPY{!-G}FmdFr9%>rm9rb8l{%)`#PEVp()LNe@pft_`cWp^+8ku3HI}!rpa#MiA4(n;$L~H
z5u5kexdF-`{o#6t4EH81myAuok
z9g7!HxFn^Vr`HWG?L2RM?|4eIsFsoyv(!ZUl2Cr)4Tf_i4U&dDB2vDUvRBuOuRSQT(QSp_>Vn=AYc%dV|CQ
zFBNLVG@1U*ZQDx1y|Vm~;P7|zRcfdc?W6o<^25emQI}ff?u>2rvx^pdviJSTx6m63
zF3CX(eMq$otC?VfK&3q`N=bKVP6!T62}E$vCJ_|Z}N^tQHK(zRZT|GK~ZeD6^#
z&KR+Zm=H9WR`1rge&?!>yY&4{UGn2wbbJPz7(RwttS)k7iL@-$yC=5#ev)*Z;N@>1
zdPRTI{%}~15;u|FF1bk5JIa`A{|F`;i^(p!p;e;as>>8f`?;_Lm#lPk=PvfZJ`u62
zZ+SUy1YL*~b>w11{%W0?HJneYaN<&#KER0W)@5358R!ub#Ay`YT2s9hg0+t+yK=5i
zT&F9)Q0#O;;6;<^5OqW?rKw|aImRW0L06sp_{k(`aN4qPV?x_`@7n0Mx|ll2$T+EG
zJ&VodU_;ie^XFg7e>mRNsPn|
zNxvAUA0-k~XE0bn5IDnVSJ7cDz5b+_qYA@TPidAvuP=60OsgnWQT(!1-Sv{SkcavWY>AU2^N~xXCEC>U}!?QHQJ*)Lyi&_{nnx+$du14!ah{
zsS??}@;hGU{2p>!A5}K1k1TOyU{$X6TDbH6^d`gjZ0hgcrOX8GkjI7Q=_X5Smib@$
zV(K_N>L{mUdH!a&e
zoTOQBqweTPq#jxHg6lH&taOS$)1HZ?$)9jN
zg{5v(e7ApR8*%SC+J}~by+ZB5U+IbU+Ae}4eL9YU8XS^+fQxiR+tQLx*~TSEUp_x{
z_c2zdx%tY=6ej(FmYDd-JB-*gzsNY_!3l=wg$}QvW|~Sv#-`Z0d$=n%#N`K-TM0Ml
zHV$15sge4sJh-(QjU}>&J7o5quKXRgc`R!f*_XjG*3}lIrYl>IjfleFme%H)6a&!{<_SFvFuQ3Fl@fe9h7&)NUkTF=fmdG9q#V$&v0MXEyfjrmA4Iy5Hj^dHSm_T5jcyi89&8ESc`&^G@^i%(b%B
z^kGdH)yBT|6dN6iHttx=`Vli1GZRiTp&7}dW0)zIsx`noekOTle}{O-Wu>6K=h&m-
z^2@$*;!4}<`sP>m6vZiFbS{#sw_+wr4-ql9Y-SA2y7q4OG;w8csN}h`R~bBDvQ2M%
ze0JuLm|oo|QU6%=N2cX$Z6^MlbBxQ0mOW2U-LNN$ocC|+But;&`Ah4vI~p4^R+2f!
zPE$4!6ZQLM^FoM~f%aIoy<#)vuWihLJO7uUJDUs>?y0kW<6#^m)rsGDnA4FdwV!Z6v_nZ1x8F`k>
zs%(sA>z90_bE0X84Se(eL9Y(oJ%)_Wr2h=UH8YZG<;%
z&*MyxGHsk+nqEc4qt*He8-$s7f|oW*(4f{hFD{PzF+{C84{nI6-1as6eiE(LN!Vzg
z(j=6>#_rtr^&ilV8X#gE6}rSFBo01@1tZj)ew20|Im31Pr7@xW+<5`j>ZOiFSp#2y
zSCAS?4fl5rawN%G!=C>@zE^)`OnyDS4o`y$dz1g+LTX)o7W-u){V~fQJ8y7JPJMb0
z;!OIEv~iZ`b#YeN$IsKuu>ZTQ>pS{oaVBTyEQ}?>nB(3)R7ekz!KN`5Dnbq_qBIH1uf+R9k*&jruD*_PTj$MDD18B7
z44$dz8y6IGUm{K$6$Bqik+kmko!Vi|1Fzct-&Y9DPPEJeNeSy1XbPFABiU(Xg*;NS
zcuo!(J!(Ulq;`Zd{HS5>&=7y1s;~Z@lOyS}mDK5i<9^4~7d+?yg=sN`4IWMD6}8j$
zK)aAAg1HxYUOBsv`aB%x;8MISw!`l!?#8~O64njWZ>cnM^w6+E!uvO=?=u<=mIpMl_VlQ!0%J4r$6gUM1mPm2A(Qowc%?H#s
zk4R>}P4hkZ?8dW064rO9^%P@WWp6116;TpGEwr_j+I0orbey7WKqU0sE8JI2KV;e)
zj(;{FKW|$?lphU{zCUs`D6;xn4m*eG`B&eBAA4Uk9G^D`GVpA$L;wb49YFoe5)hz9
z!vA#KCEe>)Qf%5*0l}C1Gn}|Ya?)*inOZ=yyI(mq83Y-6W*(Hgz+JyzLc$*Qd;iTi
zfKg&10-fvs!kPZdAmTZcCP2mOC&4H)(PwY1SicbR?QSA9kbI?jMndxV6X@PBaRksyT-Rp1
zS10eW@HayyPh<=nR$uXJ`W?HRC_k?2&GZ-=sCQ*
zQPb2yPD@R#1Pr-)GC{ivNExpIlc&0lrVXN{K;<;EOIc3zVFQ9iPT&wz6zDNl!0PWa
zIVbpMybxxs+q4x(N-tMW8b$t2$@86k7JH#yQ9|Nm7jgaDb1^n&cRWy$7S69i`az35
z()@|WYl5qk#go~Wmuf7u6jr-|x|FBpeR0Tj;FZ%dSgF0wNKL(}(+DZM)h+*Ng6R;s
z|B_D&83SpLQTWVeBM2t8Zqw}_Az~ow%0FxwPRP~O9vy}I=f17Lh5&sd9BM5s^kuO*
zHo12c3<`fz?tv5E8z0E{tN~+6N_Y(DIh(swO-}>IL{AK9m-VqzScZYdpv~96x^Cd{8DeV
zyJaYu)KP&WG2?*@(Z1LU{1#1MbYazfL=fP+^%DfP&!LqyLvrV8wW;Q(QM9bikYWna
zX2XNDGP%l8LSk5e&c5o5{rgZ=TgMQ$@UT40h6|NO1Fm^gDh(KfCb9}^eIm079E$@!
zMr%!Lg7DXe{HUM9RAX0ap`r37;G0}q?jNM)wyB1u*Y&}Y4k${PO#Mhb1Qgx{lJ)_l
z5zR?u*VY6#(DfFI=!R{WUuuHlQBy3y{`dpwpqn4)c+VDFY^FKk0*}t*1c~fXm4O@8
zr8ny5iV6lSjjmqG7d!n<2D+)3oNdKJAAK;5r5blO5`keuf;`ja2IOO#fp0Q73_a4p
znh2%54-S!1Ig^mKnvR#wZTk@m{;%D*ARibH`;LPe3ajZa1)5935E;5XmBTgfg7#R*
z=06~)Rsff-k%-xVCd7^Hkb+isfKgx`T2a^g!s?LN$S2L!Cs2i)XTmeQ+rh_FbgvPf
zZw*vYHaTD%`u&Z^Iq)IAj^L5EL&QXhD<2os307L4Kfi4|+wiCJ0h{!@>jMe4PM9>^
zjUUemlSSrOs!AZ;roX_HOQG&pvR_`rz!-pveciH_6=wOW;**@^S#et-dGirTU~FHM7jQIOQM?9LeknF(!+kk
z-ZfKGmti?DgWh{)u+qhFoATo@Ie?Sgl3<#1iThIivnncYqxR-xY40hw!yDRp{#DRX
z&%l5|)Pf*K8T1)%N#ZqFb-c*<$K!*`>ZnUj#?e!mV#m=1sEtXz(G!
zSk|KhH-m_`cts<(Z}v<=KPy}L>-sSdp}*CgC>tJra>VcJ(M*1DVs-ve=@O!w5ohw+
z>apZ->L;=5pcD?@UTrO$C*){n>}}8JuP*(lbdF^ePUbm+*_?=#>x%`SzMH*P#w|6m
zY@(e$5r48(60eUoXhNdUGL$MsH<-!Q3GuUj+y^rPv#^tuZs^)L0oApyxi9JUU6YeW
z@93DTu4emz`^l%+ukXADn-AJvPC6C?v%3IHlbmCtpfdw=N>r3m*DMe|5|_h3pT)0y
zWgk#h&S8p=yzy)31yI*%Qh63PIFh6Jd#4?VmJo1
zr^*B@^gjYM8|vCOvHGCpPH@Y{Snj6j$unJCwU!G$$wz?Cg|XB
zlH3A^Ns+Y#|zv(B~PdO0*gwj@2HH-1oTul7#XHhFkw2+_m*4^
z9CTYfX*$!9Z9Cuo@wdF~H|Up;Z_>2TUGLp&{|&~?f>7mCFoG1%NB;diCGXVOU=t$m
zYxef$ql?zG6U5vm6pMV&hjiJh|kp6);QX0DLMiO$i30gUMD{Z}cPX%!2=c
zx?^OlaG=Tj7!U~9_Zm;!p{FYR;a7`vPt$t;CF(1XL8mQHeZOUQF)-DpB$PmI{gHs`
z6=;`YV4(;Fk4FoIExt~>IJW;O^ib0!b!gFDF!o)Vq-=ne$Qsk|cRD)+()E*W&}%Df
zL}7Qu>`yizpLl15eut_o^%-k4&(nMVjhG~W20iv`O>{;bCDVXxY;-tn`hRc8@9jVN
z?k42Ge`YjoyJ6QqCkP8ReRvZWmwM(zdYc+7|BZ43SxztyJFBjpGAh`BoqN?Im>P)R
zM$9>qM$VC({wMo;TVAsdN9`)3puXOGBR&?8B4YSY8r_e-QFe%q3-{9E8AV(*7hXu5
zguSOs!Q11B20{6ZX$YSp8Bu1PyrS?+Wcz2@ViL&-u%+S)8l!2rG#kM!h`OHXGGHAv
zumIa#!)rfr|C7zre;a}PfBEp>J*>S0YIu;aR&(6waO+y^`GRy5WJETkQNzj|q>oYO
z@ua?yqZ~;WUpZ1A=&vi1UhjupO$^Ts=>g#ZiI>F-}*|A3GM0I;UVU-e|=v`#YuYA*Fx!8H7k1^9*ljM36zck6%^Qi)6&~$cwELeg_2d2Vt9WHR_c$9mkS7Wk$rO&foD?j9T0lHuYY;gI
zX-FZy1B?5gFgM)UwTL%4;6`$s)r&KsL0xC`GO1oL2okl84$MVftfTBbcxMc!K6n!`
zr)~NLgAe@pNYq!Z{utFnD@@!u1o@Or`dY?W5@~h}o_RBd(0|jO6~kr6
zASB%JK#Mt(r9l|O=6h_#thsJJYmlEBR-!Wpuj3t$$HoK}(|nEEdz4UO*;e}K5nVX`
z0e%j>5rfSUq05GFBOSucArG;$G;3TjbyQ=wKNu6u|b|DDKC
zM_DHB*grj)6)1`b6yImZORHE%DSn+pYV4z;>`n$^K@2N`DD9_yiqUZvJp!xt|8u^DY
zGJA`o!YsUTu~=ThI-Hsw)f1(G35(3X!N#zaHOPvW#w!_|rH{hlum_ME`$o+)NNVGv
zF;fDZ4kt6K*Y#s0#Ujiz*#b?n{JSIwM1ciT_PGrQGrojHgEnVf+L0NO)77vl>W1dD
zMjQYZM<>oc%s**nOq&D1$TP|ziDXNNMomVsgA@2K_^v1p=1SOyK84_`)bMn3@&Q}U
zba!@+l65GW$!HzrJO2A!Qf!>btsYL+|Ih*cOPB^zl_$Et?i+@kgQJ867VS5L#pBH{
z9bm%r6oQw8PQ-32!E=q$OSqUhs0gU8r;fWmYQf22hKnPq$8#+C^c@Y`QQ-A0@
z2a#u5Y}^$^Ij?u;<&oMfI&-lR8e^Cnj83F;OQN*neD7Rg{BYrny3n;#wRL`-cV5Pf
zdkXj}`DWlEv&%M48WsG6X!W($p$W=&0)e?dMaY+Y7oXCN-tWilRmfCarxN;do${gP?8Wg=*d~6SIl7mohT=B)nhmYad{K*25El;qz^ehC!?_-EC$i4g@^rVCnHQYzYWf)~p
zknoS9tJL*nT1mjZcR@=RmG~>o(aOJ|GrX6SZIYXvCKp6S2V_K;s|tDuUi#xl$Bmxm
z+wQH?Pp!H!6>^3mtDR{H-B(fLH=R`~
zFY({1cB}V%DCAz9+5#mpfRY#x%4JrBuo?VzjF(y71du<+953JR%fIqUB}>0f$l=97
zDE(!(>SMgrRsme0gdG*esv+}{G#s@sqU$>DjD8;-7JcLV?B@y6Zs@@TMFF&$hz5@N
zOgYVv9N-L8RLHarJBYl>TB&f8e7%a!4nfl6`XO4&am2r)oW--{u}eYe;6L!@ekv3_
zP7swkwnQSIf0|Q|55u#_@;X03qu>5~pY3*V^Y^!T62$7}AMaW#Sn(_@9m7r2z;u}&KtjUup@5eDjsw~
z>8%@OX*k7#?f*QgCjdOjY1k!Zp*-|JSj>9W&k>ByH;!8NOyDK?lRZ12RvK&tMq!eh
z#-V_^q$;40T25H>at_aOCZK7{{hIv
zPPh97WL4P`-|LVMKlCU2j9|P(Xe#n-RyXrGJ32yTKa%?J#6H+eaFo!%GbCYe?F+Q5
zUYIIns}<6w&lJb*Q-=tf41lTz469<
zfu@71{lv%%9T*RqC+3Vr3D4Hf-+xPzHAJAoXf(Js>3cu}}SyY+ip>3x8XP
z^V&`ysg?F9BY#B+{__j7)1KYU1x#0Z$dv1@?TCi-8VNLA3NSJ=<72{3LwwyCo*v)*{m}Ykun!?ZbzK5KKl34
zhR#&JH^)@WUF5B&JxPi;2!f58FjSQ3@G-Zt5sX8HWdQhUtZe@=Gcsw>fm2;B!x0Ps
z?!}p$Vy-%z5^&;zLbcsZYVZu){lC{PdcNLT_s3*N!EU(cQ_z>g#BY}zshiBCA(Ip7
zSCbV|);->m4FF-h2lz79X4v-`Kz!Z>VyDfNt8=11djwK@0*8z=6v5&F%aoJNbw%n5
zp+tRMbXRdb0-!({Y0Nb-fI7v!WEp=ZhfQ!xh)p)NS
zb!vP9kc2dyDVy#ZJH)YVp(D+A_rsY1+*FaoM>hSdz;}n3_a10#va36_9(=dZel+*J
z7zHQ$_>l`8aDh4y=zz6L8dY`Ss0Z|32)qmdmXnkfkT1xtU_&Y8Ua!R
zPQ9sxP=pF_QTec;yAYVJeB!FV^C-?F1SanQ6}PH)b%Yr}j6Op^k!_;}+<6jw{hM_V
z-+lV_%#eC)47ggG4b=q9S*I&Fv_tu*r&(m0S#Tt~JaRWg|8r0{^=B0Goz;B_RPgQqMUlx!)k}%8<=ga-jiA
zF@vO}WZ?!85QT?AnktRNa(mPkdD*hqB4-m0D+mVkBN#v_#I^2xIuKQwY3+8Xk3EcR
z0!h+$a9Sx?^6CVWG5}iu7ySdsT@O&m3$!L%6B8NiKzTV{JDDKYmw>(b?F2)b?D9yR
zfBzpy8K^*mCQM&N0*n^VR;CJ(vP0nDT`=x`_^N3)tK?j+#9Bz7hSgJbU2+lmUD;?>Cjs
zNj*lb82LFD|Z)?Oh4m8JQY$Z23~@TV6V7M=2@uO!hGmC1(W4BI10SHh(?{2XMr+
zwE-jos{oYDpM?1L&saBieDrs~VSgH?JQfPL1qM$5ODcK`3aZ~I0GfHB2uL^scC{2h
zpzcw7*6b#Exnoh#IV06Un7KR8AXDp>r%v2Z$V|@Mz$;N`UqB(TEf09Bp#UNPDbcfu
z2;}VL(xZK&bioR)5+)L)JfeFh~cu+hL>i+^b(*Aqu
zEAj;(ygijyWKqvyP!)=3FTFW8N`dlcLpA~{k7PBM8J4wm5R6~Wg`W!EUt
zbgL+(*0~+>7>u(Gqyf(ysGX3`-T5c`1}3=E1zp|!Yr3!UG<3cb
zkS~~|z<>w`^flck642qxAya7$(9CsnUi9(Ny`SQ_>_NE2KAn*h&|_+!cq<6HsMY*y
zu<>fxus14r*X{f4>Tj!izjdPr`v#Ndk45f=1B}cy76H!oW=Cr({ie+71DEdOs>A>K
zp$VBEZng>=0}jfELbFgsl?{%2yE`6GJ>kkd0H6LO3Hh~&hhRiN8AgL!tlB>o{^yMK
zU(g>x-#^js3h5e3!O62+b0QBVB&LeZ|IN{KZ^PS^lpnkW(XTJygsPAeF7N@nV<7PaHi0?J9(R_{E!GVw74h5+(f?~%WfS|BRMY6mG$~S
zn&wGV*yIf4SXKPUs(AgLMOfruH$)HdO?rUgJxb=_jlNMXSPcarPDz#g-t(&+4XNO(
z06A3ok;&0+9)W3&bJnopQNxpv0znm>b^`0mja;~IFFWjib)?*mbTt|UtAe=WT93Ck
zTzUWQh42hNGl9a
z&leyANWkbZem8k947$w?H{e*0VL|wjly3OYh{Lrx}9I~2FZhT%qy?Pqxvg4R42D@`n
zqH+-JBwc}>h^%~l=<;nA+$9=R$D%c=>>K4PK_Gij6>p61iVo#3y+IRk;K?FsLC%jA
zT5>)gDE!AzIIylboi>Png#SuvR5lc(7cy;2$f5Ug`s}fHfW?o@)Fg{a|Z?PFv!*d;+yD;b6E=c#4TD7=5h8zF+c5kNk8
zo|FmIiKKoARXrIk$H+B=auCn-lv|Nq;aho#E50N_-H?3-Ff+szjYCM&O4E2pqmQ3!
u-l5Y+@)#$c#M=bzS-OPELT)~6PgM8WB7@K0GinI
zhu?eO`{(6(=3#es=FB-~PJF+g_@JY$N_X^O3w`Zvv+g+G7Mh+?OGxufK!tXJZ6LTFin|LMdxGv
z$rR3yo$e^{t4};O*(0J2O#Z+?l=1~|tz!`XKgMs^uWAY%uE3l}zIIt+N
zHSmpM$Eeq%^<1xgDW3x|ud=djg8{UAb`UE}@JHznPsv|tH^aL(ip0Mq8zW-u%NxGJYimmCDI=;M_O^ZNKYeB+fpem+=?&oA*%t
z)Z@<7$MY;lk$4%nOfp`d*}ZVUgQ?GhiHpPx=6V024}xu!`QHbRaiEy{GalJu|NqO9
zO{K--1CG~^e!h^$eEi|f>GoK)^>c|CJ1U8#pyT=~E#;lb3fNqu0LDIhGa-R70}i7LxSVNzb})y^}b`Kw;D-aoZqV+G1BUQ+QZ
z6Vhljnfza03@_6rSC`a*4_vvg6~;f?52Z~Ozj(wb9}+a~baj4^_jh*MF2L1c%
zxrX69S#F{{b+Yx7Ypr>*!gNlgkI9ybQ?q~DPgfU@gn>HQUcL+~&sP5W@H-jU>pWY(
z?c(?QNB+0}Hnx71(P870+I@dV5=F}c(n#a~y`JSJ*gv}ze9mm!7hf27zJL91G_)5@
z9QZVTr8#h;@>I=!~zMW1oROvBY>N;r!6N&3A3yYjpS;4;T=R$On-s2Ehg4V>-CJ&svkV_tnbaP*NRc0Rp?SqO&_EOyHS+pTX{V3i(
zxGsx`-J~aJ0`Fo59l}@7KM=hd3%hGV%+yBS-h}0%UO;`{BdNmoh7f1$;6UARafO8v
z7ja=a{~mPO`Yv8}#EN>de%b4pTG03RWI{w}iv~v;p{{FDU?hf=)^y!o^8GB*;`_DO
z;^iQ*=)ZzI9?h0Yrr}d>$G#s{>clThn0zL5;~1aBU+uRg#0qsb8|e6(@V}}rN!cY~
zl+X-}Z*-aan|F8pzT<3`m|$=&l8{Q&kj)FV0MEtg&6?Rr?eNbFSBX7H~-&0WMJ`KwWU+OzOz%9q>jB_%@YbP)xM&ozl
zWnx`nbg4;?pe=?^KT1Y@P30_}tocs*^halKVCO&1_H?~H>8p#CgcE^w_VOZdD&~d*0
zolG8Rk?i?=^7?QV-5#f=gP#S-}5ydsekmJSQrT$ed$~19G62DY!)o@d3FA!RnDMa89*ZPU{?LxM1o@
zE;4FN`aLLV!x?g*V#}$%o%JI$cr_%(ZH_I|?fvHU$C91d=0HdDaEIfkknaSBW%~$=
zJWlqo8x9x7DPP`0R-M^)GfecZ=`zGh1ES?6QmpSkKfXGl4js;Xd2-x1=bGh>mY8!+
z7E_Z+W8|T~yWWt80Sm;3MsvS~h6ufP(*=DjfpNdejJ$rmG%DO%XOwh*9C*;-_n}eq
z?Z9xk66u${#yP>yJI9)`%ZZ!KkZ~;aSDy@1d^~8DMe-THQi||8#s+hrb2V?;?Bbo^
zrD6MF=Y(kxTD~FUXujyh4#mFZgZc3-?q5i{3m*y}lKyz~P^h#Rp@k8h^63*wA2p2n
zhpK~XOVss!4)En{F8l+-VZw1{$XQ~^>B4DeY!G;{VXZW{$TK!Z=uh*IdYFc>j=fq#
zO20z9uK1_1r^MF+Z|UDH6gNSPiSu!0B8`}nn0#K6#rg`sF5<{s)&7@ABb~MnS~N>C
z1@S!jzdm`GZLs9wVt1pbA%=Q
zY~g}rQT@r&#yrE7!`jE`&6x3n2uh{o^QZNwKV~i@w30j|gBYpqxIOa^nc>zF;Ba{n
z4cpd;PI$A3p0o#Edz3q{l$ZH$t!%K2HpoUqGcb|w?UyG^fN^p7y*u|0n!t#lkhJddS`
z(+I8$M(@T`6H!5Zn-DH0BQ^SXHrI5oRopRiNoCUCUX*%;m!ht4Vi&%n5cU?o4fyWI
z?Q7^r_Q3MjxBrg%9wDTCc$2wa2#(1+Pgkdao&!U=2lz>&!L94&EH$(4_3`kN4Y-D&
zb$=o&%o6N4QG$H7biaS4o2v&(7HQ`U-WPOxb?|SytV*57flTHQLo3VB!dOKUf}_p3
z%dtblybz`(n(a!woV{txzU303cL+yl4SzuWa|rqNkJn21n}!^eHtxpUjo2CEHp8y-
z16%^jMsBVlu>gKE&|3G-f9qLDsrc<*Wqrd>me7yxGIoRY&KhLj
zoRpj>CD2(0iJZ@Sku8PZ1;1Lc4Ebko5%OXaBj;rM
z7oXQBuSkTz<6VU}3VO2NXb&w=6bhVaxCDkJu45i`$N=g-#SSPml|HZ*Q-@_E4_gdJ
zP_#~J08i?^N0xN-;8EcKY%?!z;WfuJ50hI2b;7uJS40}hii!M6~S3&Zi(%QYN4
zoNsibWuLS0sV&Lke^ox`{JNd`+NF$uZ`j#`blpSUGYd6;m?C0i`pkuXps(g48Rti2JQny~@JQBak$G{ED*?yr+
zbOt9MQewc38J`V?8e&L9=Cv`WTr56YBmbB@MSFwLYIFi;Vnu)%|gX*7&(j?*8N5lR&{&ZcEJ`
zQxv{vS-J)NSR%PBmx313!6WdJEc_ozw0E8itvz;5FD#+F^lJIiEL7X^>REKl70pHY
zkJ=1G+Xho#DSgHa!}957v*tK$N?g>S7(tLmMC!VXRRgk#Abe^?0N)i09H=sG7|CpC
zN@?+cJmRx_45M^Jet-9|+%wD=2VB~o?Mkl
z8^`^+g`R~p9xKljhQ5e?yN$b>v6kW$9WfC8f!4;Gsc%38eoNe4yK3nIeL}6rk^rO-
z#l5yrC-kllxNYKFv!iN;Yi#ukxVY_lfR$ku(?u2!ws!N2uQ@vg=%+fhw)NUwL26EY04
zH&o@t1%lW3m2PY3F?zSNpQwSJRp-i(7aHY=!K6LyA@O`%6XK`7{c@pP2Ywy=+khd-
zX}_Pte2rHNP8$6Mqg`Mt(2D0U2Wb!Igj^;d7kJsy@3?@x3i8Y@D$@#@-fi+}glo6@
zOEk?F;zK$`jDM66A;@JcQuCOYCZZ0Mnw~W0;n_ox;yv6mEiiLO2hrll;o1T#dTe_U
zWXb<2%XTB$#mvSGqFl3oDn|9`zq|~R+)w0Fg*avHR_rO)`N=D6{`{ME=TkylUkA0;
z=X#^YlmooIHp{~$Wy`}p<&{@z
zZ&JuZrz;DFC_E!RYW3Og4+!M6*E#;;Rf&73`&uO1vD?V9a8SV5N2IPLa`pYW`fP?y
zmq3~s_-8FY3E}<+b_|Z;{AQKKEa;hOe780uIEx)d|AX3JWn2Nw_;SWmvLV7EQggX<
z+I;*7htFk)sUkp3Sbf~XPz6ilh3nQT4aAF3%7dwxZIz?N{!`Kf!UlI+2j1t19I8So
zv4MEyy!<+oPB?pdf=HUD(XLhHr#Z9XND&m_+5=P7nRk!aQy#o|zuao7H9hm@0qZ0W
zP3V)lPdxTsg#!azaBVyZo_eO2ai6(e-rUCPWPalrFa}?B{!mhGrUDqM`Ymb0H_f@SjBCdCeIgFhfo`t=78?C|$+Z&{3N
z2PmUwORoM^;)&{VDUro3sk@5w=@y3zsSGhwA~I0A+O~GI4nG3O2dT-yS+>yc=v{6_
zi<0kzGd+BI8TAxj;Q?gAs^bQbCiQI=ljhpBpVWH}*e}*!lN9^vC+YFvJ-~lcXbRLV
z1m_ZCV18~6lZ&%$L;$GdKy%>$gbre=%S4=7LE{JlRp=b^J|69jd=*@31F^u5m#DMk
zqfm4$8L!4xqXKZ#g4Zshwd1Da65_N%W
zd>ExjADH508F#26Var@Es_@54TbvJh{j@Ux4!
zM=x|TLlRGr$dv+WJcvl$Xt-*!x62E-m3Nbvls0H3jgyN`$*{y&_#bPe7%q)H?pO5_
zN^8}{Ytcz&!t7TgLEtbJni{B710Ccu)nJp(EpUc#LS=i_i59Fy3mf_J#qV
z-7Av65`j6^gkXk5M{Pq=%-gYkinDh6&Eun!PYRKt8q#7PXttBZ*5_#bjmEWU5_?Lc
zluQnfQ^gu6SPi!!F#;-v(qz7Z#)_y`wb=ry>}!F``3##&Bdu;4Z$<^bYWF4UxK+sG%{6*qvy5F8PPA6Th$F%(IrJrki_E
zmZ&Le5X6joMVfou4e31NjY1%hQ)&daoZ2u?jbs3w!cM7HJZ0PMe;Q#Gm6`h8z7p=8
z#}RrbDKcet@IcT+yM%EH|Fu1|7%|iAOj9Ijp*23KJf60!et&N=(2w>|AP-Ok&t;Mi
zrF@A~FUrQ2NpjWGDppC3cXE|t1u0lY6o{eF7X6J@S3Yl0MDouR7iqnO>wHxQXTbK$FX^HjlWRi^EPtbhT4Ii1%F!e$ToYt#j$)QBY4Dj7~q|a=<~_`GVD8+MDhgwwD76PUXQdw
zn>W7}b{MuAi>`&PH1=o0(+_`kIQD28p0GQE;*RJK&u5E-mFuxcu?(q#+FtZZbBN;z
zf}DxtX&zsbXE6KS{KCQAYG`hZimWBVS3VBLs>h7S6il1|*3$mI;cgG1L$_~F;`}Sw
zR|iX6#Xv#6WSGD{`9&5^imyVhhr1f#Mi{<&)TaraBM;t^^g3VgbC|BSmU=Z(N@C{G
zL(>kVpDno(FTZZbE350DeA;`!4>`}OMYbvgMg+K6NNo+^I^){yHpTNl;;DE9m&RD)
znn;3SiGk~)*36nl(6kP``tX)*@|48UR;=3AE^9ku!8ERpfwE;rqp?!%535rE!K;PFzJ}P1}e+l2hnO2i~TY2@Z}uY#A*zbp#J1f#o}SR_$k^bq9lO?mxAj*aKNv
z849lLQV0OB|1x|rtx|5k{iumYx^Ubi=olaAFSl(nL7FIiHFwzu3RdDv4jz1avMq%&
zuqs4mQEx=1h^dX+K>DyW2r0JShC{{@>Bq7)I8Hf`r}!6Aj(H5j;K$NN-kqV|At}g~
zF%rR4G2`)Gc4F<=Y>U+|
z?ZLu
zXLKOk^+of3zS_P3sDYC^3xjH9pC|nTCUdb~V!iAqNw*cTcU5f0O^+}}u+Q)%MC$g2
z%exRaLud<#scnc~nWU#>a_F`Qt5aixlVt5VIjr#iic@l^}wkc8Fz
zpWV06%Fam16d{6Aw5_uW0h>(LpSx%`r9O*D$xITQ^Kp+zbZ!oTQ0w26a8rW);ydNL
zMWyKOP{s>zwGgZ8#&ro9q=RtoVHImeZWh)Qw$ObTZkSfb37@4PBF-h+CAyYhz6;|T
zc81J1%PWhf^q7I$YTCsKmu5SoC);^y;Xe3ym|Yqxm!3)WBG&Iw*`578^70%2y!+=FaI5_?c
zMXku%YYG|`sWTSeQzh&?`AJ}sB!pLq8}hiB{O9kh*YR7Cqf1Z89YYEOI#vt_IU2Zv
z{y8Nfukh7dC*?4q&GwU}pU_-EEeXXdDmXoBFTq)42eSNJS_pZ0+b+Jq9;Q2wZoOQDh)Px$)|f>yR!&!}ayV
zT^y2(P-r--pz#wb3+fx}-6=fFESivi(Sxr_N6`_Pz|KvuKp?cz7Zw6dQy(Z%{bx@g
zAy_P*OMxXxMVHr1SIpGJ^Ub=S|5BRlY=|#
z+`@rv2nwmxJFGyM)84czSf^{fu<`?6iNSYRts;?=V-Eh0e^6{fp*7ize(FH7rj(Fc
zPyFnt9fej=wyjL@#$Yw%7bxUW?|5|8Ua5AR%T%mR5lr|d>hNyeiSkbZ+F2K~$18gf
zDp&ZCh4~3v#>)e}>B3VnVbLOm)F`AO&W<*jqM5#|BGFqO!sk
F>Y>-m{P~(*#e`
z+5HoHB$c$r?|HCC5X8F`q9_)`9I@ny%PK5O)5UI}bxSWfgYHe?%0|d4_;sLpkpE7rBj-z6`!3vC@1=c{*VD#v1vxswM7ylr7!?Y*1iP`@e;B9)g(ts&*7J;M4ZfOv
zoiAtER?srgFnjZ%XzjQX?fa|nE0Bw_`wMf7c>sEjz&edX^mL&aDX52PxvSQ-+1LqQ
z=H!Xh<%zaSI29~7Bv4WJNuVG&xZ7_a2Nb#AlVKdi{HHC0B0mWS7mk74y(eROztc6+
z8&iaoYnSa~Pw|Z=jBoWT;YN+Id{yBZ5I5aGwx5+IH?Kthahu6f*>J;rsuZIamq#d~
z@DxjJHoDrYz&!JtCJ4zQ`S{b#^KV03HL~gR#7rDp#t`K>7|7)j?$`9#`>=Zl?aa7L
z7HJ+1>;NpT%un`Nz)x$k*?(%btq@?2IoSJ~kBHRuKz+*)d!*hV90f~4ez^B*sq`+A
zUB)gAfxb94XTgUIJbnslrsPfff3X#vXJ_Ej$~W&RQ%Wd2yn->A9^wx4`qG^ySn|i%
zUS>1lt^qlTBra&C4HnG2OadVW0ckjPL?Hmc#`bV_K&C-8#^W-O=V)i_XOL#aaR;2j
z-&lG$x?Ge!s0Y}$0$WcZc}ja-l)leod0|P&pl-zlJQ=lqzk1{GGI$Y{MckVGxL_2b
z!vVTMRj~VlZPXqE?fe!otX2J*h6#N24K2te^W8!r;MwN{%s}#S4Rpop!S|x82-Rw_
zQyd^Yj7KIARL+14M0N-SxAwxTKw7LEm^n(*y7Viqis-rd*Jz~LtHwWo&yUk880zyo4(
zvEY{j!_LvjP>eRJjd9^R;sXCqvfT0d0l1PJg3A{gitB6L^N(%_q_Y0B#5OMkjm7@W
z<~|t7jZ7hkC3w2cYj(gtxO1qfTqX2&is1ZJ8lNk9=}+)U{s}ldQS=YFdf&C3GEyhK
zY&Ub}E=&OAqEW5W>)Y(}*)Hu6GqPgjNJe4HK{nZ4Uinw)@U9fZje~?F4G$XFo0%0
zFK0-@0s8QG+7{HMY7W4m=nRq1o7dB}32Q0(+K@NFT_HEo9g8Ef=Voutb_r1chWhoF
zk)^rVes19Yr{JqIp0(z)Sto=j$V12wf=9}v27u%k8N$|BeoN-rWG$`>tzyp8i7Fo%
z#tJp)&Zce2NM%oSwkLR~?z
zQ%)0~lkyl%n!0r~yuN-;CTp;NkIhf(zmR?TwKzTW@@$VWx#8p588|=-z9I764+8*=
zB(*aEnkxQ{5Fdi+f3*Oo>W1kv0M@FJEq}TB8F4GS!$@h|%WON)kIB}1sA@$L_IF%EDAmzvvYg%_
zH-HoPZ;j6Qqeudj!{)O+@f+a(SK^=UV?^k^q*wnLflCZ;-EeK&YphS@49oGIEmebE
z{)rXxzcU$n`Ee7DbV<91B7wA%
z6JSYv2Ne$er{)0`aA>;5Hg@E`gJWp;jN5z#KC33I3x)DjwLAIVO9fUG4(+XCshuu^!4i^ItXmSp^
z?rw2YivA`}z*l{&7yhTeW<=kdyq>Josv6!jNHfc|CJW=Hso0`JlsU#9D`16%sql0_yA2@|L-8
zAV#2R9?tsw9d!=Z+-V~q=O_?ibZZy67ez>IlO
z)A9QDi4z#cK0lt}AN4Z2QNLm;X7B*!?=hgrz^oUq>uJf*A7{&VQ9KSs@A3of#%1*!
z-ebsNu~aju?Lix2KEccZLjEdH4ye>(#;E8$@&?p_)vlqFA?Fzd2!OcG)n-%2iKtLl
ziS3OsD+YLdJvTua$P@huL#=)6&V-PC92pFBqW3!_QOj4*9^aPz@*Sq^pH>-CG;p*0
ziRRd?C;%-}$NTT-$>zI#!WqDYp7FVRDITYxLIF?<<(2
zD-BE-2&70%OQg;XP#P6ua5S&m7&y_HcMC7S=h({$e;>95zg3F4^Mjwk#Yiv6H&bms
z?s&46tZ=aLn25^vm5M9f;ghP3zf5VE0NPB?3M00%wA$HxO@PKJQtjj53-$Zz0h#@B
zBPb0v<=LWL?xlX-h{b{zqCP&wa#4~Ek`t-hs3RZq7_@PKd=95a6?^n~gH0`U1^~=W
zGG+On8j}0n1R$jn;MgNE!(+mp5U|~JhLDjrE^*bhDtH!_vbc*0voT7QVVq;6W7)r4
zan3~wIu@srYg~VxBx_#
z@)p?(?C~qWo$?}OBZWvlhw-3@AjurE99u&0+sCCa
z(jK2LB7j~h9}ohSo3+$hi7FWub#ZRJ!j0n-ne1wp{-8FSoiFTS(p#NJ2wO9vieYTj
zw%wMB%(1f7di1xx+cUok
z(UDaAFNas99=3d^`$`uxgN(@)`jZ!u<`o{8?7aYm(s4<=(M;BlM5>_Hcv|mZ(DbzQ
zsvfjN#>}3A(ef!#jNbj5(zeNxNgLpi)OG1ujLhFRJ7#vT=F@D5w?|F!TsC4Xrg`gh
zMn!j$n<0=+G>27oQ^0)h_7eQT3%Qb9-uC87s+V;a{ZSj?>7Aa!pRVh(>iXC=*(35G
z!|MwUv@uR++`)phIERGE3Yxd-u3gMPzIGvvxCPTYl6Lo0e%n4|45aZ~`nRcvBUf^eybYLVjAZ)i)8&0g
zq43%>-Ixu@d=+jj1Aez;V0J~2r>buQ3I#PG(_qea?32n7P;xdv^e~2baok{-rP@q?
zLKVXW#p<}cYATVR!>{zcmk{dKSOCsXZGwPeyHK{On;`y{bNA@m`i?yVSjQ$&sZ^DE
z+cPq1KJ}+-9xZg?D+Q7~eLRZedEs+v7FPnjPf^OyGY{IGY!&YO-162Qd{j8Jk@MFn
z%gHLAoC;b#%4kns^f8CLBtN5jcoscfX*&(Szgp{Z?=G@&~_1JA`w!>XciiKSqaXy%(y0u(rLSC2b9`{E1WVo&
zfcnB1ruz7FR53q#aWB5g|A-J6{+*4>KHRRAn?5i=2$!b(()j3EwAL&~?3N*>8~L`o
z07mY>@@yG;_pa7>t~5%mH7pVAz9J^{k2K>Mf%weB*QDN9jY1o(FHuKOiOOt`XM#qV
zj!)q6kGttPJo6D9Ils+F2t)G|*!_qm=%Husr0b=WDYh=2e98LOl;x0){!Z6b&1FzT
z!O1(s4Q+)N=b;tDlpDqfxDLNI<$GzN+U&bTp;F7-G-H+Nl*F^Pk<_AB@krC~SjtQz
ztl?p27uw@q>XHoNssbVdEw8au`}?AkDRiN08Ssgmd6Q&7@Q0>$S|qt{$!?j%;6j*u
zk&%f{mVk%6P@`^tL0Wu+Be{Ssvg3&5(`sOZ=yNkqQ+~}fa7}DP`mxdL)kKgV-n>eymC~lr#oVGIV5B`m+kD9j
zcOoFf9Ziv@(@-;1+CJPI~mUE?V1}*2m#2P>GI$mtTb6V6qI;s>A{Zuq1nVSW3kyb9V4>oO~
zLez$A#ffT;F9xQO&J_?hN?Z>IM=f4r0QJ7p8W&H^7ZyPOdKIrvb0o^!kY#5oVmVs)
zjk<+){3bh?oOz0}QSA{X(*rS#k(88V>dTkW?+KN4R+uAN#7u8#n8lN%
zqGf{eYK1KE8CW-UVW_dqssp0IgN%s8nM(wRq;Z`V01lm{&pY+R)_@k~bpsZ(}
zZw{}_&YEHrd#wPdX1!!9^xytlO@0AnS8b~QBe7T!du|l0K>7=KrtKRsQpK4u)DeL5o_@(^0zXSxp@;R6Pd-(XOA!pyG
z{!HqwpA{ywKP&JS3#K#01Of^99vNjY^#LOz4oJzUDE2tD;XDcpxu>elNjpw2`b?2lNo4;d$=Msr$a=wHE3qiVF
zS`ou%v756wH%&mfYf=ZT0dy9x0CC}aQs&Ls2EO|Q1%pw-*=jI_hkkgj!O3WQk|Y5J
zBzfpu*|w4@AT_<$h(oGOtF16K(o*<`UpBd#19E&XppchhTqrJlVJB?m9EyO$t)yk90d0D225QPBJ`n-EkrrZRaDKQM?3bu|ehg|7qM?D4lOD3iQ
zQnfao$+4x9--5_V{?Wiy%|8Ho$pRUrDtB$7dzD5#fy=2PZ%Hzr_#;%}@L+R;6GcDP
zT@s~CK5cnyRfV52LuZ1ssb`$V__hs7i-ozEkL~1IB0iq_E>$tX`e<1~e>vBj?}UYJowy7%my0+3!@ouN8`2qIus49(PHH6%
zd;z@RATfR@?r89#QQT?Lpu`Lfh-3ZtTQ&e8K0Yz6K@LeAF)hE<
zYJbvh+d=0%fH_6c783vp=Ns+uQ#dDug*toKO87cWhNqmn{13X<*3gCFUD~1KD-wnA
zu}J1Ob7~9>%=pT|TpH36uFgUbY*0he$rA{f#-;uV)3%y4WE>mr3ZIZ3cxBE(l5|pn
z428_{3}pDiE0e_3$K^qLNk2lPk;lnqep=4u$YTPc-A8}+VRJ+>S*`FlY79JEe>JOK
zB=?02a4?fM?OUKEB85^+tf4#TU7BwjUr4HL8@;4oV*8E$vT(H1{E1B_0~k42BbW2v
zlKy#gcYzQ1LD&KJgEfFd$=qEZD_2$n-60xuaY#7@B+?6-nPPH5DY{YbFl`b-#t7;?iT@!7EH~^j}4%iXsG|~mvqUbER_3G33O}+s@jMPEX5qW2H=9FK9!x9j;-EXdPV$4-aC^Y^|hs-8)v_C
zR^8#jIiJ@b3lNI<^+z;f?az~C`N)Vl7eeuU3;YqBOSRbn^dz>Lbc~L%pWLCM*k}~|
z5v@rye0D*$d5*8`uEx`kg<^-p(9+aJ;%!`FhIh%6>p#^+4*!kw-
z6?PWp3R{cK4P)}+!Oi>WoAj@g%K^*Y5rH2!H#~GLE2C+^m1m)*Injz)t=HUWOc^EE
zRCjEEak1WlSKEH8)7Z`RdDq?W#U%g-(U>m*C{@aew(RLdfk)`&&%AQrtn$XaCqi6q
zQML)dE2$f*EIMWZfqPv+C*UOD*m@IudBVf+v&^UpX-m1_1ps{(E$55}xoyi4#Of!&
zda?ijf=1uWn>^PBJvY#}bQb>B&I|9u6T(R#a#aYXlV+e^~~^gouN7CT{Cdt2-3Uf}~kv=tAD)KOD%K-yys!^@ofag0pMFL?^
z)q%cXGj5hf%&r~;XN
zZ0+Bl`t551n$udiKrYn_nHqyRLayvY-T9a2`wJS`FA$M}>%r4^QtzF3;a(q+!v9qK9kB6Eqc963Av_50UNCo4zH?1Q
z3K@0JCk=(IDFldLNRXQ)uUW5=VS-JCVANj)nlg1v-OT&db*wuvT#F>vP}E@4)Zs|&
zU*CWTU}%@a#Z>)^?JvoyegF+O2Ecj%O1IyeZBX6=#>L72SKcac*e#>NWlnxPr?FT`
zQf1+}lq$-&H$wq@NuB4KIxW93s`~?#KCgn;I{H)S-7RPq&{*@|W7Gv1rC$^Qmm3TK
zm%DCg7hewiY5w~xi0GZDF>(8IAchk<<~2B7dB3@|59Einm~aM)lsIO}R-3PXVn2sY
zVS?ncb+b*PmRO;a=Hn8mQq&qM2X4XIOqSO)9u-H%)l4#E%crQj>irPYOx+*Ps4zgw
zgunKWq;N4F5K00O+_*s=xvg*&+%lzv9^%v;`Y?@8o5ueK_TLIjhT@xch(F@!Oi>HKxZ>retv+T`Cp
z>U@3!YNmBh>Pq3aBopAe(ZLQ>>FIr#i%2c#ApT_r!+JedfQyayzzP+HS#H^t3oJk3
zw((M&wD|)7%x=b72%9L;RrXT*Gi@8|`>xI#=CRdToEMTAxZm;~K%P@F?|qibfCX{=
z{s2H%`@gFL=sfv6fGRldp|ku^ZXy9Gi`|;4dUTH(8+ysyUaWvd+5lYtR}hUAGsv$s
zSa$|%H7Py340J=4q1~^OQ%Bc?2via7n^iax)NT%+MQrKr&_-wunP);KtS?
z;Mug^UX+Kp5ufss7N;Y_sp>!%o;;EvP}gr*1KgGyfXz*C%n*nM-<^XmuRy%yt8u~tSrpqbg8_pr?*H?9ftWpl>Z86;F7jF;64Z>cU=XhlWn9W>Hu46I6`?@v`8zr4P0Q
zlX(}&*X-f3;Vy(Vip)bHIE5m0zo2I+h*R9k(UZ%+MO-pXZi5exwE#|FHlh@T&r_L&
zW0y9#RO;JYSej-7u=&Byx8xmvy@Fj%b=@l8-QGz3j-;9fs=qm2NPN$I%r|?0eB<}p
zk4NZ7Zvc8l#I`rC;21nAQ)jR{tokUp8yMT+`Bp&u0ka>O0Z7Ub`Mc|a)g-|3_}IuI
z00b-wL&lv-t^oZrTMyI!a#K4bsKN01K7t3N^j3i7gt15yq4&pPXR2y6nu2}$^=I|F
zWL?|0uRl+Jr7K|XyorfCZiAa$5q=#{o?aA!%o$rb+XQ~g@Q7qmw*SZj;`>@bCl3X&
za&FbsuB)dv=Y&grRlF^FJ4Ao{;7~KB^Nw$&wXTkGq?8sI`E3X-SRt%TkpQj{a&v0*
zj_i>I?=!nN;LWxxR<`)_{gk`f{r;9r&e#zRtnHG!)rTwyAeK7b7(5#OuwN~%sl9*=lUoiRP&W{Bao7q0bc>DYNlor4G=)IMpAl?L%2Z9e*LWP
zsZIRQ}!%FH0o#8sk|5>QBC4n@zM~U8VNqhVkA0!K40|9RWz&BcGk2hu^
z>+3G>2@h=-fa-7viaE#Gh?7lEq9+a97h4pHcadI>A{Ht=fT;T|pO!WS{2k^7XiIt&y+U
zMO#>*MI2r+%x^NUUuoY=(2T1S!`hcI1OAuBp7;Oc@^f?w_pRpA0*so+l(
zM?3fO6m4k$j!1c2Doqu4#
z+a>G?=(Mzd9^RO8!u^$bsv_=_8)jhUj026y{Uba)0UwLD9(tGEN+)K&2;~LO)#x+l
zg0VwX)fuogv9&o*_nS#jr>IZR#uBW8|LSjX7`Lpgj@}J{n1>DNJ=nrNNjt$5rp+L_
z#<^CU_Gluhrg9hi+F-=8gjt+16X|U42RtX+?B4jy3H5D37Dk%;43Jk_dfR;mqy9k~
zC5Hn3>tG=Oc;}%5w^2wkmgw-LdR`Dn{y@ij+;fC|rGr4HA)^qo1iM)6X`gvEFu5?V
zGH2$bGJoE;;_o}46|)&L-ryb56MU$FRm@9NvVx@*Bbd>}qVK+;rJVkn$;l#63A~3?
zYfjR%7woK3_63x;jKWkIq;c52nKOR}Q-1x|BT+zEQ6D_HgH^a|^zdKf)niCtcjD4E
zgZ`@s4^WX+9Pk_l|3}jQ3ibdBzVCNQZH9ZC3HT77jJKcbmF*aVtPAgi`r3JSf?0(_
zNe)N5{Y4?Fn1PsY2Odhy|(1DDg~lWr=|GBaa#xQmDJmR+8DkV`xGpd=W=Ztj^#i{@)m6N0?vO
z-mtT4npcjNe{WVQc;9?k0Nf^;b^7-MGC2GRVOuucD(s^&YH4`)cJo?%nF7p+NI3Nb
z`YB$YB*}p6g3&#|>=>X3P+@+Ap(i#gxbwK)SQeNp*k_oH(QUU1R+z$Em3v;x?_V#D
zhAT%F47Xv$a`*r-Q%idjM-b6G)_mrVTg=1Y+^G@#EGh|gCL+x^@yr=-2sn&5d}kb?
zriZ;O_l+}79CZhJFcWv!_Ex88Q{E%kR5|#C?lluWCL>kI)M@xgvh)=)+B{AUa+5=GlxfnNX2^lC(YBYGYZnh9*x
z_^)+-`3)#wN^`T-FTOvOfGnA!wg_GDDYox|DFJacCe+t`_i?-TqXai_UGd8LMHAvw
ztZpH!631!4WoAASd6`7RW{WOwLv&;eU%pIy8vYEPiInPm^dsZ&+dqB!m36G=Y@jk3
zPNlAm=fmaT|5MtRheO$hZ;zdu^37s|Dj+QMx=sXHy0xQ!KjOX5X6S&x-o_8td&E5&u9ZkF<
zz3$Haf3+nDWmoA
zWejHCwxnr$%)}dXibU#+o#-B4YgkclP`S}UQ0aVu9;Z+?{`v=rHLtCQ)b{wMqHiR(
z2IWl$1~<=Gqf?wQ&X`qyg_$IqHAi&dSBjwSIDq=ImX$+w6q-D-0;5z&(sg>@kl?{z{6N-tc(@YPWX9!1XCB3
zTbtC!KH{mJ;K3|zxSAjDC&?$T_!IXEzc#0c9zc)2IKc6-;UU>u`@xM2f=HToi#>i#
zqFvD3Aq6qa|KQz0=EB0BVxAv{*my?uWB#THIid*1*`PIDx2$HAPpPZ4lm9AeAcA7A
zph-LNl6k`HV@@FdgDV<(M*^edWIZ)BtB0@xQDVA6m=Huc%LLnCf_IQl-Nu>%tj78L
zCD*UivMoziWrw1;L}~>%D=E25^Lky|`s981k}(VPU0#6)kGG9%o~((Yr$y9UoQ8Up
z9htm&obq};2(pY#CiPj9Q}BN=iOAn3>N-NGe9AVywcm?Flc~^;1|kox+H?b()Bd>x
zZlm(j1EV{*VWv>#8b*5)E-M*IdW!C!5PS9)2qR{Td*9A;)MxKy^a%@<*ggrV1!E^p
zjQwNFJv?ILBi=_br~bgBPO&wtyT`F}H?VTaGLQN|
z?)>=d#AX?L?VZw`x@o&znL&J1V@c?t%_7e@v+wbI^V`S!Yx!)h*lTn1e`VL=nhNEZtyy!W
zjDBf+q>fu>GuiroiF+tB%vu>MC#`Yx9v^$K?pLcI4)+_FT8Yh$L1r6me?3KfE;=a*x|%Ha@SkU!nIls
z@$zYtuZ`PJ=Gm@Xy)1w(-n*gs!SIepyLsDTi;difZEEbi7)C{u_9-AvPNt3RPr7h%
zAdi#YM=`kx6=N55${AWYLa_`3KElLNPBm+
zR#kV$dbxlm%TXV5p-|3Qv$R-eim&-e{FVnty?f4Z*?qD*0-KI(?)-a5T60R$2c2nZFl<+TI&60hj_=?=!*a_Le?DYg$
ze%ce^a|*(OEEg`vQd6_{RLd5=TA*_D&FcJQ->1nwS6?3g(??(I^p^zE+nFT?xn0RR
zH`99^98>k|MGtmY<10k-D*`XSz3%tykSREb_
zzdONzhk*HB{bRqsSg&HVT~NY&(?nMn(`u(kL?_3Rd{iVOJH?%Igni^bp3>Jq7H^k5
zO37uACOmT~$DAb8hVEfC#+0heyVV87X+>V{N>{Y1+9ao%Z-nNIy!fW3zH{b*bUR;v
z?ag-%eco%b?ATJOF!iGk|0wP4qtl#E9aqQLVn-X^xYP}
zHikw&Ha;Sj|
zDN4y0%cVYZwIz5DnW0I~3$Bv|Hx+iHcl$R{v#sV6av2|70$>P#8
zQE_G+W4*M2+lMB_UN3qI#yz;k&H*9%gsJkbMpmLo3cT3q2A>Tb~~^T5P~
z&Y)@u>5altVdZ{Gl;ma+^|9P_l}G8{>nfx8%Kakkr;QwKmirFf+>qz5ITh2OCuDMG
z4cnZ{=B+CJHh7o+SE@jwiT}fSAHpB|WpRr5#=cQjyk*#-oYUTwQ3Y4DVkd4m?H6aC
z)cJb4`rIO_>?|$}ueM^qp|$0C24+dkBYDT2v+P$(rI@PJFEdOCiQ!G#}
zMxiW-@vi(xB=TE$xFr0GkvZb>fA=xwrabX=^9&dIeaz=gN^Tk9>D$Os9i3lN@CJD2
z#W<>B?9)869K>P@tNLZG(jE@pgL{xM`!iqaXC@DBsg3Nf>l~Ro$ZVQDcGO>--T@u?x_!_*eW(U@4mgLqf_*9R3%3E_L?Gj
zCVHk*X}kdZ8cKU8=ZpT+3Pk!YivY|jL``0rpSohNzfyApZ#=?
zD>6c%bk9J9JpI+FRNqz-8H0Ld6sMQ=>&QT+Ok9Lsj9HfcVbj~sJS-CQbuuH4z%QTg
zrYK1_9Y$H`K!<*Nee-%syfZ&iTAqH1zH^xWUbF$?;!XEH?N
zMtNwMG=0G63HC`k6LfSQ(VMCGHuk?}8bLGnTWS5*%xq{T_v0dC=QHo|KeT9hFX`=r
zJGZFsxSld(Nrnb)LIb4{Xg95|N**km9n^+BrRU*c?1O9UB2zC46dBJQb>v6ph{U_b
zR>>39!;Cqp(Wq{&39hP(6H&Vhc{4_hkTKzwZHMndrb;%sPkY#Psd{j$SsSaZ!~D|e
zmD)jH2O_3f87gDDsN6Za_IJnjfM=rlgl9y=Vd%5FJz!P|)R_wto_fcD#NZ7nq{STt
zH&vSi9mGF*xB?!fXqjGyd^a*Dj%vn
z;Jo)`jV@a#9S#Z9`1?yBLDs?EY2&g-$sRg013|Z=gc4??*ueETW0(G7Y0$&G$;`yV
zO**e6%l`#C%Ol5+Kb@O{$_L$h6hW_&1Bs#`y2N830mKthcA7U@gljfvY6!nxCpJ0}
z>BDwJ#BLF6Pu6j-17_A17C*Y7{OF*}Hw+vQ%Spxbpv6dD(bLM4mA&8Laf&J4j0djF
ziJvQ`>MQYOZapVvSKwxsp@w%lgr+k7LO>HlHzbK}A{bZ>gN5Ob1^~EkfXM0)9X^oJ5iIQ;E8vrSw5?Ln6n1eLvc@ICwk3Y~ZBf+SL)tE;O;s%4f@q!?)|;c{%$
z%4BEu;0oxd9*c>Am)5xzaSRj_3M*HaP=AEo=z0{Ao4?6aT8~3$YD=mb8b(2J!$l~X
z%#YTqjNq6+_v6uV5<3n`rE6_3wc?*Ye^VVoCkDJwF6;<_+GxZ*9@U5npK(TUpQXlQ
z`Jd3|E0&?oDDU&z=tRXYe!3bC3R2ZC%3>zyim=T;3wJ%v>SXr1z*XacxD*4ntH9T?
zW*Du&o*E89KNJl(0_^r*P(H6^LU%TX7q;kPotQ)C
zJ3d@KMKAJze1;6{7He0{#>U187+|O8`+a-t2nw$Jz+JHGUotc>pxcHuKF7}Vp1gJ-
z(LO*LDlzKL&dx?qss~;GLjgSaDD_nvu=v}7qA1Z|qp}d(NUyH1%|#Q&K5!#ru4cT{
zpNfZGI__%U0%g^6P>W;eg=%>DWLAnzb$}vxHHaZDUb)4Ro$9yWqrcec^P@eRlcu4M
z90ovF2L5vU(|4>aEVLVL#i>dpcrd_}ay#v4a0fUG4Yk`~Yi5*b6efsm|%|!cV_#a`_1+<
zhz|gLq_V2`5X!=Rw}O7EeBkQLpB@-@hJh`4BwDgU<}yq%#`)o$?NgIgAosgau{G9|
z2$Q+Pe*=_rS(%xc9nv&^WF$>hC4;C8_Mf_|wr(tSKvV>I>!6Uv6dQK*%5UA}@
zpD!svpp6Na%(2wiTJHSQLnzXEx?eE^j3gGeY@Wd+iuLb<0hD&9<%4kZxd?nI
zztsAz{c&q55in5>gZi8Zu1U7`bWIm7LeDNs#n>Vn>S`xyR?V*>o=<>`%(RhAH-4RT
zV4qeChKswGbX#AzSqs&`h0%BVagy{R-U0~4tX0JWQ#?vXA$lCUD9UM6q!_xrnOQRf
z71;}w8kbYti#VXhNatDvfedUD1{lRq4TbuwqZQXB4J4*xAVX8)`+bBSA;EC>a4H%&
zNts(9%Q`+eoCISv5_E!j2D8|yuE;nO)yT&uD%o-0;-q{)O}Pjq{R>IH{Z}6!7gD|B
z^1R=G-W8e7f~vk#IzTjgf8mC1$loT1qMhvxv`4=Joh^2$*d?Y679)?s9*k$2sDQ8U
zPX}3;%)l9tn*0N7F%Y)t1l7X4T%PF@zyU8t%~c-HNfFn(!)8Uic(XF`Y;92Sy|UZsiC#P5y>UsLttJR|^wcii1lB2+m`2r=y91>j6~OrFD7^)ZCqnd;hgmjscU;6e@5(;S
zQu@;aee9F1rsqKZliRM;(V42!metSu;OX^i^yE=O>8+n%Do7i^9jOK`(et!Wxb1Zy
z0XCML0)n3x)adW`fJRp#Bt$pbd>;@cJA8qIvI@_*BG50|d~&EduqyA7=W2-*#r
zz=}Rv+uEmb&N;t&)u58LwKj}J8&+CJo402fU$z@mI4$LC0&#?J@)|3h|KbAe?~gfIx-yhn-E!5DG1@1wvUkKX
zdCo6;1>raJ&`jR-F7U;RW0=4ff-|6ovGcgenUFTrQF;xykhIqQ0Zk-QA
z>E5IH`VuIMVOWjl{5(;;Z1KA#_423+JW=a5SVD2Yip6&jCb-??y->O#_StGAGN&3A
zw_UgBbiX@$q5GJRs~kk3P_ZoVW%#o-gERlPk8L{M-$>9sCm{rAW6$1`czTS#wNx?htmTv@Mkn
z$-v#JpH{IE%1M0)e38jC`^|f#*0&2S5fOUd|G$=2|4-|%|MAPv?*l!QOM5HDP$=Ip
z$Sp2WC?;s4G)76eUfPSX_U$)~NSLOrwjO#
zID&3sI^VBM>FV4}qBr*|C7J17*v23=j4cdEWiP{<>{+3t>)E~?LRNK@LJz1MRYSNi
z8%3?wvWD;~u$3aBSXmK!naVeM$o0@+TLWUfBISpU?&m3Hs3dJTYkb`SD(6l}#D1O7kf*fg>`G+4z8Awjorb62aC`+w7F;tG^_6LIH2{
z%x&~^d7&?iW)!Q&>KL3dZexcX%E
znx_P_{wc&3ZWZrT(xvwFqn0NEfo!Jl5#Z&;6!myY9cg1KRLVrAilK}yg|aHMLY67o
z8<8lBviKLr97aCq%VXGnUSPLRMDta+n*-}5#!%)2$mvH)-nt8k_uf?;-F%I^Jh(OF
z@|I@#(lj|hjH!m{0pEk)qJC@Lky7P>1d_uq8i}ESNh;YkTE>AGq4&`>6}t0q@`O6G
ze;xJw8GGlDvMD%el)O&TB~1vos};|ISQ=r*pt7%>Ds6!
zP&u#cDn>acwNcg)maoONaeLZpj}!g-AY;^mRILAvSb@mA*@K_F3{=X@jXhlp@}r*R
zk*ma1vm+#BJ*T{br{vV=Y>$J0*y8*Y1+Ep;;A
zLRM)(if3etQ|a~JHNhDqI4j0Q(N`IlrOR45oXeQ1QS(tbKLk$H(SQ-;4W;>#5B0jIAsb(Ef;*%8^Xi`7#!!(G&U$e18V<51l{
zXhilfNQYCiNaO!Q(zfeM_)ktMFCZK4M_gjHr*!>UFMYsZj5*sdamk)=n>CO}-d7Ns
zaK)(YsXWx(1%w$zBF|q>m~Vu>yX2L>o`yO)vC=NF;c{rE5RqA)6W1MXkGQ^+k{h7V
zP7+gns5pY6B2g2VEIo{`eW(v2BCL$G;&wNNka^mBN>p7I=VdZ>4&?@}syRjxs2-Tv
z_m{D|Ww@o74SSd*$elC|BBU=7dfoKq>2t-eo+OHJevcazV%j{lUMW5wI0AM)os|9y
zCGu#utC)KBj~$vgC60%(`Sureb*^87)AlFIE9|u#AQ~UQA*DZahgoub?3{4_?Mdj%
z!uavXi3#c6E?}O2LaI%FtURoqpV<0%*MZ|@8uQ{2U$dGd7LrG=bTBwaQ$cl;|};3oQRZj#oyWR@Qhab3$N
zIa3?+oh3<2NVV~|XMv5<)ZLL_^uVz!{VRv1^zzhDI9qz>W`
zL}J9qamU1`xmS5dJkX@0PAt=pB!lKIv(Yk`{PA*D1jEqQTmL{ZyOIwdM{n$z-`$px
zd_fU$f_eKICXlhg>UPM7n#VkgvHwCY>@Fs8@z*faFju_((Bvk2mCo0!O~f6>)y&0F
z(j2ZatTzES
zb+7f$^$bUh6eF({F?oD&>+O~0^Ex{3&e!|IPVslJ84V*~X}@Ew0P}qR6j3${f1@KuH4<%V)KGZ(u
zxh-F&??Xp%BElv0m!&#dRrZh4Ofi;W1P>=nHo}zg22&|=t5+)Jd{h^I_cx_2^@m%0
z$e5cQFC-br6aySfJa4iflL$4~gQdq)%O=HD&ReMM2%B9cnVR3ErOr|oXzq|NJ<>S#m@VcH1nB^uq*%
z$W<-NGCGMQe>?kzGBzYv=xu2^S)qgaw-2FsXk9+6vQZLN!KD|Z-
z4vdn(M4Cla{4?iu@p{Dpfdp0|E+E`U23`Cuf*qFPT@lnt_z%R256=oXu^*)Ve_xJk
zV{0XwR2TQ1DZ#E434gyRXPd{L*Ilct^C(DEjPvUju6A8f1`PvgQZAne1iBe%mv_TFO=f9J
zFQsEhvbWc!1sLCQ;>wPdXPU4WyA~P${0A8fN$#|YCiGp44^^f$(1u=}*>Y_#^?4bP
zC7g$b=N{x~DP6!hkH&`PlkNDCF$P_q81GwDb+DX|^XbD8xDU!aB7Be_bDwc@)U0D(
z^<#Ez#bNU=?E&7_
zfAunFyI;e&?*>$;pRU0>BU8|<%_{UwlY*;@3BY|!EXFGrD~;mlV0a7{{bJl5@xhiq
ztNCDkEkXZ0-4XwWGZW5)P`J{!uHgI+UMS!8BVi>`-k1!=I{v`N{<#6x1;2BNE$@~q
z>1*t}i`NYd4GHRjO0Wybb1b_n!WNEf*&cJ|&wRjjE1e&Ya;K4!4
z)CsuCmuRt8NDi3E;HC2waFEo}DEg)q|7flt0lN)*HPCaACD^^@V(+SCihEtfcv_0D
zgRah$1h&VT_tc0J*|Jn>vCYI*Uq5p1dvKbUTT!0}Tc+1_ZnWB+5LszyX{??5bRRLB
zM4E$>_qFPmsY8ZFqYb^g@ZP@2
zF%J^3Rx1JweXi0WxSH8<-T9>qz#%m%nB-1@=
zz}{sZwqf|()L-gh2#_Zb{*ip546$x>_a#sWGK_%F&nReJj$&IbIs|_PSE9Yc^aRpp
zh!+{No@>7q8-I8u#GeNH;b0~^3J?JR{{9#P@K6Z0^f_Cxlx;+)10Naw;W;p)0gCOl
zZ?O^p%YL~>fJBQ42N_uu3#Z_xG7zsRgm?g^5EpeEa9OxD=NUHua`!2FI|l85mCO-r
z3#ep%Yz=`!5nYYgUkN*75N><4rfX_m8$hA>T}&*uF3d@VOJU+4@Q5@5_}9GocgeQm
zwgmj@&!lTn`l_IwYi*!1^af0SpzAn5Ecryt3+@=UX?VhR3cxpyjuqHz$)Mk>C(rKr
zy4v-xe4>FfClQh+FTUPL4?d@_ufOSk^}GB0$VUZ$J3Q3sr#v4JL?U54+EyBMViboS
zGui@L2m2E}odXPVLBX{He=M(@k)7ef)wW{LK>>`hXIK+9#fW3fN^Z+{&;(k1Jvd3(
zfcFM?8L`9OJ8X`lb@!{l7i_`jA=kdx!Za{-3J0`R>Nz+&MV{qRIjkuHtGPq;DRHbb
zz9fIae)m^EMqA2;LpaaSm9Tw8Dd_#DY{spcJE!TJO96t!;0RkZ*Qa6(=nr`17C>Fi
zxwoFKWg_?={*Kbz_D6u74;HMNcHt=&KRnjy{z;V~#O7Ub@rIOx)!=9a-Oc#ztk2m8
zTpuYntGpmGq|ze;l`?GnmaQ)fqKAF(O81`-5N+F*y6>Yah$0R}MI=hGTBoXEP2L?U
z#aI|m4^^uH${aDL`Df%_)!IA>m^A8;T0f5(W
zy>sIr8^-|Dz7X>1!9E5a)X3*@g{oua+se3vCbCf@TVI$d@;hzGL{2
z-^84gr=+nCUKq}>DCvhsO)R@^gU6IJpy3N!YI9ZeErz60(aw##Y2`n84qm@a2io>4
zxR4?Aw8oigd;_?dn+%ZxjLC%AguM|kX;tWx4dggUwn5>38t%kqCE;72kf%3hh=_#}
z0^P_A_9Hn~y$vHkk0ksNWM<~B2?jcu8kTKVwawXSEXI+xS@b{w#&0EqDzMAPK`0tX
z(Y4iJ*;WPaV9RsE>3}H8`OVn0K#}3k(iDBW6bby6bBuyKRH7SN=DbfZ2t0T!xv
zT>5=37rP+6%24+!51Hv?mKJ>CD6{~k;az&k(k<-6;8u!oi8&Nmis*)Jx6M<#1Yi!1
ze>vdAJTXS|60Fojp99yw9ueElV0hn2`|V2p^;f|es2hp<=OO`%K|;DS87^s73e~N{k+804p(ZjCJA`48
z4A{^at++Gm?wt&nQr&;wj(Wfw&=XToWZgFFgtY}y+Im+q^N6pbZt|iNrqtOOE7=Ya
z(SP**-d%kxaQsZPIg(86N$%5xROBH&Ti(8ux=t53AkPb%k4+28+8epLO4AWz^}toi
zRK-n;Q*;Qv%?@Dw^KdePlFMSo>i+z;i(*>~wRZ4pKof46*GwSih3IR@aL;PReIoRI
zCVy3Un0IIG@u{Mg=A3@H0)~qW+1VdMe|bgXUv
z%W6_+%=l^w;~JvjhO#sFJSR3(F&);QNd5ByA0=9-7nyppRl0=BCDJ`oY%h+8$g>$a
zARZopT4ap2c@}*E?^8FJ)#WZguAqfjiuRvo`oq?yP%r%$S5FN#$)m^MZwd0ov7e|t
zh@R`pL8*k5rVE!brEdu8JcA~`ag()YyjY;JYvBUuunOioUlNz_v)}X4`8-_Tj)p0r}A3lVh<~9;vLcMh+e}>$0+k<6ghLMZGBx6xA#Tt=azCpY&3we~D
z1|+n*2z`ZQCj5C{>(0k^*4Kvv==0qVa^+H$SP4X+|W8>JaqP)
zKc%t%rgfR95a%7=HJ{ybkr8?xFOA}?2!vUKB!mW^i|u{GVJ1;#QQx&Y*xxWrcLS@p
zsGX8~(pzZW?IouZN0>EPkSy=$SKQ2Ce`l?aWeSo}y^<}>EDn~^r^PvyutOw5U)Mw@
JPuns4e*w4@!z};+


From 760e2a15bf04f888ee6c40f90d70ceac25c315c4 Mon Sep 17 00:00:00 2001
From: Pieter Wuille 
Date: Wed, 2 Mar 2016 19:19:42 +0100
Subject: [PATCH 240/259] Make the threshold independent from the deployment

---
 bip-0009.mediawiki | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/bip-0009.mediawiki b/bip-0009.mediawiki
index e6be63a1..6c65c8cb 100644
--- a/bip-0009.mediawiki
+++ b/bip-0009.mediawiki
@@ -25,7 +25,6 @@ In addition, BIP 34 made the integer comparison (nVersion >= 2) a consensus rule
 Each soft fork deployment is specified by the following per-chain parameters (further elaborated below):
 
 # The '''bit''' determines which bit in the nVersion field of the block is to be used to signal the soft fork lock-in and activation. It is chosen from the set {0,1,2,...,28}.
-# The '''threshold''' specifies how many blocks within a single retarget period (2016 blocks) must have the bit set before we lock in the deployment. The recommended value is 1916 (95%) for mainnet and 1512 (75%) for testnets.
 # The '''starttime''' specifies a minimum median time past of a block at which the bit gains its meaning.
 # The '''timeout''' specifies a time at which the deployment is considered failed. If the median time past of a block >= timeout and the soft fork has not yet locked in (including this block's bit state), the deployment is considered failed on all descendants of the block.
 
@@ -95,7 +94,9 @@ refers to the median nTime of the 11 blocks preceeding a given block (referred t
             return DEFINED;
 
 After a period in the STARTED state, if we're past the timeout, we switch to FAILED. If not, we tally the bits set,
-and transition to LOCKED_IN if we pass the threshold. The transaction to FAILED takes precendence, as otherwise there
+and transition to LOCKED_IN if a sufficient number of blocks in the past period set the deployment bit in their
+version numbers. The threshold is 1915 blocks (95% of 2016), or 1512 on testnet (75% of 2016).
+The transaction to FAILED takes precendence, as otherwise there
 could be two non-overlapping deployments on the same bit, where the first one transitions to LOCKED_IN and the other
 to STARTED, which would mean both would demand setting the bit. Note that a block's state never depends on its own
 nVersion; only on that of its ancestors.

From 63d626668c01c6aaa5baadf7f80341d6eed0b090 Mon Sep 17 00:00:00 2001
From: Pieter Wuille 
Date: Wed, 2 Mar 2016 19:42:41 +0100
Subject: [PATCH 241/259] Clarify things and make notation more consistent

---
 bip-0009.mediawiki | 29 +++++++++++++++--------------
 1 file changed, 15 insertions(+), 14 deletions(-)

diff --git a/bip-0009.mediawiki b/bip-0009.mediawiki
index 6c65c8cb..8a765590 100644
--- a/bip-0009.mediawiki
+++ b/bip-0009.mediawiki
@@ -74,7 +74,7 @@ floor(block1.height / 2016) = floor(block2.height / 2016), they are guaranteed t
 deployment.
 
         if ((block.height % 2016) != 0) {
-            return GetStateForBlock(GetParent(block));
+            return GetStateForBlock(block.parent);
         }
 
 Otherwise, the next state depends on the previous state:
@@ -82,27 +82,29 @@ Otherwise, the next state depends on the previous state:
         switch (GetStateForBlock(GetAncestorAtHeight(block, block.height - 2016))) {
 
 We remain in the initial state until either we pass the start time or the timeout. GetMedianTimePast in the code below
-refers to the median nTime of the 11 blocks preceeding a given block (referred to as MTP in the diagram above).
+refers to the median nTime of a block and its 10 predecessors. The expression GetMedianTimePast(block.parent) is
+referred to as MTP in the diagram above, and is treated as a monotonic clock defined by the chain.
 
         case DEFINED:
-            if (GetMedianTimePast(block) >= timeout) {
+            if (GetMedianTimePast(block.parent) >= timeout) {
                 return FAILED;
             }
-            if (GetMedianTimePast(block) >= starttime) {
+            if (GetMedianTimePast(block.parent) >= starttime) {
                 return STARTED;
             }
             return DEFINED;
 
 After a period in the STARTED state, if we're past the timeout, we switch to FAILED. If not, we tally the bits set,
 and transition to LOCKED_IN if a sufficient number of blocks in the past period set the deployment bit in their
-version numbers. The threshold is 1915 blocks (95% of 2016), or 1512 on testnet (75% of 2016).
-The transaction to FAILED takes precendence, as otherwise there
-could be two non-overlapping deployments on the same bit, where the first one transitions to LOCKED_IN and the other
-to STARTED, which would mean both would demand setting the bit. Note that a block's state never depends on its own
-nVersion; only on that of its ancestors.
+version numbers. The threshold is 1915 blocks (95% of 2016), or 1512 for testnet (75% of 2016).
+The transition to FAILED takes precendence, as otherwise an ambiguity can arise.
+There could be two non-overlapping deployments on the same bit, where the first one transitions to LOCKED_IN while the
+other one simultaneously transitions to STARTED, which would mean both would demand setting the bit.
+
+Note that a block's state never depends on its own nVersion; only on that of its ancestors.
 
         case STARTED: {
-            if (GetMedianTimePast(block) >= timeout) {
+            if (GetMedianTimePast(block.parent) >= timeout) {
                 return FAILED;
             }
             int count = 0;
@@ -133,14 +135,13 @@ And ACTIVE and FAILED are terminal states, which a deployment stays in once they
         }
     }
 
-'''Forks'''
+'''Implementation'''
 It should be noted that the states are maintained along block chain
 branches, but may need recomputation when a reorganization happens.
 
-'''Implementation'''
 Given that the state for a specific block/deployment combination is completely determined by its ancestry before the
 current retarget period (i.e. up to and including its ancestor with height block.height - 1 - (block.height % 2016)),
-it is possible to implement the mechanism above efficiently by caching the resulting state of every multiple-of-2016
+it is possible to implement the mechanism above efficiently and safely by caching the resulting state of every multiple-of-2016
 block, indexed by its parent.
 
 ====Warning mechanism====
@@ -152,7 +153,7 @@ To support upgrade warnings, an extra "unknown upgrade" is tracked, using the "i
 The mechanism described above is very generic, and variations are possible for future soft forks. Here are some ideas that can be taken into account.
 
 '''Modified thresholds'''
-The 95% threshold (based on in BIP 34) does not have to be maintained for eternity, but changes should take the effect on the warning system into account. In particular, having a lock-in threshold that is incompatible with the one used for the warning system may have long-term effects, as the warning system cannot rely on a permanently detectable condition anymore.
+The 1915 threshold (based on in BIP 34's 95%) does not have to be maintained for eternity, but changes should take the effect on the warning system into account. In particular, having a lock-in threshold that is incompatible with the one used for the warning system may have long-term effects, as the warning system cannot rely on a permanently detectable condition anymore.
 
 '''Conflicting soft forks'''
 At some point, two mutually exclusive soft forks may be proposed. The naive way to deal with this is to never create software that implements both, but that is making a bet that at least one side is guaranteed to lose. Better would be to encode "soft fork X cannot be locked-in" as consensus rule for the conflicting soft fork - allowing software that supports both, but can never trigger conflicting changes.

From cd6dfb94116224d552b3cc884b3454deeeaf0ad8 Mon Sep 17 00:00:00 2001
From: Pieter Wuille 
Date: Wed, 2 Mar 2016 19:48:34 +0100
Subject: [PATCH 242/259] Recommend a fallow pause explicitly

---
 bip-0009.mediawiki | 7 ++++---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/bip-0009.mediawiki b/bip-0009.mediawiki
index 8a765590..ef7a2ab0 100644
--- a/bip-0009.mediawiki
+++ b/bip-0009.mediawiki
@@ -30,9 +30,10 @@ Each soft fork deployment is specified by the following per-chain parameters (fu
 
 The starttime should be set to some date in the future, coordinates with software release date. This is to prevent
 triggers as a result of parties running pre-release software. The timeout should be set a reasonable time after the
-starttime. A later deployment using the same bit is possible as long as its starttime is after the previous one's
-timeout. This means that by setting it to 3 years after the starttime would allow around 9 deployments to be initiated
-every year.
+starttime. A later deployment using the same bit is possible as long as the first one its starttime is after the previous one's
+timeout or activation, though it is recommended to have a pause in between to detect buggy software.
+
+Setting the timeout to 3 years after the starttime allows at least 9 new deployments per year.
 
 ====States====
 

From a3df16e6504769498c51af88afd4cf2148896bd0 Mon Sep 17 00:00:00 2001
From: Pieter Wuille 
Date: Wed, 2 Mar 2016 19:59:18 +0100
Subject: [PATCH 243/259] Correct the claim that only 29 bits are available
 anyway

---
 bip-0009.mediawiki | 16 ++++++++++------
 1 file changed, 10 insertions(+), 6 deletions(-)

diff --git a/bip-0009.mediawiki b/bip-0009.mediawiki
index ef7a2ab0..7ef014d2 100644
--- a/bip-0009.mediawiki
+++ b/bip-0009.mediawiki
@@ -48,12 +48,16 @@ With each block and soft fork, we associate a deployment state. The possible sta
 ====Bit flags====
 
 Blocks in the STARTED state get an nVersion whose bit position bit is set to 1. The top 3 bits of such blocks must be
-001, so the range of actually possible nVersion values is [0x20000000...0x3FFFFFFF], inclusive. This leaves two future
-upgrades for different mechanisms (top bits 010 and 011), while complying to the constraints set by BIP 34 and others.
-Having more than 29 available bits for parallel soft forks does not add anything anyway, as the (nVersion >= 3)
-requirement already makes that impossible. When a block nVersion does not have top bits 001, it is treated as if all
-bits are 0 for the purposes of deployments in the context of this BIP. Miners should continue setting the bit in
-LOCKED_IN phase, so uptake is visible
+001, so the range of actually possible nVersion values is [0x20000000...0x3FFFFFFF], inclusive.
+
+Due to the constraints set by BIP 34, BIP 66 and BIP 65, we only have 0x7FFFFFFB possible nVersion values available.
+This restricts us to at most 30 independent deployments. By restricting the top 3 bits to 001 we get 29 out of those
+for the purposes of this proposal, and support two future upgrades for different mechanisms (top bits 010 and 011).
+When a block nVersion does not have top bits 001, it is treated as if all
+bits are 0 for the purposes of deployments.
+
+Miners should continue setting the bit in LOCKED_IN phase so uptake is visible, though this has no effect on
+consensus rules.
 
 ====New consensus rules====
 

From b3a93c42016ba8d29f6f3cbb0cd23068b4bf1505 Mon Sep 17 00:00:00 2001
From: MarcoFalke 
Date: Sun, 6 Mar 2016 18:18:23 +0100
Subject: [PATCH 244/259] Update bip-0133.mediawiki

---
 bip-0133.mediawiki | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/bip-0133.mediawiki b/bip-0133.mediawiki
index b5146e33..f78f3283 100644
--- a/bip-0133.mediawiki
+++ b/bip-0133.mediawiki
@@ -28,13 +28,13 @@ After receiving a feefilter message, a node can know before sending an inv that
 # Feature discovery is enabled by checking protocol version >= 70013
 
 ==Considerations==
-The propagation efficiency of transactions across the network should not be adversely affected by this change. In general, transactions which are not accepted to your mempool are not relayed and the funcionality implemented with this message is meant only to filter those transactions.  There could be a small number of edge cases where a node's mempool min fee is actually less than the filter value a peer is aware of and transactions with fee rates between these values will now be newly inhibited.
+The propagation efficiency of transactions across the network should not be adversely affected by this change. In general, transactions which are not accepted to a node's mempool are not relayed by this node and the functionality implemented with this message is meant only to filter those transactions. There could be a small number of edge cases where a node's mempool min fee is actually less than the filter value a peer is aware of and transactions with fee rates between these values will now be newly inhibited.
 
 Feefilter messages are not sent to whitelisted peers if the "-whitelistforcerelay" option is set. In that case, transactions are intended to be relayed even if they are not accepted to the mempool.
 
-There are privacy concerns with deanonymizing a node by the fact that it is broadcasting identifying information about its mempool min fee. To help ameliorate this concern, the implementaion quantizes the filter value broadcast with a small amount of randomness, in addition, the messages are broadcast to different peers at individually randomly distributed times.
+There are privacy concerns with deanonymizing a node by the fact that it is broadcasting identifying information about its mempool min fee. To help ameliorate this concern, the implementation quantizes the filter value broadcast with a small amount of randomness, in addition, the messages are broadcast to different peers at individually randomly distributed times.
 
-If a node is using prioritisetransaction to accept transactions whose actual fee rates might fall below the node's mempool min fee, it may want to consider setting "-nofeefilter" to make sure it is exposed to all possible txid's.
+If a node is using prioritisetransaction to accept transactions whose actual fee rates might fall below the node's mempool min fee, it may want to consider setting "-feefilter=0" to make sure it is exposed to all possible txid's.
 
 ==Backward compatibility==
 

From fa02af6e894a64e4c4abb9f4484aedc4b1f69904 Mon Sep 17 00:00:00 2001
From: MarcoFalke 
Date: Mon, 7 Mar 2016 09:33:34 +0100
Subject: [PATCH 245/259] bip 133: remove implementation detail

---
 bip-0133.mediawiki | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/bip-0133.mediawiki b/bip-0133.mediawiki
index f78f3283..7d98f87c 100644
--- a/bip-0133.mediawiki
+++ b/bip-0133.mediawiki
@@ -34,11 +34,11 @@ Feefilter messages are not sent to whitelisted peers if the "-whitelistforcerela
 
 There are privacy concerns with deanonymizing a node by the fact that it is broadcasting identifying information about its mempool min fee. To help ameliorate this concern, the implementation quantizes the filter value broadcast with a small amount of randomness, in addition, the messages are broadcast to different peers at individually randomly distributed times.
 
-If a node is using prioritisetransaction to accept transactions whose actual fee rates might fall below the node's mempool min fee, it may want to consider setting "-feefilter=0" to make sure it is exposed to all possible txid's.
+If a node is using prioritisetransaction to accept transactions whose actual fee rates might fall below the node's mempool min fee, it may want to consider disabling the fee filter to make sure it is exposed to all possible txid's.
 
 ==Backward compatibility==
 
-Older clients remain fully compatible and interoperable after this change.  The sending of feefilter messages can be disabled by unsetting the "-feefilter" option.
+Older clients remain fully compatible and interoperable after this change. Also, clients implementing this BIP can choose to not send any feefilter messages.
 
 ==Implementation==
 

From c6f8e3ae62dcf8fa9f464928f3d71d4cae4d6022 Mon Sep 17 00:00:00 2001
From: Jonathan Cross 
Date: Mon, 7 Mar 2016 16:51:59 +0100
Subject: [PATCH 246/259] Small typo in bip-0009.mediawiki

---
 bip-0009.mediawiki | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/bip-0009.mediawiki b/bip-0009.mediawiki
index 7ef014d2..49e6adf2 100644
--- a/bip-0009.mediawiki
+++ b/bip-0009.mediawiki
@@ -30,7 +30,7 @@ Each soft fork deployment is specified by the following per-chain parameters (fu
 
 The starttime should be set to some date in the future, coordinates with software release date. This is to prevent
 triggers as a result of parties running pre-release software. The timeout should be set a reasonable time after the
-starttime. A later deployment using the same bit is possible as long as the first one its starttime is after the previous one's
+starttime. A later deployment using the same bit is possible as long as the starttime is after the previous one's
 timeout or activation, though it is recommended to have a pause in between to detect buggy software.
 
 Setting the timeout to 3 years after the starttime allows at least 9 new deployments per year.

From 2bfa7bb7b7b377191e036d1e883a8f8b8c2d69ce Mon Sep 17 00:00:00 2001
From: Luke Dashjr 
Date: Tue, 8 Mar 2016 18:01:40 +0000
Subject: [PATCH 247/259] bip-0002: Complete license explanation

---
 bip-0002.mediawiki | 48 ++++++++++++++++++++++++++++++----------------
 1 file changed, 31 insertions(+), 17 deletions(-)

diff --git a/bip-0002.mediawiki b/bip-0002.mediawiki
index 0d94792b..8f81b4d4 100644
--- a/bip-0002.mediawiki
+++ b/bip-0002.mediawiki
@@ -139,40 +139,54 @@ New BIPs may be accepted with the following licenses. Each new BIP must identify
 
 For example, a preamble might include the following License header:
 
-    License: CC-0
-             MIT
+    License: BSD-2-Clause
+             GNU-All-Permissive
+
+In this case, the BIP text is fully licensed under both the OSI-approved BSD 2-clause license as well as the GNU All-Permissive License, and anyone may modify and redistribute the text provided they comply with the terms of *either* license. In other words, the license list is an "OR choice", not an "AND also" requirement.
 
 It is also possible to license source code differently from the BIP text. A optional License-Code header is placed after the License header. Again, each license must be referenced by their respective abbreviation given below.
 
 For example, a preamble specifying the optional License-Code header might look like:
 
-    License: CC-0
-             MIT
-    License-Code: GPL-2.0
+    License: BSD-2-Clause
+             GNU-All-Permissive
+    License-Code: GPL-2.0+
+
+In this case, the code in the BIP is not available under the BSD or All-Permissive licenses, but only under the terms of the GNU General Public License (GPL), version 2 or newer.
+If the code were to be available under *only* version 2 exactly, the "+" symbol should be removed from the license abbreviation.
+For a later version (eg, GPL 3.0), you would increase the version number (and retain or remove the "+" depending on intent).
+
+    License-Code: GPL-2.0   # This refers to GPL v2.0 *only*, no later license versions are acceptable.
+    License-Code: GPL-2.0+  # This refers to GPL v2.0 *or later*.
+    License-Code: GPL-3.0   # This refers to GPL v3.0 *only*, no later license versions are acceptable.
+    License-Code: GPL-3.0+  # This refers to GPL v3.0 *or later*.
+
+In the event that the text or code is not available under common license terms, the list should instead be replaced with the single term "Complex", and full details provided in the Copyright section of the BIP.
 
 ====Recommended licenses====
 
 * BSD-2-Clause: [https://opensource.org/licenses/BSD-2-Clause OSI-approved BSD 2-clause license]
 * BSD-3-Clause: [https://opensource.org/licenses/BSD-3-Clause OSI-approved BSD 3-clause license]
-* CC-0: [https://creativecommons.org/publicdomain/zero/1.0/ Creative Commons CC0 1.0 Universal]
-* GNU-ALL-PERMISSIVE: [http://www.gnu.org/prep/maintain/html_node/License-Notices-for-Other-Files.html GNU All-Permissive License]
+* CC0-1.0: [https://creativecommons.org/publicdomain/zero/1.0/ Creative Commons CC0 1.0 Universal]
+* GNU-All-Permissive: [http://www.gnu.org/prep/maintain/html_node/License-Notices-for-Other-Files.html GNU All-Permissive License]
 
 In addition, it is recommended that literal code included in the BIP be dual-licensed under the same license terms as the project it modifies. For example, literal code intended for Bitcoin Core would ideally be dual-licensed under the MIT license terms as well as one of the above with the rest of the BIP text.
 
 ====Not recommended, but acceptable licenses====
 
-* ALv2: [http://www.apache.org/licenses/LICENSE-2.0 Apache License, version 2.0]
-* BSL-1.0 [http://www.boost.org/LICENSE_1_0.txt Boost Software License, version 1.0]
-* CC-BY-4.0 [https://creativecommons.org/licenses/by/4.0/ Creative Commons Attribution 4.0 International]
-* CC-BY-SA-4.0 [https://creativecommons.org/licenses/by-sa/4.0/ Creative Commons Attribution-ShareAlike 4.0 International]
-* MIT [https://opensource.org/licenses/MIT Expat/MIT/X11 license]
-* AGPL-3.0 [http://www.gnu.org/licenses/agpl-3.0.en.html GNU Affero General Public License (AGPL), version 3 or newer]
-* FDL-1.3 [http://www.gnu.org/licenses/fdl-1.3.en.html GNU Free Documentation License]
-* GPL-2.0 [http://www.gnu.org/licenses/old-licenses/gpl-2.0.en.html GNU General Public License (GPL), version 2 or newer]
-* LGPL-2.1 [http://www.gnu.org/licenses/old-licenses/lgpl-2.1.en.html GNU Lesser General Public License (LGPL), version 2.1 or newer]
-* OPL-1.0 [http://opencontent.org/openpub/ Open Publication License, version 1.0]
+* Apache-2.0: [http://www.apache.org/licenses/LICENSE-2.0 Apache License, version 2.0]
+* BSL-1.0: [http://www.boost.org/LICENSE_1_0.txt Boost Software License, version 1.0]
+* CC-BY-4.0: [https://creativecommons.org/licenses/by/4.0/ Creative Commons Attribution 4.0 International]
+* CC-BY-SA-4.0: [https://creativecommons.org/licenses/by-sa/4.0/ Creative Commons Attribution-ShareAlike 4.0 International]
+* MIT: [https://opensource.org/licenses/MIT Expat/MIT/X11 license]
+* AGPL-3.0+: [http://www.gnu.org/licenses/agpl-3.0.en.html GNU Affero General Public License (AGPL), version 3 or newer]
+* FDL-1.3: [http://www.gnu.org/licenses/fdl-1.3.en.html GNU Free Documentation License, version 1.3]
+* GPL-2.0+: [http://www.gnu.org/licenses/old-licenses/gpl-2.0.en.html GNU General Public License (GPL), version 2 or newer]
+* LGPL-2.1+: [http://www.gnu.org/licenses/old-licenses/lgpl-2.1.en.html GNU Lesser General Public License (LGPL), version 2.1 or newer]
+* OPL: [http://opencontent.org/openpub/ Open Publication License, version 1.0]
 
 Additionally, PD is used to express that the work is placed in the public domain.
+This may not be used for new BIPs, and is only defined for use by BIPs predating acceptance of this BIP.
 
 ===Rationale===
 

From 54018e97fa691127327318e7e7212ed47f6156f2 Mon Sep 17 00:00:00 2001
From: Luke Dashjr 
Date: Tue, 8 Mar 2016 18:12:42 +0000
Subject: [PATCH 248/259] bip-0002: Rationale for prohibiting PD in new BIPs

---
 bip-0002.mediawiki | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/bip-0002.mediawiki b/bip-0002.mediawiki
index 8f81b4d4..4150b34f 100644
--- a/bip-0002.mediawiki
+++ b/bip-0002.mediawiki
@@ -201,6 +201,10 @@ Why are there software licenses included?
 * Some BIPs, especially consensus layer, may include literal code in the BIP itself which may not be available under the exact license terms of the BIP.
 * Despite this, not all software licenses would be acceptable for content included in BIPs.
 
+Why is Public Domain no longer acceptable for new BIPs?
+
+* In some jurisdictions, public domain is not recognised as a legitimate legal action, leaving the BIP simply copyrighted with no redistribution or modification allowed at all.
+
 ==See Also==
 
 * [[bip-0001.mediawiki|BIP 1: BIP Purpose and Guidelines]]

From bac34a1e8c4b252a9d3c8cbdffd5e6d409738713 Mon Sep 17 00:00:00 2001
From: Luke Dashjr 
Date: Tue, 8 Mar 2016 18:40:29 +0000
Subject: [PATCH 249/259] bip-0002: Clarify ordering of Comments-* headers

---
 bip-0002.mediawiki | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/bip-0002.mediawiki b/bip-0002.mediawiki
index 4150b34f..4e457a31 100644
--- a/bip-0002.mediawiki
+++ b/bip-0002.mediawiki
@@ -118,6 +118,8 @@ For example, the preamble to BIP 1 might be updated to include the line:
     Comments-URI: https://en.bitcoin.it/wiki/BIP_Comments:BIP_0001
                   https://some-other-wiki.org/BIP_1_Comments
 
+These fields must follow the "Discussions-To" header defined in BIP 1 (if that header is not present, it should follow the position where it would be present; generally this is immediately above the Status header).
+
 To avoid doubt: comments and status are unrelated metrics to judge a BIP, and neither should be directly influencing the other.
 
 ===Rationale===

From 0c87a9b7f1dcbbe94e9378f67331e176719f3628 Mon Sep 17 00:00:00 2001
From: Luke Dashjr 
Date: Wed, 9 Mar 2016 15:25:58 +0000
Subject: [PATCH 250/259] bip-0002: Fix typo

---
 bip-0002.mediawiki | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/bip-0002.mediawiki b/bip-0002.mediawiki
index 4e457a31..d9a0ede1 100644
--- a/bip-0002.mediawiki
+++ b/bip-0002.mediawiki
@@ -211,4 +211,4 @@ Why is Public Domain no longer acceptable for new BIPs?
 
 * [[bip-0001.mediawiki|BIP 1: BIP Purpose and Guidelines]]
 * [[bip-0123.mediawiki|BIP 123: BIP Classification]]
-* [https://tools.ietf.org/html/rfc7282 RBF 7282: On Consensus and Humming in the IETF]
+* [https://tools.ietf.org/html/rfc7282 RFC 7282: On Consensus and Humming in the IETF]

From 79679bee32d5b5cbd28ec39a14fd2b8061ca7f18 Mon Sep 17 00:00:00 2001
From: Dan Gershony 
Date: Thu, 10 Mar 2016 10:43:12 +0000
Subject: [PATCH 251/259] Crypzo has changed name to CoinVault

---
 bip-0044.mediawiki | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/bip-0044.mediawiki b/bip-0044.mediawiki
index 64358d8c..883677a6 100644
--- a/bip-0044.mediawiki
+++ b/bip-0044.mediawiki
@@ -267,7 +267,7 @@ is required and a pull request to the above file should be created.
 * [[https://play.google.com/store/apps/details?id=com.mycelium.wallet|Mycelium Bitcoin Wallet (Android)]] ([[https://github.com/mycelium-com/wallet|source]])
 * [[https://copay.io/|Copay]] ([[https://github.com/bitpay/copay|source]])
 * [[https://maza.club/encompass|Encompass]] ([[https://github.com/mazaclub/encompass|source]])
-* [[https://www.crypzo.com/|Crypzo]] 
+* [[https://www.coinvault.io/|CoinVault]] 
 ==Reference==
 
 * [[bip-0032.mediawiki|BIP32 - Hierarchical Deterministic Wallets]]

From d6e848dc4b07ae2c84796fee73b593b6f8120914 Mon Sep 17 00:00:00 2001
From: Luke Dashjr 
Date: Thu, 10 Mar 2016 16:44:21 +0000
Subject: [PATCH 252/259] bip-0002: Updates from Q&A with Mustafa Al-Bassam

---
 bip-0002.mediawiki | 11 ++++++++++-
 1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/bip-0002.mediawiki b/bip-0002.mediawiki
index d9a0ede1..a667026f 100644
--- a/bip-0002.mediawiki
+++ b/bip-0002.mediawiki
@@ -35,7 +35,7 @@ A process BIP may change status from Draft to Active when it achieves rough cons
 
 See [[bip-0123.mediawiki|BIP 123]] for definitions of the various BIP layers. Activation of this BIP implies activation of BIP 123.
 
-A soft-fork BIP strictly requires a clear miner majority expressed by blockchain voting (eg, using BIP 9). In addition, if the economy seems willing to make a "no confidence" hard-fork (such as a change in proof-of-work algorithm), the soft-fork does not become Final for as long as such a hard-fork has potentially-majority support, or at most three months. Soft-fork BIPs may also set additional requirements for their adoption. Because of the possibility of changes to miner dynamics, especially in light of delegated voting (mining pools), it is highly recommended that a supermajority vote around 95% be required by the BIP itself, unless rationale is given for a lower threshold.
+A soft-fork BIP strictly requires a clear miner majority expressed by blockchain voting (eg, using BIP 9). In addition, if the economy seems willing to make a "no confidence" hard-fork (such as a change in proof-of-work algorithm), the soft-fork does not become Final for as long as such a hard-fork might have majority support, or at most three months. Soft-fork BIPs may also set additional requirements for their adoption. Because of the possibility of changes to miner dynamics, especially in light of delegated voting (mining pools), it is highly recommended that a supermajority vote around 95% be required by the BIP itself, unless rationale is given for a lower threshold.
 
 A hard-fork BIP requires adoption from the entire Bitcoin economy, particularly including those selling desirable goods and services in exchange for bitcoin payments, as well as Bitcoin holders who wish to spend or would spend their bitcoins (including selling for other currencies) differently in the event of such a hard-fork. Adoption must be expressed by de facto usage of the hard-fork in practice (ie, not merely expressing public support, although that is a good step to establish agreement before adoption of the BIP). This economic adoption cannot be established merely by a super-majority, except by literally forcing the minority to accept the hard-fork (whether this is viable or not is outside the scope of this document).
 
@@ -68,6 +68,15 @@ But they're doing something important and have invested a lot in Bitcoin! Should
 
 * This BIP does not aim to address what "should" be the basis of decisions. Such a statement, no matter how perfect in its justification, would be futile without some way to force others to use it. The BIP process does not aim to be a kind of forceful "governance" of Bitcoin, merely to provide a collaborative repository for proposing and providing information on standards, which people may voluntarily adopt or not. It can only hope to achieve accuracy in regard to the "Status" field by striving to reflect the reality of *how things actually are*, rather than *how they should be*.
 
+What if a single merchant wishes to block a hard-fork?
+
+* This BIP addresses only the progression of the BIP Status field, not the deployment of the hard-fork (or any other change) itself.
+* Regardless, one shop cannot operate in a vacuum: if they are indeed alone, they will soon find themselves no longer selling in exchange for bitcoin payments, as nobody else would exist willing to use the previous blockchain to pay them. If they are no longer selling, they cease to meet the criteria herein which enables their veto.
+
+How about a small number of merchants (maybe only two) who sell products to each other?
+
+* In this scenario, it would seem the previous Bitcoin is alive any working, and that the hard-fork has failed. How to resolve such a split is outside the scope of this BIP.
+
 How can economic agreement veto a soft-fork?
 
 * The group of miners is determined by the consensus rules for the dynamic-membership multi-party signature (for Bitcoin, the proof-of-work algorithm), which can be modified with a hard-fork. Thus, if the same conditions required to modify this group are met in opposition to a soft-fork, the miner majority supporting the soft-fork is effectively void because the economy can decide to replace them with another group of would-be miners who do not support the soft-fork.

From 314e87f9c0c1e3920d2954a2ae3fb70473c887a2 Mon Sep 17 00:00:00 2001
From: Chris Priest 
Date: Mon, 14 Mar 2016 15:16:51 -0700
Subject: [PATCH 253/259] added paragraph about address reuse

---
 bip-0131.mediawiki | 22 ++++++++++++++++++++++
 1 file changed, 22 insertions(+)

diff --git a/bip-0131.mediawiki b/bip-0131.mediawiki
index c30ef54c..3b1661cc 100644
--- a/bip-0131.mediawiki
+++ b/bip-0131.mediawiki
@@ -77,6 +77,28 @@ the user when their wallet contains many UTXOs that qualify it to benefit from
 a coalescing transaction. Wallets should not simply replace non-coalescing transactions
 with coalescing transactions in all instances.
 
+== Isn't this BIP bad because it encourage address re-use? ==
+
+Address re-use comes in two forms: reuse from the ''sender'', and re-use from the ''receiver''.
+
+Re-use by the sender is basically using the same address for the change output. This is generally considered bad
+since people looking through your transaction history can determine who you do business with. When
+you generate a new address for every change, your privacy is conserved as it is impossible to know which
+output is a recipient, and which output is the change output. This BIP has '''no effect''' on re-use
+by the sender.
+
+On the other hand, address re-use by the ''receiver'' occurs under completely different circumstances.
+When you publish an address and have multiple people send to that address, you are engaging in address re-use
+from th receiver. This activity has historically been considered bad because it leads to re-using a private key.
+When you re-use a private key too many times, you run the risk of somebody performing statistical analysis
+on the multiple signatures, which can lead to an attacker finding out your private key.
+
+This BIP introduces a way to spend multiple inputs without re-using the private key. In a sense, this BIP
+fixes the problem that makes address re-use bad for the receiver. After this BIP becomes implemented
+and deployed, address re-use by the receiver will no longer be considered bad form.
+
+
+
 ==Copyright==
 
 This document is placed in the public domain.

From 46a91a8dc4936af3b3d8f3de7f36487e6aff2631 Mon Sep 17 00:00:00 2001
From: Chris Priest 
Date: Mon, 14 Mar 2016 15:51:14 -0700
Subject: [PATCH 254/259] fixed typos and wording

---
 bip-0131.mediawiki | 10 ++++------
 1 file changed, 4 insertions(+), 6 deletions(-)

diff --git a/bip-0131.mediawiki b/bip-0131.mediawiki
index 3b1661cc..1efe7133 100644
--- a/bip-0131.mediawiki
+++ b/bip-0131.mediawiki
@@ -79,7 +79,7 @@ with coalescing transactions in all instances.
 
 == Isn't this BIP bad because it encourage address re-use? ==
 
-Address re-use comes in two forms: reuse from the ''sender'', and re-use from the ''receiver''.
+Address re-use comes in two forms: re-use by the ''sender'', and re-use by the ''receiver''.
 
 Re-use by the sender is basically using the same address for the change output. This is generally considered bad
 since people looking through your transaction history can determine who you do business with. When
@@ -89,16 +89,14 @@ by the sender.
 
 On the other hand, address re-use by the ''receiver'' occurs under completely different circumstances.
 When you publish an address and have multiple people send to that address, you are engaging in address re-use
-from th receiver. This activity has historically been considered bad because it leads to re-using a private key.
-When you re-use a private key too many times, you run the risk of somebody performing statistical analysis
+from the receiver. This activity has historically been considered bad because it leads to re-using a private key.
+When you re-use a private key too many times, you run the risk of an attacker performing statistical analysis
 on the multiple signatures, which can lead to an attacker finding out your private key.
 
-This BIP introduces a way to spend multiple inputs without re-using the private key. In a sense, this BIP
+This BIP introduces a way to spend multiple inputs ''without'' re-using the private key. In a sense, this BIP
 fixes the problem that makes address re-use bad for the receiver. After this BIP becomes implemented
 and deployed, address re-use by the receiver will no longer be considered bad form.
 
-
-
 ==Copyright==
 
 This document is placed in the public domain.

From 7314d13a08a72ded7d6cdaa32d1b4b88d8b76832 Mon Sep 17 00:00:00 2001
From: Rusty Russell 
Date: Thu, 10 Mar 2016 13:27:09 +1030
Subject: [PATCH 255/259] bip9: fix heading levels.

It goes from level 2 (specification) to 4; those headings should be level 3.

Signed-off-by: Rusty Russell 
---
 bip-0009.mediawiki | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/bip-0009.mediawiki b/bip-0009.mediawiki
index 49e6adf2..6848c45e 100644
--- a/bip-0009.mediawiki
+++ b/bip-0009.mediawiki
@@ -35,7 +35,7 @@ timeout or activation, though it is recommended to have a pause in between to de
 
 Setting the timeout to 3 years after the starttime allows at least 9 new deployments per year.
 
-====States====
+===States===
 
 With each block and soft fork, we associate a deployment state. The possible states are:
 
@@ -45,7 +45,7 @@ With each block and soft fork, we associate a deployment state. The possible sta
 # '''ACTIVE''' for all blocks after the LOCKED_IN retarget period.
 # '''FAILED''' for one retarget period past the timeout time, if LOCKED_IN was not reached.
 
-====Bit flags====
+===Bit flags===
 
 Blocks in the STARTED state get an nVersion whose bit position bit is set to 1. The top 3 bits of such blocks must be
 001, so the range of actually possible nVersion values is [0x20000000...0x3FFFFFFF], inclusive.
@@ -59,11 +59,11 @@ bits are 0 for the purposes of deployments.
 Miners should continue setting the bit in LOCKED_IN phase so uptake is visible, though this has no effect on
 consensus rules.
 
-====New consensus rules====
+===New consensus rules===
 
 The new consensus rules for each soft fork are enforced for each block that has ACTIVE state.
 
-====State transitions====
+===State transitions===
 
 
 
@@ -149,7 +149,7 @@ current retarget period (i.e. up to and including its ancestor with height block
 it is possible to implement the mechanism above efficiently and safely by caching the resulting state of every multiple-of-2016
 block, indexed by its parent.
 
-====Warning mechanism====
+===Warning mechanism===
 
 To support upgrade warnings, an extra "unknown upgrade" is tracked, using the "implicit bit" mask = (block.nVersion & ~expectedVersion) != 0. Mask will be non-zero whenever an unexpected bit is set in nVersion.  Whenever LOCKED_IN for the unknown upgrade is detected, the software should warn loudly about the upcoming soft fork. It should warn even more loudly after the next retarget period (when the unknown upgrade is in the ACTIVE state).
 

From 4c4009bfdb94d10d94908a144d768399cf40ea6f Mon Sep 17 00:00:00 2001
From: Rusty Russell 
Date: Thu, 10 Mar 2016 13:18:03 +1030
Subject: [PATCH 256/259] BIP9: More explicit recommendations on values.

Basically the same thing reworded as a checklist, with 3 years turned into 1,
and suggesting a 1 month delay after expected deployment date.

Signed-off-by: Rusty Russell 
---
 bip-0009.mediawiki | 14 +++++++++-----
 1 file changed, 9 insertions(+), 5 deletions(-)

diff --git a/bip-0009.mediawiki b/bip-0009.mediawiki
index 6848c45e..83ce7d00 100644
--- a/bip-0009.mediawiki
+++ b/bip-0009.mediawiki
@@ -28,12 +28,16 @@ Each soft fork deployment is specified by the following per-chain parameters (fu
 # The '''starttime''' specifies a minimum median time past of a block at which the bit gains its meaning.
 # The '''timeout''' specifies a time at which the deployment is considered failed. If the median time past of a block >= timeout and the soft fork has not yet locked in (including this block's bit state), the deployment is considered failed on all descendants of the block.
 
-The starttime should be set to some date in the future, coordinates with software release date. This is to prevent
-triggers as a result of parties running pre-release software. The timeout should be set a reasonable time after the
-starttime. A later deployment using the same bit is possible as long as the starttime is after the previous one's
-timeout or activation, though it is recommended to have a pause in between to detect buggy software.
+===Selection guidelines===
 
-Setting the timeout to 3 years after the starttime allows at least 9 new deployments per year.
+The following guidelines are suggested for selecting these parameters for a soft fork:
+
+# '''bit''' should be selected such that no two concurrent softforks use the same bit.
+# '''starttime''' should be set to some date in the future, approximately one month software release date including the soft fork.  This allows for some release delays, while preventing triggers as a result of parties running pre-release software.
+# '''timeout''' should be 1 year (31536000 seconds) after starttime.
+
+A later deployment using the same bit is possible as long as the starttime is after the previous one's
+timeout or activation, though it is recommended to have a pause in between to detect buggy software.
 
 ===States===
 

From bce835d2ce0172bffa2858eaba21a6c6c3723110 Mon Sep 17 00:00:00 2001
From: Pieter Wuille 
Date: Tue, 15 Mar 2016 16:29:24 +0100
Subject: [PATCH 257/259] Small improvements to BIP0009

---
 bip-0009.mediawiki | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/bip-0009.mediawiki b/bip-0009.mediawiki
index 83ce7d00..509a8a94 100644
--- a/bip-0009.mediawiki
+++ b/bip-0009.mediawiki
@@ -33,11 +33,11 @@ Each soft fork deployment is specified by the following per-chain parameters (fu
 The following guidelines are suggested for selecting these parameters for a soft fork:
 
 # '''bit''' should be selected such that no two concurrent softforks use the same bit.
-# '''starttime''' should be set to some date in the future, approximately one month software release date including the soft fork.  This allows for some release delays, while preventing triggers as a result of parties running pre-release software.
+# '''starttime''' should be set to some date in the future, approximately one month after a software release date including the soft fork.  This allows for some release delays, while preventing triggers as a result of parties running pre-release software.
 # '''timeout''' should be 1 year (31536000 seconds) after starttime.
 
 A later deployment using the same bit is possible as long as the starttime is after the previous one's
-timeout or activation, though it is recommended to have a pause in between to detect buggy software.
+timeout or activation, but it is discouraged until necessary, and even then recommended to have a pause in between to detect buggy software.
 
 ===States===
 

From 159cc9bd0eb1bdf97facac7f839069c81a4cc301 Mon Sep 17 00:00:00 2001
From: Johnson Lau 
Date: Wed, 16 Mar 2016 23:20:58 +0800
Subject: [PATCH 258/259] BIP142: Deferred

BIP142 will not be deployed with BIP141 at the same time. Initially, people are expected to use P2SH segwit, or payment protocol for native segwit
---
 bip-0142.mediawiki | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/bip-0142.mediawiki b/bip-0142.mediawiki
index ff831cbe..bb602653 100644
--- a/bip-0142.mediawiki
+++ b/bip-0142.mediawiki
@@ -2,7 +2,7 @@
   BIP: 142
   Title: Address Format for Segregated Witness
   Author: Johnson Lau 
-  Status: Draft
+  Status: Deferred
   Type: Standards Track
   Created: 2015-12-24
 


From 3f586626d5b4b8eaf075c95dfeba51494dbb021b Mon Sep 17 00:00:00 2001
From: Johnson Lau 
Date: Thu, 17 Mar 2016 02:15:55 +0800
Subject: [PATCH 259/259] BIP142: Deferred

---
 README.mediawiki | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/README.mediawiki b/README.mediawiki
index 02a5a767..a5eb68f6 100644
--- a/README.mediawiki
+++ b/README.mediawiki
@@ -474,7 +474,7 @@ Those proposing changes should consider that ultimately consent may rest with th
 | Address Format for Segregated Witness
 | Johnson Lau
 | Standard
-| Draft
+| Deferred
 |-
 | [[bip-0143.mediawiki|143]]
 | Transaction Signature Verification for Version 0 Witness Program