Double Spend Attacks on Exchanges


#8

““An unknown party with access to very large amounts of hashpower is trying to use “51% attacks” to perform “double spend” attacks to steal money from Exchanges””

If i see the hashrate chart it is okay
https://www.coinwarz.com/cryptocurrency/coins/bitcoingold

The network hashrate is between 33 to 50 Mh/s
The hashrate is okay then how it is attacking?


#9

Still, it would be valuable to know the legit pools manage to find blocks in regular intervals.


#10

Thanks for the suggestion. Currently we use getchaintips command provided by the core node to detect double spending.

So far we know the attacker is using the following addresses:

  1. Funds: GTNjvCGssb2rbLnDV1xxsHmunQdvXnY2Ft
  2. Receive mined coins: GXXjRkdquAkyHeJ6ReW3v4FY3QbgPfugTx

#11

For Korean Community.

알수 없는 공격자로부터 매우 많은 양의 Hashpower가 발생하였고 거래소들에게 돈을 훔치기 위해서 “51% 공격”을 시도하며 “이중지불(Double Spending)”을 발생시키려고 합니다.

일반 사용자 또는 보유하고 있던 기존의 기금에 대한 위험은 없습니다. 거래소를 타겟으로하여 많은 갯수의 BTG를 수령하게 하는 것이 목표입니다. 거래소는 25개 이상의 Confirm을 요구하면 안정성이 매우 높아집니다.

공격받는 거래소 중 하나는 이 공격자가 과거에도 비트코인(BTC)의 이중지불을 시도했다고 강력하게 믿고 있습니다.
그들의 말에 따르면, “우리는 같은 사람이라는 것을 100프로 확신한다. 우리는 여러 계좌들의 연관성을 발견했다”라고 말했습니다.

이 소식은 문제가 해결될때까지 주기적으로 업데이트할 예정입니다.


#12

That is not a valid indication. If the attacker does private mining and then releases their longer chain to reorg the existing one - it wouldn’t be noticed in the hashrate. The hashrate is estimated based on how often a block is found and is unrelated to the attack.


#14

He mined 9 blocks in the mainnet with his attacking node connected. His block times were between 100 and 160 seconds apart. You can calculate howmuch hash power you need for the current network difficulty in order to produce block for that time :slight_smile:


#15

