From b1e7db53760d8b4c4a976876f99f7fac1bebf4e9 Mon Sep 17 00:00:00 2001 From: Daniel Weigl Date: Tue, 14 Jun 2016 14:49:09 +0200 Subject: [PATCH 01/68] new bip proposal "Derivation scheme for P2WPKH-nested-in-P2SH based accounts" --- bip-p2sh-accounts.mediawiki | 95 +++++++++++++++++++++++++++++++++++++ 1 file changed, 95 insertions(+) create mode 100644 bip-p2sh-accounts.mediawiki diff --git a/bip-p2sh-accounts.mediawiki b/bip-p2sh-accounts.mediawiki new file mode 100644 index 00000000..f7453c2c --- /dev/null +++ b/bip-p2sh-accounts.mediawiki @@ -0,0 +1,95 @@ +
+  BIP: 
+  Title: Derivation scheme for P2WPKH-nested-in-P2SH based accounts
+  Author: Daniel Weigl 
+  Status: Draft
+  Type: Informational
+  Created: 2016-05-19
+
+ +==Abstract== + +This BIP defines the derivation scheme for HD wallets using the P2WPKH-nested-in-P2SH ([[bip-0141.mediawiki|BIP 141]]) serialization format for segregated witness transactions. + +==Motivation== + +With the usage of P2WPKH-nested-in-P2SH ([[bip-0141.mediawiki#p2wpkh-nested-in-bip16-p2sh|BIP 141]]) transactions it is necessary to have a common derivation scheme. +It allows the user to use different HD wallets with the same masterseed and/or a single account seamlessly. + +Thus the user needs to create a dedicated segregate witness accounts, which ensures that only wallets compatible with this BIP +will detect the account and handle them appropriately. + +===Considerations=== +Two generally different approaches are possible for current BIP44 capable wallets: + + 1) Allow the user to use the same account(s) that they already uses, but add segregated witness encoded addresses to it + 1.1) Use the same public keys as defined in BIP44, but in addition to the normal P2PKH address also derive the P2SH address from it. + 1.2) Use the same account root, but branch off and derive different external and internal chain roots to derive dedicated public keys for the segregated witness addresses. + + 2) Create dedicated accounts only used for segregated witness addresses. + +The solutions from point 1 have a common disadvantage: if a user imports/recovers a BIP-compatible wallet masterseed into/in a non-BIP-compatible wallet, the account might show up but also it might miss some UTXOs. +Thus this BIP uses solution 2, which fails in a more visible way. Either the account shows up or not at all. The user does not have to check his balance after using the same seed in different wallets. + + +==Specifications== + +This BIP defines the two needed steps to derive multiple deterministic addresses based on a [[bip-0032.mediawiki|BIP 32]] +root account. + +===Public key derivation=== + +To derive a public key from the root account, this BIP uses the same account-structure as defined in +[[bip-0044.mediawiki|BIP 44]], but only uses a different purpose value to indicate the different transaction +serialization method. + +
+m / purpose' / coin_type' / account' / change / address_index
+
+ +For the `purpose`-path level it uses '. The rest of the levels are used as defined in BIP44 + + +===Address derivation=== + +To derive the P2SH address from the above calculated public key, we use the encapsulation defined in [[bip-0141.mediawiki#p2wpkh-nested-in-bip16-p2sh|BIP 141]]: + + witness: + scriptSig: <0 <20-byte-key-hash>> + (0x160014{20-byte-key-hash}) + scriptPubKey: HASH160 <20-byte-script-hash> EQUAL + (0xA914{20-byte-script-hash}87) + + +==Test vectors== + +(tbd. when we have the actual bip number) +
+  masterseedWords = abandon abandon abandon abandon abandon abandon abandon abandon abandon abandon abandon about
+  masterseed = 
+
+  // Account 0, root = m/'/0'/0'
+  account0Xpriv = 
+
+  // Account 0, first receiving private key = m/'/0'/0'/0/0
+  account0recvPrivateKey = 
+  account0recvPublickKey = 
+
+  // Address derivation
+  keyhash = HASH160(account0recvPublickKey) = 
+  scriptSig = <0 > = 
+  addressBytes = HASH160(scriptSig) = 
+
+  // addressBytes base58check encoded for testnet
+  address = base58check(prefix | addressBytes) = 1xyz....
+
+ +... + +==Reference== + +* [[bip-0016.mediawiki|BIP16 - Pay to Script Hash]] +* [[bip-0032.mediawiki|BIP32 - Hierarchical Deterministic Wallets]] +* [[bip-0043.mediawiki|BIP43 - Purpose Field for Deterministic Wallets]] +* [[bip-0043.mediawiki|BIP44 - Multi-Account Hierarchy for Deterministic Wallets]] +* [[bip-0141.mediawiki|BIP141 - Segregated Witness (Consensus layer)]] \ No newline at end of file From babd604cc4fc040ec22d58f120569556afeac3ce Mon Sep 17 00:00:00 2001 From: Daniel Weigl Date: Tue, 14 Jun 2016 14:54:41 +0200 Subject: [PATCH 02/68] minor cleanups --- bip-p2sh-accounts.mediawiki | 21 +++++++++++---------- 1 file changed, 11 insertions(+), 10 deletions(-) diff --git a/bip-p2sh-accounts.mediawiki b/bip-p2sh-accounts.mediawiki index f7453c2c..cf030039 100644 --- a/bip-p2sh-accounts.mediawiki +++ b/bip-p2sh-accounts.mediawiki @@ -22,20 +22,22 @@ will detect the account and handle them appropriately. ===Considerations=== Two generally different approaches are possible for current BIP44 capable wallets: - 1) Allow the user to use the same account(s) that they already uses, but add segregated witness encoded addresses to it - 1.1) Use the same public keys as defined in BIP44, but in addition to the normal P2PKH address also derive the P2SH address from it. - 1.2) Use the same account root, but branch off and derive different external and internal chain roots to derive dedicated public keys for the segregated witness addresses. +1) Allow the user to use the same account(s) that they already uses, but add segregated witness encoded addresses to it - 2) Create dedicated accounts only used for segregated witness addresses. +1.1) Use the same public keys as defined in BIP44, but in addition to the normal P2PKH address also derive the P2SH address from it. -The solutions from point 1 have a common disadvantage: if a user imports/recovers a BIP-compatible wallet masterseed into/in a non-BIP-compatible wallet, the account might show up but also it might miss some UTXOs. -Thus this BIP uses solution 2, which fails in a more visible way. Either the account shows up or not at all. The user does not have to check his balance after using the same seed in different wallets. +1.2) Use the same account root, but branch off and derive different external and internal chain roots to derive dedicated public keys for the segregated witness addresses. + +2) Create dedicated accounts only used for segregated witness addresses. + +The solutions from point 1 have a common disadvantage: if a user imports/recovers a BIP-compatible wallet masterseed into/in a non-BIP{ThisBipNumber}-compatible wallet, the account might show up but also it might miss some UTXOs. + +Therefore this BIP uses solution 2, which fails in a more visible way. Either the account shows up or not at all. The user does not have to check his balance after using the same seed in different wallets. ==Specifications== -This BIP defines the two needed steps to derive multiple deterministic addresses based on a [[bip-0032.mediawiki|BIP 32]] -root account. +This BIP defines the two needed steps to derive multiple deterministic addresses based on a [[bip-0032.mediawiki|BIP 32]] root account. ===Public key derivation=== @@ -47,7 +49,7 @@ serialization method. m / purpose' / coin_type' / account' / change / address_index -For the `purpose`-path level it uses '. The rest of the levels are used as defined in BIP44 +For the `purpose`-path level it uses {ThisBipNumber}'. The rest of the levels are used as defined in BIP44 ===Address derivation=== @@ -84,7 +86,6 @@ To derive the P2SH address from the above calculated public key, we use the enca address = base58check(prefix | addressBytes) = 1xyz.... -... ==Reference== From 1402ca99cba8c7b370248e5b7e09603d80c5c491 Mon Sep 17 00:00:00 2001 From: Johnson Lau Date: Wed, 27 Jul 2016 17:11:09 +0800 Subject: [PATCH 03/68] BIP112: fix example --- bip-0112.mediawiki | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/bip-0112.mediawiki b/bip-0112.mediawiki index 0397332a..40378ee7 100644 --- a/bip-0112.mediawiki +++ b/bip-0112.mediawiki @@ -59,10 +59,10 @@ established in the following way. Alice, Bob and Escrow create a 2-of-3 address with the following redeemscript. IF - 2 3 CHECKMULTISIGVERIFY + 2 3 CHECKMULTISIG ELSE "30d" CHECKSEQUENCEVERIFY DROP - CHECKSIGVERIFY + CHECKSIG ENDIF At any time funds can be spent using signatures from any two of Alice, From f64f3c3d9c9b6d36a90b270d7b971cec071ec10a Mon Sep 17 00:00:00 2001 From: Justus Ranvier Date: Mon, 11 Jul 2016 14:01:08 -0500 Subject: [PATCH 04/68] BIP126: Clarify interaction with BIP69 --- bip-0126.mediawiki | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/bip-0126.mediawiki b/bip-0126.mediawiki index eed0c3ea..43722d0d 100644 --- a/bip-0126.mediawiki +++ b/bip-0126.mediawiki @@ -37,6 +37,10 @@ In order to achieve these goals, this specification proposes a set of best pract In order to achieve this, two forms of HIT are proposed: Standard form and alternate form. +==Interaction with Other Procedures== + +Applications which wish to comply both with this procedure and BIP69 should apply this procedure prior to applying BIP69. + ==Standard form heterogenous input script transaction== ===Rules=== @@ -96,3 +100,7 @@ An HIT formed via the preceding procedure will adhere to the following condition ==Non-compliant heterogenous input script transactions== If a user wishes to create an output that is larger than half the total size of their spendable outputs, or if their inputs are not distributed in a manner in which the alternate form procedure can be completed, then the user can not create a transaction which is compliant with this procedure. + +==Reference== + +* [[bip-0069.mediawiki|BIP69 - Lexicographical Indexing of Transaction Inputs and Outputs]] From 89a9829ec4703f7d7d69db60d6cd99e66eb2a3de Mon Sep 17 00:00:00 2001 From: Johnson Lau Date: Fri, 2 Sep 2016 12:28:34 +0800 Subject: [PATCH 05/68] Add NULLDUMMY softfork BIP --- bip-nulldummy.mediawiki | 55 +++++++++++++++++++++++++++++++++++++++++ 1 file changed, 55 insertions(+) create mode 100644 bip-nulldummy.mediawiki diff --git a/bip-nulldummy.mediawiki b/bip-nulldummy.mediawiki new file mode 100644 index 00000000..802fb21d --- /dev/null +++ b/bip-nulldummy.mediawiki @@ -0,0 +1,55 @@ +
+  BIP: ?
+  Title: Dealing with dummy stack element malleability
+  Author: Johnson Lau 
+  Status: Draft
+  Type: Standards Track
+  Created: 2016-09-02
+
+ +==Abstract== + +This document specifies proposed changes to the Bitcoin transaction validity rules to fix the malleability of extra stack element for OP_CHECKMULTISIG and OP_CHECKMULTISIGVERIFY. + + +==Motivation== + +Signature malleability refers to the ability of any relay node on the network to transform the signature in transactions, with no access to the relevant private keys required. For non-segregated witness transactions, signature malleability will change the txid and invalidate any unconfirmed child transactions. Although the txid of segregated witness ([https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki BIP141]) transactions is not third party malleable, this malleability vector will change the wtxid and may reduce the efficiency of compact block relay ([https://github.com/bitcoin/bips/blob/master/bip-0152.mediawiki BIP152]). + +A design flaw in OP_CHECKMULTISIG and OP_CHECKMULTISIGVERIFY makes them consuming an extra stack element ("dummy element") after signature validation. The dummy element is not inspected in any manner, and could be replaced by any value without invalidating the script. This document specifies a new rule to fix this signature malleability. + + +==Specification== + +To fix the dummy element malleability, a new consensus rule ("NULLDUMMY") is deployed to require that the dummy element MUST be the empty byte array. Anything else makes the script evaluate to false immediately. The NULLDUMMY rule applies to OP_CHECKMULTISIG and OP_CHECKMULTISIGVERIFY in pre-segregated scripts, and also pay-to-witness-script-hash scripts described in BIP141. + + +==Deployment== + +This BIP will be deployed by "version bits" [https://github.com/bitcoin/bips/blob/master/bip-0009.mediawiki BIP9] using the same parameters for BIP141 and BIP143, with the name "segwit" and using bit 1. + +For Bitcoin mainnet, the BIP9 starttime is midnight TBD UTC (Epoch timestamp TBD) and BIP9 timeout is midnight TBD UTC (Epoch timestamp TBD). + +For Bitcoin testnet, the BIP9 starttime is midnight 1 May 2016 UTC (Epoch timestamp 1462060800) and BIP9 timeout is midnight 1 May 2017 UTC (Epoch timestamp 1493596800). + + +==Compatibility== + +The reference client has produced compatible signatures from the beginning, and the NULLDUMMY rule has been enforced as relay policy by the reference client since v0.10.0. There has been no transactions violating the requirement being added to the chain since at least August 2015. + +For all scriptPubKey types in actual use, non-compliant signatures can trivially be converted into compliant ones, so there is no loss of functionality by this requirement. Users MUST pay extra attention to this new rule when designing exotic scripts. + + +==Implementation== + +An implementation for the reference client is available at https://github.com/bitcoin/bitcoin/pull/8636 + + +==Acknowledgements== + +Peter Todd is the original author of NULLDUMMY. This document is extracted from the previous [https://github.com/bitcoin/bips/blob/master/bip-0062.mediawiki BIP62] proposal, which was composed by Pieter Wuille and had input from various people. + + +==Copyright== + +This document is placed in the public domain. From 40ba92af28fe7f60c3fd438994a018cf0f588eb3 Mon Sep 17 00:00:00 2001 From: Johnson Lau Date: Fri, 2 Sep 2016 15:15:48 +0800 Subject: [PATCH 06/68] BIP146: title and content changed --- README.mediawiki | 4 +-- bip-0146.mediawiki | 84 ++++++++++++++++++++++++++++++++++++++-------- 2 files changed, 72 insertions(+), 16 deletions(-) diff --git a/README.mediawiki b/README.mediawiki index 8b48af15..d2d6521a 100644 --- a/README.mediawiki +++ b/README.mediawiki @@ -513,8 +513,8 @@ Those proposing changes should consider that ultimately consent may rest with th | Draft |- | [[bip-0146.mediawiki|146]] -| Dealing with signature malleability -| Pieter Wuille, Johnson Lau +| Dealing with signature encoding malleability +| Johnson Lau, Pieter Wuille | Standard | Draft |- diff --git a/bip-0146.mediawiki b/bip-0146.mediawiki index c92c54ef..5358411a 100644 --- a/bip-0146.mediawiki +++ b/bip-0146.mediawiki @@ -1,8 +1,8 @@ 
   BIP: 146
-  Title: Dealing with signature malleability
-  Author: Pieter Wuille 
-          Johnson Lau 
+  Title: Dealing with signature encoding malleability
+  Author: Johnson Lau 
+          Pieter Wuille 
   Status: Draft
   Type: Standards Track
   Created: 2016-08-16
@@ -10,58 +10,114 @@
 
 ==Abstract==
 
-This document specifies proposed changes to the Bitcoin transaction validity rules to fix signature malleability for common transaction types.
+This document specifies proposed changes to the Bitcoin transaction validity rules to fix signature malleability related to ECDSA signature encoding.
 
 
 ==Motivation==
 
 Signature malleability refers to the ability of any relay node on the network to transform the signature in transactions, with no access to the relevant private keys required. For non-segregated witness transactions, signature malleability will change the txid and invalidate any unconfirmed child transactions. Although the txid of segregated witness ([https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki BIP141]) transactions is not third party malleable, this malleability vector will change the wtxid and may reduce the efficiency of compact block relay ([https://github.com/bitcoin/bips/blob/master/bip-0152.mediawiki BIP152]).
 
-Since the enforcement of Strict DER signatures ([https://github.com/bitcoin/bips/blob/master/bip-0066.mediawiki BIP66]), there are 2 remaining known sources of malleability in the signature passed to ECDSA verification opcodes:
+Since the enforcement of Strict DER signatures ([https://github.com/bitcoin/bips/blob/master/bip-0066.mediawiki BIP66]), there are 2 remaining known sources of malleability in ECDSA signatures:
 
 # '''Inherent ECDSA signature malleability''': ECDSA signatures are inherently malleable as taking the negative of the number S inside (modulo the curve order) does not invalidate it.
 
-# '''Inputs ignored by scripts''': The (unnecessary) extra stack element consumed by OP_CHECKMULTISIG and OP_CHECKMULTISIGVERIFY is not inspected in any manner, and could be replaced with any value.
+# '''Malleability of failing signature''': If a signature failed to validate in OP_CHECKSIG or OP_CHECKMULTISIG, a FALSE would be returned to the stack and the script evaluation would continue. The failing signature may take any value, as long as it follows all the rules described in BIP66.
 
 This document specifies new rules to fix the aforesaid signature malleability.
 
 
 ==Specification==
 
-To fix signature malleability, the following new rules are applied:
+To fix signature encoding malleability, the following new rules are applied to pre-segregated witness and segregated witness scripts:
 
 
 ===LOW_S===
 
 We require that the S value inside ECDSA signatures is at most the curve order divided by 2 (essentially restricting this value to its lower half range). Every signature passed to OP_CHECKSIGIncluding pay-to-witness-public-key-hash (P2WPKH) described in BIP141, OP_CHECKSIGVERIFY, OP_CHECKMULTISIG, or OP_CHECKMULTISIGVERIFY, to which ECDSA verification is applied, MUST use a S value between 0x1 and 0x7FFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF 5D576E73 57A4501D DFE92F46 681B20A0 (inclusive) with strict DER encoding (see [https://github.com/bitcoin/bips/blob/master/bip-0066.mediawiki BIP66]).
 
-These operators all perform ECDSA verifications on pubkey/signature pairs, iterating from the top of the stack backwards. For each such verification, if the signature does not pass the Low S value check, the entire script evaluates to false immediately. If the signature is valid DER with low S value, but does not pass ECDSA verification, opcode execution continues as it used to, causing opcode execution to stop and push false on the stack (but not immediately fail the script) in some cases, which potentially skips further signatures (and thus does not subject them to Low S value check).
+If a signature passing to ECDSA verification does not pass the Low S value check and is not an empty byte array, the entire script evaluates to false immediately.
 
 A high S value in signature could be trivially replaced by S' = 0xFFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFE BAAEDCE6 AF48A03B BFD25E8C D0364141 - S.
 
 
-===NULLDUMMY===
+===NULLFAIL===
 
-The extra stack element consumed by OP_CHECKMULTISIG and OP_CHECKMULTISIGVERIFY MUST be the empty byte array (the result of OP_0). Anything else makes the script evaluate to false immediately.
+If an OP_CHECKSIG is trying to return a FALSE value to the stack, we require that the relevant signature must be an empty byte array.
+
+If an OP_CHECKMULTISIG is trying to return a FALSE value to the stack, we require that all signatures passing to this OP_CHECKMULTISIG must be empty byte arrays, even the processing of some signatures might have been skipped due to early termination of the signature verification.
+
+Otherwise, the entire script evaluates to false immediately.
+
+
+==Examples==
+
+The following examples are the combined results of the LOW_S and NULLFAIL rules.Please note that due to implementation details in reference client v0.13.1, some signatures with S value higher than the half curve order might pass the LOW_S test. However, such signatures are certainly invalid, and will fail later due to NULLFAIL test.
+
+Notation:
+
+  CO       : curve order = 0xFFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFE BAAEDCE6 AF48A03B BFD25E8C D0364141
+  HCO      : half curve order = CO / 2 = 0x7FFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF 5D576E73 57A4501D DFE92F46 681B20A0
+  P1, P2   : valid, serialized, public keys
+  S1L, S2L : valid low S value signatures using respective keys P1 and P2 (1 ≤ S ≤ HCO)
+  S1H, S2H : signatures with high S value (otherwise valid) using respective keys P1 and P2 (HCO < S < CO)
+  F        : any BIP66-compliant non-empty byte array but not a valid signature
+
+These scripts will return a TRUE to the stack as before:
+
+  S1L P1 CHECKSIG
+  0 S1L S2L 2 P1 P2 2 CHECKMULTISIG
+
+These scripts will return a FALSE to the stack as before:
+
+  0 P1 CHECKSIG
+  0 0 0 2 P1 P2 2 CHECKMULTISIG
+
+These previously TRUE scripts will fail immediately under the new rules:
+
+  S1H P1 CHECKSIG
+  0 S1H S2L 2 P1 P2 2 CHECKMULTISIG
+  0 S1L S2H 2 P1 P2 2 CHECKMULTISIG
+  0 S1H S2H 2 P1 P2 2 CHECKMULTISIG
+
+These previously FALSE scripts will fail immediately under the new rules:
+
+  F P1 CHECKSIG
+  0 S2L S1L 2 P1 P2 2 CHECKMULTISIG
+  0 S1L F   2 P1 P2 2 CHECKMULTISIG
+  0 F   S2L 2 P1 P2 2 CHECKMULTISIG
+  0 S1L 0   2 P1 P2 2 CHECKMULTISIG
+  0 0   S2L 2 P1 P2 2 CHECKMULTISIG
+  0 F   0   2 P1 P2 2 CHECKMULTISIG
+  0 0   F   2 P1 P2 2 CHECKMULTISIG
 
 
 ==Deployment==
 
-This BIP will be deployed by "version bits" [https://github.com/bitcoin/bips/blob/master/bip-0009.mediawiki BIP9] using the same parameters for BIP141 and BIP143, with the name "segwit" and using bit 1.
+This BIP will be deployed by "version bits" [https://github.com/bitcoin/bips/blob/master/bip-0009.mediawiki BIP9]. Details TBD.
 
 For Bitcoin mainnet, the BIP9 starttime will be midnight TBD UTC (Epoch timestamp TBD) and BIP9 timeout will be midnight TBD UTC (Epoch timestamp TBD).
 
-For Bitcoin testnet, the BIP9 starttime will be midnight 1 May 2016 UTC (Epoch timestamp 1462060800) and BIP9 timeout will be midnight 1 May 2017 UTC (Epoch timestamp 1493596800).
+For Bitcoin testnet, the BIP9 starttime will be midnight TBD UTC (Epoch timestamp TBD) and BIP9 timeout will be midnight TBD UTC (Epoch timestamp TBD).
 
 
 ==Compatibility==
 
-The reference client has produced compatible signatures since v0.9.0, and NULLDUMMY and LOW_S have been enforced as relay policy by the reference client since v0.10.0 and v0.11.1 respectively. As of August 2016, very few transactions violating the requirement are being added to the chain. In addition, every non-compliant signature can trivially be converted into a compliant one, so there is no loss of functionality by this requirement.
+The reference client has produced LOW_S compatible signatures since v0.9.0, and the LOW_S rule has been enforced as relay policy by the reference client since v0.11.1. As of August 2016, very few transactions violating the requirement are being added to the chain. For all scriptPubKey types in actual use, non-compliant signatures can trivially be converted into compliant ones, so there is no loss of functionality by these requirements.
+
+Scripts with failing OP_CHECKSIG or OP_CHECKMULTISIG rarely happen on the chain. The NULLFAIL rule has been enforced as relay policy by the reference client since v0.13.1.
+
+Users MUST pay extra attention to these new rules when designing exotic scripts.
 
 
 ==Implementation==
 
-An implementation for the reference client is available at https://github.com/bitcoin/bitcoin/pull/8533
+Implementations for the reference client is available at:
+
+https://github.com/bitcoin/bitcoin/blob/35fe0393f216aa6020fc929272118eade5628636/src/script/interpreter.cpp#L185
+
+and
+
+https://github.com/bitcoin/bitcoin/pull/8634
 
 
 ==Footnotes==

From 36496946860d71d4460437572e6c4c780b125cad Mon Sep 17 00:00:00 2001
From: Luke Dashjr 
Date: Fri, 2 Sep 2016 22:09:46 +0000
Subject: [PATCH 07/68] Assign BIP 147: Dealing with dummy stack element
 malleability

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

diff --git a/README.mediawiki b/README.mediawiki
index 8b48af15..813d6b3b 100644
--- a/README.mediawiki
+++ b/README.mediawiki
@@ -518,6 +518,12 @@ Those proposing changes should consider that ultimately consent may rest with th
 | Standard
 | Draft
 |-
+| [[bip-0147.mediawiki|147]]
+| Dealing with dummy stack element malleability
+| Johnson Lau
+| Standard
+| Draft
+|-
 | [[bip-0150.mediawiki|150]]
 | Peer Authentication
 | Jonas Schnelli
diff --git a/bip-nulldummy.mediawiki b/bip-0147.mediawiki
similarity index 99%
rename from bip-nulldummy.mediawiki
rename to bip-0147.mediawiki
index 802fb21d..8b6fe1ab 100644
--- a/bip-nulldummy.mediawiki
+++ b/bip-0147.mediawiki
@@ -1,5 +1,5 @@
 
-  BIP: ?
+  BIP: 147
   Title: Dealing with dummy stack element malleability
   Author: Johnson Lau 
   Status: Draft

From 316d4f32a0fa5630de027893e8e7ef2c74bd4c3d Mon Sep 17 00:00:00 2001
From: Pieter Wuille 
Date: Thu, 21 Jul 2016 18:40:38 +0200
Subject: [PATCH 08/68] Version 2 sendcmpct for integration of segwit with CB

---
 bip-0152.mediawiki | 36 ++++++++++++++++++++++++++++++------
 1 file changed, 30 insertions(+), 6 deletions(-)

diff --git a/bip-0152.mediawiki b/bip-0152.mediawiki
index cfae0c0d..8d84ee98 100644
--- a/bip-0152.mediawiki
+++ b/bip-0152.mediawiki
@@ -21,7 +21,7 @@ Thus, decreasing the bandwidth used during block relay is very useful for many i
 
 While the goal of this work is explicitly not to reduce block transfer latency, it does, as a side effect reduce block transfer latencies in some rather significant ways. Additionally, this work forms a foundation for future work explicitly targeting low-latency block transfer.
 
-==Specification==
+==Specification for version 1==
 
 ===Intended Protocol Flow===
 
@@ -45,7 +45,7 @@ A PrefilledTransaction structure is used in HeaderAndShortIDs to provide a list
 |-
 |index||CompactSize||1, 3 bytes||Compact Size, differentially encoded since the last PrefilledTransaction in a list||The index into the block at which this transaction is
 |-
-|tx||Transaction||variable||As encoded in "tx" messages||The transaction which is in the block at index index.
+|tx||Transaction||variable||As encoded in "tx" messages sent in response to getdata MSG_TX||The transaction which is in the block at index index.
 |}
 
 ====HeaderAndShortIDs====
@@ -90,7 +90,7 @@ A BlockTransactions structure is used to provide some of the transactions in a b
 |-
 |transactions_length||CompactSize||1 or 3 bytes||As used to encode array lengths elsewhere||||The number of transactions provided
 |-
-|transactions||List of Transactions||variable||As encoded in "tx" messages||The transactions provided
+|transactions||List of Transactions||variable||As encoded in "tx" messages in response to getdata MSG_TX||The transactions provided
 |}
 
 ====Short transaction IDs====
@@ -111,6 +111,7 @@ A new inv type (MSG_CMPCT_BLOCK == 4) and several new protocol messages are adde
 # Upon receipt of a "sendcmpct" message with the second integer set to something other than 1, nodes MUST treat the peer as if they had not received the message (as it indicates the peer will provide an unexpected encoding in cmpctblock, and/or other, messages). This allows future versions to send duplicate sendcmpct messages with different versions as a part of a version handshake for future versions.
 # Nodes SHOULD check for a protocol version of >= 70014 before sending sendcmpct messages.
 # Nodes MUST NOT send a request for a MSG_CMPCT_BLOCK object to a peer before having received a sendcmpct message from that peer.
+# Nodes MUST NOT request a MSG_CMPCT_BLOCK object before having sent a sendcmpct message to that peer, as the peer cannot know what version protocol to use in the response.
 
 ====MSG_CMPCT_BLOCK====
 # getdata messages may now contain requests for MSG_CMPCT_BLOCK objects.
@@ -136,7 +137,17 @@ A new inv type (MSG_CMPCT_BLOCK == 4) and several new protocol messages are adde
 ## For each short transaction ID from the original cmpctblock, in order, find the corresponding transaction either from the blocktxn message or from other sources and place it in the first available position in the block.
 # Once the block has been reconstructed, it shall be processed as normal, keeping in mind that short transaction IDs are expected to occasionally collide, and that nodes MUST NOT be penalized for such collisions, wherever they appear.
 
-===Implementation Notes===
+==Specification for version 2==
+Compact blocks version 2 is almost identical to version 1, but supports segregated witness transactions (BIP 141 and BIP 144). The changes are:
+
+# The version number inside sendcmpct is 2 instead of 1.
+# Transactions inside cmpctblock messages (both those used as direct announcement and those in response to getdata) and in blocktxn should include witness data, using the same format as responses to getdata MSG_WITNESS_TX, specified in BIP144.
+# Short transaction IDs sent to us in cmpctblock messages, and sent by us in getblocktxn messages, are computed using the same process as in version 1, but using the wtxid as defined in BIP 141 instead of the txid.
+
+Nodes that support segwit MAY choose to support both version 1 and 2 compact blocks. To do so, two sendcmpct messages SHOULD be sent at startup: the first one for version 1 and a second one for version 2.
+When receiving multiple sendcmpct messages, the last received one that is compatible with the receiver's software MUST be used.
+
+==Implementation Notes==
 # For nodes which have sufficient inbound bandwidth, sending a sendcmpct message with the first integer set to 1 to up to 3 peers is RECOMMENDED. If possible, it is RECOMMENDED that those peers be selected based on their past performance in providing blocks quickly (eg the three peers which provided the highest number of the recent N blocks the quickest), allowing nodes to receive blocks which come from those peers in only 0.5*RTT.
 
 # Nodes MUST NOT send such sendcmpct messages to more than three peers, as it encourages wasting outbound bandwidth across the network.
@@ -153,7 +164,7 @@ A new inv type (MSG_CMPCT_BLOCK == 4) and several new protocol messages are adde
 
 # Note that the MSG_CMPCT_BLOCK section does not require that nodes respond to MSG_CMPCT_BLOCK getdata requests for blocks which they did not recently announce. This allows nodes to calculate cmpctblock messages at announce-time instead of at request-time. Blocks which are requested with a MSG_CMPCT_BLOCK getdata, but which are not responded to with a cmpctblock message MUST be responded to with a block message, allowing nodes to request all blocks using MSG_CMPCT_BLOCK getdatas and rely on their peer to pick an appropriate response.
 
-# While the current version sends transactions with the same encodings as is used in tx messages and elsewhere in the protocol, the version field in sendcmpct is intended to allow this to change in the future. For this reason, it is recommended that the code used to decode PrefilledTransaction and BlockTransactions messages be prepared to take a different transaction encoding, if and when the version field in sendcmpct changes in a future BIP.
+# While the current version sends transactions with the same encodings as are used in tx messages and elsewhere in the protocol, the version field in sendcmpct is intended to allow this to change in the future. For this reason, it is recommended that the code used to decode PrefilledTransaction and BlockTransactions messages be prepared to take a different transaction encoding, if and when the version field in sendcmpct changes in a future BIP.
 
 # Any undefined behavior in this spec may cause failure to transfer block to, peer disconnection by, or self-destruction by the receiving node. A node receiving non-minimally-encoded CompactSize encodings should make a best-effort to eat the sender's cat.
 
@@ -190,13 +201,26 @@ In case 1, we're good. In cases 2, 3, or 4, we request the full transaction beca
 
 This means that ''B = 48'' bits short IDs suffice for blocks with up to ''t = 10000'' transactions, mempools up to ''m = 100000'' transactions, with failure to reconstruct at most one in ''F = 281474'' blocks. Since failure to reconstruct just means we fall back to normal inv/header based relay, it isn't necessary to avoid such failure completely. It just needs to be sufficiently rare they have a lower impact than random transmission failures (for example, network disconnection, node overloaded, ...).
 
+====Separate version for segregated witness====
+
+The changes to transaction and block relay in BIP 144 introduce separate MSG_FILTERED_ versions of messages in getdata,
+allowing a receiver to choose individually where witness data is wanted.
+
+This method is not useful for compact blocks because `cmpctblock` blocks can be sent unsolicitedly in high-bandwidth
+mode, so we need to negotiate at least whether those should include witness data up front. There is little use for a
+validating node that only sometimes processes witness data, so we may as well use that negotiation for everything and
+turn it into a separate protocol version. We also need a means to distinguish different versions of the same transaction
+with different witnesses for correct reconstruction, so this also forces us to use wtxids instead of txids for short IDs
+everywhere in that case.
+
 ==Backward compatibility==
 
 Older clients remain fully compatible and interoperable after this change.
 
 ==Implementation==
 
-https://github.com/bitcoin/bitcoin/pull/8068
+https://github.com/bitcoin/bitcoin/pull/8068 for version 1.
+https://github.com/bitcoin/bitcoin/pull/8393 for version 2.
 
 ==Acknowledgements==
 

From 367eade6e8e639c31e9c44d13f882a8273012656 Mon Sep 17 00:00:00 2001
From: Matt Corallo 
Date: Mon, 5 Sep 2016 17:11:00 -0400
Subject: [PATCH 09/68] Add version negotiation details

---
 bip-0152.mediawiki | 18 ++++++++++++------
 1 file changed, 12 insertions(+), 6 deletions(-)

diff --git a/bip-0152.mediawiki b/bip-0152.mediawiki
index 8d84ee98..9a011650 100644
--- a/bip-0152.mediawiki
+++ b/bip-0152.mediawiki
@@ -108,10 +108,10 @@ A new inv type (MSG_CMPCT_BLOCK == 4) and several new protocol messages are adde
 # The second integer SHALL be interpreted as a little-endian version number. Nodes sending a sendcmpct message MUST currently set this value to 1.
 # Upon receipt of a "sendcmpct" message with the first and second integers set to 1, the node SHOULD announce new blocks by sending a cmpctblock message.
 # Upon receipt of a "sendcmpct" message with the first integer set to 0, the node SHOULD NOT announce new blocks by sending a cmpctblock message, but SHOULD announce new blocks by sending invs or headers, as defined by BIP130.
-# Upon receipt of a "sendcmpct" message with the second integer set to something other than 1, nodes MUST treat the peer as if they had not received the message (as it indicates the peer will provide an unexpected encoding in cmpctblock, and/or other, messages). This allows future versions to send duplicate sendcmpct messages with different versions as a part of a version handshake for future versions.
+# Upon receipt of a "sendcmpct" message with the second integer set to something other than 1, nodes MUST treat the peer as if they had not received the message (as it indicates the peer will provide an unexpected encoding in cmpctblock, and/or other, messages). This allows future versions to send duplicate sendcmpct messages with different versions as a part of a version handshake for future versions. See Protocol Versioning section, below, for more info on the specifics of the version-negotiation mechanics.
 # Nodes SHOULD check for a protocol version of >= 70014 before sending sendcmpct messages.
 # Nodes MUST NOT send a request for a MSG_CMPCT_BLOCK object to a peer before having received a sendcmpct message from that peer.
-# Nodes MUST NOT request a MSG_CMPCT_BLOCK object before having sent a sendcmpct message to that peer, as the peer cannot know what version protocol to use in the response.
+# Nodes MUST NOT request a MSG_CMPCT_BLOCK object before having sent all sendcmpct messages to that peer which they intend to send, as the peer cannot know what version protocol to use in the response.
 
 ====MSG_CMPCT_BLOCK====
 # getdata messages may now contain requests for MSG_CMPCT_BLOCK objects.
@@ -137,16 +137,22 @@ A new inv type (MSG_CMPCT_BLOCK == 4) and several new protocol messages are adde
 ## For each short transaction ID from the original cmpctblock, in order, find the corresponding transaction either from the blocktxn message or from other sources and place it in the first available position in the block.
 # Once the block has been reconstructed, it shall be processed as normal, keeping in mind that short transaction IDs are expected to occasionally collide, and that nodes MUST NOT be penalized for such collisions, wherever they appear.
 
+==Protocol Versioning==
+# The protocol version negotiation allows two nodes to agree on the version of compact blocks which they will exchange. As it is only in a single field, it does not allow a node to support a specific version in only one direction (sending or receiving).
+# Upon connection establishment, a node SHOULD send a burst of sendcmpct messages containing every version of compact block encodings for which they are willing to support sending cmpctblock and blocktxn messages, and receiving getblocktxn messages. These messages SHOULD be ordered in the order of the priority which the node wishes to receive cmpctblock/blocktxn messages, with the highest-priority version sendcmpct message sent last.
+# The encoding version used to send a cmpctblock or blocktxn message or to receive a getblocktxn message MUST be the second integer (version number) in the most recent sendcmpct message received for which a sendcmpct message with the same version number was sent.
+# Nodes MUST NOT send a sendcmpct message which contains a version number other than the version number which has been negotiated for receiving cmpctblock/blocktxn messages after sending a request for a MSG_CMPCT_BLOCK object, sending a cmpctblock, getblocktxn, blocktxn, or pong message.
+# Nodes MUST NOT set the first integer (boolean) value in sendcmpct messages to 1 in any sendcmpct message prior to the last sendcmpct message which contains a novel second integer (version number).
+# As a node must send all sendcmpct messages which contain a novel version announcement before any other compact block-related messages, it is possible to determine which version of compact blocks will be used for each object received. It is, however, not possible to know which version will be used to encode the response to a request for a compact block object before any MSG_CMPCT_BLOCK-containing inv, cmpctblock, getblocktxn, blocktxn, or ping messages have been exchanged.
+# Thus, if a node wishes to determine exactly which version of compact blocks will be used before requesting a compact block object, it must send all of its sendcmpct version announcements, followed by a ping, and wait for the pong response to ensure it has received all sendcmpctblock version announcement messages from the remote peer. Nodes can, obviously, however, determine that the version used will be at least a certain version (in their priority order) after having received a sendcmpct message from the remote peer containing that version as the second integer.
+
 ==Specification for version 2==
 Compact blocks version 2 is almost identical to version 1, but supports segregated witness transactions (BIP 141 and BIP 144). The changes are:
 
-# The version number inside sendcmpct is 2 instead of 1.
+# The second integer (version number) inside sendcmpct is 2 instead of 1 (see Protocol Versioning section, above).
 # Transactions inside cmpctblock messages (both those used as direct announcement and those in response to getdata) and in blocktxn should include witness data, using the same format as responses to getdata MSG_WITNESS_TX, specified in BIP144.
 # Short transaction IDs sent to us in cmpctblock messages, and sent by us in getblocktxn messages, are computed using the same process as in version 1, but using the wtxid as defined in BIP 141 instead of the txid.
 
-Nodes that support segwit MAY choose to support both version 1 and 2 compact blocks. To do so, two sendcmpct messages SHOULD be sent at startup: the first one for version 1 and a second one for version 2.
-When receiving multiple sendcmpct messages, the last received one that is compatible with the receiver's software MUST be used.
-
 ==Implementation Notes==
 # For nodes which have sufficient inbound bandwidth, sending a sendcmpct message with the first integer set to 1 to up to 3 peers is RECOMMENDED. If possible, it is RECOMMENDED that those peers be selected based on their past performance in providing blocks quickly (eg the three peers which provided the highest number of the recent N blocks the quickest), allowing nodes to receive blocks which come from those peers in only 0.5*RTT.
 

From 2692800cab4680c3310fc900e2a3e6f479056e70 Mon Sep 17 00:00:00 2001
From: Thomas Kerin 
Date: Wed, 7 Sep 2016 16:25:59 +0100
Subject: [PATCH 10/68] Fix url for BIP44

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

diff --git a/bip-p2sh-accounts.mediawiki b/bip-p2sh-accounts.mediawiki
index cf030039..251f7682 100644
--- a/bip-p2sh-accounts.mediawiki
+++ b/bip-p2sh-accounts.mediawiki
@@ -92,5 +92,5 @@ To derive the P2SH address from the above calculated public key, we use the enca
 * [[bip-0016.mediawiki|BIP16 - Pay to Script Hash]]
 * [[bip-0032.mediawiki|BIP32 - Hierarchical Deterministic Wallets]]
 * [[bip-0043.mediawiki|BIP43 - Purpose Field for Deterministic Wallets]]
-* [[bip-0043.mediawiki|BIP44 - Multi-Account Hierarchy for Deterministic Wallets]]
-* [[bip-0141.mediawiki|BIP141 - Segregated Witness (Consensus layer)]]
\ No newline at end of file
+* [[bip-0044.mediawiki|BIP44 - Multi-Account Hierarchy for Deterministic Wallets]]
+* [[bip-0141.mediawiki|BIP141 - Segregated Witness (Consensus layer)]]

From c2213ed1fdabc671c8b3c46b3f7dcfedacf7dafb Mon Sep 17 00:00:00 2001
From: jonnynewbs 
Date: Thu, 15 Sep 2016 16:39:10 -0400
Subject: [PATCH 11/68] Update BIP 141 to include definition of Virtual
 transaction size and Transaction weight

---
 bip-0141.mediawiki | 14 ++++++++++++++
 1 file changed, 14 insertions(+)

diff --git a/bip-0141.mediawiki b/bip-0141.mediawiki
index ccf18b62..2b2360b7 100644
--- a/bip-0141.mediawiki
+++ b/bip-0141.mediawiki
@@ -125,6 +125,20 @@ The sigop limit is likewise quadrupled to ≤ 80,000.
 
 Each P2WPKH input is counted as 1 sigop. In addition, opcodes within a P2WSH witnessScript are counted identically as previously within the P2SH redeemScript. That is, CHECKSIG is counted as only 1 sigop, and CHECKMULTISIG is counted as 1 to 20 sigops according to the arguments. This rule applies to both native witness program and P2SH witness program.
 
+=== Additional definitions ===
+
+The following definitions are not used for consensus limits, but are suggested to provide language consistent with the terminology introduced above.
+
+==== Transaction size calculations ====
+
+''Transaction weight'' is defined as ''Base transaction size'' * 3 + ''Total transaction size'' (ie. the same method as calculating ''Block weight'' from ''Base size'' and ''Total size'').
+
+''Virtual transaction size'' is defined as ''Transaction weight'' / 4 (rounded up to nearest integer).
+
+''Base transaction size'' is the transaction size in bytes with the original transaction serialization without any witness-related data.
+
+''Total transaction size'' is the transaction size in bytes serialized as described in [[bip-0144.mediawiki|BIP144]], including base data and witness data.
+
 == Examples ==
 
 === P2WPKH ===

From a380daff168cccac72b716294cc6cd947d9e0df6 Mon Sep 17 00:00:00 2001
From: Matt Corallo 
Date: Thu, 8 Sep 2016 10:43:22 -0400
Subject: [PATCH 12/68] Switch priority order to highest-first and add sample
 negotiation

---
 bip-0152.mediawiki | 15 +++++++++++----
 1 file changed, 11 insertions(+), 4 deletions(-)

diff --git a/bip-0152.mediawiki b/bip-0152.mediawiki
index 9a011650..5635ed3f 100644
--- a/bip-0152.mediawiki
+++ b/bip-0152.mediawiki
@@ -139,13 +139,20 @@ A new inv type (MSG_CMPCT_BLOCK == 4) and several new protocol messages are adde
 
 ==Protocol Versioning==
 # The protocol version negotiation allows two nodes to agree on the version of compact blocks which they will exchange. As it is only in a single field, it does not allow a node to support a specific version in only one direction (sending or receiving).
-# Upon connection establishment, a node SHOULD send a burst of sendcmpct messages containing every version of compact block encodings for which they are willing to support sending cmpctblock and blocktxn messages, and receiving getblocktxn messages. These messages SHOULD be ordered in the order of the priority which the node wishes to receive cmpctblock/blocktxn messages, with the highest-priority version sendcmpct message sent last.
-# The encoding version used to send a cmpctblock or blocktxn message or to receive a getblocktxn message MUST be the second integer (version number) in the most recent sendcmpct message received for which a sendcmpct message with the same version number was sent.
+# Upon connection establishment, a node SHOULD send a burst of sendcmpct messages containing every version of compact block encodings for which they are willing to support sending cmpctblock and blocktxn messages, and receiving getblocktxn messages. These messages SHOULD be ordered in the order of the priority which the node wishes to receive cmpctblock/blocktxn messages, with the highest-priority version sendcmpct message sent first.
+# The encoding version used to send a cmpctblock or blocktxn message or to receive a getblocktxn message MUST be the second integer (version number) in the first sendcmpct message received for which a sendcmpct message with the same version number was sent.
 # Nodes MUST NOT send a sendcmpct message which contains a version number other than the version number which has been negotiated for receiving cmpctblock/blocktxn messages after sending a request for a MSG_CMPCT_BLOCK object, sending a cmpctblock, getblocktxn, blocktxn, or pong message.
-# Nodes MUST NOT set the first integer (boolean) value in sendcmpct messages to 1 in any sendcmpct message prior to the last sendcmpct message which contains a novel second integer (version number).
-# As a node must send all sendcmpct messages which contain a novel version announcement before any other compact block-related messages, it is possible to determine which version of compact blocks will be used for each object received. It is, however, not possible to know which version will be used to encode the response to a request for a compact block object before any MSG_CMPCT_BLOCK-containing inv, cmpctblock, getblocktxn, blocktxn, or ping messages have been exchanged.
+# As a node must send all sendcmpct messages which contain a novel version announcement before any other compact block-related messages, it is possible to determine which version of compact blocks will be used for each object received. It is, however, not possible to know which version will be used to encode the response to a request for a compact block object before any MSG_CMPCT_BLOCK-containing inv, cmpctblock, getblocktxn, blocktxn, or ping/pong messages have been exchanged.
 # Thus, if a node wishes to determine exactly which version of compact blocks will be used before requesting a compact block object, it must send all of its sendcmpct version announcements, followed by a ping, and wait for the pong response to ensure it has received all sendcmpctblock version announcement messages from the remote peer. Nodes can, obviously, however, determine that the version used will be at least a certain version (in their priority order) after having received a sendcmpct message from the remote peer containing that version as the second integer.
 
+===Sample Version Implementation===
+# By way of example, an implementation of the above protocol might look like the following.
+# Upon exchanging version/verack messages, a node immediately sends its list of sendcmpct announcements to the other side, with the version which it wants to receive sent first.
+# Upon receiving the first sendcmpct announcement with a protocol version which is understood from the remote peer, a node will "lock in" the compact block encoding version which will be used to encode compact blocks to that peer.
+# Upon receiving a sendcmpct announcement with a protocol version which is understood from the remote peer, a node will check if that protocol version is higher-receive-priority than the current receive-protocol-version in use on the connection, and switch to that version for decoding new compact block messages received.
+# A node might wish to keep a flag for each peer which indicates compact block version negotiation is complete, which can be set upon receiving any compact block-related, or pong message.
+# The above implementation requires only a compile-time list of supported versions in some static priority order, two version fields per peer, and an optional negotiation-complete boolean per-peer.
+
 ==Specification for version 2==
 Compact blocks version 2 is almost identical to version 1, but supports segregated witness transactions (BIP 141 and BIP 144). The changes are:
 

From bca0dfb3b981ac2bd35aee566dd33e14886a43f8 Mon Sep 17 00:00:00 2001
From: Matt Corallo 
Date: Thu, 8 Sep 2016 10:56:24 -0400
Subject: [PATCH 13/68] Fix message type

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

diff --git a/bip-0152.mediawiki b/bip-0152.mediawiki
index 5635ed3f..38c402cb 100644
--- a/bip-0152.mediawiki
+++ b/bip-0152.mediawiki
@@ -142,7 +142,7 @@ A new inv type (MSG_CMPCT_BLOCK == 4) and several new protocol messages are adde
 # Upon connection establishment, a node SHOULD send a burst of sendcmpct messages containing every version of compact block encodings for which they are willing to support sending cmpctblock and blocktxn messages, and receiving getblocktxn messages. These messages SHOULD be ordered in the order of the priority which the node wishes to receive cmpctblock/blocktxn messages, with the highest-priority version sendcmpct message sent first.
 # The encoding version used to send a cmpctblock or blocktxn message or to receive a getblocktxn message MUST be the second integer (version number) in the first sendcmpct message received for which a sendcmpct message with the same version number was sent.
 # Nodes MUST NOT send a sendcmpct message which contains a version number other than the version number which has been negotiated for receiving cmpctblock/blocktxn messages after sending a request for a MSG_CMPCT_BLOCK object, sending a cmpctblock, getblocktxn, blocktxn, or pong message.
-# As a node must send all sendcmpct messages which contain a novel version announcement before any other compact block-related messages, it is possible to determine which version of compact blocks will be used for each object received. It is, however, not possible to know which version will be used to encode the response to a request for a compact block object before any MSG_CMPCT_BLOCK-containing inv, cmpctblock, getblocktxn, blocktxn, or ping/pong messages have been exchanged.
+# As a node must send all sendcmpct messages which contain a novel version announcement before any other compact block-related messages, it is possible to determine which version of compact blocks will be used for each object received. It is, however, not possible to know which version will be used to encode the response to a request for a compact block object before any MSG_CMPCT_BLOCK-containing getdata, cmpctblock, getblocktxn, blocktxn, or ping/pong messages have been exchanged.
 # Thus, if a node wishes to determine exactly which version of compact blocks will be used before requesting a compact block object, it must send all of its sendcmpct version announcements, followed by a ping, and wait for the pong response to ensure it has received all sendcmpctblock version announcement messages from the remote peer. Nodes can, obviously, however, determine that the version used will be at least a certain version (in their priority order) after having received a sendcmpct message from the remote peer containing that version as the second integer.
 
 ===Sample Version Implementation===

From 430bf9f2355203c755cb205c6ad5671ffae5e888 Mon Sep 17 00:00:00 2001
From: Matt Corallo 
Date: Fri, 9 Sep 2016 09:46:09 -0400
Subject: [PATCH 14/68] Specify which block encoding to use in the fallback
 block message

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

diff --git a/bip-0152.mediawiki b/bip-0152.mediawiki
index 38c402cb..1b743061 100644
--- a/bip-0152.mediawiki
+++ b/bip-0152.mediawiki
@@ -159,6 +159,7 @@ Compact blocks version 2 is almost identical to version 1, but supports segregat
 # The second integer (version number) inside sendcmpct is 2 instead of 1 (see Protocol Versioning section, above).
 # Transactions inside cmpctblock messages (both those used as direct announcement and those in response to getdata) and in blocktxn should include witness data, using the same format as responses to getdata MSG_WITNESS_TX, specified in BIP144.
 # Short transaction IDs sent to us in cmpctblock messages, and sent by us in getblocktxn messages, are computed using the same process as in version 1, but using the wtxid as defined in BIP 141 instead of the txid.
+# Upon receipt of a getdata containing a request for a MSG_CMPCT_BLOCK object for which a cmpctblock message is not sent in response, the block message containing the requested block in non-compact form MUST be encoded with witnesses (as is sent in reply to a MSG_WITNESS_BLOCK getdata) if the protocol version used to encode the cmpctblock message would have been 2, and encoded without witnesses (as is sent in response to a MSG_BLOCK getdata) if the protocol version used to encode the cmpctblock message would have been 1.
 
 ==Implementation Notes==
 # For nodes which have sufficient inbound bandwidth, sending a sendcmpct message with the first integer set to 1 to up to 3 peers is RECOMMENDED. If possible, it is RECOMMENDED that those peers be selected based on their past performance in providing blocks quickly (eg the three peers which provided the highest number of the recent N blocks the quickest), allowing nodes to receive blocks which come from those peers in only 0.5*RTT.

From 605cb29934666c1acae15032f3f6abcf2bfcc6b3 Mon Sep 17 00:00:00 2001
From: TomZ 
Date: Mon, 19 Sep 2016 18:13:33 +0200
Subject: [PATCH 15/68] Adding Flexible Transactions proposal.

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

diff --git a/bip-flexibleTransactions.mediawiki b/bip-flexibleTransactions.mediawiki
new file mode 100644
index 00000000..9b428ec8
--- /dev/null
+++ b/bip-flexibleTransactions.mediawiki
@@ -0,0 +1,244 @@
+
+  BIP: ??
+  Title: Flexible Transactions
+  Author: Tom Zander 
+  Status: Draft
+  Type: Standards Track
+  Created: 2016-07-27
+

+
+==Abstract==
+
+This BIP describes the next step in making Bitcoin's most basic element,
+the transaction, more flexible and easier to extend. At the same time this
+fixes all known cases of malleability and resolves significant amounts of
+technical debt.
+
+==Summary==
+
+Flexible Transactions uses the fact that the first 4 bytes in a transaction
+determine the version and that the majority of the clients use a
+non-consensus rule (a policy) to not accept transaction version numbers
+other than those specifically defined by Bitcoin.
+This BIP chooses a new version number, 4, and defines that the data
+following the bytes for the version is in a format called Compact Message
+Format (CMF). CMF is a flexible, token based format where each token is a
+combination of a name, a format and a value. Because the name is added we
+can skip unused tokens and we can freely add new tokens in a simple manner
+in future. Soft fork upgrades will become much easier and cleaner this
+way.
+
+This protocol upgrade cleans up past soft fork changes like BIP68 which
+reuse existing fields and do them in a much better to maintain and easier
+to parse system. It creates the building blocks to allow new features to be
+added much cleaner in the future.
+
+It also shows to be possible to remove signatures from transactions with
+minimal upgrades of software and still maintain a coherent transaction
+history. Tests show that this can reduce space usage to about 75%.
+
+==Motivation==
+
+Token based file-formats are not new, systems like XML and HTMl use a
+similar system to allow future growth and they have been quite successful
+for decades in part because of this property.
+
+Bitcoin needs a similar way of making the transaction future-proof because
+re-purposing not used fields for new features is not good for creating
+maintainable code.
+
+Next to that this protocol upgrade will re-order the data-fields which
+allows us to cleanly fix the malleability issue which means that future
+technologies like Lightning Network will depend on this BIP being deployed.
+
+At the same time, due to this re-ordering of data fields, it becomes very
+easy to remove signatures from a transaction without breaking its tx-id,
+which is great for future pruning features.
+
+
+=== Tokens ===
+
+In the compact message format we define tokens and in this specification we
+define how these tokens are named, where they can be placed and which are
+optional.  To refer to XML, this specification would be the schema of
+a transaction.
+
+CMF tokens are triplets of name, format (like PositiveInteger) and value.
+Names in this scope are defined much like an enumeration where the actual
+integer value (id, below) is equally important to the written name.
+If any token found that is not covered in the next table will make the
+transaction that contains it invalid.
+
+{| class="wikitable"
+|-
+! Name !! id !! Format !! Default Value !! Description
+|-
+|TxEnd         ||  0 ||BoolTrue ||  Required    ||A marker that is end of the transaction.
+|-
+|TxInPrevHash  ||  1 ||ByteArray||  Required    ||TxId we are spending
+|-
+|TxPrevIndex   ||  2 ||Integer  ||      0       ||Index in prev tx we are spending (applied to previous TxInPrevHash)
+|-
+|TxInScript    ||  3 ||ByteArray||  Required    ||The 'input' part of the script
+|-
+|TxOutValue    ||  4 ||Integer  ||  Required    ||Amount of satoshi to transfer
+|-
+|TxOutScript   ||  5 ||ByteArray||  Required    ||The 'output' part of the script
+|-
+|LockByBlock   ||  6 ||Integer  ||  Optional    ||BIP68 replacement
+|-
+|LockByTime    ||  7 ||Integer  ||  Optional    ||BIP68 replacement
+|-
+|ScriptVersion ||  8 ||Integer  ||      2       ||Defines script version for outputs following
+|-
+|NOP_1x        || 1x || . ||  Optional    ||Values that will be ignored by anyone parsing the transaction
+|}
+
+
+=== Scripting changes ===
+
+In the current version of Bitcoin-script, version 1, there are various
+opcodes that are used to validate the cryptographic proofs that users have
+to provide in order to spend outputs.
+
+The OP_CHECKSIG is the most well known and, as its name implies, it
+validates a signature.
+In the new version of 'script' (version 2) the data that is signed is
+changed to be equivalent to the transaction-id. This is a massive
+simplification and also the only change between version 1 and version 2 of
+script.
+
+=== Serialization order===
+
+The tokens defined above shall be serialized in a certain order for the
+transaction to be valid.  Not serializing transactions in the
+order specified would allow multiple interpretations of the data which
+can't be allowed.
+There is still some flexibility and for that reason it is important for
+implementors to remember that the actual serialized data is used for the
+calculation of the transaction-id. Reading and writing it may give you a
+different output and when the txid changes, the signatures will break.
+
+At a macro-level the transaction has these segments. The order of the
+segments can not be changed, but you can skip segments.
+
+{| class="wikitable"
+!Segment !! Description
+|-
+|   Inputs   || Details about inputs.
+|-
+|  Outputs   || Details and scripts for outputs
+|-
+| Additional || For future expansion
+|-
+| Signatures || The scripts for the inputs
+|-
+|   TxEnd    || End of the transaction
+|}
+
+The TxId is calculated by taking the serialized transaction without the
+Signatures and the TxEnd and hashing that.
+
+
+{| class="wikitable"
+!Segment !! Tags !! Description
+|-
+|Inputs||TxInPrevHash and TxInPrevIndex||Index can be skipped, but in any input the PrevHash always has to come first
+|-
+|Outputs||TxOutScript, TxOutValue||Order is not relevant
+|-
+|Additional||LockByBlock  LockByTime NOP_1x
+|-
+|Signatures||TxInScript||Exactly the same amount as there are inputs
+|-
+|TxEnd||TxEnd
+|}
+
+TxEnd is there to allow a parser to know when one transaction in a stream
+has ended, allowing the next to be parsed.
+
+Notice that the token ScriptVersion is currently not allowed because we
+don't have any valid value to give it. But if we introduce a new script
+version it would be placed in the outputs segment.
+
+=== Script v2 ===
+
+The default value of ScriptVersion is number 2, as opposed to the version 1
+of script that the is in use today.  The version 2 is mostly identical
+to version one, including upgrades made to it over the years and in the 
+future. The only exception is that the OP_CHECKSIG is made dramatically
+simpler.  The input-type for OP_CHECKSIG is now no longer configurable, it is
+always '1' and the content that will be signed is the txid.
+
+TODO: does check-multisig need its own mention?
+
+
+=== Block-malleability ===
+
+The effect of leaving the signatures out of the calculation of the
+transaction-id implies that the signatures are also not used for the
+calculation of the merkle tree.  This means that changes in signatures
+would not be detectable. Except naturally by the fact that missing or
+broken signatures breaks full validation. But it is important to detect
+modifications to such signatures outside of validating all transactions.
+
+For this reason the merkle tree is extended to include (append) the hash of
+the v4 transactions. The markle tree will continue to have all the
+transactions' tx-ids but appended to that are the v4 hahes that include the
+signatures as well.  Specifically the hash is taken over a data-blob that
+is build up from:
+
+1. the tx-id
+2. the CMF-tokens 'TxInScript'
+
+
+=== Future extensibility ===
+
+The NOP_1x wildcard used in the table explaining tokens is actually a list
+of 10 values that currently are specified as NOP (no-operation) tags.
+
+Any implementation that supports the v4 transaction format should ignore
+this field in a transaction. Interpreting and using the transaction as if
+that field was not present at all.
+
+Future software may use these fields to decorate a transaction with
+additional data or features. Transaction generating software should not
+trivially use these tokens for their own usage without cooperation and
+communication with the rest of the Bitcoin ecosystem as miners certainly
+have the option to reject transactions that use unknown-to-them tokens.
+
+==Backwards compatibility ==
+
+Fully validating older clients are not compatible with this change.
+
+SPV (simple payment validation) wallets need to be updated to receive or
+create the new transaction type.
+
+This BIP introduces a new transaction format without changing or
+deprecating the existing one or any of its practices. Therefor it is
+backwards compatible for any existing data or parsing-code.
+
+==Reference Implementation==
+
+Bitcoin Classic includes this in its beta releases and a reference
+implementation can be found at;
+
+https://github.com/bitcoinclassic/bitcoinclassic/pull/186
+
+
+==Deployment==
+
+To be determined
+
+==References==
+
+[https://github.com/bitcoinclassic/documentation/blob/master/spec/compactmessageformat.md] CMF
+
+==Copyright==
+
+Copyright (c) 2016 Tom Zander 
+
+This document is licensed under the Open Publication License v1.0
+
+Distribution of substantively modified versions of this document is prohibited without the explicit permission of the copyright holder.
+Distribution of the work or derivative of the work in any standard (paper) book form is prohibited unless prior permission is obtained from the copyright holder.

From b3654088ccc7d78f5ce45b1b3e68a4dd9e06658c Mon Sep 17 00:00:00 2001
From: Luke Dashjr 
Date: Fri, 23 Sep 2016 10:03:34 +0000
Subject: [PATCH 16/68] Assign BIP 134: Flexible Transactions

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

diff --git a/README.mediawiki b/README.mediawiki
index 0f0f9e1b..1b293212 100644
--- a/README.mediawiki
+++ b/README.mediawiki
@@ -476,6 +476,12 @@ Those proposing changes should consider that ultimately consent may rest with th
 | Standard
 | Draft
 |-
+| [[bip-0134.mediawiki|134]]
+| Flexible Transactions
+| Tom Zander
+| Standard
+| Draft
+|-
 | [[bip-0140.mediawiki|140]]
 | Normalized TXID
 | Christian Decker
diff --git a/bip-flexibleTransactions.mediawiki b/bip-0134.mediawiki
similarity index 99%
rename from bip-flexibleTransactions.mediawiki
rename to bip-0134.mediawiki
index 9b428ec8..280103f1 100644
--- a/bip-flexibleTransactions.mediawiki
+++ b/bip-0134.mediawiki
@@ -1,5 +1,5 @@
 
-  BIP: ??
+  BIP: 134
   Title: Flexible Transactions
   Author: Tom Zander 
   Status: Draft

From 3b4421b7886662e4c97fe6f2bd5d2ac0db362529 Mon Sep 17 00:00:00 2001
From: Luke Dashjr 
Date: Sat, 24 Sep 2016 00:36:32 +0000
Subject: [PATCH 17/68] bip-0002: Prohibit the OPL in new BIPs

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

diff --git a/bip-0002.mediawiki b/bip-0002.mediawiki
index 9d59405f..c5274c00 100644
--- a/bip-0002.mediawiki
+++ b/bip-0002.mediawiki
@@ -172,7 +172,10 @@ For a later version (eg, GPL 3.0), you would increase the version number (and re
     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.
+In the event that the licensing for the text or code is too complicated to express with a simple list of alternatives, the list should instead be replaced with the single term "Complex". In all cases, details of the licensing terms must be provided in the Copyright section of the BIP.
+
+BIPs are not required to be *exclusively* licensed under approved terms, and may also be licensed under unacceptable licenses *in addition to* at least one acceptable license.
+In this case, only the acceptable license(s) should be listed in the License and License-Code headers.
 
 ====Recommended licenses====
 
@@ -194,10 +197,14 @@ In addition, it is recommended that literal code included in the BIP be dual-lic
 * 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.
+====Not acceptable licenses====
+
+All licenses not explicitly included in the above lists are not acceptable terms for a Bitcoin Improvement Proposal unless a later BIP extends this one to add them.
+However, BIPs predating the acceptance of this BIP were allowed under other terms, and should use these abbreviation when no other license is granted:
+
+* OPL: [http://opencontent.org/openpub/ Open Publication License, version 1.0]
+* PD: Released into the public domain
 
 ===Rationale===
 

From 9f0ef24770f9286f6753c881edc3f6609398dc33 Mon Sep 17 00:00:00 2001
From: Luke Dashjr 
Date: Sat, 24 Sep 2016 02:48:30 +0000
Subject: [PATCH 18/68] bip-0002: Move BIP Comments to GitHub bitcoin/bips wiki

---
 bip-0002.mediawiki | 22 ++++++++++++++--------
 1 file changed, 14 insertions(+), 8 deletions(-)

diff --git a/bip-0002.mediawiki b/bip-0002.mediawiki
index c5274c00..57044050 100644
--- a/bip-0002.mediawiki
+++ b/bip-0002.mediawiki
@@ -102,18 +102,25 @@ 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].
+Each BIP should, in its preamble, link to a public 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.
 The comments page should generally only be used to post final comments for a completed BIP.
 If a BIP is not yet completed, reviewers should instead post on the applicable development mailing list thread to allow the BIP author(s) to address any concerns or problems pointed out by the review.
 
 Some BIPs receive exposure outside the development community prior to completion, and other BIPs might not be completed at all. To avoid a situation where critical BIP reviews may go unnoticed during this period, reviewers may, at their option, still post their review on the comments page, provided they first post it to the mailing list and plan to later remove or revise it as applicable based on the completed version. Such revisions should be made by editing the previous review and updating the timestamp. Reviews made prior to the complete version may be removed if they are no longer applicable and have not been updated in a timely manner (eg, within one month).
 
-Pages must be named after the full BIP number (eg, "BIP 0001") and placed in the "BIP Comments" namespace. For example, the link for BIP 1 will be https://en.bitcoin.it/wiki/BIP_Comments:BIP_0001 .
+Pages must be named after the full BIP number (eg, "BIP 0001") and placed in the "Comments" namespace.
+For example, the link for BIP 1 will be https://github.com/bitcoin/bips/wiki/Comments:BIP-0001 .
 
-In order to avoid possible abuse of Bitcoin Wiki moderation, BIPs may choose to list a second forum for BIP comments, in addition to the Bitcoin Wiki. In this case, the second forum's URI should be listed below the Bitcoin Wiki's URI.
+Comments posted to this wiki should use the following format:
 
-Summary tones may be chosen from the following, but this BIP does not intend to cover all possible nuances:
+     --, 
+
+BIPs may also choose to list a second forum for BIP comments, in addition to the BIPs wiki.
+In this case, the second forum's URI should be listed below the primary wiki's URI.
+
+After some time, the BIP itself may be updated with a summary tone of the comments.
+Summary tones may be chosen from the following, but this BIP does not intend to cover all possible nuances and other summaries may be used as needed:
 
 * No comments yet.
 * Unanimously Recommended for implementation
@@ -124,7 +131,7 @@ Summary tones may be chosen from the following, but this BIP does not intend to
 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
+    Comments-URI: https://github.com/bitcoin/bips/wiki/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).
@@ -139,8 +146,7 @@ What is the purpose of BIP comments?
 
 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.
+* Participants should freely refrain from commenting outside of their area of knowledge or expertise. However, comments should not be censored, and participation should be open to the public.
 
 ==BIP licensing==
 

From 5a066ea8fa3053bc4c72cf55b49b2e428e1ef416 Mon Sep 17 00:00:00 2001
From: Luke Dashjr 
Date: Sat, 24 Sep 2016 03:15:36 +0000
Subject: [PATCH 19/68] Copypaste BIP 1 into BIP 2 and aim for replacement

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

diff --git a/README.mediawiki b/README.mediawiki
index 1b293212..6f3ee08d 100644
--- a/README.mediawiki
+++ b/README.mediawiki
@@ -20,7 +20,7 @@ Those proposing changes should consider that ultimately consent may rest with th
 | Active
 |-
 | [[bip-0002.mediawiki|2]]
-| BIP Status and Comments
+| BIP process, revised
 | Luke Dashjr
 | Process
 | Deferred
diff --git a/bip-0002.mediawiki b/bip-0002.mediawiki
index 57044050..7297bc0f 100644
--- a/bip-0002.mediawiki
+++ b/bip-0002.mediawiki
@@ -1,20 +1,182 @@
 
   BIP: 2
-  Title: BIP Status and Comments
+  Title: BIP process, revised
   Author: Luke Dashjr 
   Status: Deferred
   Type: Process
   Created: 2016-02-03
+  Replaces: 1
 

 
 ==Abstract==
 
+BIP stands for Bitcoin Improvement Proposal. A BIP is a design document providing information to the Bitcoin community, or describing a new feature for Bitcoin or its processes or environment. The BIP should provide a concise technical specification of the feature and a rationale for the feature.
+
+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.
+
 This BIP describes objective criteria that can be used to determine when a BIP Status should be changed, to ensure it is a reliable metric documenting actual usage of the proposal. It also adds a way for final comment on completed BIPs, by adding to them a reference to a wiki page and summary of the tone thereof. Finally, it extends the list of allowable BIP licenses to include many more popular options.
 
 ==Copyright==
 
 This BIP is dual-licensed under the Open Publication License and BSD 2-clause license.
 
+==BIP 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.
+
+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.
+
+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. 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.
+
+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 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.
+
+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.
+
+A BIP can also be "Rejected". Perhaps after all is said and done it was not a good idea. It is still important to have a record of this fact.
+
+BIPs can also be superseded by a different BIP, rendering the original obsolete. This is intended for Informational BIPs, where version 2 of an API can replace version 1.
+
+The possible paths of the status of BIPs are as follows:
+
+
+
+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).
+
+===Transferring BIP Ownership===
+
+It occasionally becomes necessary to transfer ownership of BIPs to a new champion. In general, we'd like to retain the original author as a co-author of the transferred BIP, but that's really up to the original author. A good reason to transfer ownership is because the original author no longer has the time or interest in updating it or following through with the BIP process, or has fallen off the face of the 'net (i.e. is unreachable or not responding to email). A bad reason to transfer ownership is because you don't agree with the direction of the BIP. We try to build consensus around a BIP, but if that's not possible, you can always submit a competing BIP.
+
+If you are interested in assuming ownership of a BIP, send a message asking to take over, addressed to both the original author and the BIP editor. If the original author doesn't respond to email in a timely manner, the BIP editor will make a unilateral decision (it's not like such decisions can't be reversed :).
+
+===BIP Editors===
+
+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===
+
+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:
+
+* Read the BIP to check if it is ready: sound and complete. The ideas must make technical sense, even if they don't seem likely to be accepted.
+* The title should accurately describe the content.
+* Edit the BIP for language (spelling, grammar, sentence structure, etc.), markup (for reST BIPs), code style (examples should match BIP 8 & 7).
+
+If the BIP isn't ready, the editor will send it back to the author for revision, with specific instructions.
+
+Once the BIP is ready for the repository it should be submitted as a "pull request" to the [https://github.com/bitcoin/bips bitcoin/bips] repository on GitHub where it may get further feedback.
+
+The BIP editor will:
+
+* Assign a BIP number (almost always just the next available number, but sometimes it's a special/joke number, like 666 or 3141) in the pull request comments.
+
+* Merge the pull request when the author is ready (allowing some time for further peer review).
+
+* List the BIP in [[README.mediawiki]]
+
+* Send email back to the BIP author with next steps (post to bitcoin-dev mailing list).
+
+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.
+
+==BIP format and structure==
+
+===Specification===
+
+BIPs should be written in mediawiki or markdown format.
+
+Each BIP should have the following parts:
+
+* Preamble -- RFC 822 style headers containing meta-data about the BIP, including the BIP number, a short descriptive title (limited to a maximum of 44 characters), the names, and optionally the contact info for each author, etc.
+
+* Abstract -- a short (~200 word) description of the technical issue being addressed.
+
+* Copyright/public domain -- Each BIP must either be explicitly labelled as placed in the public domain (see this BIP as an example) or licensed under the Open Publication License.
+
+* Specification -- The technical specification should describe the syntax and semantics of any new feature. The specification should be detailed enough to allow competing, interoperable implementations for any of the current Bitcoin platforms (Satoshi, BitcoinJ, bitcoin-js, libbitcoin).
+
+* Motivation -- The motivation is critical for BIPs that want to change the Bitcoin protocol. It should clearly explain why the existing protocol specification is inadequate to address the problem that the BIP solves. BIP submissions without sufficient motivation may be rejected outright.
+
+* Rationale -- The rationale fleshes out the specification by describing what motivated the design and why particular design decisions were made. It should describe alternate designs that were considered and related work, e.g. how the feature is supported in other languages.
+
+* The rationale should provide evidence of consensus within the community and discuss important objections or concerns raised during discussion.
+
+* Backwards Compatibility -- All BIPs that introduce backwards incompatibilities must include a section describing these incompatibilities and their severity. The BIP must explain how the author proposes to deal with these incompatibilities. BIP submissions without a sufficient backwards compatibility treatise may be rejected outright.
+
+* Reference Implementation -- The reference implementation must be completed before any BIP is given status "Final", but it need not be completed before the BIP is accepted. It is better to finish the specification and rationale first and reach consensus on it before writing code.
+
+* The final implementation must include test code and documentation appropriate for the Bitcoin protocol.
+
+====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.
+
+
+  BIP: 
+  Title: 
+  Author: 
+* Discussions-To: 
+  Status: 
+  Type: 
+  Created: 
+* Post-History: 
+* Replaces: 
+* Superseded-By: 
+* Resolution: 
+

+
+The Author header lists the names, and optionally the email addresses of all the authors/owners of the BIP. The format of the Author header value must be
+
+  Random J. User 
+
+if the email address is included, and just
+
+  Random J. User
+
+if the address is not given.
+
+If there are multiple authors, each should be on a separate line following RFC 2822 continuation line conventions.
+
+Note: The Resolution header is required for Standards Track BIPs only. It contains a URL that should point to an email message or other web resource where the pronouncement about the BIP is made.
+
+While a BIP is in private discussions (usually during the initial Draft phase), a Discussions-To header will indicate the mailing list or URL where the BIP is being discussed. No Discussions-To header is necessary if the BIP is being discussed privately with the author, or on the bitcoin email mailing lists.
+
+The Type header specifies the type of BIP: Standards Track, Informational, or Process.
+
+The Created header records the date that the BIP was assigned a number, while Post-History is used to record the dates of when new versions of the BIP are posted to bitcoin mailing lists. Both headers should be in yyyy-mm-dd format, e.g. 2001-08-14.
+
+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. 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").
+
+==BIP types==
+
+There are three kinds of BIP:
+
+* A Standards Track BIP describes any change that affects most or all Bitcoin implementations, such as a change to the network protocol, a change in block or transaction validity rules, or any change or addition that affects the interoperability of applications using Bitcoin.
+* 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. Informational BIPs do not necessarily represent a Bitcoin community consensus or recommendation, so users and implementors are free to ignore Informational BIPs or follow their advice.
+* A Process BIP describes a process surrounding Bitcoin, or proposes a change to (or an event in) a process. Process BIPs are like Standards Track BIPs but apply to areas other than the Bitcoin protocol itself. They may propose an implementation, but not to Bitcoin's codebase; they often require community consensus; unlike Informational BIPs, they are more than recommendations, and users are typically not free to ignore them. Examples include procedures, guidelines, changes to the decision-making process, and changes to the tools or environment used in Bitcoin development. Any meta-BIP is also considered a Process BIP.
+
 ==BIP status field==
 
 ===Specification===
@@ -229,6 +391,10 @@ 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.
 
+==History==
+
+This document was derived heavily from Python's PEP-0001. In many places text was simply copied and modified. Although the PEP-0001 text was written by Barry Warsaw, Jeremy Hylton, and David Goodger, they are not responsible for its use in the Bitcoin Improvement Process, and should not be bothered with technical questions specific to Bitcoin or the BIP process. Please direct all comments to the BIP editors or the Bitcoin development mailing list.
+
 ==See Also==
 
 * [[bip-0001.mediawiki|BIP 1: BIP Purpose and Guidelines]]

From f1ed5afd1fa4e4ea12c81883947c45bb18aaeab2 Mon Sep 17 00:00:00 2001
From: Luke Dashjr 
Date: Sat, 24 Sep 2016 03:23:08 +0000
Subject: [PATCH 20/68] bip-0002: Revise for BIP 1 replacement

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

diff --git a/bip-0002.mediawiki b/bip-0002.mediawiki
index 7297bc0f..3252d77d 100644
--- a/bip-0002.mediawiki
+++ b/bip-0002.mediawiki
@@ -10,13 +10,13 @@
 
 ==Abstract==
 
-BIP stands for Bitcoin Improvement Proposal. A BIP is a design document providing information to the Bitcoin community, or describing a new feature for Bitcoin or its processes or environment. The BIP should provide a concise technical specification of the feature and a rationale for the feature.
+A Bitcoin Improvement Proposal (BIP) is a design document providing information to the Bitcoin community, or describing a new feature for Bitcoin or its processes or environment. The BIP should provide a concise technical specification of the feature and a rationale for the feature.
 
 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.
 
-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.
+This particular BIP replaces BIP 1 with a more well-defined and clear process.
 
 ==Copyright==
 

From deb036798acc61023636bae1886718e3386d4efb Mon Sep 17 00:00:00 2001
From: Luke Dashjr 
Date: Sat, 24 Sep 2016 03:24:28 +0000
Subject: [PATCH 21/68] bip-0002: Drop BitcoinTalk recommendation

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

diff --git a/bip-0002.mediawiki b/bip-0002.mediawiki
index 3252d77d..59b6af04 100644
--- a/bip-0002.mediawiki
+++ b/bip-0002.mediawiki
@@ -24,7 +24,8 @@ This BIP is dual-licensed under the Open Publication License and BSD 2-clause li
 
 ==BIP 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.
+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 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 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.
 

From f0999cdcc1461c44c4f45f33d5c7b768aa80a906 Mon Sep 17 00:00:00 2001
From: Luke Dashjr 
Date: Sat, 24 Sep 2016 03:44:24 +0000
Subject: [PATCH 22/68] bip-0002: Language improvements for BIP workflow

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

diff --git a/bip-0002.mediawiki b/bip-0002.mediawiki
index 59b6af04..dc53d01a 100644
--- a/bip-0002.mediawiki
+++ b/bip-0002.mediawiki
@@ -25,25 +25,37 @@ This BIP is dual-licensed under the Open Publication License and BSD 2-clause li
 ==BIP 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 is the best way to go about this.
+Small enhancements or patches to a particular piece of software often don't require standardisation between multiple projects; these don't need a BIP and should be injected into the relevant project-specific development workflow with a patch submission to the applicable issue tracker.
+Additionally, many ideas have been brought forward for changing Bitcoin that have been rejected for various reasons.
+The first step should be to search past discussions to see if an idea has been considered before, and if so, what issues arose in its progression.
+After investigating past work, the best way to proceed is by posting about the new idea to the [https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev Bitcoin development mailing list].
 
-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.
+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.
+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.
 
-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.
+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 development 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 submitted to the [https://github.com/bitcoin/bips BIPs git repository] as a pull request.
+This draft must be written in BIP style as described below, and named with an alias such as "bip-johndoe-infinitebitcoins" until the editor has assigned it a BIP number (authors MUST NOT self-assign BIP numbers).
 
 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. 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.
+When the BIP draft is complete, the BIP editor will assign the BIP a number, label it as Standards Track, Informational, or Process, and merge the pull request to the BIPs git repository.
+The BIP editor will not unreasonably reject a BIP.
+Reasons for rejecting BIPs 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.
 
-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.
+The BIP author may update the Draft as necessary in the git repository. Updates to drafts should also be submitted by the author as pull requests.
 
-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.
+Standards Track BIPs consist of two parts, a design document and a reference implementation.
+The reference implementation is not required to be begun until the BIP is accepted, unless having such an 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.
 
 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".
 
@@ -55,9 +67,9 @@ BIPs can also be superseded by a different BIP, rendering the original obsolete.
 
 The possible paths of the status of BIPs are as follows:
 
-
+
 
-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).
+Some Informational and Process BIPs may also have a status of "Active" if they are never meant to be completed. E.g. BIP 2 (this BIP).
 
 ===Transferring BIP Ownership===
 

From efbbe30cce96a5fd0d6f30d6cb9bbbaef5bf521b Mon Sep 17 00:00:00 2001
From: Luke Dashjr 
Date: Sat, 24 Sep 2016 03:51:50 +0000
Subject: [PATCH 23/68] bip-0002: Clarify and update BIP editor role

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

diff --git a/bip-0002.mediawiki b/bip-0002.mediawiki
index dc53d01a..783ecc55 100644
--- a/bip-0002.mediawiki
+++ b/bip-0002.mediawiki
@@ -83,29 +83,30 @@ The current BIP editor is Luke Dashjr who can be contacted at [[mailto:luke_bipe
 
 ===BIP Editor Responsibilities & Workflow===
 
-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.
+The BIP editor subscribes to the Bitcoin development mailing list.
+Off-list 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:
 
 * Read the BIP to check if it is ready: sound and complete. The ideas must make technical sense, even if they don't seem likely to be accepted.
 * The title should accurately describe the content.
-* Edit the BIP for language (spelling, grammar, sentence structure, etc.), markup (for reST BIPs), code style (examples should match BIP 8 & 7).
+* The BIP draft must have been sent to the Bitcoin development mailing list for discussion.
+* Motivation and backward compatibility (when applicable) must be addressed.
+* Licensing terms must be acceptable for BIPs.
 
 If the BIP isn't ready, the editor will send it back to the author for revision, with specific instructions.
 
-Once the BIP is ready for the repository it should be submitted as a "pull request" to the [https://github.com/bitcoin/bips bitcoin/bips] repository on GitHub where it may get further feedback.
+Once the BIP is ready for the repository it should be submitted as a "pull request" to the [https://github.com/bitcoin/bips BIPs git repository] where it may get further feedback.
 
 The BIP editor will:
 
-* Assign a BIP number (almost always just the next available number, but sometimes it's a special/joke number, like 666 or 3141) in the pull request comments.
+* Assign a BIP number in the pull request.
 
-* Merge the pull request when the author is ready (allowing some time for further peer review).
+* Merge the pull request when it is ready.
 
 * List the BIP in [[README.mediawiki]]
 
-* Send email back to the BIP author with next steps (post to bitcoin-dev mailing list).
-
-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.
+The BIP editors are intended to fulfill administrative and editorial responsibilities. The BIP editors monitor BIP changes, and update BIP headers as appropriate.
 
 ==BIP format and structure==
 

From c864f641fa4e7a7f1f048d8b7546647b327c3b89 Mon Sep 17 00:00:00 2001
From: Luke Dashjr 
Date: Sat, 24 Sep 2016 03:52:23 +0000
Subject: [PATCH 24/68] bip-0002: Disallow markdown format

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

diff --git a/bip-0002.mediawiki b/bip-0002.mediawiki
index 783ecc55..2fecad40 100644
--- a/bip-0002.mediawiki
+++ b/bip-0002.mediawiki
@@ -112,7 +112,7 @@ The BIP editors are intended to fulfill administrative and editorial responsibil
 
 ===Specification===
 
-BIPs should be written in mediawiki or markdown format.
+BIPs should be written in mediawiki format.
 
 Each BIP should have the following parts:
 

From db70f458c81946064f580061bb2c9dd0af13a425 Mon Sep 17 00:00:00 2001
From: Luke Dashjr 
Date: Sat, 24 Sep 2016 03:59:16 +0000
Subject: [PATCH 25/68] bip-0002: Reduce unnecessary duplication in summary of
 BIP parts

---
 bip-0002.mediawiki | 20 ++++++++------------
 1 file changed, 8 insertions(+), 12 deletions(-)

diff --git a/bip-0002.mediawiki b/bip-0002.mediawiki
index 2fecad40..4fed0399 100644
--- a/bip-0002.mediawiki
+++ b/bip-0002.mediawiki
@@ -116,25 +116,21 @@ BIPs should be written in mediawiki format.
 
 Each BIP should have the following parts:
 
-* Preamble -- RFC 822 style headers containing meta-data about the BIP, including the BIP number, a short descriptive title (limited to a maximum of 44 characters), the names, and optionally the contact info for each author, etc.
+* Preamble -- Headers containing metadata about the BIP ([[#Preamble|see below]]).
 
-* Abstract -- a short (~200 word) description of the technical issue being addressed.
+* Abstract -- A short (~200 word) description of the technical issue being addressed.
 
-* Copyright/public domain -- Each BIP must either be explicitly labelled as placed in the public domain (see this BIP as an example) or licensed under the Open Publication License.
+* Copyright -- The BIP must be explicitly licensed under acceptable copyright terms ([[#TODO|see below]]).
 
-* Specification -- The technical specification should describe the syntax and semantics of any new feature. The specification should be detailed enough to allow competing, interoperable implementations for any of the current Bitcoin platforms (Satoshi, BitcoinJ, bitcoin-js, libbitcoin).
+* Specification -- The technical specification should describe the syntax and semantics of any new feature. The specification should be detailed enough to allow competing, interoperable implementations for any of the current Bitcoin platforms.
 
-* Motivation -- The motivation is critical for BIPs that want to change the Bitcoin protocol. It should clearly explain why the existing protocol specification is inadequate to address the problem that the BIP solves. BIP submissions without sufficient motivation may be rejected outright.
+* Motivation -- The motivation is critical for BIPs that want to change the Bitcoin protocol. It should clearly explain why the existing protocol is inadequate to address the problem that the BIP solves.
 
-* Rationale -- The rationale fleshes out the specification by describing what motivated the design and why particular design decisions were made. It should describe alternate designs that were considered and related work, e.g. how the feature is supported in other languages.
+* Rationale -- The rationale fleshes out the specification by describing what motivated the design and why particular design decisions were made. It should describe alternate designs that were considered and related work. The rationale should provide evidence of consensus within the community and discuss important objections or concerns raised during discussion.
 
-* The rationale should provide evidence of consensus within the community and discuss important objections or concerns raised during discussion.
+* Backwards compatibility -- All BIPs that introduce backwards incompatibilities must include a section describing these incompatibilities and their severity. The BIP must explain how the author proposes to deal with these incompatibilities.
 
-* Backwards Compatibility -- All BIPs that introduce backwards incompatibilities must include a section describing these incompatibilities and their severity. The BIP must explain how the author proposes to deal with these incompatibilities. BIP submissions without a sufficient backwards compatibility treatise may be rejected outright.
-
-* Reference Implementation -- The reference implementation must be completed before any BIP is given status "Final", but it need not be completed before the BIP is accepted. It is better to finish the specification and rationale first and reach consensus on it before writing code.
-
-* The final implementation must include test code and documentation appropriate for the Bitcoin protocol.
+* Reference implementation -- The reference implementation must be completed before any BIP is given status "Final", but it need not be completed before the BIP is accepted. It is better to finish the specification and rationale first and reach consensus on it before writing code. The final implementation must include test code and documentation appropriate for the Bitcoin protocol.
 
 ====BIP header preamble====
 

From 7027de2882c4788439ea7871c55cb6b11c4b416c Mon Sep 17 00:00:00 2001
From: Luke Dashjr 
Date: Sat, 24 Sep 2016 04:02:54 +0000
Subject: [PATCH 26/68] bip-0002: Expand on preamble headers for BIP/Title

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

diff --git a/bip-0002.mediawiki b/bip-0002.mediawiki
index 4fed0399..632a112f 100644
--- a/bip-0002.mediawiki
+++ b/bip-0002.mediawiki
@@ -116,7 +116,7 @@ BIPs should be written in mediawiki format.
 
 Each BIP should have the following parts:
 
-* Preamble -- Headers containing metadata about the BIP ([[#Preamble|see below]]).
+* Preamble -- Headers containing metadata about the BIP ([[#BIP header preamble|see below]]).
 
 * Abstract -- A short (~200 word) description of the technical issue being addressed.
 
@@ -137,8 +137,8 @@ Each BIP should have the following parts:
 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.
 
 
-  BIP: 
-  Title: 
+  BIP: 
+  Title: 
   Author: 
 * Discussions-To: 
   Status: 
Date: Sat, 24 Sep 2016 04:06:49 +0000
Subject: [PATCH 27/68] bip-0002: Add new preamble headers for comments/license

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

diff --git a/bip-0002.mediawiki b/bip-0002.mediawiki
index 632a112f..14877a72 100644
--- a/bip-0002.mediawiki
+++ b/bip-0002.mediawiki
@@ -141,10 +141,14 @@ Each BIP must begin with an RFC 822 style header preamble. The headers must appe
   Title: 
   Author: 
 * Discussions-To: 
+* Comments-Summary: 
+  Comments-URI: 
   Status: 
   Type: 
   Created: 
+  License: 
+* License-Code: 
 * Post-History: 
 * Replaces: 
 * Superseded-By: 

From 9b040c5042a21a5bee06df4974d32cf10545c1c6 Mon Sep 17 00:00:00 2001
From: Luke Dashjr 
Date: Sat, 24 Sep 2016 04:07:56 +0000
Subject: [PATCH 28/68] bip-0002: Require email addresses for authors

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

diff --git a/bip-0002.mediawiki b/bip-0002.mediawiki
index 14877a72..9a05fed4 100644
--- a/bip-0002.mediawiki
+++ b/bip-0002.mediawiki
@@ -139,7 +139,7 @@ Each BIP must begin with an RFC 822 style header preamble. The headers must appe
 
   BIP: 
   Title: 
-  Author: 
+  Author: 
 * Discussions-To: 
 * Comments-Summary: 
   Comments-URI: 
@@ -155,16 +155,11 @@ Each BIP must begin with an RFC 822 style header preamble. The headers must appe
 * Resolution: 
 

 
-The Author header lists the names, and optionally the email addresses of all the authors/owners of the BIP. The format of the Author header value must be
+The Author header lists the names and email addresses of all the authors/owners of the BIP.
+The format of the Author header value must be
 
   Random J. User 
 
-if the email address is included, and just
-
-  Random J. User
-
-if the address is not given.
-
 If there are multiple authors, each should be on a separate line following RFC 2822 continuation line conventions.
 
 Note: The Resolution header is required for Standards Track BIPs only. It contains a URL that should point to an email message or other web resource where the pronouncement about the BIP is made.

From 7ca7445c80016fb7569903569338abb802ae742c Mon Sep 17 00:00:00 2001
From: Luke Dashjr 
Date: Sat, 24 Sep 2016 04:08:58 +0000
Subject: [PATCH 29/68] bip-0002: Drop unused and inapplicable Resolution
 header from preamble

---
 bip-0002.mediawiki | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/bip-0002.mediawiki b/bip-0002.mediawiki
index 9a05fed4..83b027cb 100644
--- a/bip-0002.mediawiki
+++ b/bip-0002.mediawiki
@@ -152,7 +152,6 @@ Each BIP must begin with an RFC 822 style header preamble. The headers must appe
 * Post-History: 
 * Replaces: 
 * Superseded-By: 
-* Resolution: 
 

 
 The Author header lists the names and email addresses of all the authors/owners of the BIP.
@@ -162,8 +161,6 @@ The format of the Author header value must be
 
 If there are multiple authors, each should be on a separate line following RFC 2822 continuation line conventions.
 
-Note: The Resolution header is required for Standards Track BIPs only. It contains a URL that should point to an email message or other web resource where the pronouncement about the BIP is made.
-
 While a BIP is in private discussions (usually during the initial Draft phase), a Discussions-To header will indicate the mailing list or URL where the BIP is being discussed. No Discussions-To header is necessary if the BIP is being discussed privately with the author, or on the bitcoin email mailing lists.
 
 The Type header specifies the type of BIP: Standards Track, Informational, or Process.

From 44f85187fe06444d83d9a7250eedb66ebdb6bde2 Mon Sep 17 00:00:00 2001
From: Luke Dashjr 
Date: Sat, 24 Sep 2016 04:11:10 +0000
Subject: [PATCH 30/68] bip-0002: Allow Post-History header to be a link as
 with BIPs 99, 122, and 124

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

diff --git a/bip-0002.mediawiki b/bip-0002.mediawiki
index 83b027cb..54554195 100644
--- a/bip-0002.mediawiki
+++ b/bip-0002.mediawiki
@@ -149,7 +149,7 @@ Each BIP must begin with an RFC 822 style header preamble. The headers must appe
   Created: 
   License: 
 * License-Code: 
-* Post-History: 
+* Post-History: 
 * Replaces: 
 * Superseded-By: 
 

@@ -165,7 +165,9 @@ While a BIP is in private discussions (usually during the initial Draft phase),
 
 The Type header specifies the type of BIP: Standards Track, Informational, or Process.
 
-The Created header records the date that the BIP was assigned a number, while Post-History is used to record the dates of when new versions of the BIP are posted to bitcoin mailing lists. Both headers should be in yyyy-mm-dd format, e.g. 2001-08-14.
+The Created header records the date that the BIP was assigned a number, while Post-History is used to record when new versions of the BIP are posted to bitcoin mailing lists.
+Dates should be in yyyy-mm-dd format, e.g. 2001-08-14.
+Post-History is permitted to be a link to a specific thread in a mailing list archive.
 
 BIPs may have a Requires header, indicating the BIP numbers that this BIP depends on.
 

From 0c203dcfb6399ae98a3e7619ead1ec899ee5f736 Mon Sep 17 00:00:00 2001
From: Luke Dashjr 
Date: Sat, 24 Sep 2016 04:48:06 +0000
Subject: [PATCH 31/68] bip-0002: Allow non-images in bip-XXXX subdirectory

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

diff --git a/bip-0002.mediawiki b/bip-0002.mediawiki
index 54554195..0cab460d 100644
--- a/bip-0002.mediawiki
+++ b/bip-0002.mediawiki
@@ -175,7 +175,7 @@ BIPs may also have a Superseded-By header indicating that a BIP has been rendere
 
 ====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").
+BIPs may include auxiliary files such as diagrams. Auxiliary files should be included in a subdirectory for that BIP, or 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").
 
 ==BIP types==
 

From c59cfdb894f3ed1f7d068b5a53eac860674bb1df Mon Sep 17 00:00:00 2001
From: Luke Dashjr 
Date: Sat, 24 Sep 2016 05:05:54 +0000
Subject: [PATCH 32/68] bip-0002: Remove/merge old BIP 1 Status stuff

---
 bip-0002.mediawiki | 27 +++++++--------------------
 1 file changed, 7 insertions(+), 20 deletions(-)

diff --git a/bip-0002.mediawiki b/bip-0002.mediawiki
index 0cab460d..593037e3 100644
--- a/bip-0002.mediawiki
+++ b/bip-0002.mediawiki
@@ -51,25 +51,7 @@ 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 should also be submitted by the author as pull requests.
-
-Standards Track BIPs consist of two parts, a design document and a reference implementation.
-The reference implementation is not required to be begun until the BIP is accepted, unless having such an 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.
-
-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.
-
-A BIP can also be "Rejected". Perhaps after all is said and done it was not a good idea. It is still important to have a record of this fact.
-
-BIPs can also be superseded by a different BIP, rendering the original obsolete. This is intended for Informational BIPs, where version 2 of an API can replace version 1.
-
-The possible paths of the status of BIPs are as follows:
-
-
-
-Some Informational and Process BIPs may also have a status of "Active" if they are never meant to be completed. E.g. BIP 2 (this BIP).
+The BIP author may update the draft as necessary in the git repository. Updates to drafts should also be submitted by the author as pull requests.
 
 ===Transferring BIP Ownership===
 
@@ -181,7 +163,7 @@ BIPs may include auxiliary files such as diagrams. Auxiliary files should be inc
 
 There are three kinds of BIP:
 
-* A Standards Track BIP describes any change that affects most or all Bitcoin implementations, such as a change to the network protocol, a change in block or transaction validity rules, or any change or addition that affects the interoperability of applications using Bitcoin.
+* A Standards Track BIP describes any change that affects most or all Bitcoin implementations, such as a change to the network protocol, a change in block or transaction validity rules, or any change or addition that affects the interoperability of applications using Bitcoin. Standards Track BIPs consist of two parts, a design document and a reference implementation.
 * 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. Informational BIPs do not necessarily represent a Bitcoin community consensus or recommendation, so users and implementors are free to ignore Informational BIPs or follow their advice.
 * A Process BIP describes a process surrounding Bitcoin, or proposes a change to (or an event in) a process. Process BIPs are like Standards Track BIPs but apply to areas other than the Bitcoin protocol itself. They may propose an implementation, but not to Bitcoin's codebase; they often require community consensus; unlike Informational BIPs, they are more than recommendations, and users are typically not free to ignore them. Examples include procedures, guidelines, changes to the decision-making process, and changes to the tools or environment used in Bitcoin development. Any meta-BIP is also considered a Process BIP.
 
@@ -189,7 +171,12 @@ There are three kinds of BIP:
 
 ===Specification===
 
+The possible paths of the status of BIPs are as follows:
+
+
+
 Champions of a BIP may decide on their own to change the status between Draft, Deferred, or Withdrawn.
+The BIP editor may also change the status to Deferred when no progress is being made on the BIP.
 
 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.
 

From f2e6bbd2190060e2e9c769d8e2d5d7d2c4e30eb1 Mon Sep 17 00:00:00 2001
From: Luke Dashjr 
Date: Sat, 24 Sep 2016 05:09:20 +0000
Subject: [PATCH 33/68] bip-0002: Remove useless History section

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

diff --git a/bip-0002.mediawiki b/bip-0002.mediawiki
index 593037e3..a98be7b9 100644
--- a/bip-0002.mediawiki
+++ b/bip-0002.mediawiki
@@ -386,10 +386,6 @@ 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.
 
-==History==
-
-This document was derived heavily from Python's PEP-0001. In many places text was simply copied and modified. Although the PEP-0001 text was written by Barry Warsaw, Jeremy Hylton, and David Goodger, they are not responsible for its use in the Bitcoin Improvement Process, and should not be bothered with technical questions specific to Bitcoin or the BIP process. Please direct all comments to the BIP editors or the Bitcoin development mailing list.
-
 ==See Also==
 
 * [[bip-0001.mediawiki|BIP 1: BIP Purpose and Guidelines]]

From 70747425d885a8b4a00f31dd64e682ecf751aaae Mon Sep 17 00:00:00 2001
From: Luke Dashjr 
Date: Sat, 24 Sep 2016 05:10:57 +0000
Subject: [PATCH 34/68] bip-0002: Mention OPL problems

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

diff --git a/bip-0002.mediawiki b/bip-0002.mediawiki
index a98be7b9..c9e817dc 100644
--- a/bip-0002.mediawiki
+++ b/bip-0002.mediawiki
@@ -375,6 +375,7 @@ BIP 1 allowed the Open Publication License or releasing into the public domain;
 
 * 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.
+* The OPL license terms allowed for the author to prevent publication and derived works, which was widely considered inappropriate for Bitcoin standards.
 * Public domain is not universally recognised as a legitimate action, thus it is inadvisable.
 
 Why are there software licenses included?

From ad4f559976b653f1ed3702e9df8876c49d9e0cc6 Mon Sep 17 00:00:00 2001
From: Luke Dashjr 
Date: Sat, 24 Sep 2016 05:19:34 +0000
Subject: [PATCH 35/68] bip-0002: Add summary of changes vs BIP 1

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

diff --git a/bip-0002.mediawiki b/bip-0002.mediawiki
index c9e817dc..b73f2d45 100644
--- a/bip-0002.mediawiki
+++ b/bip-0002.mediawiki
@@ -387,6 +387,18 @@ 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.
 
+==Changes from BIP 1==
+
+* Acceptable licenses are redefined entirely, allowing a wide variety of open licenses, while prohibiting the problematic older choices.
+* An implementation is now required (when applicable) before BIPs can proceed to Accepted Status.
+* The License preamble headers have been added.
+* BIP Comments are newly introduced.
+* Non-image auxiliary files are permitted in the bip-XXXX subdirectory.
+* The Post-History header may be provided as a link instead of a simple date.
+* The Resolution header has been dropped, as it is not applicable to a decentralised system where no authority exists to make final decisions.
+* Email addresses are now required for authors.
+* Markdown format is no longer permitted for BIPs.
+
 ==See Also==
 
 * [[bip-0001.mediawiki|BIP 1: BIP Purpose and Guidelines]]

From 3f4750f0b9c7464a47429e9ed18387eddfd78256 Mon Sep 17 00:00:00 2001
From: Luke Dashjr 
Date: Sat, 24 Sep 2016 05:20:14 +0000
Subject: [PATCH 36/68] bip-0002: Link Copyright "see below"

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

diff --git a/bip-0002.mediawiki b/bip-0002.mediawiki
index b73f2d45..899bc72a 100644
--- a/bip-0002.mediawiki
+++ b/bip-0002.mediawiki
@@ -102,7 +102,7 @@ Each BIP should have the following parts:
 
 * Abstract -- A short (~200 word) description of the technical issue being addressed.
 
-* Copyright -- The BIP must be explicitly licensed under acceptable copyright terms ([[#TODO|see below]]).
+* Copyright -- The BIP must be explicitly licensed under acceptable copyright terms ([[#BIP licensing|see below]]).
 
 * Specification -- The technical specification should describe the syntax and semantics of any new feature. The specification should be detailed enough to allow competing, interoperable implementations for any of the current Bitcoin platforms.
 

From e528af13b7eb1f728b6abef6839ea92a6bbdf16b Mon Sep 17 00:00:00 2001
From: Luke Dashjr 
Date: Sat, 24 Sep 2016 05:57:31 +0000
Subject: [PATCH 37/68] bip-0002: Replace Status chart with SVG

---
 bip-0002.mediawiki   |   2 +-
 bip-0002/process.png | Bin 0 -> 15586 bytes
 bip-0002/process.svg |  52 +++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 53 insertions(+), 1 deletion(-)
 create mode 100644 bip-0002/process.png
 create mode 100644 bip-0002/process.svg

diff --git a/bip-0002.mediawiki b/bip-0002.mediawiki
index 899bc72a..7c0c557e 100644
--- a/bip-0002.mediawiki
+++ b/bip-0002.mediawiki
@@ -173,7 +173,7 @@ There are three kinds of BIP:
 
 The possible paths of the status of BIPs are as follows:
 
-
+
 
 Champions of a BIP may decide on their own to change the status between Draft, Deferred, or Withdrawn.
 The BIP editor may also change the status to Deferred when no progress is being made on the BIP.
diff --git a/bip-0002/process.png b/bip-0002/process.png
new file mode 100644
index 0000000000000000000000000000000000000000..6b1925ec88fa768c0afa1816bab8230da51832cf
GIT binary patch
literal 15586
zcmcJ$2{e`c-#23pvH|D3hnXRY&|^_;WT+gf)!?rZOTUBBV`{Y<|g!$bQvZRFWV5X2_k{ZwOu
zSjB{Ye_X#7f1AD!euNi#S4~}$_4wnx-kOG=H#qG#b0r9-YVtq27zrj`f)FHhsTwAp
zal>sMp6t!@>qbZZo;|#O_3a4t_1CvG5slPG!jsEvbj5N{f}JRaV_uP&)+wX@E*jdD
zXrW`$8~6B68nOvKJSujTMKDZV^PpqN$O!XAoo@$UZ`}4^d`ab#%1hgiaT9-)K9=57
zbX_Yb^uPa;d?x*UI-5zik)au<{Qw~uy5QIMW+_oTPjkjEv(}!SorNWdfsxUBy36n$
z7eD{4=g(z1i1<{i9G1T;G2AnL_}k2RVWo$49sSz1nrXX!+!DXq*=c$G#tkzi#*pr1
zi_6X{zn3lUaTKj&>hEF4jfj7`tH45`ME>}nzwj&5nOxpw^@h>>g_FkIQ`5|@zP>dU
z78ap=imV9<3Bq4J&YTevIe7m%jkaDvNvXSIWqHr3%Y8Adf5OERK7Tg!p8jE*el(l^
zj`T^p0jK&$S68nS5)>pH%a;mMwI1&5w^*6yI+UPd);rH-;Y|rx$NZ*b8s1+U5N?j!A4-e3Prk^f$v`{eif+cz!&-`Rht
zkErwfdoJ?f|A!TI`0^^nGfn;ZRy)>H+mLRwb?9e7CUyQ%uuWfm%=%56YI1GfMclo6
zZonyFzrDTW;?h!%*VG{EdB0Bydv*NySe6>zMu}2*c!Gz9hBRYKOI1`nM~R0IAHHxO
zJ|0x-Iy-urZ?9K=^@7+zj=#aHiSIvtoc{eWUdN{BV%zJ?>{r2xuD_D(nltY1uzIs=
zc$cy=@0IDH%KYHGrO0s~KEb)Og3iA61;z2z
z+~d@$`FFXwxlUu<+SazVCzRMTs)HX$n`eL9DkZh)>({TTT!w3m|6vP!?dj=hxiCHK
z`M3Bt3m;#oQHoAwTiX`GY53=E1qFp9oiHA9tZr>lz8Sf7UoxJP@PGgQ0H2}@{kLZ)
z1M>2A-IqIm?M)c3R+g_@rHGOePf$=03+4Ow?}Fmu8%<43UtIdb>ANtzhp50*7#7$a
zY05alpsK2RXO5D7fML@nZ5^GpujYR7=AUa=_0K>5Xp1n-{B5i1stSyZi15efrW{T?
zWccKOh5MD|#mjLjms!PQHl8eT*B<^^aBz^e{$spyV4m$K%`DRttw1I$m;|GE++TG~
z&BKdrFP|3_)GRM8P_}FddwlRgvd_Y_UPokP2(bjfS
zmmgnqBQ%t8c79%H*Dkgbh4xqVQZ>^K#T(|G{h--We0f6TP`uKO>S`)hfEAgY`t+2;nr-IU^!
z#$Rn_+1|J0*IO6a`0S)Ig)-1lUY_1;SM0M;s9T1+(VrS@)=o7Jii(ONA~2ZmmKJ7W
zl+4V`c3x~%pc6cjVM56=mEZ}}c{M*Mky3cEd+t)nC3GewvjfyloqGXn5G>_4N$~D*;`myx>k|$r9h+XLk+f)7R+fkvdTggv7V`a6~uHbn7@vOy}@|E2`
zRd?+=tP{>Jh2OQdwe=PMPB{E=^+@^3E2FlrSts-ZnYJXfaY+grITwR5C?ldOqP_#VW*3}sf`pvX?tWxKc
zJchdM@wYWHO4MK@F*n;2E-Wmptw*UuXpw=%2{<0Y20q^7KVA}%hj
z_ltoV2PHB_;wawo>w#nFVA~64Eqe!t)P3Rnx8vd@*9K_FJGM(=E+W5K_?>*h#mD#5
zKKt7rVJWGD%kmZp~~{-OGzu}t6atjxGuP(VpZ33fvL
z%}u=2>~H#ddcjzY`<_01x((y-MA`M%ft=jj+n4@)72DuwYI=uJK-HY6!;?q9Jiu3f
zwN{u(NC=Ci``53>-qSNPToMuzW-pu`8kK!XGkEvZEHCu-%~hx!jcEn~eG@3qYy8PJ
zp)++?A$lY=e|p8CrEmj*0)$o-9nEf(+1!|CYmnlVvM-zys~Gilr+A{G>thtQ{rL7r
zj~>zD*JymO!QkW)>T=(mXXE4z@RTfOQZWU
zzBxr=^}T!dx_|!`y>;u>?U)#0A#G8nHE%x$b4Y~NZ(1ARHqfZev*+T|{Jm$Y*XI-#
z-pM?g&C@J3yAl+nRr7NtG4)zCS(`-O#VNW{AN5z$`S-girA)gIegB6*RiTQVDEBS%
zUYhzQ;*+T6cZ%q_UM?iU6mvGTO5n$jA6+PoB7In2^7F09+6-jbtVp?%wdZ21x}BZ)
z&Ye3AvySiHCMp`MSIWs5T7RWjetqg>o0g{LXIyQw7?PPOq2%#56s52Wl`-8ki^qST
z)%u@>4w<2!#AI#i*%`TI37)XEwx1HTO-(uHXGR=NYU}GawiG%XE^I6DkRg%|K9JwP
zf4^)-3tFT7kK8p}(&p+YcG2UwHQun)=XrTr*{8~$Tfb!`+r-tYSG9d>uPq-hu(N5j
z=y?;CgSA;*TbqKiNTboz-`$bw`t#?4Nj4@=yU;@O#Y*g9tJ+(;#jY&R{T3)`8||tJ
zQ{@U}czI>!nX$Ze9Sh-4BWw45U0n_GiFfUyOM0EiD}J(DP>2>5wtI6$H;@%}Yt%f7
zab=)@FO96~sm7HxHEXan_8&U*OK_i;$oRy>*q`ij5>%Whx_G3%th6*DF)W|L0YF*
z!e{5^#4d##{%nzHnic$%O+bLz!@~pJh=V6KDvAxYEMz!vJ>jO*X3?&bW%_`Tv9O?E
z4bj`%yWPgCj9)`T<5+#u5uDk~e`z8%PMM$_w>
z9&V|56P1|AOhIvH-k6p0?T-L2TSL@myMnXB6Dy0q)pDG=G)t#{UhrHPE^0s@O*awm
z{r&qvfzRcmT_XNoao2v7JU(!5{QJue?}<&5UVE|3ui~~Ol&{ma`!!ScW<^A>w%+cyqo%t0Zqvf}JDHrz
z6K4tarTMAI*w{d9_U}J`@}R!+$ji%rJ}0Ns!sUMCpRnEy%LQrq`l_lf&sse_
zQN)y8I==B|k>kpDhucw6r)_O*$77p-O@J#LzA{E1$uwOvdQN_Cvf3_g#_unjw=R#Y
zEN6e7Lf6nbbcm_Yp=B+>Eq9JZ`cx?mqsY^|F!{w`Y-y$=MK4C2#1(Pz@i}K|He%c)
zE}^xLeN-OVp4Z3G`tD?|b&&3XtvaFVDLP@H(w|mU%yjrU%H1<_cbAuU_(_i^Ys$6|
zP;XdROgBo|I4pzbktv&G#a>G_KS+LOa!Lw?gTuyT=ABHr(E*%!?m2cQ@8>{Ekqma+
z7}}JOswzK#$1IS^j?3fLZbRR5>hz!ZnUwqbkcjq2uFVV2F(FnqHcZe=zD1-st*&l=
z>&r`-b=9Z)KR+b+PsR}bGwoNHF?==ObF6Y4TIAzYeRxL7X81KVHAkmg9JR1%zkcPc
ztgKYI#D;6rX%O9Hq})}?npp^mctIom=_@_7Dw0q;>d5^aI;glEX1>L=GqqtSQ6)v{ExEijue5_dLXo}7z0O8JB0l#W=$B5|Y
z>rbCbmQFV6uV-YeMx7oVs}<;Ze{a|KJX_|Q%mTOKl|8!KJUWg%b6V^XSn)3_+q;&D
zkG6?dzH{hD-sb_gV>xHm)N)2@D=I0G1qQ{l3bZ2R%FN#`e2V9A!8Z_y^}M{ic^@}%
zm=$~TvH5vDs(bTB2WVOdn>q@tA<6;FA{Dhsq;GC+F8Rwq_1CYa=QFWJU3%*%_f&me
z0;0VA^oc7nS)i7kLV^=)zSJ~%CgUi3bp;o`g$|~srM<&&g-ws)!neOZ
zJO~@)P`NdS)l~Pu@s$_=6+sIK2mlCc+O~|o9uyW9)_AtEbQ80HYP56Do1lV%0@kBn
z9v`#;T@dM5`20{yhwTZT=PkHZD&7!BWVl6_^pw|q`Osr&Wo2c&M@i{8Q5S3B`y^Ue
zR8+s*cPYB(rC#c7jexap(SK6WI(IsCs;6Gm_U6me{HyTk_^DF~=C8cXy1ToB_f~NI
zMs;x+Y!WN>U3z)jKKhc1)19`Z4olhnfIQXJ)$An(XKiiuO-!O2p5DHpYhVz|z$MLY
zmM!Rf3~iUDa(_}%Ts-5ukK*p#N3fKHckI}4`@w??`O*Me(&jIc-oH8?4fr2)>(-tA
z{&Ok!B=uL%tmKxg#BvM_47h-!6nl&$q-tIMr4U|q7z|7kWjY}v3=KBtlr5Rd_C$^DpfcjXf2$-zBg73*SCAK4gi!F=o1kviDAAX6DWh
z(v%|?OS{Qy&szQG<;qZ2@aU)${knCrI+7-D{$>62AwB<%^#_|zD7PJ++%j42ciiri
z)rvt!`QOdeMhOFwTL`o0kBxN4?vj5+q=t9cT>Z!z&-s4-tk_UT?h+d%=BSD<=T$2{
zwDvmt1OEqJOz$xHr-w3ld2?h`h)+nw1Z}LTzM6hcgN}~wWkrR$eys*4%l{&J{3EUp
z(Sl>EtSpOC{Kv-A5o_?|TO}pmH=bsRQT)#^{@+9MUnBHCcW3E;#51YMMM5
z3tnxsIWjIT6k3OQiTfr%ySk4bbpW~0Cf3Iv3dCNs!oD$Rng-h^)r6*|CR@I#5pWx<
zg7D_dqp|xJNHGAsTJMpA&`trib;&z_#e1}C96QGS`t@sa6i~~1u=JdqohyN(0E#DL
zTjG>Gq#GL>KVyZl(q<#CZ4*^iE~%au6nfW_wK3VHqPBM3Na+L3eYc1niX$=T@uG`ioKnZxd9=K|
zly31UUIYG3#;)yeFH=Te_up4!_RON3iFn~PCC;=(iJps#OYUOp_w65d*?#=DeA*TC
zw-&ob7M((~rEK0D6c@(_Ouc5eUDNCZHEv4GiShCqOGiI0zbi>fN)i;40^(sOa&d{~
zxBu|4uh|ya(QU=9`_^va*+x8aAO2~ac4!NoAgW#r_HJr>>E#J}f589kHW>DuKJ#vL
zg5-GO^7X{Px9r46k00|)`Jl>d+6GhJ;ZRj`I6?l(Ut^@N5oj;C>0Oej~xI$=k(8__022PC$Ciy>BmU8}3J0JliXpqmmHo6E$ngA~d=Wshfs
z;i368rq9g9h+ZsVA!E00Lqo@!U=E!=@Z6Vf143cEdrY4xg>vuEgj5hC&oD%?Y+2`|
zM(cqdk9##cm^dEPH_}DBYCNw9vI4gQw2m>lS5UAUY&sO=N5Tf%hmIg&=Y|a%bO86W
z!&jDP$`yb%AFdXvs;Y_vA;9XnXa8q-cvC>7|K2Opoy|urYCv?ly1TD&o${o)7x;mF!Dsq!8v}8!IU`2b0=M^u6rThH!j&!!LKs*jb)ryib4mjM;h6=&~CWfdan!nbGIg)w*U9y`}<_q!WG;lhP{pclx5>M0HEKhFZk(-D{ik(T3TW*V8z
z;z3$vUQ
^OvyRQ{++ec3hdZ@2jU8d3$?D+`k_T-g2fVKPTsETAC;@?!liVty^TF
z+R&p4x>yc2J*oTjsdl{YT}&<}Yc+94((H`MQL3!hn^RM5(
zds1UhX@ciPXKo<5n46nia&mI$Ahd(n8@|j!8J?1R#S3z03=GoVzwe2FzHsW)DdW7e
z2LVMnBKH{xGx8}IqFgLaB(6lWi5}X2?ATqPR#T#`yCx)NnBfZF1gVS>JMEgbE4uYZ
z@F}|=5PP8DoNO#3A)(JBZ@-Puvnv
zliuUl9t}+tP%#z_5_@{QVV}U;fiGz`fYLj`sObdNmS+UAWO
z8tVHv#V`G-=Ad-o*>6Z)9JPs`aDsdepu<$YJTKAi^+yV~unrXEre5l`@^Uq7)*C3t
z+Z{YFUnWI$?piz2%dFi=Kk2Qw>;jq4N
z$4l}#Ia{LJw{PE{_61m{*2?DWSs{6O&cA>Erk^T%`F0-t#(T11-+q04)bxOcm!M2o
z6R+Fb`2p(03ll*^A*(T?C2HSF#8p*jD_uiFj50DZDRlRN5NRPH0qC19At|z6WvA}F
z{)ujDcWI#G$R;MHn}^aEbo$B$S^mqw$#>(krt9kJTF<~B;kNRdV_ovbBrryuksGsH
zDU}bk0y}^GI(u7=2>(Uf&Mi5oaPi_rCs$XA!dodRR*^DaT%4TLqeKq!w}k7Yh)tI9
zn7mxIdbJThtF71cwSWK$C#Pw@64R}18A-3Jsu~I|9F?{d6?z@sr&R^GVfASC2%+I0XUL{5+h6^#kwV4zOGw&E^#8g0+N3Ef=x;e*tKj0w3Z!G5oUgdLY$i$@R=3Q@c?$gZiS6&VwA
zV`#`8mPZe^{r6Ws%5QFM33+z1gs1G#t4FY1*aMjbq{n;{OifJ4>!o;BXT#ZwtQl@A
z;W9NXPrOZ~2V8jrwPoz<3CAwbkQ__5$$jMQrN2k#`!mKF%f98Q0+k+J_%&(d
zpw@ueCYj}(74e}{cX8RtB%m4!+V}AC#IJMTp2Zuz_Y3_4g8af~K^}~-;g!#V=AXX4
zzOMd;6!J?+ymj`&{d*j)mu&}T?j4<84x%NP{A)1e`!3CIAl|-vC*kG;k-PfG4>QKK
z0mg+FzDbWwPO=vqmpXV~jUJ*w^e~I$JmK$g%kO`JpYa?%A_P(WRGW)F$A!XoOu(O=+N|q@)lLxLdum
zXCE8aTFTZf&P~+({CONaCKc2$x#8R+NQt*2A}pIuX=+}>u0CWU9@CV0)Ig3W3^m0>
z#2`VEc)xNrG2&1f+p%*_FH#NSV#@r4l0|LCs=H9!$&Y|gsb}WqmJb0)4@26E@fQ*r
zAMMgYfeTkqRMbUPGxmUkKw`ir7Ui!X=p2HE(TBUK51Iwi)N4}{WrEs8*5>mK$u}TQ
zO7!7lWA5+1pr@|xZ|n|Q*Kkg5r{}2U<|pr8e3Wo5y(GNw|ogKQcf>7KE%0bwDTl5XmKg++J-x$p%^?Bopu
zuoDuwv#To`=7f~kjmr%ZRq>QqOEu~7y}i~zNINfll}xqA1Hl|xp0iDP2^2#ib~<-c
zQ-?kURh3@xIyN7UW4gAYVt55Ta{rjjVKySI1S`Sa&>rcPZM-u=WVR?>$RT@q58QkA`ay5qX?qLG7dkq+Qa1a}h
z6AyJm8d|?>rWzm=d~?owa;;@oxb}KYg5%S}EDv6o86j&QDTTjGHcAq_w>`KnrQ|Ew
zoP$G`P~7PV;m4?g_wymZEX##yH1Bxsv(QqSk|_%gmOx{shl#WLUH{=^2T2Rnr>hD+ugkis0oV8-Fym|
zsDbJn{pHJ->tg}|vZ7u%*xM(WX2PN0)Hx%uY0Xjo`rJ8Q9h#Z{RuzEUxM^
z-wDG@+uWSbf8Ws!HyJlygK)73VNhoZN|6x;hI!QjxL
zwFEi{Z;Yt0@M+K)BB}M4Cx99F5gwk5?}&#@{#1S!Y>HqF|}L_RQO{kcd&T(
zk$bY(sp}fagm~o6{Yxw#>~R#oBzoYkAe?u&6EdLXr0i4&Y(zSpkTQEQu&6_7N1Rb>
zNaHHwh=ij1&|Q?LeT6{T=pv2fetvXdFN;QL)I=6aI9
zKXKC1GAXr3kYPPD^S)!pj>(FTWHtv}yLJuc`Nu|Q_5sWHll
z6B3vx8V3$AqL&@K9nuX}bNhA#ehI17hELPz5*sUP(zicGxJ99Lrv|6I&{MRiox{T?
zt@m~|d=UY0x(O%gZBK%*n1TYgQv9>eONmGMXu%YarCjgMN4MD!#(<2iAE;5|8HUR*hZI+Vad{U`{*XG%(~zJb4fx+VC=IpKTp+{kWml}Q1`If6&_rYrdP=hkpouf#Q&S;fY=upA
zH2c(UvmyX$cnYh5TXvdpv9ex6go2EfAishvjZXFy*0wZO+|8O0E?$S&$jGa}EEs0B
zBdw=TpH^`F_5N^y29;wS_@HrPsy-L-IN%n)il;xU(^Z7~-`4ZFCs8rM%;`HD-d%8ZfDb~T>D=C%U9X6rxyXz23cH>|9z
z#9k`}cus&i%!HP=tv5$pO|!hrH$UT{Zb
zu%J;z=ORs_3z@Nx^a%*aJK0Z90E!S17;OqAC_J2t$hE9oMWFyMN`9}6CjAH@A(w$h
zVLCyG1~H`i0uGB(%RrEE2^H_z&)W-8G4;^j9{~q<_w@-QK4O}EN(x^|La5YsWCChB
zIxH|+;$*;t82@3L7(}bXK-GNuM1nuLbDz~oCj@UK^BVAEgoJip8Z^l%D2PGUCiMfF
zT!>CeBp#8cX0nP|Z9ifx!fI+3$Ztszz35Wpj03Kpxo|;(uwI-UyPcT0(zN2U3}UxI
zK_Q}!K3gH0DJnoY)+MKZJ@NF=m;cL
zREZ?Nm1Q8SHvrV3zN>+@$hI_qjOLA~t8SRTtiM?n_m26!6R
zQWaanE>dq|=LmI0ty?$RpSuF#_;c2YJur_^#J~2tYg=1Ca(U3L3*~fOhu_LxRBSpG
zFTK~ugCR7f7Z0zD8~gg$OE)pZRtN$;=~$W9?n$pQ-3PHU7B?Zqm_9vr6-=iJgcunK
zvM_@=FhPS%y$GLm3_5^S$15L<7qXWAB!m9KkIf9$T7`63L|hyr0ghJ#^wdz~Xp!>D
z)zx(jiIs}VN;=%3=bx-1OGn3WY<$(`5i0f9>2AYZ6Z871e|Dm28zcpO?@
zUb=u%b2tCVw?8`^e#)gt&|wg3(Mceh>sy~a+l{w@m6M7>#DfP6m<%kL$~SM;LbQ4f
zc~4M?g>wDo%`;dbxD{}>bp(*aY6t>{pH;JS@3f{h%wTnUtaoiKN<$3xWQ?N
zWLUUKq*piviQW91i$6WFN%vdPZ6I55Po4xlCMJq7k|bMmE|
zhNk8!V5VoGj@v(%csLT_(rx>w)QYOA)lfkUniG+*(Y>dax^v!xg1m;^Lpbx9tNe8}
zoqvDaf+*N(gq&(fZ*(0qf9HR2YYjZqut9WQE{IC#6k6xbZNI!J*JV;I-(W0iJu^EX;aQ_~KC)E@iA9CArRUq}gkLRiY3<{FupTD&~ajeaF-IE?Q_P6$Xyi^w5UR2LJbH-?p
zFdRX*dToWJta_^PLkKiFeISwjZ6$k}?D&&u^*qZKy4G}SiX=AjMtm>3;sG6!Txn1=
z&K4BGr$Bc~!n;OCM=JnxSBzBv+P)WD;DRwP>(*~5=h)7tA1hr0&jM=KX;WU{z*lqk>1k7bEh$;c3W88iRP|YI^bkxAerPEa
zU;k4r#_^N)ue#gOckYOQ50D8gJ$LtMwt|O9&54NUJTosALN7LGx>;!%as4`du}fbt
zn5U`{uMM5;t!?6b0=3&R1R-M}G!>F&rI@A|KqftP-4vWzqaQtYh=#tc>0wYMRvWHiMhB_W*q`=C43&k60>Gjp#f5pp95XThXCl@5=mzZYhrP$=Ka{mRD`Wn`GwG4WL>
zkCX-=HQg0upn8?2;=BO7TM2~N`S1hI|jeXeD!5#Bw$_rO_L;E)1wYy>YQU94<{DTL)B&s!W2W@BM
zm1hL`x{lw$TUwzyICi|+LOchDg7~=b#7bC5=-tK*8#MkaG!9oX2|ANO(;?JVgdF@4
zeo1k;a^=dS)Kra>29*$}cV#>8DX_n3Y2hWY5!?<^x+xv6mvDmXkwNMwWZ6UJgNjti
zXK>ealkoPQDX4Iy3JPS3N{*623l1ik3#1Zyf`tMjnh7%7jpJE5kP*6uhaH;s!9Tv(
zUK#`^mIV56cBvqL4FF;!Ac6y|4$mXU_7gufXm8DvTgSCwz47|n4Z3JyK$G}_7w*WXNJvqM1^t8G)OfB(K3AOxAS
zu%87N&}sSWcg)sBZl#5XuOmo@9z=u`tpMnlWAw;CH_|dyD7a8^P-N9HC`qQg7B9;E
zR#Ztu4{pyB?+5?o7RWm6h==5@<>ZKUS-f!}f%qdiB)vn@(rhFDlrK%6pc6zJK3WeU
zsTUSLDZG;I&VL-~wvr+oAyB7MNislZnM+CwROEi#Lp4b^KSLBe+sQaVAu
zg_aH~6;6c?sa;>5_^>BtIxjaD%nx2q_u!y7g8Gmq*>dvoqM!u6Mf5A|m4%MZO%mP{
z`=PK^fBbmpc%i)*8I~bj0H|#zv>s^uYhNEouFq%+UokiXTbz1LP1ViE?B0!xs5MvV)QBb}9&8+WGRGa+s&EQ8n?yKFiXA^ASy;ll}2xxdwzGN~P
zeyNG7P=q+PyQ)%yjFW^H4Gy%QWNpmqvG1*ZRg`~eGNfjm56EK{Q%KiN^>ev@I79qVMkP6jWOr4KOeFJ&AXa!Y)2^a-_oo>aI4G
zOgY0wmEq^-cNuBlo4SM+xPh2kUKr8tH8RdeA{Oo&yo7YQn2_p+Xv#Yg5vE*@<|86-
zWQ4c*ZGAl%);j+==_;9MqEZhfs*<#6d~xCv?iWS{JZc7FZYb~5f%!SBZl}3%n}1^s
zyZ_BEqpglZm=31ZLGytE&%I?~q_ub}dCCB|vai*M^GJF%zy~caFAtiFA(aa2R2wq(
z^V3xa2GQw{5_NE`qjSX$Kc?xV?8qQfgX@VoeEY$l$lUppGEwoMVT1zS{ki|T%=o$5
z#&dGHumDrW;m)1n+ptM7^7tTclswOFyX&A`C@Y&Cc6rY_nPi%Ncq9b@n>1!SPnCL72w59*uNZ9lmys@J~!k{8xzuI}!pUpe@`WSbXXLt_*V;9!9GoQyFvXqv(5k;Or;MJy9iO&uQ}$8Xjm
zX0>{DsWcZ2LnwSHTzOB-kv?f>l6w-!`+iMV0jEYU5O;e}yH|6o5Tsa7cq?z$|5!x|
z?|GS-7amS6n@g`ea6JQPu6>B#`1vlb#R&jNkxP?aK07-6Y3VLxS40YnN{>;LH7m#0
zk}*)sz0frz1Z;nn2L`Ug{oX{#80CSUY{)PvVkF+Isa-B=_hLZQQX)T0O>}3Uc5%rO
zGE)QWdf>j?27;75iST8+BIHGIkVFbGl>>+7{eJcI1YjwmjNHwC2m#y5YNGnn2xqG_
zf{(k;FN6=ThMq6u-;u4dXk>3c#5QF>HK91*P!=TRy0>qy(zvCtkoG~+J`|@w*V*8#
zAT9mT+Vm|H;%?{|RCDuIwi+_mN}d_RVtS3cCrLU47L2B6LPW&qcPqckhcB`Qg2JIl
zttKymKtg7(|IIE~V#5jR-?{sKd-1sjA*4JwAg4(c4&!7O-G5>b7iGC+QFlnc7j)i$
zy{M!_8Rtf>qTJpciX+qffI&IP`x5FfA3FQ{X{6NP6ARPe47#yFlN!ZHn;pav%a%)t
z>to0A^qy3v(S8*eoX<%u-s@egOzpKb4AF{LGfcBKRxGMDo${Ttftk>aIDQ3i{tj$0
zn|Pc>0L?M$&sjm@L8o>(_>GXk5v;3v8hJ=;ePkRu0bl6nri$OfGTv5bK2y_sq9#2ok5U>{FeS$xQzGe{wQ)x#F;}J*1^e+
zlqM<9jBacsk(`ywO%7KP2qOckWG$4x*t#8$9svPoKb9pK8ml*F6ADkzT`QPfHhmv@
zoH_877y>oXQ1?ckY!nhdXfypJ7?wZ0!EsC;`^#6IIs4Vr)DX~u6Sx&)#fBim9FFbv
z0;-LpWYKVl2E}!I%Vx&4PY$Qug3E;+zi%6MFOF{DG)NDbkX_?{?8FJumJ9nDuj+H0
zJPL&LYc5u|qTg~Uc#w|D-o4~GCy}Xlw_RowM3&_?1cGOiDVi!MgydI=Vw5&)w+$TGrCOKvnd%NEEXVM;rmbw}CbFT2_Aus!W8gbSvWLczhe
z#}KCU71t_bLP?)A%C#EmO6bScYr>s4FL|#3`oc9u#`?w^xH4D;YKn?;8_InKwjT|u
z`T`v&20%e~|9;PI`Nl6_`d;5)5Wc;EhjFbgB6sQO+ij9FlA$&lk_Y6Xs*~k*I16Sp
z)i;lIn2U*tL7+@M6J80(>4MNAPG=x#8JG5VBAajFU2ylUmA=1Eg1gTZ{L~b%S(Jc=
zAI4weeFp@Xly^-}{wL0vPsNFnjHloNA>QK8pjNFuo_}ua{rsXt?ech1Dylbp{T>S5><40b3w@>0M;<0Xsv(hAWYzK(CTC!KHJPxX0*Rgh`UAskXBbhQsrpJ`fN`@aC4H(j0p

literal 0
HcmV?d00001

diff --git a/bip-0002/process.svg b/bip-0002/process.svg
new file mode 100644
index 00000000..bb61e8e6
--- /dev/null
+++ b/bip-0002/process.svg
@@ -0,0 +1,52 @@
+
+	
+		
+		
+			
+		
+	
+	
+	
+	Draft
+	
+	
+	Accepted
+	
+	
+	Final
+	
+	
+	Replaced
+	
+	
+	
+	Rejected
+	
+	
+	
+	
+	Withdrawn
+	
+	
+	
+	Deferred
+	
+	
+	
+	Active
+

From 0ee015209f0615bc8074de81ebfae4cbd054f4ac Mon Sep 17 00:00:00 2001
From: Luke Dashjr 
Date: Sat, 24 Sep 2016 06:18:33 +0000
Subject: [PATCH 38/68] bip-0002: graph only shows typical paths, not all
 possible

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

diff --git a/bip-0002.mediawiki b/bip-0002.mediawiki
index 7c0c557e..8dd8bf21 100644
--- a/bip-0002.mediawiki
+++ b/bip-0002.mediawiki
@@ -171,7 +171,7 @@ There are three kinds of BIP:
 
 ===Specification===
 
-The possible paths of the status of BIPs are as follows:
+The typical paths of the status of BIPs are as follows:
 
 
 

From be3260ecd58228a6c1a4ddb80f8f5eaece20cc69 Mon Sep 17 00:00:00 2001
From: Luke Dashjr 
Date: Sat, 24 Sep 2016 06:19:36 +0000
Subject: [PATCH 39/68] bip-0002: Graph: Collapse Active into Final box

---
 bip-0002/process.png | Bin 15586 -> 15691 bytes
 bip-0002/process.svg |   5 +----
 2 files changed, 1 insertion(+), 4 deletions(-)

diff --git a/bip-0002/process.png b/bip-0002/process.png
index 6b1925ec88fa768c0afa1816bab8230da51832cf..2f86230216442879c13f8aa3ab5a12b0d35856fd 100644
GIT binary patch
literal 15691
zcmdVBcU;f^|2O(-C`3u5UEZ{#fuv0-4J{RtGD>L=X=xBzl9tM-G&Gb{QfN_>M4GhI
zKwGJ_yY4UF-*sK*oZIa>=Q@9!KaQJ^H}6mH_iH>K&&T7wUcq`g>KoT{tS1O!qs9?c
z1A?Gt#NR)!rNf`bbs?#ES?6@*q$@!%R+0Zv#fUO;5(FQip?c8JSAfs?zVT
zb>zi_VsGNt?&C2tNo0OTPOW;tEdhhJov@t=xmAz-`>4jA|fJM87s3qmX4p6U-4Wz
zZfVKAIvld`Mo>@?kEJ#jUTV($@4tkf?vt=@-#b0>Ro8O^n*_lks8c1Fc;#AjbhOKu
z96$e>0D3019FxK?Ne5}NPZm5jT}-LgRaK>3m>CJwh!Qv{7p-Yqb7%Y9XhD58H(kux
z&kqi$^;EhmJ=RUUU0f`K?`7)o`Fr|h^`CCRlj`KBw(T|*ik;=XTfN&^=F+cCFC2TG%6}c1A^*OzJmHt3
zpQ7fmy8L%LWw7yYv2*`3pT)~1Gp(n-*cAT$`?oq`hx(W7lY8tsUgVfAq*i~N8vKZb
zx|*gHd)GVpl-cIZn>TIRvMDeCI#c3rPpGDho_R;xnA%YqKL{zy^_
z`Zjl*l;!$vzg3^KEBHsT$0TJv0|T#(-}Kyv`ub|zvxZV{_tCZj
z`jOV0%7G72Ioz#1cM}uC|NN|1NpCtSw~6!&Zyu=xI?eq)
zTk`uYLx#~4R)SAloQa-^rz%GDc<=CV2UX^xsb~Y$D
z_-a_##+9W%x(^Px(h*MMod=pT^l98iT5lvKCc1UgW;JWB99mo$$!&Oil=FIEVC+4a
z&SGa8dPXi~7Z<5}`yFpPbiF#5CRN%t)>dHUJo-&C!%#$idAcd%cy59QH}jjJrgZ1w
zX5ow$n@dBDYc_I9@6C#ejSZ}-Qr&C)gH-DU5X#F*!ImSa+Aa)b|tAO{mH|mVU<8Hgvq}b!ByR_2`JUmR2RIT3=7kpGUzf
zN#~*L-O_l&A@&V)I|T(RySlh>k%Yslx7CFUZ+m)pWgjwf?srht*Jpm^HgaM1+ZzAo
zW&&nbm+Ymro}Qk+8q*l=N!w?YlxfB87PeyfJJvx@ShwZ#+calf?d&v7ef;=s
zeLa&`DbMkzrU%0~_Vo@8U2Lo-S7%@#b?G*hvbOey+q_D*-@ZL0Khu0nE%9~87VH;F
zc;xQWuY#hYj%9XyeR^7y7NQs{NmL7&qM}-iqGov17_xk+_D8tQ&ZEb
zwziWdFYJVUeSN8wW!;8%7CCfnW@g^Mf4^mUqml
z&r3OU%24sOWEruXI(4eSdhgU=tT{(v%)NUe0dyNT69&0v3X_wQ%rTn$j-@kqf6aKM
zb$6F~ukjykFVuQa9Zk)U>G7^p#1VW;Dyl2l
z_=)9@y7+SvY`4yxD!33PBPSPHP*C9E?H&5?;X~A9XjD|xEncOSH$A_-dnf%?t5=_$
zt)%t0u(FCZ5fm2IAZpSReY2vE-j_ZqFE2kZH`#Ac?(36RP{0zVwu2)~&3EoQeabS!
z`t<`X$IZ9mz47t!sVWxTpx3Wo6L*AUx~%n
zWZz_FKKa}_g1GbT+X-PYu`O7ip>KI98cO>eySLzWo_y(&78GP*Y55^e@;t4-hlhty
z`LPuBaMp)9$A66M{uIEqiYb!RG(@gc#|!(Ie1Cs}UGm&@8Cludw>KCD(R>X~oDf?4
zJF$(J%Jo~;a&dKyS?KXwEp4FkTV8NGaCtP2xWlA4r`*`o6eB)~t;RsKJv*y%ptNu5
zj~~5GjIUwyr1_NP^asI2j5mDW8viTHGhfwa`uh9dy?Jxc>+krkix)5AvMiPtW(;yn
z_Ib{<9FOsO^ypFTidU&wenG)tTCCY-tbZUAFKa}Hxl5_{Usgdu!M0NGBDM{5l589D
z?b@WM_{^_N-e@$_==&Y+x1=JV9mgjuEbP+%eq+4E*=xj|zun%tncm;uuA$=7x+^9b
zays{`*3Zum-?g+DF>=WyRp~`Oi@mZgB&h2B`;eTR9I|#?TwJQoNYvb5*j80vuWKk`
zbXb7VXyI&F)f;^1-acCarPZZ^E!(zfsj1!Ez%6TNC=#=C=T0HFpLOv&L}E0JpPFXw
ze7R=L8Y$l;4=O%EodSE7o^!1CCH#d@1|Na)cW!ZS6gmZCdZf-8BPPCqeni|)shRNq>I8hbM
zvYCs^E_!eD?>~Q{&<929bInRch=GE7#XVWoRo@%PH7vi_B#qTk9zLq(s3OU{=s-(6a|qM@t14U=;Ir_$<0!}N@dBQ~ws!cl^{tjrND
zPmVJX^Gko~kM^<4dpyJL6E&~l4^~094qJ)*`0-=Z`!G(encM-
z(A(@2(Gl!i>NS(6cQ`&3+SLbj{4$!$SuBIOUdK=IPhcuiPhYpMHJ$I{-t*$pQiYj`M3}FOOPZ
zI?Y0u`7OI`;E`wJ2%}5ad3eazSCMWbhlOGF`}cJBrR@!7yI#5q5=kn7j7M~Iq_a9m
zF!k*j6^dQuiE&Q!6aW@SSenzNOR7C(K6xIK=eXoOHUX!mmA#K#X)m<3YBc}z<5QmZ
zUx%Ii{Eq=oZT~722_Y_DzN}`+Eqkf>r|%B++k3st
zq{_DM*r6i4=(jqtN=2yBlB3GTMg-e9A~BKa)Txg0ndK6j77?s~_5+y)i~B)m#@Y)#
z#$W!7K3{HL?)$8$NF6t#8_1JTHZa&685Jdo{S!5*_VMnnfUr+Jt1rhoU+%f$>^HYEdv7$fuX=a{BAy`8-L{~$9{)fn3|)Q{yq!S^Bv2vk8AlEDc7!F
zr$yay#?aH!#&Lgmb+(eOWOZdx#%*|up~%+G&Q1)|>(8I>WpqgmOfD{FD_>oaqo$$B
zbM9A5>#VM(fA{X)iE>{B?5cp|WQu92*H&GHnP?486z#DxQ?18E^9u|2nis2;Rvs;_
z&j0yIMPM0s?Rya&y(OjUO{Z0=bN_qIuKeg}jN;b@Be=(JDl2J#+Aj3FI6Gg(l#XB4
z8$=PC4rhnt&n+%;D!4m25yX})TZAkr*8q3>Msmy5fSc^>?0Uz?8Rg{Uwrt&cQvOLg
z&K4_IdCIZWQo8kg^=*s~s@=PHt0mSyK6=0J%OjQAq`G`XcYZ(rmD3_I>oLaPVw42A
z{`|b1kB=x{p5^4?;*xOcRVMs=o+fyYzclF3(A0dDyP|b$aC0Emmjr~miu0-Zo>;S^
z!{gnhoG7!yK(culMqouE#{yA{*XQQuLe|Ffxa#Zc*VNQhps4aLkC{Y`0R*w_xv;^%
zV@HFli%YGY?uz5XNZfMoS$p8IQ$-HKd#=~nm&Zny3!OGK9cPaX4P`JmcI@LV^3o{R
z@B{HVDPKn>*jW_X#o}+Xad2eS-SPh0<=&8GBnrqFRMT_sGhm;Mg@r}5Y=AIO79nBV
zDpo+^o>0tSp~TnTK8mYPx0!iRVIOZd&NT}I;_Uxw?)UD_c9rO_CmJ2ETq*ewU$gnI
z>x&ez@Gfe-zfyiHSBN6rvF?xfv5mmwz~@QFbIodFGlC3jlKBny0Y0SQes5xqQeT`M
z%d_v0wk&%c9?pbje6(E#%;U%BhoPuNOA$*`(+3)*heKJ`PxLm|cg1cU|MBx@y6Ld!6D4nNZ&dAlpNANhro7kqC?`rhB->xu
zhZ;RGegvdlJ9srUb!W;R7E27ox!;vclAco*#jjr78xzD`03Q%Y{Di8u-pj$CCp6y~
zFX!O5FqFP%wkZcEW8L(4qwoCSHq&xn?C(*DSJB5@e#jj-&^F+j)?j_c$_i7!ck8xo
z{Q*ph6}jarAwLtm86V2Im;F@4>7bSDo!7GIdgT@r7FKAzrj}!$4N+WrkEfw)1079k
z&Z%_M+|rI9<{f$f*uYOz#7#!-5b&Mz6Wyh1Gm7&AEZHW7>j42(!g&-(rr}t=%!+-c
z`4E>xf}UcR!S(*-Pj`r$m3-Uz82s_k$$|?4<`w8?QYLlU=}q5@dVB-GHC()2K0jY(
z;jq-TOrCDMRl>p7m&c+D){$juXD4><+__uByG@?gj4rAgX@UGXbe9AJ-?D`XZep&x
zzh8HL)q8&VZx1ssZ}|S6D@~)b1y=PGY3bI{pH1Kam)-fN;-DSQC+_(`S_6}j1ke%
z*Fk))04Bxly}0=mcGhrav)ugRVr4@EGpNHmbe)LE$ZN^T$@D(K({bO*{ggn?>J3-|
ze|MxkQ5C?`wqRqsjq5X2@uj+CZ=k1k2NuxYv}3euiw1c2XNpqR`}Iv
zY0lZMr;Hnt!p-~l?@t|WDzMVsz$LSZfmN)cE`El?)ZD_#
z+J`0h$1B0rHZ4dwdsnRkJeN+1oednk$WVzGMky
z-Ssw%bHCG%I(F>@d3LZqRS=Nz`DIfnwR4TB8W+TkXo{5F!GHx~UufN8lcc6x!?$cC
zemAJ|Zr`WckP@N$0Q86zt}U4aqmI
zOgE?-7#dpS>nbbzPmi`WrIr*Ip8%giI}oxjv~D=W$RjUwEL~@7p~)_62#UeNC2i&i
zAkq-cG=ugdnwnm7;w4;8R1c<$)fFh_8bFf69f{_G(~5Ow(ocmUosBp
z#J(%Fwb=Rm0c?urjy(ws%0?TWh!JZl2D}$A5vY|F7k=$X8^vd(F8$IQJVDC`sul?<
zy>9K=J7%R`!fv0AR(HN~d-AQL<0G%%lD^F?^6QVAd8Rdwkpu^WZ>Z~ak--bV2@oi$
z1^JllhX%<2oC|*^a+`&N$Hs@^+=m-d0*O0auifw4iHeCu12G&S@uf7Uw4IQsakkK(
z*J)x#Hr#QtTdsJJ+`6eIpmpq&vIqA@19JDpDeLI!o3O^XQ#Jgz%`KvYxJ$RJ$^IdXs
zr#?TFOV2Jdx!2cs4k}6vs9Q>mm?(AlYOVKDkMREe$3G`1hAq%Y$Dx(*+!SYWk9ruA3-*GIr2+@aIo0ZS7mBX=w^hr%bEAQ?-5jmV}jL
zY9`e`k)=z_3S~ex!>u{q^nhXT1BYh1k-RH
zSHH5Vs^L8nqP*K?zSrB<_SOCbXTD@_z+Lv%?2`dd1|V=H(;HwA91Ng~k>!gY4-2MY
z?m7lMA$eua$u{udbOmOh*6Gn;u}ZD2s;a6Mk^+q6OP;q`R!~UDA!}>v!&Qf3v@I-B
z3ss)U@~j$d3-`mHCr?(FXEpEgYfx0~*}nSM+?LyOboI^RSH;JwG4FOh<9=SAH3LQa})af+gv6@rrDm<
z78wdig$C2;4;=!yECl>+y&aIvCnB;QBC!ZzVq1O4FkZr$PeeseZxb3qVI`mF+Kn3z
zlUH5Imvu?z{Z+`tV(+W|-@dF#3K9ukUi^E0cC<}k5a^H;n6L-wd3h5TZM@s^Ey)Is
znbVM}5k%i@q6meALo@NPwPUH
z=MG&QfRY_Pg+7yghp}>eqM{?))t6&|yYcJHyO6DejVrgg7qr7
zK{X2=nb&?X_x}7D2pGT#d?I^!qB{&QLAXPe)~Y_?T`-Gal0oK|m#$WOZJKMWS06m!
zN=;8s0TLImHwS`O59c{-Y|PqT`M!J_kR>Hb4xX9&TZH@!|#HV1D5x
zG)1BpGRC(eM_!!Wml99c6d7G;&*;)`T3cDsXvAk4wMnh&qMhaM;rl*tTz
z72-(2g--*+El((vzJUQlmu%tivz0f67t_(ofWX%HgElLpJ&4*Anq2t&K$tGzO-AlM
z+twiHW28)0R8;h>txdzjqgdv^fe#QXCKi{MU!y4f-QQ=|&MjZ$Z}shOQ{rWs&JYV$
zadytb{nCOMGIib_s?P7;H>9f5_R=-|KWdHUHAw(!OF!4(%3JJvX#KBX<&(dTK)$F?
zQ0VLJ6|CMkIt
z?3b1{1{g>K<^q4*frh!;w3rWKCMI5-jNak=*}v{FmSg)9mj6uF@H2{+FXdmqaYN(8
ziMXZdCf)oqZ>WbF(?W?&ImS<#;Z*cMvjSKau;0k5XezIu5L3YDF32b;DM^Yg=ilFw
zY&-s>CB!7>uF}e!imEEWz9b$8zD@_6Su!uspehZ^RPXR9I8l3)`B
zxI}zT}Wfa@WQy`6-(D&RY)7%T1I7V7pXeo`|%Vzw8C8q9Sya
zmM>-6r=_OG9p%!TeF(HFaP*$xa2eq=)W|=#u)s01k$C#_Dcq!L1@n56EO+W~X+}jy
z(=stJ?GzA5w*C54paWD8ocvOKSy0B3q%&WZMV8T%o8TBi^^iY8aM1pb;^nH)H)33v
zuWF_px^UsK)a&mKX)&RliZtH8dk@M_R%>T5^yoxi-?irEW`hw3
zSR~8;Kafi~I*OM^@ogG?{;yz_Bp3xCQnQr-6<1NcbN4PC=3PplNzTpEQiZ)7VQtdO
z%ga;*Fo3{f`?qfut*yoyTpZGNK~Ik7zC9zsRv2;Tjz8#%u$6#jKU!3FwirCByX@)s
zcu8p~GlqJj8rsFzK)$SLvtYRmKa9
zPO`OdDtJ9_lYt69S+}P?3DQJu+jaOp;5e)(Xf?NOyG$%*-8MD!SGT7aJn>qcJ|pr;
zmJ#R!dhHI-7E%tT6j||aV3$&Dwkcdf#odLXtck&Ni(Af^sKMxnSq5^074(?6(~zS6
zvCL<20OzaOc6}X7v=?;G#^)E0Wx|nM0x59;!bcUAftbci+ut+L&HWmho}S+PrbcLi#Im*23W&M!<4ohWkPPVigtgmgfji^oLi-)BzW
z4_yJYC;Y*S&XLm8Y@5|byFIXP0e|NPqI7@vhbvJNXs3a20l6GYCT|+lzj;GNdXeAq
z&c|#OMZHQu4NbZ4lG$P-W?H-njw2=E%9I9Cfvxu?^O)e$%Ho8_pHKTGtv+*+G!J47
z6&2OD7xtWx!*ia0@9z%)-R*(CWgHD+wK)UUSmA7GW6y;eqjpd6!sUVgOy^_wfJ`V}K%_8&&Z}oXxjq+YhOHx@}LPymBltJP6Rj
zdcF@>R+Y6sZGEy70LkPfzpX~?K`zNzxBr2*9XoayEm37QK5u38&&WU9r)(&lQ%J){
z$1*Cr+Fga?E&v{kt^V;rIOig-!<@kp#n=@9z8)`oLW(oxOgBV_gmCbZD}I?Ru+~3
z*w;_qSL^{!ws4bkAHN><$y`Z;at$VVFWj{EFzAE9V@^rRzG7jar%N3=xZa+2JV0gKvHY2ITMBn%rFk1
zlL8?|<~Ni5)y}|rP$-i~F{vdhM#G#yr@Tor25b^l2!stN`;@qeTO;TMM~)sntgKAP
zx{uqvFoTWC$Sr#vy2T@KM)JdlC6$J=eU$!Wbt^G9EUzbl(v&n*Nh&_Hp$kRsLyd<~
zmG90-2w6h+WpQ+LBrS>L!wm2rSYd&+<(&^~D8p@x1sz8wU=!Zc&orb~#?H4uQx#YS
z9qrB-#hH+u2%aMZ0T!^%O`M#ZsKZ#O92_mnXe(q#L5nxcH9Jkz_*2pB6c^XcJP%OQ
zUE+Dp%1Tg2N2d`0ko<;6D)btV+ik=T95_iDrZ9jo1cYD=k_{$)@5M;s+0w=`U6UN+
zGih(Wx2}B89$sc)?h=0@$OzWC1%@G1YW-S33epyXvn;^Q&Q763#>Wc-uEQ1FrlGBE
zI1DyvHvBbLd}U>23OcZ+nOVXE1#jc|?J!`T8~h!wdX$u;TvAe!3ZX4BIyyBvQPxcp
z|K2Gfp(iZoJ)4b2%MOPW#9C|GtCYk$=WK07C(0I|8aU2R4N@y#sEgYU*Q(Zb8m1(i
zQ+9rJoEbBw9_jY|$4<1(EftWKme%I_ro^nDX80($GF)jz2(rg!R#pMh9@I`$Jl)yV
zMczO_ucYRQp7L@W8Mt-7jo_|bM=?5JaEV%CmEbI5ezUc7VcCc~>sSPYEP<}}J9OS5
zqaA4RN6#flS%#oTlNKj)1XLM}uTU@n&KB>%nB%FyI0mMsVvq!);mT{Pt69(nEM{c+Y6XPd>NS`vjh+*
z=pX6?4h&eNEGQ}}VuOkT);)yYZ5hzKeSAXRns9YR8D$(C!6j!pxM9TWn>TCwLJ0j%>)(i!lA;6hK>wdJo_
zovT*b#Lc~tASESz1(c-x{6G|#mS(2&aaxiKTeuAk4b^6cz-rrT+qwZ|V*MrQs)3-Q
zA`hYo*uhs}g|%G1
z^WlU3!YkipS@i!$OLIMlt1tmF6aG+YX$ZyT>0=}azObmJsYy-1KBOjq!7L1rD`^@n
z+ZsIb?}oO3Z+LomdY*+9S?u(k8br+Az#Xz+O@00T#h~!;q6{VIHrP?6&8cvTXkg~5
zK|j7LcJdn1DU>~XSg_yKtoCX~?_^11e(BS)0L^muzFDw34k9`ZKIhT)hLIW8(z2;4
zlKhH1gecEV{6?P>vBXL}D=1L8az!3ShBl8)AqS!%YGc4#eUPEmED@c65_4fSSv=43
zBP;3MfJszAiPcL{+i2N=#uvTn?&=!wFP_o}TF8C0!#x5~@x`EeYrvB&CH+sy4&2
zc{ABt@7&oG_2RC$xx@6okdSjf9V9Drn^mak1Oe=uGKHEvJ6Ib-B$@so5lEijs&7i1
zDlNoLG}C~boLycs!#B`qdePhu!Y9_hZ`+!E5FI(ss-B0afIdnPNU7}2az|%=lFMN&
z*K$TjM|bk^DPs-^0%%7S+I|fIJ1c(q@&lkl^egxJEE)6`sDu~69=H^*oIo;ZHx`st
zNlA$vWQ8Ebw9p`u%Naf~K8m@*kKP>xnBKKPxPJM~>Mu6$F|W
zH}M7FpS&ebZf?5@CooCu+Mln(MW`dyMb%j*_Nc|C0n@{-vzQqml^#|M1Fn@6$#YAl
z)&pG95WlCU4xKo`Mh<|qPut9|FcZHMSC{CK|Dh$CpPuG~Wbh6`N7(yQ*(dU-(NE(J
zxC(%QuY-Gx?g%b*G~Vs(t{>_*|@=PMiXmQj+{A@BrPOV)9!p{E9wg2L#ZuB
ze_My)_HD;>u^p4qM0zF!i%;T4T-Ls}m0Ho<-dJlR$&l0dlf;~WwBS!NEu*T|`;(tU)Tj#FE$HCni
zDGfrl$2vn_zm~(C*p+okUq&YKpQJ^?nCTNTn<4f_D=H)Q^2_;vnNN
zhG?7?f5>AVsnN6|?C3N*dJ;q_=GcI$svn6*4{AExb#w0n1YZNVhB*h#&D$z7<$8l`W3TJy7&%A06bSc^Y{(?OyJ+dvrR&So?cxIfg&*tntyd8*~vcNXiDNfk1R#>>kKP?vx1-Fh-6LaJpm
zk98i3fTX$n`m#OKIOiU5r(SVUTU8a|AwC#QtiW$a@9m91Mlwh(g&8gUfY)?JP*BO_
zdrnf*dinCDCfZ>)iSu9;>F183%1L_(%9Xn->UQaTu0ogDb<|$4I1`uu;qS)kvw2RK582J4K1OfrDZEdHyL<^!$GD6
z;FQ(HQ4!FpHbEf<*sz@DL4FSv)sT^h3}=#KPuUmiy_#*Lc68y>z3rl+3|NU1&(2Vh
zrGTE8JiR|5h=&89XKRMV0~JHVE&d(p%k}vB1O;!3gv2ItyvK?{Y0Wi#Tx<^0q#7I(
z4)XfmS+R9kgwdXI^UObQ=y{Wpk_hC!t|CxCQ~=n(`SCZ)-GA{95_q7r?;#wA0wPp?
z_^=L1%s5#$k-NK2(Scf|IbcprA|rhc7!u~$+6^17Ll_0jny1|zwIcjK55pi)D
z(TCO5QxF)0jGxv}hWuS%X=$m(eIT7|Mg}2f-wZfyHmv=Nd3d8Q1X#y{V$AKo233whn`@Q_mFs7
zS?P?P2UU*`H411@iITpFtw_oyq*_8ME?6MWneP)5j*Yni0Re6MB!Yf@Ck>4Ct%#E$
z+}jTsr*`h1NFh@XENVout#JcO%KHv)pkKbpoC&@A#`I@``
zrM7#!ISTL_4mjrI7srP1#c48>B}a^9kvS
z_26)$U9bN-zB`7q$8!lA!2vwrHZ;6)vlTm;PfG%FNS24~N$U%%tA6er1(`vAaLDth
z#kGu#@6lSZK>KO|BO!Z>H0f!P0Y2hOx!-E}3`fwfNxl3#I!0rOJoZdJgEdpp4eweAKu}UMGJch{qY*_ucp!$(9Eq^#qD_iaZ*7F?4`*3{hVyTc
z=C^Nu?wKTwJkiq95>Lj)7){IP#1>`+GZ_ZO4e3tbgKHR^BYNcI!COy}$C_O8&EI|I4xc|Jw^E!|-+a>%Kf{
zoZ&93;rV*-j8#=*0*84zRQ}7O-O9{hB!y605DINgQsHGW*xd&@|J?eINo&96`k|Pk
z*49Fl9XoQk>6n>~DE}Ps{~;!x|Bt5lzwuIF@nLBFKIcAF=(j@k_I7r9$eP1|=tsU@
z89@%7;&4*jt7KBDLdPQ?SmA>He6>T&5zMIy+FS@SBFXRsTNwj`g0eC+-QSbj>b3iX
zal*E(ThGF2^MLKv0OyAkyEjEFI;e5f7Ri#NPhi*GElkVg^*?K(D)oS%}g6ePqP8SsnW1%3MFw-iwX2_<2&^NALYo
z2-JR$XAb2W$k}&nTaq^>
zcnxQ|c&I~4YjN7K(KFY?DX)gW7)hKQG<3Aoew32G_en-8EC*TO8aNX;yVTZ
zJvtFFQNC(M#K~i~0-^5PXM~vKP9hZ=E9t91EbR7Ov8YPY$BDHMSD$b^L5q+1H24=FDe!NrE5OUUl0!fA!Kyb}e+8t{e>hAZIH@54Ahh_=9jR)#BZ
zdo)p@{Nm#E8B0Kl)XJ=QwvAF0MS*(2F5{G>!3E&)Z$BF!AG%=F8H!m1uLV&eTH+g$
z03c>$>HtWCQvq`DS^^%=sd#%NA6N*$2l^;!D3&*oj6gxMjqO3yp*j0xQ|d1857J=s
zOn{t-HA@0zKp;uNrUMB-Ag5~FU4lTgD^MrB5;FGD_Oa&7rXG)2H22!-9eZT*RSzDd
z0-k)lbSFW{kB5)|VbYG5dN-;FHfs6eWFxs{v~u9IUI$|lst3|^e9_%Ch)4Gbk~>sX
zSEo0>pyC4vBfcQR6(yUHkdXFX4gF4^=VjG)kyVT75
zy(q|f7F&2{S_mXcm6V3w!mnmD1R5Sq@$&K4fNl+y$W}lh5l~ui#|BV=YXH0IXgjIJ
z6&00RP3hl@{KyafAz
zW4;OicphtiL|c1rJ8bg<%~?ha5EE$$GVehy5j2l5Gp!331n?Y)r#Ym4W(Dn-DFZTR
z0-1@v_wrlV4WW?scR;tLq1#Z=`O-D!6@<0-5DLlAD0xU|V5H5AP|9`knLTc~*3r1D
zawtg#0G}$TW60(PlJ+fhQ-B3BIbXK2U^|#yu{<}|A5NMsBp!pcfRkkSBe*ZlOz+D
z%$Y`9Qz@DL9~}v~efuui9F)=c
zZPc6Qm=RXy&U0K}wf`4Ueis@xitMlV5$LwZdSGc>waSEr3fG;e8~(~ls1
zxrQ#0!L*P?OIus-`j4CcqGMU?9h*99kZG84s_5xqH#oOn@-08Q1jAAL<*OhSume56
zW`X?Z|0)zVe&7iOy8(|Y{R0R89`Pk*Y4(^kZqEm~X^m{i>={b%|K`_p(A=s5WgvX*
Uryu%wI-1ZptfTt$(3xxh4I(UI)Bpeg

literal 15586
zcmcJ$2{e`c-#23pvH|D3hnXRY&|^_;WT+gf)!?rZOTUBBV`{Y<|g!$bQvZRFWV5X2_k{ZwOu
zSjB{Ye_X#7f1AD!euNi#S4~}$_4wnx-kOG=H#qG#b0r9-YVtq27zrj`f)FHhsTwAp
zal>sMp6t!@>qbZZo;|#O_3a4t_1CvG5slPG!jsEvbj5N{f}JRaV_uP&)+wX@E*jdD
zXrW`$8~6B68nOvKJSujTMKDZV^PpqN$O!XAoo@$UZ`}4^d`ab#%1hgiaT9-)K9=57
zbX_Yb^uPa;d?x*UI-5zik)au<{Qw~uy5QIMW+_oTPjkjEv(}!SorNWdfsxUBy36n$
z7eD{4=g(z1i1<{i9G1T;G2AnL_}k2RVWo$49sSz1nrXX!+!DXq*=c$G#tkzi#*pr1
zi_6X{zn3lUaTKj&>hEF4jfj7`tH45`ME>}nzwj&5nOxpw^@h>>g_FkIQ`5|@zP>dU
z78ap=imV9<3Bq4J&YTevIe7m%jkaDvNvXSIWqHr3%Y8Adf5OERK7Tg!p8jE*el(l^
zj`T^p0jK&$S68nS5)>pH%a;mMwI1&5w^*6yI+UPd);rH-;Y|rx$NZ*b8s1+U5N?j!A4-e3Prk^f$v`{eif+cz!&-`Rht
zkErwfdoJ?f|A!TI`0^^nGfn;ZRy)>H+mLRwb?9e7CUyQ%uuWfm%=%56YI1GfMclo6
zZonyFzrDTW;?h!%*VG{EdB0Bydv*NySe6>zMu}2*c!Gz9hBRYKOI1`nM~R0IAHHxO
zJ|0x-Iy-urZ?9K=^@7+zj=#aHiSIvtoc{eWUdN{BV%zJ?>{r2xuD_D(nltY1uzIs=
zc$cy=@0IDH%KYHGrO0s~KEb)Og3iA61;z2z
z+~d@$`FFXwxlUu<+SazVCzRMTs)HX$n`eL9DkZh)>({TTT!w3m|6vP!?dj=hxiCHK
z`M3Bt3m;#oQHoAwTiX`GY53=E1qFp9oiHA9tZr>lz8Sf7UoxJP@PGgQ0H2}@{kLZ)
z1M>2A-IqIm?M)c3R+g_@rHGOePf$=03+4Ow?}Fmu8%<43UtIdb>ANtzhp50*7#7$a
zY05alpsK2RXO5D7fML@nZ5^GpujYR7=AUa=_0K>5Xp1n-{B5i1stSyZi15efrW{T?
zWccKOh5MD|#mjLjms!PQHl8eT*B<^^aBz^e{$spyV4m$K%`DRttw1I$m;|GE++TG~
z&BKdrFP|3_)GRM8P_}FddwlRgvd_Y_UPokP2(bjfS
zmmgnqBQ%t8c79%H*Dkgbh4xqVQZ>^K#T(|G{h--We0f6TP`uKO>S`)hfEAgY`t+2;nr-IU^!
z#$Rn_+1|J0*IO6a`0S)Ig)-1lUY_1;SM0M;s9T1+(VrS@)=o7Jii(ONA~2ZmmKJ7W
zl+4V`c3x~%pc6cjVM56=mEZ}}c{M*Mky3cEd+t)nC3GewvjfyloqGXn5G>_4N$~D*;`myx>k|$r9h+XLk+f)7R+fkvdTggv7V`a6~uHbn7@vOy}@|E2`
zRd?+=tP{>Jh2OQdwe=PMPB{E=^+@^3E2FlrSts-ZnYJXfaY+grITwR5C?ldOqP_#VW*3}sf`pvX?tWxKc
zJchdM@wYWHO4MK@F*n;2E-Wmptw*UuXpw=%2{<0Y20q^7KVA}%hj
z_ltoV2PHB_;wawo>w#nFVA~64Eqe!t)P3Rnx8vd@*9K_FJGM(=E+W5K_?>*h#mD#5
zKKt7rVJWGD%kmZp~~{-OGzu}t6atjxGuP(VpZ33fvL
z%}u=2>~H#ddcjzY`<_01x((y-MA`M%ft=jj+n4@)72DuwYI=uJK-HY6!;?q9Jiu3f
zwN{u(NC=Ci``53>-qSNPToMuzW-pu`8kK!XGkEvZEHCu-%~hx!jcEn~eG@3qYy8PJ
zp)++?A$lY=e|p8CrEmj*0)$o-9nEf(+1!|CYmnlVvM-zys~Gilr+A{G>thtQ{rL7r
zj~>zD*JymO!QkW)>T=(mXXE4z@RTfOQZWU
zzBxr=^}T!dx_|!`y>;u>?U)#0A#G8nHE%x$b4Y~NZ(1ARHqfZev*+T|{Jm$Y*XI-#
z-pM?g&C@J3yAl+nRr7NtG4)zCS(`-O#VNW{AN5z$`S-girA)gIegB6*RiTQVDEBS%
zUYhzQ;*+T6cZ%q_UM?iU6mvGTO5n$jA6+PoB7In2^7F09+6-jbtVp?%wdZ21x}BZ)
z&Ye3AvySiHCMp`MSIWs5T7RWjetqg>o0g{LXIyQw7?PPOq2%#56s52Wl`-8ki^qST
z)%u@>4w<2!#AI#i*%`TI37)XEwx1HTO-(uHXGR=NYU}GawiG%XE^I6DkRg%|K9JwP
zf4^)-3tFT7kK8p}(&p+YcG2UwHQun)=XrTr*{8~$Tfb!`+r-tYSG9d>uPq-hu(N5j
z=y?;CgSA;*TbqKiNTboz-`$bw`t#?4Nj4@=yU;@O#Y*g9tJ+(;#jY&R{T3)`8||tJ
zQ{@U}czI>!nX$Ze9Sh-4BWw45U0n_GiFfUyOM0EiD}J(DP>2>5wtI6$H;@%}Yt%f7
zab=)@FO96~sm7HxHEXan_8&U*OK_i;$oRy>*q`ij5>%Whx_G3%th6*DF)W|L0YF*
z!e{5^#4d##{%nzHnic$%O+bLz!@~pJh=V6KDvAxYEMz!vJ>jO*X3?&bW%_`Tv9O?E
z4bj`%yWPgCj9)`T<5+#u5uDk~e`z8%PMM$_w>
z9&V|56P1|AOhIvH-k6p0?T-L2TSL@myMnXB6Dy0q)pDG=G)t#{UhrHPE^0s@O*awm
z{r&qvfzRcmT_XNoao2v7JU(!5{QJue?}<&5UVE|3ui~~Ol&{ma`!!ScW<^A>w%+cyqo%t0Zqvf}JDHrz
z6K4tarTMAI*w{d9_U}J`@}R!+$ji%rJ}0Ns!sUMCpRnEy%LQrq`l_lf&sse_
zQN)y8I==B|k>kpDhucw6r)_O*$77p-O@J#LzA{E1$uwOvdQN_Cvf3_g#_unjw=R#Y
zEN6e7Lf6nbbcm_Yp=B+>Eq9JZ`cx?mqsY^|F!{w`Y-y$=MK4C2#1(Pz@i}K|He%c)
zE}^xLeN-OVp4Z3G`tD?|b&&3XtvaFVDLP@H(w|mU%yjrU%H1<_cbAuU_(_i^Ys$6|
zP;XdROgBo|I4pzbktv&G#a>G_KS+LOa!Lw?gTuyT=ABHr(E*%!?m2cQ@8>{Ekqma+
z7}}JOswzK#$1IS^j?3fLZbRR5>hz!ZnUwqbkcjq2uFVV2F(FnqHcZe=zD1-st*&l=
z>&r`-b=9Z)KR+b+PsR}bGwoNHF?==ObF6Y4TIAzYeRxL7X81KVHAkmg9JR1%zkcPc
ztgKYI#D;6rX%O9Hq})}?npp^mctIom=_@_7Dw0q;>d5^aI;glEX1>L=GqqtSQ6)v{ExEijue5_dLXo}7z0O8JB0l#W=$B5|Y
z>rbCbmQFV6uV-YeMx7oVs}<;Ze{a|KJX_|Q%mTOKl|8!KJUWg%b6V^XSn)3_+q;&D
zkG6?dzH{hD-sb_gV>xHm)N)2@D=I0G1qQ{l3bZ2R%FN#`e2V9A!8Z_y^}M{ic^@}%
zm=$~TvH5vDs(bTB2WVOdn>q@tA<6;FA{Dhsq;GC+F8Rwq_1CYa=QFWJU3%*%_f&me
z0;0VA^oc7nS)i7kLV^=)zSJ~%CgUi3bp;o`g$|~srM<&&g-ws)!neOZ
zJO~@)P`NdS)l~Pu@s$_=6+sIK2mlCc+O~|o9uyW9)_AtEbQ80HYP56Do1lV%0@kBn
z9v`#;T@dM5`20{yhwTZT=PkHZD&7!BWVl6_^pw|q`Osr&Wo2c&M@i{8Q5S3B`y^Ue
zR8+s*cPYB(rC#c7jexap(SK6WI(IsCs;6Gm_U6me{HyTk_^DF~=C8cXy1ToB_f~NI
zMs;x+Y!WN>U3z)jKKhc1)19`Z4olhnfIQXJ)$An(XKiiuO-!O2p5DHpYhVz|z$MLY
zmM!Rf3~iUDa(_}%Ts-5ukK*p#N3fKHckI}4`@w??`O*Me(&jIc-oH8?4fr2)>(-tA
z{&Ok!B=uL%tmKxg#BvM_47h-!6nl&$q-tIMr4U|q7z|7kWjY}v3=KBtlr5Rd_C$^DpfcjXf2$-zBg73*SCAK4gi!F=o1kviDAAX6DWh
z(v%|?OS{Qy&szQG<;qZ2@aU)${knCrI+7-D{$>62AwB<%^#_|zD7PJ++%j42ciiri
z)rvt!`QOdeMhOFwTL`o0kBxN4?vj5+q=t9cT>Z!z&-s4-tk_UT?h+d%=BSD<=T$2{
zwDvmt1OEqJOz$xHr-w3ld2?h`h)+nw1Z}LTzM6hcgN}~wWkrR$eys*4%l{&J{3EUp
z(Sl>EtSpOC{Kv-A5o_?|TO}pmH=bsRQT)#^{@+9MUnBHCcW3E;#51YMMM5
z3tnxsIWjIT6k3OQiTfr%ySk4bbpW~0Cf3Iv3dCNs!oD$Rng-h^)r6*|CR@I#5pWx<
zg7D_dqp|xJNHGAsTJMpA&`trib;&z_#e1}C96QGS`t@sa6i~~1u=JdqohyN(0E#DL
zTjG>Gq#GL>KVyZl(q<#CZ4*^iE~%au6nfW_wK3VHqPBM3Na+L3eYc1niX$=T@uG`ioKnZxd9=K|
zly31UUIYG3#;)yeFH=Te_up4!_RON3iFn~PCC;=(iJps#OYUOp_w65d*?#=DeA*TC
zw-&ob7M((~rEK0D6c@(_Ouc5eUDNCZHEv4GiShCqOGiI0zbi>fN)i;40^(sOa&d{~
zxBu|4uh|ya(QU=9`_^va*+x8aAO2~ac4!NoAgW#r_HJr>>E#J}f589kHW>DuKJ#vL
zg5-GO^7X{Px9r46k00|)`Jl>d+6GhJ;ZRj`I6?l(Ut^@N5oj;C>0Oej~xI$=k(8__022PC$Ciy>BmU8}3J0JliXpqmmHo6E$ngA~d=Wshfs
z;i368rq9g9h+ZsVA!E00Lqo@!U=E!=@Z6Vf143cEdrY4xg>vuEgj5hC&oD%?Y+2`|
zM(cqdk9##cm^dEPH_}DBYCNw9vI4gQw2m>lS5UAUY&sO=N5Tf%hmIg&=Y|a%bO86W
z!&jDP$`yb%AFdXvs;Y_vA;9XnXa8q-cvC>7|K2Opoy|urYCv?ly1TD&o${o)7x;mF!Dsq!8v}8!IU`2b0=M^u6rThH!j&!!LKs*jb)ryib4mjM;h6=&~CWfdan!nbGIg)w*U9y`}<_q!WG;lhP{pclx5>M0HEKhFZk(-D{ik(T3TW*V8z
z;z3$vUQ
^OvyRQ{++ec3hdZ@2jU8d3$?D+`k_T-g2fVKPTsETAC;@?!liVty^TF
z+R&p4x>yc2J*oTjsdl{YT}&<}Yc+94((H`MQL3!hn^RM5(
zds1UhX@ciPXKo<5n46nia&mI$Ahd(n8@|j!8J?1R#S3z03=GoVzwe2FzHsW)DdW7e
z2LVMnBKH{xGx8}IqFgLaB(6lWi5}X2?ATqPR#T#`yCx)NnBfZF1gVS>JMEgbE4uYZ
z@F}|=5PP8DoNO#3A)(JBZ@-Puvnv
zliuUl9t}+tP%#z_5_@{QVV}U;fiGz`fYLj`sObdNmS+UAWO
z8tVHv#V`G-=Ad-o*>6Z)9JPs`aDsdepu<$YJTKAi^+yV~unrXEre5l`@^Uq7)*C3t
z+Z{YFUnWI$?piz2%dFi=Kk2Qw>;jq4N
z$4l}#Ia{LJw{PE{_61m{*2?DWSs{6O&cA>Erk^T%`F0-t#(T11-+q04)bxOcm!M2o
z6R+Fb`2p(03ll*^A*(T?C2HSF#8p*jD_uiFj50DZDRlRN5NRPH0qC19At|z6WvA}F
z{)ujDcWI#G$R;MHn}^aEbo$B$S^mqw$#>(krt9kJTF<~B;kNRdV_ovbBrryuksGsH
zDU}bk0y}^GI(u7=2>(Uf&Mi5oaPi_rCs$XA!dodRR*^DaT%4TLqeKq!w}k7Yh)tI9
zn7mxIdbJThtF71cwSWK$C#Pw@64R}18A-3Jsu~I|9F?{d6?z@sr&R^GVfASC2%+I0XUL{5+h6^#kwV4zOGw&E^#8g0+N3Ef=x;e*tKj0w3Z!G5oUgdLY$i$@R=3Q@c?$gZiS6&VwA
zV`#`8mPZe^{r6Ws%5QFM33+z1gs1G#t4FY1*aMjbq{n;{OifJ4>!o;BXT#ZwtQl@A
z;W9NXPrOZ~2V8jrwPoz<3CAwbkQ__5$$jMQrN2k#`!mKF%f98Q0+k+J_%&(d
zpw@ueCYj}(74e}{cX8RtB%m4!+V}AC#IJMTp2Zuz_Y3_4g8af~K^}~-;g!#V=AXX4
zzOMd;6!J?+ymj`&{d*j)mu&}T?j4<84x%NP{A)1e`!3CIAl|-vC*kG;k-PfG4>QKK
z0mg+FzDbWwPO=vqmpXV~jUJ*w^e~I$JmK$g%kO`JpYa?%A_P(WRGW)F$A!XoOu(O=+N|q@)lLxLdum
zXCE8aTFTZf&P~+({CONaCKc2$x#8R+NQt*2A}pIuX=+}>u0CWU9@CV0)Ig3W3^m0>
z#2`VEc)xNrG2&1f+p%*_FH#NSV#@r4l0|LCs=H9!$&Y|gsb}WqmJb0)4@26E@fQ*r
zAMMgYfeTkqRMbUPGxmUkKw`ir7Ui!X=p2HE(TBUK51Iwi)N4}{WrEs8*5>mK$u}TQ
zO7!7lWA5+1pr@|xZ|n|Q*Kkg5r{}2U<|pr8e3Wo5y(GNw|ogKQcf>7KE%0bwDTl5XmKg++J-x$p%^?Bopu
zuoDuwv#To`=7f~kjmr%ZRq>QqOEu~7y}i~zNINfll}xqA1Hl|xp0iDP2^2#ib~<-c
zQ-?kURh3@xIyN7UW4gAYVt55Ta{rjjVKySI1S`Sa&>rcPZM-u=WVR?>$RT@q58QkA`ay5qX?qLG7dkq+Qa1a}h
z6AyJm8d|?>rWzm=d~?owa;;@oxb}KYg5%S}EDv6o86j&QDTTjGHcAq_w>`KnrQ|Ew
zoP$G`P~7PV;m4?g_wymZEX##yH1Bxsv(QqSk|_%gmOx{shl#WLUH{=^2T2Rnr>hD+ugkis0oV8-Fym|
zsDbJn{pHJ->tg}|vZ7u%*xM(WX2PN0)Hx%uY0Xjo`rJ8Q9h#Z{RuzEUxM^
z-wDG@+uWSbf8Ws!HyJlygK)73VNhoZN|6x;hI!QjxL
zwFEi{Z;Yt0@M+K)BB}M4Cx99F5gwk5?}&#@{#1S!Y>HqF|}L_RQO{kcd&T(
zk$bY(sp}fagm~o6{Yxw#>~R#oBzoYkAe?u&6EdLXr0i4&Y(zSpkTQEQu&6_7N1Rb>
zNaHHwh=ij1&|Q?LeT6{T=pv2fetvXdFN;QL)I=6aI9
zKXKC1GAXr3kYPPD^S)!pj>(FTWHtv}yLJuc`Nu|Q_5sWHll
z6B3vx8V3$AqL&@K9nuX}bNhA#ehI17hELPz5*sUP(zicGxJ99Lrv|6I&{MRiox{T?
zt@m~|d=UY0x(O%gZBK%*n1TYgQv9>eONmGMXu%YarCjgMN4MD!#(<2iAE;5|8HUR*hZI+Vad{U`{*XG%(~zJb4fx+VC=IpKTp+{kWml}Q1`If6&_rYrdP=hkpouf#Q&S;fY=upA
zH2c(UvmyX$cnYh5TXvdpv9ex6go2EfAishvjZXFy*0wZO+|8O0E?$S&$jGa}EEs0B
zBdw=TpH^`F_5N^y29;wS_@HrPsy-L-IN%n)il;xU(^Z7~-`4ZFCs8rM%;`HD-d%8ZfDb~T>D=C%U9X6rxyXz23cH>|9z
z#9k`}cus&i%!HP=tv5$pO|!hrH$UT{Zb
zu%J;z=ORs_3z@Nx^a%*aJK0Z90E!S17;OqAC_J2t$hE9oMWFyMN`9}6CjAH@A(w$h
zVLCyG1~H`i0uGB(%RrEE2^H_z&)W-8G4;^j9{~q<_w@-QK4O}EN(x^|La5YsWCChB
zIxH|+;$*;t82@3L7(}bXK-GNuM1nuLbDz~oCj@UK^BVAEgoJip8Z^l%D2PGUCiMfF
zT!>CeBp#8cX0nP|Z9ifx!fI+3$Ztszz35Wpj03Kpxo|;(uwI-UyPcT0(zN2U3}UxI
zK_Q}!K3gH0DJnoY)+MKZJ@NF=m;cL
zREZ?Nm1Q8SHvrV3zN>+@$hI_qjOLA~t8SRTtiM?n_m26!6R
zQWaanE>dq|=LmI0ty?$RpSuF#_;c2YJur_^#J~2tYg=1Ca(U3L3*~fOhu_LxRBSpG
zFTK~ugCR7f7Z0zD8~gg$OE)pZRtN$;=~$W9?n$pQ-3PHU7B?Zqm_9vr6-=iJgcunK
zvM_@=FhPS%y$GLm3_5^S$15L<7qXWAB!m9KkIf9$T7`63L|hyr0ghJ#^wdz~Xp!>D
z)zx(jiIs}VN;=%3=bx-1OGn3WY<$(`5i0f9>2AYZ6Z871e|Dm28zcpO?@
zUb=u%b2tCVw?8`^e#)gt&|wg3(Mceh>sy~a+l{w@m6M7>#DfP6m<%kL$~SM;LbQ4f
zc~4M?g>wDo%`;dbxD{}>bp(*aY6t>{pH;JS@3f{h%wTnUtaoiKN<$3xWQ?N
zWLUUKq*piviQW91i$6WFN%vdPZ6I55Po4xlCMJq7k|bMmE|
zhNk8!V5VoGj@v(%csLT_(rx>w)QYOA)lfkUniG+*(Y>dax^v!xg1m;^Lpbx9tNe8}
zoqvDaf+*N(gq&(fZ*(0qf9HR2YYjZqut9WQE{IC#6k6xbZNI!J*JV;I-(W0iJu^EX;aQ_~KC)E@iA9CArRUq}gkLRiY3<{FupTD&~ajeaF-IE?Q_P6$Xyi^w5UR2LJbH-?p
zFdRX*dToWJta_^PLkKiFeISwjZ6$k}?D&&u^*qZKy4G}SiX=AjMtm>3;sG6!Txn1=
z&K4BGr$Bc~!n;OCM=JnxSBzBv+P)WD;DRwP>(*~5=h)7tA1hr0&jM=KX;WU{z*lqk>1k7bEh$;c3W88iRP|YI^bkxAerPEa
zU;k4r#_^N)ue#gOckYOQ50D8gJ$LtMwt|O9&54NUJTosALN7LGx>;!%as4`du}fbt
zn5U`{uMM5;t!?6b0=3&R1R-M}G!>F&rI@A|KqftP-4vWzqaQtYh=#tc>0wYMRvWHiMhB_W*q`=C43&k60>Gjp#f5pp95XThXCl@5=mzZYhrP$=Ka{mRD`Wn`GwG4WL>
zkCX-=HQg0upn8?2;=BO7TM2~N`S1hI|jeXeD!5#Bw$_rO_L;E)1wYy>YQU94<{DTL)B&s!W2W@BM
zm1hL`x{lw$TUwzyICi|+LOchDg7~=b#7bC5=-tK*8#MkaG!9oX2|ANO(;?JVgdF@4
zeo1k;a^=dS)Kra>29*$}cV#>8DX_n3Y2hWY5!?<^x+xv6mvDmXkwNMwWZ6UJgNjti
zXK>ealkoPQDX4Iy3JPS3N{*623l1ik3#1Zyf`tMjnh7%7jpJE5kP*6uhaH;s!9Tv(
zUK#`^mIV56cBvqL4FF;!Ac6y|4$mXU_7gufXm8DvTgSCwz47|n4Z3JyK$G}_7w*WXNJvqM1^t8G)OfB(K3AOxAS
zu%87N&}sSWcg)sBZl#5XuOmo@9z=u`tpMnlWAw;CH_|dyD7a8^P-N9HC`qQg7B9;E
zR#Ztu4{pyB?+5?o7RWm6h==5@<>ZKUS-f!}f%qdiB)vn@(rhFDlrK%6pc6zJK3WeU
zsTUSLDZG;I&VL-~wvr+oAyB7MNislZnM+CwROEi#Lp4b^KSLBe+sQaVAu
zg_aH~6;6c?sa;>5_^>BtIxjaD%nx2q_u!y7g8Gmq*>dvoqM!u6Mf5A|m4%MZO%mP{
z`=PK^fBbmpc%i)*8I~bj0H|#zv>s^uYhNEouFq%+UokiXTbz1LP1ViE?B0!xs5MvV)QBb}9&8+WGRGa+s&EQ8n?yKFiXA^ASy;ll}2xxdwzGN~P
zeyNG7P=q+PyQ)%yjFW^H4Gy%QWNpmqvG1*ZRg`~eGNfjm56EK{Q%KiN^>ev@I79qVMkP6jWOr4KOeFJ&AXa!Y)2^a-_oo>aI4G
zOgY0wmEq^-cNuBlo4SM+xPh2kUKr8tH8RdeA{Oo&yo7YQn2_p+Xv#Yg5vE*@<|86-
zWQ4c*ZGAl%);j+==_;9MqEZhfs*<#6d~xCv?iWS{JZc7FZYb~5f%!SBZl}3%n}1^s
zyZ_BEqpglZm=31ZLGytE&%I?~q_ub}dCCB|vai*M^GJF%zy~caFAtiFA(aa2R2wq(
z^V3xa2GQw{5_NE`qjSX$Kc?xV?8qQfgX@VoeEY$l$lUppGEwoMVT1zS{ki|T%=o$5
z#&dGHumDrW;m)1n+ptM7^7tTclswOFyX&A`C@Y&Cc6rY_nPi%Ncq9b@n>1!SPnCL72w59*uNZ9lmys@J~!k{8xzuI}!pUpe@`WSbXXLt_*V;9!9GoQyFvXqv(5k;Or;MJy9iO&uQ}$8Xjm
zX0>{DsWcZ2LnwSHTzOB-kv?f>l6w-!`+iMV0jEYU5O;e}yH|6o5Tsa7cq?z$|5!x|
z?|GS-7amS6n@g`ea6JQPu6>B#`1vlb#R&jNkxP?aK07-6Y3VLxS40YnN{>;LH7m#0
zk}*)sz0frz1Z;nn2L`Ug{oX{#80CSUY{)PvVkF+Isa-B=_hLZQQX)T0O>}3Uc5%rO
zGE)QWdf>j?27;75iST8+BIHGIkVFbGl>>+7{eJcI1YjwmjNHwC2m#y5YNGnn2xqG_
zf{(k;FN6=ThMq6u-;u4dXk>3c#5QF>HK91*P!=TRy0>qy(zvCtkoG~+J`|@w*V*8#
zAT9mT+Vm|H;%?{|RCDuIwi+_mN}d_RVtS3cCrLU47L2B6LPW&qcPqckhcB`Qg2JIl
zttKymKtg7(|IIE~V#5jR-?{sKd-1sjA*4JwAg4(c4&!7O-G5>b7iGC+QFlnc7j)i$
zy{M!_8Rtf>qTJpciX+qffI&IP`x5FfA3FQ{X{6NP6ARPe47#yFlN!ZHn;pav%a%)t
z>to0A^qy3v(S8*eoX<%u-s@egOzpKb4AF{LGfcBKRxGMDo${Ttftk>aIDQ3i{tj$0
zn|Pc>0L?M$&sjm@L8o>(_>GXk5v;3v8hJ=;ePkRu0bl6nri$OfGTv5bK2y_sq9#2ok5U>{FeS$xQzGe{wQ)x#F;}J*1^e+
zlqM<9jBacsk(`ywO%7KP2qOckWG$4x*t#8$9svPoKb9pK8ml*F6ADkzT`QPfHhmv@
zoH_877y>oXQ1?ckY!nhdXfypJ7?wZ0!EsC;`^#6IIs4Vr)DX~u6Sx&)#fBim9FFbv
z0;-LpWYKVl2E}!I%Vx&4PY$Qug3E;+zi%6MFOF{DG)NDbkX_?{?8FJumJ9nDuj+H0
zJPL&LYc5u|qTg~Uc#w|D-o4~GCy}Xlw_RowM3&_?1cGOiDVi!MgydI=Vw5&)w+$TGrCOKvnd%NEEXVM;rmbw}CbFT2_Aus!W8gbSvWLczhe
z#}KCU71t_bLP?)A%C#EmO6bScYr>s4FL|#3`oc9u#`?w^xH4D;YKn?;8_InKwjT|u
z`T`v&20%e~|9;PI`Nl6_`d;5)5Wc;EhjFbgB6sQO+ij9FlA$&lk_Y6Xs*~k*I16Sp
z)i;lIn2U*tL7+@M6J80(>4MNAPG=x#8JG5VBAajFU2ylUmA=1Eg1gTZ{L~b%S(Jc=
zAI4weeFp@Xly^-}{wL0vPsNFnjHloNA>QK8pjNFuo_}ua{rsXt?ech1Dylbp{T>S5><40b3w@>0M;<0Xsv(hAWYzK(CTC!KHJPxX0*Rgh`UAskXBbhQsrpJ`fN`@aC4H(j0p

diff --git a/bip-0002/process.svg b/bip-0002/process.svg
index bb61e8e6..b8c8a4c7 100644
--- a/bip-0002/process.svg
+++ b/bip-0002/process.svg
@@ -28,7 +28,7 @@
 	Accepted
 	
 	
-	Final
+	Final/Active
 	
 	
 	Replaced
@@ -46,7 +46,4 @@
 	
 	Deferred
 	
-	
-	
-	Active
 

From 95c8f65b11cb782df299ea99fd56a1b3735ec5a0 Mon Sep 17 00:00:00 2001
From: Luke Dashjr 
Date: Sat, 24 Sep 2016 06:22:33 +0000
Subject: [PATCH 40/68] bip-0002: Rename Accepted Status to Proposed

---
 bip-0002.mediawiki   |  13 +++++++------
 bip-0002/process.png | Bin 15691 -> 15714 bytes
 bip-0002/process.svg |   2 +-
 3 files changed, 8 insertions(+), 7 deletions(-)

diff --git a/bip-0002.mediawiki b/bip-0002.mediawiki
index 8dd8bf21..897ba05c 100644
--- a/bip-0002.mediawiki
+++ b/bip-0002.mediawiki
@@ -125,7 +125,7 @@ Each BIP must begin with an RFC 822 style header preamble. The headers must appe
 * Discussions-To: 
 * Comments-Summary: 

   Comments-URI: 
-  Status: 
   Type: 
   Created: 
@@ -178,11 +178,11 @@ The typical paths of the status of BIPs are as follows:
 Champions of a BIP may decide on their own to change the status between Draft, Deferred, or Withdrawn.
 The BIP editor may also change the status to Deferred when no progress is being made on the BIP.
 
-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.
+A BIP may only change status from Draft (or Rejected) to Proposed, 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.
+BIPs should be changed from Draft or Proposed 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 Proposed 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.
+An Proposed 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.
 
@@ -208,7 +208,7 @@ These criteria are considered objective ways to observe the de facto adoption of
 
 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.
+* 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 Proposed 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?
 
@@ -390,7 +390,7 @@ Why is Public Domain no longer acceptable for new BIPs?
 ==Changes from BIP 1==
 
 * Acceptable licenses are redefined entirely, allowing a wide variety of open licenses, while prohibiting the problematic older choices.
-* An implementation is now required (when applicable) before BIPs can proceed to Accepted Status.
+* An implementation is now required (when applicable) before BIPs can proceed to Proposed Status.
 * The License preamble headers have been added.
 * BIP Comments are newly introduced.
 * Non-image auxiliary files are permitted in the bip-XXXX subdirectory.
@@ -398,6 +398,7 @@ Why is Public Domain no longer acceptable for new BIPs?
 * The Resolution header has been dropped, as it is not applicable to a decentralised system where no authority exists to make final decisions.
 * Email addresses are now required for authors.
 * Markdown format is no longer permitted for BIPs.
+* Accepted Status has been renamed to Proposed.
 
 ==See Also==
 
diff --git a/bip-0002/process.png b/bip-0002/process.png
index 2f86230216442879c13f8aa3ab5a12b0d35856fd..a834947f36aea765ff9bcd0f4efb77695fedcece 100644
GIT binary patch
literal 15714
zcmdVBcUX@9|37>tDytz)Ef=DJN}5u*v`J}bs7N7cX{SMGOB!U97EMtannrsnij;O}
zD5a_Odz`-a{ky-Pn&H;b)K*D^?W`b>lJw7xXQ+L-0KK}*r=vT
z)gg#gjQIaX20HwyUmui&FKg{p4X+RcV>$UBO_T`Z7J?8U)ToDa-5&k==5C^^w?hBB
zsa{Oq{+^9UMbyYYE^n=T=vH*>i_1K
z(-vWoVXD5{X5FZx?Q+DH{t2^^iMeOP^?eg|uKtfH@87+1>h0~FRpd#V?Ca}e-m)cq
z)sq}&QK@(RW!(J}P5otZMc*cTo|V(!RUd}xXA-RigoW3=eEBku@%>Y`MFX<~%kGN?
z=kw*4TcftDV_{)YsJ<`5%)%1h`v3gPSOM|L&uVg@M#g;oxb!>6AY^9>-t)EDSqQ`Hqsb-Zgd6yrm#S|6EFD@;K
zJN-QI%DS~yIb83umg17+yLaz?{~gKdklUPX{&#BVOYS9u*Bu?NF8Vbms#q+}O}Ndp
zpPy*a*sFKpz{=mxWq0D@!q%*3?|eBnSa)w?@lR8K$!ymVe@0%-yoN`zthjSdF>|6a
zgzHLo|Kd!C-Ndi_?!E}EgNOcnZy5Jnn5{eFTDf)WR+@*>cKWefHqdR~zP+b=Wm%eA
z+BU?s+lzyuv(+n%M|Knby>cY0jPdbt|0hobM!U=S8y@U`|Mb{H;Uq1O7rgQ=8^p!M
zckS7uU#p{|BWBli;Faw+Zhr5%_>GC_g?TpZXD4Z|rA2R3xh)_lNVjIqnhzt>R$+JV
zZW(Qu+_}@Hv!FR?v`KNL{7;i&*wDvk
z@4tQHjo7JGn&mY-?P1fNy@qw?@$#ba()36>{N#pM7w=iyyVCr_Rf
zx9?HXjFDJV;xT=Aq%HF@CvWq&c`RN}U*B1Whi}c5OilS-8C~9?qF4Ip5l{U?X{NZV
zlWQfpLu>LL%e(eX4%WH#1@3%dQN_4jP%yzT$I7);%gBhkrKP35b{mEA`};$?cQrLb
z&%b7hGFkSS2j=HXOWAz!ZOb&?h8_FfpUMB;Jr1I$^Ys;b2Zux73Z296-0}5Vm^t(1
z#hH}TMN-6*7cZDSXU8gDU-{AV{rjz+9&<^%E*|UYP*y25HMIi!-c{7qjEsz`nwmEr
zKjvLt{G-LA=*>gePY$RR6cr_!mUu8QFuZ7ZsKgXaDBLgz~Z
zKYnc6wvG1MwQG1#r%F8bTYr8Y>b>+=XaP6JNYBWlWNW)e&grMG)a9@DUx`p;y#7iS
z7Z;yM*Wb;9z2G@BdMz%F-(%|MnTaFC1qGaI*RCZm1X~{8qj7b04R+YMV@L0Y_#@Q~
z4M%gV8a||++?m7FlPz
zJAb7cWU&*I*d4-_s7nd=$#XIL&fg}O3CG1b2No8?7v|Rr3JZgRgM(jPXg<7Z)vDFL
zPNQG6pPw!gq)_=sn~TpiS6Rz+7F~I3lm9p-K7+Yj){qAe^nSql=_abv9Z4I-vxHj5GStzb5a-@rUnAi$b%91eI7*#RjSxJxeaDW9?YI2snbhs=U!>>?PfSd(
zgeq^_vuDp_f0*KfPjz*55gev&hll`wfB#RZCshd5y6D|I_U~^^8oRlkBS|HUZ2>1Tsv2Hh!
z-*aUP{XRW!uB}p`@jW_=D$Pfve!@ndC1Z1aW4>S|SOY}}q6f#b)IuTtuA>)$BO
z9Xi<{-F<4&^h>dOPCx)Ug%+WzqjMKG6pUp!@b_n;)sjhxhu$lrOi{B^6Drm5$`#A<
z0G3rssHn*C)ZX|0!KPVdzee^nmGG=Eo$h<`dE{uOzD7sh<*4jCcbMJBUjHbssZsmh
z_*euDF$xW;y~H!0xZ|_@Cr;7WVnd?3(0N4oC!4{e6-E2B>G#or?}OMxG;il*my-==vU*#Xs*O!XwwbPOBp$3`
zo=prMj5z0p$(o&U421jq;JqlRx=sF#kL5M6XxQfJXU@c9xy%UFdwWhtGIgR!Ui|Rn
z8kW;&ezK{)J`&A7SU)`qvr6b!>EGe>1fA4#AD#xpV!#xT)IRNgrBH8)+S$y`kJ
z+40Ba4GqU;M%%Yhqz~HE-JQv1I?NKDl(fCsI=3ZJg{h{gi6gOjSJ}#P(dyN!1Jsk#
zGRotP6m7y~P~d84Fav1!5iKn`HI0qYG_-Vhg@oE+bpAcqywQ8j_R#qqqS|g}O;iru
zL^#gf8hH^vRBGGI*gy2mD%Q9{`~y(Dka(P{u{U`#CBQP_9Rm$r&q+CfB*)e
zJ$u+oO!uOaS1EbV_0lJIC8>3Hn+Q^R5u}Lw9f}3S!Wo{lG!c9jGA1-ffJZ{w#ds%1vckla6
zEG%d4N=B|_V7Sv&;wjS96sNeC7{E9ePpvBNee133(q}Hoy<_K275yyJ-KM6d*vzRm
zA{snoQTZ&-KWkBTbj<$J-d=+@JN8wIJ5=Jr2LaT>-SF_O6rUZ8(<7hnb#|IW{Pm;T
zh;%}V12Zx
zA%z&I+gm0XoQqD~QtW;uc?|uoqN~faF;?M{PX4G}P~eePh2^?U^ooj#7r(rSufa4t
zOs&=8AwKSVN1@2Oj%|J;`Eqgap4mAxSu3w+Nl6SuMAIMn9gH3&rdPeZ2Fq5KvMPRM
zl`R)aT7OcNl`?p4B18-%h8@%y=G;J+YF1YI%C5U>wB8UfD9IqpwD!s+R{!i9gG;mB
z(y5=HY4LN(*gsKwY}~ysd`qA|x=6+N3;EZl`%YZ0l&}GJ
zMK1Qv&POj?NU13`&bM7dyt?$6k&BBZfw-AU7iT@AqeW~AB~TXSXl|8
zx7siLb-s}MwQPERar(2_k*v=aqhDTHbx>Dha8&~2#_OaK1VGbuKR;S>q~>>dtS9co
z#@-GI*??}Xo@!t<(O2;zXJNrC|FN9&^|CU>gv3N~%i7Jvn37Z*PYQdLxFeI*_*
zysYBexA1V?h7DA#yUVYyH+KSJ+0B~8THliiV9+^vvZ3t?!`ihkW$royAGytbb9I>d
zsg3sJ=H~XMy`9U@(2!?9b+#eHFekG42iBQtZZ1GV%9;4}Z$^U;?BCBuh%z#WY?(f-
z|12cgLP1Q7nTWh*oSK?C_KGdyUU&Zd569VOY1rur
zorY}rteZEVo9t|EW+6`K>Lx`7GFa8$zXrIf^GE0kS=$M>79p$n+*RbumQKtUE3ztwZ4G*RJTaq=t6gX^?vg-;dD3GBlE1#_h
zVpCOB^#v%Tu73Xfd3Algs5E1yelWUp00RJx)yvy&%?tWR;_2`0|HzVpJkN0ju3Mm)(!4JsfD6AgndNj=jZijFNcCJ
z^r8V&F)1$kUi|p9w~F7V94sTVxH8-Oq>heeBeiSPw$Y`t@kl=L>2ZCm!WKfzdvQ*_
zZ3(36j2P$d4!g2=;BEC50ZLT%g|*@PYmW~C!^T`jdthXg651=DZk}pu=m{o>CMyx5
zoLEta|JV0kyGnX_55UDgb_Nbb{;S}z2RE>r%mIH0Ta)j*iaLM%{CQ#WM0%^ey}hq;
z;x$wcTHWr_rx_Wd=|0C=-m6i?e3q}iy4=BT=CiclDAzjKgilpVOImiHgS>Jg%Xrz!
zK|#&?gtWAD@KOfW0o<0EB|=4CpBs^(VZ?$(v;u=ay6j=R>^gzFW7nl^6=eCh82mAb+LmVzkMpjm+
z>`g7Iiw=ZCKU2wYMq|9~WCe9rqs)7$r>Do)u5`X~;66V8RGtl2aS5n=f7rv(9EX18
zoR9aqeO45(%bSxmI0)(EUZzDZ4Fgl61dp5(L)C5G_b4rbc>Ve{10!Q)c_8btVbo!~
zR@_0t7ma3>uY{ua^5VRpvxbJo1bSyYnqY1F4GeYxA)&Q_fq{a~KN=pMACy1Bl#cBL
zc*O>2x1UQ(fPzwbI=SLHi76$pW5=4Tl9>k;zjhvfqy$VR5!+`K8yowxt3=*qtTV8_
zUUT)DHSxgrbIS|k#~LHq*xCCs^Sj=mV4||K$Jb~CD;Y}Id=UfiJv00%)&9zrBVl|B
znt3$eeNMg!H5Nl-=&6ko(Vw=+^p|iTQGb2RKJhExH8mefZQNV@d)48?hspg4o^p1q
z^R<5NM@*;9?CfW;o$+v0Kp5FYPx)dP#e+}`#wwQ>g5NxP^ytNfX38Tu=XD%=OqA5r
zYD!9}l$)p{0KOITg_&QR;%8U8jCX~CNS&Sf+5F|D1^xG?IJ=okX`p>SzZFSK*>(ni
z1Dn@I3eC;`h!gi-bhFGTFL3DZ86OX0*{0kRytniXi1SOAUq%~vWSEaVkkr;!b;g*<
zxBd14w5fP;vMwMjOa*({duiH0^MT}A!2DW@o|eM&=6CPki+lZbB4MVC<3PaVdTU@H
zw?7TiQEL*rJVtiQ$jkR*4pt7grjs4}r<2@O07xD)-G+;~MpMJB>oLYEirxR%57x4g
zq?J`r^G*0Rl@moSzvR6S-U|)ql(sc_eQ&KnrqP!fvcrVYNC*IKW
zU-iZQ+`uch83lV3V=vbIJC_MI*ts6dcJ&t+)JISk;BsLdm2&5*nK3d%O$wNSc_a)|
zc5mOl+M+V#kdu=n3hIeymV!ecmE`vpRk!un_hpDO4LE6bN+egmeR~K)ZqSeE;2luS
z94|b}BwV=FAo_K}#~~8!T@;a#IW;r(O$6jRg@x%Dq_?UA96+<_PO?3I
z{5DDXPxJ
z2S;6`(8(mLh6m~oL%H|sv^l@t(rV4?A9Mmg1neID>eZ{FWfdTmXwZln@brf7g$83yY7fCA>acc)hDtAd{m4Wt|*3;9kj{ln?ftA?9cS(6J2
z=JKWia0WmaYu9BA0@_A_U#O|8>#+Y#-Ed%;Kcv6x$rGjHk7Tyq+iSLLym0f@ty;yE
z`KEP&sYyxHyLa!_F3E3x9c~jR?|K{xf>m@tcjn0FERC~g6V6#$e!F69Qq{{xwlNU%
z*-y&9zUGQ7IkD&|f-Cx5^71%;{(R20h-hGkDEYGs`rz`vfB!D9Pyq2w|J!y!vQ}3+
z!MHU=n-;o&&!sqki?dC!3Uj1Xuw77IzDS-g2V92hgnOBcoSg7%MT#oZASXQ_$7KC|
zaazEO;tFHqkB=upXtnnz=%>GQ9IW*`=%+mOL|9n(FrKAoW2C@{n1eu?@+a$DiO{<#
za*p=)yIf!H%x2uH_un-EI{sjF|l|A)G&H)uN_JjVC;_TtLQ
z*Wqf5mD#Scv4iCk0v{pkW(z&equ2Nz(@dM2iPXP$GkkQxF&
zX=pyQ%dsb<-3X*@zI?;q|Hw03|Ay>qDJi?kD=WXsZAcLIx8T8bR$Jp8{@;BuA%aqZ
zzLa=MqtvbRff9q*cN>|58UFtBrzky-W3OolM2<5U3m00FYD#Wdv;L<%oM0V#o+ltJ
z0G+P9yqpvYA=Tk`f%lReiAAB*0)O`c_LZjRVQ_}tzt1`F{d?Dsl$E;=9t1%+5H-%r
zIQ+Fc+j9N!*aL=JFSCYELj~6pw=15YJ8NOVvSmv!kQ#}BAuHVU_ou(Lf$KV&!SXMu
z^8l>H#RmXK@>Wqw<3($lN2b}@=vmtNuvHWY$Wp&6x7e9Oul`c%C4Y;NH_e8Xg?uM}
zCjMLM$%nz`KNL7vL@fRJ^Tz>7#A-Ua2f1F$i|#x!_T<#R&|RwV_0>fS@mq_FS4Y1U
zaga*y`&%2EOFUgKxpt!
ztw_(I9e`&=uH(wu+AM`mL)Rg5ESE@!1n`}jTw$6qQ&{l%a8y}YS=|x}Z76XEDwI*@
za;t&aTEg(PW3rCR{G=t9n7J=;2Vh$R17fvrF|-Ou6ltFp&=LP>X=*|rN2Vn%wrr;n
z0B?&1wqqcMI`Xry+7G5mT*pl(W@kBwzOk`AL=ry65x2?0;^5-4N4_nx>diIUsHMFo
z1p*2lQ_Mumi!(=34YFcWTCGWasr-WEgQ;A{L3L93LLZozo@Rr9WteLng&A6xqMbPQ
zcWJ4}N$#<)Yh^~`-2BCDdEWi)iu|)vDZ+tAE?!J^8t*!-D;zaxd0CP>*=J>$R8`sw
zozqG6hC5XKy13_zjirx9;CnRM)xP8yJ}brvg#r+)@8{255bSk_2Y>ts&dSOHiBN@l
z5Dg>XJnQ=(>e@HZmhMhVv
z&8%wf?pUP+2||Q2xRcRxx^!_;Bf=4a(dj~`a4;N^^Ss!k!ZR~7>JKeJQACORGAAsv
zr+>IcRfsb(Nk?VUy1hC2j?Rn+vPK1{%&}UGP!b(YjeOP;>Oc(1VxsHz=YU0lJ5TJJ6S|6A3rufIYe7tRh5XUv$BxngO$`VbBG${A4sdswhs@o
zc&bIC_K$S;RaT8?(Q7DJ-Lx{tx4?M>QHV>mH3nRKabG6#m%MGKOvo1L=bc_OJwT+t
zXJ@5{wh*12ogb1l?#Y+No_uzkrXXA0|Nuh=xAe=^wxw|uQpSzU;6yqFvCKOb4-qoQs`4~8#nhk+foDV
z*J7|XO7M~lF!>?sov5faDk>@w{zjR%K$bu3yB#XuZjd$6ABjs|t-;ltqT*ROX}4)yd9P?dqzr0!}2}EYANqHXOuY>ejmkR}r;fDG&YZf+V-7(W`2k4i$c{8((uTZ3Fcu
z#LV9iFf7i@PYw!BqqE<@Hs-XowI!ZB+M#yr*#1=Mt8@0j4$;xkeW}l44+Gjp=B%Zq
z+W;D}32@}taN|SiroIt@1ply1m1O*w#LP@II$s?K&meB#4nP%&i+=yMhwdtI
z`KzSt)wvg>fK0cMdpj`zj;!|;yM-0K>LPp+5K(pVU7?Kj{ra_=hKA;m-l3?#xbDFo
zPWl9TUl>!BVfQB5TCNl_^*7gf193Fn)d06lT&&0ZsXs5!Fz>8^a~3M`(Wru
zy%xG>lv#-x`HzH$tMJhfWbwhbEC;&2{@K)XBdAvuJPGJm%$qh{KlV^69(IKK7H@BF
zQnpYI;k*U|X%zvC{1Sp~@no&YZ13ZwGNG0>8eN*!d4+&%-BZmUr)#tK8y{PrF}C!v
zBrqf-TN&9y@juo*taE%XtbC5}QaG0uvFpqDeyCZIGkj5~UbqbzNR~
z?KHIMxykG6Z{ECdtkQx>+KbBtz4U`0RzoykC?+K*zy18#;C1<#z_;cnqF*pFF!&ms
zo;T2gPV(gA5VXlAIqI#OH-|vRF7wj2E18(^V5slrTRG6LG{ub3ajV8_tF0gf4l@Ub
zeaR$2@G_8D04Nm=cj!9}XGl|U?M7s?9
zgbm!>WcY5B$Be;AAwiK*XXV>)DpM+ugVV3CY@|z^cez9C%)8ab{!}UxO{{}}hwAbd?yZEOeu^l_->KFx6^sCpY&=@U9gkV*N6+E`fH>+w)u+I1g{kO)<#
z1zWsv^CoHd4L;ZLP&^iUfUBaSLT~w&HMq(DMwE=X8fWW|)7dK#usZ^@7O$qGlU!;~!t-Te)5=rH=`l5^P`686Ak
zhcA9DER3npb^JE>e(U?M947jXnv{9-qLRqPL$f&}$xU7gYM?t!hPoP(_dD=*ZC%|P
zaD-pkw6|pJC8}#{-^D6;{stCI0H!2Iky^cURW4Qqt(OAA3ne!DR8~^bY8bULSH5rf
znr|0|Dl%gGIF0qHUdK6S%(Fi7l?~lq`f7*rj4F>?l_n2WQ5~QoazSq>IO$%zpv0Bi*o%ne+bRH-T
zFk6{l=H#%#UuZ9K%~JbjSGJ^&GNC3mt71Q`@tqp_sIqST`Y1W&L~X0aM?x6eeWRnI
zP#HP!4!m+scOW)L%t%N`B!RTUSW3dSA}zo6^KnrSQ`QnA-91G~ABR>;ar4-Y>}?$G
zQehl1m75F?eH2S{}4(2mK~7hHQifV{QUzN1|w##Abrfgmx^
zHd_YDj45mrD`OvmI%w~NBh^qV=Q^HE$}Tolbq{5*0j_EN4^=bhD
z0fMj}{v<@af#NE5sZBI^2@*an0o{Qh@QzaH{l9))cId7xcLo)${@(fRTa-U~hw^Qn
zKxnPJ9r>GO7WVK6hIA4)<)hgir5Nw4bN&Gin`!+Pj-0&wOB
zLX=~&&m|n7NIy67fyFXdxeURO)_2oMNJ)nBbbfEsJ{yFS=_&1~eUK4}H|OKLo<`yh
z-gb5I;Zy7(qg0(NzQA`ek-!$)ckVP^JZknG)BioB8*xl~NK>0gIGG1+
zeAmi&Z!Zn>Y`pGaF4&Jhq}Cn0PtjJTywL>nG~>HJQ(jeG?Q9WN?z>MZSO*eg$5i
zX#1^j4r`0uX4CQ=k}sM2f-y!*{GR%#MN1%$Vy82Xz9nV0KU?C9hyEew@wkAWw(VEt
zz9W4TITUP(=SV7DEx`C>5e`Cz+QiGdo9u^Z^L6|_i}9a$_ghDP>FCf7
zat4s<71qZM*#&~Qefzc>8rw_g%23SjzXE%I36B)ZMUU=l|0MdukP~7#LS*U(otPH<=%|tsL0U~PO}VrV&Tl8);8`~}Hz6`i*2g}L{|54R?c?&gki)7Fx-uZ=p7xki8krH9njNP5nSEWf-%0h5KKmlbHfGX
zFJ9B`-AG3Z2Dp_1uC_Oy&)y0gAGqT^&tW8f`}emrPw6H{7o5%ENzm0r{1Ig
zDN_}0BxQ1OhC%IAU4{)C7CXEkd4EbbXc{gYJjPlQgE`vvw16DAm=s2O`PugN+y7xM
zC`KL+0*heJA7Rjhl6N@WMC+A18RVW_K;
z|4_S}{29@}AP8y>>efJNy4B=&Y7+t3bf?k(wRdny+w!3CCUu(5S^7P5uuVF@sbbM@SiCnUCfouj+5feEy?SZUL0)QVfnPfuGG|NB0
z9Kyw^LMI_o!=9LAVo|ui+UMKWyGtMa1OcfgOS}3@;h^@7jEG?02tAZ>NFbwVrk=m{
z(+J?EYV#oA&Pn(*o69~(kxO30cLrq;nV|>2*hn3vp<8R(xqguID#yj5k
zD)=*@bij#ydG|QEJ?wkmt--hwv4jsqI%OZw`v@gX&5-Qf2M_XLNbi{)yNa@|jk(5j
zaE_o{C-L#8d3ce4@eY_hi
z=bq8g5KOhMj|)gXp6NUBQupeC4@{5S%YG{018IMMmhs059ZGB#5Eb13bLL-=*Zq%G
zWOOt|QIQ`ospLob8H5c#Sm)MW$u$Z^;}Y1t`aEY$3?Xtgfp&*;pRQC3)da%?SE=idosg?3|qOAukGL#GYnXf;uYuCdePi
z_+jdc%Nobw5b<(j$5kqtI
z`}9c{tJa!iizxyblH}DCq{qok1wj0Fc03I0N{Vw3Sgq~})p{yWb=^tpBRkuH(adX_
ztuan945&`zUxErnV*&rV_U}e%pBjVJ5U8-Xj7{zfD=M0CU9sN@*mV@uhAkZc=X{ri
zFmYe>)Ea`!5rAmlm5Drk`)7BVB1X;&``*JzNlB+LO{(+$&(DKWECfgY!%GVl%ZIQ=
z(3$MfuSPpxe@v^}Y-#oZX&+bKkMIe|R*!f@b<$PrFv!UIx#2M}YYD4+>_7%D&sHG&
zVrUl+k)L#xp!H0E#jYw47uY8w!wE(ACQ@n@bz7k-XTl8reiva36d^AXL&awvPy5;84Xi5Z*JG$ui!HG6xrb9{~(y1t8PU
zZO*qd1E>H}>Vf|ZB2)=H$jr?hv@_Oi6`{Gue`>s&A3+t!9q6u7LQQpbM{ui8^#5!N
zN=fTA+Y!Do^7Qi;k^(Q`C4aaeNk-bxb~3H)aB;hK?NS2m>izXA6hFM2>4va{9|VK9
zZ{O0OO^PB8a}(ChS*QcQXJ+!!Lg9Ro50@0Kfl^3(7s4sN3Xq0V-UZrzhBDWtO{;u-
zd@Q-GW1wx)5+1W-OZld>EDAie>@BI!G3$PnX7Lz?uk&&HxTQCAK6bGQ9BQSl{;Ii%-6WP1f6345yd#HkFKEYMae!69psjQ^*Mj;pK
zq9(g9CBc9Fe_E;}fBL^2LXk1O3c=d^n?Gur~gL9xEH$%`ab0
z8T$i|>M>OPuU7bfx$OV>%?v}wLY+`vd3Kax?G<@>c}ZxOpq89cHk`w4nVwBvuu(UV
z@heiV#h&lO_Mh#vI@(d_ECN1v6UmGOxFdOt{s94LslqsJ11NyuU=VvRGLmfQZvCOs
zA5yfpky1Bvc#-W&b@(<;S;y_L*u)SOf=Kb#`^M?sJ*LG0Xj^E1U*$GaC~1{xom}*w
zms90vN5{xxH@`ctH1$ILxrO{7#KztkG8E9K}Pa%O5}>Q*@=r`lHZO;rmj=#mVvo$|dC$^ywZ%
z8wq9>^27&*;!SLFvPj3r?OIeIz93)2M0OIq{#1_DMpzak9C~!niyKiaGOdKj+4b^r
zDvT&b7Z(@x4UhugW3@oiX-Qg!X>FCIN3};ni09x{$nV!kqfEGm7q?NkLc#fzWQm(M
zZUkgy*}d*4o9kOoBLLYzw-&0~K&W&VsWXz!#(&wdt?Bm=00Qtt)Lewdd?w)bZFZJ$
z1iXemXT|+^krz~QDCu`}0O
zmNDRtQqRGc&_REJU>Sj->)_~k7w}#U$h2leWY?}c@kjjE5oGcmaXB?ieoM5oRZ27C
z-9A2D7ev6?XvRa-z!Hu`Y48BWukj@vTOm&Qu
z(}mmjmQ3A+umZ2(E>3i)O?i~S<{D~F^e4SxFo}u_l0i6>P!Y@_@+(?Mg9jeQR;>dQ
zH=s#sxVYp6bgJ@TzmhQ{@`OS)G#LCuEdVEZx_}J#NJ|?~spKbNR&27fvwQ707}VlT
zrQRU!Abo9wy!_EWKbkmTK9O`TtyuV;46eZ8%9RKhHbDX8DF>MKG1g41MFo<;!9jrgTROfAy;9?Upm*!SVp#gh?xuOgi72b~hR-TRS>IDw!8
zNkvFhR8mOM>o0Qm*eOBPp-I(1^kl%AopjP;P~_nadan)HT%r1&z>1+s69k#%LqyAI
z_|sZ|Z^1C-P;MFmqK8w56hQhq0!djv!!4))5;c?N+YA<(0ZDJmwrCt
z)ZP}-RwaN110WL{b^d_RmVY@XBNT@w?irI-E5=#vA3QkY4A)EZXeo>Y>;xR7GJAcQ
zmh=S)0Wq-;8MpKEU0=V%EYpjo-{Sy1i-li$i~ew0EvNM7#s9jCR9quP>dlV?#6@3rn6S%Gj7|w2_|PUtW-ZP^icR
z5fkgSnTB7qN`Ou@i_YJBt)#P_VxylEVbUZ|u!!Silg-yxYssh`&LYwf@IHN!I3;t6
zc?qPTv;oJ&9w~Uv)mw`5+Rtkg9H)Mmi{%+ccf3oDkp06K3dt
zPY{)X@O?`sA5Yp184NO?Nk$0~LL`*~GVMq`dbGEK!|aueRgV=2j|znG37koM55bdk
za6z1K5aK$VmR_7cG-zDc8A?i*q}hn08i6>^MGgcR`yS${X3TY9motFL1OYc2OHW2J
zIrmv@z!|h)XcL-o2YC-3JSgKj)_J-Lrjjm~jRY@izGw?*@^+AzXq3SN(MsJ)7zjQq
z3ucg&Z)bli=P8B5}dAmYBAQHQG??vkgsTt>gV9lDQ88PxOWv)>D2VTX{A
z8bHukVJI{$GFAsYefprXiyyiV4#}w^0GEA2&mCu92IeOEtpbl)p6$cEBum4SL`p>_)KGGwF
z;*^w>+JKvB_y0|Qe2`v9ZIE1H5aabUNrcWY@&0$eJd_ssl|7RJf0%8_!=Y(H?dWmp
J^TX!X{|6&CbLs#9

literal 15691
zcmdVBcU;f^|2O(-C`3u5UEZ{#fuv0-4J{RtGD>L=X=xBzl9tM-G&Gb{QfN_>M4GhI
zKwGJ_yY4UF-*sK*oZIa>=Q@9!KaQJ^H}6mH_iH>K&&T7wUcq`g>KoT{tS1O!qs9?c
z1A?Gt#NR)!rNf`bbs?#ES?6@*q$@!%R+0Zv#fUO;5(FQip?c8JSAfs?zVT
zb>zi_VsGNt?&C2tNo0OTPOW;tEdhhJov@t=xmAz-`>4jA|fJM87s3qmX4p6U-4Wz
zZfVKAIvld`Mo>@?kEJ#jUTV($@4tkf?vt=@-#b0>Ro8O^n*_lks8c1Fc;#AjbhOKu
z96$e>0D3019FxK?Ne5}NPZm5jT}-LgRaK>3m>CJwh!Qv{7p-Yqb7%Y9XhD58H(kux
z&kqi$^;EhmJ=RUUU0f`K?`7)o`Fr|h^`CCRlj`KBw(T|*ik;=XTfN&^=F+cCFC2TG%6}c1A^*OzJmHt3
zpQ7fmy8L%LWw7yYv2*`3pT)~1Gp(n-*cAT$`?oq`hx(W7lY8tsUgVfAq*i~N8vKZb
zx|*gHd)GVpl-cIZn>TIRvMDeCI#c3rPpGDho_R;xnA%YqKL{zy^_
z`Zjl*l;!$vzg3^KEBHsT$0TJv0|T#(-}Kyv`ub|zvxZV{_tCZj
z`jOV0%7G72Ioz#1cM}uC|NN|1NpCtSw~6!&Zyu=xI?eq)
zTk`uYLx#~4R)SAloQa-^rz%GDc<=CV2UX^xsb~Y$D
z_-a_##+9W%x(^Px(h*MMod=pT^l98iT5lvKCc1UgW;JWB99mo$$!&Oil=FIEVC+4a
z&SGa8dPXi~7Z<5}`yFpPbiF#5CRN%t)>dHUJo-&C!%#$idAcd%cy59QH}jjJrgZ1w
zX5ow$n@dBDYc_I9@6C#ejSZ}-Qr&C)gH-DU5X#F*!ImSa+Aa)b|tAO{mH|mVU<8Hgvq}b!ByR_2`JUmR2RIT3=7kpGUzf
zN#~*L-O_l&A@&V)I|T(RySlh>k%Yslx7CFUZ+m)pWgjwf?srht*Jpm^HgaM1+ZzAo
zW&&nbm+Ymro}Qk+8q*l=N!w?YlxfB87PeyfJJvx@ShwZ#+calf?d&v7ef;=s
zeLa&`DbMkzrU%0~_Vo@8U2Lo-S7%@#b?G*hvbOey+q_D*-@ZL0Khu0nE%9~87VH;F
zc;xQWuY#hYj%9XyeR^7y7NQs{NmL7&qM}-iqGov17_xk+_D8tQ&ZEb
zwziWdFYJVUeSN8wW!;8%7CCfnW@g^Mf4^mUqml
z&r3OU%24sOWEruXI(4eSdhgU=tT{(v%)NUe0dyNT69&0v3X_wQ%rTn$j-@kqf6aKM
zb$6F~ukjykFVuQa9Zk)U>G7^p#1VW;Dyl2l
z_=)9@y7+SvY`4yxD!33PBPSPHP*C9E?H&5?;X~A9XjD|xEncOSH$A_-dnf%?t5=_$
zt)%t0u(FCZ5fm2IAZpSReY2vE-j_ZqFE2kZH`#Ac?(36RP{0zVwu2)~&3EoQeabS!
z`t<`X$IZ9mz47t!sVWxTpx3Wo6L*AUx~%n
zWZz_FKKa}_g1GbT+X-PYu`O7ip>KI98cO>eySLzWo_y(&78GP*Y55^e@;t4-hlhty
z`LPuBaMp)9$A66M{uIEqiYb!RG(@gc#|!(Ie1Cs}UGm&@8Cludw>KCD(R>X~oDf?4
zJF$(J%Jo~;a&dKyS?KXwEp4FkTV8NGaCtP2xWlA4r`*`o6eB)~t;RsKJv*y%ptNu5
zj~~5GjIUwyr1_NP^asI2j5mDW8viTHGhfwa`uh9dy?Jxc>+krkix)5AvMiPtW(;yn
z_Ib{<9FOsO^ypFTidU&wenG)tTCCY-tbZUAFKa}Hxl5_{Usgdu!M0NGBDM{5l589D
z?b@WM_{^_N-e@$_==&Y+x1=JV9mgjuEbP+%eq+4E*=xj|zun%tncm;uuA$=7x+^9b
zays{`*3Zum-?g+DF>=WyRp~`Oi@mZgB&h2B`;eTR9I|#?TwJQoNYvb5*j80vuWKk`
zbXb7VXyI&F)f;^1-acCarPZZ^E!(zfsj1!Ez%6TNC=#=C=T0HFpLOv&L}E0JpPFXw
ze7R=L8Y$l;4=O%EodSE7o^!1CCH#d@1|Na)cW!ZS6gmZCdZf-8BPPCqeni|)shRNq>I8hbM
zvYCs^E_!eD?>~Q{&<929bInRch=GE7#XVWoRo@%PH7vi_B#qTk9zLq(s3OU{=s-(6a|qM@t14U=;Ir_$<0!}N@dBQ~ws!cl^{tjrND
zPmVJX^Gko~kM^<4dpyJL6E&~l4^~094qJ)*`0-=Z`!G(encM-
z(A(@2(Gl!i>NS(6cQ`&3+SLbj{4$!$SuBIOUdK=IPhcuiPhYpMHJ$I{-t*$pQiYj`M3}FOOPZ
zI?Y0u`7OI`;E`wJ2%}5ad3eazSCMWbhlOGF`}cJBrR@!7yI#5q5=kn7j7M~Iq_a9m
zF!k*j6^dQuiE&Q!6aW@SSenzNOR7C(K6xIK=eXoOHUX!mmA#K#X)m<3YBc}z<5QmZ
zUx%Ii{Eq=oZT~722_Y_DzN}`+Eqkf>r|%B++k3st
zq{_DM*r6i4=(jqtN=2yBlB3GTMg-e9A~BKa)Txg0ndK6j77?s~_5+y)i~B)m#@Y)#
z#$W!7K3{HL?)$8$NF6t#8_1JTHZa&685Jdo{S!5*_VMnnfUr+Jt1rhoU+%f$>^HYEdv7$fuX=a{BAy`8-L{~$9{)fn3|)Q{yq!S^Bv2vk8AlEDc7!F
zr$yay#?aH!#&Lgmb+(eOWOZdx#%*|up~%+G&Q1)|>(8I>WpqgmOfD{FD_>oaqo$$B
zbM9A5>#VM(fA{X)iE>{B?5cp|WQu92*H&GHnP?486z#DxQ?18E^9u|2nis2;Rvs;_
z&j0yIMPM0s?Rya&y(OjUO{Z0=bN_qIuKeg}jN;b@Be=(JDl2J#+Aj3FI6Gg(l#XB4
z8$=PC4rhnt&n+%;D!4m25yX})TZAkr*8q3>Msmy5fSc^>?0Uz?8Rg{Uwrt&cQvOLg
z&K4_IdCIZWQo8kg^=*s~s@=PHt0mSyK6=0J%OjQAq`G`XcYZ(rmD3_I>oLaPVw42A
z{`|b1kB=x{p5^4?;*xOcRVMs=o+fyYzclF3(A0dDyP|b$aC0Emmjr~miu0-Zo>;S^
z!{gnhoG7!yK(culMqouE#{yA{*XQQuLe|Ffxa#Zc*VNQhps4aLkC{Y`0R*w_xv;^%
zV@HFli%YGY?uz5XNZfMoS$p8IQ$-HKd#=~nm&Zny3!OGK9cPaX4P`JmcI@LV^3o{R
z@B{HVDPKn>*jW_X#o}+Xad2eS-SPh0<=&8GBnrqFRMT_sGhm;Mg@r}5Y=AIO79nBV
zDpo+^o>0tSp~TnTK8mYPx0!iRVIOZd&NT}I;_Uxw?)UD_c9rO_CmJ2ETq*ewU$gnI
z>x&ez@Gfe-zfyiHSBN6rvF?xfv5mmwz~@QFbIodFGlC3jlKBny0Y0SQes5xqQeT`M
z%d_v0wk&%c9?pbje6(E#%;U%BhoPuNOA$*`(+3)*heKJ`PxLm|cg1cU|MBx@y6Ld!6D4nNZ&dAlpNANhro7kqC?`rhB->xu
zhZ;RGegvdlJ9srUb!W;R7E27ox!;vclAco*#jjr78xzD`03Q%Y{Di8u-pj$CCp6y~
zFX!O5FqFP%wkZcEW8L(4qwoCSHq&xn?C(*DSJB5@e#jj-&^F+j)?j_c$_i7!ck8xo
z{Q*ph6}jarAwLtm86V2Im;F@4>7bSDo!7GIdgT@r7FKAzrj}!$4N+WrkEfw)1079k
z&Z%_M+|rI9<{f$f*uYOz#7#!-5b&Mz6Wyh1Gm7&AEZHW7>j42(!g&-(rr}t=%!+-c
z`4E>xf}UcR!S(*-Pj`r$m3-Uz82s_k$$|?4<`w8?QYLlU=}q5@dVB-GHC()2K0jY(
z;jq-TOrCDMRl>p7m&c+D){$juXD4><+__uByG@?gj4rAgX@UGXbe9AJ-?D`XZep&x
zzh8HL)q8&VZx1ssZ}|S6D@~)b1y=PGY3bI{pH1Kam)-fN;-DSQC+_(`S_6}j1ke%
z*Fk))04Bxly}0=mcGhrav)ugRVr4@EGpNHmbe)LE$ZN^T$@D(K({bO*{ggn?>J3-|
ze|MxkQ5C?`wqRqsjq5X2@uj+CZ=k1k2NuxYv}3euiw1c2XNpqR`}Iv
zY0lZMr;Hnt!p-~l?@t|WDzMVsz$LSZfmN)cE`El?)ZD_#
z+J`0h$1B0rHZ4dwdsnRkJeN+1oednk$WVzGMky
z-Ssw%bHCG%I(F>@d3LZqRS=Nz`DIfnwR4TB8W+TkXo{5F!GHx~UufN8lcc6x!?$cC
zemAJ|Zr`WckP@N$0Q86zt}U4aqmI
zOgE?-7#dpS>nbbzPmi`WrIr*Ip8%giI}oxjv~D=W$RjUwEL~@7p~)_62#UeNC2i&i
zAkq-cG=ugdnwnm7;w4;8R1c<$)fFh_8bFf69f{_G(~5Ow(ocmUosBp
z#J(%Fwb=Rm0c?urjy(ws%0?TWh!JZl2D}$A5vY|F7k=$X8^vd(F8$IQJVDC`sul?<
zy>9K=J7%R`!fv0AR(HN~d-AQL<0G%%lD^F?^6QVAd8Rdwkpu^WZ>Z~ak--bV2@oi$
z1^JllhX%<2oC|*^a+`&N$Hs@^+=m-d0*O0auifw4iHeCu12G&S@uf7Uw4IQsakkK(
z*J)x#Hr#QtTdsJJ+`6eIpmpq&vIqA@19JDpDeLI!o3O^XQ#Jgz%`KvYxJ$RJ$^IdXs
zr#?TFOV2Jdx!2cs4k}6vs9Q>mm?(AlYOVKDkMREe$3G`1hAq%Y$Dx(*+!SYWk9ruA3-*GIr2+@aIo0ZS7mBX=w^hr%bEAQ?-5jmV}jL
zY9`e`k)=z_3S~ex!>u{q^nhXT1BYh1k-RH
zSHH5Vs^L8nqP*K?zSrB<_SOCbXTD@_z+Lv%?2`dd1|V=H(;HwA91Ng~k>!gY4-2MY
z?m7lMA$eua$u{udbOmOh*6Gn;u}ZD2s;a6Mk^+q6OP;q`R!~UDA!}>v!&Qf3v@I-B
z3ss)U@~j$d3-`mHCr?(FXEpEgYfx0~*}nSM+?LyOboI^RSH;JwG4FOh<9=SAH3LQa})af+gv6@rrDm<
z78wdig$C2;4;=!yECl>+y&aIvCnB;QBC!ZzVq1O4FkZr$PeeseZxb3qVI`mF+Kn3z
zlUH5Imvu?z{Z+`tV(+W|-@dF#3K9ukUi^E0cC<}k5a^H;n6L-wd3h5TZM@s^Ey)Is
znbVM}5k%i@q6meALo@NPwPUH
z=MG&QfRY_Pg+7yghp}>eqM{?))t6&|yYcJHyO6DejVrgg7qr7
zK{X2=nb&?X_x}7D2pGT#d?I^!qB{&QLAXPe)~Y_?T`-Gal0oK|m#$WOZJKMWS06m!
zN=;8s0TLImHwS`O59c{-Y|PqT`M!J_kR>Hb4xX9&TZH@!|#HV1D5x
zG)1BpGRC(eM_!!Wml99c6d7G;&*;)`T3cDsXvAk4wMnh&qMhaM;rl*tTz
z72-(2g--*+El((vzJUQlmu%tivz0f67t_(ofWX%HgElLpJ&4*Anq2t&K$tGzO-AlM
z+twiHW28)0R8;h>txdzjqgdv^fe#QXCKi{MU!y4f-QQ=|&MjZ$Z}shOQ{rWs&JYV$
zadytb{nCOMGIib_s?P7;H>9f5_R=-|KWdHUHAw(!OF!4(%3JJvX#KBX<&(dTK)$F?
zQ0VLJ6|CMkIt
z?3b1{1{g>K<^q4*frh!;w3rWKCMI5-jNak=*}v{FmSg)9mj6uF@H2{+FXdmqaYN(8
ziMXZdCf)oqZ>WbF(?W?&ImS<#;Z*cMvjSKau;0k5XezIu5L3YDF32b;DM^Yg=ilFw
zY&-s>CB!7>uF}e!imEEWz9b$8zD@_6Su!uspehZ^RPXR9I8l3)`B
zxI}zT}Wfa@WQy`6-(D&RY)7%T1I7V7pXeo`|%Vzw8C8q9Sya
zmM>-6r=_OG9p%!TeF(HFaP*$xa2eq=)W|=#u)s01k$C#_Dcq!L1@n56EO+W~X+}jy
z(=stJ?GzA5w*C54paWD8ocvOKSy0B3q%&WZMV8T%o8TBi^^iY8aM1pb;^nH)H)33v
zuWF_px^UsK)a&mKX)&RliZtH8dk@M_R%>T5^yoxi-?irEW`hw3
zSR~8;Kafi~I*OM^@ogG?{;yz_Bp3xCQnQr-6<1NcbN4PC=3PplNzTpEQiZ)7VQtdO
z%ga;*Fo3{f`?qfut*yoyTpZGNK~Ik7zC9zsRv2;Tjz8#%u$6#jKU!3FwirCByX@)s
zcu8p~GlqJj8rsFzK)$SLvtYRmKa9
zPO`OdDtJ9_lYt69S+}P?3DQJu+jaOp;5e)(Xf?NOyG$%*-8MD!SGT7aJn>qcJ|pr;
zmJ#R!dhHI-7E%tT6j||aV3$&Dwkcdf#odLXtck&Ni(Af^sKMxnSq5^074(?6(~zS6
zvCL<20OzaOc6}X7v=?;G#^)E0Wx|nM0x59;!bcUAftbci+ut+L&HWmho}S+PrbcLi#Im*23W&M!<4ohWkPPVigtgmgfji^oLi-)BzW
z4_yJYC;Y*S&XLm8Y@5|byFIXP0e|NPqI7@vhbvJNXs3a20l6GYCT|+lzj;GNdXeAq
z&c|#OMZHQu4NbZ4lG$P-W?H-njw2=E%9I9Cfvxu?^O)e$%Ho8_pHKTGtv+*+G!J47
z6&2OD7xtWx!*ia0@9z%)-R*(CWgHD+wK)UUSmA7GW6y;eqjpd6!sUVgOy^_wfJ`V}K%_8&&Z}oXxjq+YhOHx@}LPymBltJP6Rj
zdcF@>R+Y6sZGEy70LkPfzpX~?K`zNzxBr2*9XoayEm37QK5u38&&WU9r)(&lQ%J){
z$1*Cr+Fga?E&v{kt^V;rIOig-!<@kp#n=@9z8)`oLW(oxOgBV_gmCbZD}I?Ru+~3
z*w;_qSL^{!ws4bkAHN><$y`Z;at$VVFWj{EFzAE9V@^rRzG7jar%N3=xZa+2JV0gKvHY2ITMBn%rFk1
zlL8?|<~Ni5)y}|rP$-i~F{vdhM#G#yr@Tor25b^l2!stN`;@qeTO;TMM~)sntgKAP
zx{uqvFoTWC$Sr#vy2T@KM)JdlC6$J=eU$!Wbt^G9EUzbl(v&n*Nh&_Hp$kRsLyd<~
zmG90-2w6h+WpQ+LBrS>L!wm2rSYd&+<(&^~D8p@x1sz8wU=!Zc&orb~#?H4uQx#YS
z9qrB-#hH+u2%aMZ0T!^%O`M#ZsKZ#O92_mnXe(q#L5nxcH9Jkz_*2pB6c^XcJP%OQ
zUE+Dp%1Tg2N2d`0ko<;6D)btV+ik=T95_iDrZ9jo1cYD=k_{$)@5M;s+0w=`U6UN+
zGih(Wx2}B89$sc)?h=0@$OzWC1%@G1YW-S33epyXvn;^Q&Q763#>Wc-uEQ1FrlGBE
zI1DyvHvBbLd}U>23OcZ+nOVXE1#jc|?J!`T8~h!wdX$u;TvAe!3ZX4BIyyBvQPxcp
z|K2Gfp(iZoJ)4b2%MOPW#9C|GtCYk$=WK07C(0I|8aU2R4N@y#sEgYU*Q(Zb8m1(i
zQ+9rJoEbBw9_jY|$4<1(EftWKme%I_ro^nDX80($GF)jz2(rg!R#pMh9@I`$Jl)yV
zMczO_ucYRQp7L@W8Mt-7jo_|bM=?5JaEV%CmEbI5ezUc7VcCc~>sSPYEP<}}J9OS5
zqaA4RN6#flS%#oTlNKj)1XLM}uTU@n&KB>%nB%FyI0mMsVvq!);mT{Pt69(nEM{c+Y6XPd>NS`vjh+*
z=pX6?4h&eNEGQ}}VuOkT);)yYZ5hzKeSAXRns9YR8D$(C!6j!pxM9TWn>TCwLJ0j%>)(i!lA;6hK>wdJo_
zovT*b#Lc~tASESz1(c-x{6G|#mS(2&aaxiKTeuAk4b^6cz-rrT+qwZ|V*MrQs)3-Q
zA`hYo*uhs}g|%G1
z^WlU3!YkipS@i!$OLIMlt1tmF6aG+YX$ZyT>0=}azObmJsYy-1KBOjq!7L1rD`^@n
z+ZsIb?}oO3Z+LomdY*+9S?u(k8br+Az#Xz+O@00T#h~!;q6{VIHrP?6&8cvTXkg~5
zK|j7LcJdn1DU>~XSg_yKtoCX~?_^11e(BS)0L^muzFDw34k9`ZKIhT)hLIW8(z2;4
zlKhH1gecEV{6?P>vBXL}D=1L8az!3ShBl8)AqS!%YGc4#eUPEmED@c65_4fSSv=43
zBP;3MfJszAiPcL{+i2N=#uvTn?&=!wFP_o}TF8C0!#x5~@x`EeYrvB&CH+sy4&2
zc{ABt@7&oG_2RC$xx@6okdSjf9V9Drn^mak1Oe=uGKHEvJ6Ib-B$@so5lEijs&7i1
zDlNoLG}C~boLycs!#B`qdePhu!Y9_hZ`+!E5FI(ss-B0afIdnPNU7}2az|%=lFMN&
z*K$TjM|bk^DPs-^0%%7S+I|fIJ1c(q@&lkl^egxJEE)6`sDu~69=H^*oIo;ZHx`st
zNlA$vWQ8Ebw9p`u%Naf~K8m@*kKP>xnBKKPxPJM~>Mu6$F|W
zH}M7FpS&ebZf?5@CooCu+Mln(MW`dyMb%j*_Nc|C0n@{-vzQqml^#|M1Fn@6$#YAl
z)&pG95WlCU4xKo`Mh<|qPut9|FcZHMSC{CK|Dh$CpPuG~Wbh6`N7(yQ*(dU-(NE(J
zxC(%QuY-Gx?g%b*G~Vs(t{>_*|@=PMiXmQj+{A@BrPOV)9!p{E9wg2L#ZuB
ze_My)_HD;>u^p4qM0zF!i%;T4T-Ls}m0Ho<-dJlR$&l0dlf;~WwBS!NEu*T|`;(tU)Tj#FE$HCni
zDGfrl$2vn_zm~(C*p+okUq&YKpQJ^?nCTNTn<4f_D=H)Q^2_;vnNN
zhG?7?f5>AVsnN6|?C3N*dJ;q_=GcI$svn6*4{AExb#w0n1YZNVhB*h#&D$z7<$8l`W3TJy7&%A06bSc^Y{(?OyJ+dvrR&So?cxIfg&*tntyd8*~vcNXiDNfk1R#>>kKP?vx1-Fh-6LaJpm
zk98i3fTX$n`m#OKIOiU5r(SVUTU8a|AwC#QtiW$a@9m91Mlwh(g&8gUfY)?JP*BO_
zdrnf*dinCDCfZ>)iSu9;>F183%1L_(%9Xn->UQaTu0ogDb<|$4I1`uu;qS)kvw2RK582J4K1OfrDZEdHyL<^!$GD6
z;FQ(HQ4!FpHbEf<*sz@DL4FSv)sT^h3}=#KPuUmiy_#*Lc68y>z3rl+3|NU1&(2Vh
zrGTE8JiR|5h=&89XKRMV0~JHVE&d(p%k}vB1O;!3gv2ItyvK?{Y0Wi#Tx<^0q#7I(
z4)XfmS+R9kgwdXI^UObQ=y{Wpk_hC!t|CxCQ~=n(`SCZ)-GA{95_q7r?;#wA0wPp?
z_^=L1%s5#$k-NK2(Scf|IbcprA|rhc7!u~$+6^17Ll_0jny1|zwIcjK55pi)D
z(TCO5QxF)0jGxv}hWuS%X=$m(eIT7|Mg}2f-wZfyHmv=Nd3d8Q1X#y{V$AKo233whn`@Q_mFs7
zS?P?P2UU*`H411@iITpFtw_oyq*_8ME?6MWneP)5j*Yni0Re6MB!Yf@Ck>4Ct%#E$
z+}jTsr*`h1NFh@XENVout#JcO%KHv)pkKbpoC&@A#`I@``
zrM7#!ISTL_4mjrI7srP1#c48>B}a^9kvS
z_26)$U9bN-zB`7q$8!lA!2vwrHZ;6)vlTm;PfG%FNS24~N$U%%tA6er1(`vAaLDth
z#kGu#@6lSZK>KO|BO!Z>H0f!P0Y2hOx!-E}3`fwfNxl3#I!0rOJoZdJgEdpp4eweAKu}UMGJch{qY*_ucp!$(9Eq^#qD_iaZ*7F?4`*3{hVyTc
z=C^Nu?wKTwJkiq95>Lj)7){IP#1>`+GZ_ZO4e3tbgKHR^BYNcI!COy}$C_O8&EI|I4xc|Jw^E!|-+a>%Kf{
zoZ&93;rV*-j8#=*0*84zRQ}7O-O9{hB!y605DINgQsHGW*xd&@|J?eINo&96`k|Pk
z*49Fl9XoQk>6n>~DE}Ps{~;!x|Bt5lzwuIF@nLBFKIcAF=(j@k_I7r9$eP1|=tsU@
z89@%7;&4*jt7KBDLdPQ?SmA>He6>T&5zMIy+FS@SBFXRsTNwj`g0eC+-QSbj>b3iX
zal*E(ThGF2^MLKv0OyAkyEjEFI;e5f7Ri#NPhi*GElkVg^*?K(D)oS%}g6ePqP8SsnW1%3MFw-iwX2_<2&^NALYo
z2-JR$XAb2W$k}&nTaq^>
zcnxQ|c&I~4YjN7K(KFY?DX)gW7)hKQG<3Aoew32G_en-8EC*TO8aNX;yVTZ
zJvtFFQNC(M#K~i~0-^5PXM~vKP9hZ=E9t91EbR7Ov8YPY$BDHMSD$b^L5q+1H24=FDe!NrE5OUUl0!fA!Kyb}e+8t{e>hAZIH@54Ahh_=9jR)#BZ
zdo)p@{Nm#E8B0Kl)XJ=QwvAF0MS*(2F5{G>!3E&)Z$BF!AG%=F8H!m1uLV&eTH+g$
z03c>$>HtWCQvq`DS^^%=sd#%NA6N*$2l^;!D3&*oj6gxMjqO3yp*j0xQ|d1857J=s
zOn{t-HA@0zKp;uNrUMB-Ag5~FU4lTgD^MrB5;FGD_Oa&7rXG)2H22!-9eZT*RSzDd
z0-k)lbSFW{kB5)|VbYG5dN-;FHfs6eWFxs{v~u9IUI$|lst3|^e9_%Ch)4Gbk~>sX
zSEo0>pyC4vBfcQR6(yUHkdXFX4gF4^=VjG)kyVT75
zy(q|f7F&2{S_mXcm6V3w!mnmD1R5Sq@$&K4fNl+y$W}lh5l~ui#|BV=YXH0IXgjIJ
z6&00RP3hl@{KyafAz
zW4;OicphtiL|c1rJ8bg<%~?ha5EE$$GVehy5j2l5Gp!331n?Y)r#Ym4W(Dn-DFZTR
z0-1@v_wrlV4WW?scR;tLq1#Z=`O-D!6@<0-5DLlAD0xU|V5H5AP|9`knLTc~*3r1D
zawtg#0G}$TW60(PlJ+fhQ-B3BIbXK2U^|#yu{<}|A5NMsBp!pcfRkkSBe*ZlOz+D
z%$Y`9Qz@DL9~}v~efuui9F)=c
zZPc6Qm=RXy&U0K}wf`4Ueis@xitMlV5$LwZdSGc>waSEr3fG;e8~(~ls1
zxrQ#0!L*P?OIus-`j4CcqGMU?9h*99kZG84s_5xqH#oOn@-08Q1jAAL<*OhSume56
zW`X?Z|0)zVe&7iOy8(|Y{R0R89`Pk*Y4(^kZqEm~X^m{i>={b%|K`_p(A=s5WgvX*
Uryu%wI-1ZptfTt$(3xxh4I(UI)Bpeg

diff --git a/bip-0002/process.svg b/bip-0002/process.svg
index b8c8a4c7..efaa02b0 100644
--- a/bip-0002/process.svg
+++ b/bip-0002/process.svg
@@ -25,7 +25,7 @@
 	Draft
 	
 	
-	Accepted
+	Proposed
 	
 	
 	Final/Active

From 894b6ea66cb87601e244c6c4667b60c61aa51ae4 Mon Sep 17 00:00:00 2001
From: Luke Dashjr 
Date: Sat, 24 Sep 2016 06:22:48 +0000
Subject: [PATCH 41/68] bip-0002: Sort changes vs BIP 1 by relevance

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

diff --git a/bip-0002.mediawiki b/bip-0002.mediawiki
index 897ba05c..c8c9de46 100644
--- a/bip-0002.mediawiki
+++ b/bip-0002.mediawiki
@@ -389,16 +389,16 @@ Why is Public Domain no longer acceptable for new BIPs?
 
 ==Changes from BIP 1==
 
-* Acceptable licenses are redefined entirely, allowing a wide variety of open licenses, while prohibiting the problematic older choices.
-* An implementation is now required (when applicable) before BIPs can proceed to Proposed Status.
-* The License preamble headers have been added.
-* BIP Comments are newly introduced.
-* Non-image auxiliary files are permitted in the bip-XXXX subdirectory.
-* The Post-History header may be provided as a link instead of a simple date.
-* The Resolution header has been dropped, as it is not applicable to a decentralised system where no authority exists to make final decisions.
-* Email addresses are now required for authors.
-* Markdown format is no longer permitted for BIPs.
+* Acceptable licenses are entirely rechosen, allowing a wide variety of open licenses, while prohibiting the problematic older choices.
 * Accepted Status has been renamed to Proposed.
+* An implementation is now required (when applicable) before BIPs can proceed to Proposed Status.
+* BIP Comments are newly introduced.
+* The License preamble headers have been added.
+* Non-image auxiliary files are permitted in the bip-XXXX subdirectory.
+* Email addresses are now required for authors.
+* The Post-History header may be provided as a link instead of a simple date.
+* Markdown format is no longer permitted for BIPs.
+* The Resolution header has been dropped, as it is not applicable to a decentralised system where no authority exists to make final decisions.
 
 ==See Also==
 

From e89b98facd4b52e0d248ca7dfc6f60a030d4cc59 Mon Sep 17 00:00:00 2001
From: Luke Dashjr 
Date: Sat, 24 Sep 2016 06:27:51 +0000
Subject: [PATCH 42/68] bip0002: Status Deferred->Draft

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

diff --git a/README.mediawiki b/README.mediawiki
index 6f3ee08d..c80d3ea8 100644
--- a/README.mediawiki
+++ b/README.mediawiki
@@ -23,7 +23,7 @@ Those proposing changes should consider that ultimately consent may rest with th
 | BIP process, revised
 | Luke Dashjr
 | Process
-| Deferred
+| Draft
 |- style="background-color: #cfffcf"
 | [[bip-0009.mediawiki|9]]
 | Version bits with timeout and delay
diff --git a/bip-0002.mediawiki b/bip-0002.mediawiki
index c8c9de46..64eaf367 100644
--- a/bip-0002.mediawiki
+++ b/bip-0002.mediawiki
@@ -2,7 +2,7 @@
   BIP: 2
   Title: BIP process, revised
   Author: Luke Dashjr 
-  Status: Deferred
+  Status: Draft
   Type: Process
   Created: 2016-02-03
   Replaces: 1

From 67b267948a2f75932645e8955417e70bd8c40674 Mon Sep 17 00:00:00 2001
From: Jonathan Cross 
Date: Sun, 25 Sep 2016 01:36:00 +0200
Subject: [PATCH 43/68] Improving wording of "makes them consuming"...

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

diff --git a/bip-0147.mediawiki b/bip-0147.mediawiki
index 8b6fe1ab..352f48d4 100644
--- a/bip-0147.mediawiki
+++ b/bip-0147.mediawiki
@@ -9,14 +9,14 @@
 
 ==Abstract==
 
-This document specifies proposed changes to the Bitcoin transaction validity rules to fix the malleability of extra stack element for OP_CHECKMULTISIG and OP_CHECKMULTISIGVERIFY.
+This document specifies proposed changes to the Bitcoin transaction validity rules to fix a malleability vector in the extra stack element consumed by OP_CHECKMULTISIG and OP_CHECKMULTISIGVERIFY.
 
 
 ==Motivation==
 
 Signature malleability refers to the ability of any relay node on the network to transform the signature in transactions, with no access to the relevant private keys required. For non-segregated witness transactions, signature malleability will change the txid and invalidate any unconfirmed child transactions. Although the txid of segregated witness ([https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki BIP141]) transactions is not third party malleable, this malleability vector will change the wtxid and may reduce the efficiency of compact block relay ([https://github.com/bitcoin/bips/blob/master/bip-0152.mediawiki BIP152]).
 
-A design flaw in OP_CHECKMULTISIG and OP_CHECKMULTISIGVERIFY makes them consuming an extra stack element ("dummy element") after signature validation. The dummy element is not inspected in any manner, and could be replaced by any value without invalidating the script. This document specifies a new rule to fix this signature malleability.
+A design flaw in OP_CHECKMULTISIG and OP_CHECKMULTISIGVERIFY causes them to consume an extra stack element ("dummy element") after signature validation. The dummy element is not inspected in any manner, and could be replaced by any value without invalidating the script. This document specifies a new rule to fix this signature malleability.
 
 
 ==Specification==

From 5c256744bffeee209b42018d79ac00db6881d8b1 Mon Sep 17 00:00:00 2001
From: isidoro ghezzi 
Date: Sun, 25 Sep 2016 21:11:11 +0200
Subject: [PATCH 44/68] minor: fix link to BIP 22

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

diff --git a/bip-0023.mediawiki b/bip-0023.mediawiki
index 874e60a1..03909587 100644
--- a/bip-0023.mediawiki
+++ b/bip-0023.mediawiki
@@ -13,7 +13,7 @@ This BIP describes extensions to the getblocktemplate JSON-RPC call to enhance p
 
 ==Specification==
 
-Note that all sections of this specification are optional extensions on top of [[BIP 0022|BIP 22]].
+Note that all sections of this specification are optional extensions on top of [[bip-0022.mediawiki|BIP 22]].
 
 ===Summary Support Levels===
 

From 5b66911109c63c4091ad8a8c8b6adb0431f5c6ce Mon Sep 17 00:00:00 2001
From: TomZ 
Date: Mon, 26 Sep 2016 18:09:34 +0200
Subject: [PATCH 45/68] Fixes to 0134

---
 bip-0134.mediawiki | 15 ++++++++-------
 1 file changed, 8 insertions(+), 7 deletions(-)

diff --git a/bip-0134.mediawiki b/bip-0134.mediawiki
index 280103f1..afb5143a 100644
--- a/bip-0134.mediawiki
+++ b/bip-0134.mediawiki
@@ -66,7 +66,7 @@ a transaction.
 CMF tokens are triplets of name, format (like PositiveInteger) and value.
 Names in this scope are defined much like an enumeration where the actual
 integer value (id, below) is equally important to the written name.
-If any token found that is not covered in the next table will make the
+If any token found that is not covered in the next table it will make the
 transaction that contains it invalid.
 
 {| class="wikitable"
@@ -81,7 +81,7 @@ transaction that contains it invalid.
 |-
 |TxInScript    ||  3 ||ByteArray||  Required    ||The 'input' part of the script
 |-
-|TxOutValue    ||  4 ||Integer  ||  Required    ||Amount of satoshi to transfer
+|TxOutValue    ||  4 ||Integer  ||  Required    ||Amount of Satoshis to transfer
 |-
 |TxOutScript   ||  5 ||ByteArray||  Required    ||The 'output' part of the script
 |-
@@ -164,7 +164,7 @@ version it would be placed in the outputs segment.
 === Script v2 ===
 
 The default value of ScriptVersion is number 2, as opposed to the version 1
-of script that the is in use today.  The version 2 is mostly identical
+of script that is in use today.  The version 2 is mostly identical
 to version one, including upgrades made to it over the years and in the 
 future. The only exception is that the OP_CHECKSIG is made dramatically
 simpler.  The input-type for OP_CHECKSIG is now no longer configurable, it is
@@ -184,9 +184,9 @@ modifications to such signatures outside of validating all transactions.
 
 For this reason the merkle tree is extended to include (append) the hash of
 the v4 transactions. The markle tree will continue to have all the
-transactions' tx-ids but appended to that are the v4 hahes that include the
+transactions' tx-ids but appended to that are the v4 hashes that include the
 signatures as well.  Specifically the hash is taken over a data-blob that
-is build up from:
+is built up from:
 
 1. the tx-id
 2. the CMF-tokens 'TxInScript'
@@ -215,7 +215,7 @@ SPV (simple payment validation) wallets need to be updated to receive or
 create the new transaction type.
 
 This BIP introduces a new transaction format without changing or
-deprecating the existing one or any of its practices. Therefor it is
+deprecating the existing one or any of its practices. Therefore it is
 backwards compatible for any existing data or parsing-code.
 
 ==Reference Implementation==
@@ -238,7 +238,8 @@ To be determined
 
 Copyright (c) 2016 Tom Zander 
 
-This document is licensed under the Open Publication License v1.0
+This document is dual-licensed under the Creative-Commons BY-SA license v4.0
+and the Open Publication License v1.0 with the following licence-options:
 
 Distribution of substantively modified versions of this document is prohibited without the explicit permission of the copyright holder.
 Distribution of the work or derivative of the work in any standard (paper) book form is prohibited unless prior permission is obtained from the copyright holder.

From 78cbaca9408ea03470379479b93592b75f9ddc0f Mon Sep 17 00:00:00 2001
From: Pieter Wuille 
Date: Wed, 28 Sep 2016 04:52:50 +0200
Subject: [PATCH 46/68] Fix a few nits suggested by @instagibbs

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

diff --git a/bip-0152.mediawiki b/bip-0152.mediawiki
index 1b743061..cdb55b9e 100644
--- a/bip-0152.mediawiki
+++ b/bip-0152.mediawiki
@@ -138,7 +138,7 @@ A new inv type (MSG_CMPCT_BLOCK == 4) and several new protocol messages are adde
 # Once the block has been reconstructed, it shall be processed as normal, keeping in mind that short transaction IDs are expected to occasionally collide, and that nodes MUST NOT be penalized for such collisions, wherever they appear.
 
 ==Protocol Versioning==
-# The protocol version negotiation allows two nodes to agree on the version of compact blocks which they will exchange. As it is only in a single field, it does not allow a node to support a specific version in only one direction (sending or receiving).
+# The protocol version negotiation allows two nodes to agree on the versions of compact blocks which they will exchange. As it is only in a single field, it does not allow a node to support a specific version in only one direction (sending or receiving).
 # Upon connection establishment, a node SHOULD send a burst of sendcmpct messages containing every version of compact block encodings for which they are willing to support sending cmpctblock and blocktxn messages, and receiving getblocktxn messages. These messages SHOULD be ordered in the order of the priority which the node wishes to receive cmpctblock/blocktxn messages, with the highest-priority version sendcmpct message sent first.
 # The encoding version used to send a cmpctblock or blocktxn message or to receive a getblocktxn message MUST be the second integer (version number) in the first sendcmpct message received for which a sendcmpct message with the same version number was sent.
 # Nodes MUST NOT send a sendcmpct message which contains a version number other than the version number which has been negotiated for receiving cmpctblock/blocktxn messages after sending a request for a MSG_CMPCT_BLOCK object, sending a cmpctblock, getblocktxn, blocktxn, or pong message.
@@ -149,7 +149,8 @@ A new inv type (MSG_CMPCT_BLOCK == 4) and several new protocol messages are adde
 # By way of example, an implementation of the above protocol might look like the following.
 # Upon exchanging version/verack messages, a node immediately sends its list of sendcmpct announcements to the other side, with the version which it wants to receive sent first.
 # Upon receiving the first sendcmpct announcement with a protocol version which is understood from the remote peer, a node will "lock in" the compact block encoding version which will be used to encode compact blocks to that peer.
-# Upon receiving a sendcmpct announcement with a protocol version which is understood from the remote peer, a node will check if that protocol version is higher-receive-priority than the current receive-protocol-version in use on the connection, and switch to that version for decoding new compact block messages received.
+# The node then sets the current receive-protocol-version in use on the connection as that version, and uses it to decode new compact block messages.
+# Upon receiving subsequent sendcmpct announcements with a protocol version which is understood from the remote peer, a node will check if that protocol version is higher-receive-priority than the current receive-protocol-version in use on the connection, and switch to that version for decoding new compact block messages received.
 # A node might wish to keep a flag for each peer which indicates compact block version negotiation is complete, which can be set upon receiving any compact block-related, or pong message.
 # The above implementation requires only a compile-time list of supported versions in some static priority order, two version fields per peer, and an optional negotiation-complete boolean per-peer.
 

From f562566d9187e578de2c735dc70a8f55e77ec05e Mon Sep 17 00:00:00 2001
From: Dan Gershony 
Date: Wed, 28 Sep 2016 21:19:39 +0100
Subject: [PATCH 47/68] Adding the source code for CoinVault

The C#  implementation is now open source
---
 bip-0044.mediawiki | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/bip-0044.mediawiki b/bip-0044.mediawiki
index e17c73d1..c289887a 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.coinvault.io/|CoinVault]] 
+* [[https://www.coinvault.io/|CoinVault]] ([[https://github.com/CoinVault/dotblock|source]])
 ==Reference==
 
 * [[bip-0032.mediawiki|BIP32 - Hierarchical Deterministic Wallets]]

From 9ea3afd7d6c9e2a90a71820efcfa4ab56d109217 Mon Sep 17 00:00:00 2001
From: MarcoFalke 
Date: Sat, 1 Oct 2016 15:43:51 +0200
Subject: [PATCH 48/68] BIP2: fix typo

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

diff --git a/bip-0002.mediawiki b/bip-0002.mediawiki
index 64eaf367..fe7761ea 100644
--- a/bip-0002.mediawiki
+++ b/bip-0002.mediawiki
@@ -309,7 +309,7 @@ Will BIP comments be censored or limited to particular participants/"experts"?
 
 ===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.
+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 respective abbreviation given below.
 
 For example, a preamble might include the following License header:
 

From 6d086e11d09acc29fee5c3204a488496d395370f Mon Sep 17 00:00:00 2001
From: Luke Dashjr 
Date: Wed, 5 Oct 2016 05:50:12 +0000
Subject: [PATCH 49/68] Bugfix: scripts/buildtable: Tolerate Discussions-To,
 Replaces, Superseded-By, and Resolution headers

---
 scripts/buildtable.pl | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/scripts/buildtable.pl b/scripts/buildtable.pl
index 568b8eb0..f0e43d26 100755
--- a/scripts/buildtable.pl
+++ b/scripts/buildtable.pl
@@ -24,7 +24,11 @@ my %EmailField = (
 	Editor => undef,
 );
 my %MiscField = (
+	'Discussions-To' => undef,
 	'Post-History' => undef,
+	'Replaces' => undef,
+	'Superseded-By' => undef,
+	'Resolution' => undef,
 );
 
 my %ValidLayer = (

From 544941d09600d14dc7daf0828d60b29248d337bc Mon Sep 17 00:00:00 2001
From: Daniel Weigl 
Date: Wed, 5 Oct 2016 13:22:18 +0200
Subject: [PATCH 50/68] added backwards compatibility and copyright

---
 bip-p2sh-accounts.mediawiki | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/bip-p2sh-accounts.mediawiki b/bip-p2sh-accounts.mediawiki
index 251f7682..60119270 100644
--- a/bip-p2sh-accounts.mediawiki
+++ b/bip-p2sh-accounts.mediawiki
@@ -62,6 +62,10 @@ To derive the P2SH address from the above calculated public key, we use the enca
     scriptPubKey: HASH160 <20-byte-script-hash> EQUAL
                   (0xA914{20-byte-script-hash}87)
 
+==Backwards Compatibility==
+
+This BIP is not backwards compatible by design as described under [#considerations]. A not compatible wallet will not discover accounts at all and the user will notice that something is wrong.
+
 
 ==Test vectors==
 
@@ -94,3 +98,7 @@ To derive the P2SH address from the above calculated public key, we use the enca
 * [[bip-0043.mediawiki|BIP43 - Purpose Field for Deterministic Wallets]]
 * [[bip-0044.mediawiki|BIP44 - Multi-Account Hierarchy for Deterministic Wallets]]
 * [[bip-0141.mediawiki|BIP141 - Segregated Witness (Consensus layer)]]
+
+== Copyright ==
+
+This document is placed in the public domain.
\ No newline at end of file

From 0f0dad6b89925d8cc5d8bd4ebf06da0fea9c8081 Mon Sep 17 00:00:00 2001
From: Luke Dashjr 
Date: Wed, 5 Oct 2016 11:35:37 +0000
Subject: [PATCH 51/68] Assign BIP 49: Derivation scheme for
 P2WPKH-nested-in-P2SH based accounts

---
 README.mediawiki                                  |  6 ++++++
 bip-p2sh-accounts.mediawiki => bip-0049.mediawiki | 10 +++++-----
 2 files changed, 11 insertions(+), 5 deletions(-)
 rename bip-p2sh-accounts.mediawiki => bip-0049.mediawiki (91%)

diff --git a/README.mediawiki b/README.mediawiki
index 974870e0..1ac6b198 100644
--- a/README.mediawiki
+++ b/README.mediawiki
@@ -216,6 +216,12 @@ Those proposing changes should consider that ultimately consent may rest with th
 | Justus Ranvier
 | Informational
 | Draft
+|-
+| [[bip-0049.mediawiki|49]]
+| Derivation scheme for P2WPKH-nested-in-P2SH based accounts
+| Daniel Weigl
+| Informational
+| Draft
 |- style="background-color: #cfffcf"
 | [[bip-0050.mediawiki|50]]
 | March 2013 Chain Fork Post-Mortem
diff --git a/bip-p2sh-accounts.mediawiki b/bip-0049.mediawiki
similarity index 91%
rename from bip-p2sh-accounts.mediawiki
rename to bip-0049.mediawiki
index 60119270..5ec371fa 100644
--- a/bip-p2sh-accounts.mediawiki
+++ b/bip-0049.mediawiki
@@ -1,5 +1,5 @@
 
-  BIP: 
+  BIP: 49
   Title: Derivation scheme for P2WPKH-nested-in-P2SH based accounts
   Author: Daniel Weigl 
   Status: Draft
@@ -30,7 +30,7 @@ Two generally different approaches are possible for current BIP44 capable wallet
 
 2) Create dedicated accounts only used for segregated witness addresses.
 
-The solutions from point 1 have a common disadvantage: if a user imports/recovers a BIP-compatible wallet masterseed into/in a non-BIP{ThisBipNumber}-compatible wallet, the account might show up but also it might miss some UTXOs.
+The solutions from point 1 have a common disadvantage: if a user imports/recovers a BIP49-compatible wallet masterseed into/in a non-BIP{ThisBipNumber}-compatible wallet, the account might show up but also it might miss some UTXOs.
 
 Therefore this BIP uses solution 2, which fails in a more visible way. Either the account shows up or not at all. The user does not have to check his balance after using the same seed in different wallets.
 
@@ -74,10 +74,10 @@ This BIP is not backwards compatible by design as described under [#consideratio
   masterseedWords = abandon abandon abandon abandon abandon abandon abandon abandon abandon abandon abandon about
   masterseed = 
 
-  // Account 0, root = m/'/0'/0'
+  // Account 0, root = m/49'/0'/0'
   account0Xpriv = 
 
-  // Account 0, first receiving private key = m/'/0'/0'/0/0
+  // Account 0, first receiving private key = m/49'/0'/0'/0/0
   account0recvPrivateKey = 
   account0recvPublickKey = 
 
@@ -101,4 +101,4 @@ This BIP is not backwards compatible by design as described under [#consideratio
 
 == Copyright ==
 
-This document is placed in the public domain.
\ No newline at end of file
+This document is placed in the public domain.

From 9fc3cf52c6d0dcb58b806c7a1f727083b7e49607 Mon Sep 17 00:00:00 2001
From: "Wladimir J. van der Laan" 
Date: Wed, 5 Oct 2016 13:39:49 +0200
Subject: [PATCH 52/68] bip-0144: Add enum values for MSG_WITNESS_{BLOCK,TX},
 MSG_FILTERED_WITNESS_BLOCK

Found these missing while working on
https://github.com/bitcoin/bitcoin/pull/8880 .
---
 bip-0144.mediawiki | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/bip-0144.mediawiki b/bip-0144.mediawiki
index f2c8857f..456da18d 100644
--- a/bip-0144.mediawiki
+++ b/bip-0144.mediawiki
@@ -103,9 +103,9 @@ and therefore, they have witness hash equal to normal hash.)
 
 
 === Relay ===
-New inv types MSG_WITNESS_TX and MSG_WITNESS_BLOCK are added, only
+New inv types MSG_WITNESS_TX (0x40000001, or (1<<30)+MSG_TX) and MSG_WITNESS_BLOCK (0x40000002, or (1<<30)+MSG_BLOCK) are added, only
 for use in getdata. Inventory messages themselves still use just MSG_TX and MSG_BLOCK,
-similar to MSG_FILTERED_BLOCK.
+similar to MSG_FILTERED_BLOCK. A further inv type MSG_FILTERED_WITNESS_BLOCK (0x40000003, or (1<<30)+MSG_FILTERED_BLOCK) is reserved for future use.
 
 * '''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.
 

From 4ce983bee9efb184f8c126d9f099dc2cae99500a Mon Sep 17 00:00:00 2001
From: MarcoFalke 
Date: Wed, 5 Oct 2016 14:56:44 +0200
Subject: [PATCH 53/68] BIP2: Remove Superseded from choices for Status

The section about the BIP status field only defines
"Replaced or Obsolete (which is equivalent to Replaced)",
so remove "Superseded" for clarity.
---
 bip-0002.mediawiki | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/bip-0002.mediawiki b/bip-0002.mediawiki
index 64eaf367..8c745c87 100644
--- a/bip-0002.mediawiki
+++ b/bip-0002.mediawiki
@@ -126,7 +126,7 @@ Each BIP must begin with an RFC 822 style header preamble. The headers must appe
 * Comments-Summary: 
   Comments-URI: 
   Status: 
+           Withdrawn | Final | Replaced>
   Type: 
   Created: 
   License: 

From 3f59ccdddc84f309dd8268706ac8240e3e42dc2b Mon Sep 17 00:00:00 2001
From: Johnson Lau 
Date: Wed, 5 Oct 2016 17:33:02 +0800
Subject: [PATCH 54/68] Add policy descriptions to BIP141 and 143 and address
 some nits.

---
 bip-0141.mediawiki | 16 ++++++++++++++--
 bip-0143.mediawiki |  7 ++++++-
 bip-0144.mediawiki |  2 +-
 3 files changed, 21 insertions(+), 4 deletions(-)

diff --git a/bip-0141.mediawiki b/bip-0141.mediawiki
index 2b2360b7..6df2624d 100644
--- a/bip-0141.mediawiki
+++ b/bip-0141.mediawiki
@@ -133,12 +133,24 @@ The following definitions are not used for consensus limits, but are suggested t
 
 ''Transaction weight'' is defined as ''Base transaction size'' * 3 + ''Total transaction size'' (ie. the same method as calculating ''Block weight'' from ''Base size'' and ''Total size'').
 
-''Virtual transaction size'' is defined as ''Transaction weight'' / 4 (rounded up to nearest integer).
+''Virtual transaction size'' is defined as ''Transaction weight'' / 4 (rounded up to the next integer).
 
-''Base transaction size'' is the transaction size in bytes with the original transaction serialization without any witness-related data.
+''Base transaction size'' is the size of the transaction serialised with the witness data stripped.
 
 ''Total transaction size'' is the transaction size in bytes serialized as described in [[bip-0144.mediawiki|BIP144]], including base data and witness data.
 
+=== New script semantics ===
+
+Despite that the script language for P2WPKH and P2WSH looks very similar to pre-segregated witness script, there are several notable differences. Users MUST NOT assume that a script spendable in pre-segregated witness system would also be spendable as a P2WPKH or P2WSH script. Before large-scale deployment in the production network, developers should test the scripts on testnet with the default relay policy turned on, and with a small amount of money after BIP141 is activated on mainnet.
+
+A major difference at consensus level is described in [https://github.com/bitcoin/bips/blob/master/bip-0143.mediawiki BIP143], as a new transaction digest algorithm for signature verification in version 0 witness program.
+
+Three relay and mining policies are also included in the first release of segregated witness at reference implementation version 0.13.1. Softforks based on these policies are likely to be proposed in the near future. To avoid indefinite delay in transaction confirmation and permanent fund loss in a potential softfork, users MUST observe the new semantics carefully:
+
+# Only compressed public keys are accepted in P2WPKH and P2WSH (See [https://github.com/bitcoin/bips/blob/master/bip-0143.mediawiki#Restrictions_on_public_key_type BIP143])
+# The argument of OP_IF/NOTIF in P2WSH must be minimalhttps://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-August/013014.html
+# Signature(s) must be null vector(s) if an OP_CHECKSIG or OP_CHECKMULTISIG is failed (for both pre-segregated witness script and P2WSH. See [https://github.com/bitcoin/bips/blob/master/bip-0146.mediawiki BIP146])
+
 == Examples ==
 
 === P2WPKH ===
diff --git a/bip-0143.mediawiki b/bip-0143.mediawiki
index 892c0278..a0b0cceb 100644
--- a/bip-0143.mediawiki
+++ b/bip-0143.mediawiki
@@ -125,6 +125,11 @@ Refer to the reference implementation, reproduced below, for the precise algorit
   return ss.GetHash();
 
 
+== Restrictions on public key type ==
+As a default policy, only compressed public keys are accepted in P2WPKH and P2WSH. Each public key passed to a sigop inside version 0 witness program must be a compressed key: the first byte MUST be either 0x02 or 0x03, and the size MUST be 33 bytes. Transactions that break this rule will not be relayed or mined by default.
+
+Since this policy is preparation for a future softfork proposal, to avoid potential future funds loss, users MUST NOT use uncompressed keys in version 0 witness programs.
+
 == Example ==
 === Native P2WPKH ===
   
@@ -538,7 +543,7 @@ As a soft fork, older software will continue to operate without modification. No
 
 == Reference Implementation ==
 
-https://github.com/bitcoin/bitcoin/pull/7910
+https://github.com/bitcoin/bitcoin/pull/8149
 
 == References ==
 
diff --git a/bip-0144.mediawiki b/bip-0144.mediawiki
index 456da18d..f10fe0cd 100644
--- a/bip-0144.mediawiki
+++ b/bip-0144.mediawiki
@@ -117,7 +117,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/bitcoin/bitcoin/pull/8149
 
 == Copyright ==
 This document is placed in the public domain.

From 7662d7124a324ce394aad3c3912ed60fdbfb8320 Mon Sep 17 00:00:00 2001
From: Daniel Weigl 
Date: Wed, 5 Oct 2016 15:55:35 +0200
Subject: [PATCH 55/68] replace BIP-number-placeholders and calculate test
 vectors

---
 bip-0049.mediawiki | 24 ++++++++++++------------
 1 file changed, 12 insertions(+), 12 deletions(-)

diff --git a/bip-0049.mediawiki b/bip-0049.mediawiki
index 5ec371fa..d4f58d7f 100644
--- a/bip-0049.mediawiki
+++ b/bip-0049.mediawiki
@@ -30,7 +30,7 @@ Two generally different approaches are possible for current BIP44 capable wallet
 
 2) Create dedicated accounts only used for segregated witness addresses.
 
-The solutions from point 1 have a common disadvantage: if a user imports/recovers a BIP49-compatible wallet masterseed into/in a non-BIP{ThisBipNumber}-compatible wallet, the account might show up but also it might miss some UTXOs.
+The solutions from point 1 have a common disadvantage: if a user imports/recovers a BIP49-compatible wallet masterseed into/in a non-BIP49-compatible wallet, the account might show up but also it might miss some UTXOs.
 
 Therefore this BIP uses solution 2, which fails in a more visible way. Either the account shows up or not at all. The user does not have to check his balance after using the same seed in different wallets.
 
@@ -49,7 +49,7 @@ serialization method.
 m / purpose' / coin_type' / account' / change / address_index
 

 
-For the `purpose`-path level it uses {ThisBipNumber}'. The rest of the levels are used as defined in BIP44
+For the `purpose`-path level it uses `49'`. The rest of the levels are used as defined in BIP44
 
 
 ===Address derivation===
@@ -69,25 +69,25 @@ This BIP is not backwards compatible by design as described under [#consideratio
 
 ==Test vectors==
 
-(tbd. when we have the actual bip number)
 
   masterseedWords = abandon abandon abandon abandon abandon abandon abandon abandon abandon abandon abandon about
-  masterseed = 
+  masterseed = tprv8ZgxMBicQKsPe5YMU9gHen4Ez3ApihUfykaqUorj9t6FDqy3nP6eoXiAo2ssvpAjoLroQxHqr3R5nE3a5dU3DHTjTgJDd7zrbniJr6nrCzd (testnet)
 
   // Account 0, root = m/49'/0'/0'
-  account0Xpriv = 
+  account0Xpriv = tprv8fnNnm525ViePCEx7Z9cZb6QNUtsUc8XKaePnZtPnKZWHw1rnAC9r6MdMdsmrkGW7Vy3eVtwtRqrfkxfWjnitBTNEZjTb6pbui7BUmnBBd3 (testnet)
 
   // Account 0, first receiving private key = m/49'/0'/0'/0/0
-  account0recvPrivateKey = 
-  account0recvPublickKey = 
+  account0recvPrivateKey = cQHH4LLDxjDqTM2rRpEi29f9a3EAQ8A7yWxiNdR8nC8WrkKU7Dms
+  account0recvPrivateKeyHex = 0x508c73a06f6b6c817238ba61be232f5080ea4616c54f94771156934666d38ee3
+  account0recvPublickKeyHex = 0x039b3b694b8fc5b5e07fb069c783cac754f5d38c3e08bed1960e31fdb1dda35c24
 
   // Address derivation
-  keyhash = HASH160(account0recvPublickKey) = 
-  scriptSig = <0 > = 
-  addressBytes = HASH160(scriptSig) = 
+  keyhash = HASH160(account0recvPublickKeyHex) = 0xf990679acafe25c27615373b40bf22446d24ff44
+  scriptSig = <0 > = 0x0014f990679acafe25c27615373b40bf22446d24ff44
+  addressBytes = HASH160(scriptSig) = 0x3fb6e95812e57bb4691f9a4a628862a61a4f769b
 
   // addressBytes base58check encoded for testnet
-  address = base58check(prefix | addressBytes) = 1xyz....
+  address = base58check(prefix | addressBytes) = 2My47gHNc8nhX5kBWqXHU4f8uuQvQKEgwMd (testnet)
 

 
 
@@ -101,4 +101,4 @@ This BIP is not backwards compatible by design as described under [#consideratio
 
 == Copyright ==
 
-This document is placed in the public domain.
+This document is placed in the public domain.
\ No newline at end of file

From 6a8b845f63049960322fa747239f6f9c20647cf8 Mon Sep 17 00:00:00 2001
From: Luke Dashjr 
Date: Wed, 5 Oct 2016 20:08:08 +0000
Subject: [PATCH 56/68] bip-0002: Add missing Obsolete status and Requires to
 preamble overview

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

diff --git a/bip-0002.mediawiki b/bip-0002.mediawiki
index 8c745c87..97c22fe2 100644
--- a/bip-0002.mediawiki
+++ b/bip-0002.mediawiki
@@ -126,12 +126,13 @@ Each BIP must begin with an RFC 822 style header preamble. The headers must appe
 * Comments-Summary: 
   Comments-URI: 
   Status: 
+           Withdrawn | Final | Replaced | Obsolete>
   Type: 
   Created: 
   License: 
 * License-Code: 
 * Post-History: 
+* Requires: 
 * Replaces: 
 * Superseded-By: 
 


From 10fcf4ed0db168ee60662fd1bddd4370ec71e6fe Mon Sep 17 00:00:00 2001
From: Matt Corallo 
Date: Fri, 14 Oct 2016 10:09:03 -0400
Subject: [PATCH 57/68] Fix a few nits and expand on coinbase short ID calc in
 ver 2

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

diff --git a/bip-0152.mediawiki b/bip-0152.mediawiki
index cdb55b9e..53ccce6c 100644
--- a/bip-0152.mediawiki
+++ b/bip-0152.mediawiki
@@ -149,8 +149,8 @@ A new inv type (MSG_CMPCT_BLOCK == 4) and several new protocol messages are adde
 # By way of example, an implementation of the above protocol might look like the following.
 # Upon exchanging version/verack messages, a node immediately sends its list of sendcmpct announcements to the other side, with the version which it wants to receive sent first.
 # Upon receiving the first sendcmpct announcement with a protocol version which is understood from the remote peer, a node will "lock in" the compact block encoding version which will be used to encode compact blocks to that peer.
-# The node then sets the current receive-protocol-version in use on the connection as that version, and uses it to decode new compact block messages.
-# Upon receiving subsequent sendcmpct announcements with a protocol version which is understood from the remote peer, a node will check if that protocol version is higher-receive-priority than the current receive-protocol-version in use on the connection, and switch to that version for decoding new compact block messages received.
+# The node then sets the current receive-protocol-version in use on the connection to that version, and uses it to decode new compact block messages.
+# Upon receiving subsequent sendcmpct announcements with a protocol version which is understood from the remote peer (ie a version which has been announced using a sendcmpct in the other direction), a node will check if that protocol version is higher-receive-priority than the current receive-protocol-version in use on the connection, and switch to that version for decoding new compact block messages received.
 # A node might wish to keep a flag for each peer which indicates compact block version negotiation is complete, which can be set upon receiving any compact block-related, or pong message.
 # The above implementation requires only a compile-time list of supported versions in some static priority order, two version fields per peer, and an optional negotiation-complete boolean per-peer.
 
@@ -159,7 +159,7 @@ Compact blocks version 2 is almost identical to version 1, but supports segregat
 
 # The second integer (version number) inside sendcmpct is 2 instead of 1 (see Protocol Versioning section, above).
 # Transactions inside cmpctblock messages (both those used as direct announcement and those in response to getdata) and in blocktxn should include witness data, using the same format as responses to getdata MSG_WITNESS_TX, specified in BIP144.
-# Short transaction IDs sent to us in cmpctblock messages, and sent by us in getblocktxn messages, are computed using the same process as in version 1, but using the wtxid as defined in BIP 141 instead of the txid.
+# Short transaction IDs sent to us in cmpctblock messages, and sent by us in getblocktxn messages, are computed using the same process as in version 1, but using the wtxid as defined in BIP 141 instead of the txid. Note that, though a node normally SHOULD, if a node does not include (ie must then include the short ID for) the coinbase transaction, it must be computed by encoding the transaction in witness format as defined by BIP 141.
 # Upon receipt of a getdata containing a request for a MSG_CMPCT_BLOCK object for which a cmpctblock message is not sent in response, the block message containing the requested block in non-compact form MUST be encoded with witnesses (as is sent in reply to a MSG_WITNESS_BLOCK getdata) if the protocol version used to encode the cmpctblock message would have been 2, and encoded without witnesses (as is sent in response to a MSG_BLOCK getdata) if the protocol version used to encode the cmpctblock message would have been 1.
 
 ==Implementation Notes==

From bb3734349fec522dbb1a639234ee9b2152399b21 Mon Sep 17 00:00:00 2001
From: Johnson Lau 
Date: Sun, 16 Oct 2016 02:33:04 +0800
Subject: [PATCH 58/68] Add examples to show FindAndDelete is not used in
 BIP143

---
 bip-0143.mediawiki | 95 ++++++++++++++++++++++++++++++++++++++++++----
 1 file changed, 87 insertions(+), 8 deletions(-)

diff --git a/bip-0143.mediawiki b/bip-0143.mediawiki
index a0b0cceb..1c1e3527 100644
--- a/bip-0143.mediawiki
+++ b/bip-0143.mediawiki
@@ -12,7 +12,7 @@
 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]
+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 SignatureHash transaction digest algorithm:
 
@@ -39,16 +39,16 @@ Semantics of the original sighash types remain unchanged, except the followings:
 # The way of serialization is changed;
 # All sighash types commit to the amount being spent by the signed input;
 # FindAndDelete of the signature is not applied to the scriptCode;
-# OP_CODESEPARATOR(s) after the last executed OP_CODESEPARATOR are not removed from the scriptCode;
+# OP_CODESEPARATOR(s) after the last executed OP_CODESEPARATOR are not removed from the scriptCode (the last executed OP_CODESEPARATOR and any script before it are always removed);
 # SINGLE does not commit to the input index. When ANYONECANPAY is not set, the semantics are unchanged since hashPrevouts and outpoint together implictly commit to the input index. When SINGLE is used with ANYONECANPAY, omission of the index commitment allows permutation of the input-output pairs, as long as each pair is located at an equivalent index.
 
 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_CODESEPARATOR, the scriptCode is the witnessScript serialized as scripts inside CTxOuts.
-**if the witnessScript contains any OP_CODESEPARATOR, the scriptCode is the evaluated script, with everything up to and including the last executed OP_CODESEPARATOR before the signature checking opcode being executed removed, serialized as scripts inside CTxOuts.
+*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_CODESEPARATOR, the scriptCode is the witnessScript serialized as scripts inside CTxOut.
+**if the witnessScript contains any OP_CODESEPARATOR, the scriptCode is the witnessScript but removing everything up to and including the last executed OP_CODESEPARATOR before the signature checking opcode being executed, serialized as scripts inside CTxOut. (The exact semantics is demonstrated in the examples below)
 
 The item 6 is a 8-byte value of the amount of bitcoin spent in this input.
 
@@ -126,11 +126,14 @@ Refer to the reference implementation, reproduced below, for the precise algorit
 
 
 == Restrictions on public key type ==
-As a default policy, only compressed public keys are accepted in P2WPKH and P2WSH. Each public key passed to a sigop inside version 0 witness program must be a compressed key: the first byte MUST be either 0x02 or 0x03, and the size MUST be 33 bytes. Transactions that break this rule will not be relayed or mined by default.
+As a default policy, only compressed public keys are accepted in P2WPKH and P2WSH. Each public key passed to a sigop inside version 0 witness program must be a compressed key: the first byte MUST be either 0x02 or 0x03, and the size MUST be 33 bytes. Transactions that break this rule will not be relayed or mined by default.
 
 Since this policy is preparation for a future softfork proposal, to avoid potential future funds loss, users MUST NOT use uncompressed keys in version 0 witness programs.
 
 == Example ==
+
+To ensure consistency in consensus-critical behaviour, developers should test their implementations against all the tests below. More tests related to this proposal could be found under https://github.com/bitcoin/bitcoin/tree/master/src/test/data .
+
 === Native P2WPKH ===
   
   The following is an unsigned transaction:
@@ -531,6 +534,82 @@ This example is a P2SH-P2WSH 6-of-6 multisig witness program signed with 6 diffe
   The serialized signed transaction is: 0100000000010136641869ca081e70f394c6948e8af409e18b619df2ed74aa106c1ca29787b96e0100000023220020a16b5755f7f6f96dbd65f5f0d6ab9418b89af4b1f14a1bb8a09062c35f0dcb54ffffffff0200e9a435000000001976a914389ffce9cd9ae88dcc0631e88a821ffdbe9bfe2688acc0832f05000000001976a9147480a33f950689af511e6e84c138dbbd3c3ee41588ac080047304402206ac44d672dac41f9b00e28f4df20c52eeb087207e8d758d76d92c6fab3b73e2b0220367750dbbe19290069cba53d096f44530e4f98acaa594810388cf7409a1870ce01473044022068c7946a43232757cbdf9176f009a928e1cd9a1a8c212f15c1e11ac9f2925d9002205b75f937ff2f9f3c1246e547e54f62e027f64eefa2695578cc6432cdabce271502473044022059ebf56d98010a932cf8ecfec54c48e6139ed6adb0728c09cbe1e4fa0915302e022007cd986c8fa870ff5d2b3a89139c9fe7e499259875357e20fcbb15571c76795403483045022100fbefd94bd0a488d50b79102b5dad4ab6ced30c4069f1eaa69a4b5a763414067e02203156c6a5c9cf88f91265f5a942e96213afae16d83321c8b31bb342142a14d16381483045022100a5263ea0553ba89221984bd7f0b13613db16e7a70c549a86de0cc0444141a407022005c360ef0ae5a5d4f9f2f87a56c1546cc8268cab08c73501d6b3be2e1e1a8a08824730440220525406a1482936d5a21888260dc165497a90a15669636d8edca6b9fe490d309c022032af0c646a34a44d1f4576bf6a4a74b67940f8faa84c7df9abe12a01a11e2b4783cf56210307b8ae49ac90a048e9b53357a2354b3334e9c8bee813ecb98e99a7e07e8c3ba32103b28f0c28bfab54554ae8c658ac5c3e0ce6e79ad336331f78c428dd43eea8449b21034b8113d703413d57761b8b9781957b8c0ac1dfe69f492580ca4195f50376ba4a21033400f6afecb833092a9a21cfdf1ed1376e58c5d1f47de74683123987e967a8f42103a6d48b1131e94ba04d9737d61acdaa1322008af9602b3b14862c07a1789aac162102d8b661b0b3302ee2f162b09e07a55ad5dfbe673a9f01d9f0c19617681024306b56ae00000000
 
 
+=== No FindAndDelete ===
+
+These examples show that FindAndDelete for the signature is not applied. The transactions are generated in an unconventional way. Instead of signing using a private key, the signatures are pre-determined as part of witnessScript. The public keys are generated with key recovery, using the fixed signatures and the sighash defined in this proposal. Therefore, the private keys are unknown.
+
+  
+  The following is an unsigned transaction: 010000000169c12106097dc2e0526493ef67f21269fe888ef05c7a3a5dacab38e1ac8387f14c1d000000ffffffff0101000000000000000000000000
+  
+    nVersion:  01000000
+    txin:      01 69c12106097dc2e0526493ef67f21269fe888ef05c7a3a5dacab38e1ac8387f1 4c1d0000 00 ffffffff
+    txout:     01 0100000000000000 00
+    nLockTime: 00000000
+  
+  The input comes from a P2WSH witness program:
+    scriptPubKey : 00209e1be07558ea5cc8e02ed1d80c0911048afad949affa36d5c3951e3159dbea19, value: 200000
+    redeemScript : OP_CHECKSIGVERIFY <0x30450220487fb382c4974de3f7d834c1b617fe15860828c7f96454490edd6d891556dcc9022100baf95feb48f845d5bfc9882eb6aeefa1bc3790e39f59eaa46ff7f15ae626c53e01>
+                   ad4830450220487fb382c4974de3f7d834c1b617fe15860828c7f96454490edd6d891556dcc9022100baf95feb48f845d5bfc9882eb6aeefa1bc3790e39f59eaa46ff7f15ae626c53e01
+  
+  To sign it with a nHashType of 1 (SIGHASH_ALL):
+  
+  hashPrevouts:
+    dSHA256(69c12106097dc2e0526493ef67f21269fe888ef05c7a3a5dacab38e1ac8387f14c1d0000)
+  = b67c76d200c6ce72962d919dc107884b9d5d0e26f2aea7474b46a1904c53359f
+  
+  hashSequence:
+    dSHA256(ffffffff)
+  = 3bb13029ce7b1f559ef5e747fcac439f1455a2ec7c5f09b72290795e70665044
+  
+  hashOutputs:
+    dSHA256(010000000000000000)
+  = e5d196bfb21caca9dbd654cafb3b4dc0c4882c8927d2eb300d9539dd0b934228
+  
+  hash preimage: 01000000b67c76d200c6ce72962d919dc107884b9d5d0e26f2aea7474b46a1904c53359f3bb13029ce7b1f559ef5e747fcac439f1455a2ec7c5f09b72290795e7066504469c12106097dc2e0526493ef67f21269fe888ef05c7a3a5dacab38e1ac8387f14c1d00004aad4830450220487fb382c4974de3f7d834c1b617fe15860828c7f96454490edd6d891556dcc9022100baf95feb48f845d5bfc9882eb6aeefa1bc3790e39f59eaa46ff7f15ae626c53e01400d030000000000ffffffffe5d196bfb21caca9dbd654cafb3b4dc0c4882c8927d2eb300d9539dd0b9342280000000001000000
+  
+    nVersion:     01000000
+    hashPrevouts: b67c76d200c6ce72962d919dc107884b9d5d0e26f2aea7474b46a1904c53359f
+    hashSequence: 3bb13029ce7b1f559ef5e747fcac439f1455a2ec7c5f09b72290795e70665044
+    outpoint:     69c12106097dc2e0526493ef67f21269fe888ef05c7a3a5dacab38e1ac8387f14c1d0000
+    scriptCode:   4aad4830450220487fb382c4974de3f7d834c1b617fe15860828c7f96454490edd6d891556dcc9022100baf95feb48f845d5bfc9882eb6aeefa1bc3790e39f59eaa46ff7f15ae626c53e01
+    amount:       400d030000000000
+    nSequence:    ffffffff
+    hashOutputs:  e5d196bfb21caca9dbd654cafb3b4dc0c4882c8927d2eb300d9539dd0b934228
+    nLockTime:    00000000
+    nHashType:    01000000
+  
+  sigHash:      71c9cd9b2869b9c70b01b1f0360c148f42dee72297db312638df136f43311f23
+  signature:    30450220487fb382c4974de3f7d834c1b617fe15860828c7f96454490edd6d891556dcc9022100baf95feb48f845d5bfc9882eb6aeefa1bc3790e39f59eaa46ff7f15ae626c53e 01
+  pubkey:       02a9781d66b61fb5a7ef00ac5ad5bc6ffc78be7b44a566e3c87870e1079368df4c
+  
+  The serialized signed transaction is: 034830450220487fb382c4974de3f7d834c1b617fe15860828c7f96454490edd6d891556dcc9022100baf95feb48f845d5bfc9882eb6aeefa1bc3790e39f59eaa46ff7f15ae626c53e012102a9781d66b61fb5a7ef00ac5ad5bc6ffc78be7b44a566e3c87870e1079368df4c4aad4830450220487fb382c4974de3f7d834c1b617fe15860828c7f96454490edd6d891556dcc9022100baf95feb48f845d5bfc9882eb6aeefa1bc3790e39f59eaa46ff7f15ae626c53e0100000000
+  
+    nVersion:  01000000
+    marker:    00
+    flag:      01
+    txin:      01 69c12106097dc2e0526493ef67f21269fe888ef05c7a3a5dacab38e1ac8387f1 4c1d0000 00 ffffffff
+    txout:     01 0100000000000000 00
+    witness:   03 4830450220487fb382c4974de3f7d834c1b617fe15860828c7f96454490edd6d891556dcc9022100baf95feb48f845d5bfc9882eb6aeefa1bc3790e39f59eaa46ff7f15ae626c53e01
+                  2102a9781d66b61fb5a7ef00ac5ad5bc6ffc78be7b44a566e3c87870e1079368df4c
+                  4aad4830450220487fb382c4974de3f7d834c1b617fe15860828c7f96454490edd6d891556dcc9022100baf95feb48f845d5bfc9882eb6aeefa1bc3790e39f59eaa46ff7f15ae626c53e01
+    nLockTime: 00000000
+  
+
+  
+  The following transaction is a OP_CHECKMULTISIGVERIFY version of the FindAndDelete examples: 010000000001019275cb8d4a485ce95741c013f7c0d28722160008021bb469a11982d47a6628964c1d000000ffffffff0101000000000000000007004830450220487fb382c4974de3f7d834c1b617fe15860828c7f96454490edd6d891556dcc9022100baf95feb48f845d5bfc9882eb6aeefa1bc3790e39f59eaa46ff7f15ae626c53e0148304502205286f726690b2e9b0207f0345711e63fa7012045b9eb0f19c2458ce1db90cf43022100e89f17f86abc5b149eba4115d4f128bcf45d77fb3ecdd34f594091340c0395960101022102966f109c54e85d3aee8321301136cedeb9fc710fdef58a9de8a73942f8e567c021034ffc99dd9a79dd3cb31e2ab3e0b09e0e67db41ac068c625cd1f491576016c84e9552af4830450220487fb382c4974de3f7d834c1b617fe15860828c7f96454490edd6d891556dcc9022100baf95feb48f845d5bfc9882eb6aeefa1bc3790e39f59eaa46ff7f15ae626c53e0148304502205286f726690b2e9b0207f0345711e63fa7012045b9eb0f19c2458ce1db90cf43022100e89f17f86abc5b149eba4115d4f128bcf45d77fb3ecdd34f594091340c039596017500000000
+  
+  redeemScript:  OP_2 OP_CHECKMULTISIGVERIFY <30450220487fb382c4974de3f7d834c1b617fe15860828c7f96454490edd6d891556dcc9022100baf95feb48f845d5bfc9882eb6aeefa1bc3790e39f59eaa46ff7f15ae626c53e01> <304502205286f726690b2e9b0207f0345711e63fa7012045b9eb0f19c2458ce1db90cf43022100e89f17f86abc5b149eba4115d4f128bcf45d77fb3ecdd34f594091340c03959601>
+  hash preimage: 0100000039283953eb1e26994dde57b7f9362a79a8c523e2f8deba943c27e826a005f1e63bb13029ce7b1f559ef5e747fcac439f1455a2ec7c5f09b72290795e706650449275cb8d4a485ce95741c013f7c0d28722160008021bb469a11982d47a6628964c1d00009552af4830450220487fb382c4974de3f7d834c1b617fe15860828c7f96454490edd6d891556dcc9022100baf95feb48f845d5bfc9882eb6aeefa1bc3790e39f59eaa46ff7f15ae626c53e0148304502205286f726690b2e9b0207f0345711e63fa7012045b9eb0f19c2458ce1db90cf43022100e89f17f86abc5b149eba4115d4f128bcf45d77fb3ecdd34f594091340c0395960175400d030000000000ffffffffe5d196bfb21caca9dbd654cafb3b4dc0c4882c8927d2eb300d9539dd0b9342280000000001000000
+  sighash:       c1628a1e7c67f14ca0c27c06e4fdeec2e6d1a73c7a91d7c046ff83e835aebb72
+  witness:       07 00
+                    4830450220487fb382c4974de3f7d834c1b617fe15860828c7f96454490edd6d891556dcc9022100baf95feb48f845d5bfc9882eb6aeefa1bc3790e39f59eaa46ff7f15ae626c53e01
+                    48304502205286f726690b2e9b0207f0345711e63fa7012045b9eb0f19c2458ce1db90cf43022100e89f17f86abc5b149eba4115d4f128bcf45d77fb3ecdd34f594091340c03959601
+                    0102
+                    2102966f109c54e85d3aee8321301136cedeb9fc710fdef58a9de8a73942f8e567c0
+                    21034ffc99dd9a79dd3cb31e2ab3e0b09e0e67db41ac068c625cd1f491576016c84e
+                    9552af4830450220487fb382c4974de3f7d834c1b617fe15860828c7f96454490edd6d891556dcc9022100baf95feb48f845d5bfc9882eb6aeefa1bc3790e39f59eaa46ff7f15ae626c53e0148304502205286f726690b2e9b0207f0345711e63fa7012045b9eb0f19c2458ce1db90cf43022100e89f17f86abc5b149eba4115d4f128bcf45d77fb3ecdd34f594091340c0395960175
+
+
 The new serialization format is described in BIP144 [[bip-0144.mediawiki|BIP144: Segregated Witness (Peer Services)]]
 
 == Deployment ==
@@ -547,7 +626,7 @@ https://github.com/bitcoin/bitcoin/pull/8149
 
 == References ==
 
-
+
 
 == Copyright ==
 

From 61e766b9dd78e5d7cd738e34cf5a86e23289c5bd Mon Sep 17 00:00:00 2001
From: Daniel Weigl 
Date: Sun, 16 Oct 2016 17:25:14 +0200
Subject: [PATCH 59/68] fix wrong cointype for test vectors - use m/49'/1'/0'
 for testnet

---
 bip-0049.mediawiki | 20 ++++++++++----------
 1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/bip-0049.mediawiki b/bip-0049.mediawiki
index d4f58d7f..4460ba76 100644
--- a/bip-0049.mediawiki
+++ b/bip-0049.mediawiki
@@ -73,21 +73,21 @@ This BIP is not backwards compatible by design as described under [#consideratio
   masterseedWords = abandon abandon abandon abandon abandon abandon abandon abandon abandon abandon abandon about
   masterseed = tprv8ZgxMBicQKsPe5YMU9gHen4Ez3ApihUfykaqUorj9t6FDqy3nP6eoXiAo2ssvpAjoLroQxHqr3R5nE3a5dU3DHTjTgJDd7zrbniJr6nrCzd (testnet)
 
-  // Account 0, root = m/49'/0'/0'
-  account0Xpriv = tprv8fnNnm525ViePCEx7Z9cZb6QNUtsUc8XKaePnZtPnKZWHw1rnAC9r6MdMdsmrkGW7Vy3eVtwtRqrfkxfWjnitBTNEZjTb6pbui7BUmnBBd3 (testnet)
+  // Account 0, root = m/49'/1'/0'
+  account0Xpriv = tprv8gRrNu65W2Msef2BdBSUgFdRTGzC8EwVXnV7UGS3faeXtuMVtGfEdidVeGbThs4ELEoayCAzZQ4uUji9DUiAs7erdVskqju7hrBcDvDsdbY (testnet)
 
-  // Account 0, first receiving private key = m/49'/0'/0'/0/0
-  account0recvPrivateKey = cQHH4LLDxjDqTM2rRpEi29f9a3EAQ8A7yWxiNdR8nC8WrkKU7Dms
-  account0recvPrivateKeyHex = 0x508c73a06f6b6c817238ba61be232f5080ea4616c54f94771156934666d38ee3
-  account0recvPublickKeyHex = 0x039b3b694b8fc5b5e07fb069c783cac754f5d38c3e08bed1960e31fdb1dda35c24
+  // Account 0, first receiving private key = m/49'/1'/0'/0/0
+  account0recvPrivateKey = cULrpoZGXiuC19Uhvykx7NugygA3k86b3hmdCeyvHYQZSxojGyXJ
+  account0recvPrivateKeyHex = 0xc9bdb49cfbaedca21c4b1f3a7803c34636b1d7dc55a717132443fc3f4c5867e8
+  account0recvPublickKeyHex = 0x03a1af804ac108a8a51782198c2d034b28bf90c8803f5a53f76276fa69a4eae77f
 
   // Address derivation
-  keyhash = HASH160(account0recvPublickKeyHex) = 0xf990679acafe25c27615373b40bf22446d24ff44
-  scriptSig = <0 > = 0x0014f990679acafe25c27615373b40bf22446d24ff44
-  addressBytes = HASH160(scriptSig) = 0x3fb6e95812e57bb4691f9a4a628862a61a4f769b
+  keyhash = HASH160(account0recvPublickKeyHex) = 0x38971f73930f6c141d977ac4fd4a727c854935b3
+  scriptSig = <0 > = 0x001438971f73930f6c141d977ac4fd4a727c854935b3
+  addressBytes = HASH160(scriptSig) = 0x336caa13e08b96080a32b5d818d59b4ab3b36742
 
   // addressBytes base58check encoded for testnet
-  address = base58check(prefix | addressBytes) = 2My47gHNc8nhX5kBWqXHU4f8uuQvQKEgwMd (testnet)
+  address = base58check(prefix | addressBytes) = 2Mww8dCYPUpKHofjgcXcBCEGmniw9CoaiD2 (testnet)
From 5c2da7e07d924c34af4edf7098981c9a376263d2 Mon Sep 17 00:00:00 2001 From: Pieter Wuille Date: Mon, 17 Oct 2016 13:16:10 +0200 Subject: [PATCH 60/68] BIP 141 start and end time --- bip-0141.mediawiki | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/bip-0141.mediawiki b/bip-0141.mediawiki index 6df2624d..352256f7 100644 --- a/bip-0141.mediawiki +++ b/bip-0141.mediawiki @@ -299,7 +299,7 @@ As a soft fork, older software will continue to operate without modification. N This BIP will be deployed by "version bits" BIP9 with the name "segwit" and using bit 1. -For Bitcoin mainnet, the BIP9 starttime will be midnight TBD UTC (Epoch timestamp TBD) and BIP9 timeout will be midnight TBD UTC (Epoch timestamp TBD). +For Bitcoin mainnet, the BIP9 starttime will be midnight 15 november 2016 UTC (Epoch timestamp 1479168000) and BIP9 timeout will be midnight 15 november 2017 UTC (Epoch timestamp 1510704000). For Bitcoin testnet, the BIP9 starttime will be midnight 1 May 2016 UTC (Epoch timestamp 1462060800) and BIP9 timeout will be midnight 1 May 2017 UTC (Epoch timestamp 1493596800). From 20673078748a4a3f225c91edff353f707190d9c8 Mon Sep 17 00:00:00 2001 From: Johnson Lau Date: Mon, 17 Oct 2016 20:18:35 +0800 Subject: [PATCH 61/68] Add start day for BIP147 --- bip-0147.mediawiki | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/bip-0147.mediawiki b/bip-0147.mediawiki index 352f48d4..001abc65 100644 --- a/bip-0147.mediawiki +++ b/bip-0147.mediawiki @@ -28,7 +28,7 @@ To fix the dummy element malleability, a new consensus rule ("NULLDUMMY Date: Mon, 17 Oct 2016 15:33:17 +0100 Subject: [PATCH 62/68] Update segwit deployment details --- bip-0009/assignments.mediawiki | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/bip-0009/assignments.mediawiki b/bip-0009/assignments.mediawiki index e145ceb0..6a12e791 100644 --- a/bip-0009/assignments.mediawiki +++ b/bip-0009/assignments.mediawiki @@ -27,11 +27,11 @@ State can be defined, active, failed. Dates are in UTC. |- | segwit | 1 -| TBD -| TBD +| 2016-11-15 00:00:00 +| 2017-11-15 00:00:00 | - | 2016-05-01 00:00:00 | 2017-05-01 00:00:00 | active since #834624 -| [[/bip-0141.mediawiki|141]], [[/bip-0143.mediawiki|143]] +| [[/bip-0141.mediawiki|141]], [[/bip-0143.mediawiki|143]], [[/bip-0147.mediawiki|147]] |} From d75418ee38544c88aff746f6c98405d0924d099c Mon Sep 17 00:00:00 2001 From: Richard Kiss Date: Tue, 1 Nov 2016 20:16:30 -0700 Subject: [PATCH 63/68] BIP143 - Fix hex of first FindAndDelete example (was just witness data). --- bip-0143.mediawiki | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/bip-0143.mediawiki b/bip-0143.mediawiki index 1c1e3527..766fd9f2 100644 --- a/bip-0143.mediawiki +++ b/bip-0143.mediawiki @@ -582,8 +582,8 @@ These examples show that FindAndDelete for the signature is not app signature: 30450220487fb382c4974de3f7d834c1b617fe15860828c7f96454490edd6d891556dcc9022100baf95feb48f845d5bfc9882eb6aeefa1bc3790e39f59eaa46ff7f15ae626c53e 01 pubkey: 02a9781d66b61fb5a7ef00ac5ad5bc6ffc78be7b44a566e3c87870e1079368df4c - The serialized signed transaction is: 034830450220487fb382c4974de3f7d834c1b617fe15860828c7f96454490edd6d891556dcc9022100baf95feb48f845d5bfc9882eb6aeefa1bc3790e39f59eaa46ff7f15ae626c53e012102a9781d66b61fb5a7ef00ac5ad5bc6ffc78be7b44a566e3c87870e1079368df4c4aad4830450220487fb382c4974de3f7d834c1b617fe15860828c7f96454490edd6d891556dcc9022100baf95feb48f845d5bfc9882eb6aeefa1bc3790e39f59eaa46ff7f15ae626c53e0100000000 - + The serialized signed transaction is: 0100000000010169c12106097dc2e0526493ef67f21269fe888ef05c7a3a5dacab38e1ac8387f14c1d000000ffffffff01010000000000000000034830450220487fb382c4974de3f7d834c1b617fe15860828c7f96454490edd6d891556dcc9022100baf95feb48f845d5bfc9882eb6aeefa1bc3790e39f59eaa46ff7f15ae626c53e012102a9781d66b61fb5a7ef00ac5ad5bc6ffc78be7b44a566e3c87870e1079368df4c4aad4830450220487fb382c4974de3f7d834c1b617fe15860828c7f96454490edd6d891556dcc9022100baf95feb48f845d5bfc9882eb6aeefa1bc3790e39f59eaa46ff7f15ae626c53e0100000000 + nVersion: 01000000 marker: 00 flag: 01 From 5b1c59da6d4905610de0c779579cd2db890a7c4c Mon Sep 17 00:00:00 2001 From: Thomas Kerin Date: Thu, 3 Nov 2016 10:14:41 +0100 Subject: [PATCH 64/68] BIP39: 'recommended size' -> 'allowed size' --- bip-0039.mediawiki | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/bip-0039.mediawiki b/bip-0039.mediawiki index 3c95d4d1..f0f59099 100644 --- a/bip-0039.mediawiki +++ b/bip-0039.mediawiki @@ -33,7 +33,7 @@ sentences (also known as brainwallets) into a wallet seed. The mnemonic must encode entropy in a multiple of 32 bits. With more entropy security is improved but the sentence length increases. We refer to the -initial entropy length as ENT. The recommended size of ENT is 128-256 bits. +initial entropy length as ENT. The allowed size of ENT is 128-256 bits. First, an initial entropy of ENT bits is generated. A checksum is generated by taking the first 
ENT / 32
bits of its SHA256 hash. This checksum is From 78c3b0a244a46f489de723318bbca6f8a9f6497a Mon Sep 17 00:00:00 2001 From: Suhas Daftuar Date: Thu, 3 Nov 2016 08:12:16 -0400 Subject: [PATCH 65/68] [BIP 152] Fix invalid link --- bip-0152.mediawiki | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/bip-0152.mediawiki b/bip-0152.mediawiki index 53ccce6c..73777961 100644 --- a/bip-0152.mediawiki +++ b/bip-0152.mediawiki @@ -26,7 +26,7 @@ While the goal of this work is explicitly not to reduce block transfer latency, ===Intended Protocol Flow=== -The protocol is intended to be used in two ways, depending on the peers and bandwidth available, as discussed [[#Implementation_Details|later]]. The "high-bandwidth" mode, which nodes may only enable for a few of their peers, is enabled by setting the first boolean to 1 in a sendcmpct message. In this mode, peers send new block announcements with the short transaction IDs already (via a cmpctblock message), possibly even before fully validating the block (as indicated by the grey box in the image above). In some cases no further round-trip is needed, and the receiver can reconstruct the block and process it as usual immediately. When some transactions were not available from local sources (ie mempool), a getblocktxn/blocktxn roundtrip is necessary, bringing the best-case latency to the same 1.5*RTT minimum time that nodes take today, though with significantly less bandwidth usage. +The protocol is intended to be used in two ways, depending on the peers and bandwidth available, as discussed [[#Implementation_Notes|later]]. The "high-bandwidth" mode, which nodes may only enable for a few of their peers, is enabled by setting the first boolean to 1 in a sendcmpct message. In this mode, peers send new block announcements with the short transaction IDs already (via a cmpctblock message), possibly even before fully validating the block (as indicated by the grey box in the image above). In some cases no further round-trip is needed, and the receiver can reconstruct the block and process it as usual immediately. When some transactions were not available from local sources (ie mempool), a getblocktxn/blocktxn roundtrip is necessary, bringing the best-case latency to the same 1.5*RTT minimum time that nodes take today, though with significantly less bandwidth usage. The "low-bandwidth" mode is enabled by setting the first boolean to 0 in a sendcmpct message. In this mode, peers send new block announcements with the usual inv/headers announcements (as per BIP130, and after fully validating the block). The receiving peer may then request the block using a MSG_CMPCT_BLOCK getdata request, which will receive a response of the header and short transaction IDs. In some cases no further round-trip is needed, and the receiver can reconstruct the block and process it as usual, taking the same 1.5*RTT minimum time that nodes take today, though with significantly less bandwidth usage. When some transactions were not available from local sources (ie mempool), a getblocktxn/blocktxn roundtrip is necessary, bringing the latency to at least 2.5*RTT in this case, again with significantly less bandwidth usage than today. Because TCP often exhibits worse transfer latency for larger data sizes (as a multiple of RTT), total latency is expected to be reduced even when the full 2.5*RTT transfer mechanism is used. From 30620da93cb7841e7c7f4d8797ebbaeaf02b8e64 Mon Sep 17 00:00:00 2001 From: Suhas Daftuar Date: Thu, 3 Nov 2016 08:29:18 -0400 Subject: [PATCH 66/68] [BIP 152] Bump p2p protocol for proper banning behavior --- bip-0152.mediawiki | 2 ++ 1 file changed, 2 insertions(+) diff --git a/bip-0152.mediawiki b/bip-0152.mediawiki index 73777961..b1cc468c 100644 --- a/bip-0152.mediawiki +++ b/bip-0152.mediawiki @@ -183,6 +183,8 @@ Compact blocks version 2 is almost identical to version 1, but supports segregat # Any undefined behavior in this spec may cause failure to transfer block to, peer disconnection by, or self-destruction by the receiving node. A node receiving non-minimally-encoded CompactSize encodings should make a best-effort to eat the sender's cat. +# As high-bandwidth mode permits relaying of CMPCTBLOCK messages prior to full validation (requiring only that the block header is valid before relay), nodes SHOULD NOT ban a peer for announcing a new block with a CMPCTBLOCK message that is invalid, but has a valid header. For avoidance of doubt, nodes SHOULD bump their peer-to-peer protocol version to 70015 or higher to signal that they will not ban or punish a peer for announcing compact blocks prior to full validation, and nodes SHOULD NOT announce a CMPCTBLOCK to a peer with a version number below 70015 before fully validating the block. + ==Justification== ====Protocol design==== From 21985daefb0db972c942b8241e880ce7d4f3d635 Mon Sep 17 00:00:00 2001 From: Russell Yanofsky Date: Mon, 14 Nov 2016 10:56:49 -0500 Subject: [PATCH 67/68] BIP152: Fix missing space between words. --- bip-0152.mediawiki | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/bip-0152.mediawiki b/bip-0152.mediawiki index 53ccce6c..2621ea9c 100644 --- a/bip-0152.mediawiki +++ b/bip-0152.mediawiki @@ -128,7 +128,7 @@ A new inv type (MSG_CMPCT_BLOCK == 4) and several new protocol messages are adde ====getblocktxn==== # The getblocktxn message is defined as as a message containing a serialized BlockTransactionsRequest message and pchCommand == "getblocktxn". -# Upon receipt of a properly-formatted getblocktxnmessage, nodes which recently provided the sender of such a message a cmpctblock for the block hash identified in this message MUST respond with an appropriate blocktxn message. Such a blocktxn message MUST contain exactly and only each transaction which is present in the appropriate block at the index specified in the getblocktxn indexes list, in the order requested. +# Upon receipt of a properly-formatted getblocktxn message, nodes which recently provided the sender of such a message a cmpctblock for the block hash identified in this message MUST respond with an appropriate blocktxn message. Such a blocktxn message MUST contain exactly and only each transaction which is present in the appropriate block at the index specified in the getblocktxn indexes list, in the order requested. ====blocktxn==== # The blocktxn message is defined as as a message containing a serialized BlockTransactions message and pchCommand == "blocktxn". From 376029beea0f0bec52531747291319b4c8b2ccdb Mon Sep 17 00:00:00 2001 From: Russell Yanofsky Date: Mon, 14 Nov 2016 10:58:22 -0500 Subject: [PATCH 68/68] BIP152: Allow block responses to getblocktxn requests Corresponding bitcoind change in: dac53b5 Modify getblocktxn handler not to drop requests for old blocks --- bip-0152.mediawiki | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/bip-0152.mediawiki b/bip-0152.mediawiki index 2621ea9c..8f6d0238 100644 --- a/bip-0152.mediawiki +++ b/bip-0152.mediawiki @@ -128,7 +128,7 @@ A new inv type (MSG_CMPCT_BLOCK == 4) and several new protocol messages are adde ====getblocktxn==== # The getblocktxn message is defined as as a message containing a serialized BlockTransactionsRequest message and pchCommand == "getblocktxn". -# Upon receipt of a properly-formatted getblocktxn message, nodes which recently provided the sender of such a message a cmpctblock for the block hash identified in this message MUST respond with an appropriate blocktxn message. Such a blocktxn message MUST contain exactly and only each transaction which is present in the appropriate block at the index specified in the getblocktxn indexes list, in the order requested. +# Upon receipt of a properly-formatted getblocktxn message, nodes which recently provided the sender of such a message a cmpctblock for the block hash identified in this message MUST respond with either an appropriate blocktxn message, or a full block message. A blocktxn response MUST contain exactly and only each transaction which is present in the appropriate block at the index specified in the getblocktxn indexes list, in the order requested. ====blocktxn==== # The blocktxn message is defined as as a message containing a serialized BlockTransactions message and pchCommand == "blocktxn".