{"type":"rich","version":"1.0","author_name":"npub149tvqh6gesh22h60jrehl5clrxscx6q65wznq9ty6pae8sxq00esg5vasy","author_url":"https://nostr.ae/npub149tvqh6gesh22h60jrehl5clrxscx6q65wznq9ty6pae8sxq00esg5vasy","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2017-03-29\n📝 Original message:\u003e Pruned nodes are not the default configuration, if it was the default\nconfiguration then I think you would see far more users running a pruned\nnode.\n\nDefault configurations aren't a big enough deal to factor into the critical\ndiscussion of node costs versus transaction fee cost.  Default\nconfigurations can be changed, and if nodes are negatively affected by a\ndefault configuration, there will be an abundance of information about how\nto correct that effect by turning on pruning.  Bitcoin can't design with\nthe assumption that people can't google - If we wanted to cater to that\npopulation group right now, we'd need 100x the blocksize at least.\n\n\u003e But that would also substantially increase the burden on archive nodes.\n\nThis is already a big problem from the measurements I've been looking at.\nThere are alternatives that need to be considered there as well.  If we\nlimit ourselves to not changing the syncing process for most users, the\nblocksize limit debate changes drastically.  Hard drive costs, CPU costs,\npropagation times... none of those things matter because the cost of sync\nbandwidth is so incredibly high even now ($130ish per month, see other\nemail).  Even if we didn't increase the blocksize any more than segwit,\nwe're already seeing sync costs being shifted onto fewer nodes - I.e., Luke\nJr's scan finding ~50k nodes online but only 7k of those show up on sites\nlike bitnodes.21.co.  Segwit will shift it further until the few nodes\nproviding sync limit speeds and/or max out on connections, providing no\nfully-sync'd nodes for a new node to connect to. Then wallet providers /\nnode software will offer a solution - A bundled utxo checkpoint that\nremoves the need to sync.  This slightly increases centralization, and\nincreases centralization more if core were to adopt the same approach.\n\nThe advantage would be tremendous for such a simple solution - Node costs\nwould drop by a full order of magnitude for full nodes even today, more\nwhen archival nodes are more restricted, history is bigger, and segwit\nblocksizes are in effect, and then blocksizes could be safely increased by\nnearly the same order of magnitude, increasing the utility of bitcoin and\nthe number of people that can effectively use it.\n\nAnother, much more complicated option is for the node sync process to\nfunction like a tor network.  A very small number of seed nodes could send\ndata on to only other nodes with the highest bandwidth available(and good\nretention policy, i.e. not tightly pruning as they sync), who then spread\nit out further and so on.  That's complicated though, because as far as I\nknow the syncing process today has no ability to exchange a selfish syncing\nnode for a high performing syncing node.  I'm not even sure - will a\nsyncing node opt to sync from a different node that, itself, isn't fully\nsync'd but is farther ahead?\n\nAt any rate, syncing bandwidth usage is a critical problem for future\ngrowth and is solvable.  The upsides of fixing it are huge, though.\n\nOn Wed, Mar 29, 2017 at 9:25 AM, David Vorick via bitcoin-dev \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e\n\u003e On Mar 29, 2017 12:20 PM, \"Andrew Johnson\" \u003candrew.johnson83 at gmail.com\u003e\n\u003e wrote:\n\u003e\n\u003e What's stopping these users from running a pruned node?  Not every node\n\u003e needs to store a complete copy of the blockchain.\n\u003e\n\u003e\n\u003e Pruned nodes are not the default configuration, if it was the default\n\u003e configuration then I think you would see far more users running a pruned\n\u003e node.\n\u003e\n\u003e But that would also substantially increase the burden on archive nodes.\n\u003e\n\u003e\n\u003e Further discussion about disk space requirements should be taken to\n\u003e another thread.\n\u003e\n\u003e\n\u003e\n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170329/6593ee82/attachment.html\u003e"}