Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
Meta: Race Condition in Hashed Time Lock Scheme #624
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.
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.
So now, at time T, we have the following two blocks being broadcast:
What now happens is a terrible race condition.
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)
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.
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:
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:
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.