Overview

On September 8th, 2018 we were informed by Bittrex that the FLO network was subject to a large reorg of blocks (precisely 443) which resulted in a deposit of 680,000 FLO to be invalidated, along with several smaller deposits summing up to approximately 20,000 FLO. As a result, Bittrex’s FLO wallet was closed for deposits and withdrawals, although trading is still enabled on the exchange. Depositing and withdrawing will remain unavailable until a technical solution is found.

FLO has supported Bittrex with software updates and technical matters since Bittrex listed our coin on its exchange since March 2015. The FLO team would like to take responsibility for paying back the 700,000 FLO that Bittrex lost. We’re currently implementing a technical solution to prevent 51% attacks on our chain in the future.

Why did this happen to FLO? Weren’t the devs aware of the vulnerability?

Approximately 2 years ago, the FLO team got together and discussed changing the consensus algorithm on FLO to something other than proof of work. The Alexandria devs were adamant about sticking with proof of work because they felt that it had more potential to stay decentralized and secure over the long term. As a precautionary measure, we asked Bittrex to increase its required confirmation time to 300 confirms, greatly increasing their security against a 51% attack.

If we had ignored the Alexandria devs and switched away from proof of work at that time, the other three apps on our chain would not have selected FLO for their blockchain solution. Had we switched consensus mechanisms, it is likely that the Jensen Lab at Caltech, Medici Ventures, and tZERO would not have been interested in building on FLO.

To summarize the above, the FLO devs made the decision to stick with proof-of-work based on the wishes of:

Alexandria

The Jensen Lab at Caltech

Medici Ventures

tZERO

In other words, many important apps on top of our chain would be forced to consider another blockchain to build on if FLO switched away from proof-of-work.

What is the proposed solution?

Our solution is to implement Sunny King’s advanced checkpointing system. This system was originally deployed in Peercoin, Quark, and Primecoin, and is also currently in use in the Feathercoin core codebase.

What is advanced checkpointing?

Sunny King’s advanced checkpointing system can be used to enforce a rule disallowing block reorganizations back past the most recent checkpointed block.

Current plan to implement checkpointing

Forking Feathercoin 0.16.1 is our current plan because of the similarity between FLO and FTC. Feathercoin implements Sunny King’s checkpoint system and is listed on Bittrex. https://github.com/FeatherCoin/Feathercoin/releases

Technical details

Checkpoints disallow block reorganizations back past the most recently checkpointed block. One node is responsible for checkpointing blocks on the network. This node authenticates checkpoint data using an asymmetric key owned by the coin developer. All other nodes enforce checkpoints by default, but there is an enforcecheckpoint option to toggle checkpoint enforcement on and off within the client.

Advantage: 51% attacks are much more difficult to execute because the attacker’s secretly-mined blocks will not be checkpointed and an attempt to reorganize checkpointed blocks won’t be valid.

Disadvantage: This solution is currently centralized around a single developer’s key and node.

Potential threat: DDOS attacks can interrupt the connection between the developer’s checkpoint node and other nodes on the network.

Overall, PoW with advanced checkpointing is far more secure than PoW without it, and it is a good solution for the time being.

Timetable

In the last 5 and a half years FLO has existed, in general, it has taken 1–2 months to make an upgrade to the protocol code. This is the expected timetable for another similar upgrade.

Long term solution

In the end we want to move away from a centralized checkpoint server operated by developers. Here are the following considerations we have for more secure PoW consensus mechanisms.

Currently the only solutions for PoW chains are:

Become the supermajority leader in your hardware profile for the algorithm you’re using for consensus (Bitcoin, Ethereum, etc) Use a hybrid PoW/PoS system Use decentralized checkpointing and notary (KMD, Veriblock) Layer-2 or sidechain with Bitcoin Collaborative-defense by stake-holders in projects built on FLO (theoretical only, in development by Alexandria)

Who controls the funds collected for the FLO upgrade?

The addresses are owned by the FLO dev team and will be managed by the team.

Who will manage the checkpoint node?

The checkpoint node will be managed by the FLO developers as well as the Alexandria team.

What can I do to help?

The team is launching a community effort to re-pay the lost FLO to Bittrex in honor of our relationship with them. If you would like to contribute, please donate to one of the addresses below:

FLO: F7LP3ABRSathxFCWVeVaygWKSQcHBvwzKZ

BTC: 1CYRfTv9EL7yc4d9aLRqkgp49aBsGaFCgN

ETH: 0x0a92567249d6aEE28ED201d2125BE1b550bDa56D

Any surplus donations will be used to accelerate development work on the advanced checkpointing upgrade for FLO.

2018–12–13 update: FLO has been upgraded to version 0.15.1.1 with a maximum reorg depth update, similar to Ravencoin’s solution. The original plan outlined below was abandoned and no central node was implemented into the core code. Instead, the more applicable max reorg depth consensus rules were added to FLO.