I like the tabular format. It helps visualize what's going on here.
I recommend reading through the discussion between me and Gavin about this. There's a
lot of overlap with what you posted, but also some details that we already worked out that you're missing:
https://bitcointalksearch.org/topic/buyer-seller-escrow-transactions-with-or-without-3rd-party-75481We referred to the "guaranteefee" as a "risk deposit", and it's something that both parties have to contribute. It's the only way to make the remaining risk symmetric -- if everything goes smoothly, everyone gets their risk deposits back. Until then, both parties have financial incentive to resolve the transaction agreeably. Any off-nominal behavior could result in loss of risk deposit. The size of the deposit can be set depending on the level of trust (or lack of) between the two parties. 20% might be agreeable for online sellers with reputations at risk, but 100% would be expected between two parties contacting each other on craigslist.
It is possible, with multi-sig and non-standard signature hashtypes, that the buyer can create a transaction including purchase price plus buyer-risk-deposit that is
invalid until the seller commits his risk deposit to the same transaction (which will all go to the 2-of-2 "wallet"). It won't be valid until the seller commits a risk deposit of the correct size to the transaction. In other words, either both parties get their money in at the same time, or no one does. This is a prerequisite for any contract/escrow that requires money from multiple parties.
Also, I strongly disapprove of key-sharing, for any reason. Also, it doesn't work if the money is ultimately split at the end (Alice puts in (1+Risk)*X and Bob puts in Risk*X, and at the end, Alice gets Risk*X and Bob gets (1+Risk)*X). When one party gives up their private key, there's nothing stopping the other party from taking 100% even if the two parties agreed to split it in some way. Additionally, it is a potential security disaster for app developers to have to accommodate private keys for which it is epic-fail if they are revealed, but other keys are expected to be revealed.
This is why multi-sig was created (P2SH). You create a wallet specifically for these types of escrow transactions. Buyer and seller each generate the next private key in their wallet, and exchange public keys to create the 2-of-2 "address" to which funds will be committed. At the end of the transaction, one party creates the payout transaction as they'd like to see it (usually (1+R)*X to Bob and R*X to Alice, but could also be a refund transaction, or some split due to wacky situations). That party signs it with their private key and sends it to the other party. That party verifies the distribution is correct, then signs and broadcasts it. No one compromised any private keys, and P2SH was used to its fullest potential