Beam Mitigating Reorgs

This note is to advise and reassure our community that Beam Team is dedicated to keeping our decentralised network safe from attack.

Download Beam Android Wallet | Beam iOS Wallet | Beam Desktop Wallet

Mitigating Double-Spend Attacks

Before the recent consensus change in Beam, where we moved from BeamHashII to BeamHashIII, we made attempt to reach out to exchanges and pools to help us mitigate any chance of irregular activity with the Beam blockchain. Specifically, to help us combat any unseen attack on the network where a miner might hold more than 50% of the network hashrate. We ensured that the majority of exchanges implemented longer confirmation times for deposits of Beam, and we also introduced a 60-block rolling checkpoint, a mechanism that prevents reorgs deeper than 60 blocks. Unfortunately, there were a minimal number of exchanges who did not acknowledge the request to extend confirmation times.

Important request to exchanges and OTC handlers: Please allow at least 70 block confirmations before accepting user funds.

So, over the past short while, we have noticed some irregular network activity and as a result feel it only right to issue this statement.

Below is the timeline of known attacks, and the steps we took to mitigate them.

27–05–2020

Events

Several big reorgs happened in a row.

• 730833 -> 730779 -> 730873 (-54, +94)
• 730938 -> 730902 -> 731048 (-36, +146)
• 731075 -> 731066 -> 731116 (-9, +50)

Investigation:

We had 16 public mainnet nodes, from which we collected and analyzed their logs to see the whole picture. Mainly to understand better, if it was perhaps a deliberate attack, or if reorgs of the chain happened spontaneously.

In this instance, the logs didn’t show a consistent picture. We saw considerable deviations in the state of our nodes due to poor inter-node connectivity. Different nodes followed different branches for significant duration, whilst irregular, sporadic reorgs happened.

Our conclusions:

• Poor network connectivity, spontaneous (natural) network splits couldn’t be ruled-out, and this could be a logical explanation to reorgs.
• Attack was possible, but not confirmed.

Our actions:

• We took measures to reinforce inter-node connectivity.
• Fixed some issues in dynamic peer management
• Added possibility to configure permanent peers, i.e. peers to which the node should maintain connection constantly
• Updated all our mainnet nodes, configured them to maintain permanent connection to each other, to have a super-connected cluster.
• Advised all known pools and exchanges to do the same

11–06–2020

Events

2 big reorgs happened in a row.

• 753811 -> 753796 -> 753815 (-15, +19)
• 753904 -> 753821 -> 753927 (-83, +106)

Investigation:

We collected and analyzed logs from all our 16 mainnet nodes. This time they showed a perfectly consistent picture; all were in tight sync, and each underwent exactly the same reorgs at the same time. So this rules-out network connectivity problem.

So, it seemed that a very powerful miner mined for some period of time in isolation. But the question still remained: was this a deliberate attack, or maybe the most powerful mining pool just lost the connection temporarily?

We analyzed the reorged blocks and noticed that they were mostly empty, but some one of them contained a single transaction. This was consistent with how an attack might be played out. In isolation there should be no transactions, the user can only send funds to themselves (in MW, transactions are built mutually). Sending funds to yourself — looks like a deliberate double-spend. In addition we noticed anomalies in the network hashrate. For the duration of the (alleged) attack the hashrate of the honest community dropped considerably, but the (alleged) attacker hashrate was significantly higher than this drop. Which means; if we estimate the total hashrate of the network — it increased dramatically.

We discovered that during this time there were abnormally big hashpower orders on NiceHash.

Our conclusions:

Double-spend attack is very likely.

Complexity of the attack: modest

• Temporary isolation can be achieved by tweaking the firewall.
• No need to know or modify our code

Cost of the attack

• Given the current Beam prices and mining difficulty it’s feasible.
• If the attack is successful — the attacker also gets the blocks rewards, which further reduces the cost

Our actions:

We implemented a rolling checkpoint mechanism that prevents automatic reorg any deeper than 60 blocks.

• Instructed all pools and exchanges to have at least 80 confirmations for deposits
• We realized that our change to the consensus rule can lead to a network split, so we also did the following:
• Added network split detection and alert mechanisms
• Ability for the user to reorg manually
• Automatic reorg to arbitrary depth in case the current branch is abandoned. This is to make things easier for ordinary users. In case of network split, once the attack is over, their nodes will reorg automatically after some time.

