P2P algorithm to carry out limited trust exchange of bitcoins for real goods

[Phil Dann Ward]

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?

[MPOE-PR]

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.

I'd suggest reading much much more and writing much, much less.

[Phil Dann Ward]

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.

I'd suggest reading much much more and writing much, much less.

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. :-)

[Joshuar]

There will always have to be a thirdparty, trusting an exchange is a hell of a lot better than trusting a random stranger to trade bitcoins with..seriously.

[Bitalo_Maciej]

Phil Dann Ward: There is one flaw in your protocol regarding lately discussed transaction malleability issue. You cannot be sure about a TXID of transaction until it is included in the blockchain (and even then, there could be a reorg later, but let's assume that's highly unlikely). And yet, this protocol relies on an assumption that a lock time transaction will be able to spend the funds using a specific TXID as an input. If in the mean time the TXID gets changed (someone manages to insert a modified version of the transaction in the blockchain), this will fail.

This problem (which is a problem for many Contract-style protocols) will gradually fade away as Bitcoin devs address the malleability issue somehow.

[Phil Dann Ward]

Phil Dann Ward: There is one flaw in your protocol regarding lately discussed transaction malleability issue. You cannot be sure about a TXID of transaction until it is included in the blockchain (and even then, there could be a reorg later, but let's assume that's highly unlikely). And yet, this protocol relies on an assumption that a lock time transaction will be able to spend the funds using a specific TXID as an input. If in the mean time the TXID gets changed (someone manages to insert a modified version of the transaction in the blockchain), this will fail.

This problem (which is a problem for many Contract-style protocols) will gradually fade away as Bitcoin devs address the malleability issue somehow.

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 :-) ).

[malthus]

What happens if Alice receives the goods but doesn't pay? Wouldn't she get back the full amount upon expiry?

[Phil Dann Ward]

What happens if Alice receives the goods but doesn't pay? Wouldn't she get back the full amount upon expiry?

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]

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.

That's correct, transactions with lock time set in the future are considered non-standard and won't be relayed. This is to prevent possible DOS attacks where you could spam the network with such transactions.

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

You can check that the transaction is valid yourself:
- you can decode it to see if all parameters are ok - all outputs are pointing where they should be, and the nLockTime is properly set
- you can pick signatures from inputs and check them yourself using the same algorithms that Bitcoin software uses

That said, I have a feeling that we misunderstood ourselves regarding the use of some terminology. When I'm referring to "transaction malleability", I'm not talking about ability for the author of the transaction to submit a new version of it based on lock time parameter. I'm talking about someone else (let's call her Eve) being able to tweak certain tx parameters in a way that the signature is still valid, but the TXID is different. This can happen without Eve knowing Bob or Alice - she can set up a node that will catch transactions as they propagate in the network and re-submit them with tweaked parameters. She won't gain anything by doing this, but she can mess up with software and protocols that expect that TXID's don't change, effectively pulling of a DOS attack on those.

[Phil Dann Ward]

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.

That's correct, transactions with lock time set in the future are considered non-standard and won't be relayed. This is to prevent possible DOS attacks where you could spam the network with such transactions.

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

You can check that the transaction is valid yourself:
- you can decode it to see if all parameters are ok - all outputs are pointing where they should be, and the nLockTime is properly set
- you can pick signatures from inputs and check them yourself using the same algorithms that Bitcoin software uses

That said, I have a feeling that we misunderstood ourselves regarding the use of some terminology. When I'm referring to "transaction malleability", I'm not talking about ability for the author of the transaction to submit a new version of it based on lock time parameter. I'm talking about someone else (let's call her Eve) being able to tweak certain tx parameters in a way that the signature is still valid, but the TXID is different. This can happen without Eve knowing Bob or Alice - she can set up a node that will catch transactions as they propagate in the network and re-submit them with tweaked parameters. She won't gain anything by doing this, but she can mess up with software and protocols that expect that TXID's don't change, effectively pulling of a DOS attack on those.

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.