Cross Chain Swap with Escrow

User Alice has HBD but wants bitcoin and Bob has bitcoin but wants HBD. They can both send their funds to Binance and then Binance will pretend the HBD wasn't sent to them. So don't do that. So to avoid third parties and to solve this trust issue, both can use a blockchain level Escrow transactions on Hive.

A third party that doesn't need to handle the money directly, David comes to help. David should be a high reputation account in the normal sense of the word. The user behind the David account should be known for good judgement and good character.

Alice generates a single new BTC address and sends it to both Bob and David. Previously, Alice and Bob agreed on amounts and pricing of w HBD for v BTC.

1. Alice pays w HBD to Bob via escrow managed by David.
2. Preseumably the condenser_api.get_escrow API call should show both Bob and David the transaction is available, and then they can approve the escrow.
3. Once approved by David and Bob, Bob sends Alice the agreed Bitcoins. Should Bob reneg on the promise to send bitcoins, Alice can send a dispute transaction and David can return her HBD.
4. Once Bitcoins are deposited, Alice should release the funds to Bob. . Should Alice reneg on her agreement, Bob can make a dispute transaction so David, who also sees the bitcoins have been transferred to Alice, can arbitrate HBD to Bob.

The Hive software only needs to monitor the blockchain.

Third Party...

There is a third party but the escrowed HBD can only go to Alice or Bob no matter what David tries. David could be an automoton watching the Bitcoin blockchain for the transfer and then preparing for approval. Most of the time, David doesn't need to do anything.

Contrasting this with the other idea, which required the David user to keep a transaction secret and let Bob know it is valid, it is more simple. However, David can eventually send Alice's HBD to Bob in this case without Bob paying. In the other described method David could cheat Bob by conspiring with Alice telling Bob that a transaction that he cannot see is a real transfer but he wont find out it is fake until he has already sent his coins. I am not satisfied with either method completely, but this one seems to be a better compromise because there is less issues with timing and there is no need to store transactions. One other benefit is the elimination of the need for a lent out "Carmen" account.

Can we get rid of David? Hive doesn't have any hash functions in its scripting language because it doesn't have a scripting language. Now I thought that perhaps I could be clever and have the Bitcoin scripting language validate that a Hive transaction was signed but after investigating that avenue I see that those operations always include too much data into the hash. I was thinking the secret transaction would do the trick but then I later realized that this account could be stolen unless I make David a cosigner for everything the lent account does. I basically had to implement escrow off-chain in order to keep the participants from stealing the account in a way that doesn't let the account owner steal the money.

You might want to look at these tools you can use to do what is described in the article

The lack of scripting in Hive can only be compensated with escrow agents (using the escrow transfers). The only attack vector is a conspiracy involving an escrow agent and the trader trading her HBD.