11 – BarterDex: Explaining Etomic Swaps

From a thread on reddit.com/r/ethereum with some editing

jl777 – It has taken a lot of work to get BarterDex working and debugged to the level it has and I wanted a solution for swapping ETH/ERC20 that had minimal changes to the source code. So I came up with ETOMIC, which is a special purpose coin whose purpose is to dynamically create a custom colored coin, just for a specific swap. The ETH side is locked in a contract to be released only if the corresponding ETOMIC utxo is properly spent via atomic swap protocol. Basically possession of the ETOMIC utxo proves you performed the atomic swap and we have ETH side contracts that implement the various hashlocking and time releases. It is a bit strange, but ETOMIC basically creates a virtual set of utxos for ETH to use for the atomic swap, so we can then use the existing barterDEX to swap ETOMIC as if it was the ETH. With pre and post lock and unlock actions to the ETH smartcontract to make it complete the ETH swap

privpub This is not an atomic swap: the Etomic blockchain effectively acts as a middleman and now needs to be trusted. Use of another blockchain also introduces an attack vector. I now not only need to trust the security of the ETH/BTC blockchains I am swapping between, but also that of the Etomic blockchain.

barbierirIf you’re worried about the Etomic blockchain security, it gets regularly notarized on Bitcoin blockchain (like all other Komodo assetchains). It’s called delayed-Proof-of-Work: https://wiki.komodoplatform.com/wiki/Delayed_Proof_of_Work_(dPoW). Even if an attacker has enough equihash power to attack Etomic, he couldn’t do that because he should first do the same to Bitcoin!

privpub I think dPoW is a weak security model, as it doesn’t in fact stop an attacker from taking control over the Etomic blockchain. It just makes it so that others can verify something did not go according to the history that was hashed and put in the Bitcoin blockchain. It doesn’t in fact provide security; it provides a small amount of transparency. If the incentive is big enough (say a swap for 1000s of BTC or ETH), the attacker can get away with a one-off attack that breaks the Etomic chain. dPoW or whatever one wants to call timestamping hashes into the Bitcoin blockchain is great for proving something existed at some point in time, not for security.

jl777 I dont think you are fully understanding the dPoW mechanism. The transparency you talk about is used by all the nodes to identify chain rewrite attacks to reject them. Once a notarization is done, then ETOMIC nodes wont accept any blocks older than the notarized block. So the KMD chain (and BTC chain when KMD is notarized) would need to be rewritten in order to undo a notarized ETOMIC tx.

That being said, until a notarization is achieved, the ETOMIC chain is indeed more like unconfirmed transactions and it is recommended that the user requires sufficient confirmations when doing very large atomic swaps. This is kind of common sense, ie. you dont do 1000 BTC tx on 0conf

That being said, the ETOMIC chain is used to create utxo for ETH balances, since ETH is balance based, it has no utxo. The atomic swap protocol is based on a reveal secret method and the possession of these secrets allows the spending of the locked funds. It is possible that even if ETOMIC chain is rewritten to the point of the notarized tx that a swap will properly complete. More detailed analysis of which tx is attacked and the effects of that on the true lock/unlock.

As you already understand timestamping hashes onto the Bitcoin blockchain is great to prove that a specific block exists, and using this proof of existence to prevent it from being erased is the power of dPoW.

privpub I think I understand it quite well, as nothing you described changes what I thought. There is nothing stopping a “false” tx/block from getting notarized if an attacker briefly controls the Etomic blockchain (except the security of the Etomic blockchain itself). This reduces the security of the swap to the security of the Etomic blockchain.

jl777 – If the “false” block gets notarized then it is the official block. So the “real” tx would become unspendable assuming the attack is replacing one tx with another.

The notarizations resolves which tx/block is real and which arent.

So if a node is waiting for notarization before proceeding to the next step (this can be configured by the user), then that node would only have a single valid chain history.

Can you describe a specific attack that the attacker briefly controlling the ETOMIC chain can do to a node that is waiting for notarizations?

privpub – Attacker (with control of Etomic blockchain) creates a false TX to do a successful Etomic-BTC swap and claims BTC, but ETH-side now has no valid way of claiming locked up ETH. Alternatively, just falsifying this and claim ETH:

   Basically possession of the ETOMIC utxo proves you performed the atomic swap

The attacks might not be entirely correct, but I don’t have time right now to dive into the specifics of the implementation. It boils down to that the implementation reduces the security of the swap to the security of the “middleman”, i.e. the Etomic blockchain. I much prefer HTLC atomic swaps.

jl777 It is of course your right to prefer HTLC swaps over ETOMIC, but let us not just make up random things and call it an attack. Also it might be via ETOMIC, but it is HTLC, so you can view ETOMIC as an offchain way of revealing HTLC secrets.

You say “attacker creates a false tx to do a successful ETOMIC-BTC swap”, but how is that possible to do with a false tx? The tx that qualifies to advance the atomic swap protocol to the next step requires it to be using the prenegotiated txid/vout with the prenegotiated p2sh address.

To my mind it seems there cant be a false tx that can advance the protocol to the next step as any tx that is valid enough to advance the protocol would be valid.

The protocol has as initial tx: bobdeposit alicepayment bobpayment

Then the spend tx: alicespend (of bobpayment) bobspend (of alicepayment) bobrefund (of bobdeposit).

At each step, each node can wait to advance until they are satisfied that the condition has been met. Let us assume that we are waiting for ETOMIC to be notarized so there is only one valid history and we can avoid the confusion of having different valid tx at each step (though even if we allowed that it seems it is fine).

After alicespend is done, it reveals the info bob needs to do bobspend. This either happens or doesnt happen. If it doesnt happen, the the atomic swap unwinds as if nothing happens. no harm, no foul. If it does happen, then bob is able to do the bobspend (as it is actually a conditional HTLC that you prefer)

Bob is able to invoke a refund at anytime so he can both spend alicepayment and retrieve his deposit. Alice started this hypothetical off with spending bobpayment, so she is whole and cant be losing funds.

Maybe the confusion arises from you using early draft idea statements like “Basically possession of the ETOMIC utxo proves you performed the atomic swap” as the basis for evaluation and not the actual implementation which refined the original concept. I apologize if the description was overly general.

If you dont have time to dive into the specifics of the implementation, I think it is only fair that you refrain from making blanket “this isn’t secure” type of statements. Fair enough?

Clearly it is all about the implementation, I just hope you can be open to using HTLC on an ETOMIC chain in lieu of (offchain or onchain) HTLC can be a good way to atomic swap assuming the implementation is sound.

I welcome a detailed review of the atomic swap protocol, especially the ETOMIC aspects.

 

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s