public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Peter Todd <pete@petertodd•org>
To: Michael Gronager <gronager@ceptacle•com>
Cc: 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 14:09:40 -0500	[thread overview]
Message-ID: <20131115190940.GA29469@petertodd.org> (raw)
In-Reply-To: <52860C56.7000608@ceptacle.com>

[-- Attachment #1: Type: text/plain, Size: 2081 bytes --]

On Fri, Nov 15, 2013 at 12:58:14PM +0100, Michael Gronager wrote:
> My Q and q are meant differently, I agree to your Q vs Q-1 argument,
> but the q is "me as a miner" participating in "a pool" Q. If I
> participate in a pool I pay the pool owner a fraction, e, but at the
> same time I become part of an economy of scale (well actually a math
> of scale...) and that can end up paying for the lost e. The question
> is what is the ratio q/Q where I should rather mine on my own ? This
> question is interesting as it will make bigger miners break away from
> pools into solo mining, but I also agree that from pure math the most
> advantageous scenario is the 100% mining rig.

The underlying issue is what is the pools expenses compared to yours.
There is an overhead to mining, you need to spend money and time (and
hence money) running and administering full nodes at the very minimum.
The pool can amortise that cost over many hashers; the solo miner can't.

Pools will of course have some profit margin, but why would you expect
that margin to not be sufficiently low to make it in a solo-miner's
interest to join the pool? Both the pool and the former solo-miner earn
more return after all if they centralize.

The fundemental issue is that in the design of Bitcoin there is an
incentive for miners to join into pools, and that incentive exists at
any amount of hashing power. Sure second order effects like regulation
and social pressure can counteract that incentive in some circumstances,
but that's not very strong protection.

> > 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!
> 
> Ha, yes, and then the math for p2pool starts... a math where we have
> much more stales...

However p2pool doesn't necessarily need a linear blockchain to function,
so there is a potential for stales to be much less relevant.

-- 
'peter'[:-1]@petertodd.org
000000000000000772f720b0a231150f22af20760c1463ef920f71ba3daab819

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

  reply	other threads:[~2013-11-15 19:10 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
2013-11-15 11:58         ` Michael Gronager
2013-11-15 19:09           ` Peter Todd [this message]
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=20131115190940.GA29469@petertodd.org \
    --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