From: Peter Todd <pete@petertodd•org>
To: Michael Gronager <gronager@ceptacle•com>
Cc: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] Even simpler minimum fee calculation formula: f > bounty*fork_rate/average_blocksize
Date: Fri, 15 Nov 2013 06:12:04 -0500 [thread overview]
Message-ID: <20131115111204.GF17034@savin> (raw)
In-Reply-To: <5285FBD9.2070106@ceptacle.com>
[-- Attachment #1: Type: text/plain, Size: 4171 bytes --]
On Fri, Nov 15, 2013 at 11:47:53AM +0100, Michael Gronager wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi Peter,
>
> Love to see things put into formulas - nice work!
>
> Fully agree on the your fist section: As latency determines maximum
> block earnings, define a 0-latency (big-miner never orphans his own
> blocks) island and growing that will of course result in increased earnings.
>
> So build your own huge mining data center and you rock.
>
> However, that is hardly the real work scenario today. Instead we have
> pools (Huge pools). It would be interesting to do the calculation:
>
> Q = Total pool size (fraction of all mining power)
> q = My mining power (do.)
> e = fraction of block fee that pool reserves
>
> It is pretty obvious that given your formulas small miners are better
> off in a pool (can't survive as solo miners), but there will be a
> threshold q_min above which you are actually better off on you own -
> depending also on e. (excluding here all benefits of a stable revenue
> stream provided by pools)
Unfortunately the math doesn't work that way. For any Q, a bigger Q
gives you a higher return. Remember that the way I setup those equations
in section 3.2 is such that I'm actually modeling two pools, one with Q
hashing power and one with (1-Q) hashing power. Or maybe more
accurately, it's irrelevant if the (1-Q) hashing power is or isn't a
unified pool.
The other thing is the fraction of the block fee the pool reserves
indicates you're talking about real-world costs... and the moment you do
that you find that pools themselves have economies of scale simply by
virtue of using a small overhead infrastructure, their nodes etc., for a
large number of miners. On that basis alone a small miner joining a
larger pool would always be financially advantageous modulo situations
where the large pool had legal restrictions that artificially increased
their overheads.
> Next interesting calculation would be bitcoin rate as a function of pool
> size, I expect a sharp dip somewhere in the 40%s of hardware controlled
> by one entity ;)
Bitcoin rate?
> Finally, as you mention yourselves, qualification of the various
> functions is needed. This could e.g. suggest if we are like to get 3 or
> 10 miners on the long run.
The equations give an incentive to centralize all the way up to 1 miner
with 100% hashing power.
Of course, if that one pool were p2pool, that might be ok!
> And now for section 2. You insert a definition of f(L) = a-bL. I think
> the whole idea of letting f depend on L is superfluous. As a miner you
> are always free to choose which transactions to include. You will always
> choose those with the biggest fee, so really it is only the average fee
> that is relevant: f(L) = c. Any dependence in L will be removed by the
> reshuffeling. To include an extra transaction will require either that
> it has a fee larger than another (kicking that out out) or that it has a
> fee so large that it covers for the other transaction too. Also recall
> that there is a logical minimum fee (as I have already shown), and a
> maximum optimal block size - that is until the bounty becomes 0 (which
> is where other effects kick in).
By defining f(L) you can model supply and demand, which can be relevant
in that a steep demand curve with a small number of high-fee
transactions can reduce centralization pressure in my model.
Of course, by defining f(L) = a-bL you also wind up with mathematica
spitting out some truly hideous polynomials. :P Setting f(L) = c as you
suggest is something I looked at, and results in equations that are more
reasonable, so I think I'll likely wind up doing that. You can make a
good argument anyway that the centralization would cause a flattening of
any demand curve anyway, as in the no-blocksize-limit case the larger
pools cost per transaction tends towards zero as their hashing power
increases - why pay high fees when the large pool will mine them almost
as fast?
--
'peter'[:-1]@petertodd.org
0000000000000000b4ff49cd2cad865d6cbca99828987a02f3d5f41067eab00a
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 685 bytes --]
next prev parent reply other threads:[~2013-11-15 11:12 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-11-13 11:52 Michael Gronager
2013-11-13 12:34 ` Michael Gronager
2013-11-15 10:46 ` Peter Todd
2013-11-13 20:01 ` John Dillon
2013-11-13 20:32 ` Michael Gronager
2013-11-15 9:54 ` Peter Todd
2013-11-15 9:59 ` Gregory Maxwell
2013-11-15 10:47 ` Michael Gronager
2013-11-15 11:12 ` Peter Todd [this message]
2013-11-15 11:58 ` Michael Gronager
2013-11-15 19:09 ` Peter Todd
2013-11-15 10:32 ` Peter Todd
2013-11-15 11:47 ` Michael Gronager
2013-11-15 19:19 ` Peter Todd
2013-11-20 10:01 ` Peter Todd
2013-11-13 23:52 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=20131115111204.GF17034@savin \
--to=pete@petertodd$(echo .)org \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=gronager@ceptacle$(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