And, if I've understood it correctly, I think their exchange algorithm is inherently susceptible to (accidental and/or malicious) failure due to bitcoin transaction malleability.

Their github wiki shows a worked example of the bitcoin transactions http://github.com/Coinffeine/coinffeine/wiki/Exchange-algorithm#transaction-definitions.

It shows that their algorithm is based on creating and signing transactions to spend outputs from other transactions that haven't even been broadcast yet.

So if, for example, Sam's Tx0.1 is subject to a malleability modification it's hash will not be the same as Tx0.3 assumes thus Tx0.3 is useless as a means for Sam to get his (potentially large chunk of) bitcoins back.

If Bob refuses or is no longer around to help Sam create and sign a new version of Tx0.3 referencing Tx0.1's actual, confirmed hash then Sam's bitcoins are permanently locked in Tx0.1.  

@flix I re-read their wiki but couldn't see anywhere that the 'one side has no bitcoin deposit' bootstrapping issue was dealt with...can you give me a more precise pointer?

I think we're mostly in agreement again. :-)

But I think that we continue to circle around the two part issue of value and ownership; we've talked about possible ways to determine the former but we haven't really talked about how the latter might be demonstrated for legal purposes.

Are you aware of any ruling in any jurisdiction in which someone has posited such an argument but where the jurisdiction didn't already consider bitcoins to be money and didn't (re)classify bitcoins as money as part of any ruling on the case?

The reason I ask is because you refer to demonstrating "control" of the bitcoins but I don't think that control is necessarily synonymous with ownership and (taking your use of that word to be literal) I've been doing a brief review of the legal cases that you've mentioned to see for myself if any precedents have been set; please note that I'm not a lawyer so please excuse my admittedly amateurish attempts to interpret what I've found.

BTCST involved the agreed transfer of control of owners' bitcoins to BTCST on the basis that an investment was being made between the owners and BTCST and BTCST issued paperwork to investors providing the details of the investment and their stake in it. As part of the SECs case against BTCST, a US Court has made a ruling that the transfers of bitcoins to BTCST and the purpose of those transfers constituted an investment which had properties that made it legally recognisable as such (and the Court also ruled that bitcoins were money as part of its legal argument for it being an investment). This opened up the feasibility of the SEC taking legal action against BTCST and it's officials for running an illegal investment vehicle since the SEC asserts that BTCST operated as a Ponzi scheme which is a criminal offence under US law. In its case against BTCST, I don't think that the SEC are particularly interested in who owns the bitcoins in question, they are more interested in those people who were investors in BTCST, as evidenced by their respective paperwork. So although the BTCTS case has said something about the financial value of bitcoins, I can't see that it has said very much about determining the ownership of them.

The Silk Road situation seems, among many things but of most relevance to theft of bitcoins, to revolve around bitcoins being held in escrow accounts which had been placed there by bitcoin owners. Unsurprisingly, because of Silk Road's anarcho-libertarian nature, these were unofficial escrow accounts rather than legally certified escrow accounts. Of course the point of any proper escrow account is that a 3rd party controls the contents of the account strictly on behalf of the owner(s) of the contents of the account in accordance with a legally binding escrow agreement and this should also apply to a properly supervised bitcoin escrow account. So the concept of escrow appears to set a general precedent that control does not necessarily equate to ownership.

But this doesn't quite fit with the traditional view of bitcoins from the point of view of the bitcoin protocol in which an (at least nominally anonymous) bitcoin account doesn't have an identified owner but simply has somebody who knows the private key for that account and thus controls it; implicit in the bitcoin protocol is the assumption that whoever controls a bitcoin account is the owner of the bitcoins within the account.

As I understand it, the legal case against Ulbricht actually relates to charges of drug trafficking and money laundering rather than to the theft of bitcoins but it has thrown up an interesting debate with regard to the FBI's apparent desire to gain access to Silk Road's bitcoin accounts and the possible use of a 5th amendment defence by Ulbricht to avoid disclosing any private keys that he may have for those accounts (http://www.coindesk.com/silk-road-case-bitcoin-legal-precedent). I can't work out if:
# the FBI is already actively seeking to show that if Ulbricht is able to exercise control of the account then he is at least complicit in the use of the account for the activities he's charged with, regardless of who owns the bitcoins in the account (and possibly regardless of who else might be able to control the accounts).
# or whether Ulbricht's defence team are simply concerned that if he happens (or is forced to) show that he has the means to control the accounts, even if showing he can do so is for other purposes, that the FBI may *subsequently* try to use it as evidence that he is complicit.
# or whether the FBI is wants or needs to show that Ulbricht actually owns the bitcoins in the accounts and given the implicit entanglement of ownership and control within the bitcoin protocol, the only way they can do that is to show that he can control the accounts...unless he has documented proof that although he might be able to control the accounts, that somebody else actually owns the bitcoins in the accounts.

These are big fraud/theft cases featuring bitcoin but you run into the control versus ownership issue at a simpler level. For example, if you hold bitcoins in your account and I steal your private key and transfer the bitcoins to my account. The bitcoins that I now have are under my control, not yours; and even though it is easy to show that the coins came from your account, you would have to show that I had stolen your private key and used to transfer bitcoins to my account without your consent, I.e. that I had usurped the control of your account, and I think that's a much more difficult task than simply showing who is able to control a particular bitcoin account.

I think we are in agreement on almost every point, Clobered09. :-)

