Merge remote-tracking branch 'bitcoin.org/master' into generatingtxes

Conflicts:
	_includes/guide_payment_processing.md
	_less/screen.less

_includes/guide_block_chain.md

@@ -179,7 +179,7 @@ are usually referenced by the SHA256(SHA256()) hash of their header.
 
 {% autocrossref %}
 
-Every block must include one or more transactions. Exactly one of these
+Every block must include one or more transactions. The first one of these
 transactions must be a coinbase transaction which should collect and
 spend the block reward and any transaction fees paid by transactions included in this block.
 

_includes/guide_contracts.md

@@ -204,8 +204,7 @@ can each easily track those satoshis to learn what Bitcoin
 addresses she pays, how much she pays them, and possibly how many
 satoshis she has left.
 
-Because Alice isn't a criminal, she doesn't want to use some shady
-Bitcoin laundering service; she just wants plausible deniability about
+Alice isn't a criminal, she just wants plausible deniability about
 where she has spent her satoshis and how many she has left, so she
 starts up the Tor anonymity service on her computer and logs into an
 IRC chatroom as "AnonGirl."

_includes/guide_payment_processing.md

@@ -402,6 +402,9 @@ users and software don't need to worry about payments being sent to
 addresses which are no longer monitored.)  See the Refunds section below
 for more details.
 
+**Resource:** Gavin Andresen's [Payment Request Generator][] generates
+custom example URIs and payment requests for use with testnet.
+
 {% endautocrossref %}
 
 ### Verifying Payment

_includes/guide_transactions.md

@@ -269,8 +269,30 @@ redeemScript, so P2SH scripts are as secure as P2PKH pubkey hashes.
 
 {% autocrossref %}
 
-Care must be taken to avoid non-standard output scripts. As of Bitcoin Core
-0.9, the standard script types are:
+After the discovery of several dangerous bugs in early versions of
+Bitcoin, a test was added which only accepted transactions from the
+network if they had an output script which matched a small set of
+believed-to-be-safe templates and if the rest of the transaction didn't
+violate another small set of rules enforcing good network behavior. This
+is the `isStandard()` test, and transactions which pass it are called
+standard transactions.
+
+Non-standard transactions---those that fail the test---may be accepted
+by nodes not using the default Bitcoin Core settings. If they are
+included in blocks, they will also avoid the isStandard test and be
+processed.
+
+Besides making it more difficult for someone to attack Bitcoin for
+free by broadcasting harmful transactions, the standard transaction
+test also helps prevent users from creating transactions today that
+would make adding new transaction features in the future more
+difficult. For example, as described above, each transaction includes
+a version number---if users started arbitrarily changing the version
+number, it would become useless as a tool for introducing
+backwards-incompatible features.
+
+
+As of Bitcoin Core 0.9, the standard script types are:
 
 **Pubkey Hash (P2PKH)**
 
@@ -378,14 +400,22 @@ accept, broadcast, nor mine your transaction. When you try to broadcast
 your transaction to a peer running the default settings, you will
 receive an error.
 
-Unfortunately, if you create a non-standard redeemScript, hash it, and use the hash
+If you create a redeemScript, hash it, and use the hash
 in a P2SH output, the network sees only the hash, so it will accept the
-output as valid no matter what the redeemScript says. When you go to
-spend that output, however, peers and miners using the default settings
-will see the non-standard redeemScript and reject it. It will be
+output as valid no matter what the redeemScript says.
+This allows
+payment to non-standard output scripts almost as easily as payment to
+standard output scripts. However, when you go to
+spend that output, peers and miners using the default settings will
+check the redeemScript to see whether or not it's a standard output
+script. If it isn't, they won't process it further---so it will be
 impossible to spend that output until you find a miner who disables the
 default settings.
 
+Note: standard transactions are designed to protect and help the
+network, not prevent you from making mistakes. It's easy to create
+standard transactions which make the satoshis sent to them unspendable.
+
 As of Bitcoin Core 0.9, standard transactions must also meet the following
 conditions:
 
