Ravencoin — Building the immune system

The Ravencoin network experienced several attacks on September 13–14, 2018. There was a double-spend attack that took place over a couple of days by morally bankrupt attackers.

One of the known vulnerabilities of crypto-currencies is the 51% double-spend attack. Any mining pool, or individual that can marshal more mining power than the rest of the network, can tamper with the network. They can’t spend your funds, as that would require your private key, but they can spend their own funds — twice.

How is this attack done?

1. Send the funds in a transaction. In this case, RVN was sent to an exchange.
2. Get the value out. In this case, they exchanged RVN for BTC and withdrew the BTC.
3. Mine a new chain starting with a block above the original spend by renting hash power.
4. Decrease the honest mining hash power by DDOS attacking the honest mining pools.
5. Double-spend the same funds back to the attacker in order to invalidate the original deposit. This will replace the original spend if the chain has more work.
6. Once the counterfeit hash power is larger, then submit the chain, erasing the original RVN transaction.

Details

See the Appendix below.

How can this happen?

This has always been possible on Bitcoin, or any other UTXO coin. This is still possible on Bitcoin, but much less likely because of the extreme amount of honest mining power relative to the amount of rentable hash power. Smaller coins are not as protected, and several 51% attacks have taken place over the last few months on smaller coins.

Rentable hash power has become a problem for a number of coins. During the early days of RVN, this was not a problem because x16r was new and the algorithm was not available to rent. As RVN has become more popular, the demand for the x16r hashing algorithm caused the major hash renting companies to support x16r. This opened up a new attack vector that didn’t exist until recently.

This was not caused by a flaw or bug in Ravencoin, but is an inherent risk in UTXO coins where the security is always probabilistic. With sufficient mining power, any number of blocks can be re-written.

Was this related to the recent DGW (difficulty adjustment) algorithm?

It does not appear to be. We analyzed the orphaned blocks, and compared the difficulty with the difficulty of the replacement blocks. The DGW worked as expected, increasing the difficulty on the attacker by a small percentage because they were slightly ahead of the work on the main chain.

Is it a problem for assets?

Yes, this attack vector must be addressed for assets because as the value of the assets stored on the Ravencoin chain increases, the block reward which incentivizes the miners in RVN may not rise at the required rate to protect the network.

What are the possible solutions?

There are several possible solutions. Some of the solutions which might work for other coins are not compatible with Ravencoin’s philosophy of being fully decentralized.

Possible Solution:

• Simply increase number of confirmations required before a transaction is considered “accepted”.
• Problem: Attackers may be able to marshal additional hash power to reorg more blocks.

Possible Solution:

• Create checkpoints with block height and hash on a server periodically.
• Nodes verify checkpoints before accepting a chain.
• Problem: Incompatible with the decentralized nature of Ravencoin.
• Problem: DDOS attacks on centralized nodes can interrupt connection between centralized server and other nodes.

Possible Solution:

• Throw all the hackers into a lake of fire.
• Problem: Not sure we can find them all.
• Problem: Sourcing a lake of fire.

Possible Solution:

• Use a platform like KMD — Komodo Platform to anchor hashes periodically.
• Problem: Incompatible with the decentralized nature of Ravencoin and requires payment.

Possible Solution:

• Anchor Ravencoin hashes into a decentralized secure chain like Bitcoin.
• Problem: Requires payment and someone or some server (centralized) to hold private keys to pay for anchoring.

Possible Solution:

• Create checkpoints with a privileged developer private key.
• Problem: Incompatible with the decentralized nature of Ravencoin. Places responsibility and trust in a centralized entity.

Possible Solution:

• Don’t allow a chain reorganization after X blocks.
• Problem: Can prevent a valid chain re-integration and therefore a possible network split.

Possible Solution:

• Don’t allow a chain reorganization after X blocks, but only if fully synchronized, and well connected to nodes.
• Can prevent a valid chain re-integration and therefore a possible network split, but only in extraordinary cases.

Is this a continuing concern?

Yes. The best solution would be to have enough honest hash power that an attack would be impossible with sufficient confirmations required. Until that day, the Ravencoin blockchain is at risk of a double-spend attack by morally bankrupt attackers.

What can be done?

The chosen option to prevent future double-spend attacks is a default maximum reorg depth with specific node conditions. This has been discussed by other blockchain developers, and has been implemented in some proof-of-stake coins. Ravencoin is integrating this change into the code for a future release.