15–07–2020

Events

4 big reorgs occurred within several hours during the night. 2 more reorgs during the next day. 2 reorgs on the next evening and night.

• 800823 -> 800788 -> 800833 (-35, +45)
• 800923 -> 800913 -> 800938 (-10, +25)
• 800979 -> 800958 -> 800991 (-21, +33)
• 801014 -> 800994 -> 801021 (-20, +27)
• 802281 -> 802240 -> 802290 (-41, +50)
• 802341 -> 802321 -> 802351 (-20, +30)
• 803422 -> 803366 -> 803431 (-58, +65)

Investigation:

All reorgs follow the same pattern we observed previously. Reorged blocks are mostly empty, with only few transactions (that look like double-spend).

• Same fluctuations of hashrate.
• None of the reorg was above 60 blocks, as expected.
• No Network split

This time we further analyzed the reorged blocks where we suspected that there had been a double-spend contained within them. This showed that the replacement block spends some input that was spent also in the original block, whereas the outputs of the replacement block are different. Meaning, the original block contained A->B, whereas the replacement block contained A->C.

Unfortunately we couldn’t perform the same analysis on previous reorgs, because our nodes didn’t keep reorged (orphaned) blocks forever. However we could do this for the most recent reorgs. And this is what we discovered.

• 803422 -> 803366 -> 803431
• H=803424 Double-spend. Original Height=803375
• 802341 -> 802321 -> 802351
• H=802330 Double-spend. Original Height=802329
• 802281 -> 802240 -> 802290
• H=802250 Double-spend. Original Height=802246

So for the last 3 reorgs we are CERTAIN. This is a double-spend. We also know the exact spend height of the original (reverted) transaction. What remained unclear is WHY the attacker keeps doing this? Reorgs no deeper than 60 blocks should not cause funds to be lost on exchanges, because they should have at least 80 confirmations. Later in the evening we discovered abnormal trading values on some known exchanges and discovered that, contrary to our advice, they have had a small number of confirmations for Beam deposits.

Our conclusions:

• The attacker had identified exchanges with a small number of confirmations, and was able to conduct the attack repeatedly. Unfortunately exchanges didn’t notice this in time, despite our best prior advice, and their loss of funds.
• It is likely that the attacker also tried to conduct the attack on other exchanges, but didn’t succeed
• Some other exchanges which we contacted in this matter, reported they had deposits on the corresponding heights, but were reverted. Luckily they had took our advices and enabled enough number of confirmations for deposits of Beam.
• The attacker might also have tried deeper reorgs (to attack other exchanges), but didn’t succeed.
• In addition to stealing funds from exchanges, attacker puts the network at risk
• Some dependent transactions may not be recovered after the reorg, causing inconvenience to users
• Risk of network split is imposed

Our actions:

• We urgently contacted the affected exchanges we found, and asked them to raise the number of confirmations.
• We’re working on our API for pools and exchanges, so that their wallet will select only “mature” UTXOs for transactions, to prevent “accidental” transactions failure due to reversal of ancestor transactions. To reduce possible side effects of the reorgs.

This has been a very thorough and in-depth investigation by our team to pinpoint and mitigate against these attacks and it is not a unique event to Beam. It is a possible scenario for any cryptocurrency.

In the analysis of the events, we would like to assure and thank our community for your patience and understanding during this time of duress.

Finally we would like miners to consider how best you can assist us whilst we monitor and mitigate these attack events. Join smaller pools, bolster your decentralised Beam network by spreading your hashrate, protect your mined rewards from reorgs and don’t let these attackers perpetuate on overweight pools. Don’t enable them by centralising onto the largest pools.

Come discover Beam and join our community!

Download Beam Android Wallet on Google Play

Download Beam iOS Wallet on App Store

Learn more about Beam on our website and blog

Telegram: t.me/BeamPrivacy

QQ Beam 中国官方社区: https://jq.qq.com/?_wv=1027&k=5Mbs8N4

Reddit: reddit.com/r/beamprivacy/

Twitter: twitter.com/beamprivacy