rich1.0npub149tvqh6gesh22h60jrehl5clrxscx6q65wznq9ty6pae8sxq00esg5vasyhttps://nostr.ae/npub149tvqh6gesh22h60jrehl5clrxscx6q65wznq9ty6pae8sxq00esg5vasynjumphttps://nostr.ae📅 Original date posted:2017-03-29 📝 Original message:> When considering what block size is acceptable, the impact of running bitcoin in the background on affordable, non-dedicated home-hardware should be a top consideration. Why is that a given? Is there math that outlines what the risk levels are for various configurations of node distributions, vulnerabilities, etc? How does one even evaluate the costs versus the benefits of node costs versus transaction fees? > Disk space I believe is the most significant problem today, with RAM being the second most significant problem, and finally bandwidth consumption as the third most important consideration. I believe that v0.14 is already too expensive on all three fronts, and that block size increases shouldn't be considered at all until the requirements are reduced (or until consumer hardware is better, but I believe we are talking 3-7 years of waiting if we pick that option). Disk space is not the largest cost, either today or in the future. Without historical checkpointing in some fashion, bandwidth costs are more than 2 orders of magnitude higher cost than every other cost for full listening nodes. With historical syncing discounted(i.e. pruned or nonlistening nodes) bandwidth costs are still higher than hard drive costs. Today: Full listening node, 133 peers, measured 1.5 TB/mo of bandwidth consumption over two multi-day intervals. 1,500 GB/month @ ec2 low-tier prices = $135/month, 110 GB storage = $4.95. Similar arguments extend to consumer hardware - Comcast broadband is ~$80/mo depending on region and comes with 1.0 TB cap in most regions, so $120/mo or even $80/mo would be in the same ballpark. A consumer-grade 2GB hard drive is $70 and will last for at least 2 years, so $2.93/month if the hard drive was totally dedicated to Bitcoin and $0.16/month if we only count the percentage that Bitcoin uses. For a non-full listening node, ~25 peers I measured around 70 GB/month of usage over several days, which is $6.3 per month EC2 or $5.6 proportional Comcast cost. If someone isn't supporting syncing, there's not much point in them not turning on pruning. Even if they didn't, a desktop in the $500 range typically comes with 1 or 2 TB of storage by default, and without segwit or a blocksize cap increase, 3 years from now the full history will only take up the 33% of the smaller, three year old, budget-range PC hard drive. Even then if we assume the hard drive price declines of the last 4 years hold steady(14%, very low compared to historical gains), 330gb of data only works out to a proportional monthly cost of $6.20 - still slightly smaller than his bandwidth costs, and almost entirely removable by turning on pruning since he isn't paying to help others sync. I don't know how to evaluate the impacts of RAM or CPU usage, or consequently electricity usage for a node yet. I'm open to quantifying any of those if there's a method, but it seems absurd that ram could even become a signficant factor given the abundance of cheap ram nowadays with few programs needing it. CPU usage and thus electricity costs might become a factor, I just don't know how to quantify it at various block scales. Currently cpu usage isn't taxing any hardware that I run a node on in any way I have been able to notice, not including the syncing process. > I am also solidly unconvinced that increasing the blocksize today is a good move, even as little as SegWit does. The consequence of your logic that holds node operational costs down is that transaction fees for users go up, adoption slows as various use cases become impractical, price growth suffers, and alt coins that choose lower fees over node cost concerns will exhibit competitive growth against Bitcoin's crypto-currency market share. Even if you are right, that's hardly a tradeoff not worth thoroughly investigating from every angle, the consequences could be just as dire for Bitcoin in 10 years as it would be if we made ourselves vulnerable. And even if an altcoin can't take Bitcoin's dominance by lower fees, we will not end up with millions of home users running nodes, ever. If they did so, that would be orders of magnitude fee market competition, and continuing increases in price, while hardware costs decline. If transaction fees go up from space limitations, and they go up even further in real-world terms from price increases, while node costs decline, eventually it will cost more to send a transaction than it does to run a node for a full month. No home users would send transactions because the fee costs would be higher than anything they might use Bitcoin for, and so they would not run a node for something they don't use - Why would they? The cost of letting the ratio between node costs and transaction costs go in the extreme favor of node costs would be worse - Lower Bitcoin usability, adoption, and price, without any meaningful increase in security. How do we evaluate the math on node distributions versus various attack vectors? On Wed, Mar 29, 2017 at 8:57 AM, David Vorick via bitcoin-dev < bitcoin-dev at lists.linuxfoundation.org> wrote: > > On Mar 29, 2017 9:50 AM, "Martin Lízner via bitcoin-dev" < > bitcoin-dev at lists.linuxfoundation.org> wrote: > > Im tending to believe, that HF is necessary evil now. > > > I will firmly disagree. We know how to do a soft-fork blocksize increase. > If it is decided that a block size increase is justified, we can do it with > extension blocks in a way that achieves full backwards compatibility for > all nodes. > > Barring a significant security motivation, there is no need to hardfork. > > I am also solidly unconvinced that increasing the blocksize today is a > good move, even as little as SegWit does. It's too expensive for a home > user to run a full node, and user-run full nodes are what provide the > strongest defence against political manuveuring. > > When considering what block size is acceptable, the impact of running > bitcoin in the background on affordable, non-dedicated home-hardware should > be a top consideration. > > Disk space I believe is the most significant problem today, with RAM being > the second most significant problem, and finally bandwidth consumption as > the third most important consideration. I believe that v0.14 is already too > expensive on all three fronts, and that block size increases shouldn't be > considered at all until the requirements are reduced (or until consumer > hardware is better, but I believe we are talking 3-7 years of waiting if we > pick that option). > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170329/2e9b6644/attachment-0001.html>