Skip to main content
Skip to content
Case File
efta-02725909DOJ Data Set 11Other

EFTA02725909

Date
Unknown
Source
DOJ Data Set 11
Reference
efta-02725909
Pages
15
Persons
0
Integrity

Summary

Ask AI About This Document

0Share
PostReddit

Extracted Text (OCR)

EFTA Disclosure
Text extracted via OCR from the original document. May contain errors from the scanning process.
NYC Bitcoin Exchange The First NYDFS Regulated Bitcoin Exchange EIFTA_R1_03213475 EFTA02725909 Problem Bitcoin is innovative but exchanges have had problems • A brief history of Bitcoin o Bitcoin: open source technology invented in 2009 o Widely hailed as technological breakthrough o Like the early Internet, bumpy patches and security problems o Most prominent: Mt. Gox meltdown and funds loss o Also potential issues around KYC, AML, compliance • Where we are today o Pressing need for a stable, regulated Bitcoin exchange o NYDFS is leading the way with a regulatory framework o Regulated exchange should have provisions for auditing of customer balances, KYC/AML compliance, strong security EFTA_R1_02213479 EFTA02725910 Solution A safe, regulated Bitcoin exchange under NYDFS • Compliance Goals o Compliance: Provide full audit trails of every dollar and BTC that passes through the system, along with identities of large buyers o Liquidity: Ensure liquidity for the Bitcoin ecosystem, and have large enough reserve ratios to prevent Gox-like situation o Trust: Create trust in Bitcoin ecosystem, allow institutional investors to establish positions in digital currencies o Reputation: Build in partnership with established/reputable investors and venture capital firms • Technological Goals o Easy to use front-end comparable to large consumer websites o Top-to-bottom emphasis on information security EFTA_R1_02213480 EFTA02725911 Executive Team Have built and scaled $1B+ in tech/ finance companies • Matt Pauker (CEO) o Founder, Voltage Security (>$40m rev) o Author of 15+ cryptography patents; commercialized IBE o BS Computer Science, Stanford • Andrew Farkas (Board of Directors) o CEO of Island Capital o BA Economics, Harvard • Balaji S. Srinivasan (Chairman) o Newest General Partner at Andreessen Horowitz (1, a) o Founder/CTO, Counsyl (-5% US births, —$1B+ val) o BS/MS/PhD EE, MS ChemE Stanford • Terence Spies (CTO) o CTO of Voltage Security o Designed SSL server/client for Microsoft Internet Explorer o Chairs ANSI X9F1 bank cryptography committee EFTA_R1_02213481 EFTA02725912 Technology What technological considerations are involved? 170,121_02213402 EFTA02725913 Technical Challenges Building a Bitcoin exchange is computer science Security o Exchange will be under constant attack by hackers around the globe; both Denial of Service and active threats (e.g., APTs) o Bitcoin relies on advanced cryptography; getting it wrong can result in loss of funds (see Mt. Gox) Ecosystem integration o I \change is one of several core Bitcoin infrastructure services o Must provide tight API integration with wallets, merchant processors, miners Compliance o Technology must be designed to support (often conflicting) compliance goals o Leverage best practices from PCI, FFIEC, NIST EFTA_R1_02213483 EFTA02725914 Technical Challenges Our number one concern technologically is security • Threats o Distributed denial of service (DDoS) o 0-day exploits in open source software o Spear-phishing o Advanced persistent threats (e.g. China) o Source code compromise o Social engineering attacks o Physical compromise of vaulting facility or datacenter • Mitigation o FireEye/Mandiant (malware), Cloudflare (DDoS), Sift Science (fraud), Voltage (encryption), Skipfish/Ratproxy (headless) o Open bids for zero days in any software utilized o Constant penetration testing, automatic/manual (Detectify) o Static and dynamic checking of codebase (Coverity) EFTA_R1_02213484 EFTA02725915 Technical Challenges Security expertise must be baked into every layer Example: Heartbleed: Security issues are subtle r Meg wants these 500 letters: HAZ. . .. ! ; ! HI . I:4X: . • ? : • . . !•••:r:n r•qa v !! . . •••-! ••••• . . . . . • . rr•i rt. • , : • : • 4 7 t. • HAT. [eras requests tho "laiso-A ccero ctians* pogo. Eve laaninistraUx} war. to to set server's ouster key to - 148 35038534'. Isabel wants pages about sashes but not WO Ion' . User Karen swats to change account Fas..,vord to EFTA_R1_02213485 EFTA02725916 Technical Architecture Increase security via subsystem isolation, cold storage Accounting System 00' Customer Accounts User Mgmt Exchange Wallet System System System Web UI API Cold Wallet Enrollment (KYC) Transaction Validator Warm Wallet Authentication Hot Wallet Funds Transfer Core Engine Bitcoin Network Interface Services-Oriented Architecture improves security o Discrete, well-defined subsystems reduce risk of spillover attacks Full auditability for all functions o User activity, funds, trades Will work closely with NYSDFS on functionality & user interface O Ensure regulatory compliance, proper disclosures, transparency EFTA_R1_02213486 EFTA02725917 Technical Architecture Limit amount of "hot" Bitcoin; most in cold wallet Seller Wallet Buyer Wallet NYBE Inbound Wallet NYBE Outbound Wallet NYBE Hot Wallet NYBE Cold Wallet Typical transaction flow: o Seller sends BTC into NYBE Inbound Wallet, then stored in Hot Wallet o After trade, BTC is moved to Outbound Wallet, then Buyer Wallet o Seller & Buyer Wallets reside at 3rd party (Coinbase, Xapo, etc.) Occasionally: money moved out of Hot Wallet o Maintain minimum required amount of BTC online EFTA_R1_02213487 EFTA02725918 Technical Architecture Security principles for wallets, passwords, pentesting Bitcoin wallets o Not a consumer wallet provider: only hold customer funds for trading o Three-tiered wallet hierarchy ■ Hot: online, available immediately (-25%) ■ Warm: offline, available within 24 hours (-25%) ■ Cold: offline & geo-dispersed, available within 72 hours (-50%) Industry-standard best practices o Least-privilege architecture o Two-factor user authentication o n-of-m key sharing o Bank-level network & data security design (256-bit encryption, anti-DDoS) Continuous evaluation o Regular internal security audits o External "red teams" to identify potential vulnerabilities EFTA_R1_02213488 EFTA02725919 Technical Architecture We build the exchange for extensibility beyond BTC Exchange built to handle more digital currencies over time o Compliance is kcy in all of this; start with liTC, generalize as we build confidence o Technology: simply requires additional wallet subsystems on top of existing architecture Items we may trade over time o Altcoins: Bitcoin "clones" (Litecoin, Namecoin) which primarily change some parameters o Appcoins: new proof-of-work systems with new functionality (Namecoin, Ethereum, Mastercoin) o Side-chains: support for side-chains & proof-of-burn o Smart property: can use the blockchain to exchange software licenses, stock certificates, digital keys to houses, etc. o And more: Colored Coins video gives sense of what Bitcoin can enable EFTA_R1_02213489 EFTA02725920 Exchange Economics Two possible models for an exchange Model I: Pure facilitation of trades o In this model, we bucket all buy/sell orders into (say) .1 BTC buckets o We then match buyers and sellers in the same bucket o Buyers and sellers exchange directly with each other and the exchange takes a commission • Model II: Serve as counterparty o In this model, we are the buyer and seller of BTC traded on the exchange o We maintain BTC and USD reserves that are sufficient to handle large spikes in buy or sell orders o The exchange monetizes through the size of the bid/ask spread o Benefit: greater liquidity for exchange customers. Cost: larger reserve ratios. EFTA_R1_02213490 EFTA02725921 Next Steps We'd like to work with NYDFS on this. EIFTA_R1_02213491 EFTA02725922 Next Steps What's the next step from NYDFS's perspective? • Areas we are seeking input o What is the optimal corporate structure for this vehicle in NYDFS's view? o What existing legislation/regulatory framework is NYDFS thinking about using as a basis for this? o How does NYDFS think about annual Bitlicense/exchange fees and the like, if any? o What type of ongoing supervision does NYDFS envision? o These are the sorts of questions we'd like to figure out collaboratively; please tell us how we can help. EFTA_R1_02213492 EFTA02725923

Technical Artifacts (31)

View in Artifacts Browser

Email addresses, URLs, phone numbers, and other technical indicators extracted from this document.

Phone2213402
Phone2213479
Phone2213480
Phone2213481
Phone2213483
Phone2213484
Phone2213485
Phone2213486
Phone2213487
Phone2213488
Phone2213489
Phone2213490
Phone2213491
Phone2213492
Phone2725909
Phone2725910
Phone2725911
Phone2725912
Phone2725913
Phone2725914
Phone2725915
Phone2725916
Phone2725917
Phone2725918
Phone2725919
Phone2725920
Phone2725921
Phone2725922
Phone2725923
Phone3213475
Phone5038534

Forum Discussions

This document was digitized, indexed, and cross-referenced with 1,400+ persons in the Epstein files. 100% free, ad-free, and independent.

Annotations powered by Hypothesis. Select any text on this page to annotate or highlight it.