New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Meta: Race Condition in Hashed Time Lock Scheme #624

Closed
its-me-yours-truly opened this Issue Jan 7, 2019 · 2 comments

Comments

Projects
None yet
2 participants
@its-me-yours-truly
Copy link
Contributor

its-me-yours-truly commented Jan 7, 2019

I have just read the entire paper (twice) and have identified what I would call a race condition in the hashed time lock scheme.

Imagine the following attack scenario:

a) ALICE wants to send 1 BTC to BOB.
b) BOB wants to send 100 ETH to ALICE in exchange.
c) The current state is: both ALICE and BOB have both "negotiated" their hash locked charge back transactions as well as the "atomic swap" transaction
d) Both are waiting for the secret to be revealed by either of them transmitting his "claim" transaction and therefore revealing the "interlocked secret" for the other "claim" transaction

Typically, block timestamps can be chosen "randomly" by the miners as long as they follow certain criteria (something like being greater than the last block and less than 2 hours in the future?) and we know that local clocks on machines connected to the internet can be a bitch.
Let's keep it simple for now: we just assume that two blocks are found on both blockchains, at the same time, but with slightly different (20 seconds) timestamps.

So now, at time T, we have the following two blocks being broadcast:

  • Block ETH at time (T-20), that is 20 seconds before the block on the BTC chain is found
  • Block BTC at time (T) and then later the block on the BTC blockchain

What now happens is a terrible race condition.
Whoever is claiming on the ETH blockchain, broadcasts the claim transaction and reveals his secret.
At the very same time, however, he can charge back on the BTC blockchain, because the blockchain's "reality" is 20 seconds in the future and already past T.

Now

a) When BOB, who has ETH locked up, sees the charge back transaction on the BTC chain, he cannot reliably charge back on the ETH yet. He can try to submit a charge back transaction, but it is not guaranteed that the next block will actually have a timestamp > T (only > T-20)
b) At the same time, BOB who has ETH locked up, sees his ETH being claimed by ALICE -> this reveals the secret
c) Technically, he could claim his BTC from ALICE now, but they are gone already! All he can do it try to "broadcast" faster and hope that the next miner sees his transaction before the "charge back" sent by ALICE. Most likely he will fail (txn-outs already spent) as has the "first mover advantage" and her transaction is already being broadcast for quite a while.
d) Now, BOB will most likely try to get in his "ETH" charge back in as soon as possible. This is very difficult, as the "claim" has been already "claimed" in the unconfirmed pools. Since both transactions are "pre created", replace by fee probably is not an option.
e) Even if the application took care of it, and gave the charge backs more fees in the first place, this would not change the general bias towards the attacker's advantage.

What do you think? Did I miss anything? In my humble opinion this is a very realistic (and frequently spottable in the wild) scenario, especially due to the fine granularity of ETH blocks.

@D4nte

This comment has been minimized.

Copy link
Member

D4nte commented Jan 7, 2019

Hi @cagara,

Thank you for sharing your concerns. Please note that the design has evolved since the white paper was released. We are currently working on RFCs that will describe the protocol more precisely. Please watch our GitHub organisation to access them once released.

Regarding the issue you raised, if I understand correctly by "charge back" you mean that Alice tries to refund her BTC back to her address, is that correct?

The issue regarding the block timestamp is indeed correct, this is why the TimeLock part of the HTLC needs to be set with care.

In the case of a BTC->ETH swap as described above, we would set the following:

  • BTC HTLC time lock: 24 hours
  • ETH HTLC time lock: 12 hours

Which means that Bob cannot refund his ETH until 12 hours after the contract is setup and Alice cannot refund her BTC until 24 hours after the contract is setup.

If 12 hours have passed and Alice has not revealed the secret, Bob should refund ETH to himself.

The scenario you described can still occur under the following conditions:

  • 24 hours have passed
  • Alice & Bob have not done any actions in the blockchain (the assets are still locked in HTLCs)
  • Alice sends a refund BTC and redeem ETH at the same time

However, if 12 hours have passed and Alice has not redeemed than Bob should refund its ETH to keep it safe.

We would also recommend for Alice to NOT proceed to the ETH redemption if she is getting close to the time lock expiry. This is to avoid Bob seeing the secret in the mempool and attempting to get a faster transaction to refund ETH.

I hope this makes sense.

@its-me-yours-truly

This comment has been minimized.

Copy link
Contributor Author

its-me-yours-truly commented Jan 7, 2019

The different time locks make perfect sense! Thanks for the explanation ..

@D4nte D4nte added this to the Sprint 4 🎄🎅🏿 milestone Jan 8, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment