Merge remote-tracking branch 'upstream/master'

# Please enter a commit message to explain why this merge is necessary,
# especially if it merges an updated upstream into a topic branch.
#
# Lines starting with '#' will be ignored, and an empty message aborts
# the commit.

13 files changed, 176 insertions, 60 deletions

diff --git a/README.mediawiki b/README.mediawiki
index ee7b0d8..239294f 100644
--- a/README.mediawiki
+++ b/README.mediawiki
@@ -271,12 +271,12 @@ Those proposing changes should consider that ultimately consent may rest with th
 | Thomas Kerin, Jean-Pierre Rupp, Ruben de Vries
 | Standard
 | Draft
-|-
+|- style="background-color: #cfffcf"
 | [[bip-0068.mediawiki|68]]
 | Relative lock-time using consensus-enforced sequence numbers
 | Mark Friedenbach, BtcDrak, Nicolas Dorier, kinoshitajona
 | Standard
-| Draft
+| Final
 |-
 | [[bip-0069.mediawiki|69]]
 | Lexicographical Indexing of Transaction Inputs and Outputs
@@ -391,18 +391,18 @@ Those proposing changes should consider that ultimately consent may rest with th
 | Matt Corallo, Peter Todd
 | Standard
 | Draft
-|-
+|- style="background-color: #cfffcf"
 | [[bip-0112.mediawiki|112]]
 | CHECKSEQUENCEVERIFY
 | BtcDrak, Mark Friedenbach, Eric Lombrozo
 | Standard
-| Draft
-|-
+| Final
+|- style="background-color: #cfffcf"
 | [[bip-0113.mediawiki|113]]
 | Median time-past as endpoint for lock-time calculations
 | Thomas Kerin, Mark Friedenbach
 | Standard
-| Draft
+| Final
 |-
 | [[bip-0114.mediawiki|114]]
 | Merkelized Abstract Syntax Tree
@@ -446,6 +446,12 @@ Those proposing changes should consider that ultimately consent may rest with th
 | Standard
 | Draft
 |-
+| [[bip-0126.mediawiki|126]]
+| Best Practices for Heterogeneous Input Script Transactions
+| Kristov Atlas
+| Informational
+| Draft
+|-
 | [[bip-0130.mediawiki|130]]
 | sendheaders message
 | Suhas Daftuar
diff --git a/bip-0009/assignments.mediawiki b/bip-0009/assignments.mediawiki
index ee56e17..e145ceb 100644
--- a/bip-0009/assignments.mediawiki
+++ b/bip-0009/assignments.mediawiki
@@ -18,11 +18,11 @@ State can be defined, active, failed. Dates are in UTC.
 | csv
 | 0
 | 2016-05-01 00:00:00
-| 2017-05-01 00:00:00 
-| defined
+| 2017-05-01 00:00:00
+| active since #419328
 | 2016-03-01 00:00:00
 | 2017-05-01 00:00:00
-| active since #770111
+| active since #770112
 | [[/bip-0068.mediawiki|68]], [[/bip-0112.mediawiki|112]], [[/bip-0113.mediawiki|113]]
 |-
 | segwit
@@ -32,6 +32,6 @@ State can be defined, active, failed. Dates are in UTC.
 | -
 | 2016-05-01 00:00:00
 | 2017-05-01 00:00:00
-| defined
+| active since #834624
 | [[/bip-0141.mediawiki|141]], [[/bip-0143.mediawiki|143]]
 |}
diff --git a/bip-0021.mediawiki b/bip-0021.mediawiki
index e7094e5..daf4cf8 100644
--- a/bip-0021.mediawiki
+++ b/bip-0021.mediawiki
@@ -122,3 +122,6 @@ Characters must be URI encoded properly.
 === Bitcoin clients ===
 * Bitcoin-Qt supports the old version of Bitcoin URIs (ie without the req- prefix), with Windows and KDE integration as of commit 70f55355e29c8e45b607e782c5d76609d23cc858.
 
