This note is to advise and reassure our community that Beam Team is dedicated to keeping our decentralised network safe from attack.
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.
Several big reorgs happened in a row.
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.
2 big reorgs happened in a row.
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.
Double-spend attack is very likely.
Complexity of the attack: modest
Cost of the attack
We implemented a rolling checkpoint mechanism that prevents automatic reorg any deeper than 60 blocks.
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.
All reorgs follow the same pattern we observed previously. Reorged blocks are mostly empty, with only few transactions (that look like double-spend).
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.
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.
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
QQ Beam 中国官方社区: https://jq.qq.com/?_wv=1027&k=5Mbs8N4
Write a post
Are you sure you want to delete this post?
Are you sure you want to delete this comment?
Purchase has been completed.
닉네임을 설정 후 작성해주세요.