<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, May 13, 2015 at 6:19 AM, Daniel Kraft <span dir="ltr"><<a href="mailto:d@domob.eu" target="_blank">d@domob.eu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
2) Divide the range of all blocks into intervals with exponentially<br>
growing size. I. e., something like this:<br>
<br>
1, 1, 2, 2, 4, 4, 8, 8, 16, 16, ...<br></blockquote><div><br></div><div>Interesting. This can be combined with the system I suggested.<br><br></div><div>A node broadcasts 3 pieces of information<br><br></div>Seed (16 bits): This is the seed<br><div>M_bits_lsb (1 bit): Used to indicate M during a transition<br>N (7 bits): This is the count of the last range held (or partially held)<br></div><div><br></div><div></div><div></div><div>M = 1 << M_bits<br></div><div><br>M should be set to the lowest power of 2 greater than double the block chain height<br><br></div><div>That gives M = 1 million at the moment. During changing M, some nodes will be using the higher M and others will use the lower M.<br><br></div><div>The M_bits_lsb field allows those to be distinguished.<br><br></div><div>As the block height approaches 512k, nodes can begin to upgrade. For a period around block 512k, some nodes could use M = 1 million and others could use M = 2 million.<br></div><div><br></div><div>Assuming M is around 3 times higher than the block height, then the odds of a start being less than the block height is around 35%. If they runs by 25% each step, then that is approx a double for each hit.<br><br></div><div></div><div>Size(n) = ((4 + (n & 0x3)) << (n >> 2)) * 2.5MB<br><br></div><div>This gives an exponential increase, but groups of 4 are linearly interpolated.<br></div><div><br><b>Size(0) = 10 MB<br></b></div><div>Size(1) = 12.5MB<br></div><div>Size(2) = 15 MB<br></div><div>Size(3) = 17.5MB<br></div><div>Size(4) = 20MB<br></div><div><b>Size(5) = 25MB<br></b></div><div>Size(6) = 30MB<br></div><div>Size(7) = 35MB<br></div><div><b>Size(8) = 40MB<br></b></div><div><br></div><div>Start(n) = Hash(seed + n) mod M <br><br></div><div>A node should store as much of its last start as possible. Assuming start 0, 5, and 8 were "hits" but the node had a max size of 60MB. It can store 0 and 5 and have 25MB left. That isn't enough to store all of run 8, but it should store 25MB of the blocks in run 8 anyway.<br><br></div><div>Size(255) = pow(2, 31) * 17.5MB = 35,840 TB<br><br></div><div>Decreasing N only causes previously accepted runs to be invalidated. <br><br></div><div>When a node approaches a transition point for N, it would select a block height within 25,000 of the transition point. Once it reaches that block, it will begin downloading the new runs that it needs. When updating, it can set N to zero. This spreads out the upgrade (over around a year), with only a small number of nodes upgrading at any time. <br><br></div><div>New nodes should use the higher M, if near a transition point (say within 100,000).<br></div></div></div></div>