* Re: [Bitcoin-development] A mining pool at 46%
2013-04-05 9:48 ` Mike Hearn
@ 2013-04-05 10:02 ` Gregory Maxwell
2013-04-05 10:13 ` Melvin Carvalho
2013-04-05 10:50 ` Robert McKay
2 siblings, 0 replies; 8+ messages in thread
From: Gregory Maxwell @ 2013-04-05 10:02 UTC (permalink / raw)
To: Mike Hearn; +Cc: Bitcoin Dev
On Fri, Apr 5, 2013 at 2:48 AM, Mike Hearn <mike@plan99•net> wrote:
> 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.
As an aside and a clarification— P2pool works great with FPGAs, and
one of the largest FPGA farms I've heard of uses it. But it doesn't
work well the old BFL FPGA miners— because they have insane latency.
Likewise it doesn't currently work well with Avalon, again because of
insane latency. P2pool uses a 10 second sharechain in order to give
miners low variance but that means that if you have a several second
miner you'll end up subsidizing all the faster p2pool users somewhat.
It was basically stable with the network until ASICminer came online
mining on BTCguild mostly and the first avalons started to ship, and
then the network went up 10TH in a couple weeks (and now 15TH) while
P2Pool stayed mostly constant.
ForrestV (the author and maintainer of the P2pool software) would love
to work on making Avalon and other higher latency devices first class
supported on P2Pool, but he doesn't have one— and frankly, all the
people who have them aren't super eager to fuss around with a 5BTC/day
revenue stream, especially since the avalon firmware (and its internal
copy of cgminer) itself has a bunch of quirks and bugs that are still
getting worked out... and I do believe that p2pool helps reduce
concerns around mining pool centralization. ... but I think as a
community we don't always do a great job at supporting people who work
on infrastructure— even just making sure to get them what they need to
keep giving us free stuff—, we just assume they're super rich Bitcoin
old hands, but that often isn't true.
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [Bitcoin-development] A mining pool at 46%
2013-04-05 9:48 ` Mike Hearn
2013-04-05 10:02 ` Gregory Maxwell
@ 2013-04-05 10:13 ` Melvin Carvalho
2013-04-05 12:12 ` Peter Todd
2013-04-05 10:50 ` Robert McKay
2 siblings, 1 reply; 8+ messages in thread
From: Melvin Carvalho @ 2013-04-05 10:13 UTC (permalink / raw)
To: Mike Hearn; +Cc: Bitcoin Dev
[-- 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 --]
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [Bitcoin-development] A mining pool at 46%
2013-04-05 10:13 ` Melvin Carvalho
@ 2013-04-05 12:12 ` Peter Todd
2013-04-08 12:32 ` Daryl Tucker
0 siblings, 1 reply; 8+ messages in thread
From: Peter Todd @ 2013-04-05 12:12 UTC (permalink / raw)
To: Melvin Carvalho; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 757 bytes --]
On Fri, Apr 05, 2013 at 12:13:23PM +0200, Melvin Carvalho wrote:
> 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?
Vandalize the chain how? By delibrately triggering bugs? (like the old
OP_CHECKSIG abuse problem) Regardless of whether or not the
vulnerability requires multiple blocks in a row, the underlying problem
should be fixed.
By putting illegal data into it? Fundementally we have no way to prevent
people from doing that other than by making it expensive. An attacker
having a lot of hashing power just means they can do so faster and a bit
cheaper.
--
'peter'[:-1]@petertodd.org
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [Bitcoin-development] A mining pool at 46%
2013-04-05 12:12 ` Peter Todd
@ 2013-04-08 12:32 ` Daryl Tucker
0 siblings, 0 replies; 8+ messages in thread
From: Daryl Tucker @ 2013-04-08 12:32 UTC (permalink / raw)
To: bitcoin-development
BTC Guild's response:
51% Mitigation Plan
I want to start by thanking all users, new and old, for making BTC
Guild become what it is today. I never expected a service that
originally started on a mining PC in my dining room in April 2011 to
go this far.
However, recently BTC Guild has started to become "too big". Users of
Bitcoin are becoming scared that BTC Guild, either directly or through
hacking/coercion, could be used to attack the network as it gets
closer to 51% of the network. If this were to happen, it is likely
many people would lose confidence in Bitcoin, as a single entity could
control the network if it wanted to do so.
I have put forward a proposal of my plans on how to mitigate this
threat, but unfortunately nothing can be done without users taking
some initiative as well. The following are the actions that will be
taken if certain thresholds are crossed:
More than 40% of the Network [last 2016 blocks]
PPS fee will be raised from 5% to 7% on all new accounts. Old accounts
will also be increased (PPS ONLY) to 7% after a difficulty change. If
the pool eventually drops back under 40% for more than 72 hours, these
fees will be turned back down to 5% after the next difficulty change.
More than 45% of the Network [last 2016 blocks]
Getwork based pools will be completely removed within 24 hours. All
users on getwork have been warned in the past that it is a unsupported
and not advised method of connecting. This should remove ~15% of BTC
Guild's hash rate immediately.
More than 40% of the Network again [last 2016 blocks]
PPLNS fee will be raised from 3% to 4% after a 72 hour warning. This
fee will be reduced back to 3% once the pool drops back under 40% for
more than 72 hours.
If you have questions or comments, please leave them on the forum
thread related to this issue:
https://bitcointalk.org/index.php?topic=168108.0
https://www.btcguild.com/index.php?page=home
On 04/05/2013 07:12 AM, Peter Todd wrote:
> On Fri, Apr 05, 2013 at 12:13:23PM +0200, Melvin Carvalho wrote:
>> 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?
>
> Vandalize the chain how? By delibrately triggering bugs? (like the
> old OP_CHECKSIG abuse problem) Regardless of whether or not the
> vulnerability requires multiple blocks in a row, the underlying
> problem should be fixed.
>
> By putting illegal data into it? Fundementally we have no way to
> prevent people from doing that other than by making it expensive.
> An attacker having a lot of hashing power just means they can do so
> faster and a bit cheaper.
>
>
>
> ------------------------------------------------------------------------------
>
>
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
>
--
Daryl Tucker
daryl@daryltucker•com
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [Bitcoin-development] A mining pool at 46%
2013-04-05 9:48 ` Mike Hearn
2013-04-05 10:02 ` Gregory Maxwell
2013-04-05 10:13 ` Melvin Carvalho
@ 2013-04-05 10:50 ` Robert McKay
2 siblings, 0 replies; 8+ messages in thread
From: Robert McKay @ 2013-04-05 10:50 UTC (permalink / raw)
To: Mike Hearn; +Cc: Bitcoin Dev
On Fri, 5 Apr 2013 11:48:51 +0200, Mike Hearn wrote:
> However, youre somewhat right in the sense that its 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 doesnt own the actual mining
> hardware, he then wouldnt be able to do it again.
Unless all the miners are monitoring the work they do for their pools
and the actual miners that found the blocks noticed (unlikely) - the
only way anyone knows which pool did anything is the source IP that
first disseminates the new block. Also since it's unlikely that both of
the doublespend blocks would be found by the same end miner, neither of
them would know that the pool operator was responsible even if they were
monitoring their work.
There's nothing stopping the pool owner from channeling the doublespend
blocks through some other previously unknown IP, so I don't think they
would suffer any reputational damage from doing this repeatidly.
Robert
^ permalink raw reply [flat|nested] 8+ messages in thread