Perhaps the only point I might disagree with you on is that bitcoins are software. I think most jurisdictions have fairly strict definitions of what constitutes 'software'. Although the implementations of the bitcoin protocol are obviously software, the bitcoins that they 'count' are (I think, self-evidently) data within and between the software instances rather than functional software in and of themselves and especially since ownership of that 'data' is (re)assigned to individuals who are not required to possess the bitcoin protocol software themselves (although they obviously have to interact with the bitcoin protocol software directly or indirectly in order to receive or send their bitcoins).

I suggested in one of my earlier replies that I thought that at the very least, any jurisdiction might be able to reasonably accept bitcoins as being data owned by an individual whether or not that jurisdiction considers bitcoins to be money/legal tender/etc and that an individual might be able to make a case for his (bitcoin) data having been stolen (though I'm not sure that all jurisdictions currently recognise data as something that can be stolen but I feel that most of them would). I suppose the theft, if proven, would ideally result in the return or direct replacement of the bitcoin (data) to its rightful owner but if that is not technically possible, then the owner might seek restitution in financial terms (e.g. fiat money) instead...and that's where the interesting debate would occur with regard to what is the financial (fiat money denominated) value of the bitcoins.

What do you think?

Sorry, I hadn't seen the case notes...I tend not to read the court rulings of jurisdictions other than the one I live in since they don't apply to me...bitcoins still don't count as money where I am. However, I should have done wider ranging research before spouting off on the subject in as general terms as I did - apologies.

At another tangent, it's interesting that you frame the bitcoin value question in terms of *getting* bitcoins; I contend that the question should be framed the other way round...what real, tangible goods and services can you get with bitcoins. The answer, of course, is that with at least a few retailers willing to accept bitcoins for the things that they sell, bitcoins do have demonstrable value in the 'real' world.

And to be slightly controversial, picking up on your proposition, it is arguably the case that you *can* get bitcoins for 'free' by mining them, I.e. you can get bitcoins without having to exchange anything (fiat currency, real world goods, etc) with any other individual or organisation. That is not to say that mining bitcoins is not without cost, I.e. computer hardware, electricity, etc. but it doesn't necessarily mean that their value to anyone else is even equal to the cost of producing them.

Sorry, I should have been clearer...I had made a somewhat assumptive corollary from "XXXXX recognises bitcoins as legal tender" to "XXXXX's legal system recognises bitcoins as having implicit *financial* value" and progressed my argument from the latter proposition, not from the former.

So even from Clobered09's example of being defrauded of his motorcycle, motorcycles are not legal tender either but the legal system recognises that a motorcycle has financial value and that financial value belongs to the legally recognised owner of the motorcycle. The same argument applies to gold, shares and land but there appears to be no equivalent precedent for bitcoins.

It doesn't matter whether what is stolen is money or not. What matters is that you have been defrauded of something that has legally recognised, financial value, in your example, your motorcycle.

The point I was trying to make is that fiat money is legally recognised as having financial value but bitcoins (probably?) are not recognised as such so if somebody steals your bitcoins it is not at all clear to a court of law that that you have suffered any sort of financial loss that they could try to sort out on your behalf.

I assume that if country XXXXX recognised bitcoins as legal tender then they would be saying that a bitcoin was imbued with implicit (though probably not intrinsic) financial value.

If someone was to con you out of some of your bitcoins (e.g. by failing to provide agreed goods or services which you had paid for with bitcoins) within XXXXX's jurisdiction, then XXXXX's legal system would have to take the view that you had suffered an illegal financial loss, i.e. that you had been criminally defrauded. Beyond any criminal case that XXXXX's justice system might make against the fraudster, you could mount a civil case against the fraudster through XXXXX's legal system in an attempt to recoup your bitcoins.

So XXXXX effectively stands as a trusted(?) third party arbiter for resolution of disputes of bitcoin denominated trades within its jurisdiction; although it's worth bearing in mind that legal systems generally (and therefore probably XXXX's as well) will only take action against or in support of identifiable entities (I.e. individual people or registered companies/organisations) so if your bitcoin-based trade is (truly) anonymous then you probably can't expect to get any help from XXXXX's legal system.