+=== Libraries ===
+* Javascript - https://github.com/bitcoinjs/bip21
+* https://github.com/SandroMachado/BitcoinPaymentURI Java library to process and generate Bitcoin payment URI's.
diff --git a/bip-0032.mediawiki b/bip-0032.mediawiki
index 8692c6d..0c660ad 100644
--- a/bip-0032.mediawiki
+++ b/bip-0032.mediawiki
@@ -257,7 +257,7 @@ Two Python implementations exist:
 
 PyCoin (https://github.com/richardkiss/pycoin) is a suite of utilities for dealing with Bitcoin that includes BIP0032 wallet features.  BIP32Utils (https://github.com/jmcorgan/bip32utils) is a library and command line interface specifically focused on BIP0032 wallets and scripting.
 
-A Java implementation is available at https://github.com/bitsofproof/supernode/blob/1.1/api/src/main/java/com/bitsofproof/supernode/api/ExtendedKey.java
+2 Java implementations exist: https://github.com/bitsofproof/supernode/blob/1.1/api/src/main/java/com/bitsofproof/supernode/api/ExtendedKey.java and https://github.com/bushidowallet/bushido-java-core/tree/master/src/main/java/com/bushidowallet/core/bitcoin/bip32
 
 A C++ implementation is available at https://github.com/ciphrex/mSIGNA/blob/master/deps/CoinCore/src/hdkeys.h
 
diff --git a/bip-0039.mediawiki b/bip-0039.mediawiki
index b553666..0d05d81 100644
--- a/bip-0039.mediawiki
+++ b/bip-0039.mediawiki
@@ -131,12 +131,18 @@ http://github.com/trezor/python-mnemonic
 
 ==Other Implementations==
 
-Objective-C - https://github.com/nybex/NYMnemonic
+Objective-C:
+* https://github.com/nybex/NYMnemonic
 
-Haskell - https://github.com/haskoin/haskoin
+Haskell:
+* https://github.com/haskoin/haskoin
 
-.NET C# (PCL) - https://github.com/Thashiznets/BIP39.NET
+.NET C# (PCL):
+* https://github.com/Thashiznets/BIP39.NET
 
-.NET C# (PCL) - https://github.com/NicolasDorier/NBitcoin
+.NET C# (PCL):
+* https://github.com/NicolasDorier/NBitcoin
 
-JavaScript - https://github.com/bitpay/bitcore-mnemonic, https://github.com/bitcoinjs/bip39
+JavaScript:
+* https://github.com/bitpay/bitcore-mnemonic
+* https://github.com/bitcoinjs/bip39 (used by [[https://github.com/blockchain/My-Wallet-V3/blob/v3.8.0/src/hd-wallet.js#L121-L146|blockchain.info]])
diff --git a/bip-0050.mediawiki b/bip-0050.mediawiki
index 4f48fca..fbc1c0f 100644
--- a/bip-0050.mediawiki
+++ b/bip-0050.mediawiki
@@ -41,7 +41,7 @@ This would be an issue even if the entire network was running version 0.7.2. It
 ===Immediately===
 
 '''Done''': Release a version 0.8.1, forked directly from 0.8.0, that, for the next two months has the following new rules:
-# Reject blocks that would probably could cause more than 10,000 locks to be taken.
+# Reject blocks that would probably cause more than 10,000 locks to be taken.
 # Limit the maximum block-size created to 500,000 bytes
 # Release a patch for older versions that implements the same rules, but also increases the maximum number of locks to 537,000
 # Create a web page on bitcoin.org that will urge users to upgrade to 0.8.1, but will tell them how to set DB_CONFIG to 537,000 locks if they absolutely cannot.
diff --git a/bip-0068.mediawiki b/bip-0068.mediawiki
index 0303924..923441e 100644
--- a/bip-0068.mediawiki
+++ b/bip-0068.mediawiki
@@ -5,7 +5,7 @@
           BtcDrak <btcdrak@gmail.com>
           Nicolas Dorier <nicolas.dorier@gmail.com>
           kinoshitajona <kinoshitajona@gmail.com>
-  Status: Draft
+  Status: Final
   Type: Standards Track
   Created: 2015-05-28
 </pre>
diff --git a/bip-0112.mediawiki b/bip-0112.mediawiki
index e19e0e9..0397332 100644
--- a/bip-0112.mediawiki
+++ b/bip-0112.mediawiki
@@ -4,7 +4,7 @@
   Author: BtcDrak <btcdrak@gmail.com>
           Mark Friedenbach <mark@friedenbach.org>
           Eric Lombrozo <elombrozo@gmail.com>
-  Status: Draft
+  Status: Final
   Type: Standards Track
   Created: 2015-08-10
 </pre>
diff --git a/bip-0113.mediawiki b/bip-0113.mediawiki
index 8290c13..1c402aa 100644
--- a/bip-0113.mediawiki
+++ b/bip-0113.mediawiki
@@ -3,7 +3,7 @@
   Title: Median time-past as endpoint for lock-time calculations
   Author: Thomas Kerin <me@thomaskerin.io>
           Mark Friedenbach <mark@friedenbach.org>
-  Status: Draft
+  Status: Final
   Type: Standards Track
   Created: 2015-08-10
 </pre>
diff --git a/bip-0126.mediawiki b/bip-0126.mediawiki
new file mode 100644
index 0000000..eed0c3e
--- /dev/null
+++ b/bip-0126.mediawiki
@@ -0,0 +1,98 @@
+<pre>
+  BIP: 126
+  Title: Best Practices for Heterogeneous Input Script Transactions
+  Author: Kristov Atlas <kristov@openbitcoinprivacyproject.org>
+  Status: Draft
+  Type: Informational
+  Created: 2016-02-10
+</pre>
+
+==Abstract==
+
+When a Bitcoin transaction contains inputs that reference previous transaction outputs sent to different Bitcoin addresses, personally identifiable information of the user will leak into the blockchain in an uncontrolled manner. While undesirable, these transactions are frequently unavoidable due to the natural fragmentation of wallet balances over time.
+
+This document proposes a set of best practice guidelines which minimize the uncontrolled disclosure of personally identifiable information by defining standard forms for transactions containing heterogenous input scripts.
+
+==Copyright==
+
+This BIP is in the public domain.
+
+==Definitions==
+
+* '''Heterogenous input script transaction (HIT)''': A transaction containing multiple inputs where the scripts of the previous transaction outputs being consumed are not identical (e.g. a transaction spending outputs which were sent to more than one Bitcoin address)
+* '''Unavoidable heterogenous input script transaction''': A HIT created as a result of a user’s desire to create a new output with a value larger than the value of his wallet's largest existing unspent output
+* '''Intentional heterogenous input script transaction''': A HIT created as part of a user protection protocol for reducing uncontrolled disclosure of personally-identifying information (PII)
+
+Throughout this procedure, when input scripts are evaluated for uniqueness, "input script" should be interpreted to mean, "the script of the previous output referenced by an input to a transaction".
+
+==Motivations==
+
+The recommendations in this document are designed to accomplish three goals:
+
+# Maximise the effectiveness of user-protecting protocols: Users may find that protection protocols are counterproductive if such transactions have a distinctive fingerprint which renders them ineffective.
+# Minimise the adverse consequences of unavoidable heterogenous input transactions: If unavoidable HITs are indistinguishable from intentional HITs, a user creating an unavoidable HIT benefits from ambiguity with respect to graph analysis.
+# Limiting the effect on UTXO set growth: To date, non-standardized intentional HITs tend to increase the network's UTXO set with each transaction; this standard attempts to minimize this effect by standardizing unavoidable and intentional HITs to limit UTXO set growth.
+
+In order to achieve these goals, this specification proposes a set of best practices for heterogenous input script transaction creation. These practices accommodate all applicable requirements of both intentional and unavoidable HITs while maximising the effectiveness of both in terms of preventing uncontrolled disclosure of PII.
+
+In order to achieve this, two forms of HIT are proposed: Standard form and alternate form.
+
+==Standard form heterogenous input script transaction==
+
+===Rules===
+
+A HIT is Standard form if it adheres to all of the following rules:
+
+# The number of unique output scripts must be equal to the number of unique inputs scripts (irrespective of the number of inputs and outputs).
+# All output scripts must be unique.
+# At least one pair of outputs must be of equal value.
+# The largest output in the transaction is a member of a set containing at least two identically-sized outputs.
+
+===Rationale===
+
+The requirement for equal numbers of unique input/output scripts instead of equal number of inputs/outputs accommodates user-protecting UTXO selection behavior. Wallets may contain spendable outputs with identical scripts due to intentional or accidental address reuse, or due to dusting attacks. In order to minimise the adverse consequences of address reuse, any time a UTXO is included in a transaction as an input, all UTXOs with the same spending script should also be included in the transaction.
+
+The requirement that all output scripts are unique prevents address reuse. Restricting the number of outputs to the number of unique input scripts prevents this policy from growing the network’s UTXO set. A standard form HIT transaction will always have a number of inputs greater than or equal to the number of outputs.
+
+The requirement for at least one pair of outputs in an intentional HIT to be of equal value results in optimal behavior, and causes intentional HITs to resemble unavoidable HITs.
+
+==Alternate form heterogenous input script transactions==
+
+The formation of a standard form HIT is not possible in the following cases:
+
+# The HIT is unavoidable, and the user’s wallet contains an insufficient number or size of UTXOs to create a standard form HIT.
+# The user wishes to reduce the number of utxos in their wallet, and does not have any sets of utxos with identical scripts.
+
+When one of the following cases exist, a compliant implementation may create an alternate form HIT by constructing a transaction as follows:
+
+===Procedure===
+
+# Find the smallest combination of inputs whose value is at least the value of the desired spend.
+## Add these inputs to the transaction.
+## Add a spend output to the transaction.
+## Add a change output to the transaction containing the difference between the current set of inputs and the desired spend.
+# Repeat step 1 to create a second pair of outputs, where one output has the same value as the spend output of the previous step.
+# (optional) Repeat step 2 until the desired number of inputs have been consumed and/or the desired number outputs have been created.
+# Adjust the change outputs as necessary to pay the desired transaction fee.
+
+Clients which create intentional HITs must have the capability to form alternate form HITs, and must do so for a non-zero fraction of the transactions they create.
+
+===Rules===
+
+An HIT formed via the preceding procedure will adhere to the following conditions:
+
+# The number of unique inputs scripts must exceed the number of output scripts.
+# All output scripts must be unique.
+# At least one pair of outputs must be of equal value.
+## "Standard outputs" refers to the set of outputs with equal value
+## "Standard value" refers to the value of the standard outputs
+## "Change outputs" refers to all outputs which are not standard outputs
+# For a HIT containing n standard outputs, there must exist at least one possible way to organize the inputs and outputs into n sets, where all sets satisfy the following:
+## The set contains one or more inputs, exactly one standard output, and exactly one change output
+## An input or output that appears in one set must not appear in any other set
+## The sum of the inputs in the set minus the value of the change output is equal to the standard value with a tolerance equal to the transaction fee.
+## Change outputs with a value of zero (virtual change outputs) are permitted. The are defined for the purpose of testing whether or not a HIT adheres to this specification but are not present in the version of the transaction which is broadcast to the network.
+
+==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.
diff --git a/bip-0141.mediawiki b/bip-0141.mediawiki
index ed025ac..ccf18b6 100644
--- a/bip-0141.mediawiki
+++ b/bip-0141.mediawiki
@@ -48,7 +48,7 @@ A new <code>wtxid</code> is defined: the double SHA256 of the new serialization
   
 Format of <code>nVersion</code>, <code>txins</code>, <code>txouts</code>, and <code>nLockTime</code> are same as traditional serialization.
 
-The <code>marker</code> MUST be <code>0x00</code>.
+The <code>marker</code> MUST be a 1-byte zero value: <code>0x00</code>.
 
 The <code>flag</code> MUST be a 1-byte non-zero value. Currently, <code>0x01</code> MUST be used.
 
@@ -98,9 +98,9 @@ If the version byte is 0, and the witness program is 32 bytes:
 * The <code>witnessScript</code> is deserialized, and executed after normal script evaluation with the remaining witness stack (≤ 520 bytes for each stack item).
 * The script must not fail, and result in exactly a single TRUE on the stack.
 
-If the version byte is 0, but the witness program is neither 20 nor 32 bytes, the script must fail.
+If the version byte is 0, but the witness program is neither 20 nor 32 bytes, the script must fail.<ref>For example, a scriptPubKey with OP_0 followed by a 40-byte non-zero data push will fail due to incorrect program size. However, a scriptPubKey with OP_0 followed by a 41-byte non-zero data push will pass, since it is not considered to be a witness program</ref>
 
-If the version byte is 1 to 16, no further interpretation of the witness program or witness happens, and there is no size restriction for the witness. These versions are reserved for future extensions.
+If the version byte is 1 to 16, no further interpretation of the witness program or witness stack happens, and there is no size restriction for the witness stack. These versions are reserved for future extensions.<ref>For backward compatibility, for any version byte from 0 to 16, the script must fail if the witness program has a <code>CastToBool</code> value of zero. However, having a hash like this is a successful preimage attack against the hash function, and the risk is negligible.</ref>
 
 === Other consensus critical limits ===
 
@@ -108,13 +108,13 @@ If the version byte is 1 to 16, no further interpretation of the witness program
 
 Blocks are currently limited to 1,000,000 bytes (1MB) total size. We change this restriction as follows:
 
-''Block cost'' is defined as ''Base size'' * 3 + ''Total size''. (rationale<ref>Rationale of using a single composite constraint, instead of two separate limits such as 1MB base data and 3MB witness data: Using two separate limits would make mining and fee estimation nearly impossible. Miners would need to solve a complex non-linear optimization problem to find the set of transactions that maximize fees given both constraints, and wallets would not be able to know what to pay as it depends on which of the two conditions is most constrained by the time miners try to produce blocks with their transactions in. Another problem with such an approach is freeloading. Once a set of transactions hit the base data 1MB constraint, up to 3MB extra data could be added to the witness by just minimally increasing the fee. The marginal cost for extra witness space effectively becomes zero in that case.</ref>)
+''Block weight'' is defined as ''Base size'' * 3 + ''Total size''. (rationale<ref>Rationale of using a single composite constraint, instead of two separate limits such as 1MB base data and 3MB witness data: Using two separate limits would make mining and fee estimation nearly impossible. Miners would need to solve a complex non-linear optimization problem to find the set of transactions that maximize fees given both constraints, and wallets would not be able to know what to pay as it depends on which of the two conditions is most constrained by the time miners try to produce blocks with their transactions in. Another problem with such an approach is freeloading. Once a set of transactions hit the base data 1MB constraint, up to 3MB extra data could be added to the witness by just minimally increasing the fee. The marginal cost for extra witness space effectively becomes zero in that case.</ref>)
 
 ''Base size'' is the block size in bytes with the original transaction serialization without any witness-related data, as seen by a non-upgraded node.
 
 ''Total size'' is the block size in bytes with transactions serialized as described in [[bip-0144.mediawiki|BIP144]], including base data and witness data.
 
-The new rule is ''block cost'' ≤ 4,000,000.
+The new rule is ''block weight'' ≤ 4,000,000.
 
 ==== Sigops ====
 
@@ -123,14 +123,13 @@ Sigops per block is currently limited to 20,000. We change this restriction as f
 Sigops in the current pubkey script, signature script, and P2SH check script are counted at 4 times their previous value.
 The sigop limit is likewise quadrupled to ≤ 80,000.
 
-In addition, opcodes within the witness program are counted identical to as previously within the P2SH check script.
-That is, CHECKSIG in a witness program is counted as only 1 sigop, and CHECKMULTISIG in a witness program is counted as 1 to 20 sigops according to the arguments. This rule applies to both native witness program and P2SH witness program.
+Each P2WPKH input is counted as 1 sigop. In addition, opcodes within a P2WSH <code>witnessScript</code> are counted identically as previously within the P2SH <code>redeemScript</code>. 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.
 
 == Examples ==
 
-=== P2WPKH witness program ===
+=== P2WPKH ===
 
-The following example is a version 0 pay-to-witness-public-key-hash (P2WPKH) witness program:
+The following example is a version 0 pay-to-witness-public-key-hash (P2WPKH):
 
     witness:      <signature> <pubkey>
     scriptSig:    (empty)
@@ -147,7 +146,7 @@ Comparing with a traditional P2PKH output, the P2WPKH equivalent occupies 3 less
 
 === P2WPKH nested in BIP16 P2SH ===
 
-The following example is the same P2WPKH witness program, but nested in a BIP16 P2SH output.
+The following example is the same P2WPKH, but nested in a BIP16 P2SH output.
 
     witness:      <signature> <pubkey>
     scriptSig:    <0 <20-byte-key-hash>>
@@ -159,13 +158,13 @@ The only item in scriptSig is hashed with HASH160, compared against the 20-byte-
 
     0 <20-byte-key-hash>
 
-The P2WPKH witness program is then executed as described in the previous example.
+The public key and signature are then verified as described in the previous example.
 
 Comparing with the previous example, the scriptPubKey is 1 byte bigger and the scriptSig is 23 bytes bigger. Although a nested witness program is less efficient, its payment address is fully transparent and backward compatible for all Bitcoin reference client since version 0.6.0.
 
-=== P2WSH witness program ===
+=== P2WSH ===
 
-The following example is an 1-of-2 multi-signature version 0 pay-to-witness-script-hash (P2WSH) witness program.
+The following example is an 1-of-2 multi-signature version 0 pay-to-witness-script-hash (P2WSH).
 
     witness:      0 <signature1> <1 <pubkey1> <pubkey2> 2 CHECKMULTISIG>
     scriptSig:    (empty)
@@ -180,13 +179,13 @@ The script is executed with the remaining data from witness:
 
     0 <signature1> 1 <pubkey1> <pubkey2> 2 CHECKMULTISIG
 
-A P2WSH witness program allows arbitrarily large script as the 520-byte push limit is bypassed.
+P2WSH allows maximum script size of 10,000 bytes, as the 520-byte push limit is bypassed.
 
 The scriptPubKey occupies 34 bytes, as opposed to 23 bytes of BIP16 P2SH. The increased size improves security against possible collision attacks, as 2<sup>80</sup> work is not infeasible anymore (By the end of 2015, 2<sup>84</sup> hashes have been calculated in Bitcoin mining since the creation of Bitcoin). The spending script is same as the one for an equivalent BIP16 P2SH output but is moved to witness.
 
 === P2WSH nested in BIP16 P2SH ===
 
-The following example is the same 1-of-2 multi-signature P2WSH witness program, but nested in a BIP16 P2SH output.
+The following example is the same 1-of-2 multi-signature P2WSH script, but nested in a BIP16 P2SH output.
 
     witness:      0 <signature1> <1 <pubkey1> <pubkey2> 2 CHECKMULTISIG>
     scriptSig:    <0 <32-byte-hash>>
@@ -198,7 +197,7 @@ The only item in scriptSig is hashed with HASH160, compared against the 20-byte-
 
     0 <32-byte-hash>
 
-The P2WSH witness program is then executed as described in the previous example.
+The P2WSH witnessScript is then executed as described in the previous example.
 
 Comparing with the previous example, the scriptPubKey is 11 bytes smaller (with reduced security) while witness is the same. However, it also requires 35 bytes in scriptSig.
 
@@ -249,8 +248,6 @@ Since a version byte is pushed before a witness program, and programs with unkno
 
 Examples of new script system include Schnorr signatures which reduce the size of multisig transactions dramatically, Lamport signature which is quantum computing resistance, and Merklized abstract syntax trees which allow very compact witness for conditional scripts with extreme complexity.
 
-The 32-byte limitation for witness program could be easily extended through a soft fork in case a stronger hash function is needed in the future. The version byte is also expandable through a softfork.
-
 === Per-input lock-time and relative-lock-time ===
 
 Currently there is only one nLockTime field in a transaction and all inputs must share the same value. [https://github.com/bitcoin/bips/blob/master/bip-0068.mediawiki BIP68] enables per-input relative-lock-time using the nSequence field, however, with a limited lock-time period and resolution.
@@ -290,7 +287,7 @@ Special thanks to Gregory Maxwell for originating many of the ideas in this BIP
 
 == Reference Implementation ==
 
-https://github.com/bitcoin/bitcoin/pull/7910
+https://github.com/bitcoin/bitcoin/pull/8149
 
 == References ==
 
diff --git a/bip-0145.mediawiki b/bip-0145.mediawiki
index b04c9e6..cac838d 100644
--- a/bip-0145.mediawiki
+++ b/bip-0145.mediawiki
@@ -22,7 +22,7 @@ The template Object is revised to include a new key:
 |-
 ! Key !! Required !! Type !! Description
 |-
-| costlimit || No || Number || total cost allowed in blocks
+| weightlimit || No || Number || total weight allowed in blocks
 |}
 
 The '!' rule prefix MUST be enabled on the "segwit" rule for templates including transactions with witness data.
@@ -40,7 +40,7 @@ The Objects listed in the response's "transactions" key is revised to include th
 |-
 | txid || String || transaction id encoded in hexadecimal; required for transactions with witness data
 |-
-| cost || Number || numeric cost of the transaction, as counted for purposes of the block's costlimit; if key is not present, cost is unknown and clients MUST NOT assume it is zero, although they MAY choose to calculate it themselves
+| weight || Number || numeric weight of the transaction, as counted for purposes of the block's weightlimit; if key is not present, weight is unknown and clients MUST NOT assume it is zero, although they MAY choose to calculate it themselves
 |-
 | hash || String || reversed hash of complete transaction (with witness data included) encoded in hexadecimal
 |}
