<div dir="ltr"><div class="gmail_extra">Let me make sure I understand this proposal:</div><div class="gmail_extra"><br></div><div class="gmail_extra"><div class="gmail_quote">On Fri, May 8, 2015 at 11:36 PM, Gregory Maxwell <span dir="ltr">&lt;<a href="mailto:gmaxwell@gmail.com" target="_blank">gmaxwell@gmail.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div id=":1zn" class="" style="overflow:hidden">(*) I believe my currently favored formulation of general dynamic control<br>
idea is that each miner expresses in their coinbase a preferred size<br>
between some minimum (e.g. 500k) and the miner&#39;s effective-maximum;<br>
the actual block size can be up to the effective maximum even if the<br>
preference is lower (you&#39;re not forced to make a lower block because you<br>
stated you wished the limit were lower).  There is a computed maximum<br>
which is the 33-rd percentile of the last 2016 coinbase preferences<br>
minus computed_max/52 (rounding up to 1) bytes-- or 500k if thats<br>
larger. The effective maximum is X bytes more, where X on the range<br>
[0, computed_maximum] e.g. the miner can double the size of their<br>
block at most. If X &gt; 0, then the miners must also reach a target<br>
F(x/computed_maximum) times the bits-difficulty; with F(x) = x^2+1  ---<br>
so the maximum penalty is 2, with a quadratic shape;  for a given mempool<br>
there will be some value that maximizes expected income.  (obviously all<br>
implemented with precise fixed point arithmetic).   The percentile is<br>
intended to give the preferences of the 33% least preferring miners a<br>
veto on increases (unless a majority chooses to soft-fork them out). The<br>
minus-comp_max/52 provides an incentive to slowly shrink the maximum<br>
if its too large-- x/52 would halve the size in one year if miners<br>
were doing the lowest difficulty mining. The parameters 500k/33rd,<br>
-computed_max/52 bytes, and f(x)  I have less strong opinions about;<br>
and would love to hear reasoned arguments for particular parameters.</div></blockquote></div><br>I&#39;m going to try to figure out how much transaction fee a transaction would have to pay to bribe a miner to include it. Greg, please let me know if I&#39;ve misinterpreted the proposed algorithm. And everybody, please let me know if I&#39;m making a bone-headed mistake in how I&#39;m computing anything:</div><div class="gmail_extra"><br></div><div class="gmail_extra">Lets say miners are expressing a desire for 600,000 byte blocks in their coinbases.</div><div class="gmail_extra"><br></div><div class="gmail_extra">computed_max = 600,000 - 600,000/52 = 588,462 bytes.</div><div class="gmail_extra">  --&gt; this is about 23 average-size (500-byte) transactions less than 600,000.</div><div class="gmail_extra">effective_max = 1,176,923</div><div class="gmail_extra"><br></div><div class="gmail_extra">Lets say I want to maintain status quo at 600,000 bytes; how much penalty do I have?</div><div class="gmail_extra">((600,000-588,462)/588,462)^2 + 1 = 1.00038</div><div class="gmail_extra"><br></div><div class="gmail_extra">How much will that cost me?</div><div class="gmail_extra">The network is hashing at 310PetaHash/sec right now.</div><div class="gmail_extra">Takes 600 seconds to find a block, so 186,000PH per block</div><div class="gmail_extra">186,000 * 0.00038 = 70 extra PH</div><div class="gmail_extra"><br></div><div class="gmail_extra">If it takes 186,000 PH to find a block, and a block is worth 25.13 BTC (reward plus fees), that 70 PH costs:</div><div class="gmail_extra">(25.13 BTC/block / 186,000 PH/block) * 70 PH = 0.00945 BTC</div><div class="gmail_extra">or at $240 / BTC:  $2.27</div><div class="gmail_extra"><br></div><div class="gmail_extra">... so average transaction fee will have to be about ten cents ($2.27 spread across 23 average-sized transactions) for miners to decide to stay at 600K blocks. If they fill up 588,462 bytes and don&#39;t have some ten-cent-fee transactions left, they should express a desire to create a 588,462-byte-block and mine with no penalty.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Is that too much?  Not enough?  Average transaction fees today are about 3 cents per transaction.</div><div class="gmail_extra">I created a spreadsheet playing with the parameters:</div><div class="gmail_extra">  <a href="https://docs.google.com/spreadsheets/d/1zYZfb44Uns8ai0KnoQ-LixDwdhqO5iTI3ZRcihQXlgk/edit?usp=sharing">https://docs.google.com/spreadsheets/d/1zYZfb44Uns8ai0KnoQ-LixDwdhqO5iTI3ZRcihQXlgk/edit?usp=sharing</a></div><div class="gmail_extra"><br></div><div class="gmail_extra">&quot;We&quot; could tweak the constants or function to get a transaction fee we think is reasonable... but we really shouldn&#39;t be deciding whether transaction fees are too high, too low, or just right, and after thinking about this for a while I think any algorithm that ties difficulty to block size is just a complicated way of dictating minimum fees.</div><div class="gmail_extra"><br></div><div class="gmail_extra">As for some other dynamic algorithm: OK with me. How do we get consensus on what the best algorithm is? I&#39;m ok with any &quot;don&#39;t grow too quickly, give some reasonable-percentage-minority of miners the ability to block further increases.&quot;</div><div class="gmail_extra"><br></div><div class="gmail_extra"><div class="gmail_extra">Also relevant here:</div>&quot;The curious task of economics is to demonstrate to men how little they really know about what they imagine they can design.&quot; - Friedrich August von Hayek</div><div class="gmail_extra"><br></div><div class="gmail_extra">-- <br><div class="gmail_signature">--<br>Gavin Andresen<br></div>
</div></div>