Bitcoin Forum
December 10, 2019, 03:55:53 PM *
News: Latest Bitcoin Core release: 0.19.0.1 [Torrent]
 
   Home   Help Search Login Register More  
Pages: [1]
  Print  
Author Topic: How 51% attack is deterministically implemented on testnet?  (Read 179 times)
chameleon123
Jr. Member
*
Offline Offline

Activity: 48
Merit: 16


View Profile
January 28, 2019, 05:05:25 AM
 #1

Just for scientific reasons!

How 51% attack is implemented on testnet. I want to see the results visually ?
Is disconnecting one node from chain for some time will do the it properly or other nodes recognize it once it is added to the chain ?
1575993353
Hero Member
*
Offline Offline

Posts: 1575993353

View Profile Personal Message (Offline)

Ignore
1575993353
Reply with quote  #2

1575993353
Report to moderator
1575993353
Hero Member
*
Offline Offline

Posts: 1575993353

View Profile Personal Message (Offline)

Ignore
1575993353
Reply with quote  #2

1575993353
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
Heisenberg_Hunter
Hero Member
*****
Offline Offline

Activity: 714
Merit: 670



View Profile WWW
January 28, 2019, 07:41:47 AM
Merited by bones261 (2), ETFbitcoin (1), HeRetiK (1)
 #2

A btc testnet functions similar to that of a mainnet, but these coins don't have real value and the difficulty for mining the block is literally very low. The testnet follows almost all the consensus rules similar to that of the mainnet.Hence 51% attack functions similar to that in the mainnet. At the current difficulty,in order to carry out a 51% attack on the mainnet, the individual miner or group of miners need to control 51% of current hashrate which stands at 40 million TH/s. But the testnet has a lower hashrate of 62 TH/s, which requires just 2 or 3 ASIC mining rigs to take control and perform the 51% attack on the testnet successfully.

But you could try using regtest mode in the bitcoind application to test your own local blockchain with such kind of attacks. You could even try out performing eclipse attack and the cybil attack successfully. Since Btc is a p2p applicaton,in regtest mode you can create multiple nodes and control them and carry out 51% attacks and see them visually.

Is disconnecting one node from chain for some time will do the it properly or other nodes recognize it once it is added to the chain ?
I don't get your point. Why should you disconnect your node to carry out 51% attack? Am I missing something here  Huh

chameleon123
Jr. Member
*
Offline Offline

Activity: 48
Merit: 16


View Profile
January 28, 2019, 08:11:59 AM
 #3

Quote
But the testnet has a lower hashrate of 62 TH/s, which requires just 2 or 3 ASIC mining rigs to take control and perform the 51% attack on the testnet successfully.

In fact I reduced difficulty of whole network and created my private chain. I'm currently mining on that which  is good enough to implement 51% attack quickly, and also uses all main net functions.
 
Quote
But you could try using regtest mode in the bitcoind application to test your own local blockchain with such kind of attacks.

yes, I know but simulating these attacks require creating two blocks at the same time which the fake chain is longer that the true chain. Since for test I mine with bitcoin built-in miner I have no idea how to create two blocks at the same time. There is always a delay(at least in timestamp). Son the step by step scenario seemed a bit confusing at first sight.

Quote
I don't get your point. Why should you disconnect your node to carry out 51% attack? Am I missing something here  Huh

Because I thought I couldn't generate blocks simultaneously, It crossed my mind that I can develop a fake chain offline by disconnecting that node from chain, then by reconnecting  to the main chain. The fake chain which is longer is accepted. I'm not sure about it. Just an idea.   
achow101
Moderator
Legendary
*
expert
Offline Offline

Activity: 1974
Merit: 2951


bc1qshxkrpe4arppq89fpzm6c0tpdvx5cfkve2c8kl


View Profile WWW
January 28, 2019, 03:19:41 PM
Last edit: January 28, 2019, 08:38:28 PM by achow101
Merited by Foxpup (3), bones261 (2)
 #4

Is disconnecting one node from chain for some time will do the it properly or other nodes recognize it once it is added to the chain ?
Yes, disconnecting your node from the network would work fine. You don't even need to disconnect though. Bitcoin Core has an invalidateblock command which you can use to tell your node to mark a block and all of its descendants invalid. That will force you onto reject new blocks and you can then make your own blockchain fork starting from that point.

yes, I know but simulating these attacks require creating two blocks at the same time which the fake chain is longer that the true chain. Since for test I mine with bitcoin built-in miner I have no idea how to create two blocks at the same time. There is always a delay(at least in timestamp). Son the step by step scenario seemed a bit confusing at first sight.
The timestamp doesn't matter.

Heisenberg_Hunter
Hero Member
*****
Offline Offline

Activity: 714
Merit: 670



View Profile WWW
January 28, 2019, 03:24:17 PM
 #5

In fact I reduced difficulty of whole network and created my private chain. I'm currently mining on that which  is good enough to implement 51% attack quickly, and also uses all main net functions.
That's great bud. I have even used testnet and regtest quite some times, but never thought of implementing any kind of attack on it.
 
yes, I know but simulating these attacks require creating two blocks at the same time which the fake chain is longer that the true chain. Since for test I mine with bitcoin built-in miner I have no idea how to create two blocks at the same time. There is always a delay(at least in timestamp).
Let me try to explain it as simple as I can from what I have read about double spending and how to carry out one. Double spending can be done by many ways. The common one being what you are trying to achieve by creating 2 blocks in 2 different nodes in exactly the same timestamp. The other one being marking the validated block as invalid. I believe this method is a way of double spending a coin but not sure actually.

 First send some coins to a wallet. Allow the blocks to be confirmed. Once the tx has got enough confirmations, type invalidateblock [hash] in the console. Here [hash] is the hash of the block where the tx is present. invalidateblock command instructs other nodes that the particular block has not followed consensus rules and would become invalid. Thus the chainstate gets back to how it was back before the block i.e your transaction is still not yet confirmed. This is where it gets tricky, you should have enough hashpower i.e more than 51% to overcome the main chain and create yourself a newer chain. Once the newer chain becomes longer, the network would shift to the longest chain as a valid one. By this way, your coins would return back to your wallet by which you have successfully double spent your coins. You have paid and got back the money by stating the block as invalid.
 
EDIT : achow was faster. I am in mobile right now

darosior
Full Member
***
Offline Offline

Activity: 208
Merit: 256



View Profile WWW
January 28, 2019, 04:41:16 PM
 #6

Just for scientific reasons!

How 51% attack is implemented on testnet. I want to see the results visually ?
Is disconnecting one node from chain for some time will do the it properly or other nodes recognize it once it is added to the chain ?
Hi,

If you are interested about how is implemented a 51% attack, I made one against Insacoin last week.
You can checkout the article I made after that about what it is, how to do it in theory, how to do it in practice.
Here is the client I used to perform it (in a dirty way) using a pool (unomp) and an asic.

chameleon123
Jr. Member
*
Offline Offline

Activity: 48
Merit: 16


View Profile
January 29, 2019, 03:54:17 PM
 #7

Hi,

Thank you for all your amazing guides. I read all that and do exactly as you said. Great guides in every way.
Pages: [1]
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!