It occurred to me after I made my previous post that my example doesn't require three keypairs--the buyer could simply give a copy of the second keypair to the arbiter.
I'm not able to think of a another likely scenario where more than two keypairs are required.
Thank you anyway, -Dave
Topic: How To Make a Distributed BitCoin Escrow Service (Read 8199 times)
It's not implemented yet, but the network can support a transaction that requires two signatures. It's described here:
https://bitcointalksearch.org/topic/escrow-750
https://bitcointalksearch.org/topic/escrow-750
I can't believe I didn't find that in my search before posting. Thank you.
As you say in the linked post, the escrow is implemented in software (running on the nodes, I presume), so in theory the network can support a transaction that requires n signatures, where n can be any number. Is this correct?
If so, can the network also support transactions that require a majority of signatures (instead of all registered signatures)? For example, the buyer generates three keypairs--using one to initiate the transaction, saving one to release the funds, and distributing one to an arbiter trusted by both parties. Either the buyer or the arbiter could then release the funds.
Thank you again,
-Dave
It's not implemented yet, but the network can support a transaction that requires two signatures. It's described here:
https://bitcointalksearch.org/topic/escrow-750
It's absolutely safer than a straight payment without escrow, but not as good as a human arbitrated escrow, assuming you trust the human enough.
In this kind of escrow, a cheater can't win, but it's still possible for you to lose. It at least takes away the profit motive for cheating you. The seller is assured that the money is reserved for him, while the buyer retains the leverage that the seller hasn't been paid yet until completion.
https://bitcointalksearch.org/topic/escrow-750
It's absolutely safer than a straight payment without escrow, but not as good as a human arbitrated escrow, assuming you trust the human enough.
In this kind of escrow, a cheater can't win, but it's still possible for you to lose. It at least takes away the profit motive for cheating you. The seller is assured that the money is reserved for him, while the buyer retains the leverage that the seller hasn't been paid yet until completion.
Summary: Giving BitCoin a decentralized escrow would give it an advantage over all other exchange mediums, which might increase its adoption rate. Details follow.
For a decentralized currency, centralized escrows seem to be the norm for BitCoin today. An example:
Alice wants to buy $5 USD worth of BitCoins from Bob, but neither Alice nor Bob fully trust the other, so they go to a site they both trust--say Mt. Gox. There they deposit their respective monies and there they have Mt. Gox make the exchange for them.
No offense to Mt. Gox (a site I like), but can we do without its escrow service?
An almost distributed alternative:
(For simplicity I omit part of the PayPal details like who pays the transaction fee and how long you should wait to avoid chargeback fraud. I also omit any incentive for Bob to perform the final step.)
More advanced almost-distributed examples can be made if we substitute something more sophisticated for the Unix command split. For example: a Shamir's secret sharing scheme implementation like ssss[1]. A utility like ssss allows Alice and Bob to appoint an arbiter in case they get in a disagreement.
The problem with all of this, of course, is that we must trust Charlie to not abuse the full copy of the private key he creates.
The ideal solution would be for Alice and Bob to each generate half of the private key on their own. I don't fully understand the math used in modern keypairs, but I doubt this is possible with the current algorithm.
Is there an alternative way for Alice and Bob to each acquire half of a private key without giving the whole key to any party?
-Dave
[1] See: http://en.wikipedia.org/wiki/Shamir's_Secret_Sharing
For a decentralized currency, centralized escrows seem to be the norm for BitCoin today. An example:
Alice wants to buy $5 USD worth of BitCoins from Bob, but neither Alice nor Bob fully trust the other, so they go to a site they both trust--say Mt. Gox. There they deposit their respective monies and there they have Mt. Gox make the exchange for them.
No offense to Mt. Gox (a site I like), but can we do without its escrow service?
An almost distributed alternative:
- Charlie, a trusted third-party, generates a BitCoin private key.
- Charlie then uses the Unix command split to split the private key in half--giving one half to Alice and one half to Bob.
- Bob deposits $5 USD worth of BitCoins into the split BitCoin account;
- Alice verifies the transaction using the public block;
- Alice sends $5 USD to Bob by PayPal;
- Bob verifies the PayPal transaction;
- Bob sends Alice his half of the split private key so Alice can access the BitCoins he deposited earlier.
(For simplicity I omit part of the PayPal details like who pays the transaction fee and how long you should wait to avoid chargeback fraud. I also omit any incentive for Bob to perform the final step.)
More advanced almost-distributed examples can be made if we substitute something more sophisticated for the Unix command split. For example: a Shamir's secret sharing scheme implementation like ssss[1]. A utility like ssss allows Alice and Bob to appoint an arbiter in case they get in a disagreement.
The problem with all of this, of course, is that we must trust Charlie to not abuse the full copy of the private key he creates.
The ideal solution would be for Alice and Bob to each generate half of the private key on their own. I don't fully understand the math used in modern keypairs, but I doubt this is possible with the current algorithm.
Is there an alternative way for Alice and Bob to each acquire half of a private key without giving the whole key to any party?
-Dave
[1] See: http://en.wikipedia.org/wiki/Shamir's_Secret_Sharing
Jump to: