Anchors: rename "cup_of_coffee" to "spending_bitcoin"

ch02.asciidoc

@@ -64,7 +64,7 @@ own transactions, the operator may be able to guess how many bitcoins
 you've received, spent, and currently own.
 ====
 
-[[bitcoin_e_commerce]]
+[[spending_bitcoin]]
 ==== Buying from an Online Store
 
 Alice, introduced in the previous chapter, is a new user who has just

ch03.asciidoc

@@ -753,7 +753,7 @@ blocks from other Bitcoin clients. You can check its progress using
 transactions")))((("transactions", "exploring with Bitcoin Core
 API")))Commands: +getrawtransaction+, +decoderawtransaction+
 
-In <<cup_of_coffee>>, ((("use cases", "buying coffee",
+In <<spending_bitcoin>>, ((("use cases", "buying coffee",
 id="alicethree")))Alice made a purchase from Bob's store. Her
 transaction was recorded on the blockchain.
 Let's use the API to retrieve and examine that transaction by passing

ch07.asciidoc

@@ -696,7 +696,7 @@ Let’s look at some of our example transactions and see how they would change w
 [[p2wpkh]]
 ===== Pay-to-Witness-Public-Key-Hash (P2WPKH)
 
-In <<cup_of_coffee>>, ((("use cases", "buying coffee", id="aliced")))Alice created a transaction to pay Bob for a cup of coffee. That transaction created a P2PKH output with a value of 0.015 BTC that was spendable by Bob. The output’s script looks like this:
+In <<spending_bitcoin>>, ((("use cases", "buying coffee", id="aliced")))Alice created a transaction to pay Bob for a cup of coffee. That transaction created a P2PKH output with a value of 0.015 BTC that was spendable by Bob. The output’s script looks like this:
 
 .Example P2PKH output script
 ----

ch10.asciidoc

@@ -138,7 +138,7 @@ Jing's node is listening for new blocks, propagated on the Bitcoin network, as d
 
 ((("mining and consensus", "aggregating transactions into blocks", id="MACaggreg10")))((("transactions", "aggregating into blocks", id="Taggreg10")))((("blocks", "aggregating transactions into", id="Baggreg10")))((("blocks", "candidate blocks")))((("candidate blocks")))((("transaction pools")))((("memory pools (mempools)")))After validating transactions, a Bitcoin node will add them to the _memory pool_, or _transaction pool_, where transactions await until they can be included (mined) into a block. Jing's node collects, validates, and relays new transactions just like any other node. Unlike other nodes, however, Jing's node will then aggregate these transactions into a _candidate block_.
 
-Let's follow the blocks that were created during the time Alice bought a cup of coffee from Bob's Cafe (see <<cup_of_coffee>>). Alice's transaction was included in block 277,316. For the purpose of demonstrating the concepts in this chapter, let's assume that block was mined by Jing's mining system and follows Alice's transaction as it becomes part of this new block.
+Let's follow the blocks that were created during the time Alice bought a cup of coffee from Bob's Cafe (see <<spending_bitcoin>>). Alice's transaction was included in block 277,316. For the purpose of demonstrating the concepts in this chapter, let's assume that block was mined by Jing's mining system and follows Alice's transaction as it becomes part of this new block.
 
 Jing's mining node maintains a local copy of the blockchain. By the time ((("use cases", "buying coffee")))Alice buys the cup of coffee, Jing's node has assembled a chain up to block 277,314. Jing's node is listening for transactions, trying to mine a new block and also listening for blocks discovered by other nodes. As Jing's node is mining, it receives block 277,315 through the Bitcoin network. The arrival of this block signifies the end of the competition for block 277,315 and the beginning of the competition to create block 277,316.