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