Bitcoin Forum
June 08, 2024, 09:06:58 AM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: [1]
  Print  
Author Topic: If there was a 51% attack...  (Read 1074 times)
Este Nuno (OP)
Legendary
*
Offline Offline

Activity: 826
Merit: 1000


amarha


View Profile
June 07, 2014, 01:47:06 PM
 #1

Would just waiting for a larger number of confirmations defeat the attempts at double spending?

Like instead of the standard 6, instead wait for 8, 10, 12? Whatever the safe amount would be so that there would be enough blocks solved by different independent sources. Or am I missing something here and that wouldn't be a solution to the problem...
shorena
Copper Member
Legendary
*
Offline Offline

Activity: 1498
Merit: 1520


No I dont escrow anymore.


View Profile WWW
June 07, 2014, 01:50:47 PM
 #2

More blocks = harder to replace them.

That will not help against a 51% attack (or >50% attack) because the idea behind that attack is that the attackers control the majority of the hashing power. They could create replacement blocks without publishing them and wait 8, 10, 12 or even more confirmations before broadcasting them.

Im not really here, its just your imagination.
Este Nuno (OP)
Legendary
*
Offline Offline

Activity: 826
Merit: 1000


amarha


View Profile
June 07, 2014, 02:14:35 PM
 #3

More blocks = harder to replace them.

That will not help against a 51% attack (or >50% attack) because the idea behind that attack is that the attackers control the majority of the hashing power. They could create replacement blocks without publishing them and wait 8, 10, 12 or even more confirmations before broadcasting them.

I thought there was an issue of probability involved with the reversing of transactions. Or is it something like when the attacker who has >50% chooses to publish their blockchain that doesn't have the transaction that's supposed to be double spent the network automatically accepts their chain because they've done the most proof of work? Does that sound right at all? So it doesn't matter how many confirmations happen because they will all be wiped out when the network accepts this new chain?

shorena
Copper Member
Legendary
*
Offline Offline

Activity: 1498
Merit: 1520


No I dont escrow anymore.


View Profile WWW
June 07, 2014, 02:33:38 PM
 #4

-snip-
I thought there was an issue of probability involved with the reversing of transactions.

Thats true because there is probability involved when finding a block.

Or is it something like when the attacker who has >50% chooses to publish their blockchain that doesn't have the transaction that's supposed to be double spent the network automatically accepts their chain because they've done the most proof of work?

"The rule" is: the longest blockchain is the valid one. The attackers can work on an an alternative blockchain in secrecy and release it to the public when its long enough.

Does that sound right at all? So it doesn't matter how many confirmations happen because they will all be wiped out when the network accepts this new chain?

That is correct. The new, now longer chain of blocks, will most likely have no or very few transactions at all* thus all transactions that have been included in other blocks are now invalid. Well not exactly invalid, they never happened.

*this depends on the prefernce of the attckers, they can basically put any valid transaction in those blocks they want

Im not really here, its just your imagination.
DannyHamilton
Legendary
*
Offline Offline

Activity: 3416
Merit: 4658



View Profile
June 08, 2014, 01:01:03 AM
 #5

Would just waiting for a larger number of confirmations defeat the attempts at double spending?

Like instead of the standard 6, instead wait for 8, 10, 12? Whatever the safe amount would be so that there would be enough blocks solved by different independent sources. Or am I missing something here and that wouldn't be a solution to the problem...

As has already been pointed out, someone with more than 50% of the total bitcoin network hashing power (in other words, more hashing power than the entire combined rest of the bitcoin network), then they have a better than 50% chance of solving the next block.

If they fail to find the next block fast enough, then they can ignore the block that the rest of the network is working and, and continue on their own block.  They still have a better than 50% chance of solving their block before the network moves on to yet another. Because their probability is better, sooner or later, they will solve enough blocks in a row to create a chain longer than the one they are trying to replace.  The higher above 50% they have, the faster they'll be able to get such a chain of blocks.  Once their chain is longer, their chain replaces the existing one.  Any transactions that were confirmed in any of the replaced blocks that aren't also in the attacker's blocks immediately become unconfirmed.  If the attacker spends any outputs in his blocks that were spent elsewhere in the chain being replaced, then those transactions in the replaced blocks don't just become unconfirmed, they also become invalid and they disappear.

They can start their attack chain many blocks before paying you.  Therefore, no matter how many confirmations you want to wait for, they can make sure that they have a long enough chain to broadcast once you've accepted the payment.
Este Nuno (OP)
Legendary
*
Offline Offline

Activity: 826
Merit: 1000


amarha


View Profile
June 08, 2014, 10:55:52 AM
 #6

Would just waiting for a larger number of confirmations defeat the attempts at double spending?

Like instead of the standard 6, instead wait for 8, 10, 12? Whatever the safe amount would be so that there would be enough blocks solved by different independent sources. Or am I missing something here and that wouldn't be a solution to the problem...

As has already been pointed out, someone with more than 50% of the total bitcoin network hashing power (in other words, more hashing power than the entire combined rest of the bitcoin network), then they have a better than 50% chance of solving the next block.

If they fail to find the next block fast enough, then they can ignore the block that the rest of the network is working and, and continue on their own block.  They still have a better than 50% chance of solving their block before the network moves on to yet another. Because their probability is better, sooner or later, they will solve enough blocks in a row to create a chain longer than the one they are trying to replace.  The higher above 50% they have, the faster they'll be able to get such a chain of blocks.  Once their chain is longer, their chain replaces the existing one.  Any transactions that were confirmed in any of the replaced blocks that aren't also in the attacker's blocks immediately become unconfirmed.  If the attacker spends any outputs in his blocks that were spent elsewhere in the chain being replaced, then those transactions in the replaced blocks don't just become unconfirmed, they also become invalid and they disappear.

