A proposal for do-it-yourself escrow with bitcoins

[astrolabe]

I'm not a cryptographer so take this with a pinch of salt.

Roughly speaking I'm proposing a protocol that is analogous to tearing a banknote in half and handing half to the seller.

Suppose that Alice wants to buy goods from Bob but that neither entirely trusts the other.  The parties each select a secret random number less than the degree of the bitcoin underlying field.  The parties go through the elliptic curve Diffie-Helman key agreement protocol using the bitcoin elliptic curve, and their secret random numbers.  They also agree on a random value for k.

The exchanged key together with k forms a bitcoin public key known to both parties from which a bitcoin address can be generated, but neither party on his own can find the corresponding private key.  Alice deposits bitcoins into the address.  When Bob sees that the payment has been made into the address he hands over the goods.  Once Alice has the goods she passes Bob her secret which enables Bob to generate the private key (it's just the product of the two secrets modulo the prime), and transfer the bitcoins to his own wallet.

After Alice deposits the bitcoins, Bob could try to blackmail her.  After Bob has handed over the goods, Alice could try to blackmail him.  However, neither party can gain anything without the other's cooperation.  If a small positive reward is available for successful completion of the protocol, such as is available through a reputation system, or even because the trade is mutually beneficial, and if neither party appears desperate, then blackmail is unlikely.  If a permanent blackmail happens, then the bitcoins are lost forever.

[1713953909]

1713953909

[etotheipi]

This has been proposed a couple times.  Yes, it's a poor-man's 2-of-2 transaction.  It suffers from two big problems though:

(1) Requiring uses to reveal private keys, and/or managing secrets separately from the existing wallet infrastructure
(2) There is no mechanism for partial payouts.  One user or the other user gets it all.  Partial refunds are not "possible" in a zero-trust environment, and there's no room for a third-party to save you if one party loses the key (not that third-parties are required, but they should be optional).

Of course, multi-sig transactions solve all this.  But it's not implemented anywhere yet (in a usable way).  However, the effort to actually implement this would be better spent just implementing the multi-sig approach, which is enabled on the network.

But yeah, it does "work".  Yay for EC math.

[astrolabe]

Thanks for the information.  Maybe there is something to be said in favour of the approach I suggested though: it would only lead to an ordinary transaction being recorded on the blockchain which might be useful for privicy reasons if multi-sig transactions are rare and become associated with sensitive purchases.