Merge pull request #400 from bitcoin/develp2pkh

Replace P2PH With P2PKH

_autocrossref.yaml

@@ -120,7 +120,7 @@ orphan: orphaned
 outputs: output
 output:
 output index:
-p2ph:
+p2pkh:
 p2sh:
 p2sh multisig:
 parent chain code:

_includes/guide_payment_processing.md

@@ -611,9 +611,9 @@ each payment.
 ## Amount of the request
 amount = 10000000  ## In satoshis
 
-## P2PH pubkey hash
+## P2PKH pubkey hash
 pubkey_hash = "2b14950b8d31620c6cc923c5408a701b1ec0a020"
-## P2PH output script entered as hex and converted to binary
+## P2PKH output script entered as hex and converted to binary
 # OP_DUP OP_HASH160 <push 20 bytes> <pubKey hash> OP_EQUALVERIFY OP_CHECKSIG
 #   76       a9            14       <pubKey hash>        88          ac
 hex_script = "76" + "a9" + "14" + pubkey_hash + "88" + "ac"
@@ -657,13 +657,13 @@ serialized_script = hex_script.decode("hex")
 
 `script`: (required) You must specify the output script you want the spender to
 pay---any valid script is acceptable. In this example, we'll request
-payment to a P2PH output script.  
+payment to a P2PKH output script.  
 
 First we get a pubkey hash. The hash above is the hash form of the
 address used in the URI examples throughout this section,
 mjSk1Ny9spzU2fouzYgLqGUD8U41iR35QN.
 
-Next, we plug that hash into the standard P2PH output script using hex,
+Next, we plug that hash into the standard P2PKH output script using hex,
 as illustrated by the code comments.
 
 Finally, we convert the output script from hex into its serialized form.

_includes/guide_transactions.md

@@ -40,12 +40,12 @@ invalidating previous transactions.
 The figures below help illustrate the other transaction features by
 showing the workflow Alice uses to send Bob a transaction and which Bob
 later uses to spend that transaction. Both Alice and Bob will use the
