All: mostly replace "SPV client" with "lightweight client"

The description of SPV in the original paper assumed full nodes would
warn SPV clients about invalid blocks.  Such fraud proofs are not used
in production, so lightweight clients are (arguably) not SPV clients.

appdx-bips.asciidoc

@@ -12,7 +12,7 @@ _Process_ BIP:: Describes a bitcoin process, or proposes a change to (or an even
 
 ((("bitcoin improvement proposals", "repository of")))BIPs are recorded in a versioned repository on GitHub: https://github.com/bitcoin/bips[https://github.com/bitcoin/bips].
 An MIT-licensed document from the open source Bitcoin Core project,
-reproduced here, describes which BIPs it implements, including listing
+reproduced here in edited form, describes which BIPs it implements, including listing
 the version of Bitcoin Core where support for each BIP was added or
 significantly changed.
 
@@ -31,7 +31,7 @@ BIPs that are implemented by Bitcoin Core:
 -    BIP32: Hierarchical Deterministic Wallets has been implemented since v0.13.0 (PR #8035).
 -    BIP34: The rule that requires blocks to contain their height (number) in the coinbase input, and the introduction of version 2 blocks has been implemented since v0.7.0. The rule took effect for version 2 blocks as of block 224413 (March 5th 2013), and version 1 blocks are no longer allowed since block 227931 (March 25th 2013) (PR #1526).
 -    BIP35: The 'mempool' protocol message (and the protocol version bump to 60002) has been implemented since v0.7.0 (PR #1641). As of v0.13.0, this is only available for NODE_BLOOM (BIP111) peers.
--    BIP37: The bloom filtering for transaction relaying, partial Merkle trees for blocks, and the protocol version bump to 70001 (enabling low-bandwidth SPV clients) has been implemented since v0.8.0 (PR #1795). Disabled by default since v0.19.0, can be enabled by the -peerbloomfilters option.
+-    BIP37: The bloom filtering for transaction relaying, partial Merkle trees for blocks, and the protocol version bump to 70001 (enabling low-bandwidth lightweight clients) has been implemented since v0.8.0 (PR #1795). Disabled by default since v0.19.0, can be enabled by the -peerbloomfilters option.
 -    BIP42: The bug that would have caused the subsidy schedule to resume after block 13440000 was fixed in v0.9.2 (PR #3842).
 -    BIP43: The experimental descriptor wallets introduced in v0.21.0 by default use the Hierarchical Deterministic Wallet derivation proposed by BIP43. (PR #16528)
 -    BIP44: The experimental descriptor wallets introduced in v0.21.0 by default use the Hierarchical Deterministic Wallet derivation proposed by BIP44. (PR #16528)

ch01.asciidoc

@@ -216,7 +216,7 @@ video for each day of Bitcoin transactions--but the full node offers
 complete autonomy to its users.
 
 Lightweight client:: ((("lightweight
-clients")))((("simplified-payment-verification (SPV)")))A lightweight
+clients")))
 client, also known as a simplified-payment-verification (SPV) client,
 connects to a full node or other remote server for receiving and sending
 Bitcoin transaction information, but stores the user wallet locally,

ch02.asciidoc

@@ -659,8 +659,7 @@ image::images/mbc2_0209.png["Alice's transaction included in a block"]
 
 === Spending the Transaction
 
-((("spending bitcoin", "simple-payment-verification
+Now that Alice's
-(SPV)")))((("simple-payment-verification (SPV)")))Now that Alice's
 transaction has been embedded in the blockchain as part of a block, it
 is part of the distributed ledger of Bitcoin and visible to all Bitcoin
 applications. Each bitcoin full node can independently verify the

ch08.asciidoc

@@ -50,11 +50,11 @@ functions, such as routing, mining, and wallet services.
 Some nodes, called _archival full nodes_, also maintain a
 complete and up-to-date copy of the blockchain. Full nodes can
 autonomously and authoritatively verify any transaction without external
-reference. ((("simple-payment-verification (SPV)")))  Those nodes can
+reference.  Those nodes can
 serve data to clients that store
-only a subset of the blockchain and verify transactions using a method
+only a subset of the blockchain and partly verify transactions using a method
 called _simplified payment verification_, or SPV. ((("lightweight
-clients")))These clients are known as lightweight clients or SPV clients.
+clients")))These clients are known as lightweight clients.
 
 ((("Bitcoin nodes", "mining nodes")))((("mining and consensus", "mining
 nodes")))((("Proof-of-Work algorithm")))((("mining and consensus",
@@ -518,29 +518,27 @@ retrieving any missing blocks happens any time a node has been offline for
 an extended period of time.
 
 [[spv_nodes]]
-=== Simplified Payment Verification (SPV) Nodes
+=== Lightweight Clients
 
-((("bitcoin network", "SPV clients", id="BNspvnodes08")))((("bitcoin
+Many Bitcoin clients are designed to run on space- and
-nodes", "SPV clients", id="BNospv08")))((("simple-payment-verification
-(SPV)", id="simple08")))Many Bitcoin clients are designed to run on space- and
 power-constrained devices, such as smartphones, tablets, or embedded
 systems. For such devices, a _simplified payment verification_ (SPV)
 method is used to allow them to operate without validating the full
-blockchain. These types of clients are called SPV clients or lightweight
+blockchain. These types of clients are called lightweight
 clients.
 
-SPV clients download only the block headers and do not download the
+Lightweight clients download only the block headers and do not download the
 transactions included in each block. The resulting chain of headers,
 without transactions, is about 10,000 times smaller than the full blockchain.
-SPV clients cannot construct a full picture of all the UTXOs that are
+Lightweight clients cannot construct a full picture of all the UTXOs that are
 available for spending because they do not know about all the
-transactions on the network. SPV clients verify transactions using a
+transactions on the network. Instead, they verify transactions using a
 slightly different method that relies on peers to provide partial views
 of relevant parts of the blockchain on demand.
 
 As an analogy, a full node is like a tourist in a strange city, equipped
-with a detailed map of every street and every address. By comparison, an
+with a detailed map of every street and every address. By comparison, a
-SPV node is like a tourist in a strange city asking random strangers for
+lightweight client is like a tourist in a strange city asking random strangers for
 turn-by-turn directions while knowing only one main avenue. Although
 both tourists can verify the existence of a street by visiting it, the
 tourist without a map doesn't know what lies down any of the side
@@ -550,39 +548,39 @@ a dozen other "23 Church Street" addresses in the city and whether this
 is the right one. The mapless tourist's best chance is to ask enough
 people and hope some of them are not trying to mug him.
 
-SPV verifies transactions by reference to their _depth_ in the blockchain. Whereas a full node will construct a fully verified chain of thousands of blocks and millions of transactions reaching down the blockchain (back in time) all the way to the genesis block, an SPV node will verify the proof of work of all blocks (but not whether the blocks and all of their transactions are valid) and link that chain to the transaction of interest.
+Lightweight clients verify transactions by reference to their _depth_ in the blockchain. Whereas a full node will construct a fully verified chain of thousands of blocks and millions of transactions reaching down the blockchain (back in time) all the way to the genesis block, a lightweight client will verify the proof of work of all blocks (but not whether the blocks and all of their transactions are valid) and link that chain to the transaction of interest.
 
 For example, when examining a transaction in block 800,000, a full node
 verifies all 800,000 blocks down to the genesis block and builds a full
 database of UTXOs, establishing the validity of the transaction by
-confirming that the transaction exists and its output remains unspent. A SPV client can
+confirming that the transaction exists and its output remains unspent. A lightweight client can
 only verify that the transaction exists. The client establishes a link
 between the transaction and the block that contains it, using a _merkle
-path_ (see <<merkle_trees>>). Then, the SPV client waits until it sees the
+path_ (see <<merkle_trees>>). Then, the lightweight client waits until it sees the
 six blocks 800,001 through 800,006 piled on top of the block containing
 the transaction and verifies it by establishing its depth under blocks
 800,006 to 800,001. The fact that other nodes on the network accepted
 block 800,000 and that miners did the necessary work to produce six more blocks
 on top of it is proof, by proxy, that the transaction actually exists.
 
-An SPV client cannot normally be persuaded that a transaction exists in a block
+A lightweight client cannot normally be persuaded that a transaction exists in a block
-when the transaction does not in fact exist. The SPV client establishes
+when the transaction does not in fact exist. The lightweight client establishes
 the existence of a transaction in a block by requesting a merkle path
 proof and by validating the Proof-of-Work in the chain of blocks.
-However, a transaction's existence can be "hidden" from an SPV client. An
+However, a transaction's existence can be "hidden" from a lightweight client. A
-SPV client can definitely prove that a transaction exists but cannot
+lightweight client can definitely prove that a transaction exists but cannot
 verify that a transaction, such as a double-spend of the same UTXO,
 doesn't exist because it doesn't have a record of all transactions. This
 vulnerability can be used in a denial-of-service attack or for a
-double-spending attack against SPV clients. To defend against this, an SPV
+double-spending attack against lightweight clients. To defend against this, a lightweight
 client needs to connect randomly to several clients, to increase the
 probability that it is in contact with at least one honest node. This
-need to randomly connect means that SPV clients also are vulnerable to
+need to randomly connect means that lightweight clients also are vulnerable to
 network partitioning attacks or Sybil attacks, where they are connected
 to fake nodes or fake networks and do not have access to honest nodes or
 the real Bitcoin network.
 
-For many practical purposes, well-connected SPV clients are secure enough,
+For many practical purposes, well-connected lightweight clients are secure enough,
 striking a balance between resource needs, practicality, and security.
 For infallible security, however, nothing beats running a full
 node.
@@ -591,33 +589,33 @@ node.
 ====
 A full node verifies a transaction by checking the entire chain of
 thousands of blocks below it in order to guarantee that the UTXO exists
-and is not spent, whereas an SPV client only proves that a transaction
+and is not spent, whereas an lightweight client only proves that a transaction
 exists and checks that the block containing that transaction is
 buried by a handful of blocks above it.
 ====
 
 To get the block headers it needs to verify a transaction is part of the
-chain, SPV clients use a +getheaders+ message.
+chain, lightweight clients use a +getheaders+ message.
 The responding peer will send up to 2,000 block headers
 using a single +headers+ message.  See the illustration in
 <<spv_synchronization>>.
 
 [[spv_synchronization]]
-.SPV client synchronizing the block headers
+.Lightweight client synchronizing the block headers
-image::images/mbc2_0807.png["SPVSynchronization"]
+image::images/mbc2_0807.png["Header synchronization"]
 
-Block headers allow an SPV client to verify that any individual block
+Block headers allow a lightweight client to verify that any individual block
 belongs to the blockchain with the most proof of work, but they don't
 tell the client which blocks contain transactions that are interesting to
 its wallet.  The client could download every block and check, but that
 would use a large fraction of the resources it would take to run a full
 node, so developers have looked for other ways to solve the problem.
 
-Shortly after the introduction of SPV/lightweight clients, Bitcoin
+Shortly after the introduction of lightweight clients, Bitcoin
 developers added a feature called _bloom filters_ in an attempt to
-reduce the bandwidth that SPV clients needed to use to learn about their
+reduce the bandwidth that lightweight clients needed to use to learn about their
 incoming and outgoing transactions.
-Bloom filters allow SPV clients to receive a subset of
+Bloom filters allow lightweight clients to receive a subset of
 the transactions without directly revealing precisely which addresses they are
 interested in, through a filtering mechanism that uses probabilities
 rather than fixed patterns.((("", startref="BNspvnodes08")))((("",
@@ -632,7 +630,7 @@ id="privacy08")))((("security", "maintaining privacy",
 id="Sprivacy08")))A bloom filter is a probabilistic search filter, a way
 to describe a desired pattern without specifying it exactly. Bloom
 filters offer an efficient way to express a search pattern while
-protecting privacy. They are used by SPV clients to ask their peers for
+protecting privacy. They are used by lightweight clients to ask their peers for
 transactions matching a specific pattern, without revealing exactly
 which addresses, keys, or transactions they are searching for.
 
@@ -651,10 +649,10 @@ more possible addresses and better privacy, but many of the results are
 irrelevant. If she asks for a very specific pattern, she gets fewer
 results but loses privacy.
 
-Bloom filters serve this function by allowing an SPV client to specify a
+Bloom filters serve this function by allowing a lightweight client to specify a
 search pattern for transactions that can be tuned toward precision or
 privacy. A more specific bloom filter will produce accurate results, but
-at the expense of revealing what patterns the SPV client is interested in,
+at the expense of revealing what patterns the lightweight client is interested in,
 thus revealing the addresses owned by the user's wallet. A less specific
 bloom filter will produce more data about more transactions, many
 irrelevant to the client, but will allow the client to maintain better
@@ -748,23 +746,23 @@ pattern is definitely not a match.
 .Testing the existence of pattern "Y" in the bloom filter. The result is a definitive negative match, meaning "Definitely Not!"
 image::images/mbc2_0812.png[]
 
-=== How SPV clients Use Bloom Filters
+=== How Lightweight Clients Use Bloom Filters
 
 Bloom filters are used to filter the transactions (and blocks containing
-them) that an SPV client receives from its peers, selecting only
+them) that a lightweight client receives from its peers, selecting only
-transactions of interest to the SPV client without revealing exactly which
+transactions of interest to the lightweight client without revealing exactly which
 addresses or keys it is interested in.
 
-((("transaction IDs (txid)")))An SPV client will initialize a bloom filter
+((("transaction IDs (txid)")))A lightweight client will initialize a bloom filter
 as "empty"; in that state the bloom filter will not match any patterns.
-The SPV client will then make a list of all the addresses, keys, and
+The lightweight client will then make a list of all the addresses, keys, and
 hashes that it is interested in. It will do this by extracting the
 public key hash and script hash and transaction IDs from any UTXO
-controlled by its wallet. The SPV client then adds each of these to the
+controlled by its wallet. The lightweight client then adds each of these to the
 bloom filter, so that the bloom filter will "match" if these patterns
 are present in a transaction, without revealing the patterns themselves.
 
-((("Bitcoin nodes", "full nodes")))The SPV client will then send a
+((("Bitcoin nodes", "full nodes")))The lightweight client will then send a
 +filterload+ message to the peer, containing the bloom filter to use on
 the connection. On the peer, bloom filters are checked against each
 incoming transaction. The full node checks several parts of the
@@ -790,7 +788,7 @@ matching the filter and a merkle path (see <<merkle_trees>>) for each
 matching transaction. The peer will then also send +tx+ messages
 containing the transactions matched by the filter.
 
-As the full node sends transactions to the SPV client, the SPV client
+As the full node sends transactions to the lightweight client, the lightweight client
 discards any false positives and uses the correctly matched transactions
 to update its UTXO set and wallet balance. As it updates its own view of
 the UTXO set, it also modifies the bloom filter to match any future
@@ -804,7 +802,7 @@ client can send a +filterclear+ message. Because it is not possible to
 remove a pattern from a bloom filter, a client has to clear and resend a
 new bloom filter if a pattern is no longer desired.
 
-The network protocol and bloom filter mechanism for SPV clients is defined
+The network protocol and bloom filter mechanism for lightweight clients is defined
 in http://bit.ly/1x6qCiO[BIP37 (Peer Services)].((("",
 startref="BNebloom08")))((("", startref="bloom08")))
 
@@ -827,7 +825,7 @@ which could lead to denial-of-service attacks.
 For both of those reasons, Bitcoin Core eventually limited support for
 bloom filters to only clients on IP addresses that were explicitly
 allowed by the node operator.  This meant that an alternative method for
-helping SPV clients find their transactions was needed.
+helping lightweight clients find their transactions was needed.
 
 === Compact Block Filters
 
@@ -858,7 +856,7 @@ block from a different peer, making it harder for full nodes to connect
 transactions belonging to a single client across multiple blocks.
 
 This idea for server-generated filters doesn't offer perfect privacy,
-it still places some costs on full nodes (and it does require SPV
+it still places some costs on full nodes (and it does require lightweight
 clients use more bandwidth for the block download), and the filters can
 only be used for confirmed transactions (not unconfirmed transactions),
 but it is much more private and reliable than BIP37 client-requested
@@ -1135,19 +1133,19 @@ lightweight client to download an 80-byte block header, a (usually)
 small coinbase transaction, and the filter for that block to receive
 strong evidence that the filter was accurate.
 
-=== SPV Clients and Privacy
+=== Lightweight Clients and Privacy
 
-Clients that implement SPV have weaker privacy than a full node. A full
+Lightweight clients have weaker privacy than a full node. A full
 node downloads all transactions and therefore reveals no information
-about whether it is using some address in its wallet. An SPV client
+about whether it is using some address in its wallet. A lightweight client
 only downloads transactions that are related to its wallet in some way.
 
-Bloom filters and compact block filters are a way to reduce the loss of privacy. Without them, an
+Bloom filters and compact block filters are a way to reduce the loss of privacy. Without them, a
-SPV client would have to explicitly list the addresses it was interested
+lightweight client would have to explicitly list the addresses it was interested
 in, creating a serious breach of privacy. However, even with
-filters, an adversary monitoring the traffic of an SPV client or
+filters, an adversary monitoring the traffic of a lightweight client or
 connected to it directly as a node in the P2P network may be able to collect enough
-information over time to learn the addresses in the wallet of the SPV
+information over time to learn the addresses in the wallet of the lightweight
 client.
 
 === Encrypted and Authenticated Connections

ch09.asciidoc

@@ -494,34 +494,32 @@ With merkle trees, a node can download just the block headers (80
 bytes per block) and still be able to identify a transaction's inclusion
 in a block by retrieving a small merkle path from a full node, without
 storing or transmitting the vast majority of the blockchain.
-Clients that do not maintain a full
+Clients that do not fully validate transactions, called lightweight
-blockchain, called simplified payment verification (SPV) client, use
+clients, use merkle paths to verify transactions without downloading
-merkle paths to verify transactions without downloading full blocks.
+full blocks.
 
-//FIXME: stretch goal to minimize use of "SPV" in the book
+=== Merkle Trees and Lightweight Clients
-=== Merkle Trees and Simplified Payment Verification (SPV)
 
-((("simple-payment-verification (SPV)")))((("bitcoin nodes", "SPV
+Merkle trees are used extensively by lightweight clients. Lightweight clients don't
-clients")))Merkle trees are used extensively by SPV clients. SPV clients don't
 have all transactions and do not download full blocks, just block
 headers. In order to verify that a transaction is included in a block,
 without having to download all the transactions in the block, they use
 a merkle path.
 
-Consider, for example, an SPV client that is interested in incoming
+Consider, for example, a lightweight client that is interested in incoming
-payments to an address contained in its wallet. The SPV client will
+payments to an address contained in its wallet. The lightweight client will
 establish a bloom filter (see <<bloom_filters>>) on its connections to
 peers to limit the transactions received to only those containing
 addresses of interest. When a peer sees a transaction that matches the
 bloom filter, it will send that block using a +merkleblock+ message. The
 +merkleblock+ message contains the block header as well as a merkle path
 that links the transaction of interest to the merkle root in the block.
-The SPV client can use this merkle path to connect the transaction to the
+The lightweight client can use this merkle path to connect the transaction to the
-block and verify that the transaction is included in the block. The SPV
+block and verify that the transaction is included in the block. The lightweight
 client also uses the block header to link the block to the rest of the
 blockchain. The combination of these two links, between the transaction
 and block, and between the block and blockchain, proves that the
-transaction is recorded in the blockchain. All in all, the SPV client will
+transaction is recorded in the blockchain. All in all, the lightweight client will
 have received less than a kilobyte of data for the block header and
 merkle path, an amount of data that is more than a thousand times less
 than a full block (about 2 megabytes currently).((("",

chapters/transactions.adoc

@@ -1087,7 +1087,7 @@ unusual problems in software that's not designed to expect them.
 //   - UTXO model theory?
 // Coin selection
 // Change
-// Inability for SPV clients to get old UTXOs
+// Inability for lightweight clients to get old UTXOs
 
 === Weight and Vbytes
 

glossary.asciidoc

@@ -220,7 +220,7 @@ SHA::
     The Secure Hash Algorithm or SHA is a family of cryptographic hash functions published by the National Institute of Standards and Technology (NIST).
 
 Simplified Payment Verification (SPV)::
-    SPV or simplified payment verification is a method for verifying particular transactions were included in a block without downloading the entire block. The method is used by some lightweight Bitcoin clients.
+    A method for verifying particular transactions were included in a block without downloading the entire block. The method is used by some lightweight Bitcoin clients.
 
 soft fork::
     soft fork or Soft-Forking Change is a temporary fork in the blockchain which commonly occurs when miners using non-upgraded nodes don't follow a new consensus rule their nodes don’t know about.