diff --git a/_autocrossref.yaml b/_autocrossref.yaml
index 24f4182e..d70c2790 100644
--- a/_autocrossref.yaml
+++ b/_autocrossref.yaml
@@ -115,7 +115,7 @@ op codes: op code
'`op_return`': op_return
'`op_verify`': op_verify
orphan:
-orphan: orphaned
+orphaned: orphan
outputs: output
output:
output index:
diff --git a/_includes/guide_p2p_network.md b/_includes/guide_p2p_network.md
index 28484c86..33a45489 100644
--- a/_includes/guide_p2p_network.md
+++ b/_includes/guide_p2p_network.md
@@ -46,10 +46,50 @@ New blocks are also discovered as miners publish their found blocks, and these m
{% autocrossref %}
-In order to send a transaction to a peer, an `inv` message is sent. If a `getdata` response message is received, the transaction is sent using `tx`. The peer receiving this transaction also forwards the transaction in the same manner, given that it is a valid transaction. If the transaction is not put into a block for an extended period of time, it will be dropped from mempool, and the client of origin will have to re-broadcast the message.
+In order to send a transaction to a peer, an `inv` message is sent. If a `getdata` response message is received, the transaction is sent using `tx`. The peer receiving this transaction also forwards the transaction in the same manner, given that it is a valid transaction.
{% endautocrossref %}
+#### Memory Pool
+
+{% autocrossref %}
+
+Full peers may keep track of unconfirmed transactions which are eligible to
+be included in the next block. This is essential for miners who will
+actually mine some or all of those transactions, but it's also useful
+for any peer who wants to keep track of unconfirmed transactions, such
+as peers serving unconfirmed transaction information to SPV clients.
+
+Because unconfirmed transactions have no permanent status in Bitcoin,
+Bitcoin Core stores them in non-persistent memory, calling them a memory
+pool or mempool. When a peer shuts down, its memory pool is lost except
+for any transactions stored by its wallet. This means that never-mined
+unconfirmed transactions tend to slowly disappear from the network as
+peers restart or as they purge some transactions to make room in memory
+for others.
+
+Transactions which are mined into blocks that are later orphaned may be
+added back into the memory pool. These re-added transactions may be
+re-removed from the pool almost immediately if the replacement blocks
+include them. This is the case in Bitcoin Core, which removes orphaned
+blocks from the chain one by one, starting with the tip (highest block).
+As each block is removed, its transactions are added back to the memory
+pool. After all of the orphaned blocks are removed, the replacement
+blocks are added to the chain one by one, ending with the new tip. As
+each block is added, any transactions it confirms are removed from the
+memory pool.
+
+SPV clients don't have a memory pool for the same reason they don't
+relay transactions. They can't independently verify that a transaction
+hasn't yet been included in a block and that it only spends UTXOs, so
+they can't know which transactions are eligible to be included in the
+next block.
+
+{% endautocrossref %}
+
+
+
+
### Misbehaving Nodes
{% autocrossref %}
diff --git a/_includes/guide_wallets.md b/_includes/guide_wallets.md
index 0abd6916..21565486 100644
--- a/_includes/guide_wallets.md
+++ b/_includes/guide_wallets.md
@@ -274,15 +274,19 @@ In order to make copying of private keys less prone to error, [Wallet Import For
2. Add a 0x80 byte in front of it for mainnet addresses or 0xef for testnet addresses.
-3. Perform a SHA-256 hash on the extended key.
+3. Append a 0x01 byte after it if it should be used with compressed
+ public keys (described in a later subsection). Nothing is appended if
+ it is used with uncompressed public keys.
-4. Perform a SHA-256 hash on result of SHA-256 hash.
+4. Perform a SHA-256 hash on the extended key.
-5. Take the first four bytes of the second SHA-256 hash; this is the checksum.
+5. Perform a SHA-256 hash on result of SHA-256 hash.
-6. Add the four checksum bytes from point 5 at the end of the extended key from point 2.
+6. Take the first four bytes of the second SHA-256 hash; this is the checksum.
-7. Convert the result from a byte string into a Base58 string using Base58Check encoding.
+7. Add the four checksum bytes from point 5 at the end of the extended key from point 2.
+
+8. Convert the result from a byte string into a Base58 string using Base58Check encoding.
The process is easily reversible, using the Base58 decoding function, and removing the padding.
@@ -310,6 +314,66 @@ address utility].
{% endautocrossref %}
+
+
+#### Public Key Formats
+
+{% autocrossref %}
+
+Bitcoin ECDSA public keys represent a point on a particular Elliptic
+Curve (EC) defined in secp256k1. In their traditional uncompressed form,
+public keys contain an identification byte, a 32-byte X coordinate, and
+a 32-byte Y coordinate. The extremely simplified illustration below
+shows such a point on the elliptic curve used by Bitcoin,
+x2 = y3 + 7, over a field of
+contiguous numbers.
+
+
+
+(Secp256k1 actually modulos coordinates by a large prime, which produces a
+field of non-contiguous integers and a significantly less clear plot,
+although the principles are the same.)
+
+An almost 50% reduction in public key size can be realized without
+changing any fundamentals by dropping the Y coordinate. This is possible
+because only two points along the curve share any particular X
+coordinate, so the 32-byte Y coordinate can be replaced with a single
+bit indicating whether the point is on what appears in the illustration
+as the "top" side or the "bottom" side.
+
+No data is lost by creating these compressed public keys---only a small
+amount of CPU is necessary to reconstruct the Y coordinate and access
+the uncompressed public key. Both uncompressed and compressed public
+keys are described in official secp256k1 documentation and supported by
+default in the widely-used OpenSSL library.
+
+Because they're easy to use, and because they reduce almost by half
+the block chain space used to store public keys for every spent output,
+compressed public keys are the default in Bitcoin Core and are the
+recommended default for all Bitcoin software.
+
+However, Bitcoin Core prior to 0.6 used uncompressed keys. This creates
+a few complications, as the hashed form of an uncompressed key is
+different than the hashed form of a compressed key, so the same key
+works with two different P2PKH addresses. This also means that the key
+must be submitted in the correct format in the input scriptSig so it
+matches the hash in the previous output script.
+
+For this reason, Bitcoin Core uses several different identifier bytes to
+help programs identify how keys should be used:
+
+* Private keys meant to be used with compressed public keys have 0x01
+ appended to them before being Base-58 encoded. (See the private key
+ encoding section above.)
+
+* Uncompressed public keys start with 0x04; compressed public keys begin
+ with 0x03 or 0x02 depending on whether they're greater or less than
+ the midpoint of the curve. These prefix bytes are all used in
+ official secp256k1 documentation.
+
+{% endautocrossref %}
+
+
#### Hierarchical Deterministic Key Creation