I do love history lessons from people who weren't actually there. Let me correct your misconceptions.
Initially there was no block size limit - it was thought that the fee > market would naturally develop and would impose economic constraints on > growth. The term "fee market" was never used back then, and Satoshi did not ever postulate economic constraints on growth. Back then the talk was (quite sensibly) how to grow faster, not how to slow things down! > But this hypothesis failed after a sudden influx of new uses. It was still > too easy to attack the network. This idea had to wait until the network was > more mature to handle things. > No such event happened, and the hypothesis of which you talk never existed. > Enter a “temporary” anti-spam measure - a one megabyte block size limit. The one megabyte limit was nothing to do with anti spam. It was a quick kludge to try and avoid the user experience degrading significantly in the event of a "DoS block", back when everyone used Bitcoin-Qt. The fear was that some malicious miner would generate massive blocks and make the wallet too painful to use, before there were any alternatives. The plan was to remove it once SPV wallets were widespread. But Satoshi left before that happened. Now on to your claims: 1) We never really got to test things out…a fee market never really got > created, we never got to see how fees would really work in practice. > The limit had nothing to do with fees. Satoshi explicitly wanted free transactions to last as long as possible. > 2) Turns out the vast majority of validation nodes have little if anything > to do with mining - validators do not get compensated…validation cost is > externalized to the entire network. > Satoshi explicitly envisioned a future where only miners ran nodes, so it had nothing to do with this either. Validators validate for themselves. Calculating a local UTXO set and then not using it for anything doesn't help anyone. SPV wallets need filtering and serving capability, but a computer can filter and serve the chain without validating it. The only purposes non-mining, non-rpc-serving, non-Qt-wallet-sustaining full nodes are needed for with today's network are: 1. Filtering the chain for bandwidth constrained SPV wallets (nb: you can run an SPV wallet that downloads all transactions if you want). But this could be handled by specialised nodes, just like we always imagined in future not every node will serve the entire chain but only special "archival nodes" 2. Relaying validated transactions so SPV wallets can stick a thumb into the wind and heuristically guess whether a transaction is valid or not. This is useful for a better user interface. 3. Storing the mempool and filtering/serving it so SPV wallets can find transactions that were broadcast before they started, but not yet included in a block. This is useful for a better user interface. Outside of serving lightweight P2P wallets there's no purpose in running a P2P node if you aren't mining, or using it as a trusted node for your own operations. And if one day there aren't enough network nodes being run by volunteers to service all the lightweight wallets, then we can easily create an incentive scheme to fix that. 3) Miners don’t even properly validate blocks. And the bigger the blocks > get, the greater the propensity to skip this step. Oops! > Miners who don't validate have a habit of bleeding money: that's the system working as designed. > 4) A satisfactory mechanism for thin clients to be able to securely obtain > reasonably secure, short proofs for their transactions never materialized. > It did. I designed it. The proofs are short and "reasonably secure" in that it would be a difficult and expensive attack to mount. But as is so often the case with Bitcoin Core these days, someone who came along much later has retroactively decided that the work done so far fails to meet some arbitrary and undefined level of perfection. "Satisfactory" and "reasonably secure" don't mean anything, especially not coming from someone who hasn't done the work, so why should anyone care about that opinion of yours?
_______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
