Imagine a scenario. There are 3 parties: Party A, Party B and a mediator party C. A and B transfer each 1 BTC to a newly created wallet W owned by C. The function of C is to distribute the entire 2 BTC to either A or B depending on some condition (think a bet). Now imagine C gets compromised and it's private key is stolen by a hacker. The hacker can now send 2 BTC to any address he wants. Is it possible to limit wallet W to sending funds to only A or B? So that even if it's compromised, the hacker can only send funds to A or B and not any arbitrary address.
Asked
Active
Viewed 106 times
1 Answers
1
Absolutely.
The mediator, C, creates an address.
After the bet payment(s) have been made, C creates two transactions. One pays to A, and the other pays to B. He keeps both of these transactions secret. Then, he destroys the private key for the address.
Depending on who wins, the mediator publishes one of the transactions.
An attacker can't send the Bitcoins to himself, but he can choose who wins the bet, or destroy both transactions.
Downsides
If additional payments are made to C's address after he destroys its private key, those Bitcoins are lost. This could be mitigated by having the address be a 1-of-2 multisignature account, where one of the keys is an offline key held by the operator of the service.
The service is vulnerable between the time that it publishes the address and the time it creates and signs the transactions. You can't create the transactions in step two before you see the incoming transactions, either, because they will depend on the txid you're trying to spend.
Nick ODell
- 29,396
- 11
- 72
- 130
-
Wow, this is a great explanation. Thanks. Is it possible to create a 1-of-2 multisig address without taking the second "master" key out of the offline storage? – andr111 Nov 14 '14 at 18:01
-
Yes. This guide explains how to create a multisignature address, assuming you know the public key of the offline key. Spending from a multisignature address is still a little annoying. – Nick ODell Nov 14 '14 at 18:28
-
Another issue is that C has no way to prove that the private key is really destroyed. He could have kept a copy, intentionally or unintentionally, that could later be stolen or abused. – Nate Eldredge Nov 14 '14 at 19:51