public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Melvin Carvalho <melvincarvalho@gmail•com>
To: Mike Hearn <mike@plan99•net>
Cc: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] A mining pool at 46%
Date: Fri, 5 Apr 2013 12:13:23 +0200	[thread overview]
Message-ID: <CAKaEYhJ9-ksVXFhnzNvWHR2QoPc72uzesvsxn7ryebvt6+zxJg@mail.gmail.com> (raw)
In-Reply-To: <CANEZrP3S7b+uh2LW4vH=53opopLJRmmJ-_Uad6yEQxZ3kHW47A@mail.gmail.com>

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

On 5 April 2013 11:48, Mike Hearn <mike@plan99•net> wrote:

> 51% isn't a magic number - it's possible to do double spends against
> confirmed transactions before that. If Michael wanted to do so, with the
> current setup he could, and that's obviously rather different to how
> Satoshi envisioned mining working.
>

Thanks for pointing this out.  I guess 51% is mainly of psychological
significance.


>
> However, you're somewhat right in the sense that it's a self-defeating
> attack. If the pool owner went bad, he could pull it off once, but the act
> of doing so would leave a permanent record and many of the people mining on
> his pool would leave. As he doesn't own the actual mining hardware, he then
> wouldn't be able to do it again.
>

Totally see the logic of this, and it makes sense.  But I dont think the
only risk is in terms of double spend, but rather

1) vandalize the block chain which may be difficult to unwind?
2) use an attack to manipulate the price downwards, then rebuy lower

As bitcoin's market cap grows, incentives to move the market will grow


>
> There are also other mining protocols that allow people to pool together,
> without p2pool and without the pool operator being able to centrally pick
> which transactions go into the block. However I'm not sure they're widely
> deployed at the moment. It'd be better if people didn't cluster around big
> mining pools, but I think p2pool still has a lot of problems dealing with
> FPGA/ASIC hardware and it hasn't been growing for a long time.
>

I guess the market will decide which algorithm is used, but as a community
we can perhaps review the different mining protocols and order them in
terms of risk ...


>
>
> On Fri, Apr 5, 2013 at 11:30 AM, Melvin Carvalho <melvincarvalho@gmail•com
> > wrote:
>
>> There was some chat on IRC about a mining pool reaching 46%
>>
>> http://blockchain.info/pools
>>
>> What's the risk of a 51% attack.
>>
>> I suggested that the pool itself is decentralized so you could not launch
>> one
>>
>> On IRC people were saying that the pool owner gets to choose what goes in
>> the block
>>
>> Surely with random non colliding nonces, it would be almost impossible to
>> coordinate a 51% even by the owner
>>
>> Someone came back and said that creating random numbers on a GPU is
>> hard.  But what about just creating ONE random number and incrementing from
>> there ...
>>
>> It would be great to know if this is a threat or a non issue
>>
>>
>> ------------------------------------------------------------------------------
>> Minimize network downtime and maximize team effectiveness.
>> Reduce network management and security costs.Learn how to hire
>> the most talented Cisco Certified professionals. Visit the
>> Employer Resources Portal
>> http://www.cisco.com/web/learning/employer_resources/index.html
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development@lists•sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>>
>

[-- Attachment #2: Type: text/html, Size: 4802 bytes --]

  parent reply	other threads:[~2013-04-05 10:13 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-04-05  9:30 Melvin Carvalho
2013-04-05  9:48 ` Mike Hearn
2013-04-05 10:02   ` Gregory Maxwell
2013-04-05 10:13   ` Melvin Carvalho [this message]
2013-04-05 12:12     ` Peter Todd
2013-04-08 12:32       ` Daryl Tucker
2013-04-05 10:50   ` Robert McKay
2013-04-05  9:52 ` Gregory Maxwell

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=CAKaEYhJ9-ksVXFhnzNvWHR2QoPc72uzesvsxn7ryebvt6+zxJg@mail.gmail.com \
    --to=melvincarvalho@gmail$(echo .)com \
    --cc=bitcoin-development@lists$(echo .)sourceforge.net \
    --cc=mike@plan99$(echo .)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