public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Peter Todd <pete@petertodd•org>
To: Daniel Lidstrom <lidstrom83@gmail•com>
Cc: Bitcoin Dev <Bitcoin-development@lists•sourceforge.net>,
	webmaster@cex•io, webmaster@ghash•io
Subject: Re: [Bitcoin-development] we can all relax now
Date: Fri, 15 Nov 2013 05:58:37 -0500	[thread overview]
Message-ID: <20131115105837.GE17034@savin> (raw)
In-Reply-To: <CADjHg8GNuoPQ7Ama0A=iGmboeE_T5LrLRHPKyvQqWwKAjT3K3w@mail.gmail.com>

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

On Thu, Nov 07, 2013 at 11:28:52AM -0700, Daniel Lidstrom wrote:
> Hey Peter, something seems wrong with your above analysis: I think a miner
> would withhold his block not because it leads to a greater probability of
> winning the next one, but because it increases his expected revenue.
> 
> Suppose a cabal with fraction q of the total hashing power is n blocks
> ahead on a secret branch of that has mined r_tot coins, and let r_next be
> its next block's reward.  If the cabal chooses not to broadcast its secret
> chain until at least the next block, its expected revenue after the next
> block is found is
> 
> (1 - (1-q)^(n+1))*(r_tot + r_next)
> 
> If it does broadcast, its expected revenue after the next block is found is
> 
> r_tot + q * r_next
> 
> If the cabal seeks only to maximize immediate revenue, then after a bit of
> algebra we find that it will withhold its chain if
> 
> q > 1 - ( 1 + r_tot / r_next )^(-1/n)
> 
> So if the cabal has just mined his first block off of the public chain,
> i.e. n = 1, and if the block reward is relatively stable, i.e. r_next =
> r_tot, then it needs q > 50% to profitably withhold, not the 29.2% you
> calculated.
> 
> From this formula we can also see that if the miner wins the race and
> withholds again, then he must grow q to compensate for the increase in
> r_tot, and any decrease in n.  So generally publication becomes
> increasingly in the cabal's interest, and secret chains will tend not to
> grow too large (intuition tells me that simulations using the above formula
> should bear this out).
> 
> This seem correct to you?

Remember how I started off by asking what was the correct strategy if a
miner wanted to get more blocks than their *competition*, not more
blocks in total. In some scenarios that strategy is the one that
maximizes returns, such as the case when you make your returns from
transaction fees, especially without a blocksize limit restricting how
many fee paying transactions you can stuff in your blocks. It's not
correct to say the cabal is trying to maximize immediate revenue.

As for the length of those secret chains, at every step you of course
want to weigh the value of the blocks you have found against the risk
that someone else catches up, and when it makes sense, publish some or
all.

-- 
'peter'[:-1]@petertodd.org
0000000000000000b4ff49cd2cad865d6cbca99828987a02f3d5f41067eab00a

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

  parent reply	other threads:[~2013-11-15 10:58 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-11-06  5:33 kjj
2013-11-06  9:26 ` Frank F
2013-11-06 11:35 ` Jeff Garzik
2013-11-06 18:06   ` Christophe Biocca
2013-11-07  3:44     ` Peter Todd
2013-11-07  4:15       ` Kyle Jerviss
2013-11-07  4:33         ` Peter Todd
2013-11-07  4:59           ` Kyle Jerviss
2013-11-07 13:09             ` Peter Todd
2013-11-07  4:56       ` Gavin Andresen
2013-11-07 13:24         ` Peter Todd
2013-11-07 16:14           ` Mike Hearn
2013-11-07 18:28             ` Daniel Lidstrom
2013-11-08 19:49               ` Andreas M. Antonopoulos
2013-11-08 20:33                 ` Gregory Maxwell
2013-11-15 10:58               ` Peter Todd [this message]
2013-11-07  8:07       ` Jannes Faber
2013-11-07  5:24     ` Kyle Jerviss
2013-11-06 18:17 ` Melvin Carvalho
2013-11-06 22:19 ` Jouke Hofman
2014-05-10 11:05 ` E willbefull

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=20131115105837.GE17034@savin \
    --to=pete@petertodd$(echo .)org \
    --cc=Bitcoin-development@lists$(echo .)sourceforge.net \
    --cc=lidstrom83@gmail$(echo .)com \
    --cc=webmaster@cex$(echo .)io \
    --cc=webmaster@ghash$(echo .)io \
    /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