2

Let's say that Alice wants to send Bob 1 BTC, and in return Bob will send Alice 1 ETH.

Alice's Bitcoin address is BTC_A, and Alice's Ethereum address is ETH_A. Likewise, Bob owns addresses BTC_B and ETH_B.

BTC_B is a "fresh" address, with no transaction history whatsoever.

Alice creates a single transaction to ETH_A containing slightly over the amount that she will send to Bob and broadcasts it. The transaction hash of this will be called tx1.

Bob waits for that transaction to be confirmed and then creates a smart contract with the following (immutable) parameters:

inputaddr, set to BTC_A

inputtx, set to the tx1_txhash from above

outputaddr, set to BTC_B

minfee, set to a "reasonable" Bitcoin fee/byte, based on current network conditions

waittime, set to the number of seconds after which a transaction with minfee will be confirmed on the BTC blockchain, plus a significant margin for safety

val is set to an amount representing 1 BTC, or however much Alice is sending to Bob

Bob also deposits 1 ETH into the smart contract, and is not allowed to withdraw it

Alice submits a transaction, tx2, to the Bitcoin blockchain with the following properties:

  • inputtx is its only input
  • outputaddr is its only output address
  • fee > minfee
  • signed by BTC_A

She also submits this whole transaction to the smart contract, which verifies these four properties. If they are all met, note the time as txtime.

Bob will continuously monitor the Bitcoin blockchain, and if Alice tries to double spend the input transaction, he will submit the double spend transaction to the smart contract. The smart contract will verify that this transaction is legitimate, and if it isn't identical to the first transaction that Alice submitted earlier, will refund the ETH back to ETH_B.

Bob will also be able to withdraw the locked ETH if Alice doesn't submit the BTC transaction to the contract in a reasonable amount of time.

If waittime has passed since txtime and Bob hasn't submitted proof of a double spend, Alice can withdraw the locked ETH to ETH_A at her leisure.


This seems like the kind of thing that someone would have already come up with, but I couldn't find any other trustless examples of a BTC-ETH exchange. Is there a fundamental flaw in this system?

  • The problem with your approach is that you can submit fake transactions to the contract and the contract cannot check if they were mined or not in the bitcoin blockchain. You might have to use BTCRelay but it is very outdated. – Ismael Aug 9 '18 at 18:33
  • @Ismael can't Bob then submit those transactions since they were signed by Alice and are now public? – Daniel M. Aug 9 '18 at 18:34
  • Bitcoin transaction still have some malleability issues, it might be possible for B to manipulate tx2 from A and get a valid transaction that have the same properties than tx2 but are not the same, so they will look like A is causing a double spend. – Ismael Aug 9 '18 at 23:22
  • 1
    @Ismael Based on what I'm reading in the Bitcoin wiki, you can avoid malleability by only accepting transactions that confirm exactly to the spec, and it seems that lightning network also relies on un-malleable transactions – Daniel M. Aug 9 '18 at 23:49
1

It has been implemented by Komodo.

I've also developed a sample cross chain atomic swap contract (for BIP-199 compatible chains). You can look at the repo here

  • Ok, that terminology "Atomic Swap" is what I've been looking for. Looks like the process is somewhat similar. – Daniel M. Aug 8 '18 at 11:00
  • You should add more details to your answer otherwise it is link only answer and they do not provide much value if the link changes in the future or the host disappear. – Ismael Aug 9 '18 at 18:31

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.