I'm guessing that if a trade goes wrong at the moment (in any jurisdiction) and somebody effectively 'steals' your bitcoins, no jurisdiction recognises bitcoins as being money, and thus no legal system will consider you to have made a financial loss and they won't get involved.

I don't know what the legal status of bitcoins is in various places...in some places they might be considered to be *data* which belongs to you and thus somebody who steals your data may be considered to have committed a criminal act. In terms of trying to get financial restitution for your loss, you would have to convince the authorities that your (bitcoin) data had demonstrable financial value and thus that you had suffered financial loss from the loss of the data. Part of that might be in showing that you could have used your (bitcoin) data (I.e. Spent your bitcoins) in return for goods, services and/or an amount of legally recognised fiat currency and thus that your stolen bitcoins were worth that amount of financial value which ought to be returned to you. Good luck with that one!

Ah, OK, yes, I get your point re: a malicious (or even just mischievous), unknown third party having the chance to usurp a transaction that's has just been legitimately submitted.

My take away from this is that currently, *any*(?) algorithm that relies on tying together consecutive bitcoin transactions without being able to wait for each transaction to be confirmed is susceptible to failure due to malleability...unless an alternative version of the algorithm can be conceived that is able to detect that *a* 'suitable' transaction has taken place, identify the transaction in question and then create the next transaction in the sequence.

So in the case of my proposed algorithm, if IntermediateTx is usurped by malleability then if Bob is unwilling or unable to create new ExpiryTx and PaymentTx transactions for Alice then her Collateral+Payment bitcoins will be stuck in AliceBobAddr and therefore lost to her forever.