-most common form of the standard Pay-To-Pubkey-Hash (P2PH) transaction
-type. [P2PH][]{:#term-p2ph}{:.term} lets Alice spend satoshis to a typical Bitcoin address,
+most common form of the standard Pay-To-Public-Key-Hash (P2PKH) transaction
+type. [P2PKH][]{:#term-p2pkh}{:.term} lets Alice spend satoshis to a typical Bitcoin address,
 and then lets Bob further spend those satoshis using a simple
 cryptographic key pair.
 
-![Creating A P2PH Public Key Hash To Receive Payment](/img/dev/en-creating-p2ph-output.svg)
+![Creating A P2PKH Public Key Hash To Receive Payment](/img/dev/en-creating-p2pkh-output.svg)
 
 Bob must first generate a private/public [key pair][]{:#term-key-pair}{:.term} before Alice can create the
 first transaction. Standard Bitcoin [private keys][private
@@ -76,7 +76,7 @@ into another format, such as a QR code containing a `bitcoin:`
 URI.
 
 Once Alice has the address and decodes it back into a standard hash, she
-can create the first transaction. She creates a standard P2PH
+can create the first transaction. She creates a standard P2PKH
 transaction output containing instructions which allow anyone to spend that
 output if they can prove they control the private key corresponding to
 Bob's hashed public key. These instructions are called the output [script][]{:#term-script}{:.term}.
@@ -92,11 +92,11 @@ index number ([output index][]{:#term-output-index}{:.term}). He must then creat
 collection of data parameters which satisfy the conditions Alice placed
 in the previous output's script.
 
-![Unlocking A P2PH Output For Spending](/img/dev/en-unlocking-p2ph-output.svg)
+![Unlocking A P2PKH Output For Spending](/img/dev/en-unlocking-p2pkh-output.svg)
 
 Bob does not need to communicate with Alice to do this; he must simply
 prove to the Bitcoin peer-to-peer network that he can satisfy the
-script's conditions.  For a P2PH-style output, Bob's scriptSig will
+script's conditions.  For a P2PKH-style output, Bob's scriptSig will
 contain the following two pieces of data:
 
 1. His full (unhashed) public key, so the script can check that it
@@ -129,11 +129,11 @@ transactions.
 
 {% endautocrossref %}
 
-### P2PH Script Validation
+### P2PKH Script Validation
 
 {% autocrossref %}
 
-The validation procedure requires evaluation of the script.  In a P2PH
+The validation procedure requires evaluation of the script.  In a P2PKH
 output, the script is:
 
 {% endautocrossref %}
@@ -145,7 +145,7 @@ OP_DUP OP_HASH160 <PubkeyHash> OP_EQUALVERIFY OP_CHECKSIG
 {% autocrossref %}
 
 The spender's scriptSig is evaluated and prefixed to the beginning of the
-script. In a P2PH transaction, the scriptSig contains a signature (sig)
+script. In a P2PKH transaction, the scriptSig contains a signature (sig)
 and full public key (pubkey), creating the following concatenation:
 
 {% endautocrossref %}
@@ -173,10 +173,10 @@ locations in stack descriptions. -harding -->
 To test whether the transaction is valid, scriptSig and script arguments
 are pushed to the stack one item at a time, starting with Bob's scriptSig
 and continuing to the end of Alice's script. The figure below shows the
-evaluation of a standard P2PH script; below the figure is a description
+evaluation of a standard P2PKH script; below the figure is a description
 of the process.
 
-![P2PH Stack Evaluation](/img/dev/en-p2ph-stack.svg)
+![P2PKH Stack Evaluation](/img/dev/en-p2pkh-stack.svg)
 
 * The signature (from Bob's scriptSig) is added (pushed) to an empty stack.
   Because it's just data, nothing is done except adding it to the stack.
@@ -231,7 +231,7 @@ currently spending. Receivers do care about the conditions imposed on
 the satoshis by the output script and, if they want, they can ask
 spenders to use a particular script. Unfortunately, custom scripts are
 less convenient than short Bitcoin addresses and more difficult to
-secure than P2PH pubkey hashes.
+secure than P2PKH pubkey hashes.
 
 To solve these problems, pay-to-script-hash
 ([P2SH][]{:#term-p2sh}{:.term}) transactions were created in 2012 to let
@@ -240,7 +240,7 @@ script][script hash]{:#term-script-hash}{:.term}, the
 [redeemScript][]{:#term-redeemscript}{:.term}.
 
 The basic P2SH workflow, illustrated below, looks almost identical to
-the P2PH workflow. Bob creates a redeemScript with whatever script he
+the P2PKH workflow. Bob creates a redeemScript with whatever script he
 wants, hashes the redeemScript, and provides the redeemScript
 hash to Alice. Alice creates a P2SH-style output containing
 Bob's redeemScript hash.
@@ -260,8 +260,8 @@ The hash of the redeemScript has the same properties as a pubkey
 hash---so it can be transformed into the standard Bitcoin address format
 with only one small change to differentiate it from a standard address.
 This makes collecting a P2SH-style address as simple as collecting a
-P2PH-style address. The hash also obfuscates any public keys in the
-redeemScript, so P2SH scripts are as secure as P2PH pubkey hashes.
+P2PKH-style address. The hash also obfuscates any public keys in the
+redeemScript, so P2SH scripts are as secure as P2PKH pubkey hashes.
 
 {% endautocrossref %}
 
@@ -272,9 +272,9 @@ redeemScript, so P2SH scripts are as secure as P2PH pubkey hashes.
 Care must be taken to avoid non-standard output scripts. As of Bitcoin Core
 0.9, the standard script types are:
 
-**Pubkey Hash (P2PH)**
+**Pubkey Hash (P2PKH)**
 
-P2PH is the most common form of script used to send a transaction to one
+P2PKH is the most common form of script used to send a transaction to one
 or multiple Bitcoin addresses.
 
 {% endautocrossref %}
@@ -340,9 +340,9 @@ scriptSig: OP_0 <sig> <sig> <redeemscript>
 
 **Pubkey**
 
-[Pubkey][]{:#term-pubkey}{:.term} scripts are a simplified form of the P2PH script,
+[Pubkey][]{:#term-pubkey}{:.term} scripts are a simplified form of the P2PKH script,
 but they aren’t as
-secure as P2PH, so they generally
+secure as P2PKH, so they generally
 aren’t used in new transactions anymore.
 
 {% endautocrossref %}
@@ -394,7 +394,7 @@ conditions:
   numbers must be 0xffffffff.
 
 * The transaction must be smaller than 100,000 bytes. That's around 200
-  times larger than a typical single-input, single-output P2PH
+  times larger than a typical single-input, single-output P2PKH
   transaction.
 
 * Each of the transaction's inputs must be smaller than 500 bytes.
@@ -563,10 +563,10 @@ people will have UTXOs that exactly match the amount they want to pay,
 so most transactions include a change output.
 
 [Change outputs][change output]{:#term-change-output}{:.term} are regular outputs which spend the surplus satoshis
-from the UTXOs back to the spender.  They can reuse the same P2PH pubkey hash
+from the UTXOs back to the spender.  They can reuse the same P2PKH pubkey hash
 or P2SH script hash as was used in the UTXO, but for the reasons
 described in the [next subsection](#avoiding-key-reuse), it is highly recommended that change
-outputs be sent to a new P2PH or P2SH address.
+outputs be sent to a new P2PKH or P2SH address.
 
 {% endautocrossref %}
 
@@ -600,7 +600,7 @@ allow reconstruction of private keys from public keys (hypothesized) or
 from signature comparisons (possible today under certain circumstances
 described below, with more general attacks hypothesized).
 
-1. Unique (non-reused) P2PH and P2SH addresses protect against the first
+1. Unique (non-reused) P2PKH and P2SH addresses protect against the first
    type of attack by keeping ECDSA public keys hidden (hashed) until the
    first time satoshis sent to those addresses are spent, so attacks
    are effectively useless unless they can reconstruct private keys in

_includes/ref_core_rpcs-abcdefg.md

@@ -74,7 +74,7 @@ wallet as spendable balances).
 {% autocrossref %}
 
 Adding a 2-of-3 P2SH multisig address to the "test account" by mixing
-two P2PH addresses and one full public key:
+two P2PKH addresses and one full public key:
 
 {% endautocrossref %}
 
@@ -266,7 +266,7 @@ provide public keys for any address not known to this wallet.
 
 {% autocrossref %}
 
-Creating a 2-of-3 P2SH multisig address by mixing two P2PH addresses and
+Creating a 2-of-3 P2SH multisig address by mixing two P2PKH addresses and
 one full public key:
 
 {% endautocrossref %}
@@ -310,7 +310,7 @@ createrawtransaction <previous output(s)> <new output(s)>
 {% autocrossref %}
 
 Create an unsigned transaction in hex rawtransaction format that spends a
-previous output to an new output with a P2PH or P2SH address. The
+previous output to an new output with a P2PKH or P2SH address. The
 transaction is not stored in the wallet or transmitted to the network.
 
 
@@ -332,11 +332,11 @@ output index number, called *vout* (number; required).
 ]
 ~~~
 
-**Argument #2: P2PH Or P2SH Addresses For New Outputs**
+**Argument #2: P2PKH Or P2SH Addresses For New Outputs**
 
 {% autocrossref %}
 
-*String; required:* A JSON object with P2PH or P2SH addresses to pay as
+*String; required:* A JSON object with P2PKH or P2SH addresses to pay as
 keys and the amount to pay each address as its value (number; required)
 in decimal bitcoins.
 
@@ -612,7 +612,7 @@ Decode a hex-encoded P2SH redeemScript.
 {% autocrossref %}
 
 A JSON object describing the redeemScript, with *asm* being the script
-in script-language psuedocode, *hex* being the a P2PH public key (if
+in script-language psuedocode, *hex* being the a P2PKH public key (if
 applicable), *type* being the output type (typically public key,
 multisig, or nonstandard), *reqSigs* being the required signatures,
 and the *addresses* array listing the addresses belonging to the

_includes/ref_core_rpcs-uvwxyz.md

@@ -28,7 +28,7 @@ indicated whether or not the address is valid. If it is valid, the
 validated *address* is returned plus *ismine* to indicate whether or not
 it belongs to this wallet and *account* to indicate which account it
 belongs to. If it's a P2SH address, *isscript* will be true. If it's a
-P2PH address, *pubkey* will contain the public key and *compressed* will
+P2PKH address, *pubkey* will contain the public key and *compressed* will
 indicate whether or not the pubkey/address is compressed.
 
 {% endautocrossref %}

_includes/ref_transactions.md

@@ -66,11 +66,11 @@ prevent the script from working as expected.
 
 {% autocrossref %}
 
-The hashes used in P2PH and P2SH outputs are commonly encoded as Bitcoin
+The hashes used in P2PKH and P2SH outputs are commonly encoded as Bitcoin
 addresses.  This is the procedure to encode those hashes and decode the
 addresses.
 
-First, get your hash.  For P2PH, you RIPEMD-160(SHA256()) hash a ECDSA
+First, get your hash.  For P2PKH, you RIPEMD-160(SHA256()) hash a ECDSA
 public key derived from your 256-bit ECDSA private key (random data).
 For P2SH, you RIPEMD-160(SHA256()) hash a redeemScript serialized in the
 format used in raw transactions (described in a [following
@@ -79,9 +79,9 @@ sub-section][raw transaction format]).  Taking the resulting hash:
 1. Add an address version byte in front of the hash.  The version
 bytes commonly used by Bitcoin are:
 
-    * 0x00 for P2PH addresses on the main Bitcoin network (mainnet)
+    * 0x00 for P2PKH addresses on the main Bitcoin network (mainnet)
 
-    * 0x6f for P2PH addresses on the Bitcoin testing network (testnet)
+    * 0x6f for P2PKH addresses on the Bitcoin testing network (testnet)
 
     * 0x05 for P2SH addresses on mainnet
 

_includes/references.md

@@ -1,7 +1,7 @@
 [51 percent attack]: /en/developer-guide#term-51-attack "The ability of someone controlling a majority of hashing power to revise transactions history and prevent new transactions from confirming"
 [accidental fork]: /en/developer-guide#term-accidental-fork "When two or more blocks have the same block height, forking the block chain.  Happens occasionally by accident"
-[addresses]: /en/developer-guide#term-address "A 20-byte hash formatted as a P2PH or P2SH Bitcoin Address"
-[address]: /en/developer-guide#term-address "A 20-byte hash formatted as a P2PH or P2SH Bitcoin Address"
+[addresses]: /en/developer-guide#term-address "A 20-byte hash formatted as a P2PKH or P2SH Bitcoin Address"
+[address]: /en/developer-guide#term-address "A 20-byte hash formatted as a P2PKH or P2SH Bitcoin Address"
 [base58Check]: /en/developer-reference#term-base58check "The method used in Bitcoin for converting 160-bit hashes into Bitcoin addresses"
 [bitcoin URI]: /en/developer-guide#term-bitcoin-uri "A URI which allows receivers to encode payment details so spenders don't have to manually enter addresses and other details"
 [bitcoins]: /en/developer-guide#term-bitcoins "A primary accounting unit used in Bitcoin; 100 million satoshis"
@@ -83,7 +83,7 @@
 [output]: /en/developer-guide#term-output "The output of a transaction which transfers value to a script"
 [output index]: /en/developer-guide#term-output-index "The sequentially-numbered index of outputs in a single transaction starting from 0"
 [outputs]: /en/developer-guide#term-output "The outputs of a transaction which transfer value to scripts"
-[P2PH]: /en/developer-guide#term-p2ph "A script which Pays To Pubkey Hashes (P2PH), allowing spending of satoshis to anyone with a Bitcoin address"
+[P2PKH]: /en/developer-guide#term-p2pkh "A script which Pays To Pubkey Hashes (P2PKH), allowing spending of satoshis to anyone with a Bitcoin address"
 [P2SH]: /en/developer-guide#term-p2sh "A script which Pays To Script Hashes (P2SH), allowing convenient spending of satoshis to an address referencing a script"
 [P2SH multisig]: /en/developer-guide#term-p2sh-multisig "A multisig script embedded in the redeemScript of a pay-to-script-hash (P2SH) transaction"
 [parent chain code]: /en/developer-guide#term-parent-chain-code "A chain code which has helped create child public or private keys"
@@ -100,7 +100,7 @@
 [point function]: /en/developer-guide#term-point-function "The ECDSA function used to create a public key from a private key"
 [private key]: /en/developer-guide#term-private-key "The private portion of a keypair which can create signatures which other people can verify using the public key"
 [private keys]: /en/developer-guide#term-private-key "The private portion of a keypair which can create signatures which other people can verify using the public key"
-[pubkey hash]: /en/developer-guide#term-pubkey-hash "The hash of a public key which can be included in a P2PH output"
+[pubkey hash]: /en/developer-guide#term-pubkey-hash "The hash of a public key which can be included in a P2PKH output"
 [public key]: /en/developer-guide#term-public-key "The public portion of a keypair which can be safely distributed to other people so they can verify a signature created with the corresponding private key"
 [public keys]: /en/developer-guide#term-public-key "The public portion of a keypair which can be safely distributed to other people so they can verify a signature created with the corresponding private key"
 [pp amount]: /en/developer-guide#term-pp-amount "Part of the Output part of the PaymentDetails part of a payment protocol where receivers can specify the amount of satoshis they want paid to a particular output script"

img/dev/en-creating-p2pkh-output.dot

@@ -7,8 +7,9 @@ rankdir=LR;
 //ranksep=0.1;
 //splines=ortho;
 
-node [ shape = box, penwidth = 1.75 ];
-edge [ penwidth = 1.75 ];
+node [ fontname="Sans", shape = box, penwidth = 1.75 ];
+edge [ fontname="Sans", penwidth = 1.75 ];
+graph [ fontname="Sans" ];
 penwidth = 1.75;
 
 subgraph cluster_bob {
@@ -37,5 +38,5 @@ private_key -> full_public_key -> pubkey_hash -> spender_pubkey_hash -> tx1_pubk
 
 
 
-label = "Creating A P2PH Public Key Hash To Receive Payment"
+label = "Creating A P2PKH Public Key Hash To Receive Payment"
 }

img/dev/en-creating-p2pkh-output.svg

@@ -9,7 +9,7 @@
 <g id="graph1" class="graph" transform="scale(0.722311 0.722311) rotate(0) translate(4 144)">
 <title>blockchain</title>
 <polygon fill="white" stroke="white" points="-4,5 -4,-144 620,-144 620,5 -4,5"/>
-<text text-anchor="middle" x="307.5" y="-8.4" font-family="Sans" font-size="14.00">Creating A P2PH Public Key Hash To Receive Payment</text>
+<text text-anchor="middle" x="307.5" y="-8.4" font-family="Sans" font-size="14.00">Creating A P2PKH Public Key Hash To Receive Payment</text>
 <g id="graph2" class="cluster"><title>cluster_bob</title>
 <polygon fill="none" stroke="black" stroke-width="1.75" points="8,-41 8,-124 334,-124 334,-41 8,-41"/>
 <text text-anchor="middle" x="171" y="-107.4" font-family="Sans" font-size="14.00">Bob&#39;s Computer</text>

img/dev/en-p2pkh-stack.dot

@@ -1,13 +1,14 @@
 digraph blockchain {
 
-size=6.66;
+size=6.25;
 splines = "false";
 //rankdir=LR;
 //ranksep=0.1;
 //splines=ortho;
 
-node [ shape = box ];
-edge [ style = invis, minlen = 1 ];
+node [ fontname="Sans", shape = box ];
+edge [ fontname="Sans", style = invis, minlen = 1 ];
+graph [ fontname="Sans" ];
 //fixedsize
 nodesep = 0.05;
 //concentrate = true;
@@ -141,5 +142,5 @@ stack6_ophash -> stack6_pubkeyhash [ style = "" ];
 stack7_pubkey -> stack7_opchecksig [ style = "" ]; 
 stack7_sig -> stack7_pubkey [ style = "" ]; 
 
-label = "Evaluation Stack Over Time During Succesful P2PH Script Validation"
+label = "Evaluation Stack Over Time During Succesful P2PKH Script Validation"
 }

img/dev/en-p2pkh-stack.svg

@@ -4,12 +4,12 @@
 <!-- Generated by graphviz version 2.26.3 (20100126.1600)
  -->
 <!-- Title: blockchain Pages: 1 -->
-<svg width="480pt" height="351pt"
- viewBox="0.00 0.00 480.00 350.53" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink">
-<g id="graph1" class="graph" transform="scale(0.631579 0.631579) rotate(0) translate(4 551)">
+<svg width="450pt" height="329pt"
+ viewBox="0.00 0.00 450.00 328.62" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink">
+<g id="graph1" class="graph" transform="scale(0.592105 0.592105) rotate(0) translate(4 551)">
 <title>blockchain</title>
 <polygon fill="white" stroke="white" points="-4,5 -4,-551 757,-551 757,5 -4,5"/>
-<text text-anchor="middle" x="376" y="-8.4" font-family="Sans" font-size="14.00">Evaluation Stack Over Time During Succesful P2PH Script Validation</text>
+<text text-anchor="middle" x="376" y="-8.4" font-family="Sans" font-size="14.00">Evaluation Stack Over Time During Succesful P2PKH Script Validation</text>
 <g id="graph2" class="cluster"><title>cluster_alice</title>
 <polygon fill="grey" stroke="black" points="8,-462 8,-539 710,-539 710,-462 8,-462"/>
 <text text-anchor="middle" x="359" y="-522.4" font-family="Sans" font-size="14.00">Instructions And Data Provided By Alice In Transaction #1&#39;s Output Script</text>

img/dev/en-unlocking-p2pkh-output.dot

@@ -9,8 +9,9 @@ rankdir=LR;
 overlap = false;
 nodesep = 0.1;
 
-node [ shape = box, penwidth = 1.75 ];
-edge [ penwidth = 1.75, minlen = 2 ];
+node [ fontname="Sans", shape = box, penwidth = 1.75 ];
+edge [ fontname="Sans", penwidth = 1.75, minlen = 2 ];
+graph [ fontname="Sans" ];
 penwidth = 1.75;
 
 subgraph cluster_tx2 {
@@ -43,5 +44,5 @@ tx1_pubkey_hash -> tx2_pubkey_hash;
     tx2_signature -> private_key [ style = "dashed" ];
 }
 
-label = " \nSpending A P2PH Output"
+label = " \nSpending A P2PKH Output"
 }

img/dev/en-unlocking-p2pkh-output.svg

@@ -10,7 +10,7 @@
 <title>blockchain</title>
 <polygon fill="white" stroke="white" points="-4,5 -4,-292 553,-292 553,5 -4,5"/>
 <text text-anchor="middle" x="274" y="-25.4" font-family="Sans" font-size="14.00"> </text>
-<text text-anchor="middle" x="274" y="-8.4" font-family="Sans" font-size="14.00">Spending A P2PH Output</text>
+<text text-anchor="middle" x="274" y="-8.4" font-family="Sans" font-size="14.00">Spending A P2PKH Output</text>
 <g id="graph2" class="cluster"><title>cluster_tx2</title>
 <polygon fill="none" stroke="black" stroke-width="1.75" points="208,-50 208,-280 350,-280 350,-50 208,-50"/>
 </g>