From: "Andreas M. Antonopoulos" <andreas@rooteleven•com>
To: Bitcoin Dev <Bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] we can all relax now
Date: Fri, 8 Nov 2013 11:49:11 -0800 [thread overview]
Message-ID: <CAFmyj8y2H8hR=T4Ogui09MPOzz1nydNDvNZug2GZ8bWiu+52wA@mail.gmail.com> (raw)
In-Reply-To: <CADjHg8GNuoPQ7Ama0A=iGmboeE_T5LrLRHPKyvQqWwKAjT3K3w@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 7003 bytes --]
Nicholas Weaver is reporting that pools have already started delaying
blocks, something that hints at Selfish Mining, since Nov. 3rd.
https://medium.com/something-like-falling/d321a2ef9317
He dismisses other reasons for delayed block propagation.
Any ideas on whether pools are already mucking around with block delaying
tactics?
I have no idea if this report is accurate or explained by some other issue
in the network, does anyone here have a comment on this?
On Thu, Nov 7, 2013 at 10:28 AM, Daniel Lidstrom <lidstrom83@gmail•com>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?
>
>
> On Thu, Nov 7, 2013 at 9:14 AM, Mike Hearn <mike@plan99•net> wrote:
>
>> Once the ASIC race calms down because everyone has one, has more or less
>> optimal power supplies, process improvements aren't easily reachable
>> anymore etc then I'd expect people to dissipate from the large pools
>> because eliminating their fees will become the next lowest hanging fruit to
>> squeeze out extra profit. There's no particular reason we need only a
>> handful of pools that control a major fraction of the hashpower.
>>
>> If we end up with a few hundred pools or lots of miners on p2pool, then a
>> lot of these theoretical attacks become not very relevant (I don't think ID
>> sacrifices will be so common or large as to justify a pile of custom mining
>> code+strategies at any point ...)
>>
>>
>> On Thu, Nov 7, 2013 at 2:24 PM, Peter Todd <pete@petertodd•org> wrote:
>>
>>> On Thu, Nov 07, 2013 at 02:56:56PM +1000, Gavin Andresen wrote:
>>> > > P.S: If any large pools want to try this stuff out, give me a shout.
>>> You
>>> > > have my PGP key - confidentiality assured.
>>> > >
>>> >
>>> > If I find out one of the large pools decides to run this 'experiment'
>>> on
>>> > the main network, I will make it my mission to tell people to switch
>>> to a
>>> > more responsible pool.
>>>
>>> I hope they listen.
>>>
>>> A few months ago ASICMiner could have made use of that attack if my
>>> memories of their peak hashing power were correct. They certainely could
>>> have used the selfish miner version, (we need better name for that)
>>> although development costs would eat into profits.
>>>
>>> GHash.IO, 22%, says they're a "private Bitfury ASIC mining pool" - dunno
>>> what they mean by that, but they're involved with CEX.IO who has
>>> physical control of a bunch of hashing power so I guess that means their
>>> model is like ASICMiners. They're a bit short of 30%, but maybe some
>>> behind-the-scenes deals would fix that, and/or lowering the barrier with
>>> reactive block publishing. (a better name)
>>>
>>> > And if you think you can get away with driving up EVERYBODY's orphan
>>> rate
>>> > without anybody noticing, you should think again.
>>>
>>> ...and remember, if you only do the attack a little bit, you still can
>>> earn more profit, and only drive up the orphan rate a little bit. So who
>>> knows, maybe the orphans are real, or maybe they're an attack? ASICMiner
>>> was involved with a bunch of orphans a while back...
>>>
>>> You know what this calls for? A witchhunt!
>>>
>>> BURN THE LARGE POOLS!
>>>
>>> > > P.P.S: If you're mining on a pool with more than, like, 1% hashing
>>> > > power, do the math on varience... Seriously, stop it and go mine on a
>>> > > smaller pool, or better yet, p2pool.
>>> > >
>>> >
>>> > That I agree with.
>>>
>>> Glad to hear.
>>>
>>> --
>>> 'peter'[:-1]@petertodd.org
>>> 0000000000000007bd936f19e33bc8b8f9bb1f4c013b863ef60a7f5a6a5d2112
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> November Webinars for C, C++, Fortran Developers
>>> Accelerate application performance with scalable programming models.
>>> Explore
>>> techniques for threading, error checking, porting, and tuning. Get the
>>> most
>>> from the latest Intel processors and coprocessors. See abstracts and
>>> register
>>>
>>> http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk
>>> _______________________________________________
>>> Bitcoin-development mailing list
>>> Bitcoin-development@lists•sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>>
>>>
>>
>>
>> ------------------------------------------------------------------------------
>> November Webinars for C, C++, Fortran Developers
>> Accelerate application performance with scalable programming models.
>> Explore
>> techniques for threading, error checking, porting, and tuning. Get the
>> most
>> from the latest Intel processors and coprocessors. See abstracts and
>> register
>>
>> http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development@lists•sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>>
>
>
> ------------------------------------------------------------------------------
> November Webinars for C, C++, Fortran Developers
> Accelerate application performance with scalable programming models.
> Explore
> techniques for threading, error checking, porting, and tuning. Get the most
> from the latest Intel processors and coprocessors. See abstracts and
> register
> http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
[-- Attachment #2: Type: text/html, Size: 9450 bytes --]
next prev parent reply other threads:[~2013-11-08 20:11 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 [this message]
2013-11-08 20:33 ` Gregory Maxwell
2013-11-15 10:58 ` Peter Todd
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='CAFmyj8y2H8hR=T4Ogui09MPOzz1nydNDvNZug2GZ8bWiu+52wA@mail.gmail.com' \
--to=andreas@rooteleven$(echo .)com \
--cc=Bitcoin-development@lists$(echo .)sourceforge.net \
/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