Merge branch 'master' into HEAD

Author: luke-jr

.travis.yml

@@ -1,7 +1,7 @@
 os: linux
 language: generic
-sudo: false
 script:
+    - scripts/link-format-chk.sh
     - scripts/buildtable.pl >/tmp/table.mediawiki || exit 1
     - diff README.mediawiki /tmp/table.mediawiki | grep '^[<>] |' >/tmp/after.diff || true
     - if git checkout HEAD^ && scripts/buildtable.pl >/tmp/table.mediawiki 2>/dev/null; then diff README.mediawiki /tmp/table.mediawiki | grep '^[<>] |' >/tmp/before.diff || true; newdiff=$(diff -s /tmp/before.diff /tmp/after.diff -u | grep '^+'); if [ -n "$newdiff" ]; then echo "$newdiff"; exit 1; fi; else echo 'Cannot build previous commit table for comparison'; fi

README.mediawiki

@@ -223,7 +223,7 @@ Those proposing changes should consider that ultimately consent may rest with th
 | Marek Palatinus
 | Standard
 | BIP number allocated
-|-style="background-color: #cfffcf"
+|- style="background-color: #cfffcf"
 | [[bip-0042.mediawiki|42]]
 | Consensus (soft fork)
 | A finite monetary supply for Bitcoin
@@ -258,13 +258,13 @@ Those proposing changes should consider that ultimately consent may rest with th
 | Justus Ranvier
 | Informational
 | Draft
-|-
+|- style="background-color: #cfffcf"
 | [[bip-0049.mediawiki|49]]
 | Applications
 | Derivation scheme for P2WPKH-nested-in-P2SH based accounts
 | Daniel Weigl
 | Informational
-| Draft
+| Final
 |- style="background-color: #cfffcf"
 | [[bip-0050.mediawiki|50]]
 |
@@ -371,20 +371,20 @@ Those proposing changes should consider that ultimately consent may rest with th
 | Stephen Pair
 | Standard
 | Final
-|-
+|- style="background-color: #ffcfcf"
 | [[bip-0074.mediawiki|74]]
 | Applications
 | Allow zero value OP_RETURN in Payment Protocol
 | Toby Padilla
 | Standard
-| Draft
-|-
+| Rejected
+|- style="background-color: #cfffcf"
 | [[bip-0075.mediawiki|75]]
 | Applications
 | Out of Band Address Exchange using Payment Protocol Encryption
 | Justin Newton, Matt David, Aaron Voisine, James MacWhyte
 | Standard
-| Draft
+| Final
 |- style="background-color: #ffffcf"
 | [[bip-0079.mediawiki|79]]
 | Applications
@@ -449,26 +449,33 @@ Those proposing changes should consider that ultimately consent may rest with th
 | Informational
 | Draft
 |- style="background-color: #ffcfcf"
+| [[bip-0100.mediawiki|100]]
+| Consensus (hard fork)
+| Dynamic maximum block size by miner vote
+| Jeff Garzik, Tom Harding, Dagur Valberg Johannsson
+| Standard
+| Rejected
+|- style="background-color: #ffcfcf"
 | [[bip-0101.mediawiki|101]]
 | Consensus (hard fork)
 | Increase maximum block size
 | Gavin Andresen
 | Standard
 | Withdrawn
-|-
+|- style="background-color: #ffcfcf"
 | [[bip-0102.mediawiki|102]]
 | Consensus (hard fork)
 | Block size increase to 2MB
 | Jeff Garzik
 | Standard
-| Draft
-|-
+| Rejected
+|- style="background-color: #ffcfcf"
 | [[bip-0103.mediawiki|103]]
 | Consensus (hard fork)
 | Block size following technological growth
 | Pieter Wuille
 | Standard
-| Draft
+| Withdrawn
 |-
 | [[bip-0104.mediawiki|104]]
 | Consensus (hard fork)
@@ -658,6 +665,13 @@ Those proposing changes should consider that ultimately consent may rest with th
 | Sancho Panza
 | Informational
 | Draft
+|-
+| [[bip-0136.mediawiki|136]]
+| Applications
+| Bech32 Encoded Tx Position References
+| Велеслав, Jonas Schnelli, Daniel Pape
+| Informational
+| Draft
 |- style="background-color: #cfffcf"
 | [[bip-0137.mediawiki|137]]
 | Applications
@@ -756,12 +770,19 @@ Those proposing changes should consider that ultimately consent may rest with th
 | Matt Corallo
 | Standard
 | Draft
-|-
+|- style="background-color: #ffcfcf"
 | [[bip-0154.mediawiki|154]]
 | Peer Services
 | Rate Limiting via peer specified challenges
 | Karl-Johan Alm
 | Standard
+| Withdrawn
+|-
+| [[bip-0155.mediawiki|155]]
+| Peer Services
+| addrv2 message
+| Wladimir J. van der Laan
+| Standard
 | Draft
 |-
 | [[bip-0156.mediawiki|156]]
