Alright, here goes...
I have two major ideas planned for multi-signature transactions to go into Armory, as soon as I finish up with the some other priorities. The first one is fairly straightforward, so I'm just posting for reference. The second is a bit more controversial and could use some ironing out.(1) Two-factor authentication without a third-party
There's a more-general version of this for two equally-capable devices, but I'll be implementing this version due to its simplicity and it accommodates one of the most desired use-cases of multi-sigSetup Wallets:
- Create two new wallets in Armory, A and B
- Print off paper backup of each wallet.
- In wallet B, choose "Remove/Delete Wallet" and delete just the private keys to make it a watching-only wallet, B'
- Scan paper backup B with smartphone
- Stash both paper backups in safe or safety-deposit box
Now your online computer has wallet A (full) and B' (watching-only) and your phone has B (full). I will probably make a special wallet format for 2-of-2 wallets that makes this process even simpler (and symmetric: A+B' on one device and A'+B on the other device).Generate Addresses:
- On computer Armory: generate new address for this special wallet (A+B')
- Armory finds next unused address index, n, in wallet A. Computes PubKeyA(n) and PubKeyB(n).
- Create 2-of-2 multisig address
- On computer, construct transaction as normal. "Send" button is greyed out.
- Click "Sign for wallet A"
- Signature added, transaction is converted to BIP 0010 packet and displayed as a QR-code (or sequence of them).
- Phone scans QR code(s), displays transaction details, verifies signature A, requests confirmation
- Phone adds second signature, B, and connects to the Bitcoin network and broadcasts
I will probably find QR codes to be difficult to use here. I'm thinking of other ways I might do it: perhaps send data to the phone via special email that can automatically be detected by the phone and parsed. Unfortunately it would never fit into a text message...
But a sequence of QR codes may not be bad... you can tile a lot of QR codes on the screen, and phones are very fast at scanning them.(2) Buyer-Seller Escrow, with or without third-party
Alice posts an item on craigslist, knowing that unknown, untrusted Bob will try to buy it. In this case, Alice is the seller and will set the "Risk Deposit" (could also be "Escrow Deposit").
- Alice makes craigslist posting identifying the item for sale, the price (25 BTC), and the desired "Risk Deposit" (20%)
- Bob finds the posting and emails Alice saying "I'll buy it for 20 BTC, 20% deposit is fine, here's a public key, and let's use a third-party Charles."
- Alice agrees so she obtains a public key from Charles, and constructs a very wacky transaction:
- (1) Alice 4 BTC (20% deposit) -- signed using SIGHASH_ANYONECANPAY
- (1) 28 BTC to TwoOfThree(PubKeyA, PubKeyB, PubKeyC)
- (2) Alice's change output, if necessary
- Sends incomplete tx to Bob
- Bob verifies that PubKeyC belongs to Charles.
- Bob creates a perfect-sized input of 24+fee BTC, adds it to the tx, signs and broadcasts (Alice's sig is still valid because of ANYONECANPAY)
Now there is 28 BTC locked up in the network requiring two-of-three signatures from Alice, Bob or Charles. This could be a 2-of-2 tx without Charles, but if one party disappears (before tx completion) the money will be locked forever.
Three possible outcomes:
- Everything goes smoothly, Alice creates "completion transaction": Inputs: 2-of-3 for 28 BTC and an optional fee input, Outputs: Alice 24, Bob 4. Signs and sends to Bob who signs and broadcasts
- Something went wrong, Bob needs a refund. He constructs tx: Inputs: 2-of-3 for 28 BTC and optional fee, Outputs: Alice 4, Bob 24.
- DISPUTE: Charles contacts both parties, figures out who gets the money -- assume it's Alice -- then Charles creates a Tx; Inputs: 2-of-3 for 28 BTC + fee; Outputs: Alice 20, Charles 8; signs and sends to Alice who signs and broadcasts.
In this case, the "Risk Deposit" serves two purposes: (1) guarantees that Bob has incentive to complete the transaction after he receives his merchandise, and adds incentive to the seller not to randomly back out and leave the multi-sig money stranded. (2) It's an already-included, equally-funded-by-both-parties fee, in case the tx needs arbitration.
Someone had brought up the possibility that only the "loser" of the arbitration should pay, and the "winner" would get their risk deposit back. I'm not entirely sure which is better...
While many of these steps look complicated, I think my GUI-fu is good enough to make a lot of this transparent. Third-parties can register to be included in a global list on most clients (to retrieve and verify addresses). Users will not see all the script magic going on in the background, they just have to enter their amount, and their risk preference. But of course, I have to iron out the under-the-hood stuff, first, so that I can implement it soundly and then make it transparent to the user...