Published on: 2012-01-05T23:30:16+00:00
In this discussion, two topics are explored: transaction pruning and simplified payment verification (SPV) mode. Transaction pruning, also known as "stubbing," focuses on saving disk space without affecting the initial chain download bandwidth or time. On the other hand, SPV clients can download only chain headers with no bodies, which reduces the setup time. However, this method still requires regular signed checkpoints from a trusted developer and a circular block store for bounded overheads.The merkle tree remains useful in SPV clients as it allows them to receive only transactions of interest while maintaining similar assurances to downloading full blocks. Contrary to popular belief, SPV clients do not rely on the "number of blocks on top" to determine validity. Instead, they look for the best available chain. If an SPV node has access to the P2P network and is communicating with a user, it can be defrauded as long as it dominates the network's hash power through a 51% attack. However, once the network dominance ends, the correct chain will catch up, exposing the fraud to the SPV user.In a conversation between Gregory Maxwell and an unknown person on January 2, 2012, they discuss the potential of using a Bitcoin transaction to double-spend coins. The unknown person suggests that if a node controls the private keys for a transaction and it makes it into the chain, the transaction can be assumed unspent after being buried in a few blocks. However, Gregory raises concerns about attackers using a faked block sequence to target multiple clients with several double-spend transactions in the first faked block. This would spread the cost over multiple attacks. Simply checking the transaction value may not be sufficient, and determining the difficulty for those blocks adds further complexity.In an email conversation dated January 2, 2012, Elden Tyrell and Christian Decker discuss the necessity of full blocks to detect usable inputs for future outgoing transactions. Tyrell believes that a paranoid client cannot confirm receipt of coins without an unstubbed copy of the entire chain, ensuring that incoming coins haven't already been spent. However, Decker disagrees, stating that if a node controls the private keys and the transaction makes it into the chain, it can be safely assumed unspent after being buried in a few blocks. This concept is at the core of Simplified Payment Verification (SPV) nodes. Decker suggests that the system could be extended to allow SPV nodes to perform this function for transactions that aren't their own.In another conversation between Christian Decker and an individual, it is discussed that full blocks are necessary to detect usable inputs for future outgoing transactions. A paranoid client requires an unstubbed copy of the entire blockchain to confirm receipt of coins because incoming coins may have already been spent. While a stubbed chain can be used for other actions, such as sending coins, confirmation of receipt necessitates the full unstubbed chain.For a newly created wallet, downloading the chain with transactions is not necessary initially, as it only has new key-pairs and no incoming transactions. However, later on, full blocks would be required to detect usable inputs for future outgoing transactions. Validating the chain itself can be done without the transactions, as long as the very last blocks are verified. Satoshi's paper mentions reducing storage requirements by deleting spent transaction outputs, but this technique does not reduce the bandwidth needed for the initial chain download by a high-security client that doesn't trust its peers. A paranoid client booting up for the first time needs an unstubbed chain to ensure each transaction's inputs are unspent and their sum exceeds the outputs (unless it's a coinbase). By accepting stubbed blocks only when the sum of difficulties in subsequent blocks exceeds a certain number N, the cost of attacking the client can be made prohibitively expensive by selecting a large enough N.While Satoshi's paper suggests reducing storage requirements by deleting spent transaction outputs, this technique does not address the bandwidth needed for the initial chain download by a high-security client that doesn't trust its peers. The validation rule for blocks in the blockchain is to trust the longest valid chain. A block is considered valid if each transaction's inputs are unspent and their sum exceeds the outputs, unless it's a coinbase. Stubbed out transactions lacking inputs and being non-coinbases cannot undergo this validation process. Therefore, a paranoid client starting up for the first time requires an unstubbed chain. However, by accepting stubbed blocks only when the sum of difficulties in subsequent blocks exceeds a certain number N, the client can be protected from attacks by choosing a sufficiently large N. It's important to note that these techniques aim to reduce storage requirements rather than the initial chain download bandwidth for a high-security client that distrusts its peers.
Updated on: 2023-08-01T02:51:11.262429+00:00