@@ -66,12 +66,12 @@ It additionally also adds a new way of counting resource limits, and so GBT must
 
 ==Rationale==
 
-Why doesn't "costlimit" simply redefine the existing "sizelimit"?
+Why doesn't "weightlimit" simply redefine the existing "sizelimit"?
 * "sizelimit" is already enforced by clients by counting the sum of bytes in transactions' "data" keys.
-* Servers may wish to limit the overall size of a block, independently from the "cost" of the block.
+* Servers may wish to limit the overall size of a block, independently from the "weight" of the block.
 
-Why is "sigoplimit" redefined instead of a new "sigopcostlimit" being added?
-* The old limit was already arbitrarily defined, and could not be counted by clients on their own anyway. The concept of "sigop cost" is merely a change in the arbitrary formula used.
+Why is "sigoplimit" redefined instead of a new "sigopweightlimit" being added?
+* The old limit was already arbitrarily defined, and could not be counted by clients on their own anyway. The concept of "sigop weight" is merely a change in the arbitrary formula used.
 
 Why is "sigoplimit" divided by 4?
 * To resemble the previous values. (FIXME: is this a good reason? maybe we shouldn't divide it?)
diff --git a/bip-0151.mediawiki b/bip-0151.mediawiki
index 18d3901..a4c8b8e 100644
--- a/bip-0151.mediawiki
+++ b/bip-0151.mediawiki
@@ -36,17 +36,22 @@ Encryption initialization must happen before sending any other messages to the r
 
 === Symmetric Encryption Cipher Keys ===
 
-The symmetric encryption cipher keys will be calculated with ECDH by sharing the pubkeys of a ephemeral key. Once the ECDH secret is calculated on each side, the symmetric encryption cipher keys must be calculated with <code>HMAC_SHA512(key=ecdh_secret|cipher-type,msg="encryption key")</code>.
+The symmetric encryption cipher keys will be calculated with ECDH/HKDF by sharing the pubkeys of a ephemeral key. Once the ECDH secret is calculated on each side, the symmetric encryption cipher keys must be derived with HKDF [2] after the following specification:
 
-<code>K_1</code> must be the left 32bytes of the <code>HMAC_SHA512</code> hash.
+1. HKDF extraction
+<code>PRK = HKDF_EXTRACT(hash=SHA256, salt="bitcoinechd", ikm=ecdh_secret|cipher-type)</code>.
 
-<code>K_2</code> must be the right 32bytes of the <code>HMAC_SHA512</code> hash.
+2. Derive Key1
+<code>K_1 = HKDF_EXPAND(prk=PRK, hash=SHA256, info="BitcoinK1", L=32)</code>
 
-It is important to include the cipher-type into the symmetric cipher key to avoid weak-cipher-attacks.
+3. Derive Key2
+<code>K_2 = HKDF_EXPAND(prk=PRK, hash=SHA256, info="BitcoinK2", L=32)</code>
+
+It is important to include the cipher-type into the symmetric cipher key derivation to avoid weak-cipher-attacks.
 
 === Session ID ===
 
-Both sides must also calculate the 256bit session-id using <code>HMAC_SHA256(key=ecdh_secret,msg="session id")</code>. The session-id can be used for linking the encryption-session to an identity check.
+Both sides must also calculate the 256bit session-id using <code>SID = HKDF_EXPAND(prk=PRK, hash=SHA256, info="BitcoinSessionID", L=32)</code>. The session-id can be used for linking the encryption-session to an identity check.
 
 === The <code>encinit</code> message type ===
 
@@ -69,19 +74,19 @@ Possible symmetric key ciphers types
 
 === ChaCha20-Poly1305 Cipher Suite ===
 
-ChaCha20 is a stream cipher designed by Daniel Bernstein [2]. It operates by permuting 128 fixed bits, 128 or 256 bits of key,
+ChaCha20 is a stream cipher designed by Daniel Bernstein [3]. It operates by permuting 128 fixed bits, 128 or 256 bits of key,
 a 64 bit nonce and a 64 bit counter into 64 bytes of output. This output is used as a keystream, with any unused bytes simply discarded.
 
-Poly1305, also by Daniel Bernstein [3], is a one-time Carter-Wegman MAC that computes a 128 bit integrity tag given a message and a single-use
+Poly1305, also by Daniel Bernstein [4], is a one-time Carter-Wegman MAC that computes a 128 bit integrity tag given a message and a single-use
 256 bit secret key.
 
-The chacha20-poly1305@openssh.com specified and defined by openssh [4] combines these two primitives into an authenticated encryption mode. The construction used is based on that proposed for TLS by Adam Langley [5], but differs in the layout of data passed to the MAC and in the addition of encyption of the packet lengths.
+The chacha20-poly1305@openssh.com specified and defined by openssh [5] combines these two primitives into an authenticated encryption mode. The construction used is based on that proposed for TLS by Adam Langley [6], but differs in the layout of data passed to the MAC and in the addition of encyption of the packet lengths.
 
 <code>K_1</code> must be used to only encrypt the payload size of the encrypted message to avoid leaking information by revealing the message size.
 
 <code>K_2</code> must be used in conjunction with poly1305 to build an AEAD.
 
-Optimized implementations of ChaCha20-Poly1305 are very fast in general, therefore it is very likely that encrypted messages require less CPU cycles per bytes then the current unencrypted p2p message format. A quick analysis by Pieter Wuille of the current ''standard implementations'' has shown that SHA256 requires more CPU cycles per byte then ChaCha20 & Poly1304 [5].
+Optimized implementations of ChaCha20-Poly1305 are very fast in general, therefore it is very likely that encrypted messages require less CPU cycles per bytes then the current unencrypted p2p message format. A quick analysis by Pieter Wuille of the current ''standard implementations'' has shown that SHA256 requires more CPU cycles per byte then ChaCha20 & Poly1304.
 
 === The <code>encack</code> message type ===
 
@@ -123,7 +128,7 @@ Processing the message before the authentication succeeds must not be done.
 
 The 4byte sha256 checksum is no longer required because the AEAD.
 
-Both peers need to track the message number (int64) of sent messages to the remote peer for building a symmetric cipher IV. Padding might be required (96bit IVs).
+Both peers need to track the message sequence number (uint32) of sent messages to the remote peer for building a 64 bit symmetric cipher IV. Sequence numbers are allowed to overflow to zero after 4294967295 (2^32-1).
 
 The encrypted payload will result decrypted in one or many unencrypted messages:
 
@@ -151,7 +156,7 @@ The Re-Keying must be done after every 1GB of data sent or received (recommended
 
 === Risks ===
 
-The encryption does not include an identity authentication scheme. This BIP does not cover a proposal to avoid MITM attacks during the encryption initialization. 
+The encryption does not include an identity authentication scheme. This BIP does not cover a proposal to avoid MITM attacks during the encryption initialization.
 
 Identity authentication will be covered in another BIP and will presume communication encryption after this BIP.
 
@@ -164,10 +169,11 @@ This proposal is backward compatible. Non-supporting peers will ignore the <code
 == References ==
 
 * [1] http://e-collection.library.ethz.ch/eserv/eth:48205/eth-48205-01.pdf
-* [2] ChaCha20 http://cr.yp.to/chacha/chacha-20080128.pdf
-* [3] Poly1305 http://cr.yp.to/mac/poly1305-20050329.pdf
-* [4] https://github.com/openssh/openssh-portable/blob/05855bf2ce7d5cd0a6db18bc0b4214ed5ef7516d/PROTOCOL.chacha20poly1305
-* [5] "ChaCha20 and Poly1305 based Cipher Suites for TLS", Adam Langley http://tools.ietf.org/html/draft-agl-tls-chacha20poly1305-03
+* [2] HKDF (RFC 5869) https://tools.ietf.org/html/rfc5869
+* [3] ChaCha20 http://cr.yp.to/chacha/chacha-20080128.pdf
+* [4] Poly1305 http://cr.yp.to/mac/poly1305-20050329.pdf
+* [5] https://github.com/openssh/openssh-portable/blob/05855bf2ce7d5cd0a6db18bc0b4214ed5ef7516d/PROTOCOL.chacha20poly1305
+* [6] "ChaCha20 and Poly1305 based Cipher Suites for TLS", Adam Langley http://tools.ietf.org/html/draft-agl-tls-chacha20poly1305-03
 
 == Acknowledgements ==
 * Pieter Wuille and Gregory Maxwell for most of the ideas in this BIP.