<div dir="ltr">&gt; <span class="gmail-im">&gt; <span style="font-size:12.8px">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.</span><div style="font-size:12.8px" dir="auto" class="gmail_extra"><br></div></span><div style="font-size:12.8px" class="gmail_extra">&gt; 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?</div><div style="font-size:12.8px" dir="auto" class="gmail_extra"><br></div><div style="font-size:12.8px" class="gmail_extra">It&#39;s a political assessment. Full nodes are the ultimate arbiters of consensus. When a contentious change is suggested, only the full nodes have the power to either accept or reject this contentious change. If home users are not running their own full nodes, then home users have to trust and rely on other, more powerful nodes to represent them. Of course, the more powerful nodes, simply by nature of having more power, are going to have different opinions and objectives from the users. And it&#39;s impossible for 5000 nodes to properly represent the views of 5,000,000 users. Users running full nodes is important to prevent political hijacking of the Bitcoin protocol. Running a full node yourself is the only way to guarantee (in the absence of trust - which Bitcoin is all about eliminating trust) that changes you are opposed to are not introduced into the network.<br><br>&gt; <span class="gmail-im"></span>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. <br><br></div><div style="font-size:12.8px" class="gmail_extra">This statement is not true for home users, it is true for datacenter nodes. For home users, 200 GB of bandwidth and 500 GB of bandwidth largely have the exact same cost. I pay a fixed amount of money for my internet, and if I use 500 GB the cost is identical to if I use 200 GB. So long as bandwidth is kept under my home bandwidth cap, bandwidth for home nodes is _free_.<br><br>Similarly, disk space may only be $2/TB in bulk, but as a home user I have a $1000 computer with 500 GB of total storage, 100 GB seems (psychologically) to cost a lot closer to $200 than to $2. And if I go out and buy an extra drive to support Bitcoin, it&#39;s going to cost about $50 no matter what drive I pick, because that&#39;s just how much you have to spend to get a drive. The fact that I get an extra 900 GB that I&#39;m not using is irrelevant - I spent $50 explicitly so I could run a bitcoin node.<br><br></div><div style="font-size:12.8px" class="gmail_extra">The financials of home nodes follow a completely different math than the costs you are citing by quoting datacenter prices.<br><br>&gt; I don&#39;t know how to evaluate the impacts of RAM or CPU usage, or 
consequently electricity usage for a node yet.  I&#39;m open to quantifying 
any of those if there&#39;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.<br><br></div><div style="font-size:12.8px" class="gmail_extra">Many home machines only have 4GB of RAM. (I am acutely aware of this because my own software consumes about 3.5GB of RAM, which means all of our users stuck at 4 GB cannot use my software and Chrome at the same time). 0.14 uses more than 1 GB of RAM. This I think is not really a problem for most people, but it becomes a problem if the amount of RAM required grows enough that they can&#39;t have all of their programs open at the same time. 1GB I think is really the limit you&#39;d want to have before you&#39;d start seeing users choose not to run nodes simply because they&#39;d rather have 300 tabs open instead.<br><br></div><div style="font-size:12.8px" class="gmail_extra">CPU usage I think is pretty minimal. Your node is pretty busy during IBD which is annoying but tolerable. And during normal usage a user isn&#39;t even going to notice. Same for electricity. They aren&#39;t going to notice at the end of the month if their electricity bill is a dollar higher because of Bitcoin.<br><br>&gt; <span style="font-size:12.8px">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&#39;s crypto-currency market
 share.  Even if you are right, that&#39;s hardly a tradeoff not worth 
thoroughly investigating from every angle, the consequences could be 
just as dire for Bitcoin <span tabindex="0" class="gmail-aBn"><span class="gmail-aQJ">in 10 years</span></span> as it would be if we made ourselves vulnerable.<br><br></span></div><div style="font-size:12.8px" class="gmail_extra"><span style="font-size:12.8px">This is very much worth considering. If transaction fees are so high that there is no use case at all for people unwilling to buy extra hardware for Bitcoin (a dedicated node or whatever), then there is no longer a reason to worry about these people as users. However, I think the fees would have to get in the $50 range for that to start to be the case. When talking about emergency funds - that is, $10k+ that you keep in case your government defaults, hyperinflates, seizes citizen assets, etc. etc. (situations that many Bitcoin users today have to legitimately worry about), then you are going to be making a few transactions per year at most, and the cost of fees on a home node may be $150 / yr, while the cost of dedicated hardware might be $150/yr ($600 box amortized over 4 years). We are two orders of magnitude away from this type of fee pressure, so I think it continues to make sense to be considering the home nodes as the target that we want to hit.<br><br>&gt;  </span>What about periodically committing the entire UTXO set 
to a special checkpoint block which becomes the new de facto Genesis 
block? <br><div dir="auto"><br></div></div><div style="font-size:12.8px" class="gmail_extra">This should be discussed in another thread but I don&#39;t think I&#39;m alone in saying that I think this could actually be done in a secure / safe / valuable way if you did it correctly. It would reduce bandwidth pressure on archive nodes, reduce disk pressure on full nodes, and imo make for a more efficient network overall.<br></div><div style="font-size:12.8px" class="gmail_extra"><br></div></div>