Merge remote-tracking branch 'upstream/master'

Author: Fonta1n3

README.mediawiki

@@ -1,4 +1,4 @@
-People wishing to submit BIPs, first should propose their idea or document to the [https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev [email protected]] mailing list. After discussion, please open a PR. After copy-editing and acceptance, it will be published here.
+People wishing to submit BIPs, first should propose their idea or document to the [https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev [email protected]] mailing list (do <em>not</em> assign a number - read <a href="bip-0002.mediawiki">BIP 2</a> for the full process). After discussion, please open a PR. After copy-editing and acceptance, it will be published here.
 
 We are fairly liberal with approving BIPs, and try not to be too involved in decision making on behalf of the community. The exception is in very rare cases of dispute resolution when a decision is contentious and cannot be agreed upon. In those cases, the conservative option will always be preferred.
 
@@ -392,7 +392,7 @@ Those proposing changes should consider that ultimately consent may rest with th
 | Nicolas Dorier
 | Standard
 | Draft
-|- style="background-color: #ffffcf"
+|- style="background-color: #ffcfcf"
 | [[bip-0079.mediawiki|79]]
 | Applications
 | Bustapay :: a practical coinjoin protocol
@@ -847,20 +847,20 @@ Those proposing changes should consider that ultimately consent may rest with th
 | Pieter Wuille, Greg Maxwell
 | Informational
 | Final
-|- style="background-color: #ffffcf"
+|- style="background-color: #cfffcf"
 | [[bip-0174.mediawiki|174]]
 | Applications
 | Partially Signed Bitcoin Transaction Format
 | Andrew Chow
 | Standard
-| Proposed
-|-
+| Final
+|- style="background-color: #ffcfcf"
 | [[bip-0175.mediawiki|175]]
 | Applications
 | Pay to Contract Protocol
 | Omar Shibli, Nicholas Gregory
 | Informational
-| Draft
+| Rejected
 |-
 | [[bip-0176.mediawiki|176]]
 |
@@ -953,6 +953,13 @@ Those proposing changes should consider that ultimately consent may rest with th
 | Standard
 | Draft
 |-
+| [[bip-0338.mediawiki|338]]
+| Peer Services
+| Disable transaction relay message
+| Suhas Daftuar
+| Standard
+| Draft
+|-
 | [[bip-0339.mediawiki|339]]
 | Peer Services
 | WTXID-based transaction relay
@@ -980,6 +987,13 @@ Those proposing changes should consider that ultimately consent may rest with th
 | Pieter Wuille, Jonas Nick, Anthony Towns
 | Standard
 | Draft
+|-
+| [[bip-0350.mediawiki|350]]
+| Applications
+| Bech32m format for v1+ witness addresses
+| Pieter Wuille
+| Standard
+| Draft
 |}
 
 <!-- IMPORTANT!  See the instructions at the top of this page, do NOT JUST add BIPs here! -->

bip-0008.mediawiki

@@ -79,12 +79,13 @@ for the purposes of this proposal, and support two future upgrades for different
 When a block nVersion does not have top bits 001, it is treated as if all
 bits are 0 for the purposes of deployments.
 
+Miners should continue setting the bit in LOCKED_IN phase so uptake is visible, though this has no effect on consensus rules.
+
 ===New consensus rules===
 
 The new consensus rules for each soft fork are enforced for each block that has ACTIVE state.
 
-During the MUST_SIGNAL and LOCKED_IN phases, blocks that fail to signal are invalid.
-For flexibility, during the LOCKED_IN phase only, this rule does NOT require the top 3 bits to be set any particular way.
+During the MUST_SIGNAL phase, if '''(2016 - threshold)''' blocks in the retarget period have already failed to signal, any further blocks that fail to signal are invalid.
 
 ===State transitions===
 
@@ -176,16 +177,23 @@ block, indexed by its parent.
 
 ===Mandatory signalling===
 
