From: Gavin Andresen <gavinandresen@gmail•com>
To: Gregory Maxwell <gmaxwell@gmail•com>
Cc: Bitcoin Development <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] Proposed alternatives to the 20MB step function
Date: Sun, 10 May 2015 17:21:06 -0400 [thread overview]
Message-ID: <CABsx9T2+ThQ+z2wyb_NbDWEK1zJO-WaLMdDU3ewpTELNKhb7YA@mail.gmail.com> (raw)
In-Reply-To: <CAAS2fgQRS7w7RRNXVK_+=4CQ7=AWxWQQ7+Tf4tNUPTTZOf7rEQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 4100 bytes --]
Let me make sure I understand this proposal:
On Fri, May 8, 2015 at 11:36 PM, Gregory Maxwell <gmaxwell@gmail•com> 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
[-- Attachment #2: Type: text/html, Size: 5914 bytes --]
next prev parent reply other threads:[~2015-05-10 21:21 UTC|newest]
Thread overview: 69+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-05-08 7:20 Matt Whitlock
2015-05-08 10:15 ` Mike Hearn
2015-05-08 10:30 ` Clément Elbaz
2015-05-08 12:32 ` Joel Joonatan Kaartinen
2015-05-08 12:48 ` Matt Whitlock
2015-05-08 13:24 ` Matt Whitlock
2015-05-08 12:48 ` Gavin Andresen
2015-05-08 16:51 ` Peter Todd
2015-05-08 22:36 ` Joel Joonatan Kaartinen
2015-05-09 18:30 ` Peter Todd
2015-05-08 15:57 ` Alex Mizrahi
2015-05-08 16:55 ` Bryan Bishop
2015-05-08 20:33 ` Mark Friedenbach
2015-05-08 22:43 ` Aaron Voisine
2015-05-08 22:45 ` Mark Friedenbach
2015-05-08 23:15 ` Aaron Voisine
2015-05-08 23:58 ` Mark Friedenbach
2015-05-09 3:36 ` Gregory Maxwell
2015-05-09 11:58 ` Gavin Andresen
2015-05-09 13:49 ` Tier Nolan
2015-05-10 17:36 ` Owen Gunden
2015-05-10 18:10 ` Mark Friedenbach
2015-05-10 21:21 ` Gavin Andresen [this message]
2015-05-10 21:33 ` Gregory Maxwell
2015-05-10 21:56 ` Rob Golding
2015-05-13 10:43 ` Tier Nolan
2015-05-16 0:22 ` Rusty Russell
2015-05-16 11:09 ` Tier Nolan
2015-05-18 1:42 ` Rusty Russell
2015-05-19 8:59 ` Tier Nolan
2015-05-10 21:48 ` Thomas Voegtlin
2015-05-10 22:31 ` Mark Friedenbach
2015-05-10 23:11 ` Thomas Voegtlin
2015-05-28 15:53 ` Gavin Andresen
2015-05-28 17:05 ` Mike Hearn
2015-05-28 17:19 ` Gavin Andresen
2015-05-28 17:34 ` Mike Hearn
2015-05-28 18:23 ` Gavin Andresen
2015-05-29 11:26 ` Mike Hearn
2015-05-29 11:42 ` Tier Nolan
2015-05-29 11:57 ` Mike Hearn
2015-05-29 12:39 ` Gavin Andresen
2015-05-29 14:00 ` insecurity
2015-05-29 14:15 ` Braun Brelin
2015-05-29 14:09 ` Tier Nolan
2015-05-29 14:20 ` Gavin Andresen
2015-05-29 14:22 ` Mike Hearn
2015-05-29 14:21 ` Mike Hearn
2015-05-29 14:22 ` Tier Nolan
2015-05-29 16:39 ` [Bitcoin-development] Proposed alternatives to the 20MB stepfunction Raystonn .
2015-05-29 18:28 ` Tier Nolan
2015-05-29 17:53 ` [Bitcoin-development] Proposed alternatives to the 20MB step function Admin Istrator
2015-05-30 9:03 ` Aaron Voisine
2015-06-01 11:30 ` Ricardo Filipe
2015-06-01 11:46 ` Marcel Jamin
2015-05-29 18:47 ` Bryan Cheng
2015-05-30 1:36 ` Cameron Garnham
2015-05-28 17:39 ` [Bitcoin-development] Proposed alternatives to the 20MB stepfunction Raystonn .
2015-05-28 17:59 ` Pieter Wuille
2015-05-28 18:21 ` Gavin Andresen
2015-05-28 17:50 ` [Bitcoin-development] Proposed alternatives to the 20MB step function Peter Todd
2015-05-28 17:14 ` Thomas Voegtlin
2015-05-28 17:34 ` Pieter Wuille
2015-05-29 17:45 ` Aaron Voisine
2015-05-08 14:57 Steven Pine
2015-05-09 0:13 Raystonn
[not found] <CAAjy6kDdB8uODpPcmS8h4eap8fke7Y2y773NHJZja8tB5mPk4Q@mail.gmail.com>
2015-05-28 16:30 ` Steven Pine
[not found] ` <CABsx9T03aNRC5DRbR06nNtsiBdJAcQsGAHvbCOe3pnuRpdvq5w@mail.gmail.com>
2015-05-28 18:25 ` Steven Pine
2015-05-28 18:31 ` Gavin Andresen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CABsx9T2+ThQ+z2wyb_NbDWEK1zJO-WaLMdDU3ewpTELNKhb7YA@mail.gmail.com \
--to=gavinandresen@gmail$(echo .)com \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=gmaxwell@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox