It will never cease to amaze me that someone with the technical chops to pull off an attack worth this much hasn't done the minimum pre-work necessary to get away with the cash or at least some non-trivial amount of it.
Money laundering, especially when hundreds of millions of dollars in value are on the line (meaning it's not your sleepy local police office dealing with it, but the best the federal government can offer), is hard in itself - and cashing out in actual physical dollars is even harder.
The potential for messing up on the way is simply enormous. Remember Silk Road? Guy got v& because of a stackoverflow post.
What was missing for me in the article is the fact that they don't call a function by name AND by validation of hash.
Instead, only by hash(<method name string> + "(bytes,bytes,uint64)").slice(0,10) which is brute-force-able.
Still, this sounds just like one of my worst nightmares. A code in production having bugs that will lose all my money to an untraceable environment (the tornado chain).
Funny tangent about the function hash... I can't tell you the number of man-hours I spent brute-forcing random function names to find the lowest value hash.
Quick background. Back in the pre Flashbot days, the competitive barrier to front running was winning priority gas auctions. Basically whoever was able to bid at the highest gas price would get their transaction mined with first, and would extract the MEV. (Kind of analogous to traditional HFTs fighting to shave off nanoseconds to win a latency-based priority race.)
So you had to make sure that your on-chain smart contract for the front-running bot is an insanely gas optimized as possible. You'd literally pay a thousand times per unit of gas as the average person. Every single byte matters. And one thing about the EVM is that zero bytes in the transaction data cost slightly less than non-zero bytes.
So anyway, in the hot-path of that front-running bot, you'd want to get as many zeros in the method hash as you could. So I'd literally run a GPU to brute force method names.
This doesn't even sound like a hack. The beneficiaries executed the digital contract in way that was explicitly permissible by the contract. It was perhaps contrary to the original intent of the contracts creator but that intent needs to be irrelevant for digital contracts to serve any useful purpose more than just traditional non-digital contracts.
3pt14159|4 years ago
lordnacho|4 years ago
mschuster91|4 years ago
The potential for messing up on the way is simply enormous. Remember Silk Road? Guy got v& because of a stackoverflow post.
yonixw|4 years ago
Instead, only by hash(<method name string> + "(bytes,bytes,uint64)").slice(0,10) which is brute-force-able.
Still, this sounds just like one of my worst nightmares. A code in production having bugs that will lose all my money to an untraceable environment (the tornado chain).
dcolkitt|4 years ago
Quick background. Back in the pre Flashbot days, the competitive barrier to front running was winning priority gas auctions. Basically whoever was able to bid at the highest gas price would get their transaction mined with first, and would extract the MEV. (Kind of analogous to traditional HFTs fighting to shave off nanoseconds to win a latency-based priority race.)
So you had to make sure that your on-chain smart contract for the front-running bot is an insanely gas optimized as possible. You'd literally pay a thousand times per unit of gas as the average person. Every single byte matters. And one thing about the EVM is that zero bytes in the transaction data cost slightly less than non-zero bytes.
So anyway, in the hot-path of that front-running bot, you'd want to get as many zeros in the method hash as you could. So I'd literally run a GPU to brute force method names.
hamburgerwah|4 years ago
patrickthebold|4 years ago
cwkoss|4 years ago
I wonder if Coinbase has flagged the USDC that was stolen. Are those currently less-fungible USDCs?
martinko|4 years ago
unknown|4 years ago
[deleted]
lfmunoz4|4 years ago
[deleted]