-Blocks received while in the MUST_SIGNAL and LOCKED_IN phases must be checked to ensure that they signal. For example:
+Blocks received while in the MUST_SIGNAL phase must be checked to ensure that they signal as required. For example:
 
     if (GetStateForBlock(block) == MUST_SIGNAL) {
-        if ((block.nVersion & 0xE0000000) != 0x20000000 || ((block.nVersion >> bit) & 1) != 1) {
-            return state.Invalid(BlockValidationResult::RECENT_CONSENSUS_CHANGE, "bad-version-bip8-must-signal");
-        }
-    }
-    if (GetStateForBlock(block) == LOCKED_IN) {
-        if (((block.nVersion >> bit) & 1) != 1) {
-            return state.Invalid(BlockValidationResult::RECENT_CONSENSUS_CHANGE, "bad-version-bip8-locked-in");
+        int nonsignal = 0;
+        walk = block;
+        while (true) {
+            if ((walk.nVersion & 0xE0000000) != 0x20000000 || ((walk.nVersion >> bit) & 1) != 1) {
+                ++nonsignal;
+                if (nonsignal > 2016 - threshold) {
+                    return state.Invalid(BlockValidationResult::RECENT_CONSENSUS_CHANGE, "bad-version-bip8-must-signal");
+                }
+            }
+            if (walk.nHeight % 2016 == 0) {
+                // checked every block in this retarget period
+                break;
+            }
+            walk = walk.parent;
         }
     }
 
@@ -226,7 +234,7 @@ The template Object is also extended:
 The "version" key of the template is retained, and used to indicate the server's preference of deployments.
 If versionbits is being used, "version" MUST be within the versionbits range of [0x20000000...0x3FFFFFFF].
 Miners MAY clear or set bits in the block version WITHOUT any special "mutable" key, provided they are listed among the template's "vbavailable" and (when clearing is desired) NOT included as a bit in "vbrequired".
-Servers MUST set bits in "vbrequired" for deployments in MUST_SIGNAL and LOCKED_IN states, to ensure blocks produced are valid.
+Servers MUST set bits in "vbrequired" for deployments in MUST_SIGNAL state, to ensure blocks produced are valid.
 
 Softfork deployment names listed in "rules" or as keys in "vbavailable" may be prefixed by a '!' character.
 Without this prefix, GBT clients may assume the rule will not impact usage of the template as-is; typical examples of this would be when previously valid transactions cease to be valid, such as BIPs 16, 65, 66, 68, 112, and 113.

bip-0034.mediawiki

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

bip-0039.mediawiki

@@ -113,7 +113,14 @@ will make the desired wallet available.
 
 ==Wordlists==
 
-* [[bip-0039/bip-0039-wordlists.md|Moved to separate document]]
+Since the vast majority of BIP39 wallets supports only the English wordlist,
+it is '''strongly discouraged''' to use non-English wordlists for generating
+the mnemonic sentences.
+
+If you still feel your application really needs to use a localized wordlist,
+use one of the following instead of inventing your own.
+
+* [[bip-0039/bip-0039-wordlists.md|Wordlists]]
 
 ==Test vectors==
 
@@ -137,6 +144,9 @@ http://github.com/trezor/python-mnemonic
 Go:
 * https://github.com/tyler-smith/go-bip39
 
+Python:
+* https://github.com/meherett/python-hdwallet
+
 Elixir:
 * https://github.com/aerosol/mnemo
 
@@ -164,6 +174,7 @@ Ruby:
 
 Rust:
 * https://github.com/maciejhirsz/tiny-bip39/
+* https://github.com/koushiro/bip0039-rs
 
 Swift:
 * https://github.com/CikeQiu/CKMnemonic

bip-0039/bip-0039-wordlists.md

@@ -9,6 +9,7 @@
 * [French](french.txt)
 * [Italian](italian.txt)
 * [Czech](czech.txt)
+* [Portuguese](portuguese.txt)
 
 ## Wordlists (Special Considerations)
 
@@ -98,3 +99,19 @@ Words chosen using the following rules:
 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.
+
+### Portuguese
+
+Credits: @alegotardo @bitmover-studio @brenorb @kuthullu @ninjastic @sabotag3x @Trimegistus
+
+1. Words can be uniquely determined typing the first 4 characters.
+2. No accents or special characters.
+3. No complex verb forms.
+4. No plural words, unless there's no singular form.
+5. No words with double spelling.
+6. No words with the exact sound of another word with different spelling.
+7. No offensive words.
+8. No words already used in other language mnemonic sets.
+9. The words which have not the same spelling in Brazil and in Portugal are excluded.
+10. No words that remind negative/sad/bad things.
+11. No very similar words with 1 letter of difference.