That sounds like quite a serious flaw in my proposed algorithm so I don't think that it's a practical proposition until bitcoin transactions are made non-malleable. :-(

Thanks for the info; I really appreciate it.

The deposit approach *is* elegant but there is a bootstrapping issue with it. If the fiat currency holder has only fiat currency and *no* bitcoins then he can't put up the bitcoin deposit to start the Coinffeine-based exchange which he wants to carry out in order to get bitcoins. :-(

Yes, Alice would get back the full amount (Collateral+Payment) upon expiry...and Bob obviously loses the real goods (to Alice). Those are the respective Phase 2 gains and losses which I highlight in my original post.

Bear in mind that the algorithm that I'm proposing cannot eliminate all the risks and unfortunately for Bob, he bears the ultimate risk. But the point of a (potentially very large) collateral and/or a (potentially very long) expiry time is to incentivise Alice to hold up her side of the exchange to get her collateral back in a timely fashion.

If Bob is undertaking several bitcoin-based exchanges with different people then it's possible that he might incorporate a risk premium into the Payment amount for each exchange (as compared to a smaller amount of fiat currency that he would otherwise accept in an equivalent series of real world exchanges for the same goods) reckoning on still being able to make a profit on the whole set of exchanges even if a proportion of the exchanges go bad.

Bitalo_Maciej: I'm glad that you picked up on transaction malleability since it was one thing that I wasn't entirely sure that I'd adequately covered but I didn't think I'd got it so badly wrong that I bothered to explicitly raise it as one of my outstanding questions/requests; perhaps I should have.

I used bitcoin Contracts.Providing a Deposit (https://en.bitcoin.it/wiki/Contracts#Example_1:_Providing_a_deposit) algorithm as the basis of my algorithm where my IntermediateTx is equivalent to the 'Deposit' Tx1 and my ExpiryTx is equivalent to the 'Deposit' Tx2.

In 'Deposit', Tx2 spends Tx1 with reference to Tx1's transaction id and Tx2 will fail if Tx1 is changed. But Tx1 is controlled by the user and the user is the one who's keen to have Tx2 succeed in order for them to get their money back from Tx1. Therefore it's in the interest of the user not to invalidate Tx2 by changing Tx1. In 'Deposit', the website isn't so interested in the Tx1 transaction id itself but only in knowing that the deposit has been lodged in the dual signature (user+website) bitcoin account.

The interesting thing about 'Deposit' is that Tx1 and Tx2 are submitted together (by the user!) early in the algorithm and then, because Tx2 has two correct signatures, sequence number set to less than UINT_MAX and nLockTime greater than zero, Tx2 remains valid but outstanding (until nLockTime is reached) and malleable. In fact, the rest of the algorithm *relies* on the fact that Tx2 is malleable since it means that a new version of Tx2 can be mutually created by the user and the website to either return the deposit back to the user early or to extend the term of the deposit.

But what I'd picked up in my reading (perhaps wrongly but please feel free to correct me) was that the bitcoin protocol had been changed (I assume, after the Contracts.Providing a Deposit algorithm had been expounded) to effectively deprecate the use of nLockTime greater than zero in a transaction since such a transaction will be immediately marked as invalid and deleted from the transaction queue.

The (assumed) latter deprecation is why, in my proposed algorithm, although Alice transmits IntermediateTx (which is under her control) she doesn't transmit ExpiryTx (which, with sequence number set UINT_MAX, isn't malleable) until after nLockTime has been reached and which, therefore, (assuming that it has two valid signatures - see below) is processed immediately thereafter.

Since ExpiryTx can't be left outstanding in the transaction queue (even if Alice submits it, possibly multiple times), it doesn't need to be malleable because a suitable, dual-signature PaymentTx (or a mutually agreed, different ExprityTx) can be submitted at any time to spend IntermediateTx...although only so long as the IntermediateTx transaction id is the same as referenced from PaymentTx (or ExpiryTx).

Bob makes sure that the IntermediateTx transaction id is referred to in both the ExpiryTx and PaymentTx (Step 0.10 and Step 0.11).

Alice wants to make sure that the IntermediateTx transaction id remains the same as that referred to in ExpiryTx (otherwise she'll never get her bitcoins back) and therefore, as far as Bob is concerned, Alice has an implicit incentive to ensure that the IntermediateTx transaction id remains the same as that referred to in PaymentTx.

Bob has an incentive to check that IntermediateTx (to the dual signature AliceBobAddr) is confirmed in the bitcoin network with the transaction id that he expects, matching that referred to in PaymentTx (Step 1.3), and that AliceBobAddr contains the right amount of Collateral+Payment (Step 1.4); that way he knows that he has some chance of getting the Payment amount from the PaymentTx so long as Alice eventually signs her part of PaymentTx and submits it once she's got the real world goods from Bob.

Beyond checking that the use of nLockTime greater than zero has effectively been deprecated, I have an additional query about how Alice can know that ExpiryTx is otherwise valid apart from having not yet reached its nLockTime, i.e. that it has two valid signatures, without submitting it to the bitcoin network? And if the only way for Alice to check that ExpiryTx as two valid signatures is to submit it then does the bitcoin network give a nuanced report of the transaction's validity, e.g. indicating that the signatures are valid even if the nLockTime is invalid...and perhaps also indicating that IntermediateTx does not exist yet since Alice wouldn't want to submit IntermediateTx until after she's made a test submission of ExpiryTx to avoid forever locking up her bitcoins in AlicceBobAddr because, without an (eventually) valid ExpiryTx, she has no way of getting them back again?

The answers to my additional queries may change the validity of it but the algorithm is based around the parties who could make the transactions malleable not actually making them malleable because they have mutually dependent incentives not to make them malleable and have various opportunities to confirm that the transactions aren't malleable.

Anyway, thanks for your interest Bitalo_Maciej; I hope you can answer my questions and check if the algorithm still makes sense thereafter (and hopefully MPOE-PR won't mind that I've probably written too much again :-) ).

Thanks MPOE-PR. You're are right that I have much much more to read (and unfortunately I'm already renowned among my friends for writing too much - sorry).

It's interesting that you picked out that particular line and in following the link that you kindly posted, I see that you've made some interesting points on WoT, something I only vaguely recall having heard about before.

The point of my original post was to describe the exchange algorithm and started off from the *premise* (which, in retrospect, perhaps I should have highlighted) that Alice and Bob had *already* reached the point at which they had attained at least some provisional level of trust in each other albeit still subject to agreement of terms (Step 0.0), principally the amount of collateral and the expiry time.

The algorithm itself aims to make it such that both parties have 'skin in the game' in an attempt to acceptably minimise each person's residual risk in that particular exchange and regardless of how many exchanges they had previously carried out with however many other people (or even with each other).

I do need to (and will) read more, especially all the learned content regarding trust; I hope you don't mind me raising questions/comments on that subject elsewhere in the forum, possibly in the thread that you pointed me to.

Thanks again for helping out a newbie with your enlightening post. :-)

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://bitcointalk.org/index.php?topic=118418.0), 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?