Merge remote-tracking branch 'refs/remotes/bitcoin-dot-org/master'

2025-07-27 17:56:16 +00:00 · 2015-12-27 01:53:10 +00:00 · 2015-12-27 01:53:10 +00:00 · 06e41b9e5a
commit 06e41b9e5a
parent c2befaecd2 cc79a1ee7d
21 changed files with 1032 additions and 79 deletions
--- a/_autocrossref.yaml
+++ b/_autocrossref.yaml
@ -309,6 +309,9 @@ CVE-2012-2459:
 '`ping` RPC': rpc ping
 '`sendfrom`': rpc sendfrom
 '`sendfrom` RPC': rpc sendfrom
 '`sendheaders`': sendheaders message
 '`sendheaders` message': sendheaders message
 '`sendheaders` messages': sendheaders message
 '`sendmany`': rpc sendmany
 '`sendmany` RPC': rpc sendmany
 '`sendrawtransaction`': rpc sendrawtransaction
--- a/_events.yml
+++ b/_events.yml
@ -1,27 +1,3 @@
 - date: 2015-11-12
  title: "The Future of Money: Cashing out on Cash"
  venue: "Thomson Reuters"
  address: "3 Times Square"
  city: "New York"
  country: "USA"
  link: "http://rsvp.thomsonreuters.com/node/839"
 - date: 2015-11-20
  title: "Practical workshop"
  venue: "Las Naves"
  address: "Joan Verdeguer 16"
  city: "Valencia"
  country: "Spain"
  link: "http://avalbit.org/actividades/taller-practico-bitcoin/"
 - date: 2015-11-24
  title: "ADCCA Fintech Summit"
  venue: "The Westin Sydney"
  address: "1 Martin Place"
  city: "Sydney"
  country: "Australia"
  link: "http://www.adccasummit.com/"
 - date: 2015-12-03
  title: "Moneylab#2 Economies of Dissent"
  venue: "Pakhuis De Zwijger"
@ -31,9 +7,9 @@
  link: "http://networkcultures.org/moneylab/"
 - date: 2015-12-02
-  title: "Bitcoin Wednesday Conference"
+  title: "The Bitcoin Film Festival: Bitcoin Wednesday Conference"
-  venue: "De Balie"
+  venue: "Melkweg"
-  address: "Leidseplein, Kleine-Gartmanplantsoen 10"
+  address: "Leidseplein, Lijnbaansgracht 234a"
  city: "Amsterdam"
  country: "The Netherlands"
  link: "http://www.bitcoinwednesday.com/event/bitcoin-wednesday-30/"
@ -78,6 +54,14 @@
  country: "United States"
  link: "http://insidebitcoins.com/san-diego/2015?utm_source=bitcoinorg&utm_medium=eventlisting&utm_campaign=bitcoinorgeventlistingibsd"
 - date: 2016-01-06
  title: "Bitcoin Wednesday Conference"
  venue: "Melkweg"
  address: "Leidseplein, Lijnbaansgracht 234a"
  city: "Amsterdam"
  country: "The Netherlands"
  link: "http://www.bitcoinwednesday.com/event/bitcoin-wednesday-31/"
 - date: 2016-01-21
  title: "The North American Bitcoin Conference"
  venue: "James L Knight Center"
