Bitcoin Forum
May 05, 2024, 08:31:00 AM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: « 1 2 3 [4]  All
  Print  
Author Topic: Pools With a Significant Hashrate: A Realistic Double Spend Attack Taking 2 Hr  (Read 11668 times)
MrJoshua
Member
**
Offline Offline

Activity: 76
Merit: 10


View Profile
July 07, 2011, 08:50:53 AM
 #61

Then the problem is insecure pool design.

I'm sorry.  Have I somehow missed what this entire thread is about?

Pools reduce the security of bitcoin.  End of line.

j

Yes, but listen. IT IS FIXABLE. And smart minds are working on it. It is only the current manifestation of the pool system that allow these pool attacks to work.

http://forum.bitcoin.org/index.php?topic=9137.0

It is possible to have pools work with zero pool attack risk. It is being worked on by smart people. The new system will probably be adopted soon (within 6 months).

Yes I know thank you.  Let's hope the entire bitcoin enterprise isn't compromised in the next six months.  

I love playing with risk like this.  It's like smoking, the best possible outcome is nothing at all, worst outcome you die a painful death.  It's not like you win billions of dollars for the risk you take on, nope just nothing or death.  In some universes that's a game not worth playing, apparently not so much here.

j

The value of bitcoins is not a theory, predictions of it's failure are what is theoretical.
There are several different types of Bitcoin clients. The most secure are full nodes like Bitcoin Core, but full nodes are more resource-heavy, and they must do a lengthy initial syncing process. As a result, lightweight clients with somewhat less security are commonly used.
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
sadpandatech
Hero Member
*****
Offline Offline

Activity: 504
Merit: 500



View Profile
July 07, 2011, 08:58:13 AM
 #62

It is being worked on by smart people.

Couldn't help but grab that one. Thank god for smart people! ;p

If you're not excited by the idea of being an early adopter 'now', then you should come back in three or four years and either tell us "Told you it'd never work!" or join what should, by then, be a much more stable and easier-to-use system.
- GA

It is being worked on by smart people.  -DamienBlack
DamienBlack
Jr. Member
*
Offline Offline

Activity: 56
Merit: 1


View Profile
July 07, 2011, 08:59:23 AM
 #63

It is being worked on by smart people.

Couldn't help but grab that one. Thank god for smart people! ;p

Yes, if it were in my hands... heaven help us.
mrb (OP)
Legendary
*
Offline Offline

Activity: 1512
Merit: 1027


View Profile WWW
July 07, 2011, 09:42:31 AM
 #64

Getwork returns data (essentially block header) and midstate. Midstate can be created from data. Data contains block header which MUST contain previous block hash. Block header contains also merkle root which is unpredictable but everything else must be consistent.

Hash is unpredictable but the data to be hashed must be valid. Otherwise the block will not be accepted by the network.

Right. In theory it should be possible to modify miners to check this previous hash. For some reason I only remembered the merkle root was here.
Raulo
Full Member
***
Offline Offline

Activity: 238
Merit: 100


View Profile
July 07, 2011, 10:17:24 AM
 #65

Personally, I would urge exchange owners to require 144 or 288 confirmations (nominally 24 or 48 hours).

It is definitely too draconian. Imagine there is a sudden jump in BTC value and you want to cash out. Sorry, 24 hour waiting.

The exchanges can, however, instate a 24 hours waiting period for cashing out. Essentially, you could withdraw balance that was there 24 hours ago. If there is a BTC reversal, the perpetrator would have a negative BTC balance in the exchange account. The USD balance that is hold for 24 hours could cover the loss then.

1HAoJag4C3XtAmQJAhE9FTAAJWFcrvpdLM
Chris Acheson
Sr. Member
****
Offline Offline

Activity: 266
Merit: 251


View Profile
July 07, 2011, 11:01:41 AM
Last edit: July 07, 2011, 11:17:14 AM by Chris Acheson
 #66

Yes, but listen. IT IS FIXABLE. And smart minds are working on it. It is only the current manifestation of the pool system that allow these pool attacks to work.

