{"type":"rich","version":"1.0","author_name":"npub17ty4mumkv43w8wtt0xsz2jypck0gvw0j8xrcg6tpea25z2nh7meqf4qgyd","author_url":"https://nostr.ae/npub17ty4mumkv43w8wtt0xsz2jypck0gvw0j8xrcg6tpea25z2nh7meqf4qgyd","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2015-07-29\n📝 Original message:I do love history lessons from people who weren't actually there.\n\nLet me correct your misconceptions.\n\n\nInitially there was no block size limit - it was thought that the fee\n\u003e market would naturally develop and would impose economic constraints on\n\u003e growth.\n\n\nThe term \"fee market\" was never used back then, and Satoshi did not ever\npostulate economic constraints on growth. Back then the talk was (quite\nsensibly) how to grow faster, not how to slow things down!\n\n\n\n\u003e But this hypothesis failed after a sudden influx of new uses. It was still\n\u003e too easy to attack the network. This idea had to wait until the network was\n\u003e more mature to handle things.\n\u003e\n\nNo such event happened, and the hypothesis of which you talk never existed.\n\n\n\n\u003e Enter a “temporary” anti-spam measure - a one megabyte block size limit.\n\n\nThe one megabyte limit was nothing to do with anti spam. It was a quick\nkludge to try and avoid the user experience degrading significantly in the\nevent of a \"DoS block\", back when everyone used Bitcoin-Qt. The fear was\nthat some malicious miner would generate massive blocks and make the wallet\ntoo painful to use, before there were any alternatives.\n\nThe plan was to remove it once SPV wallets were widespread. But Satoshi\nleft before that happened.\n\n\nNow on to your claims:\n\n1) We never really got to test things out…a fee market never really got\n\u003e created, we never got to see how fees would really work in practice.\n\u003e\n\nThe limit had nothing to do with fees. Satoshi explicitly wanted free\ntransactions to last as long as possible.\n\n\n\u003e 2) Turns out the vast majority of validation nodes have little if anything\n\u003e to do with mining - validators do not get compensated…validation cost is\n\u003e externalized to the entire network.\n\u003e\n\nSatoshi explicitly envisioned a future where only miners ran nodes, so it\nhad nothing to do with this either.\n\nValidators validate for themselves. Calculating a local UTXO set and then\nnot using it for anything doesn't help anyone. SPV wallets need filtering\nand serving capability, but a computer can filter and serve the chain\nwithout validating it.\n\nThe only purposes non-mining, non-rpc-serving, non-Qt-wallet-sustaining\nfull nodes are needed for with today's network are:\n\n   1. Filtering the chain for bandwidth constrained SPV wallets (nb: you\n   can run an SPV wallet that downloads all transactions if you want). But\n   this could be handled by specialised nodes, just like we always imagined in\n   future not every node will serve the entire chain but only special\n   \"archival nodes\"\n\n   2. Relaying validated transactions so SPV wallets can stick a thumb into\n   the wind and heuristically guess whether a transaction is valid or not.\n   This is useful for a better user interface.\n\n   3. Storing the mempool and filtering/serving it so SPV wallets can find\n   transactions that were broadcast before they started, but not yet included\n   in a block. This is useful for a better user interface.\n\nOutside of serving lightweight P2P wallets there's no purpose in running a\nP2P node if you aren't mining, or using it as a trusted node for your own\noperations.\n\nAnd if one day there aren't enough network nodes being run by volunteers to\nservice all the lightweight wallets, then we can easily create an incentive\nscheme to fix that.\n\n\n3) Miners don’t even properly validate blocks. And the bigger the blocks\n\u003e get, the greater the propensity to skip this step. Oops!\n\u003e\n\nMiners who don't validate have a habit of bleeding money:   that's the\nsystem working as designed.\n\n\n\n\u003e 4) A satisfactory mechanism for thin clients to be able to securely obtain\n\u003e reasonably secure, short proofs for their transactions never materialized.\n\u003e\n\nIt did. I designed it. The proofs are short and \"reasonably secure\" in that\nit would be a difficult and expensive attack to mount.\n\nBut as is so often the case with Bitcoin Core these days, someone who came\nalong much later has retroactively decided that the work done so far fails\nto meet some arbitrary and undefined level of perfection. \"Satisfactory\"\nand \"reasonably secure\" don't mean anything, especially not coming from\nsomeone who hasn't done the work, so why should anyone care about that\nopinion of yours?\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150729/79c8c15d/attachment-0001.html\u003e"}