Multi-Sig Recipes
•Descargar como PPTX, PDF•
1 recomendación•898 vistas
A talk on different recipes (models) for multi-sig Bitcoin security, delivered at Boost, Mar 17 2015.
Recomendados
Recomendados
Más contenido relacionado
Destacado
Destacado (14)
Similar a Multi-Sig Recipes
Similar a Multi-Sig Recipes (20)
Último
Último (20)
Multi-Sig Recipes
- 1. Multi-Sig Recipes Ben Davenport, BitGo @bendavenport ben@bitgo.com
- 2. Goal Learn some ways to use multi-sig to provide enhanced security for your service and unlock new possibilities for users.
- 3. Agenda ● Ingredients ● Recipes ● Real world examples
- 4. Ingredient: Multi-Sig ● Introduced in BIP 11 (Oct 2011) ● OP_CHECKMULTISIG ● Requires M-of-N keys to sign ● Eliminates a single point of failure (the key) ● Direct use supplanted by indirect (P2SH)
- 5. Ingredient: P2SH ● Introduced in BIP 16 (Mar 2012) o P2PKH: 1DRW7nQ4adMk7xPTXf2KeB7AxzDtX1fNrU o P2SH: 3Q8pEaNZeaC6pHtaFRsTUrFhdrH8e6hkBe ● ~8% of bitcoin currently in P2SH addresses ● Mainly used for multi-sig today
- 6. The Recipes ● Use basic ingredients of P2SH and multi-sig ● Add additional techniques ● Describe security for a single wallet ● Combine recipes as necessary
- 7. But First: Multi-Sig Diagrams ● Single key is easy to reason about ● Multi-sig => Combinatorial explosion ● Need a visual language ● Represent as graphs o Nodes = entities o Directed edges = control (full or partial)
- 8. Recipe: Good Old Single-Key As simple as it gets:
- 10. 2-of-2 Multi-Device Examples ● Multiple computers o BitcoinD createmultisigaddress o Armory lockboxes ● Computer + Phone o Bitcoin Authenticator ● Computer + Hardware Wallet o Trezor o Ledger
- 11. Recipe: Joint Wallet (M-of-N)
- 12. Joint Wallet Examples ● Husband & Wife ● Custodial wallet for child ● Business partnership
- 14. Multi-Sig Escrow Examples ● HashTrust ● BitRated ● OpenBazaar
- 15. Ingredient: Co-Signing Service ● 2 keys held by customer, 1 key by service ● User creates and half-signs transaction, then sends to co-signer ● Co-signer executes security and logic
- 16. Recipe: Co-Signed Wallet (1 user)
- 17. Co-Signed Wallet Example ● Core model for all BitGo wallets ● Enables additional control / security o Require 2FA from user o Time-delays / out-of-band notification o Transaction velocity limits o White/black-listing of addresses o Apply fraud detection algos
- 18. Recipe: Multi-User Co-Signed Wallet
- 19. ● Per-day limits / Per-transaction limits ● Destination bitcoin address whitelists ● Time of day restrictions ● Human approvals - User/password/2FA ● Red button (kill switch) ● Blacklisting, IP lockdown, ... ● External webhooks BitGo Co-Signer Logic
- 20. Corporate Treasury ● Multiple users on a wallet o Require 2FA and User Auth ● Lower level emp can spend limited amounts ● CEO, CFO able to approve large withdrawals ● Can add/remove privileges of users at any time ● Example customers: SecondMarket, ChangeTip, BitFury
- 21. ATM Provider ● Shared wallet with multiple machines ● One access token per machine ● IP lockdown for each token ● Tokens may be individually revoked ● Example customers: Lamassu ATMs
- 22. Exchange Hot Wallet ● Per-day limit ● Callback via webhook ● Enforce human approver for large transactions ● Examples: Bitstamp, BitSpark, BitQuick
- 23. Exchange-owned Segregated Wallet ● One wallet per exchange user ● Per-user-wallet policy granularity ● Withdrawals require user 2FA ● Transactions to house wallet whitelisted
- 24. Recipe: Exchange Segregated Wallet
- 25. Exchange+User Joint Wallet ● User and exchange each own a private key ● Instant confirmation ● Withdrawals depend on o Webhook call to exchange to ensure user has sufficient margin
- 26. We Want to Work with You How can we help you? ● Co-develop new recipes ● Enhance your security ● Improve your operational efficiency
- 27. Thank you visit: https://www.bitgo.com/platform twitter: @bendavenport email: ben@bitgo.com
Notas del editor
- (Delivered at Boost, Mar 17 2015) Hi everyone, my name is Ben Davenport I’m co-founder and Chief Product Officer at BitGo (My history with Bitcoin / BitGo)
- Keys to cooking: know your ingredients, your techniques, and how to combine them into great recipes Same for building secure systems: understand the building blocks & how to put them together successfully. Follow proven recipes for security where possible -- generally innovate on product, not security.
- The first standard BIP Con: pubkeys are revealed in blockchain prior to spending (inferior to P2PKH) Bigger con: communicating payment instructions from recipient to sender (no longer an address) Never achieved much adoption, problems were solved by P2SH
- P2SH was developed in 2012, in BIP16 Allows recipient to give sender arbitrary Bitcoin script hash to receive payment -- sender doesn’t care what the script looks like. Helps retain the useful fiction of addresses that have balances - they just look different Moves fee burden due to script complexity to recipient Amount held in P2SH addresses is only around 8%. Many people haven’t moved their coins out of single key addresses yet. Inertia is powerful. Single key addresses are risky because of the rising amount of hacks, malware and viruses out there today targeting Bitcoin. No single online machine can be considered uncompromisable The only truly ‘safe’ move with a single key address setup is to hold coins it in cold storage and not use them. Cold / hot model is inherently a pooled, off-blockchain approach: we can do better P2SH and multi-sig allow for new ways to use Bitcoin in a more secure fashion.
- We’ll now take a look at several multi-sig concepts and scenarios that have emerged or are emerging today. We’ll add additional techniques which help provide access control and eliminate single points of failure Recipes are typically describing security model of a single wallet or scenario A real business will ultimately need to expand these recipes and/or combine a number of recipes
- Single key systems are pretty simple - not many ways to combine them. Multi-sig recipes can have many more moving parts There’s a fundamental combinatorial explosion It’s useful to have a visual design language to understand how the pieces of the system relate
- Bitcoin is controlled by 1 key Key is controlled by 1 user As simple as it gets Only way it gets simpler is if the user loses his key, or gets hit by a bus
- A single user controls 2 keys, both of which are required to move the bitcoin They better be on different devices, because otherwise, why bother? Better than single key, because multiple machines would need to be compromised Note: still potentially a single point of failure (the user)
- A number of different ways to approach this Started out very raw & manual with BitcoinD, improving over time Essentially using multi-sig as “2FA for Bitcoin” Hardware wallets are a great step forward in security + ease of use Private keys never leave the device during signing (but allow for initial backup via seed) Good for humans, not very usable in an automated environment
- Keys are still on different devices, but now also controlled by separate users 2-of-2 is the simplest model, but has no room for error What if Alice or Bob loses a key or becomes hostile? What if Bob is involved in a tragic kayaking accident?
- Copay (BitPay) has led the way developing this multi-user peer-to-peer model Has some limitations in terms of coordination Downsides: Cannot change signers once address created All signers are equally important Collusion risk
- Temporary wallet for escrow of funds vs. a promised real-world delivery of goods WIth bitcoin, for the first time ever, the escrow agent can never steal the funds! Only needs to be trusted to arbitrate fairly. Arbitrator has a single key and can co-sign for buyer or seller Users have indirect control over the arbitrator by giving their okay or disputing the transaction This was seen as a potential huge use case seen for multi-sig Assumed people would be doing significant volume of peer-to-peer purchases Well, they were, but mostly drugs.
- Currently a technology in search of a truly successful P2P market
- A brief diversion to explain smart co-signing services... Also known as oracles (as proposed originally by Mike Hearn) A co-signing service typically holds 1 key, but could hold more Job of the oracle is to co-sign transactions when instructed by the user, but only under certain conditions Allows layering more subtle security policies on a wallet Let’s first see how it improves things for a single-user wallet When a user wants to spend funds, they create a transaction and sign it, then pass it on to the service for co-signing & submission
- Oracle represented by “O” here 2-of-3 model. In this example, user is in control of 2, while oracle holds 1. User maintains 1 key online, and 1 key offline as a cold backup Similar to escrow model, oracle need not be trusted not to steal funds. User maintains full custody in a mathematical sense
- We’ve now introduced a second user into the picture The situation is quite a bit more complex than the joint wallet we saw previously Note that both users share a single key We’ve also introduced a custodian (C) who is responsible for holding a cold backup key The custodian has a contract with one or more of the users, or the company they work for Will release key for disaster recovery under certain circumstances The users, since they share a single key, cannot collude to take funds “outside the system” The signing oracle can require multiple users to approve a given transaction or policy change Benefit: Adding new users to a wallet is possible Benefit: Users can have different levels of access rights
- Before co-signing BitGo runs a set of automated policies and rules before sending a transaction to the network. Some of these rules help security while others bridge external state (contracts) onto bitcoin. Every bitcoin application is different, and you can customize your policies. Even the most basic of policies like a day limit would improve security by leaps and bounds over single-key. The co-signer model is possibly the most powerful multi-sig concept because logic can now happen externally to the blockchain, It is still secure because the co-signer cannot access the funds, only veto or approve transactions. Let’s take a look at some of the scenarios now possible with the cosigner.
- This model is great because you are able to change number of approvers More typical to match a company hierarchy Pros: stops hackers who steal private keys, no inside jobs
- Multiple machine are set up with an access tokens each Each token IP locked down to the machine If a machine is lost, tokens may be individually revoked Pros: shared balance, no need to keep capital funds on each machine Also can set up: Time of day restrictions, transaction limits humans able to approve
- This is currently the most common exchange multi-sig integration - its used with bitstamp The exchange manages a hot wallet with funds for deposits and withdrawals Outgoing withdrawals can be limited to a certain amount per day to minimize losses. The co-signer can also make an automated request callback to the exchange out of band to confirm each transaction on the accounts database Tihs helps when the accounts database is on a separate machine from the machine sending the coins Pros: quick integration path with bitcoind I’ll also show a demo of an exchange integration later
- Up-and-coming model Exchange maintains a wallet for each user with the co-signer Per-user-wallet policy granularity Transactions to settlement wallet whitelisted Co-signer can require user’s 2FA for withdrawals Remember that the exchange owns the keys, so they can debit the balance. Support margin trading, cases where user does not close trade Pros: Full control by exchange but with security policies Cons: Hard work compared to pooled wallets, customer does not own key
- Here’s an example of a specific model we’re actively developing at BitGo Exchange end-user does not have a key, but can auth to BitGo (oracle) The exchange can initiate transactions to the settlement wallet Withdrawals to external address are initiated by user thru exchange Exchange acts on behalf of user via OAuth to BitGo, passing thru user’s 2FA
- A future model User and exchange each have their own private key Outstanding sell orders lock up margin (off-blockchain) Withdrawals gated on Webhook call to exchange to ensure that the user has sufficient margin to be able to withdraw Additional policies added by the user and their 2FA Pro: Funds recoverable if exchange goes down Con: more burden on customer to maintain key