@@ -834,6 +855,13 @@ Those proposing changes should consider that ultimately consent may rest with th
 | Standard
 | Draft
 |-
+| [[bip-0179.mediawiki|179]]
+|
+| Name for payment recipient identifiers
+| Emil Engler, MarcoFalke, Luke Dashjr
+| Informational
+| Draft
+|-
 | [[bip-0180.mediawiki|180]]
 | Peer Services
 | Block size/weight fraud proof
@@ -855,6 +883,20 @@ Those proposing changes should consider that ultimately consent may rest with th
 | Standard
 | Draft
 |-
+| [[bip-0300.mediawiki|300]]
+| Consensus (soft fork)
+| Hashrate Escrows (Consensus layer)
+| Paul Sztorc, CryptAxe
+| Standard
+| Draft
+|-
+| [[bip-0301.mediawiki|301]]
+| Consensus (soft fork)
+| Blind Merged Mining (Consensus layer)
+| Paul Sztorc, CryptAxe
+| Standard
+| Draft
+|-
 | [[bip-0310.mediawiki|310]]
 | Applications
 | Stratum protocol extensions
@@ -875,6 +917,20 @@ Those proposing changes should consider that ultimately consent may rest with th
 | Karl-Johan Alm
 | Standard
 | Draft
+|-
+| [[bip-0325.mediawiki|325]]
+| Applications
+| Signet
+| Karl-Johan Alm
+| Standard
+| Draft
+|-
+| [[bip-0330.mediawiki|330]]
+| Peer Services
+| Transaction announcements reconciliation
+| Gleb Naumenko, Pieter Wuille
+| Standard
+| Draft
 |}
 
 <!-- IMPORTANT!  See the instructions at the top of this page, do NOT JUST add BIPs here! -->

bip-0002.mediawiki

@@ -240,7 +240,7 @@ What if a single merchant wishes to block a hard-fork?
 
 How about a small number of merchants (maybe only two) who sell products to each other?
 
-* In this scenario, it would seem the previous Bitcoin is alive any working, and that the hard-fork has failed. How to resolve such a split is outside the scope of this BIP.
+* In this scenario, it would seem the previous Bitcoin is alive and working, and that the hard-fork has failed. How to resolve such a split is outside the scope of this BIP.
 
 How can economic agreement veto a soft-fork?
 

bip-0013.mediawiki

@@ -50,7 +50,7 @@ This proposal is not backwards compatible, but it fails gracefully-- if an older
 
 ==Reference Implementation==
 
-See base58.cpp1/base58.h at https://github.com/bitcoin/bitcoin/src
+See base58.cpp/base58.h at https://github.com/bitcoin/bitcoin/tree/master/src
 
 ==See Also==
 

bip-0016.mediawiki

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

bip-0032.mediawiki

@@ -294,7 +294,7 @@ Two JavaScript implementations exist: available at https://github.com/sarchar/br
 
 A PHP implementation is available at https://github.com/Bit-Wasp/bitcoin-lib-php
 
-A C# implementation is available at https://github.com/NicolasDorier/NBitcoin (ExtKey, ExtPubKey)
+A C# implementation is available at https://github.com/MetacoSA/NBitcoin (ExtKey, ExtPubKey)
 
 A Haskell implementation is available at https://github.com/haskoin/haskoin together with a CLI interface at https://github.com/np/hx
 

bip-0039/bip-0039-wordlists.md

@@ -8,6 +8,7 @@
 * [Chinese (Traditional)](chinese_traditional.txt)
 * [French](french.txt)
 * [Italian](italian.txt)
+* [Czech](czech.txt)
 
 ## Wordlists (Special Considerations)
 
@@ -82,3 +83,18 @@ Words chosen using the following rules:
 Rules 11 and 12 prevent the selection words that are not different enough. This makes each word more recognizable among others and less error prone. For example: the wordlist contains "atono", then "atomo" is rejected, but "atomico" is good.
 
 All the words have been manually selected and automatically checked against the rules.
+
+### Czech
+
+Credits: @zizelevak (Jan Lansky [email protected])
+
+Words chosen using the following rules:
+
+1.  Words are 4-8 letters long.
+2.  Words can be uniquely determined typing the first 4 letters.
+3.  Only words containing all letters without diacritical marks. (It was the hardest task, because in one third of all Czech letters has diacritical marks.)
+4.  Only nouns, werbs and adverbs, no other word types. All words are in basic form.
+5.  No personal names or geografical names.
+6.  No very similar words with 1 letter of difference.
+7. Words are sorting according English alphabet (Czech sorting has difference in "ch").
+8.  No words already used in other language mnemonic sets (english, italian, french, spanish). Letters with diacritical marks from these sets are counted as analogous  letters without diacritical marks.