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!

BitFloor Logo/Homepage

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.”

Bitfloor was founded by Roman Shtylman. "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
February 23rd, 2012 4:55:20 PM MST	The Bitcoin Show YouTube Interview	An interview is conducted and published on The Bitcoin Show with BitFloor founder Roman Shtylman. The interview explores the development of a Bitcoin exchange platform, focusing on user-friendly features and trading options. The speaker highlights the need for simplified trading processes, including a one-time confirmation button for transactions and an "Auto Sell" feature for merchants to manage currency risk effectively. They discuss the launch of a test network for users to practice trading safely and emphasize the importance of clear API documentation and responsive customer support. Additionally, Roman outlines a unique liquidity provider model that rewards users for placing standing orders, encouraging a fuller order book and facilitating better trading conditions. Future plans include revamping the web interface based on user feedback and enhancing reporting features.
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."
December 2012	Final Repayment	The final repayment from the BitFloor exchange operator.
May 18th, 2013	Bitcoin 2013 Meeting	Reported/speculated that Roman Shtylman reached out to the Internet Archive's IAFCU (Internet Archive Federal Credit Union) after a presentation at the Bitcoin 2013 conference.
August 5th, 2013 1:44:51 PM MDT	Repayments In Progress	According to a capture of the BitFloor website, repayments are still in progress, being facilitated by the IAFCU (Internet Archive Federal Credit Union).
March 26th, 2014 11:21:51 AM MDT	Site Still Captured Online	The Bitfloor website is still captured as online.

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

“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.