The default max reorg depth selected for RVN is 55 blocks. At the 1 minute expected time for blocks, this is nearly an hour. It is comparable, in wait time, to the six 10-minute blocks used on the Bitcoin blockchain.

This would allow an exchange, to set their confirmations to 60 blocks (about one hour), and be reasonably certain that the blockchain will not re-organize and orphan (“vaporize”) the deposit.

One downside to this solution is that a rogue node could send 55 blocks to another node, and the node would then stop listening to the larger honest blockchain. For this reason, there are some other conditions that must be met before a node will ignore other larger, potentially fraudulent “surprise” blockchains. It must be connected to enough nodes so it isn’t tricked into accepting a bogus chain for 55 blocks at which point it would stop accepting blocks from the honest chain. It must be “caught up” on the blockchain because we are only making this reorg exception to prevent real-time surprise selfish-mining double-spend attacks.

For Gavin Andresen’s “half-baked thoughts” (his words, not mine) on this solution: https://gist.github.com/gavinandresen/630d4a6c24ac6144482a

Thank you Gavin.

It may be possible to set the number lower, but lowering the number too much comes with some risk. If there is a valid chain fork of too many blocks, the network would not come back together and there would be two different Ravencoin chains. This is very unlikely at 55 blocks and it hasn’t happened in Ravencoin’s short history. A 22 block reorg is the maximum experienced by Ravencoin mainnet, and it was a result of the recent attack. With more data, and after careful evaluation of how well this works, it may be possible to lower the max reorg default value. The advantage of a lower number is the ability to reduce the number of confirmations required to safely accept RVN or a Ravencoin hosted asset.

Is this a hard fork?

No, it is not part of the consensus rules, and can be changed. However, it can cause the blockchain to fork, but only if there is a 55+ block surprise selfish mining attack. Anyone using the new default maximum reorg depth will not accept surprise chains that invalidate 55 blocks or more. This is an improvement because Ravencoin nodes will not accept surprise, selfishly privately mined blocks. While the original software will switch over to the larger-proof-of-work, but probably to a fraudulently selfishly mined blockchain.

This change will be included in the software that is asset capable (probably version 2.1), but will activate immediately upon installation and is not part of the BIP9 activation of assets.

The max reorg depth setting can be changed by the nodes with a command-line setting, but it is advisable only to do so if you know what you’re doing, or if your node has incorrectly stopped syncing with the honest blockchain.

Building Ravencoin’s Immune System

Bitcoin has been compared to a sewer rat with a bulletproof immune system. If you haven’t watched Andreas talk about the adaptations that Bitcoin went through, you should watch this video: https://www.youtube.com/watch?v=810aKcfM__Q (jump to 12:57 if you’re short on time) This attack is a virus for which Ravencoin needs an immune response. The code will make Ravencoin stronger, and better able to securely carry assets.

Open for discussion

This change is code complete. If you understand the issues, we’d love your feedback on the benefits and potential pitfalls of this change: https://github.com/RavenProject/Ravencoin/pull/295

Update

The default re-org depth is being set to 60 instead of 55. The extra 5 block buffer isn’t needed. The code is set to only prevent the re-org if blocks being replaced are 60 or more and node count is 4+ and the IsInitialDownload is false. https://github.com/RavenProject/Ravencoin/pull/316

I’d recommend that exchanges and commerce sites should set their confirmation for acceptance of RVN or Ravencoin hosted assets to 60 confirmations after version 2.1 is widely adopted.

Appendix

Example transaction:

Replacing 200,000 RVN with a double-spend

8143d279f8d6b84c1da62cc75c9ccbf822e6a102355df18ebab824d054f0d1da

On the Ravencoin block explorer:

https://ravencoin.network/tx/8143d279f8d6b84c1da62cc75c9ccbf822e6a102355df18ebab824d054f0d1da

Orphaned Block: 000000000001e961c1071198e5d7832384f211c1bc0c1f2c64d0bac45b2e828c

At the end of 10 block selfish mining attack

Orphaned block 360036 00000000000281f0636942053bc55169c4e0fa125b187271559bba297b9fae22

Diff: 25643.80719237

Replacement block 360036 0000000000019ff5c62bba554037d9e4442c5d0da6df1be043b0fa67947805fc

Diff: 26078.86234053

DGW difficulty difference: +1.7% for the attacker

Several multi-block replacements were done, with the longest being 22 blocks.