--- a/_includes/bitcoin-core/capability-increases-sigs.md
+++ b/_includes/bitcoin-core/capability-increases-sigs.md
@ -0,0 +1,55 @@
 {% comment %}
 This file is licensed under the MIT License (MIT) available on
 http://opensource.org/licenses/MIT.
 {% endcomment %}
 - [Adam Back](https://github.com/adam3us)
 - [Alex Morcos](https://github.com/morcos)
 - [Ben Davenport](https://github.com/bpdavenport)
 - [Ben Gorlick](https://github.com/bgorlick)
 - [Bram Cohen](https://github.com/bramcohen)
 - [Bryan Bishop](https://github.com/kanzure)
 - [BtcDrak](https://github.com/btcdrak)
 - [Charlie Lee](https://github.com/coblee)
 - [Christian Decker](https://github.com/cdecker)
 - [Cory Fields](https://github.com/theuni)
 - [Craig Watkins](https://github.com/crwatkins)
 - [Daniel](https://github.com/arowser)
 - [Daniel Kraft](https://github.com/domob1812)
 - [David A. Harding](https://github.com/harding)
 - [David Vorick](https://github.com/DavidVorick)
 - [Dev Random](https://github.com/devrandom)
 - [DexX7](https://github.com/dexX7)
 - [Douglas Huff](https://github.com/jrmithdobbs)
 - [Eric Lombrozo](https://github.com/CodeShark)
 - [Glenn H Tarbox](https://github.com/ghtdak)
 - [Gregory Maxwell](https://github.com/gmaxwell)
 - [Gregory Sanders](https://github.com/instagibbs)
 - [James Hilliard](https://github.com/jameshilliard)
 - [Johnathan Corgan](https://github.com/jmcorgan)
 - [Johnson Lau](https://github.com/jl2012)
 - [Jonas Schnelli](https://github.com/jonasschnelli)
 - [Jouke Hofman](https://github.com/Joukehofman)
 - [Lawrence Nahum](https://github.com/greenaddress)
 - [Luke Dashjr](https://github.com/luke-jr)
 - [Mark Friedenbach](https://github.com/maaku)
 - [Marshall Long](https://github.com/FinalHash)
 - [Eric Martindale](https://github.com/martindale)
 - [Marco Falke](https://github.com/MarcoFalke)
 - [Matt Corallo](https://github.com/TheBlueMatt)
 - [Midnight Magic](https://github.com/midnightmagic)
 - [Michael Ford](https://github.com/fanquake)
 - [Nicolas Bacca](https://github.com/btchip)
 - [Nicolas Dorier](https://github.com/NicolasDorier)
 - [Obi Nwosu](https://github.com/obi)
 - [Patrick Strateman](https://github.com/pstratem)
 - [Pavel Janik](https://github.com/paveljanik)
 - [Pieter Wuille](https://github.com/sipa)
 - [Randy Waterhouse](https://github.com/randy-waterhouse)
 - [Rodolfo Novak](https://github.com/nvk)
 - [Suhas Daftuar](https://github.com/sdaftuar)
 - [Theymos](https://github.com/theymos)
 - [Thomas Kerin](https://github.com/afk11)
 - [Wang Chun](https://github.com/wangchun)
 - [Warren Togami](https://github.com/wtogami)
 - [Wladimir J. van der Laan](https://github.com/laanwj)
--- a/_includes/bitcoin-core/core-committers.html
+++ b/_includes/bitcoin-core/core-committers.html
@ -9,4 +9,5 @@ http://opensource.org/licenses/MIT.
  <div><div>Jeff Garzik</div><div><a href="mailto:jgarzik@pobox.com">jgarzik@pobox.com</a></div><div><a href="/jgarzik-pobox.asc">PGP</a></div></div>
  <div><div>Gregory Maxwell</div><div><a href="mailto:greg@xiph.org">greg@xiph.org</a></div><div><a href="/gmaxwell.asc">PGP</a></div></div>
  <div><div>Pieter Wuille</div><div><a href="mailto:pieter.wuille@gmail.com">pieter.wuille@gmail.com</a></div><div><a href="/pieterwuille.asc">PGP</a></div></div>
  <div><div>Jonas Schnelli</div><div><a href="mailto:dev@jonasschnelli.ch">dev@jonasschnelli.ch</a></div><div><a href="/jonasschnelli.asc">PGP</a></div></div>
 </div>
--- a/_includes/devdoc/ref_p2p_networking.md
+++ b/_includes/devdoc/ref_p2p_networking.md
@ -68,6 +68,7 @@ As of Bitcoin Core 0.11.0, the most recent protocol version is 70002.
 | Version | Initial Release                    | Major Changes
 |---------|------------------------------------|--------------
 | 70012   | Bitcoin Core 0.12.0 <br>(Not released yet)  | [BIP130][]: <br>• Added `sendheaders` message
 | 70002   | Bitcoin Core 0.9.0 <br>(Mar 2014)  | • Send multiple `inv` messages in response to a `mempool` message if necessary <br><br>[BIP61][]: <br>• Added `reject` message
 | 70001   | Bitcoin Core 0.8.0 <br>(Feb 2013)  | • Added `notfound` message. <br><br>[BIP37][]: <br>• Added `filterload` message. <br>• Added `filteradd` message. <br>• Added `filterclear` message. <br>• Added `merkleblock` message. <br>• Added relay field to `version` message <br>• Added `MSG_FILTERED_BLOCK` inventory type to `getdata` message.
 | 60002   | Bitcoin Core 0.7.0 <br>(Sep 2012)  | [BIP35][]: <br>• Added `mempool` message. <br>• Extended `getdata` message to allow download of memory pool transactions
@ -1211,6 +1212,19 @@ header has been omitted.)
 {% endautocrossref %}
 #### SendHeaders
 {% include helpers/subhead-links.md %}
 {% autocrossref %}
 The `sendheaders` message tells the receiving peer to send new block
 announcements using a `headers` message rather than an `inv` message.
 There is no payload in a `sendheaders` message.  See the [message header
 section][section message header] for an example of a message without a payload.
 {% endautocrossref %}
 #### VerAck
 {% include helpers/subhead-links.md %}
--- a/_includes/references.md
+++ b/_includes/references.md
@ -175,6 +175,7 @@ http://opensource.org/licenses/MIT.
 [ping message]: /en/developer-reference#ping "A P2P network message used to see if the remote host is still connected"
 [pong message]: /en/developer-reference#pong "A P2P network message used to reply to a P2P network ping message"
 [reject message]: /en/developer-reference#reject "A P2P network message used to indicate a previously-received message was rejected for some reason"
 [sendheaders message]: /en/developer-reference#sendheaders "A P2P network message used to request new blocks be announced through headers messages rather than inv messages"
 [tx message]: /en/developer-reference#tx "A P2P protocol message which sends a single serialized transaction"
 [verack message]: /en/developer-reference#verack "A P2P network message sent in reply to a version message to confirm a connection has been established"
 [version message]: /en/developer-reference#version "A P2P network message sent at the begining of a connection to allow protocol version negotiation"
@ -287,6 +288,7 @@ http://opensource.org/licenses/MIT.
 [BIP70]: https://github.com/bitcoin/bips/blob/master/bip-0070.mediawiki
 [BIP71]: https://github.com/bitcoin/bips/blob/master/bip-0071.mediawiki
 [BIP72]: https://github.com/bitcoin/bips/blob/master/bip-0072.mediawiki
 [BIP130]: https://github.com/bitcoin/bips/blob/master/bip-0130.mediawiki
 [CVE-2012-2459]: https://en.bitcoin.it/wiki/CVEs#CVE-2012-2459
 [RFC5737]: http://tools.ietf.org/html/rfc5737
 [secp256k1]: http://www.secg.org/sec2-v2.pdf
--- a/_releases/0.11.2.md
+++ b/_releases/0.11.2.md
@ -0,0 +1,248 @@
 ---
 # This file is licensed under the MIT License (MIT) available on
 # http://opensource.org/licenses/MIT.
 # Text originally from Bitcoin Core project
 # Metadata and small formatting changes from Bitcoin.org project
 ## Required value below populates the %v variable (note: % needs to be escaped in YAML if it starts a value)
 required_version: 0.11.2
 ## Optional release date.  May be filled in hours/days after a release
 optional_date: 2015-11-13
 ## Optional title.  If not set, default is: Bitcoin Core version %v released
 optional_title: Bitcoin Core version %v released
 ## Optional magnet link.  To get it, open the torrent in a good BitTorrent client
 ## and View Details, or install the transmission-cli Debian/Ubuntu package
 ## and run: transmission-show -m <torrent file>
 #
 ## Link should be enclosed in quotes and start with: "magnet:?
 optional_magnetlink: "magnet:?xt=urn:btih:d6d3387160f7e14f6f27dc40ae84cf566ebf631b&dn=bitcoin-core-0.11.2&tr=udp%3A%2F%2Ftracker.openbittorrent.com%3A80%2Fannounce&tr=udp%3A%2F%2Ftracker.publicbt.com%3A80%2Fannounce&tr=udp%3A%2F%2Ftracker.ccc.de%3A80%2Fannounce&tr=udp%3A%2F%2Ftracker.coppersurfer.tk%3A6969&tr=udp%3A%2F%2Fopen.demonii.com%3A1337&ws=https%3A%2F%2Fbitcoin.org%2Fbin%2F"
 ## The --- below ends the YAML header. After that, paste the release notes.
 ## Warning: this site's Markdown parser commonly requires you make two
 ## changes to the release notes from the Bitcoin Core source tree:
 ##
 ## 1. Make sure both ordered and unordered lists are preceeded by an empty
 ## (whitespace only) line, like the empty line before this list item.
 ##
 ## 2. Place URLs inside angle brackets, like <http://bitcoin.org/bin>
 ---
 {% githubify https://github.com/bitcoin/bitcoin %}
 Bitcoin Core version 0.11.2 is now available from:
  <https://bitcoin.org/bin/bitcoin-core-0.11.2/>
 This is a new minor version release, bringing bug fixes, the BIP65
 (CLTV) consensus change, and relay policy preparation for BIP113. It is
 recommended to upgrade to this version as soon as possible.
 Please report bugs using the issue tracker at github:
  <https://github.com/bitcoin/bitcoin/issues>
 Upgrading and downgrading
 =========================
 How to Upgrade
 --------------
 If you are running an older version, shut it down. Wait until it has completely
 shut down (which might take a few minutes for older versions), then run the
 installer (on Windows) or just copy over /Applications/Bitcoin-Qt (on Mac) or
 bitcoind/bitcoin-qt (on Linux).
 Downgrade warning
 ------------------
 Because release 0.10.0 and later makes use of headers-first synchronization and
 parallel block download (see further), the block files and databases are not
 backwards-compatible with pre-0.10 versions of Bitcoin Core or other software:
 * Blocks will be stored on disk out of order (in the order they are
 received, really), which makes it incompatible with some tools or
 other programs. Reindexing using earlier versions will also not work
 anymore as a result of this.
 * The block index database will now hold headers for which no block is
 stored on disk, which earlier versions won't support.
 If you want to be able to downgrade smoothly, make a backup of your entire data
 directory. Without this your node will need start syncing (or importing from
 bootstrap.dat) anew afterwards. It is possible that the data from a completely
 synchronised 0.10 node may be usable in older versions as-is, but this is not
 supported and may break as soon as the older version attempts to reindex.
 This does not affect wallet forward or backward compatibility. There are no
 known problems when downgrading from 0.11.x to 0.10.x.
 Notable changes since 0.11.1
 ============================
 BIP65 soft fork to enforce OP_CHECKLOCKTIMEVERIFY opcode
 --------------------------------------------------------
 This release includes several changes related to the [BIP65][] soft fork
 which redefines the existing OP_NOP2 opcode as OP_CHECKLOCKTIMEVERIFY
 (CLTV) so that a transaction output can be made unspendable until a
 specified point in the future.
 1. This release will only relay and mine transactions spending a CLTV
   output if they comply with the BIP65 rules as provided in code.
 2. This release will produce version 4 blocks by default. Please see the
   *notice to miners* below.
 3. Once 951 out of a sequence of 1,001 blocks on the local node's best block
   chain contain version 4 (or higher) blocks, this release will no
   longer accept new version 3 blocks and it will only accept version 4
   blocks if they comply with the BIP65 rules for CLTV.
 For more information about the soft-forking change, please see
 <https://github.com/bitcoin/bitcoin/pull/6351>
 Graphs showing the progress towards block version 4 adoption may be
 found at the URLs below:
 - Block versions over the last 50,000 blocks as progress towards BIP65
  consensus enforcement: <http://bitcoin.sipa.be/ver-50k.png>
 - Block versions over the last 2,000 blocks showing the days to the
  earliest possible BIP65 consensus-enforced block: <http://bitcoin.sipa.be/ver-2k.png>
 **Notice to miners:** Bitcoin Core’s block templates are now for
 version 4 blocks only, and any mining software relying on its
 getblocktemplate must be updated in parallel to use libblkmaker either
 version 0.4.3 or any version from 0.5.2 onward.
 - If you are solo mining, this will affect you the moment you upgrade
  Bitcoin Core, which must be done prior to BIP65 achieving its 951/1001
  status.
 - If you are mining with the stratum mining protocol: this does not
  affect you.
 - If you are mining with the getblocktemplate protocol to a pool: this
  will affect you at the pool operator’s discretion, which must be no
  later than BIP65 achieving its 951/1001 status.
 [BIP65]: https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki
 BIP113 mempool-only locktime enforcement using GetMedianTimePast()
 ----------------------------------------------------------------
 Bitcoin transactions currently may specify a locktime indicating when
 they may be added to a valid block.  Current consensus rules require
 that blocks have a block header time greater than the locktime specified
 in any transaction in that block.
 Miners get to choose what time they use for their header time, with the
 consensus rule being that no node will accept a block whose time is more
 than two hours in the future.  This creates a incentive for miners to
 set their header times to future values in order to include locktimed
 transactions which weren't supposed to be included for up to two more
 hours.
 The consensus rules also specify that valid blocks may have a header
 time greater than that of the median of the 11 previous blocks.  This
 GetMedianTimePast() time has a key feature we generally associate with
 time: it can't go backwards.
 [BIP113][] specifies a soft fork (**not enforced in this release**) that
 weakens this perverse incentive for individual miners to use a future
 time by requiring that valid blocks have a computed GetMedianTimePast()
 greater than the locktime specified in any transaction in that block.
 Mempool inclusion rules currently require transactions to be valid for
 immediate inclusion in a block in order to be accepted into the mempool.
 This release begins applying the BIP113 rule to received transactions,
 so transaction whose time is greater than the GetMedianTimePast() will
 no longer be accepted into the mempool.
 **Implication for miners:** you will begin rejecting transactions that
 would not be valid under BIP113, which will prevent you from producing
 invalid blocks if/when BIP113 is enforced on the network. Any
 transactions which are valid under the current rules but not yet valid
 under the BIP113 rules will either be mined by other miners or delayed
 until they are valid under BIP113. Note, however, that time-based
 locktime transactions are more or less unseen on the network currently.
 **Implication for users:** GetMedianTimePast() always trails behind the
 current time, so a transaction locktime set to the present time will be
 rejected by nodes running this release until the median time moves
 forward. To compensate, subtract one hour (3,600 seconds) from your
 locktimes to allow those transactions to be included in mempools at
 approximately the expected time.
 [BIP113]: https://github.com/bitcoin/bips/blob/master/bip-0113.mediawiki
 Windows bug fix for corrupted UTXO database on unclean shutdowns
 ----------------------------------------------------------------
 Several Windows users reported that they often need to reindex the
 entire blockchain after an unclean shutdown of Bitcoin Core on Windows
 (or an unclean shutdown of Windows itself). Although unclean shutdowns
 remain unsafe, this release no longer relies on memory-mapped files for
 the UTXO database, which significantly reduced the frequency of unclean
 shutdowns leading to required reindexes during testing.
 For more information, see: <https://github.com/bitcoin/bitcoin/pull/6917>
 Other fixes for database corruption on Windows are expected in the
 next major release.
 0.11.2 Change log
 =================
 Detailed release notes follow. This overview includes changes that affect
 behavior, not code moves, refactors and string updates. For convenience in locating
 the code changes and accompanying discussion, both the pull request and
 git merge commit are mentioned.
 - #6124 `684636b` Make CScriptNum() take nMaxNumSize as an argument
 - #6124 `4fa7a04` Replace NOP2 with CHECKLOCKTIMEVERIFY (BIP65)
 - #6124 `6ea5ca4` Enable CHECKLOCKTIMEVERIFY as a standard script verify flag
 - #6351 `5e82e1c` Add CHECKLOCKTIMEVERIFY (BIP65) soft-fork logic
 - #6353 `ba1da90` Show softfork status in getblockchaininfo
 - #6351 `6af25b0` Add BIP65 to getblockchaininfo softforks list
 - #6688 `01878c9` Fix locking in GetTransaction
 - #6653 `b3eaa30` [Qt] Raise debug window when requested
 - #6600 `1e672ae` Debian/Ubuntu: Include bitcoin-tx binary
 - #6600 `2394f4d` Debian/Ubuntu: Split bitcoin-tx into its own package
 - #5987 `33d6825` Bugfix: Allow mining on top of old tip blocks for testnet
 - #6852 `21e58b8` build: make sure OpenSSL heeds noexecstack
 - #6846 `af6edac` alias `-h` for `--help`
 - #6867 `95a5039` Set TCP_NODELAY on P2P sockets.
 - #6856 `dfe55bd` Do not allow blockfile pruning during reindex.
 - #6566 `a1d3c6f` Add rules--presently disabled--for using GetMedianTimePast as end point for lock-time calculations
 - #6566 `f720c5f` Enable policy enforcing GetMedianTimePast as the end point of lock-time constraints
 - #6917 `0af5b8e` leveldb: Win32WritableFile without memory mapping
 - #6948 `4e895b0` Always flush block and undo when switching to new file
 Credits
 =======
 Thanks to everyone who directly contributed to this release:
 - Alex Morcos
 - ฿tcDrak
 - Chris Kleeschulte
 - Daniel Cousens
 - Diego Viola
 - Eric Lombrozo
 - Esteban Ordano
 - Gregory Maxwell
 - Luke Dashjr
 - Marco Falke
 - Mark Friedenbach
 - Matt Corallo
 - Micha
 - Mitchell Cash
 - Peter Todd
 - Pieter Wuille
 - Wladimir J. van der Laan
 - Zak Wilcox
 And those who contributed additional code review and/or security research.
 As well as everyone that helped translating on [Transifex](https://www.transifex.com/projects/p/bitcoin/).
 {% endgithubify %}
--- a/_templates/about-us.html
+++ b/_templates/about-us.html
@ -54,7 +54,7 @@ id: about-us
 <h3 id="translation">{% translate translation %}</h3>
 <div class="credit">
-  <p><a href="https://github.com/wilbns">Will Binns</a><span>Translation coordination</span></p>
+  <p><a href="https://github.com/wbinns">Will Binns</a><span>Translation coordination</span></p>
  <p>Ar Vicco<span>Russian</span></p>
  <p>Simon Alexander Hinterreiter<span>German</span></p>
  <p>Jacob Burenstam<span>Swedish</span></p>
--- a/_templates/choose-your-wallet.html
+++ b/_templates/choose-your-wallet.html
@ -445,6 +445,29 @@ wallets:
          privacyaddressreuse: "checkfailprivacyaddressrotation"
          privacydisclosure: "checkfailprivacydisclosurespv"
          privacynetwork: "checkfailprivacynetworknosupporttor"
 - greenbits:
    title: "GreenBits"
    titleshort: "GreenBits"
    compat: "mobile android"
    level: 2
    platform:
      mobile:
        text: "walletgreenbits"
        link: "https://play.google.com/store/apps/details?id=com.greenaddress.greenbits_android_wallet"
        source: "https://github.com/greenaddress/GreenBits"
        screenshot: "greenbits.png"
        os:
        - android
        check:
          control: "checkpasscontrolmulti"
          validation: "checkpassvalidationspvp2p"
          transparency: "checkpasstransparencyopensource"
          environment: "checkpassenvironmenttwofactor"
          privacy: "checkpassprivacybasic"
        privacycheck:
          privacyaddressreuse: "checkpassprivacyaddressrotation"
          privacydisclosure: "checkfailprivacydisclosureaccount"
          privacynetwork: "checkfailprivacynetworknosupporttor"
 - mycelium:
    title: "Mycelium"
    titleshort: "Mycelium"
--- a/_translations/en.yml
+++ b/_translations/en.yml
@ -190,6 +190,7 @@ en:
    walletninki: "An advanced wallet for experienced Bitcoin users. Ninki is a multi-signature wallet with a beautiful user interface. You have full control of your bitcoins at all times."
    walletbither: "Bither is a simple and secure wallet on many platforms. With special designed Cold/Hot modes, user can easily get both safety and simplicity. Bither's XRANDOM uses different entropy sources to generate true random number for users. Also with HDM, users can have HD's advantages and Multisig's security."
    walletcoinapult: "Coinapult's wallet is designed with Bitcoin newcomers in mind. It allows sending bitcoins via email and SMS, and a handy tool called Locks helps protecting your balance from Bitcoin price swings. Users can Lock bitcoins to Gold, Euros, and more!"
    walletgreenbits: "GreenBits is a fast and easy to use wallet. Enjoy improved security with a minimal/zero trust approach, optional hardware wallets support, multisignature based 2FA and spending limits functionality."
    walletcoinomi: "Coinomi is a lightweight, secure, open-source, universal, HD Wallet. Apart from Bitcoin it also supports many altcoins so you can keep all your funds in a single wallet. Your private keys never leave your device and you only need to back it up just once!"
    walletdownload: "Install"
    walletvisit: "Visit website"
--- a/en/bitcoin-core/capacity-increases-faq.md
+++ b/en/bitcoin-core/capacity-increases-faq.md
@ -0,0 +1,369 @@
 ---
 # This file is licensed under the MIT License (MIT) available on
 # http://opensource.org/licenses/MIT.
 layout: base-core
 lang: en
 id: bitcoin-core-capacity-increases-faq
 columns: 1
 title: Capacity increases FAQ — Bitcoin Core
 breadcrumbs:
  - bitcoin
  - bcc
  - Capacity increases FAQ
 ---
 # Capacity increases FAQ
 1. toc
 {:toc}
 ## What specific technologies are included in the roadmap, and when can we expect them?  {#roadmap-dates}
 New technology will be deployed when it is ready and has been tested.
 However, we believe the following is a reasonable schedule for the
 specific improvements described in the [roadmap][].
 | Dec 2015 | | Deploy segregated witness testnet |
 | Feb 2016 | 0.12.0 | [libsecp256k1 verification][] |
 | Feb 2016 | | Segregated witness feature complete & ready for general review |
 | Mar 2016\* | 0.12.x | Deploy OP_CHECKSEQUENCEVERIFY (BIPs [68][BIP68] & [112][BIP112]) + [BIP113][] as first [BIP9][] versionbits soft fork |
 | April 2016\* |  0.12.x |  Deploy segregated witness |
 | 2016 | | Weak blocks, IBLTs, or both |
 \* Dates with an asterisk are when we expect to release soft fork-ready code. The code will not be released until it has been well reviewed, and the actual fork will take time to activate ([BIP66][] activated in July 2015 after a few months; [BIP65][] activated in Dec 2015 after only 5 weeks).
 - **Segregated witness testnet:** a separate testnet (not part of the
  regular testnet) that provides an opportunity for Bitcoin Core
  contributors to test segregated witness and for wallet authors to
  begin working with it.
 - **[Libsecp256k1][] verification:** 500% to 700% speed boost on x86\_64
  hardware during verification to help new full nodes join the network
  and to lighten the burden on existing nodes.
 - **[OP\_CHECKSEQUENCEVERIFY][BIP112]:** 25,000% improvement in bi-directional
  [payment channel efficiency][] by allowing users to keep channels open
  as long as they want.
 - **[VersionBits][BIP9]:** increase the maximum number of soft forks able to be
  deployed simultaneously from 1 to 29, allowing for faster and more
  decentralized future upgrades of the network.
 - **[Segregated witness][bip-segwit]:** 175% to 400% direct capacity upgrade, 66%
  additional improvement in bi-directional channel efficiency by
  consolidating channel open and close operations, an end to
  third-party malleability that hurts smart contract deployment, fraud
  proofs to allow lightweight clients to better participate in
  economic enforcement, and ability to more easily upgrade Bitcoin's
  Script language so that new and more powerful trustless contracts
  may be devised.
 - **IBLTs and weak blocks:** 90% or more reduction in critical bandwidth
  to relay blocks created by miners who want their blocks to propagate
  quickly with a modest [increase in total bandwidth][], bringing many of
  the benefits of the [Bitcoin Relay Network][] to all full nodes. This
  improvement is accomplished by spreading bandwidth usage out over time
  for full nodes, which means IBLT and weak blocks may allow for safer
  future increases to the max block size.
 ## Is the segregated witness soft fork equivalent to a 4MB block size increase, a 2MB increase, a 1.75MB increase, or what? I keep hearing different numbers.  {#segwit-size}
 The [current proposal][] for soft fork segregated witness (segwit) counts
 each byte in a witness as 0.25 bytes towards the maximum block size
 limit, meaning the maximum size of a block is just under 4MB.
 However, blocks are not expected to consist entirely of witness data and
 each non-witness byte is counted as 1.00 bytes towards the maximum block
 size limit, so blocks near 4MB in size would be unlikely.
 According to some [calculations][] performed by Anthony Towns, a block
 filled with standard single-signature P2PKH transactions would be about
 1.6MB and a block filled with 2-of-2 multisignature transactions would
 be about 2.0MB.
 [current proposal]: https://youtu.be/fst1IK_mrng?t=2234
 [calculations]: http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/011869.html
 ## Segregated witness sounds complicated; will the ecosystem be prepared for its deployment?  {#ecosystem-ready}
 Some ideas are easy to explain but hard to execute. Other ideas are easy
 to execute but hard to explain. Segregated witness (segwit) seems to be
 the latter.
 Segwit can be deployed incrementally without breaking compatibility, so
 no significant preparation of the ecosystem is necessary. Developers
 who want immediate hands-on experience with segwit can begin to test
 their software on the segwit testnet being deployed in Dec 2015.
 Initially, only miners who wish to support it need to upgrade in
 order to activate it and enforce it on the mainnet. Existing
 applications only need to change if they wish to take advantage of the
 new features.
 Segregated witness transactions will require lower fees, will afford
 much greater performance optimizations, and can support multistage smart
 contracts and protocols such as bi-directional payment channels that can
 scale without writing extra data to the blockchain. Wallets are strongly
 encouraged to upgrade but can continue to operate without modification
 as the deployment does not break backwards compatibility.
 ## Segregated witness still sounds complicated. Why not simply raise the maximum block size?  {#size-bump}
 There's a [single line of code][max_block_size] in Bitcoin Core that says the maximum block size is 1,000,000 bytes (1MB). The simplest change would be a hard fork to update that line to say, for example, 2,000,000 bytes (2MB).
 Hard forks are anything but simple:
 - **We don't have experience:** Miners, merchants, developers, and users
  have never deployed a hard fork, so techniques for safely deploying
  them have not been tested.
    This is unlike soft forks, whose deployments were initially managed
    by Nakamoto, where we gained experience from the complications in
    the [BIP16][] deployment, where we refined our technique in the [BIP34][]
    deployment, and where we've gained enough experience with BIPs [66][BIP66]
    and [65][BIP65] to begin managing multiple soft forks with [BIP9][] version bits
    in the future.
 - **Upgrades required:** Hard forks require all full nodes to upgrade or
  everyone who uses that node may lose money. This includes the node
  operator, if they use it to protect their wallet, as well as
  lightweight clients who get their data from the node.
 - **Other changes required:** Even a single-line change such as
  increasing the maximum block size has effects on other parts of the
  code, some of which are undesirable. For example, right now it's
  possible to construct a transaction that takes up almost 1MB of
  space and which takes 30 seconds or more to validate on a modern
  computer (blocks containing such transactions have been mined). In
  2MB blocks, a 2MB transaction can be constructed that may take over
  10 minutes to validate which opens up dangerous denial-of-service
  attack vectors.  Other lines of code would need to be changed to
  prevent these problems.
 Despite these considerable complications, with sufficient precautions,
 none of them is fatal to a hard fork, and we do expect to make hard
 forks in the future. But with segregated witness (segwit) we have a
 soft fork, similar to other soft forks we've performed and gained
 experience in deploying, that provides us with many benefits in addition
 to allowing more transactions to be added to the blockchain.
 Segwit does require more changes in higher level software stacks than a
 simple block size increase, but if we truly want to see bitcoin scale,
 far more invasive changes will be needed anyway, and segwit will
 gently encourage people to upgrade to more scalable models right away
 without forcing them to do so.
 Developers, miners, and the community have accrued significant
 experience deploying soft forks, and we believe segwit can be deployed
 at least as fast, and probably more securely, than a hard fork that
 increases the maximum block size.
 ## Will there be a hard fork before or as part of the segregated witness implementation?  {#pre-segwit-fork}
 No. That is not part of the [roadmap][].
 [roadmap]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/011865.html
 ## If there's eventually going to be a hard fork, why not do it now? {#why-not-now}
 We currently have the ability to increase the capacity of the
 system through soft forks that have widespread consensus without any
 of the complications of a hard fork, as described in an [earlier
 question][q simple raise], so the expectation that there will be an
 eventual hard fork is not sufficient reason to attempt one now.
 In addition to giving us extra transaction capacity, the improvements
 proposed in the roadmap (combined with other technology such as
 bi-directional payment channels) give users the ability to reduce the
 amount of blockchain space they use on average---effectively increasing
 the capacity of the Bitcoin system without increasing the amount of full
 node bandwidth used.
 For example,
 - [BIP68][] and [BIP112][] allow bi-directional payment channels to stay open
  indefinitely, which we expect to vastly reduce the number of payment
  channel transactions that need to be committed to the blockchain.
 - Segregated witness allows a payment channel close transaction to be
  combined with a payment channel open transaction, reducing the
  blockchain space used to change channels by about 66%.
 - Segregated witness allows soft forks to change the Bitcoin Script
  language in ways that could reduce the average size of a transaction,
  such as using public-key-recovery-from-signatures or Schnorr combined
  signatures.
 - Segregated witness permits the creation of compact fraud proofs that
  may bring the security of Simplified Payment Verification (SPV)
  lightweight clients up near to that of full nodes, which may allow the
  network to function well with fewer full nodes than it can under
  currently-deployed technology.
 The actual effect of these technologies is unknown, but scaling now with
 a soft fork that has wide consensus allows us to obtain the immediate
 gains, test and measure the mid-term possibilities, and use that data to
 formulate long-term plans.
 ## How will segregated witness transactions work for wallets?  {#segwit-in-wallets}
 Wallets that currently support P2SH can migrate to full segregated
 witness in two phases:
 - Phase 1: Scripts are hashed twice, first to 256 bits and then to 160
  bits. The 160 bit hash will be compatible with existing P2SH
  addresses, so upgraded wallets will be able to send and receive
  bitcoins to and from currently existing wallets.
 - Phase 2: Scripts are hashed once to 256 bits. This format will not be
  compatible with existing wallets but will allow more efficient use of
  block space and will offer better security due to greater collision
  resistance.
 ## If no one is forced to upgrade, why will anyone bother to upgrade? I heard P2SH took almost two years to become widely deployed.  {#why-upgrade}
 Each byte of the witness part of a segregated witness (segwit)
 transaction will only count as 0.25 bytes towards the size of the
 transaction. Since transaction fees are based on the size of a
 transaction, this is effectively a 75% discount on fees for that part of
 a transaction---but only for people who use segwit.
 David Harding provided a table of [estimated savings][] at various
 fee/transaction levels. That is, if the fee for a typical 250-byte
 transaction is $0.01 USD, using segwit will save about $0.003 when
 spending a P2PK-in-P2SH transaction output.
 | Transaction | Bytes saved | $0.01/250B | $0.05/250B | $0.25/250B | $1.00/250B |
 |-------------|-------------|------------|------------|------------|------------|
 | P2PK-in-P2SH |  79/107 | $0.003 | $0.015 | $0.079 | $0.316 |
 | 1-of-1 P2SH multisig | 83/112 | $0.003 | $0.016 | $0.083 | $0.332 |
 | 2-of-2 P2SH multisig | 163/219 | $0.006 | $0.032 | $0.163 | $0.652 |
 | 2-of-3 P2SH multisig | 189/254 | $0.007 | $0.037 | $0.189 | $0.756 |
 (We don't expect fees to get as high as the highest seen in this
 table; they are just provided for reference.)
 Web wallets and exchanges that send large numbers of transactions each
 day at fixed rates (such as for free or for 1% per spend) are expected
 to be early adopters---even the small savings per spend seen in the
 table above will add up to significant amounts of money if repeated hundreds
 or thousands of times a day.
 ## I heard you were breaking zero-confirmation transactions. Which technology in the scaling roadmap is doing that?  {#rbf}
 None of them. By default, current versions of Bitcoin Core won't
 replace an unconfirmed transaction with another transaction that spends
 any of the same inputs. Some people think this means the first
 transaction they see that spends a particular input is safe, but this is
 untrue. (If it were true, we wouldn't need the blockchain.)
 This current default policy does mean that people who want to be able to
 update their unconfirmed transactions can't do that. The original
 version of Bitcoin provided people with a way to indicate that they
 wanted to be able to update their transactions, but Nakamoto had to
 disable it in 2010 to prevent denial-of-service attacks.
 Recent Bitcoin Core developers realized that they could prevent the
 DOS attack by requiring updated transactions pay extra fees, and they've
 re-enabled Nakamoto's mechanism for indicating when a transactions can
 be replaced. This feature is planned for Bitcoin Core 0.12.0 (expected
 Jan/Feb 2016) but, like Nakamoto's original feature, is opt-in so
 people who want to be able to replace their transactions have to use a
 wallet that supports that feature.
 Currently there are no wallets that provide this feature, but wallets
 that do provide it in the future may be able to combine multiple
 transactions together to reduce the amount of blockchain space they use
 as well as increase the fees they pay on transactions that are taking a
 long time to confirm, helping to prevent transactions from getting
 “stuck” (a known usability problem).
 ## Weak blocks and IBLTs just say “2016” in the roadmap schedule. Does this mean you have no idea when they'll be available?  {#weak-blocks-iblts}
 [Weak blocks and IBLTs][] are two separate technologies that are still being
 [actively studied][] to choose the right parameters, but the number of
 developers working on them is limited and so it's difficult to guess
 when they'll be deployed.
 Weak blocks and IBLTs can both be deployed as network-only enhancements
 (no soft or hard fork required) which means that there will probably
 only be a short time from when testing is completed to when their
 benefits are available to all upgraded nodes. We hope this will happen
 within 2016.
 After deployment, both weak blocks and IBLTs may benefit from a simple
 non-controversial soft fork ([canonical transaction ordering][]), which
 should be easy to deploy using the [BIP9][] versionBits system described
 elsewhere in this FAQ.
 [canonical transaction ordering]: https://gist.github.com/gavinandresen/e20c3b5a1d4b97f79ac2#canonical-ordering-of-transactions
 ## “Why would miners adopt the SegWit format, given that it does not provide any savings of bandwidth, storage, or processing time to them?” {#why-mine-segwit}
 Most [previous soft forks][] have not provided these benefits to miners
 either. For example,
 | [BIP16][] (P2SH) | New transaction type |
 | [BIP30][] (duplicate txids) | Required checking for duplicate txids |
 | [BIP34][] (height in coinbase) | Reduced miner coinbase space by 4 bytes |
 | [BIP65][] (OP_CLTV) | New opcode |
 The [BIP66][] (strict DER) soft fork which activated in July 2015 will
 soon be providing reduced processing time by making it possible to
 switch to libsecp256k1 for validation as described elsewhere is this
 FAQ. The reduced validation time makes it uncommon among soft
 forks in providing direct benefits to miners.
 What segregated witness (segwit) does is provide several major benefits
 to anyone who uses it to create transactions:
 A permanent fix for third-party malleability, allowing multi-stage
 smart contracts to flourish. A modest reduction in fees. Easy future
 upgrades to Bitcoin Script, so wallets can more easily gain access to
 new features.
 Through the previous soft forks, and through conversations such as the
 [Miners' Panel][] at Scaling Bitcoin Hong Kong, miners have
 repeatedly shown that they want Bitcoin to be the most useful system
 possible even if they don't receive any direct benefits. Segwit and
 the other improvements in the roadmap provide significant usability
 enhancements.
 In addition, segwit allows miners to put more transactions in their
 blocks, which may allow them to increase their per-block revenue.
 ## How can I help?
 Start by reading the [Bitcoin Core contributor][] pages on Bitcoin.org.
 In particular, [code review][] is a critical part of getting soft forks
 deployed.
 To get specific suggestions on how you can help, please join the
 [#bitcoin-dev][] IRC channel.
 [#bitcoin-dev]: https://webchat.freenode.net/?channels=bitcoin-dev&amp;uio=d4
 [actively studied]: http://diyhpl.us/wiki/transcripts/scalingbitcoin/bitcoin-block-propagation-iblt-rusty-russell/
 [bip-segwit]: https://github.com/jl2012/bips/blob/segwit/bip-segwit.mediawiki
 [BIP9]: https://github.com/bitcoin/bips/blob/master/bip-0009.mediawiki
 [BIP16]: https://github.com/bitcoin/bips/blob/master/bip-0016.mediawiki
 [BIP30]: https://github.com/bitcoin/bips/blob/master/bip-0030.mediawiki
 [BIP34]: https://github.com/bitcoin/bips/blob/master/bip-0034.mediawiki
 [BIP50]: https://github.com/bitcoin/bips/blob/master/bip-0050.mediawiki
 [BIP65]: https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki
 [BIP66]: https://github.com/bitcoin/bips/blob/master/bip-0066.mediawiki
 [BIP68]: https://github.com/bitcoin/bips/blob/master/bip-0068.mediawiki
 [BIP112]: https://github.com/bitcoin/bips/blob/master/bip-0112.mediawiki
 [BIP113]: https://github.com/bitcoin/bips/blob/master/bip-0113.mediawiki
 [bitcoin core contributor]: /en/bitcoin-core/
 [Bitcoin relay network]: http://bitcoinrelaynetwork.org/
 [code review]: https://bitcoin.org/en/development#code-review
 [estimated savings]: https://www.reddit.com/r/bitcoinxt/comments/3w1i6b/i_attended_scaling_bitcoin_hong_kong_these_are_my/cxtkaih
 [increase in total bandwidth]: https://scalingbitcoin.org/hongkong2015/presentations/DAY1/3_block_propagation_1_rosenbaum.pdf
 [libsecp256k1]: https://github.com/bitcoin/secp256k1
 [libsecp256k1 verification]: https://github.com/bitcoin/bitcoin/pull/6954
 [max_block_size]: https://github.com/bitcoin/bitcoin/blob/3038eb63e8a674b4818cb5d5e461f1ccf4b2932f/src/consensus/consensus.h#L10
 [miners' panel]: https://youtu.be/H-ErmmDQRFs?t=1086
 [payment channel efficiency]: https://scalingbitcoin.org/hongkong2015/presentations/DAY2/1_layer2_2_dryja.pdf
 [previous soft forks]: https://github.com/bitcoin/bips/blob/master/bip-0123.mediawiki#classification-of-existing-bips
 [weak blocks and iblts]: https://www.youtube.com/watch?v=ivgxcEOyWNs&t=1h40m20s
 [q simple raise]: #size-bump
--- a/en/bitcoin-core/capacity-increases.md
+++ b/en/bitcoin-core/capacity-increases.md
@ -0,0 +1,36 @@
 ---
 # This file is licensed under the MIT License (MIT) available on
 # http://opensource.org/licenses/MIT.
 layout: base-core
 lang: en
 id: bitcoin-core-capacity-increases
 columns: 1
 title: Capacity increases for the Bitcoin system -- Bitcoin Core
 breadcrumbs:
  - bitcoin
  - bcc
  - Capacity increases
 ---
 # Capacity increases for the Bitcoin system
 We, the undersigned, support the roadmap in [Capacity increases for the
 Bitcoin system.][1]  We have been working on
 scalability for several years within the Bitcoin Core project and
 consider this the best possible continuation of our efforts.
 For more information, please see the
 [FAQ](/en/bitcoin-core/capacity-increases-faq).
 {% include bitcoin-core/capability-increases-sigs.md %}
 ---
 Other versions of this page:
 - [简体中文](/zh_CN/bitcoin-core/capacity-increases)
 - [繁體中文](/zh_TW/bitcoin-core/capacity-increases)
 Signatures may be added to Bitcoin.org pull request [#1165](https://github.com/bitcoin-dot-org/bitcoin.org/pull/1165)
 [1]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/011865.html
--- a/en/bitcoin-core/index.md
+++ b/en/bitcoin-core/index.md
@ -91,6 +91,7 @@ breadcrumbs:
 {% endcapture %}
 {% assign array_releases = text_releases | strip_newlines | split: '::' %}
  - 2015-12-21 - Capacity increases for the Bitcoin system: [Statement](/en/bitcoin-core/capacity-increases) & [FAQ](/en/bitcoin-core/capacity-increases-faq)
 {% comment %}<!-- show the latest three releases -->{% endcomment %}
 {% for release in array_releases %}
 {% if forloop.index <= 3 %}
--- a/en/full-node.md
+++ b/en/full-node.md
@ -1396,5 +1396,93 @@ ask for help on sites like [SuperUser](http://superuser.com).
 We can't provide direct support, but if you see a way to improve these
 instructions, please [open an issue.](https://github.com/bitcoin-dot-org/bitcoin.org/issues/new)
 ## Configuration Tuning
 This section contains advice about how to change your Bitcoin Core
 configuration to adapt it to your needs.
 There are two ways to change your configuration.  The first is to start
 Bitcoin Core with the options you want.  For example, if you want to
 limit it to using one CPU core for signature verification, you can start
 Bitcoin Core like this:
 {% highlight bash %}
 ## Bitcoin Core daemon
 bitcoind -par=1 -daemon
 ## Bitcoin Core GUI
 bitcoin-qt -par=1
 {% endhighlight %}
 Once you've decided you like an option, you can add it to the Bitcoin
 Core configuration file.  You can find that file in the following
 directories:
 - Windows: %APPDATA%\Bitcoin\
 - OSX: $HOME/Library/Application Support/Bitcoin/
 - Linux: $HOME/.bitcoin/
 To add an option to the configuration file, just remove its leading
 dash.  You may also need to remove any quotation marks you used in your shell.
 For example, the `-par` option seen above would look like this in the
 configuration file:
 {% highlight text %}
 par=1
 {% endhighlight %}
 If you have any questions about configuring Bitcoin Core, please stop by
 one of our [forums](/en/bitcoin-core/help#forums) or [live
 chatrooms](/en/bitcoin-core/help#live).
 ### Reduce Traffic
 Some node operators need to deal with bandwith caps imposed by their ISPs.
 By default, bitcoin-core allows up to 125 connections to different peers, 8 of
 which are outbound. You can therefore, have at most 117 inbound connections.
 The default settings can result in relatively significant traffic consumption.
 Ways to reduce traffic:
 #### Maximum Upload Targets
 {% highlight text %}
 -maxuploadtarget=<MiB per day>
 {% endhighlight %}
 A major component of the traffic is caused by serving historic blocks to other nodes
 during the initial blocks download phase (syncing up a new node).
 This option can be specified in MiB per day and is turned off by default.
 This is *not* a hard limit; only a threshold to minimize the outbound
 traffic. When the limit is about to be reached, the uploaded data is cut by no
 longer serving historic blocks (blocks older than one week).
 Keep in mind that new nodes require other nodes that are willing to serve
 historic blocks. **The recommended minimum is 144 blocks per day (max. 144MB
 per day)**
 #### Disable listening
 {% highlight text %}
 -listen=0
 {% endhighlight %}
 Disabling listening will result in fewer nodes connected (remember the maximum of 8
 outbound peers). Fewer nodes will result in less traffic usage as you are relaying
 blocks and transactions to fewer nodes.
 #### Reduce maximum connections
 {% highlight text %}
 -maxconnections=<num>
 {% endhighlight %}
 Reducing the maximum connected nodes to a miniumum could be desirable if traffic
 limits are tiny. Keep in mind that bitcoin's trustless model works best if you are
 connected to a handful of nodes.
 </div>
 <script>updateToc();</script>
--- a/img/dev/en-p2p-control-messages.dot
+++ b/img/dev/en-p2p-control-messages.dot
@ -17,6 +17,7 @@ getaddr -> addr;
 filterload -> filteradd;
 filterload -> filterclear;
 alert;
 sendheaders;
 ERROR [ style = "invis" ];
 ERROR -> reject [ style = "invis" ];
--- a/img/dev/en-p2p-control-messages.png
+++ b/img/dev/en-p2p-control-messages.png
--- a/img/dev/en-p2p-control-messages.svg
+++ b/img/dev/en-p2p-control-messages.svg
@ -1,91 +1,96 @@
 <?xml version="1.0" encoding="UTF-8" standalone="no"?>
 <!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN"
 "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">
-<!-- Generated by graphviz version 2.26.3 (20100126.1600)
+<!-- Generated by graphviz version 2.38.0 (20140413.2041)
 -->
-<!-- Title: _anonymous_0 Pages: 1 -->
+<!-- Title: %3 Pages: 1 -->
-<svg width="450pt" height="134pt"
+<svg width="450pt" height="97pt"
- viewBox="0.00 0.00 450.00 134.16" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink">
+ viewBox="0.00 0.00 450.00 96.70" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink">
-<g id="graph1" class="graph" transform="scale(0.931677 0.931677) rotate(0) translate(4 140)">
+<g id="graph0" class="graph" transform="scale(0.690714 0.690714) rotate(0) translate(4 136)">
-<title>_anonymous_0</title>
+<title>%3</title>
-<polygon fill="white" stroke="white" points="-4,5 -4,-140 480,-140 480,5 -4,5"/>
+<polygon fill="white" stroke="none" points="-4,4 -4,-136 647.5,-136 647.5,4 -4,4"/>
-<text text-anchor="middle" x="237.5" y="-25.4" font-family="Sans" font-size="14.00"> </text>
+<text text-anchor="middle" x="321.75" y="-22.8" font-family="Sans" font-size="14.00"> </text>
-<text text-anchor="middle" x="237.5" y="-8.4" font-family="Sans" font-size="14.00">Overview Of P2P Protocol Control And Advisory Messages</text>
+<text text-anchor="middle" x="321.75" y="-7.8" font-family="Sans" font-size="14.00">Overview Of P2P Protocol Control And Advisory Messages</text>
 <!-- version -->
 <g id="node1" class="node"><title>version</title>
-<polygon fill="none" stroke="black" stroke-width="1.75" points="66,-136 2.84217e-14,-136 0,-100 66,-100 66,-136"/>
+<polygon fill="none" stroke="black" stroke-width="1.75" points="71,-132 0,-132 0,-96 71,-96 71,-132"/>
-<text text-anchor="middle" x="33" y="-113.9" font-family="Sans" font-size="14.00">version</text>
+<text text-anchor="middle" x="35.5" y="-110.3" font-family="Sans" font-size="14.00">version</text>
 </g>
 <!-- verack -->
-<g id="node3" class="node"><title>verack</title>
+<g id="node2" class="node"><title>verack</title>
-<polygon fill="none" stroke="black" stroke-width="1.75" points="64,-78 2,-78 2,-42 64,-42 64,-78"/>
+<polygon fill="none" stroke="black" stroke-width="1.75" points="68,-74 3,-74 3,-38 68,-38 68,-74"/>
-<text text-anchor="middle" x="33" y="-55.9" font-family="Sans" font-size="14.00">verack</text>
+<text text-anchor="middle" x="35.5" y="-52.3" font-family="Sans" font-size="14.00">verack</text>
 </g>
 <!-- version&#45;&gt;verack -->
-<g id="edge2" class="edge"><title>version&#45;&gt;verack</title>
+<g id="edge1" class="edge"><title>version&#45;&gt;verack</title>
-<path fill="none" stroke="black" stroke-width="1.75" d="M33,-99.9664C33,-93.0495 33,-85.1566 33,-78.2222"/>
+<path fill="none" stroke="black" stroke-width="1.75" d="M35.5,-95.8939C35.5,-88.9462 35.5,-80.9383 35.5,-74.0014"/>
 </g>
 <!-- ping -->
-<g id="node4" class="node"><title>ping</title>
+<g id="node3" class="node"><title>ping</title>
-<polygon fill="none" stroke="black" stroke-width="1.75" points="134,-136 80,-136 80,-100 134,-100 134,-136"/>
+<polygon fill="none" stroke="black" stroke-width="1.75" points="139.5,-132 85.5,-132 85.5,-96 139.5,-96 139.5,-132"/>
-<text text-anchor="middle" x="107" y="-113.9" font-family="Sans" font-size="14.00">ping</text>
+<text text-anchor="middle" x="112.5" y="-110.3" font-family="Sans" font-size="14.00">ping</text>
 </g>
 <!-- pong -->
-<g id="node6" class="node"><title>pong</title>
+<g id="node4" class="node"><title>pong</title>
-<polygon fill="none" stroke="black" stroke-width="1.75" points="134,-78 80,-78 80,-42 134,-42 134,-78"/>
+<polygon fill="none" stroke="black" stroke-width="1.75" points="139.5,-74 85.5,-74 85.5,-38 139.5,-38 139.5,-74"/>
-<text text-anchor="middle" x="107" y="-55.9" font-family="Sans" font-size="14.00">pong</text>
+<text text-anchor="middle" x="112.5" y="-52.3" font-family="Sans" font-size="14.00">pong</text>
 </g>
 <!-- ping&#45;&gt;pong -->
-<g id="edge4" class="edge"><title>ping&#45;&gt;pong</title>
+<g id="edge2" class="edge"><title>ping&#45;&gt;pong</title>
-<path fill="none" stroke="black" stroke-width="1.75" d="M107,-99.9664C107,-93.0495 107,-85.1566 107,-78.2222"/>
+<path fill="none" stroke="black" stroke-width="1.75" d="M112.5,-95.8939C112.5,-88.9462 112.5,-80.9383 112.5,-74.0014"/>
 </g>
 <!-- getaddr -->
-<g id="node7" class="node"><title>getaddr</title>
+<g id="node5" class="node"><title>getaddr</title>
-<polygon fill="none" stroke="black" stroke-width="1.75" points="218,-136 148,-136 148,-100 218,-100 218,-136"/>
+<polygon fill="none" stroke="black" stroke-width="1.75" points="227.5,-132 153.5,-132 153.5,-96 227.5,-96 227.5,-132"/>
-<text text-anchor="middle" x="183" y="-113.9" font-family="Sans" font-size="14.00">getaddr</text>
+<text text-anchor="middle" x="190.5" y="-110.3" font-family="Sans" font-size="14.00">getaddr</text>
 </g>
 <!-- addr -->
-<g id="node9" class="node"><title>addr</title>
+<g id="node6" class="node"><title>addr</title>
-<polygon fill="none" stroke="black" stroke-width="1.75" points="210,-78 156,-78 156,-42 210,-42 210,-78"/>
+<polygon fill="none" stroke="black" stroke-width="1.75" points="217.5,-74 163.5,-74 163.5,-38 217.5,-38 217.5,-74"/>
-<text text-anchor="middle" x="183" y="-55.9" font-family="Sans" font-size="14.00">addr</text>
+<text text-anchor="middle" x="190.5" y="-52.3" font-family="Sans" font-size="14.00">addr</text>
 </g>
 <!-- getaddr&#45;&gt;addr -->
-<g id="edge6" class="edge"><title>getaddr&#45;&gt;addr</title>
+<g id="edge3" class="edge"><title>getaddr&#45;&gt;addr</title>
-<path fill="none" stroke="black" stroke-width="1.75" d="M183,-99.9664C183,-93.0495 183,-85.1566 183,-78.2222"/>
+<path fill="none" stroke="black" stroke-width="1.75" d="M190.5,-95.8939C190.5,-88.9462 190.5,-80.9383 190.5,-74.0014"/>
 </g>
 <!-- filterload -->
-<g id="node10" class="node"><title>filterload</title>
+<g id="node7" class="node"><title>filterload</title>
-<polygon fill="none" stroke="black" stroke-width="1.75" points="311,-136 235,-136 235,-100 311,-100 311,-136"/>
+<polygon fill="none" stroke="black" stroke-width="1.75" points="371,-132 288,-132 288,-96 371,-96 371,-132"/>
-<text text-anchor="middle" x="273" y="-113.9" font-family="Sans" font-size="14.00">filterload</text>
+<text text-anchor="middle" x="329.5" y="-110.3" font-family="Sans" font-size="14.00">filterload</text>
 </g>
 <!-- filteradd -->
-<g id="node12" class="node"><title>filteradd</title>
+<g id="node8" class="node"><title>filteradd</title>
-<polygon fill="none" stroke="black" stroke-width="1.75" points="304,-78 230,-78 230,-42 304,-42 304,-78"/>
+<polygon fill="none" stroke="black" stroke-width="1.75" points="317,-74 238,-74 238,-38 317,-38 317,-74"/>
-<text text-anchor="middle" x="267" y="-55.9" font-family="Sans" font-size="14.00">filteradd</text>
+<text text-anchor="middle" x="277.5" y="-52.3" font-family="Sans" font-size="14.00">filteradd</text>
 </g>
 <!-- filterload&#45;&gt;filteradd -->
-<g id="edge8" class="edge"><title>filterload&#45;&gt;filteradd</title>
+<g id="edge4" class="edge"><title>filterload&#45;&gt;filteradd</title>
-<path fill="none" stroke="black" stroke-width="1.75" d="M271.134,-99.9664C270.419,-93.0495 269.602,-85.1566 268.885,-78.2222"/>
+<path fill="none" stroke="black" stroke-width="1.75" d="M313.616,-95.8939C307.164,-88.9462 299.728,-80.9383 293.287,-74.0014"/>
 </g>
 <!-- filterclear -->
-<g id="node14" class="node"><title>filterclear</title>
+<g id="node9" class="node"><title>filterclear</title>
-<polygon fill="none" stroke="black" stroke-width="1.75" points="400,-78 318,-78 318,-42 400,-42 400,-78"/>
+<polygon fill="none" stroke="black" stroke-width="1.75" points="420,-74 331,-74 331,-38 420,-38 420,-74"/>
-<text text-anchor="middle" x="359" y="-55.9" font-family="Sans" font-size="14.00">filterclear</text>
+<text text-anchor="middle" x="375.5" y="-52.3" font-family="Sans" font-size="14.00">filterclear</text>
 </g>
 <!-- filterload&#45;&gt;filterclear -->
-<g id="edge10" class="edge"><title>filterload&#45;&gt;filterclear</title>
+<g id="edge5" class="edge"><title>filterload&#45;&gt;filterclear</title>
-<path fill="none" stroke="black" stroke-width="1.75" d="M299.74,-99.9664C310.094,-92.983 321.924,-85.0048 332.277,-78.0225"/>
+<path fill="none" stroke="black" stroke-width="1.75" d="M343.551,-95.8939C349.258,-88.9462 355.836,-80.9383 361.535,-74.0014"/>
 </g>
 <!-- alert -->
-<g id="node15" class="node"><title>alert</title>
+<g id="node10" class="node"><title>alert</title>
-<polygon fill="none" stroke="black" stroke-width="1.75" points="385,-136 331,-136 331,-100 385,-100 385,-136"/>
+<polygon fill="none" stroke="black" stroke-width="1.75" points="439.5,-132 385.5,-132 385.5,-96 439.5,-96 439.5,-132"/>
-<text text-anchor="middle" x="358" y="-113.9" font-family="Sans" font-size="14.00">alert</text>
+<text text-anchor="middle" x="412.5" y="-110.3" font-family="Sans" font-size="14.00">alert</text>
 </g>
 <!-- sendheaders -->
 <g id="node11" class="node"><title>sendheaders</title>
 <polygon fill="none" stroke="black" stroke-width="1.75" points="563.5,-132 453.5,-132 453.5,-96 563.5,-96 563.5,-132"/>
 <text text-anchor="middle" x="508.5" y="-110.3" font-family="Sans" font-size="14.00">sendheaders</text>
 </g>
 <!-- ERROR -->
 <!-- reject -->
-<g id="node18" class="node"><title>reject</title>
+<g id="node13" class="node"><title>reject</title>
-<polygon fill="none" stroke="black" stroke-width="1.75" points="470,-78 414,-78 414,-42 470,-42 470,-78"/>
+<polygon fill="none" stroke="black" stroke-width="1.75" points="640,-74 581,-74 581,-38 640,-38 640,-74"/>
-<text text-anchor="middle" x="442" y="-55.9" font-family="Sans" font-size="14.00">reject</text>
+<text text-anchor="middle" x="610.5" y="-52.3" font-family="Sans" font-size="14.00">reject</text>
 </g>
 <!-- ERROR&#45;&gt;reject -->
 </g>
--- a/img/wallet/greenbits.png
+++ b/img/wallet/greenbits.png
--- a/jonasschnelli.asc
+++ b/jonasschnelli.asc
@ -0,0 +1,63 @@
 -----BEGIN PGP PUBLIC KEY BLOCK-----
 Version: GnuPG v1
 mQINBFVe7qQBEADBH9yDSQmNrq7VhOgQz6BI449kroGfvjnLRy9/r5gVV58twxqd
 QLIj78NZmE74P+Kbnr0wCltPPWp1osTngqHPYK04kGVY/xyOWdVn3mEEr5n0I66T
 rR1cjsPJJGfcNWvI2liNEJ77xIFNAlKPxvQkSTlVVg9hQ4hzcvqDssEvb/JzFXct
 UVND8D0sYF6/vLZ6aALuWqQ8+gNTW8l47U3gbScWwjG6aXzWl+CL/ZoxsYXyXstU
 AjyoxzRzhECMv/JM/NVfmqrn7MBpcxzKGDLKo6+VeUIb1qKyeY8ISJKHGYu8Z8Z0
 +aL5qnFk1Rbffzi9Vw7HOXVVxTqxVlPfT9olprxHFmoLpLmQ6vu487wIPXAHWtfM
 PxIDgB1yr1LA6RUTtB+dCLr4EiB2uwspR+Da8GNyAD8iwsROWenbv3abfDTU4p7b
 /D1Src3jmVZVM1XHZRxtYAjPpvBagwMnUM0HhdAdvkCD5UjuUgavjkSniiE58hyk
 EIxrVZUbJNihAVzrqY9nYyi0AM4e2Aambq9nIkSnapaPRq360N6l/RsU8eYYaFWP
 43gdMFYzOy7ewsICHdBZK2v6CR99SXYKx0ZjdEvqRWQIJbSj+j5XSZzxlXyQC0U/
 JgaWWw/0cS+N5eQeD4MC9EVmFI8jWbEaQaCBmUS0epn0uh+hyj3B50Ik8QARAQAB
 tCVKb25hcyBTY2huZWxsaSA8ZGV2QGpvbmFzc2NobmVsbGkuY2g+iQI+BBMBAgAo
 BQJVXu6kAhsDBQkJZgGABgsJCAcDAgYVCAIJCgsEFgIDAQIeAQIXgAAKCRAp1Ly2
 QW9T7K2OEADBCpMrulKNJIr3VBkC+xX4KA0DMLwDJ1x2lYCcmmwT6fDvqycB7Exy
 0N9p7249IZJUz08CCi5SDZgnE131HM8K/uO/Hdt687cCs1nG90pJd989XO3TWPnf
 P338u2Z6/mukhw1CTaeoveJlpnk7tXGt7yQfkrGdwUJTGWdf+y0vP1Y6acg3Vfmp
 WreVLOHzG+bsO7I6aLVn3gYcJbgEc3rDG1edeph4jjmM9xu4lYLw/yq02JxnQ3Zc
 uOkCgtK9DrxVOu+8s3RfYdP06X3Lm3ut7wk8RjnZO+s8ItjPiFAPR897fDXguRx1
 tZOMnBDdjspZ3rtI6f6XxUM+PaNPTIMEMbZhrMHIupXb1KBeb1ax9hdgXgUH01IC
 lusCaFNZVrgrgMVesu9wilohHgiLclBkNqDa07VVODEX7XRLrqqvBfBrAFsZ8NVy
 FaBKL1PWE2fbCAvKmws3VkPLuLE8IP5Icd3GBM3zK/79Y1E1n4u1Qo0IgEdCZQF6
 w1837A6u86hY8A/peOVQiUDZEgfrMpw1sNtriOPHUQ2IcCVqlXHM9NCJN+PRMNFc
 F2NuiKzBd+Q3vq6kd2B0x14XP2GIfQ9JvEBOaWYDs2uwQ0cunz1IH+CcZPYj+Us/
 n8Oyg3dC/wYKjLtpQ0NPtpuLUB6gFVXJ7ZwAvd36EM+A7MkeN/R4kYkCHAQQAQIA
 BgUCVkXIXgAKCRAicOMMUic59m0aD/9/jFA+9LqBB0iix6xXjnwu0hSeup0/H/w8
 achuQ5tLON68SiPdFD4Ps8e8XnuWPqbjloFOvqG5cLZFDM4iNFcz11iLpJVnNDXG
 eMx6nvbKVVhrBBLdUF65BuFTYGBhN4trnn7SwcED+Ff258ftrdS9JOC+yxfjhIfm
 YaDaHgjc77hw1AgN/8bvGTOQkpxCYBNGYhHXQlpoEq3HglU1XMJZM6kSpbr9ADxf
 3gtqkrxGH+aErJ3fy/cIQcjuEfR7HSjaY4WQCw9jW+9/FbMYoyiUmnVv/UU9xvsW
 X6cKiqV+e/RwKdlixC9hes6z/UqPRqe/3JGK60SnYPJoCeFp1p2sWlaNdA1R5i0W
 UnVoL7oc7/+7DaykoWpxDi1O+70eAck7WCcZOyYOyTBeoc5g28f1CO3CWE+E5ZB0
 eAs+tYGJQG+RP0fy6g1EZaDRUYDgnnUiRGHRnKguZGB6OmPtI6nAtfqB6amufRnh
 +CiErKPrPj8GinaCWJdI8Hfup26foz3aDyZKTFoRcXZnIhd15VFPpeCn7OgYM1sw
 bc+WFmIUUK8fceTyj3MDP/rl17oP7XgQdiNYFEp+7uNovZFLBRJHBEABgrC7qSBH
 Lwbv7hKKG5IdPaT/3SKXqLCnNd3JjupBdYZXF+uYZZkthPS7t34RnWlzTZQpgIWm
 2VUIhm1pArkCDQRVXu6kARAAqlYWgKoUWpDnEfr5MW9tQVYFvV1bLz0YxcKSaoCy
 jLxKzZG7yA27Lte3iXV1CFWk3RBaK5UaQQ5/Y+ZdCGcuq5pLPtctmON07kTeRjNz
 A6khtvZMJYfhBC0cSi2jBGyVABcBnneM3240gRAcI88E2hyPQItCZmX5q/UypEmt
 FxjOCQ8izfiYGjqJWhGsPkKRKiFvPTUExYlkuTQT4m9qUwvv622LC76Aj3S5EaIo
 TPnGwMy3LHSYBwCb78SNy5BuEasPqnt0sq/2e5RT9Pvjc3YugNMEzO9f8leOhD+5
 LWfO6Imtz+9gerL265yC+K5hYUf9D4uHAyvq2MlhSI3gkhDzk4u+rqDvVGelbPLd
 x7bkcvVhZss27OLxkogH+wvgtcbaJPDBIWS1WN8BzjM/9ValELlVvEbvpq1GQ8tq
 2ADpvaxrCBDov/tcHlZ3kXRslzed3A8EqiwUVeDM4GA6QjqRgRFCjyHYbNZ9Twtb
 GXRrjbRkcR9RmhiaK2D968De/7bcWsIwaDrZx03NTn+aqxDkdaS1NDkFlBnKflRP
 fOk0I5XJ5lz97PMZdxZsRc4tDANyiXGNq0sQPd40DU4xAPxL74U88YK6QjMLJiI+
 rj3MkJMwJZ3epO3YHB5r3E5Ceh60JNT2Chf94QaP/XNAMBcIY5WB13fhWs5fiq2m
 ancAEQEAAYkCJQQYAQIADwUCVV7upAIbDAUJCWYBgAAKCRAp1Ly2QW9T7GPxD/9U
 3MVgz+TIdJrTGKjh7y8FkDa+ZHwgRSa05JHOvjztnxbV1qkbFHs4tDnahZ1FlWkb
 UHmsK4m2xZuN1j3hjxGlw7oUF6ad4Z5sGG5QpzrSrARqdidm9r08QU3IHOmPfGTc
 yzsrg7Z1lNxc8aP6GV6n1OOjT2ySWpsp+BbZ8JS7YQpdbBSudnYtm1v9hrxY8Kux
 skWT5ZusuFa3uMixp1WXgB9uVyAEZvxo33wbGdg6H5MZIwm2rU1J9yFDAseulM9i
 bgxwDA4EFgN0D6KTf/94tvBGJf2zMWTrnyn7gsSswEkAout5KW4GSo4bcDNPbYd1
 9++XwbZThaE88bfc3NaiZv7AqiGOPMxVSXFhEI7nvCRRGoRb3/5riuK4FYZCqpGx
 bXAcQy7WVh0CEsnl/Sze8799V7jeS1pc2NbqT6ZcOUh0qRCBDvfqwGTcMBRz5hyZ
 aZK0+vX5O1P3V4LbcYtY/uBUOc0YQ4E6xzBT6bVsQ4k3Z24AwlJErtTSvaKmZEoN
 zAr1eZWklxN498HaX5PdF0cRkg6VpMQsRfpYl+lTgpzUol4p2n6X2B/YkPx45kCX
 DEDivbDHLOgJWDUGTdeIF+gjsaXvxbKyn78KFBwSs8lYRSCUF+sRKmqaPEf+pLLr
 KPI2Z3gDPaKLsjNYgt+6F5lHh2uMdCPqYIBLmujAsQ==
 =xtTA
 -----END PGP PUBLIC KEY BLOCK-----
--- a/zh_CN/bitcoin-core/capacity-increases.md
+++ b/zh_CN/bitcoin-core/capacity-increases.md
@ -0,0 +1,30 @@
 ---
 # This file is licensed under the MIT License (MIT) available on
 # http://opensource.org/licenses/MIT.
 layout: base-core
 lang: zh_CN
 id: bitcoin-core-capacity-increases
 columns: 1
 title: 比特币系统扩展
 breadcrumbs:
  - bitcoin
  - bcc
  - Capacity increases
 ---
 # 比特币系统扩展
 我们连署支持 [比特币系统扩展][1] 路线图。我们已在Bitcoin Core计划内为可扩展性工作多年，认为这是最可以延续我们一直以来努力的方向。
 有关更多详情请参阅 [常见问题解答][FAQ]，中文版本正在准备中。
 {% include bitcoin-core/capability-increases-sigs.md %}
 ---
 如果你想参与连署，请到[#1165](https://github.com/bitcoin-dot-org/bitcoin.org/pull/1165)。
 [1]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/011865.html
 [FAQ]: /en/bitcoin-core/capacity-increases-faq
--- a/zh_TW/bitcoin-core/capacity-increases.md
+++ b/zh_TW/bitcoin-core/capacity-increases.md
@ -0,0 +1,29 @@
 ---
 # This file is licensed under the MIT License (MIT) available on
 # http://opensource.org/licenses/MIT.
 layout: base-core
 lang: zh_TW
 id: bitcoin-core-capacity-increases
 columns: 1
 title: 比特幣系統擴展
 breadcrumbs:
  - bitcoin
  - bcc
  - Capacity increases
 ---
 # 比特幣系統擴展
 我們連署支持[比特幣系統擴展][1]路線圖。我們已在Bitcoin
 Core計劃內為可擴展性工作多年，認為這是最可以延續我們一直以來努力的方向。
 有關更多詳情請參閱 [常見問題解答][FAQ]，中文版本正在準備中。
 {% include bitcoin-core/capability-increases-sigs.md %}
 ---
 如果你想參與連署，請到[#1165](https://github.com/bitcoin-dot-org/bitcoin.org/pull/1165)。
 [1]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/011865.html
 [FAQ]: /en/bitcoin-core/capacity-increases-faq