This is adapted from a twitter thread. Like the thread, I’ll start off talking based mostly on a simplification of what actually happened, and at least point to the somewhat more complicated but more accurate account lower down. I’m virtually sure that I have some of the technical bug details wrong here, so don’t take this as gospel, but the overall lesson is clear.
Hah, I love this SO MUCH. Because I am a terrible person only slightly bothered by the people who are actually suffering as a result.
This is an auction run by code on the Ethereum blockchain. You make a bid by sending the “contract” some money (in the form of ETH cryptocurrency; every Ethereum “contract” basically has a built-in escrow agent), and if you send more than the ultimate price (it’s a “modified Dutch auction”), it’s supposed to refund that money. But!
Due to a little bitty bug (and a relatively typical one; thousands of bugs like this one are written every day), the program (roughly) thinks that it’s already done that, and doesn’t do it “again”. And all the overrides in the code aren’t low-enough level to slip past that check.
Also (due to another bug, where it falsely assumes that every “minting” transaction “mints” exactly one token-thing, but in fact some minted multiple) the program can never reach a state in which it will allow the owners of the thing(s) being auctioned to withdraw the funds; those ETH will stay in escrow forever.
Yet another example of why “Code is Law” is silly and false.
I can think of three basic things that could be done about this:
First, they could tell the victims “too bad, code is law, that’s what you get for sending money to a contract that might have bugs”. That’s imho unlikely; the publicity would be terrible, which is to say, accurate.
Second, they could fork the Ethereum blockchain, and get 51% of the system to agree to swap in an altered chain reflecting what the program should have done. Forks are also terrible publicity; I think this is unlikely too.
The main reason I think a fork is unlikely is that, third, some number of unjustly wealthy crypto-whales can just step in and make up the lost funds out of their own pockets. This will superficially make it look like “the system works”, and the donors will get clout. I kind of suspect that this is what will happen (although if in fact only the owners, and not the bidders, have lost money, see below, the first option might be more likely, in that “it’s your fault for having deployed buggy code” doesn’t sound all that bad maybe.)
I was actually dreaming about all this this morning, between waking up briefly and checking Twitter for amusing things since I was awake anyway, and actually waking up an hour or two later. (And now I have a headache :P.)
It was a fun dream, reminiscent of the early anti-virus days before it all got boring, sitting around in a War Room with various Important People on the phone, trying to decide the best mitigation for a weird code thing.
Mostly I thought / dreamed about how to fix it with a fork-but-not-really. A brute-force fork (“install this new Blockchain!”) would be boring, but what if we hacked the Ethereum bytecode interpreter? The bytecodes may be all fancily embedded in the blockchain, but their meaning isn’t!
We (note I’m saying “we” here because now I’m talking about something cool) could just (“just”) add code to the interpreter saying “if between time0 and time1 you’re interpreting these bytecodes [buggy program], then pretend that they say [fixed copy of program]”. Sweet, eh? 😁
Then you get enough nodes to install the new EVM sometime before time0, and Bob is your Uncle.
Would enough nodes object, and refuse to run the hacked code, that there would be a fork-in-practice? Good question, and I have no idea. I’m just doing this for the mental exercise. :)
Here’s a history of the most famous (unplanned) Ethereum fork. That one was due to an active attack on a bug to steal stuff, not a bug simpliciter, and differed in other interesting ways. The amount of money at stake, though, was arguably comparable.
Here’s the more detailed analysis alluded to above, which says that the bidders’ money getting stuck was due to someone intentionally exploiting that bug (by, I think, having a “contract” send a bid, and then refusing the attempt to send it a refund, or something), and they turned the exploit off (by signaling the contract to accept the refund now), after which (some? all?) refunds went through, but then due to the other bug all by itself with no exploitation, the owners are unable to withdraw the rest of the funds forever.
And here’s Web 3 is Going Great on the situation for completeness. :)
I’m fascinated by the details of the bugs that led to this, but in fact they don’t really matter; the moral is that code will have bugs, bugs will cause things to happen that no one wanted and/or that violated someone’s rights in some way, and that therefore code is not law, and must never be law.
(Speaking of which, I had a long and… somewhat memorable Twitter discussion (apologies about how hard it will be to read that anything like linearly) about this with one Vinay Gupta, who is apparently something of a Force in this space, having 37.5K Twitter followers. Among other things, he calls me all sorts of names, and declares that he himself is “a different kind/calibre of smart. Possibly a once in a generation transformational intelligence.” So that happened. :D
But if I start weblogifying all of my Twitter exploits, you’ll get bored. Heck, I’ll get bored! So I won’t.)
And that’s the end of Today’s Episode of Code Is Definitely Not Law So There. Not a podcast.
ceoln 