<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>If the plan is a fix once and for all, then that should be changed too.  It could be set so that it is at least some multiple of the max block size allowed.<br></div></div></div></div></blockquote><div><br></div><div>Well, but RAM is not infinite :-) Effectively what these caps are doing is setting the minimum hardware requirements for running a Bitcoin node.</div><div><br></div><div>That&#39;s OK by me - I don&#39;t think we are actually going to exhaust the hardware abilities of any reasonable computer any time soon, but still, having the software recognise the finite nature of a computing machine doesn&#39;t seem unwise.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>That system can send a block of any size.  It would require a change to the processing of any merkleblocks received.</div></div></div></div></blockquote><div><br></div><div>Not &quot;any&quot; size because, again, the remote node must buffer things up and have the transaction data actually in memory in order to digest it. But a much larger size, yes.</div><div><br></div><div>However, that&#39;s a bigger change. </div></div></div></div>