{"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 When considering what block size is acceptable, the impact of running\nbitcoin in the background on affordable, non-dedicated home-hardware should\nbe a top consideration.\n\nWhy is that a given?  Is there math that outlines what the risk levels are\nfor various configurations of node distributions, vulnerabilities, etc?\nHow does one even evaluate the costs versus the benefits of node costs\nversus transaction fees?\n\n\u003e Disk space I believe is the most significant problem today, with RAM\nbeing the second most significant problem, and finally bandwidth\nconsumption as the third most important consideration. I believe that v0.14\nis already too expensive on all three fronts, and that block size increases\nshouldn't be considered at all until the requirements are reduced (or until\nconsumer hardware is better, but I believe we are talking 3-7 years of\nwaiting if we pick that option).\n\nDisk space is not the largest cost, either today or in the future.  Without\nhistorical checkpointing in some fashion, bandwidth costs are more than 2\norders of magnitude higher cost than every other cost for full listening\nnodes.  With historical syncing discounted(i.e. pruned or nonlistening\nnodes) bandwidth costs are still higher than hard drive costs.\n\n\nToday: Full listening node, 133 peers, measured 1.5 TB/mo of bandwidth\nconsumption over two multi-day intervals.  1,500 GB/month @ ec2 low-tier\nprices = $135/month, 110 GB storage = $4.95.  Similar arguments extend to\nconsumer hardware - Comcast broadband is ~$80/mo depending on region and\ncomes with 1.0 TB cap in most regions, so $120/mo or even $80/mo would be\nin the same ballpark.  A consumer-grade 2GB hard drive is $70 and will last\nfor at least 2 years, so $2.93/month if the hard drive was totally\ndedicated to Bitcoin and $0.16/month if we only count the percentage that\nBitcoin uses.\n\nFor a non-full listening node, ~25 peers I measured around 70 GB/month of\nusage over several days, which is $6.3 per month EC2 or $5.6 proportional\nComcast cost.  If someone isn't supporting syncing, there's not much point\nin them not turning on pruning.  Even if they didn't, a desktop in the $500\nrange typically comes with 1 or 2 TB of storage by default, and without\nsegwit or a blocksize cap increase, 3 years from now the full history will\nonly take up the 33% of the smaller, three year old, budget-range PC hard\ndrive.  Even then if we assume the hard drive price declines of the last 4\nyears hold steady(14%, very low compared to historical gains), 330gb of\ndata only works out to a proportional monthly cost of $6.20 - still\nslightly smaller than his bandwidth costs, and almost entirely removable by\nturning on pruning since he isn't paying to help others sync.\n\nI don't know how to evaluate the impacts of RAM or CPU usage, or\nconsequently electricity usage for a node yet.  I'm open to quantifying any\nof those if there's a method, but it seems absurd that ram could even\nbecome a signficant factor given the abundance of cheap ram nowadays with\nfew programs needing it.  CPU usage and thus electricity costs might become\na factor, I just don't know how to quantify it at various block scales.\nCurrently cpu usage isn't taxing any hardware that I run a node on in any\nway I have been able to notice, not including the syncing process.\n\n\u003e I am also solidly unconvinced that increasing the blocksize today is a\ngood move, even as little as SegWit does.\n\nThe consequence of your logic that holds node operational costs down is\nthat transaction fees for users go up, adoption slows as various use cases\nbecome impractical, price growth suffers, and alt coins that choose lower\nfees over node cost concerns will exhibit competitive growth against\nBitcoin's crypto-currency market share.  Even if you are right, that's\nhardly a tradeoff not worth thoroughly investigating from every angle, the\nconsequences could be just as dire for Bitcoin in 10 years as it would be\nif we made ourselves vulnerable.\n\nAnd even if an altcoin can't take Bitcoin's dominance by lower fees, we\nwill not end up with millions of home users running nodes, ever.  If they\ndid so, that would be orders of magnitude fee market competition, and\ncontinuing increases in price, while hardware costs decline.  If\ntransaction fees go up from space limitations, and they go up even further\nin real-world terms from price increases, while node costs decline,\neventually it will cost more to send a transaction than it does to run a\nnode for a full month.  No home users would send transactions because the\nfee costs would be higher than anything they might use Bitcoin for, and so\nthey would not run a node for something they don't use - Why would they?\nThe cost of letting the ratio between node costs and transaction costs go\nin the extreme favor of node costs would be worse - Lower Bitcoin\nusability, adoption, and price, without any meaningful increase in security.\n\nHow do we evaluate the math on node distributions versus various attack\nvectors?\n\n\n\nOn Wed, Mar 29, 2017 at 8:57 AM, David Vorick via bitcoin-dev \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e\n\u003e On Mar 29, 2017 9:50 AM, \"Martin Lízner via bitcoin-dev\" \u003c\n\u003e bitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e\n\u003e Im tending to believe, that HF is necessary evil now.\n\u003e\n\u003e\n\u003e I will firmly disagree. We know how to do a soft-fork blocksize increase.\n\u003e If it is decided that a block size increase is justified, we can do it with\n\u003e extension blocks in a way that achieves full backwards compatibility for\n\u003e all nodes.\n\u003e\n\u003e Barring a significant security motivation, there is no need to hardfork.\n\u003e\n\u003e I am also solidly unconvinced that increasing the blocksize today is a\n\u003e good move, even as little as SegWit does. It's too expensive for a home\n\u003e user to run a full node, and user-run full nodes are what provide the\n\u003e strongest defence against political manuveuring.\n\u003e\n\u003e When considering what block size is acceptable, the impact of running\n\u003e bitcoin in the background on affordable, non-dedicated home-hardware should\n\u003e be a top consideration.\n\u003e\n\u003e Disk space I believe is the most significant problem today, with RAM being\n\u003e the second most significant problem, and finally bandwidth consumption as\n\u003e the third most important consideration. I believe that v0.14 is already too\n\u003e expensive on all three fronts, and that block size increases shouldn't be\n\u003e considered at all until the requirements are reduced (or until consumer\n\u003e hardware is better, but I believe we are talking 3-7 years of waiting if we\n\u003e pick that option).\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/2e9b6644/attachment-0001.html\u003e"}