From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193] helo=mx.sourceforge.net) by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1YrYew-0006uq-5t for bitcoin-development@lists.sourceforge.net; Sun, 10 May 2015 21:21:14 +0000 Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.217.169 as permitted sender) client-ip=209.85.217.169; envelope-from=gavinandresen@gmail.com; helo=mail-lb0-f169.google.com; Received: from mail-lb0-f169.google.com ([209.85.217.169]) by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1YrYeu-0000de-KZ for bitcoin-development@lists.sourceforge.net; Sun, 10 May 2015 21:21:14 +0000 Received: by lbbuc2 with SMTP id uc2so82069827lbb.2 for ; Sun, 10 May 2015 14:21:06 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.152.121.66 with SMTP id li2mr5831268lab.65.1431292866287; Sun, 10 May 2015 14:21:06 -0700 (PDT) Received: by 10.25.90.75 with HTTP; Sun, 10 May 2015 14:21:06 -0700 (PDT) In-Reply-To: References: <16096345.A1MpJQQkRW@crushinator> Date: Sun, 10 May 2015 17:21:06 -0400 Message-ID: From: Gavin Andresen To: Gregory Maxwell Content-Type: multipart/alternative; boundary=089e0112c886dd5d470515c0d614 X-Spam-Score: -0.6 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (gavinandresen[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 1.0 HTML_MESSAGE BODY: HTML included in message -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature X-Headers-End: 1YrYeu-0000de-KZ Cc: Bitcoin Development Subject: Re: [Bitcoin-development] Proposed alternatives to the 20MB step function X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 May 2015 21:21:14 -0000 --089e0112c886dd5d470515c0d614 Content-Type: text/plain; charset=UTF-8 Let me make sure I understand this proposal: On Fri, May 8, 2015 at 11:36 PM, Gregory Maxwell wrote: > (*) I believe my currently favored formulation of general dynamic control > idea is that each miner expresses in their coinbase a preferred size > between some minimum (e.g. 500k) and the miner's effective-maximum; > the actual block size can be up to the effective maximum even if the > preference is lower (you're not forced to make a lower block because you > stated you wished the limit were lower). There is a computed maximum > which is the 33-rd percentile of the last 2016 coinbase preferences > minus computed_max/52 (rounding up to 1) bytes-- or 500k if thats > larger. The effective maximum is X bytes more, where X on the range > [0, computed_maximum] e.g. the miner can double the size of their > block at most. If X > 0, then the miners must also reach a target > F(x/computed_maximum) times the bits-difficulty; with F(x) = x^2+1 --- > so the maximum penalty is 2, with a quadratic shape; for a given mempool > there will be some value that maximizes expected income. (obviously all > implemented with precise fixed point arithmetic). The percentile is > intended to give the preferences of the 33% least preferring miners a > veto on increases (unless a majority chooses to soft-fork them out). The > minus-comp_max/52 provides an incentive to slowly shrink the maximum > if its too large-- x/52 would halve the size in one year if miners > were doing the lowest difficulty mining. The parameters 500k/33rd, > -computed_max/52 bytes, and f(x) I have less strong opinions about; > and would love to hear reasoned arguments for particular parameters. > I'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've misinterpreted the proposed algorithm. And everybody, please let me know if I'm making a bone-headed mistake in how I'm computing anything: Lets say miners are expressing a desire for 600,000 byte blocks in their coinbases. computed_max = 600,000 - 600,000/52 = 588,462 bytes. --> this is about 23 average-size (500-byte) transactions less than 600,000. effective_max = 1,176,923 Lets say I want to maintain status quo at 600,000 bytes; how much penalty do I have? ((600,000-588,462)/588,462)^2 + 1 = 1.00038 How much will that cost me? The network is hashing at 310PetaHash/sec right now. Takes 600 seconds to find a block, so 186,000PH per block 186,000 * 0.00038 = 70 extra PH 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: (25.13 BTC/block / 186,000 PH/block) * 70 PH = 0.00945 BTC or at $240 / BTC: $2.27 ... 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'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. Is that too much? Not enough? Average transaction fees today are about 3 cents per transaction. I created a spreadsheet playing with the parameters: https://docs.google.com/spreadsheets/d/1zYZfb44Uns8ai0KnoQ-LixDwdhqO5iTI3ZRcihQXlgk/edit?usp=sharing "We" could tweak the constants or function to get a transaction fee we think is reasonable... but we really shouldn'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. As for some other dynamic algorithm: OK with me. How do we get consensus on what the best algorithm is? I'm ok with any "don't grow too quickly, give some reasonable-percentage-minority of miners the ability to block further increases." Also relevant here: "The curious task of economics is to demonstrate to men how little they really know about what they imagine they can design." - Friedrich August von Hayek -- -- Gavin Andresen --089e0112c886dd5d470515c0d614 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Let me make sure I understand t= his proposal:

On Fri, May 8, 2015 at 11:36 PM, Gregory= Maxwell <gmaxwell@gmail.com> wrote:
=
(*) I believe my curr= ently favored formulation of general dynamic control
idea is that each miner expresses in their coinbase a preferred size
between some minimum (e.g. 500k) and the miner's effective-maximum;
the actual block size can be up to the effective maximum even if the
preference is lower (you're not forced to make a lower block because yo= u
stated you wished the limit were lower).=C2=A0 There is a computed maximum<= br> which is the 33-rd percentile of the last 2016 coinbase preferences
minus computed_max/52 (rounding up to 1) bytes-- or 500k if thats
larger. The effective maximum is X bytes more, where X on the range
[0, computed_maximum] e.g. the miner can double the size of their
block at most. If X > 0, then the miners must also reach a target
F(x/computed_maximum) times the bits-difficulty; with F(x) =3D x^2+1=C2=A0 = ---
so the maximum penalty is 2, with a quadratic shape;=C2=A0 for a given memp= ool
there will be some value that maximizes expected income.=C2=A0 (obviously a= ll
implemented with precise fixed point arithmetic).=C2=A0 =C2=A0The percentil= e is
intended to give the preferences of the 33% least preferring miners a
veto on increases (unless a majority chooses to soft-fork them out). The minus-comp_max/52 provides an incentive to slowly shrink the maximum
if its too large-- x/52 would halve the size in one year if miners
were doing the lowest difficulty mining. The parameters 500k/33rd,
-computed_max/52 bytes, and f(x)=C2=A0 I have less strong opinions about; and would love to hear reasoned arguments for particular parameters.
<= /blockquote>

I'm going to try to figure out how much transacti= on fee a transaction would have to pay to bribe a miner to include it. Greg= , please let me know if I've misinterpreted the proposed algorithm. And= everybody, please let me know if I'm making a bone-headed mistake in h= ow I'm computing anything:

Lets say miners are expressing a desire for 600,00= 0 byte blocks in their coinbases.

computed_max =3D 600,000 - 600,000/52 =3D 588,4= 62 bytes.
=C2=A0 --> this is about 23 av= erage-size (500-byte) transactions less than 600,000.
effective_max =3D=C2=A01,176,923

Lets say I want to maintain status qu= o at 600,000 bytes; how much penalty do I have?
((600,000-588,462)/588,462)^2 + 1 =3D=C2=A01.00038

How much will that cost m= e?
The network is hashing at 310PetaHash/se= c right now.
Takes 600 seconds to find a bl= ock, so 186,000PH per block
186,000 * 0.000= 38 =3D 70 extra PH

If it takes 186,000 PH to find a block, and a block is worth 2= 5.13 BTC (reward plus fees), that 70 PH costs:
(25.13 BTC/block / 186,000 PH/block) * 70 PH =3D 0.00945 BTC
or at $240 / BTC: =C2=A0$2.27

... so average transaction fe= e will have to be about ten cents ($2.27 spread across 23 average-sized tra= nsactions) for miners to decide to stay at 600K blocks. If they fill up 588= ,462 bytes and don't have some ten-cent-fee transactions left, they sho= uld express a desire to create a 588,462-byte-block and mine with no penalt= y.

Is = that too much?=C2=A0 Not enough?=C2=A0 Average transaction fees today are a= bout 3 cents per transaction.
I created a s= preadsheet playing with the parameters:
=C2= =A0=C2=A0https://docs.google.com/sp= readsheets/d/1zYZfb44Uns8ai0KnoQ-LixDwdhqO5iTI3ZRcihQXlgk/edit?usp=3Dsharin= g

= "We" could tweak the constants or function to get a transaction f= ee we think is reasonable... but we really shouldn't be deciding whethe= r 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.

As for some other dyn= amic algorithm: OK with me. How do we get consensus on what the best algori= thm is? I'm ok with any "don't grow too quickly, give some rea= sonable-percentage-minority of miners the ability to block further increase= s."

Also relevant here:
"The curious ta= sk of economics is to demonstrate to men how little they really know about = what they imagine they can design." - Friedrich August von Hayek
=

--
--
Gavin Andresen
--089e0112c886dd5d470515c0d614--