Double Spend Attacks on Exchanges


#1

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. We have been advising all exchanges to increase confirmations and carefully review large deposits.

There is no risk to typical users or to existing funds being held. The only parties at risk are those currently accepting large payments directly from the attacker. Exchanges are the primary targets.

The cost of mounting an ongoing attack is high. Because the cost is high, the attacker can only profit if they can quickly get something of high value from a fake deposit. A party like an Exchange may accept large deposits automatically, allow the user to trade into a different coin quickly, and then withdraw automatically. This is why they are targeting Exchanges.

Requiring more confirmations greatly increases safety. Until now, some Exchanges were operating with less than five confirmations required. We have been urging higher limits to prevent such an attack, and urging manual review of large deposits of BTG before clearing the funds for trading.

It appears that actions on the part of the exchanges have deterred the attacker, for now.

One of the targeted Exchanges reported that they strongly believe this attacker attempted to hit them with a double-spend of BTC in the past. In their words, “we are 100% sure that it is the same person, we found many associations between the accounts.”

This post will be periodically updated and extended while this event goes on.


Updates

How to prevent being attacked: post #21

20 confirmations are no longer enough to defend the attack: post #18

The attacker’s addresses:

  • Funds: GTNjvCGssb2rbLnDV1xxsHmunQdvXnY2Ft
  • Receive mined coins: GXXjRkdquAkyHeJ6ReW3v4FY3QbgPfugTx

Known reverted blocks: post #15

First and Last attacks: as of this time (EDIT: updated May 24) the first attack happened against bock 528735 from May 16, 2018 10:37:54 PM UTC, and the last attack ended after block 529048 at May 19, 2018 5:25:40 AM UTC.

(EDIT May 24) please read our Blog Post, Responding to Attacks for additional information regarding our upcoming fork.


#2

What is a Double-Spend?

This is an attempt to spend the same coins twice - for example, the attacker might send a deposit to an Exchange wallet, and then sending those same coins to another wallet of their own at the same time. This is normally resolved on a blockchain when transactions are added to blocks - when added to blocks, the transactions are put in an order. The payment which came first will be valid, and the transaction which came second will be ignored - even if the transactions were sent at the exact same time, the order of transactions in a block is clear. This way, the coins can only be sent to one place - either to the Exchange, or to the private wallet.

What is a 51% attack?

An attacker that controls more than 50% of the network’s computing power can, for the time that he is in control, exclude and modify the ordering of transactions.

Note that they cannot create transaction using other people’s coins - that would having other people’s private keys, which they do not have. But they can make transaction with their own coins, or they can exclude transactions from blocks.

This lets them manipulate the blockchain in certain ways:

  • Reverse transactions that they send while in control. This has the potential to double-spend transactions that previously had already been seen in the block chain.
  • Prevent some or all transactions from gaining any confirmations
  • Prevent some or all other miners from mining any valid blocks

The attacker can’t:

  • Reverse other people’s transactions without their cooperation
  • Prevent transactions from being sent at all (they’ll show as 0/unconfirmed)
  • Change the number of coins generated per block
  • Create coins out of thin air
  • Send coins that never belonged to them

Reference:
https://en.bitcoin.it/wiki/Weaknesses#Attacker_has_a_lot_of_computing_power


#3

Are you ready to rollout PoW change ASAP?
As this type of attack has been done once there is no reason to believe they would stop. The timeframe of two months you previously stared may not be soon enough as many people may have their funds frozen if no block from other miner manages to get through.

Also, are you aware of the full block situation? 750KB for almost every recent block. Is that part of the attack or it’s just a way to spam the block space so no other transaction gets through?

I just saw your reply: “Prevent transactions from being sent at all (they’ll show as 0/unconfirmed)”

  • That alone is enough to bring the network to a halt indefinitely as there is no reason to believe they would stop.

#4

This must be carefully coordinated with partners, but we continue to progress towards readiness for it. We can’t change a PoW before there is software to mine on the new PoW and pools are ready to allow mining with the new PoW. Also, this require a hard fork, and hard forks should always be done with care.

They appear to be stopped for the moment. We are working with partners at Exchanges and in the mining community to mitigate the attacks.

It’s not spam and not related to this attack.

It is likely a large organization cleaning up “dust.” Many tiny Bitcoin transaction UTXOs accumulated over time, long before the Bitcoin Gold fork. When BTC transaction costs were high, they were ignored because the cost of combining them was high.

On the BTG chain, transactions are currently inexpensive, so they are combining these small UTXOs into wallets to make their funds more usable. We go through periods with these kinds of small transactions from time to time as people clean up old holdings.

For example, this might be done by an Exchange preparing to list BTG or to allow access to forked coins from previously held BTC.


#5

No, because then the attacker cannot gain, either.

The 51% attack gives temporary control of the chain; it’s the double-spend that allows them to cheat an Exchange. They need the profit from cheating the Exchange to fund the continuing attack.

The hashpower for such an attack is costly. If they stop the legitimate chain entirely, they are unable to steal.

The current attacker’s goal is to steal.


#6

That is extremely important to know because otherwise if the motives are not to steal the money wouldn’t matter.

Anyway, a small improvement to the block explorer would be to tag the pool that mines the blocks so when/if the attacker is back it would be easily visible. the two-three pools would be very easy to tag and I think that would help.


#7

This attack relies on privately mining an alternative chain on a private pool while spending on the public chain.

This attack is not accomplished through the normal, honest pools.


#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.