Following the apparent failure of the Mt Gox exchange with their clients' loss of bitcoins and/or cash deposits, I got to thinking about how to implement a P2P algorithm that would allow individuals to trade with each other in the real world using bitcoins on the basis of limited trust rather than relying on a possibly untrustworthy third party to act as the agent between them.
My personal impetus was to buy bitcoins with a fiat currency without the need for a third party. LocalBitcoin is an obvious method but I live too far away from any local bitcoin seller to make that viable. Thus whatever the method, it must work between parties who are remote from each other but, since I don't yet have any bitcoins (or cryptocurrency of any kind and I don't want to get bitcoins by attempting to mine them), the method must not be reliant on *both* parties to already be holding bitcoins.
After a couple of weeks learning about a little about bitcoin and going through the bitcoin and other related forums and wikis reading about bitcoin Contracts (
https://en.bitcoin.it/wiki/Contracts), Atomic Cross Chain Trading (
https://en.bitcoin.it/wiki/Atomic_cross-chain_trading), Alternative Chains (
https://en.bitcoin.it/wiki/Alternative_chain), CoinJoin, CoinSwap, etc, I came to the conclusion that apart from one attempt by Zangelbert Bingledack (
https://bitcointalksearch.org/topic/proposal-a-dual-2-key-wallet-system-for-trustless-trade-118418), most of these approaches limit their primary application to trustless inter-cryptocurrency exchange or gaining anonymity in intra-cryptocurrency transfers.
The algorithm I propose below is based on bitcoin Contracts.Providing a Deposit (
https://en.bitcoin.it/wiki/Contracts#Example_1:_Providing_a_deposit) and Zangelbert Bingledack's P2P exchange algorithm and requires the holder of the bitcoins to temporarily put up some bitcoin collateral along with their bitcoin payment. It is not intended as a suggestion to change the bitcoin protocol but as a bitcoin newbie I don't know if the algorithm can be completely implemented using the existing protocol nor if I've made any mistakes in my use of bitcoin transactions; I'm really interested in getting feedback.
Please note that the mechanism makes no attempt to anonymize the bitcoin part of the exchange; this is deliberate for two reasons:
* I wanted to describe the basic algorithm rather than getting confused by additional anonymization steps (especially since I'm a bitcoin newbie and I don't completely understand the anonymization algorithms that I've read).
* I've assumed that neither party can (nor wants/needs to) remain anonymous in *both* the bitcoin transfer and the real world delivery.
Use Case
========
Alice has bitcoins that she wants to use to buy a real world good from a remote seller, Bob. Bob has *no* bitcoins. There will be a finite time between the Bob dispatching the real world good and Alice receiving it. (The 'real world good' could be anything, for example, a book, a car, a pizza, a stack of US dollar bills, an electronic (wire) transfer of US dollars, etc. Depending on the delivery method, a 'finite time' could be as little as a few seconds or minutes to as much as days or even weeks.)
Problem
=======
Alice and Bob don't know each other and thus have only the very lowest level of trust in each other to complete the exchange successfully. As well as facilitating the transfer of bitcoins from Alice to Bob, the algorithm should incentivise both Alice and Bob to complete the purchase successfully.
Algorithm
=========
Pre-Condition:
Alice has sufficient spendable bitcoins in her bitcoin address (AliceAddr).
Phase 0:
Step 0.0: Alice and Bob communicate to agree the bitcoin purchase price (Payment) for the real world good that Bob is offering. They also agree two other terms: the bitcoin collateral amount (Collateral) that Alice will have to temporarily put up in addition to her payment amount and the minimum time (ExpiryTime) that Alice's Payment and Collateral have to be locked up before they are returned to her if the exchange doesn't complete successfully. (The use of these will become apparent in the desciption of the algorithm and they are discussed further at the end of the desciption of the algorithm.)
Step 0.1: Bob ensures that he has a bitcoin address to receive the payment (BobAddr).
Step 0.2: Bob creates a public-private key pair (BobKey).
Step 0.3: Bob sends a copy of his public key (BobKey.Pub) to Alice.
Step 0.4: Alice creates a public-private key pair (AliceKey).
Step 0.5: Alice sends a copy of her public key (AliceKey.Pub) to Bob.
Step 0.6: Alice sends a copy of her AliceAddr to Bob.
Step 0.7: Alice creates a 2-of-2 signature intermediate bitcoin address (AliceBobAddr) using AliceKey.Pub and BobKey.Pub.
Step 0.8: Alice drafts an intermediate transaction (IntermediateTx) to transfer (Payment+Collateral) amount of bitcoins from AliceAddr to AliceBobAddr and adds her AliceAddr(.Signature).
Step 0.9: Alice sends a copy of IntermediateTx.Hash to Bob.
Step 0.10: Bob drafts an expiry transaction (ExpiryTx) to transfer (Payment+Collateral) amount of bitcoins from IntermediateTx(.Hash) (i.e. from AliceBobAddr) to AliceAddr with a lock time of ExpiryTime and adds his BobKey signature.
Step 0.11: Bob drafts a payment transaction (PaymentTx) to transfer (Payment) amount of bitcoins from IntermediateTx(.Hash) (i.e. from AliceBobAddr) to BobAddr and to transfer (Collateral) amount of bitcoins from IntermediateTx(.Hash) to AliceAddr with a lock time of zero and adds his BobKey signature.
Step 0.12: Bob sends copies of ExpiryTx and PaymentTx to Alice.
Step 0.13: Alice checks that ExpiryTx is for the transfer of (Payment+Collateral) amount of bitcoins from IntermediateTx(.Hash) to AliceAddr with a lock time of ExpiryTime and that it contains Bob's BobKey signature.
Step 0.14: Alice adds her AliceKey signature to ExpiryTx and saves her copy of it in a safe place.
Step 0.15: Alice checks that PaymentTx is for the transfer of (Collateral) amount of bitcoins from IntermediateTx(.Hash) to AliceAddr with a lock time of zero and that it contains Bob's BobKey signature.
Step 0.16: Alice adds her AliceKey signature to PaymentTx and saves her copy of it in a safe place.
Phase 1:
Step 1.1: Alice transmits IntermediateTx to the bitcoin network.
...Eventually, IntermediateTx is processed and confirmed in the blockchain.
Step 1.2: Alice tells Bob that the IntermediateTx has been confirmed in the blockchain.
Step 1.3: Bob checks the blockchain to ensure that IntermediateTx(.Hash) has been confirmed and ensures that its output address is one that is jointly locked by BobKey.Pub and AliceKey.Pub, i.e. that it is AliceBobAddr.
Step 1.4: Bob checks the blockchain to ensure that AliceBobAddr contains (Payment+Collateral) amount of bitcoins.
Phase 2:
Step 2.1: Bob dispatches the real world good to Alice.
Step 2.2: Bob tells Alice that the real world good has been dispatched.
...Eventually, Alice receives the real world good.
Phase 3:
Step 3.1: Alice transmits PaymentTx to the bitcoin network.
...Eventually, PaymentTx is processed and confirmed in the blockchain: (Payment) bitcoins are transferred from AliceBobAddr to BobAddr and (Collateral) bitcoins are transferred from AliceBobAddr to AliceAddr.
Discussion
==========
We can look at what Alive and Bob stand to gain or lose during each phase of the algorithm if the exchange fails in that phase...
Phase 0:
* Alice gains nothing.
* Alice loses nothing.
* Bob gains nothing.
* Bob loses nothing.
Phase 1:
* Alice gains nothing.
* Alice loses nothing but her (Payment+Collateral) bitcoins are stuck in AliceBobAddr. Alice waits until ExpiryTime is reached and then transmits ExpiryTx to the bitcoin network which, when added to the blockchain, will transfer her bitcoins from AliceBobAddr back to AliceAddr. (N.B. This is different to the Contracts.Providing a Deposit algorithm in that ExpiryTx is not transmitted immediately after IntermediateTx since I believe that transaction replacement isn't (never was?) supported in the bitcoin protocol.)
* Bob gains nothing.
* Bob loses nothing.
Phase 2:
* Alice gains the real world good.
* Alice loses nothing but her (Payment+Collateral) bitcoins are stuck in AliceBobAddr. Alice waits until ExpiryTime is reached and then transmits ExpiryTx to the bitcoin network which, when added to the blockchain, will transfer her bitcoins from AliceBobAddr back to AliceAddr.
* Bob gains nothing.
* Bob loses the real world good.
Phase 3:
* Alice gains the real world good.
* Alice loses nothing.
* Bob gains (Payment) bitcoins.
* Bob loses nothing.
This is not a pejorative comment and my intention in making it is definitely *not* to start a flame war but in most of my reading of the bitcoin forums it appears that proponents of bitcoin tend to view themselves as more likely to be the victims rather than the perpetrators of potential fraud. Generally speaking, bitcoin, like any fiat currency, is only really worth as much as the real world goods and services that it can be exchanged for, either now or in the future, and thus my view is that the true value in the exchange that I've described resides in the real world goods and the loss of value is borne by the unremitted owner of the real world goods, i.e. Bob. (This is notwithstanding the real world expense, and thus value, embodied in the bitcoin by its production, i.e. mining.)
So my contention is that it is worth the opening up the risk of bitcoin holders having their bitcoin funds tied up due to maliciously bogus (though ultimately *not* fraudulent) real world exchange offers versus the real world parties being defrauded of their real world goods by fraudulent bitcoin holders. This is notwithstanding the possibility of accidental, non-malicious loss to real world parties, e.g. Alice dying before completing the exchange or else losing her AliceKey(.Private) key and/or losing her copy of PaymentTx and being unable to complete the exchange...although if she's a moral person she should contact Bob and either regenerate PaymentTx with him or else make the bitcoin payment directly to him even though she may have effectively 'lost' her bitcoins that are stuck in AliceBobAddr.
The interesting and indeterminate questions are what should be the amount of collateral posted by the bitcoin holder and what should be the duration of the expiry time before the payment and collateral are released back to the bitcoin holder in the invent of either the bitcoin holder *or* the real world good holder failing to complete their sides of the exchange?
At the very least, the ExpiryTime should be no less than the time that it is expected to take to transfer the real world good from Bob to Alice.
But ultimately, it is up to the protagonists of the exchange (Alice and Bob) to mutually agree not only the payment amount but also the collateral amount and the expiry time. Their proposals and counterproposals in Step 0.0 will naturally have to be cognisant of possible exchanges that either side could make with other bitcoin and/or real world goods holders who might offer better terms.
However, I contend that the collateral amount should be large enough and the expiry time long enough such that the combination acts as a deterent on the bitcoin holder to renege on completing the exchange.
If the real world good can be subdivided in some way then an alternative approach is to apply the algorithm to each subdivisional exchange; the reduction in the size of potential loss (and thus the reduction in the level of trust required) in each subdivisional exchange makes the sum of the risk of the subdivisional exchanges less than the risk of a single, all-encompassing exchange. It is also the case that each successful subdivisional exchange reduces the risk of each subsequent subdivisional exchange since it increases the level of trust that the parties have in each other. Obviously, if the transfer of the real world good can't be subdivided in to multiple, indepedent exchanges, then risk and lack of trust is carried forward through the subdivisional exchanges by one party or the other.
Although large collateral amounts and long expiry times open up the possibility of maliciously bogus, 'anti-bitcoin' real world ('honeytrap') offers, the deterent must not be too soft if there is a suspicion that the bitcoin holder is never intending to transfer any of her bitcoins in future (and doesn't mind them being locked up for periods of time) and is simply using them to defraud real world parties of their goods in the meantime.
Given that the exchange algorithm proposed above depends on the protagonists *assuming* a limited degree of trust to begin with, ideally they could each do with some sort of empirical evidence that the other side is worthy of at least the minimum level of trust for the exchange process to begin. My intention is produce a seperate post, referencing back to this one, proposing my ideas on how it might be possible for parties in exchanges carried out under the algorithm described above to gain widespread trust through a public record of successfully completed exchanges.
Questions/Requests from the Author
==================================
* Can somebody explain the precise details of how the IntermediateTx and PaymentTx transactions are created with Alice's and Bob's 'signatures' (for transfer of funds out of AliceBobAddr) without Alice and/or Bob being able to steal each other's signatures and simply take the contents of AliceBobAddr for themselves.
* As the only holder of bitcoins, Alice has to pick up the tab for any bitcoin transaction fees that are due (although the Payment value may be mutually agreed by Alice and Bob to reflect this fact). Do transaction fees need to be taken into account in the above algorithm and if so, how?
* The algorithm requires a number of steps which novice users might find too fiddly to carry out themselves; can the algorithm be (semi)automated in wallet software?