Known reverted blocks as of May 19:

  {
    "height": 529043,
    "hash": "000000001783db4c9bcc58c4c28c517bf839b785ac02a836d42ce6438def5684",
    "branchlen": 22,
    "status": "valid-fork"
  }, 
  {
    "height": 528953,
    "hash": "0000000024cc17971de3cf0b03f527562093cd5e10ee26562376b1b40df65776",
    "branchlen": 2,
    "status": "valid-fork"
  }, 
  {
    "height": 528942,
    "hash": "000000002b887b73e05333c93cd83096b03405ab2dbc7b2164a59a5ec4614a7f",
    "branchlen": 11,
    "status": "valid-fork"
  }, 
  {
    "height": 528929,
    "hash": "0000000032c7e239820d283ce531867683b6da22f2a5df24a7a8ab7a4c5ae40b",
    "branchlen": 9,
    "status": "valid-fork"
  }, 
  {
    "height": 528916,
    "hash": "00000000291b073f1b504783a81c0dd01f3ceb94279eff002c658be547056cbd",
    "branchlen": 7,
    "status": "valid-fork"
  }, 
  {
    "height": 528908,
    "hash": "000000001e5d6d7f66604ffba4dd5a7f09ba94686c65560c8da1e8695d03f062",
    "branchlen": 9,
    "status": "valid-fork"
  }, 
  {
    "height": 528896,
    "hash": "000000002ab685f176f820a10df2a21e8891457534dcbfd13c74cdfd861765af",
    "branchlen": 11,
    "status": "valid-fork"
  }, 
  {
    "height": 528880,
    "hash": "0000000024980856ef6ed778b6a6aafb3d160e151e92784574f2b867b25fa35a",
    "branchlen": 6,
    "status": "valid-fork"
  }, 
  {
    "height": 528865,
    "hash": "000000002edeb249dbb2e28d7e17ca275fb3b3b6f738d6999099f4b5bbb6a001",
    "branchlen": 3,
    "status": "valid-fork"
  }, 
  {
    "height": 528836,
    "hash": "0000000021557ac1e65c1246d869f519c12901101b1f8377d720b2796da3de49",
    "branchlen": 5,
    "status": "valid-fork"
  }, 
  {
    "height": 528778,
    "hash": "000000000a58038744f54d8be26cb9959986211b7a509ad7359c7131348e97d6",
    "branchlen": 10,
    "status": "valid-fork"
  }, 
  {
    "height": 528765,
    "hash": "000000001acf8667a73029b5cef8614cdcf593f9eb139471d1da17e09b430571",
    "branchlen": 5,
    "status": "valid-fork"
  }, 
  {
    "height": 528752,
    "hash": "000000002fee9bb475fe5ccc40f1b5907493bd8983574e70648cc7e6afacae50",
    "branchlen": 2,
    "status": "valid-fork"
  }, 
  {
    "height": 528745,
    "hash": "000000002baff4217c1098548948cb08fd9183381672f919843a0f9f29664c49",
    "branchlen": 3,
    "status": "valid-fork"
  }, 
  {
    "height": 528736,
    "hash": "0000000009302871e691105605e266e66b66a42b26d22c0ee5c7d2e4c93934ef",
    "branchlen": 2,
    "status": "valid-fork"
  }, 
  {
    "height": 528732,
    "hash": "00000000190c90b77cebd11ecedc4cb38d00f8c941c6287a569b06905824fd9f",
    "branchlen": 1,
    "status": "valid-fork"
  }, 
  {
    "height": 528651,
    "hash": "000000002af60b217f587617c1c00e9175d3d6b7f9e684bcd298450791a943ce",
    "branchlen": 1,
    "status": "valid-fork"
  

#16

@flavius was right in what he said, above:

Putting it another way…

Say our natural hashrate is 40 M.

The attacker rents > 40 M of power. Let’s assume they rent 50 M… There is now a total of 90 M in play, and the attacker controls more than 50%.

However, they don’t add their 50 M to the main net with the honest miners; instead, they mine privately to build a parallel chain.

The hashrate charts will see 40 M or 50 M, but not 90 M. The hashrate charts only look at one chain, not both.

This raises a side point: a 50% attack could done by half the existing miners (if >20 M of our 40 M decided to coordinate and cheat), or it can be done by bringing in outside hashpower (someone brings in >40M to out-power our 40M.)

The attacker appears to be bringing in outside power greater than 40 M; it does not appear to be related to any normal BTG mining pool.


#17

The last attack attempt was roughly six hours ago; we see no new attacks since then.
(EDIT: this is no longer true; there was a subsequent attack. The last known attack was on May 19th. The text below remains to provide an example for study.)

Here is the last orphaned block seen on the chain, caused by these attacks:

Orphaned chain tip from fork, Block #528953
image
Source: explorer.bitcoingold.org, timestamp in Eastern Daylight Time, UTC-4.


Here is the block that replaced it, becoming part of the main chain:

Active chain, Block #528953

image
Source: explorer.bitcoingold.org, timestamp in Eastern Daylight Time, UTC-4.


No newer orphaned blocks sitting on a chain tip have been seen since then. Any new attack would create a new orphaned chain tip.

Technical note: Chain information is available from any Full Node, using the getchaintips command:

getchaintips
[{
“height”: 528980,
“hash”: “000000001cf5dbb022414111af2f9b4636a08489743b27b4ad56a8ab45bb8822”,
“branchlen”: 0,
“status”: “active”
},
{
“height”: 528953,
“hash”: “0000000024cc17971de3cf0b03f527562093cd5e10ee26562376b1b40df65776”,
“branchlen”: 2,
“status”: “valid-fork”
}, …

Note that orphaned blocks can be explored in explorer.bitcoingold.org by entering the block hash - searching on the block number will always return the mainchain block, not the orphaned block, but entering the actual hash will show a block that was orphaned.


#18

20 confirmations are not enough to defend the attack! Switch to 50 or higher.

The latest attack happened 45 hours ago.

  {
    "height": 529105,
    "hash": "0000000023ad92fe3c2cf28f0d64e4eebdfef57f08872edab57398aea8ce0589",
    "branchlen": 1,
    "status": "valid-fork"
  },
  {
    "height": 529064,
    "hash": "00000000155e2435fee41d84f57f6f9877c534b86c77bf8eeea6e67259da34b3",
    "branchlen": 1,
    "status": "valid-fork"
  },
  {
    "height": 529052,
    "hash": "000000000f5bb9fd2980dcf1f995cd295322f67f1a8fead4422b11b37eae510d",
    "branchlen": 1,
    "status": "valid-fork"
  },
  {
    "height": 529043,
    "hash": "000000001783db4c9bcc58c4c28c517bf839b785ac02a836d42ce6438def5684",
    "branchlen": 22,
    "status": "valid-fork"
  },

The first 3 branches don’t contain any double spending transaction but the final one does. The attacker successfully revert a chain with 22 blocks by a longer chain with 25 blocks!

So 20 confirmations are not enough to prevent a double spending.


#19

we are expecting Sidechains and cross chain atomic swap will be available soon.
Hope so bitcoingold will upgrade in a week for asic resistance.
All people are keeping eye on Lightning network and Bitcoingold upgrade.
When we will hear some good news from your side.

You visited consensus have you met the exchanges to add btg Like (poloniex, Kraken , coinbase and some more)
When jaxx wallet will add btg?
You were invited by the maker of jaxx wallet cruising on boat. When we will hear some great news from jaxx


#20

Again and again saying to exchanges it will make them worry. Or they can delist BTG.
Kindly upgrade it fast.(In a week)


#21

How to prevent double spending attack?

You are safe if you don’t receive coins from the attacker (or anyone you don’t know). Usually the targets attacks are Exchanges.

Otherwise you should:

  1. Be really careful about large transactions
  2. Wait for enough confirmations
  3. Watch the known attacker’s patterns and be prepared

What’s a large transaction?

It depends. The amounts of the observed double spending transactions are from ~8000 BTG to ~12000 BTG. So each time the attacker succeeds, the exchanges lose that amount.

The attacker needs to spend some money to to mine enough block to perform the 51% attack. In order to revert n blocks, the cost should be around (n+1) * 12.5 BTG, where n is the confirmations required by the exchange. A 21 block attack will cost around 262.5 BTG.

Besides the money stolen by the double spending, the attacker may also get back close to 90% of the cost after a successful attack because the mining rewards will belong to the attacker (and can be moved after 100 more blocks have passed.)

Given the cost of a (successful) attack is effectively (n+1) * 12.5 * 10% BTG (or 26.25 BTG for 20 confirmations) is relatively small, the definition of a “large transaction” is mostly up to the exchange.

However, the attacker also takes some risks. When the attack fails, all the cost to mine the private chain will be lost. That will be around (n+1)*12.5 BTG. If the exchange is aware of the attack, they may also freeze his account, so that all the funds will be locked inside the Exchange. A failed 21 block attack performed with a 10,000 BTG deposit where the Exchange freezes the account in time will result in a 10,262.5 BTG loss for the attacker.

How many confirmations should we wait?

The largest observed attack reverted 22 blocks. We advise raising confirmation requirements to 50 at this time, and for special attention to be paid to large transactions.

Higher confirmations don’t merely raise the cost of the attack, but also force the attacker to spend much more time, which means more time to detect the attack and to respond.

What’s the pattern of the attack?

We know the attacker’s address:

  • Funds: GTNjvCGssb2rbLnDV1xxsHmunQdvXnY2Ft
  • Receive mined coins: GXXjRkdquAkyHeJ6ReW3v4FY3QbgPfugTx

When an attack begins, the attacker goes through the following steps:

  1. Begins to mine his private chain, and send his coin to himself, using enough hashrate to keep the private chain longer than the public blockchain
  2. At the same time on the public blockchain, send the same coin to an Exchange
  3. Wait for enough confirmations for the Exchange to accept the deposit
  4. Quickly sell the BTG on the exchange for other coin(s) and immediately withdraw
  5. Wait for the withdrawal of other coins to be broadcast
  6. Release the private blockchain to the network, causing a re-org where the BTG were never sent to the Exchange in the first place.

Because the private blockchain is longer than the public one (which is possible with more than 51% of the hashpower), the existing blocks will be reverted, and replaced by the privately mined blocks. The deposit to the Exchange will never have happened, being replaced by the transaction to the attacker himself.

Be aware of any transaction related to the above known attacker’s addresses.


#22

It’s important to protect the ecosystem. This is real threat. We don’t want anyone lose money.


#23

Thanks for the explanation!
A little addition, the estimated attacking hashrate may be as high as 175MH:
https://www.coinotron.com/coinotron/app?action=ChartNoLogon&span=0&type=C&name=BTG

A side effect is the mining difficulty right after the attack is very high so the rest of the miners have hard time finding a block after the attacker leaves.

Miners, it’s important to keep mining so the cost of the attack remains as high as possible.

update 4 hours later:
and right after the difficulty fell, they are back at mining full speed. So basically they are milking the BTG network out of the mining rewards and leave the rest of the miners to mine the hardest blocks. It’s a vicious circle.
The worse part is, this may no longer be considered an attack (unless they still orphan some blocks, but it looks like they stopped) and it may just be a consequence of being a smaller coin amongst coins sharing one algorithm. PoW change may indeed solve this but only if BTG is using an Equihash variation that noone else uses.


#24

The Coinotron pool likely represents miners chasing the “highest profit” coin at any moment, not a malicious attempt.

Yes, it is definitely harmful to steady miners and to the ecosystem.

This is true.

Also true. The PoW change means we will leave the “big pond” of Equihash power for the “small pond” of EquihashDifferent power - a pond where we are the biggest fish, so the risk will be lower (until others choose to use the same EquihashDifferent power that we do, which will bring more water into our pond.)

Also of note, our upcoming fork includes improvements to the DAA - Difficulty Adjustment Algorithm. If our Difficulty adjusts more rapidly to the incoming surge of hashpower, the participants in the surge will earn fewer “excess” coins, limiting their profit. This will also make malicious attacks more expensive. This will help protect the steady miners and smooth out the flow of blocks.


#25

As of May 24th, it is still correct that the last known attack was on May 19th.


#26

h4x3rotab and I were discussing this and believe the current difficulty algorithm verses the new one will not affect the attack. A faulty algorithm could assist the attack, but the current and next difficulty do not have the type of problem I have in mind. But the new DA will be of some benefit if he was or would be able to pick an optimum time to begin the attack, during an oscillation that should not be there in the new DA.

If he’s able to lower the difficulty during selfish mining by something like timestamp manipulation, it might help the precision of deciding when to take it public and beat the public chain, but it does not directly help him. He has to do more chain work which is difficulty x blocks, not number of blocks. If he cuts difficulty to 1/2, he has to mine 2x more blocks to beat the public chain. He’s got 2x more blocks, but he’s not getting those blocks cheaply as h4x3rotab explained. It’s the double spends he gains on.

The public chain has to get 50 blocks before the first spends are confirmed, so the private chain getting more blocks does not help that aspect.


#27

I see; our algorithm is not a significant factor.

So it’s not about a flaw being exploited. It’s about having:

a) lots of power to make 51% attacks and
b) lots of money so their double-spends can trick exchanges into giving them lots of other coins

Got it.


#28

I have been following BTG since its creation, invested in, running full node, mining and I am a strong believer in decentralization but this is the first time for me to try and participate :slight_smile:

What is the feasibility of using a hybrid PoW algo combining or PoW&PoS for example 2 ASIC resistant algos together and specify one for odd blocks and the other for even blocks, this way the attacker mining private chain to perform 51% attack will need more resources in two different algorithms to produce longer chain than the rest of the network. dose anyone here thinks this might help secure BTG?