Author: Alan Reiner 2011-12-18 18:06:09
Published on: 2011-12-18T18:06:09+00:00
The discussion revolves around the idea of headers-only clients in Bitcoin's security model. A headers-only client is better than trusting anyone since an attacker needs more than 50% of the network's computational power to trick such clients. To keep everyone as a full node, hardware costs would need to go down so that all nodes can handle sufficient transactions to meet demand. If hardware doesn't become cheap enough quickly enough, either some people would be unable to handle being full nodes, or the max block size wouldn't rise enough to meet demand and transaction fees would become noncompetitive.The purpose of having headers built at a constant size and generation rate is to minimize the amount of data required to understand the blockchain while maximizing integrity/security in the presence of untrusted nodes. In fact, a full node (Satoshi client) has the same level of security as a headers-only client because they both base all their verification decisions on computations that end with comparing hashes to the longest-chain headers.However, if an attacker isolates the node entirely and starts feeding it poisoned blocks, then the node is vulnerable with any kind of node, whether full or lightweight. The only issue with a lightweight, headers-only node is that it will have to download an entire block to get one transaction it needs. This problem could be significantly alleviated if nodes can start requesting merkle-trees directly, even without merkle-branch-pruning.There is a critical need to find a way to do blockchain pruning for all nodes. Leaving full verification to a select few deep-pockets nodes in the future opens up all sorts of centralization/power-corporation issues that are contrary to the Bitcoin concept. It is in everyone's best interest to make it as easy as possible for anyone to act as a full node if possible. The current system of minimizing TxOut size is the right one, and TxIns take up zero bytes space in the long-run when taking into account any blockchain pruning/snapshot idea (except for nLocktime/seq transactions where the TxIn might have to be saved).
Updated on: 2023-06-05T00:47:23.769375+00:00