http://forum.bitcoin.org/index.php?topic=9137.0

It is possible to have pools work with zero pool attack risk. It is being worked on by smart people. The new system will probably be adopted soon (within 6 months).

That thread hasn't been touched in the past month.  Who, exactly, is working on this?

The fact that this shit is still going on, combined with the ridiculously pollyannaish mentality of most bitcoin users, is seriously alarming.
bcearl
Full Member
***
Offline Offline

Activity: 168
Merit: 103



View Profile
July 07, 2011, 11:49:43 AM
 #67

Yes, but listen. IT IS FIXABLE. And smart minds are working on it. It is only the current manifestation of the pool system that allow these pool attacks to work.

http://forum.bitcoin.org/index.php?topic=9137.0

It is possible to have pools work with zero pool attack risk. It is being worked on by smart people. The new system will probably be adopted soon (within 6 months).

That thread hasn't been touched in the past month.  Who, exactly, is working on this?

The fact that this shit is still going on, combined with the ridiculously pollyannaish mentality of most bitcoin users, is seriously alarming.

Maybe the best way is to create a open source mining software solution that is good enough to be adapted by mining pools.

Everything else is doomed to fail, nobody can enforce mining pools to take care about security.

Misspelling protects against dictionary attacks NOT
mrb (OP)
Legendary
*
Offline Offline

Activity: 1512
Merit: 1027


View Profile WWW
July 07, 2011, 01:11:21 PM
 #68

Which hacker with such skills will really ruin the entire economy for a few thousand bucks?

I would say the same ones who hacked into MtGox, cracked so many strong passwords that no one has a clue how they did it, crashed the market to $0.01/BTC, and ended up stealing a miserable 2000 BTC.  Roll Eyes
TriumVir
Newbie
*
Offline Offline

Activity: 56
Merit: 0


View Profile
July 07, 2011, 03:19:47 PM
 #69

Who, exactly, is working on this?
Chris Acheson
Sr. Member
****
Offline Offline

Activity: 266
Merit: 251


View Profile
July 07, 2011, 03:45:25 PM
 #70

Quote
(07:54:46 AM) cacheson: cuddlefish: hey, remember that solution you proposed a while back to prevent 50%+ attacks by pools?  is anyone still working on that?
(08:03:54 AM) cuddlefish: cacheson: I might
(08:04:07 AM) cuddlefish: cacheson: don't know much about mining
(08:05:36 AM) cacheson: cuddlefish: I'm talking about this thread: http://forum.bitcoin.org/index.php?topic=9137.0
(08:05:53 AM) cacheson: cuddlefish: no replies for a month, was just wondering if there was anyone still working on it
(08:06:13 AM) cacheson: cuddlefish: seems particularly relevant right now
(08:06:18 AM) cuddlefish: cacheson: I won't code it
(08:06:23 AM) cuddlefish: but please do
(08:06:24 AM) cuddlefish: please
(08:06:28 AM) cuddlefish: i'd use your pool
(08:06:33 AM) cacheson: cuddlefish: :/
(08:06:34 AM) cuddlefish: with my CPU netbook miner Tongue
(08:07:18 AM) cacheson: cuddlefish: I don't know any more than you do about the gritty details of mining than you do.  less, considering that you came up with the idea.  but anyway, I'll take that as a "no, no one is working on it"
(08:07:46 AM) cacheson: cuddlefish: er... mangled that message, but you get what i mean
(08:12:32 AM) cuddlefish: cacheson: k
kjj
Legendary
*
Offline Offline

Activity: 1302
Merit: 1024



View Profile
July 07, 2011, 04:42:24 PM
 #71

Exponential difficulty could kill this type of attack.  And it would take a lot less coding effort than changing every node, pool, proxy and miner.

17Np17BSrpnHCZ2pgtiMNnhjnsWJ2TMqq8
I routinely ignore posters with paid advertising in their sigs.  You should too.
Pages: « 1 2 3 [4]  All
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!