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.

Author: Matt David

bip-0009.mediawiki

@@ -109,7 +109,7 @@ referred to as MTP in the diagram above, and is treated as a monotonic clock def
 
 After a period in the STARTED state, if we're past the timeout, we switch to FAILED. If not, we tally the bits set,
 and transition to LOCKED_IN if a sufficient number of blocks in the past period set the deployment bit in their
-version numbers. The threshold is 1915 blocks (95% of 2016), or 1512 for testnet (75% of 2016).
+version numbers. The threshold is ≥1916 blocks (95% of 2016), or ≥1512 for testnet (75% of 2016).
 The transition to FAILED takes precendence, as otherwise an ambiguity can arise.
 There could be two non-overlapping deployments on the same bit, where the first one transitions to LOCKED_IN while the
 other one simultaneously transitions to STARTED, which would mean both would demand setting the bit.
@@ -202,7 +202,7 @@ A client that does not understand a rule prefixed by '!' must not attempt to pro
 The mechanism described above is very generic, and variations are possible for future soft forks. Here are some ideas that can be taken into account.
 
 '''Modified thresholds'''
-The 1915 threshold (based on in BIP 34's 95%) does not have to be maintained for eternity, but changes should take the effect on the warning system into account. In particular, having a lock-in threshold that is incompatible with the one used for the warning system may have long-term effects, as the warning system cannot rely on a permanently detectable condition anymore.
+The 1916 threshold (based on in BIP 34's 95%) does not have to be maintained for eternity, but changes should take the effect on the warning system into account. In particular, having a lock-in threshold that is incompatible with the one used for the warning system may have long-term effects, as the warning system cannot rely on a permanently detectable condition anymore.
 
 '''Conflicting soft forks'''
 At some point, two mutually exclusive soft forks may be proposed. The naive way to deal with this is to never create software that implements both, but that is making a bet that at least one side is guaranteed to lose. Better would be to encode "soft fork X cannot be locked-in" as consensus rule for the conflicting soft fork - allowing software that supports both, but can never trigger conflicting changes.

bip-0039.mediawiki

@@ -139,4 +139,4 @@ Haskell - https://github.com/haskoin/haskoin
 
 .NET C# (PCL) - https://github.com/NicolasDorier/NBitcoin
 
-JavaScript - https://github.com/bitpay/bitcore-mnemonic
+JavaScript - https://github.com/bitpay/bitcore-mnemonic, https://github.com/bitcoinjs/bip39

bip-0068.mediawiki

@@ -49,6 +49,8 @@ The block produced time is equal to the median-time-past of its previous block.
 
 When the relative lock-time is block-based, it is interpreted as a minimum block-height constraint over the input's age. A relative block-based lock-time of zero indicates an input which can be included in any block. More generally, a relative block lock-time n can be included n blocks after the mining date of the output it is spending, or any block thereafter.
 
+The new rules are not applied to the nSequence field of the input of the coinbase transaction.
+
 ==Implementation==
 
 A reference implementation is provided by the following pull request

bip-0112.mediawiki

@@ -138,10 +138,10 @@ A simple output, paying to Alice might then look like:
 
     HASH160 <revokehash> EQUAL
     IF
-        <Bob key hash>
+        <Bob's pubkey>
     ELSE
         "24h" CHECKSEQUENCEVERIFY DROP
-        <Alice key hash>
+        <Alice's pubkey>
     ENDIF
     CHECKSIG
 
@@ -153,10 +153,10 @@ With CHECKLOCKTIMEVERIFY, this would look like:
 
     HASH160 <revokehash> EQUAL
     IF
-        <Bob key hash>
+        <Bob's pubkey>
     ELSE
         "2015/12/15" CHECKLOCKTIMEVERIFY DROP
-        <Alice key hash>
+        <Alice's pubkey>
     ENDIF
     CHECKSIG
 
@@ -181,13 +181,13 @@ Alice might look like the following in Alice's commitment transaction:
     IF
         "24h" CHECKSEQUENCEVERIFY
         2DROP
-        <Alice key hash>
+        <Alice's pubkey>
     ELSE
         <Commit-Revocation-Hash> EQUAL
         NOTIF
             "2015/10/20 10:33" CHECKLOCKTIMEVERIFY DROP
         ENDIF
-        <Bob key hash>
+        <Bob's pubkey>
     ENDIF
     CHECKSIG
 
@@ -196,12 +196,12 @@ and correspondingly in Bob's commitment transaction:
    HASH160 DUP <R-HASH> EQUAL
    SWAP <Commit-Revocation-Hash> EQUAL ADD
    IF
-       <Alice key hash>
+       <Alice's pubkey>
    ELSE
        "2015/10/20 10:33" CHECKLOCKTIMEVERIFY
        "24h" CHECKSEQUENCEVERIFY
        2DROP
-       <Bob key hash>
+       <Bob's pubkey>
    ENDIF
    CHECKSIG
 

bip-0113.mediawiki

@@ -64,6 +64,8 @@ This method takes the block time as one parameter. This BIP proposes
 that after activation calls to IsFinalTx() within consensus code use
 the return value of `GetMedianTimePast(pindexPrev)` instead.
 
+The new rule applies to all transactions, including the coinbase transaction.
+
 A reference implementation of this proposal is provided by the
 following pull request:
 

bip-0114.mediawiki

@@ -96,20 +96,20 @@ The following is the "Hashed TIme-Lock Contract" example in [[bip-0112.mediawiki
     IF
         "24h" CHECKSEQUENCEVERIFY
         2DROP
-        <Alice key hash>
+        <Alice's pubkey>
     ELSE
         <Commit-Revocation-Hash> EQUAL
         NOTIF
             "Timestamp" CHECKLOCKTIMEVERIFY DROP
         ENDIF
-        <Bob key hash>
+        <Bob's pubkey>
     ENDIF
     CHECKSIG
 
 To create a MAST Root, it is flattened to 3 mutually exclusive branches:
-    HASH160 <R-HASH> EQUALVERIFY "24h" CHECKSEQUENCEVERIFY DROP <Alice key hash> CHECKSIG
-    HASH160 <Commit-Revocation-Hash> EQUALVERIFY <Bob key hash> CHECKSIG
-    "Timestamp" CHECKLOCKTIMEVERIFY DROP <Bob key hash> CHECKSIG
+    HASH160 <R-HASH> EQUALVERIFY "24h" CHECKSEQUENCEVERIFY DROP <Alice's pubkey> CHECKSIG
+    HASH160 <Commit-Revocation-Hash> EQUALVERIFY <Bob's pubkey> CHECKSIG
+    "Timestamp" CHECKLOCKTIMEVERIFY DROP <Bob's pubkey> CHECKSIG
 
 which significantly improves readability and reduces the witness size when it is redeemed.
 

bip-0143.mediawiki

@@ -47,8 +47,8 @@ The items 1, 4, 7, 9, 10 have the same meaning as the original algorithm. <ref n
 The item 5:
 *For P2WPKH witness program, the scriptCode is <code>0x1976a914{20-byte-pubkey-hash}88ac</code>.
 *For P2WSH witness program,
-**if the <code>witnessScript</code> does not contain any <code>OP_CODESEPERATOR</code>, the <code>scriptCode</code> is the <code>witnessScript</code> serialized as scripts inside CTxOuts.
-**if the <code>witnessScript</code> contains any <code>OP_CODESEPERATOR</code>, the <code>scriptCode</code> is the evaluated script, with everything up to and including the last executed <code>OP_CODESEPARATOR</code> before the signature checking opcode being executed removed, serialized as scripts inside CTxOuts.
+**if the <code>witnessScript</code> does not contain any <code>OP_CODESEPARATOR</code>, the <code>scriptCode</code> is the <code>witnessScript</code> serialized as scripts inside CTxOuts.
+**if the <code>witnessScript</code> contains any <code>OP_CODESEPARATOR</code>, the <code>scriptCode</code> is the evaluated script, with everything up to and including the last executed <code>OP_CODESEPARATOR</code> before the signature checking opcode being executed removed, serialized as scripts inside CTxOuts.
 
 The item 6 is a 8-byte value of the amount of bitcoin spent in this input.
 
@@ -139,7 +139,8 @@ Refer to the reference implementation, reproduced below, for the precise algorit
     nLockTime: 11000000
   
   The first input comes from an ordinary P2PK:
-    scriptPubKey: 2103c9f4836b9a4f77fc0d81f7bcb01b7f1b35916864b9476c241ce9fc198bd25432ac value: 6.25
+    scriptPubKey : 2103c9f4836b9a4f77fc0d81f7bcb01b7f1b35916864b9476c241ce9fc198bd25432ac value: 6.25
+    private key  : bbc27228ddcb9209d7fd6f36b02f7dfa6252af40bb2f1cbc7a557da8027ff866
     
   The second input comes from a P2WPKH witness program:
     scriptPubKey : 00141d0f172a0ecb48aee1be1f2687d2963ae33f71a1, value: 6
@@ -248,7 +249,7 @@ Refer to the reference implementation, reproduced below, for the precise algorit
 
 === Native P2WSH ===
 
-This example shows how OP_CODESEPERATOR and out-of-range SIGHASH_SINGLE are processed:
+This example shows how <code>OP_CODESEPARATOR</code> and out-of-range <code>SIGHASH_SINGLE</code> are processed:
 
 
 
@@ -264,6 +265,7 @@ This example shows how OP_CODESEPERATOR and out-of-range SIGHASH_SINGLE are proc
   The first input comes from an ordinary P2PK:
     scriptPubKey: 21036d5c20fa14fb2f635474c1dc4ef5909d4568e5569b79fc94d3448486e14685f8ac value: 1.5625
     private key:  b8f28a772fccbf9b4f58a4f027e07dc2e35e7cd80529975e292ea34f84c4580c
+    signature:    304402200af4e47c9b9629dbecc21f73af989bdaa911f7e6f6c2e9394588a3aa68f81e9902204f3fcf6ade7e5abb1295b6774c8e0abd94ae62217367096bc02ee5e435b67da201 (SIGHASH_ALL)
   
   The second input comes from a native P2WSH witness program:
     scriptPubKey : 00205d1b56b63d714eebe542309525f484b7e9d6f686b3781b6f61ef925d66d6f6a0, value: 49
@@ -289,25 +291,25 @@ This example shows how OP_CODESEPERATOR and out-of-range SIGHASH_SINGLE are proc
   
   scriptCode:  4721026dccc749adc2a9d0d89497ac511f760f45c47dc5ed9cf352a58ac706453880aeadab210255a9626aebf5e29c0e6538428ba0d1dcf6ca98ffdf086aa8ced5e0d0215ea465ac
                                                                                        ^^
-               (please note that the not-yet-exectued OP_CODESEPERATOR is not removed from the scriptCode)
+               (please note that the not-yet-exectued OP_CODESEPARATOR is not removed from the scriptCode)
   preimage:    01000000ef546acf4a020de3898d1b8956176bb507e6211b5ed3619cd08b6ea7e2a09d4100000000000000000000000000000000000000000000000000000000000000000815cf020f013ed6cf91d29f4202e8a58726b1ac6c79da47c23d1bee0a6925f8000000004721026dccc749adc2a9d0d89497ac511f760f45c47dc5ed9cf352a58ac706453880aeadab210255a9626aebf5e29c0e6538428ba0d1dcf6ca98ffdf086aa8ced5e0d0215ea465ac0011102401000000ffffffff00000000000000000000000000000000000000000000000000000000000000000000000003000000
   sigHash:     82dde6e4f1e94d02c2b7ad03d2115d691f48d064e9d52f58194a6637e4194391
   public key:  026dccc749adc2a9d0d89497ac511f760f45c47dc5ed9cf352a58ac706453880ae
   private key: 8e02b539b1500aa7c81cf3fed177448a546f19d2be416c0c61ff28e577d8d0cd
   signature:   3044022027dc95ad6b740fe5129e7e62a75dd00f291a2aeb1200b84b09d9e3789406b6c002201a9ecd315dd6a0e632ab20bbb98948bc0c6fb204f2c286963bb48517a7058e2703
   
   scriptCode:  23210255a9626aebf5e29c0e6538428ba0d1dcf6ca98ffdf086aa8ced5e0d0215ea465ac
-               (everything up to the last executed OP_CODESEPERATOR, including that OP_CODESEPERATOR, are removed)
+               (everything up to the last executed OP_CODESEPARATOR, including that OP_CODESEPARATOR, are removed)
   preimage:    01000000ef546acf4a020de3898d1b8956176bb507e6211b5ed3619cd08b6ea7e2a09d4100000000000000000000000000000000000000000000000000000000000000000815cf020f013ed6cf91d29f4202e8a58726b1ac6c79da47c23d1bee0a6925f80000000023210255a9626aebf5e29c0e6538428ba0d1dcf6ca98ffdf086aa8ced5e0d0215ea465ac0011102401000000ffffffff00000000000000000000000000000000000000000000000000000000000000000000000003000000
   sigHash:     fef7bd749cce710c5c052bd796df1af0d935e59cea63736268bcbe2d2134fc47
   public key:  0255a9626aebf5e29c0e6538428ba0d1dcf6ca98ffdf086aa8ced5e0d0215ea465
   private key: 86bf2ed75935a0cbef03b89d72034bb4c189d381037a5ac121a70016db8896ec
   signature:   304402200de66acf4527789bfda55fc5459e214fa6083f936b430a762c629656216805ac0220396f550692cd347171cbc1ef1f51e15282e837bb2b30860dc77c8f78bc8501e503
   
-  The serialized signed transaction is: 01000000000102fe3dc9208094f3ffd12645477b3dc56f60ec4fa8e6f5d67c565d1c6b9216b36e000000004847304402200af4e47c9b9629dbecc21f73af989bdaa911f7e6f6c2e9394588a3aa68f81e9902204f3fcf6ade7e5abb1295b6774c8e0abd94ae62217367096bc02ee5e435b67da201ffffffff0815cf020f013ed6cf91d29f4202e8a58726b1ac6c79da47c23d1bee0a6925f80000000000ffffffff0100f2052a010000001976a914a30741f8145e5acadf23f751864167f32e0963f788ac000347304402200de66acf4527789bfda55fc5459e214fa6083f936b430a762c629656216805ac0220396f550692cd347171cbc1ef1f51e15282e837bb2b30860dc77c8f78bc8501e503473044022027dc95ad6b740fe5129e7e62a75dd00f291a2aeb1200b84b09d9e3789406b6c002201a9ecd315dd6a0e632ab20bbb98948bc0c6fb204f2c286963bb48517a7058e27034721026dccc749adc2a9d0d89497ac511f760f45c47dc5ed9cf352a58ac706453880aeadab210255a9626aebf5e29c0e6538428ba0d1dcf6ca98ffdf086aa8ced5e0d0215ea465ac0000000047304402200de66acf4527789bfda55fc5459e214fa6083f936b430a762c629656216805ac0220396f550692cd347171cbc1ef1f51e15282e837bb2b30860dc77c8f78bc8501e503473044022027dc95ad6b740fe5129e7e62a75dd00f291a2aeb1200b84b09d9e3789406b6c002201a9ecd315dd6a0e632ab20bbb98948bc0c6fb204f2c286963bb48517a7058e27034721026dccc749adc2a9d0d89497ac511f760f45c47dc5ed9cf352a58ac706453880aeadab210255a9626aebf5e29c0e6538428ba0d1dcf6ca98ffdf086aa8ced5e0d0215ea465ac00000000
+  The serialized signed transaction is: 01000000000102fe3dc9208094f3ffd12645477b3dc56f60ec4fa8e6f5d67c565d1c6b9216b36e000000004847304402200af4e47c9b9629dbecc21f73af989bdaa911f7e6f6c2e9394588a3aa68f81e9902204f3fcf6ade7e5abb1295b6774c8e0abd94ae62217367096bc02ee5e435b67da201ffffffff0815cf020f013ed6cf91d29f4202e8a58726b1ac6c79da47c23d1bee0a6925f80000000000ffffffff0100f2052a010000001976a914a30741f8145e5acadf23f751864167f32e0963f788ac000347304402200de66acf4527789bfda55fc5459e214fa6083f936b430a762c629656216805ac0220396f550692cd347171cbc1ef1f51e15282e837bb2b30860dc77c8f78bc8501e503473044022027dc95ad6b740fe5129e7e62a75dd00f291a2aeb1200b84b09d9e3789406b6c002201a9ecd315dd6a0e632ab20bbb98948bc0c6fb204f2c286963bb48517a7058e27034721026dccc749adc2a9d0d89497ac511f760f45c47dc5ed9cf352a58ac706453880aeadab210255a9626aebf5e29c0e6538428ba0d1dcf6ca98ffdf086aa8ced5e0d0215ea465ac00000000
 
 
-This example shows how unexecuted OP_CODESEPERATOR is processed, and SINGLE|ANYONECANPAY does not commit to the input index:
+This example shows how unexecuted <code>OP_CODESEPARATOR</code> is processed, and <code>SINGLE|ANYONECANPAY</code> does not commit to the input index:
 
 
 
@@ -346,7 +348,7 @@ This example shows how unexecuted OP_CODESEPERATOR is processed, and SINGLE|ANYO
   
   outpoint:    e9b542c5176808107ff1df906f46bb1f2583b16112b95ee5380665ba7fcfc00100000000
   scriptCode:  270063ab68210392972e2eb617b2388771abe27235fd5ac44af8e61693261550447a4c3e39da98ac
-               (since the OP_CODESEPERATOR is not executed, nothing is removed from the scriptCode)
+               (since the OP_CODESEPARATOR is not executed, nothing is removed from the scriptCode)
   hashOutputs: b258eaf08c39fbe9fbac97c15c7e7adeb8df142b0df6f83e017f349c2b6fe3d2
   preimage:    0100000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000e9b542c5176808107ff1df906f46bb1f2583b16112b95ee5380665ba7fcfc00100000000270063ab68210392972e2eb617b2388771abe27235fd5ac44af8e61693261550447a4c3e39da98acffffff0000000000ffffffffb258eaf08c39fbe9fbac97c15c7e7adeb8df142b0df6f83e017f349c2b6fe3d20000000083000000
   sigHash:     e9071e75e25b8a1e298a72f0d2e9f4f95a0f5cdf86a533cda597eb402ed13b3a
@@ -356,7 +358,7 @@ This example shows how unexecuted OP_CODESEPERATOR is processed, and SINGLE|ANYO
   
   outpoint:    80e68831516392fcd100d186b3c2c7b95c80b53c77e77c35ba03a66b429a2a1b00000000
   scriptCode:  2468210392972e2eb617b2388771abe27235fd5ac44af8e61693261550447a4c3e39da98ac
-               (everything up to the last executed OP_CODESEPERATOR, including that OP_CODESEPERATOR, are removed)
+               (everything up to the last executed OP_CODESEPARATOR, including that OP_CODESEPARATOR, are removed)
   hashOutputs: 91ea93dd77f702b738ebdbf3048940a98310e869a7bb8fa2c6cb3312916947ca
   preimage:    010000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000080e68831516392fcd100d186b3c2c7b95c80b53c77e77c35ba03a66b429a2a1b000000002468210392972e2eb617b2388771abe27235fd5ac44af8e61693261550447a4c3e39da98acffffff0000000000ffffffff91ea93dd77f702b738ebdbf3048940a98310e869a7bb8fa2c6cb3312916947ca0000000083000000
   sigHash:     cd72f1f1a433ee9df816857fad88d8ebd97e09a75cd481583eb841c330275e54
@@ -392,7 +394,7 @@ This example shows how unexecuted OP_CODESEPERATOR is processed, and SINGLE|ANYO
 
 === P2SH-P2WSH ===
 
-This example is a P2SH-P2WSH 6-of-6 multisig witness program signed with 6 different SIGHASH types.
+This example is a P2SH-P2WSH 6-of-6 multisig witness program signed with 6 different <code>SIGHASH</code> types.
 
 
 
@@ -418,7 +420,7 @@ This example is a P2SH-P2WSH 6-of-6 multisig witness program signed with 6 diffe
   = 3bb13029ce7b1f559ef5e747fcac439f1455a2ec7c5f09b72290795e70665044
   
   hashOutputs for ALL:
-  dSHA256(00e9a435000000001976a914389ffce9cd9ae88dcc0631e88a821ffdbe9bfe2688acc0832f05000000001976a9147480a33f950689af511e6e84c138dbbd3c3ee41588ac)
+    dSHA256(00e9a435000000001976a914389ffce9cd9ae88dcc0631e88a821ffdbe9bfe2688acc0832f05000000001976a9147480a33f950689af511e6e84c138dbbd3c3ee41588ac)
   = bc4d309071414bed932f98832b27b4d76dad7e6c1346f487a8fdbb8eb90307cc
   
   hashOutputs for SINGLE: