Bitfloor Exchange Hack

Notice: This page is a new case study and some aspects have not been fully researched. Some sections may be incomplete or reflect inaccuracies present in initial sources. Please check the References at the bottom for further information and perform your own additional assessment. Please feel free to contribute by adding any missing information or sources you come across. If you are new here, please read General Tutorial on Wikis or Anatomy of a Case Study for help getting started.

Notice: This page contains sources which are not attributed to any text. The unattributed sources follow the initial description. Please assist by visiting each source, reviewing the content, and placing that reference next to any text it can be used to support. Feel free to add any information that you come across which isn't present already. Sources which don't contain any relevant information can be removed. Broken links can be replaced with versions from the Internet Archive. See General Tutorial on Wikis, Anatomy of a Case Study, and/or Citing Your Sources Guide for additional information. Thanks for your help!

It’s reported that "the attacker gained accesses to an unencrypted backup of the wallet keys (the actual keys live in an encrypted area)." It’s unclear from the forum discussion if a proper wallet structure was used, however it was definitely not multi-sig, and obviously none of it was insured. None of the customers were able to retrieve any of their funds in the end.

About BitFloor

“Bitfloor was” a “[l]eading U.S. Bitcoin exchange” “in September of 2012.”

"Mr Shtylman said his New York-based service was the biggest of its kind in the US and the fourth largest in the world."

The Reality

This sections is included if a case involved deception or information that was unknown at the time. Examples include:

• When the service was actually started (if different than the "official story").
• Who actually ran a service and their own personal history.
• How the service was structured behind the scenes. (For example, there was no "trading bot".)
• Details of what audits reported and how vulnerabilities were missed during auditing.

What Happened

“Bitfloor was breached in September of 2012, losing over 24,000 BTC during the incident.”

Key Event Timeline - Bitfloor Exchange Hack

Date	Event	Description
September 3rd, 2012 9:07:39 PM MDT	First Theft Transaction	The first theft transaction on the blockchain.
September 5th, 2012 5:26:21 AM MDT	BBC Article Published	BBC published an article about the BitFloor exchange. According to the article, "Bitfloor's founder, Roman Shtylman, said he had kept unencrypted keys, which the thief accessed and used to take the money."

Technical Details

“It all started when the exchange’s server crashed, either under the influence of a DDoS-attack or because of a power outage in the data center — as was claimed by its owner Roman Shtylman.”

• 83f3c30dc4fa25afe57b85651b9bbc372e8789d81b08d6966ea81f524e0a02be
• d5d23a05858236c379d2aa30886b97600506933bc46c6f2aab2e05da85e61ad2
• 358c873892016649ace8e9db4c59f98a6ca8165287ac80e80c52e621f5a26e46
• f9d55dc4b8af65e15f856496335a29e2be40f128a7374c75b75529e864579f93
• 42ea472060118ee5aee801cdedbc4a3403f3708a87340660f766e2669f0afeb0

Total Amount Lost

The total amount lost has been estimated at $240,000 USD.

Immediate Reactions

How did the various parties involved (firm, platform, management, and/or affected individual(s)) deal with the events? Were services shut down? Were announcements made? Were groups formed?

“Four days after, the hackers used a backup copy of the key from the hot wallet of the exchange, where the funds of traders were stored, and withdrew 24,000 BTC.”

“Bitfloor explained at the time that the exchange’s hot wallet data was mistakenly held on the company’s servers which led to the hack. No bitcoins were returned to customers after the hack even though the company resumed trading and promised restitution.”

“As funds are available for repayment, they will be dispersed on a pro-rated basis,” explained Bitfloor’s founder and operator Roman Shtylman.

Ultimate Outcome

“Shtilman made an unsuccessful attempt to compensate the victims by selling a stake in BitFloor's property, but could not find an interested party.”

“However, according to the company, Bitfloor’s banks had ceased doing business with the startup and customers never saw their funds again.”

“In 2013, the exchange closed, leaving the affected investors with nothing.”

Total Amount Recovered

There do not appear to have been any funds recovered in this case.

Ongoing Developments

What parts of this case are still remaining to be concluded?

Individual Prevention Policies

No specific policies for individual prevention have yet been identified in this case.

When using any third party custodial platform (such as for trading), it is important to verify that the platform has a full backing of all assets, and that assets have been secured in a proper multi-signature wallet held by several trusted and trained individuals. If this can't be validated, then users should avoid using that platform. Unfortunately, most centralized platforms today still do not provide the level of transparency and third party validation which would be necessary to ensure that assets have been kept secure and properly backed. Therefore, the most effective strategy at present remains to learn proper self custody practices and avoid using any third party custodial platforms whenever possible.

For the full list of how to protect your funds as an individual, check our Prevention Policies for Individuals guide.

Platform Prevention Policies

All wallets, minting functions, and critical infrastructure should be implemented with a multi-signature requirement, with a recommended minimum of 3 signatures required. This means that making important changes or approving spending will require the keys held by at least 3 separate individuals within the organization to approve. The multi-signature should be implemented at the lowest layer possible, all key holders should have security training, and all key holders should be empowered and encouraged to exercise diligence.

All aspects of any platform should undergo a regular validation/inspection by experts. This validation should include a security audit of any smart contracts, reporting any risks to the backing (of any customer assets, ensuring treasuries or minting functions are properly secured under the control of a multi-signature wallet, and finding any inadequacies in the level of training or integrity of the team. The recommended interval is twice prior to launch or significant system upgrade, once after 3 months, and every 6 months thereafter. It is recommended that the third party performing the inspection not be repeated within a 14 month period.

Work with other industry platforms to set up a multi-signature wallet with private keys held separately by delegate signatories from seven prominent platforms and services within the industry. Establish requirements for contributions by all platforms and services, designed to be affordable for small platforms yet large enough to cover anticipated breach events. Any breach event can be brought forth by a member platform or a petition of 100 signatures for consideration by the delegate signatories. A vote of 4 or more delegate signatures is required to release any funds, which could partially or fully restore lost funds based on their assessment.

For the full list of how to protect your funds as a financial service, check our Prevention Policies for Platforms guide.

Regulatory Prevention Policies

All platforms should undergo published security and risk assessments by independent third parties. Two assessments are required at founding or major upgrade, one after 3 months, and one every 6 months thereafter. The third parties must not repeat within the past 14 months. A risk assessment needs to include what assets back customer deposits and the risk of default from any third parties being lent to. The security assessment must include ensuring a proper multi-signature wallet, and that all signatories are properly trained. Assessments must be performed on social media, databases, and DNS security.

Set up a multi-signature wallet with private keys held separately by delegate signatories from seven prominent platforms and services within the industry. Establish requirements for contributions by all platforms and services within the country, designed to be affordable for small platforms yet large enough to cover anticipated breach events. Any breach event can be brought forth by a member platform or a petition of 100 signatures for consideration by the delegate signatories. A vote of 4 or more delegate signatures is required to release any funds, which could partially or fully restore lost funds based on their assessment.

For the full list of regulatory policies that can prevent loss, check our Prevention Policies for Regulators guide.