Firo 51% attack post mortem and vote on attackers' funds

gusknure · January 25, 2021, 7:41pm

Seems like Binance disabled any pars with Firo.
So many lost forever?
It will be not possible to get money back?

anwar · January 25, 2021, 7:47pm

Binance is updating the ticker from XZC to FIRO. Read here:
https://www.binance.com/en/support/articles/4a06d6ab6abb4f08b12bb93d6fec30ec

GuyRer · January 25, 2021, 8:01pm

Someone don’t want to hold FIRO and want money back?
But if developers will show strength and will play with the rules, the project will have great future.
Otherwise it will not fly higher than my rockets and will never become SpaceX.
Look at the Charlie Lee works (@HighMiner , thank you): " If a crypto can’t be 51% attacked, it is permissioned and centralized."
He told that when LTC cost less 10$. What is the price of LTC today?
Look to the future of the project

gusknure · January 25, 2021, 8:55pm

didn’t saw this.
thanks

norsegaud · January 25, 2021, 10:22pm

Whatever is necessary to stay on exchanges is the only option. The ripple effect of being delisted from a major exchange would harm FIRO more than the attack.

jjk · January 25, 2021, 11:55pm

Let me start with revealing that my vote was “block funds and reimburse Binance”.
Especially since funds were blocked already when going for vote.
However, what I would like it to be, and how I think majority hope it will be, once Firo technology
is considered completed/finished, is the second option - “do nothing”.
I see as realistic to concede that Firo is not there (completed/finished) yet,
albeit we are inching close to at least loudly proclaim that “the code is untouchable law” for Firo.

Firo core team already went out of its way and manually blocked in the code the funds somehow
( I do not exactly understand how they did it ).
This on one hand shows how prone to centralized actions the project currently is, and,
on the other hand, it actually prevented the attacker from double-spending FIRO,
which is arguably an anti-feature of the once-finished Firo technology.

I see it as urgent to be very clear that this was only possible because the project is still in R&D phase,
defending designed yet unfinished developments, in this case strengthening Firo against 51% attack, and
thus prevent unwanted, unfair behavior.
Locking the funds manually was done to prevent de-facto double spending before the technology is
in its suficiently robust, self-standing, autonomous state a la Bitcoin.

The harm in the market terms hit Firo as a project, but the missing (orphaned) coins provably harm some of its users.
The reason for reimbursing Binance is that these users happened to be Binance users.
It is solely matter of fairness to users who are missing their FIRO coins
as a result of potentially illegal behaviour of double-spending,
and because the features preventing such behaviour are not in place yet as an inherent part of Firo.

It should have nothing to do with bowing to Binance or being scared of Binance.
It is also naive to think that Binance will not de-list us if they want to, even if we reimburse them with missing FIRO.
This is just a matter of fairness in a bit controversial self-defence by Firo.

reuben · January 26, 2021, 1:00am

Just to clarify, we couldn’t do this unilaterally as we required the mining pools to also accept our update. We did explain the situation to them and the code we deployed to manually block was public and accepted by them.

I do agree that as the project matures this sort of thing shouldn’t be possible (in fact if the attacker took just the additional step to anonymize) it would have been a lot harder.

sproxet · January 26, 2021, 5:43am

Hi, I’m sproxet, the developer of the Electron-based Firo Client interface. This message is signed with the GPG associated with my GitHub account, which can be retrieved and verified as belonging to that account by going to https://api.github.com/users/sproxet/gpg_keys

I strongly believe that the only viable course of action for the project is to seize the attacker’s funds and use it to compensate exchanges. While it is attractive philosophically to maintain rigid, abstract, and self-consistent principle, such as the doctrine that “Code is Law”, it’s important to understand the real effects that that would have on people, which should be obvious.

We are not slaves to a mechanistic god whose blockchain is of a sanctity beyond any associated with petty human concerns. The systems we create are tools to help people, which can, and in my thought should, be modified as the situation requires to be more effective in that purpose. Our choices, not the decrees of digital deities, decide our future.

jjk · January 26, 2021, 9:49am

Reuben you do a great job with Firo!!! A meaningful, cool, and useful job. Thank you. I just needed to get my head around what happened. You could add the fourth option “block funds, reimburse 70% Binance, and the rest give to Reuben” and I would consider it seriously - that’s the level of trust you’ve got with me over the years without even knowing you in person.

reuben · January 26, 2021, 9:51am

Thank you though I would never want to profit from something like this

jjk · January 26, 2021, 9:54am

Yeah, I know. That was a half joke, half analogy.

dodiggitydag · January 27, 2021, 4:34am

Would like to hear how we’ll prevent this in the future. I think you touched on it, but more detail would be great!

Roeer · January 27, 2021, 6:18am

Chainlock will be the soultion.

reuben · January 27, 2021, 1:19pm

Chainlocks are from Dash system and builds of the long lived masternode quorums (LLMQs) which we already functioning. This was always planned in our roadmap.

dips/dip-0008.md at master · dashpay/dips · GitHub is a deeper description of it.

In short, groups of 400 masternodes are formed deterministically and when they see a valid block they will poll among themselves that they saw this block first and sign it. Once signed, it serves as a checkpoint so that no block below this number will be valid.

To disable chainlocks to mount a 51% attack you would need control of 50% of the masternode network upon which it will revert to the longest chain rule.

reuben · January 27, 2021, 1:22pm

We’ll be closing this poll in a couple of hours. This is the most voted poll ever. Thank you for all your feedback!

I think this was also a good test in using the forum to help decide on matters. The arguments were excellent.

devwarrior · January 27, 2021, 2:09pm

They can and do! It is called development

reuben · January 27, 2021, 3:20pm

Poll is closing in 40 minutes. Last chance to get your votes in.

reuben · January 27, 2021, 4:08pm

Poll is now closed. We will make a Github PR enabling this soon, review then deploy.

reuben · January 29, 2021, 4:31pm

This is the relevant Github PR Allow one transaction to pass checks without script verification by psolstice · Pull Request #984 · firoorg/firo · GitHub