@@ -406,9 +436,8 @@ conditions:
   evaluation stack. It cannot push new OP codes, with the exception of
   OP codes which solely push data to the stack.
 
-* If any of the transaction's outputs spend less than a minimal value
-  (currently 546 satoshis), the transaction must pay
-  a minimum transaction fee (currently 10,000 satoshis).
+* The transaction must not include any outputs which receive fewer than
+  the defined minimum number of satoshis, currently 546.
 
 {% endautocrossref %}
 
@@ -550,8 +579,8 @@ based on their fee per byte, with higher-paying transactions being added
 in sequence until all of the available space is filled.
 
 As of Bitcoin Core 0.9, transactions which do not count as high-priority transactions
-need to pay a [minimum fee][]{:#term-minimum-fee}{:.term} of 10,000 satoshis to be
-broadcast across the network. Any transaction paying the minimum fee
+need to pay a [minimum fee][]{:#term-minimum-fee}{:.term} (currently 1,000 satoshis) to be
+broadcast across the network. Any transaction paying only the minimum fee
 should be prepared to wait a long time before there's enough spare space
 in a block to include it. Please see the [verifying payment section][section verifying payment]
 for why this could be important.

_includes/guide_wallets.md

@@ -158,7 +158,7 @@ As illustrated above, HD key derivation takes four inputs<!--noref-->:
 * The [index][key index]{:#term-key-index}{:.term} number is a 32-bit integer specified by the program.
 
 In the normal form shown in the above illustration, the parent chain
-code and the index number are fed into a one-way cryptographic hash
+code, the parent public key, and the index number are fed into a one-way cryptographic hash
 ([HMAC-SHA512][]) to produce 512 bits of
 deterministically-generated-but-seemingly-random data. The
 seemingly-random 256 bits on the righthand side of the hash output are
@@ -215,17 +215,41 @@ which makes them special.
 
 {% autocrossref %}
 
-Deriving [child extended keys][child extended key]{:#term-child-extended-key}{:.term} from parent extended keys is more nuanced
-than described earlier due to the presence of two extended private key
-derivation formulas. The normal formula, described above, combines
-together only the index number and the parent chain code to create the
+Hardened extended keys fix a potential problem with normal extended keys.
+If an attacker gets a normal parent
+chain code and parent public key, he can brute-force all chain
+codes deriving from it. If the attacker also obtains a child, grandchild, or
+further-descended private key, he can use the chain code to generate all
+of the extended private keys descending from that private key, as
+shown in the grandchild and great-grandchild generations of the illustration below.
+
+![Cross-Generational Key Compromise](/img/dev/en-hd-cross-generational-key-compromise.svg)
+
+Perhaps worse, the attacker can reverse the normal child private key
+derivation formula and subtract a parent chain code from a child private
+key to recover the parent private key, as shown in the child and
+parent generations of the illustration above.  This means an attacker
+who acquires an extended public key and any private key descended from
+it can recover that public key's private key and all keys descended from
+it.
+
+For this reason, the chain code part of an extended public key should be
+better secured than standard public keys and users should be advised
+against exporting even non-extended private keys to
+possibly-untrustworthy environments.
+
+This can be fixed, with some tradeoffs, by replacing the the normal
+key derivation formula with a hardened key derivation formula.
+
+The normal key derivation formula, described in the section above, combines
+together the index number, the parent chain code, and the parent public key to create the
 child chain code and the integer value which is combined with the parent
 private key to create the child private key.
 
 ![Creating Child Public Keys From An Extended Private Key](/img/dev/en-hd-private-parent-to-private-child.svg)
 
 The hardened formula, illustrated above, combines together the index
-number, the parent chain code, and also the parent private key to create
+number, the parent chain code, and the parent private key to create
 the data used to generate the child chain code and child private key.
 This formula makes it impossible to create child public keys without
 knowing the parent private key. In other words, parent extended public
@@ -233,21 +257,8 @@ keys can't create hardened child public keys.
 
 Because of that, a [hardened extended private
 key][]{:#term-hardened-extended-private-key}{:.term} is much less
-useful than a normal extended private key---however, it's more secure
-against multi-level key compromise. If an attacker gets a normal parent
-chain code, he can brute-force find all 2<sup>31</sup> normal chain
-codes deriving from it. If the attacker also obtains a child, grandchild, or
-further-descended private key, he can use the chain code to generate all
-of the extended private keys descending from that private key.
-
-![Cross-Generational Key Compromise](/img/dev/en-hd-cross-generational-key-compromise.svg)
-
-For this reason, the chain code part of an extended public key should be
-better secured than standard public keys and users should be advised
-against exporting even non-extended private keys to
-possibly-untrustworthy environments.
-
-Hardened extended private keys create a firewall through which
+useful than a normal extended private key---however, 
+hardened extended private keys create a firewall through which
 multi-level key derivation compromises cannot happen. Because hardened
 child extended public keys cannot generate grandchild chain codes on
 their own, the compromise of a parent extended public key cannot be
@@ -275,6 +286,13 @@ firewalls.
 
 ![Example HD Wallet Tree Using Prime Notation](/img/dev/en-hd-tree.svg)
 
+Wallets following the BIP32 HD protocol only create hardened children of
+the master private key (*m*) to prevent a compromised child key from
+compromising the master key. As there are no normal children for the
+master keys, the master public key is not used in HD wallets. All other
+keys can have normal children, so the corresponding extended public keys
+may be used instead.
+
 The HD protocol also describes a serialization format for extended
 public keys and extended private keys.  For details, please see the
 [wallet section in the developer reference][devref wallets] or BIP32
@@ -321,7 +339,14 @@ For implementation details, please see BIP39.
 
 {% autocrossref %}
 
-Loose-Key wallets, also called "Just a Bunch Of Keys (JBOK)", are a deprecated form of wallet that originated from the Bitcoin Core client wallet. The Bitcoin Core client wallet would create 100 private key/public key pairs automatically via a Pseudo-Random-Number Generator (PRNG) for later use. Once all these keys are consumed or the RPC call `keypoolrefill` is run, another 100 key pairs would be created. This created considerable difficulty<!--noref--> in backing up one’s keys, considering backups have to be run manually to save the newly-generated private keys. If a new key pair set is generated, used, and then lost prior to a backup, the stored satoshis are likely lost forever. Many older-style mobile wallets followed a similar format, but only generated a new private key upon user demand.
+Loose-Key wallets, also called "Just a Bunch Of Keys (JBOK)", are a deprecated form of wallet that originated from the Bitcoin Core client wallet. The Bitcoin Core client wallet would create 100 private key/public key pairs automatically via a Pseudo-Random-Number Generator (PRNG) for later use.
+
+These unused private keys are stored in a virtual "key pool", with new
+keys being generated whenever a previously-generated key was used,
+ensuring the pool maintained 100 unused keys. (If the wallet is
+encrypted, new keys are only generated while the wallet is unlocked.)
+
+This created considerable difficulty<!--noref--> in backing up one’s keys, considering backups have to be run manually to save the newly-generated private keys. If a new key pair set is generated, used, and then lost prior to a backup, the stored satoshis are likely lost forever. Many older-style mobile wallets followed a similar format, but only generated a new private key upon user demand.
 
 This wallet type is being actively phased out and discouraged from being used due to the backup hassle.
 

_includes/ref_block_chain.md

@@ -27,13 +27,13 @@ As of version 2 blocks, each block consists of four root elements:
 
 4. One or more transactions.
 
-Every block must include a [coinbase transaction][]{:#term-coinbase-tx}{:.term} which should collect and
+The first transaction in a block must be a [coinbase transaction][]{:#term-coinbase-tx}{:.term} which should collect and
 spend any transaction fees paid by transactions included in this block.
 All blocks with a block height less than 6,930,000 are entitled to
 receive a [block reward][]{:#term-block-reward}{:.term} of newly created bitcoin value, which also
 should be spent in the coinbase transaction. (The block reward started
-at 50 bitcoins and is being halved approximately every four years. As of
-April 2014, it's 25 bitcoins.) A coinbase transaction is invalid if it 
+at 50 bitcoins and is being halved every 210,000 blocks---approximately once every four years. As of
+June 2014, it's 25 bitcoins.) A coinbase transaction is invalid if it 
 tries to spend more value than is available from the transaction 
 fees and block reward.
 

_includes/ref_core_rpcs-abcdefg.md

@@ -786,7 +786,9 @@ encryptwallet <passphrase>
 
 Encrypts the wallet with 'passphrase'. This is only to enable encryption
 for the first time.  After encryption is enabled, you will need to
-enter the passphrase to use private keys.
+enter the passphrase to use private keys (which includes generating
+additional new addresses once the keypool is exhausted---see
+`keypoolrefill`).
 
 *Warning:* there is no RPC to completely disable encryption.  If you
 want to return to an unencrypted wallet, you must create a new wallet
@@ -1929,7 +1931,7 @@ Result:
 
 
 
-#### getmininginformation
+#### getmininginfo
 
 ~~~
 getmininginfo
@@ -2657,8 +2659,7 @@ transactions with at least the indicated number of confirmations.
 {% autocrossref %}
 
 *String; required:* a Bitcoin address to check.  Must be an address 
-belonging to the wallet unless `txindex=1` was added to the `bitcoind`
-startup options.
+belonging to the wallet.
 
 {% endautocrossref %}
 

_includes/ref_transactions.md

@@ -47,9 +47,9 @@ The op codes used in standard transactions are,
     error in the Bitcoin Core implementation. This value is not used, so
     scriptSigs prefix the signatures with a single OP_0 (0x00).
 
-* [`OP_RETURN`][op_return]{:#term-op-return}{:.term} terminates the script in failure. However, this will not
-  invalidate a null data transaction which contains no more than 40
-  bytes following `OP_RETURN` no more than once per transaction.
+* [`OP_RETURN`][op_return]{:#term-op-return}{:.term} terminates the script in failure,
+  rendering the output unspendable and allowing a miner to claim the
+  satoshis sent to that OP_RETURN output as an additional transaction fee.
 
 A complete list of OP codes can be found on the Bitcoin Wiki [Script
 Page][wiki script], with an authoritative list in the `opcodetype` enum

_includes/references.md

@@ -21,7 +21,6 @@
 [chain code]: /en/developer-guide#term-chain-code "In HD wallets, 256 bits of entropy added to the master public and private keys to help them generate secure child keys; the chain code is usually derived from a seed along with the master private key"
 [change address]: /en/developer-guide#term-change-output "An output used by a spender to send back to himself some of the satoshis from the inputs"
 [change output]: /en/developer-guide#term-change-output "An output used by a spender to send back to himself some of the satoshis from the inputs"
-[child extended key]: /en/developer-guide#term-child-extended-key "A child key extended with a chain code so that it can become a parent key and derive its own child keys"
 [child key]: /en/developer-guide#term-child-key "In HD wallets, a key derived from a parent key"
 [child public key]: /en/developer-guide#term-child-public-key "In HD wallets, a public key derived from a parent public key or a corresponding child private key"
 [coinbase field]: /en/developer-reference#term-coinbase-field "A special input-like field for coinbase transactions"
@@ -194,6 +193,7 @@
 [MIME]: https://en.wikipedia.org/wiki/Internet_media_type
 [Merge Avoidance subsection]: /en/developer-guide#merge-avoidance
 [mozrootstore]: https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/
+[Payment Request Generator]: http://bitcoincore.org/~gavin/createpaymentrequest.php
 [Piotr Piasecki's testnet faucet]: https://tpfaucet.appspot.com/
 [prime symbol]: https://en.wikipedia.org/wiki/Prime_%28symbol%29
 [protobuf]: https://developers.google.com/protocol-buffers/