They can start their attack chain many blocks before paying you.  Therefore, no matter how many confirmations you want to wait for, they can make sure that they have a long enough chain to broadcast once you've accepted the payment.

Thanks to both of you for your explanations.

The damage that can be done with a >50% attack is pretty big. It's a lot worse than I had originally assumed. I'm surprised it's not more of an issue in the community.
shorena
Copper Member
Legendary
*
Offline Offline

Activity: 1498
Merit: 1520


No I dont escrow anymore.


View Profile WWW
June 08, 2014, 05:32:05 PM
 #7

-snip-
Thanks to both of you for your explanations.

The damage that can be done with a >50% attack is pretty big. It's a lot worse than I had originally assumed. I'm surprised it's not more of an issue in the community.

Keep in mind that this would hurt the overall bitcoin value. So it would also hurt the attacker(s). It is an issue within the community. People are allready worried that ghash.io might accumulate over 50% hashingpower. They are currently @ 39% according to blockchain.info https://blockchain.info/pools

Also keep in mind that the biggest pools are in fact pools. There are many many people hashing for ghash.io. According to their own info1 55% of their hashingpower is from individuals. They could easily switch the pool info in their ASICs and work for a smaller pool.

[1] https://ghash.io/ghashio_press_release.pdf

Im not really here, its just your imagination.
paythrough_team
Newbie
*
Offline Offline

Activity: 56
Merit: 0


View Profile
June 14, 2014, 06:39:01 AM
 #8

51% of the accidents will not happen, I believe bitcoin team.
Este Nuno (OP)
Legendary
*
Offline Offline

Activity: 826
Merit: 1000


amarha


View Profile
June 14, 2014, 07:14:18 AM
 #9

51% of the accidents will not happen, I believe bitcoin team.

Too late Tongue
DannyHamilton
Legendary
*
Offline Offline

Activity: 3416
Merit: 4658



View Profile
June 14, 2014, 03:32:52 PM
 #10

51% of the accidents will not happen, I believe bitcoin team.

Too late Tongue

Explain?  I've not heard any news about an attack yet?
Este Nuno (OP)
Legendary
*
Offline Offline

Activity: 826
Merit: 1000


amarha


View Profile
June 14, 2014, 04:00:42 PM
 #11

51% of the accidents will not happen, I believe bitcoin team.

Too late Tongue

Explain?  I've not heard any news about an attack yet?

Not an attack, an "accidental" crossing of 50% is what I thought he meant.
joshraban76
Sr. Member
****
Offline Offline

Activity: 252
Merit: 250



View Profile
June 14, 2014, 04:08:36 PM
 #12

What I want to contribute here, that double spending won't be a risk for us, as among the other threads here, double spending is not such a big deal.

\   \  \ \\\\\\\\\\\\\\\\◥◣◢◤//////////////// /  /   /
Win88.me ❖ Fair, Trusted Online BTC Gambling ❖
/   /  / ////////////////◢◤◥◣\\\\\\\\\\\\\\\\ \  \   \
Zuminest
Full Member
***
Offline Offline

Activity: 169
Merit: 100


View Profile
June 15, 2014, 05:35:55 AM
 #13

Double spends could hurt casinos that give 0 confirmation credits for deposits. It would make every casino switch to 1 confirmation, which I believe PrimeDice has done recently. Kiss
shorena
Copper Member
Legendary
*
Offline Offline

Activity: 1498
Merit: 1520


No I dont escrow anymore.


View Profile WWW
June 15, 2014, 10:12:01 AM
 #14

Double spends could hurt casinos that give 0 confirmation credits for deposits. It would make every casino switch to 1 confirmation, which I believe PrimeDice has done recently. Kiss

Thats BS. If I can redo 1 block I can redo 2 blocks as well. As was pointed out in on of the other threads about this topic you might only realize after 100 or more confirmations that its a doublespend.

Im not really here, its just your imagination.
Wolf Rainer
Legendary
*
Offline Offline

Activity: 1960
Merit: 1022


View Profile
June 15, 2014, 02:15:48 PM
 #15

BITCOIN UNDER ATTACK!

a lot of duplicate transactions in the block chain...

https://blockchain.info/es/address/1AqTMY7kmHZxBuLUR5wJjPFUvqGs23sesr

https://blockchain.info/es/block-index/434490/0000000000000000303016fd7b04310914831689134138aebd2fe3c7db009df7

https://blockchain.info/es/block-index/434491/00000000000000003be82a35a2a6a6f270c19cc1bd58bb8e11649082e464718a

https://blockchain.info/es/block-index/438595/000000000000000011db25403dfa424bbc62224953c9a1703bfb464ee111494b

https://blockchain.info/es/block-index/434495/0000000000000000032befc625ad647767498d4ff0ce1a08b0d7651c5a8039ce


https://blockchain.info/es/address/1AcAj9p6zJn4xLXdvmdiuPCtY7YkBPTAJo

Whats going on?


Look at this Ghash.io ADDRESS with a lot of duplicate transactions!

https://blockchain.info/es/address/1CjPR7Z5ZSyWk6WtXvSFgkptmpoi4UM9BC

Fucking GHASH!
DannyHamilton
Legendary
*
Offline Offline

Activity: 3416
Merit: 4658



View Profile
June 15, 2014, 07:07:50 PM
 #16

BITCOIN UNDER ATTACK!

{A whole lot of rediculout FUD}

Fucking GHASH!

What a bunch of FUD.

It is not possible in bitcoin for the blockchain to have duplicate transactions.  What the heck are you going on about?

I haven't looked at it very closely yet, but my guess is you are looking at the result of an orphan block.
Pages: [1]
  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!