Binance Hack: Should the Threat of Reorgs Be Used to Deter Hackers? - Ep.072

Transcript

Hi everyone, welcome to Unconfirmed, the podcast that reveals how the marquee names in crypto are reacting to the week's top headlines and gets the inside scoop on what they see on the horizon. I'm your host, Laura Shin. If you haven't yet signed up for the crypto workshop, Milton Demiris of CoinShares and Jalak Jobamputra of Future Perfect Ventures and I are all teaching at Omega Institute in September, check out the show notes for more details. And if you're not yet signed up for my weekly email newsletter, Go now to unchainedpodcast.com to sign up. Ciphertrace makes it easy for exchanges and crypto businesses to comply with cryptocurrency and time money laundering laws.

Avoid illegal sources of funds and maintain healthy banking relationships. Ciphertrace is helping you grow the crypto economy by keeping it safe and secure. Today's guest is Tushar Jain, partner at Multicoin Capital. Welcome, Tushar. Hi, Laura. It's great to be on. Disclosure before we dive into today's discussion, Multicoin Capital has invested in BNB tokens. And the reason that's relevant is because we're going to talk about what happened with Binance this week. The hack of slightly more than 7000 Bitcoins, roughly $40 million at the time. What do we know about what happened? So we know a few things and Binance has been very transparent, actually, about the hack.

This was a very sophisticated attack. This was not a simple hack. This was probably something that the attackers were working on for weeks, if not months, and they were able to compromise a large number of user accounts. Then they used that access to basically submit a transaction from Binance's hot wallet to a wallet controlled by the hacker. And as Binance disclosed, it was clear that the attacker had really good knowledge about the alerts and the risk management systems and the risk control systems that Binance has in place. So

they were basically able to thread the needle, for lack of a better analogy. And they were able to clean out the entire Bitcoin hot wallet that Binance had, which was just over 7,000 Bitcoin. Yeah, and just to quote from the notice that they, or the blog post that they published, they said that hackers were able to obtain a large number of user API keys, 2FA codes, the two-factor codes that get sent to your phone or on your, are on an app that use and potentially other info. And they say that the hackers used a variety of techniques, including phishing viruses and other attacks. And Binance said that they're still figuring out all the different methods that were used. And also that there

might even be more accounts that haven't been identified. So yeah, that is like, I think what's interesting about it is when we had that and it's still going on the epidemic of the phone numbers that were being hijacked. Like when one happens at any given time, like you don't think about that exchange being hacked because it just feels like that user is being hacked, right? But it's only because like these were all coordinated that it really felt like, you know, an attack on Binance. But one other thing that I wasn't sure about was, so if you were to try something like that, I know with Coinbase that they have their vaults where a user can store their money in the hot wallet or in cold storage. But for this

situation, I looked at a bunch of those transactions that were a part of the hack and some of them, they're large, it's like 450 Bitcoin, 360 Bitcoin, stuff like that. So does that mean that those individual users were keeping that amount of Bitcoin in their own hot wallet on Binance? As far as I am aware, Binance does not give users the ability to decide what percentage of their funds are held in cold storage versus hot wallets. I think they decide that at an exchange level and they basically refill hot wallets if they get depleted from their cold storage. And so I think, you know, I don't know if that abstraction of, you know, the user put their

coins into cold storage versus hot storage makes a big difference because at the end of the day, the exchange is responsible for the hack, right? And as we saw in this case, finance is making sure that no users are actually losing any money at all and they're covering the entire cost of the hack. And I would expect that to happen for any reputable exchange in this space. If they can afford to cover the loss, it is their responsibility to cover that loss. Yeah, and I think that was a policy they put in place after a previous hack, I guess. And then I did see that, actually, I'm forgetting who it was, but somebody on the blog published something saying that they estimated that if the revenues were similar to quarter one, then they would recoup the money lost within like 47 days.

Anyway, well, okay, so the bigger issue actually ended up kind of occurring after the hack in a way. A Bitcoin Core developer, Jeremy Rubin, very casually actually, which I found interesting, tweeted to CZ, who's the CEO of Binance, that the company could basically incentivize miners to reorg the chain so as to like basically kind of recoup the hacked coins. And what he tweeted was CZ. or CZ Binance, which is CZ's Twitter handle. If you reveal your private keys for the hacked coins or a subset of them, you can decentralized Lee, he made up a word, at zero cost to you coordinate a re-arg to undo

the theft. What did he mean there? So that's a really interesting question. And I want to unpack that a little bit. But first I want to address of what the conversation has been like around this topic for the past 24 hours or so. I think that Jeremy made an interesting suggestion. And as it just so happened, CZ was doing an AMA last night, and it was a previously scheduled AMA. They'd sent it out earlier. And so someone asked him about this question. And I think that CZ's willingness to even consider this idea is what has caused a lot of reaction over social media recently. And so

to be very clear, Binance is not pursuing this plan. They're not going to try and reorg the chain or roll back any transactions. CZ just on the AMA as he was asked the question said, oh yeah, we would consider that. Bitcoin's immutability is not threatened right now. But that being said, it's a really interesting tactic because as it turns out, if you look at how the Bitcoin blockchain works, each block rewards the miner with 12.5 Bitcoins. And that is the security incentive for the block, right? The reason to mine new Bitcoins or mine new blocks is because you get 12.5 bitcoins per block right now and given that four thousand or seven thousand

bitcoins were stolen um in this hack that's substantially more bitcoins that were stolen than the miners mine and so what that basically means is if binance committed either on-chain somehow or off-chain or through some other mechanism, and we can discuss some of the types of mechanisms, if they committed to reimbursing the miners or rewarding the miners for mining a separate chain that did not include the transaction where the hackers stole the money, then the economic incentive is possibly there for the miners to take that money from Binance and basically

undo that transaction. Now, it's speculative because obviously undoing a transaction in this way would challenge the value proposition of Bitcoin itself. And so maybe the miners wouldn't go for it. We don't know until someone tries. And so one technical point before we dive into all that, one part I didn't understand about Jeremy's tweet was he said, if you reveal your private keys for the hacked coins, so why would CZ need to do that? It's only one way to do that. So what Jeremy was referring to more generically was create some sort of structure by which the miners who go back and try to rewrite history get rewarded. One way to do that is if CZ revealed the

private key for the address that controlled those 7,000 Bitcoin, then if you were a miner who went back and remined that block where the Bitcoin was stolen, you could replace the transaction that was in that block with a transaction that sent those Bitcoin to you. And by revealing Binance's private key to everyone. That means that CZ would not need to coordinate with any miners or Binance would not need to coordinate with any miners or call anyone or try and make this happen on their own. It would happen in a decentralized way because the incentive would

exist for all of the miners that currently exist to go back and try and get those Bitcoin for themselves rather than let the hacker have them. Oh my God. Wow, okay, okay. This is incredibly, incredibly fascinating. So we're gonna continue discussing like the economics around this and incentives and stuff in a moment. But first, a quick word from our fabulous sponsors. Did you know that if money laundering were an economy, its GDP would be the size of Canada's? Large volumes of tainted crypto assets move through financial networks, often below the radar of banks. Cyber criminals use unregulated crypto exchanges to avoid detection. No wonder governments around the world are rolling out tough new

anti-money laundering laws for cryptocurrencies. Complying with those laws isn't easy. Banks and exchanges need the best cryptocurrency intelligence available to avoid penalties. Now you can use the same powerful AML and compliance monitoring tools used by regulators. Cyphertrace is securing the crypto economy. To learn more, visit cyphertrace.com slash unchained. Back to my conversation with Tushar Jane of Multicoin Capital. All right. So, okay. They decided not to try this route, but let's just, you know, kind of entertain this idea. So if, do you think if they had tried that they would have succeeded? Like, and, and, and actually also, so you said that that was one way to do it where like they wouldn't need to

persuade other people, but what was the other way? Cause it, I did see some other people on Twitter talking about other methods and it did seem like those would be sort of more centralized. Yeah, there are other methods to do this. I mean, one that could be considered is just Binance saying, hey, we will pay you. Take our word for it. Right. Please go mine those blocks. And, you know, we're a credible known entity in this space. And, you know, maybe some miners would take their word for it. Obviously, that's there's a big trust assumption based in there. Or they could have sent a double spend transaction where Binance basically tries to double spend those Bitcoin, but sends it into some sort of multi-sig wallet that is controlled

by a number of prominent people in the industry who could publicly commit to rewarding the miners, or even sign double spend transactions that send that Bitcoin that was stolen to known mining pools. and just, you know, tell them like, Hey, if you want to actually have this transaction be a valid transaction, you have to go back and rewind history and re and, you know, remind those blocks. Um, and so because of the way that mining pools work, um, you could, you know, what some of their addresses are and you could literally just say, you know, we're going to try and sign transactions to double spend this money and give it to some of the biggest mining pools out there. Wow. Yeah. So it really, it could

have been basically quite centralized in this. I mean, so I, so I take Jeremy's suggestion where you could do it in a decentralized fashion. Um, but in the other ways it was like, you know, if a few people decided or, or rather if they got enough, if they got, if they got enough of the right people on board, then potentially they could have pushed this through. Is that right? I would push back on that. I think it's somewhat correct, but there's very important nuance here, which is it's not about getting the right people on board, it's about getting the right economic incentives in place. Because let me just zoom out and explain kind of the security of

Bitcoin, right? The security of Bitcoin is all about miners having a larger incentive to mine on the current longest chain than to go back and try to remind an old block. And that's all based on how much the miners are earning. And so typically people in the industry think that six block confirmations on Bitcoin is final. And they think that six block confirmations is final because at that point it becomes very unlikely that any miners or mining pools would have the incentive to go back and try to redo history.

However, when there are such large transactions at stake, when there's a transaction with 7,000 Bitcoin at stake, well, now six blocks is just not final enough. And this is a trade-off of probabilistic finality. With Bitcoin, there is not a single transaction that is actually final. Maybe the Genesis transaction, that's a more technical question. But no real transactions that you can think of are actually final. You can roll everything back. It's all probabilistic finality, right? And so because of that, I think this is capturing a lot of cognitive dissonance within the community because they want to think of some of these transactions as final. But the

larger the value of the transaction, the longer you need to wait for it to be actually final. Oh. Oh, oh, oh. Okay, now I, sorry, I just understood something. Right, right, right. Because it's just about how much you could pay to have it rolled back based on, yeah, the number of new Bitcoins being produced every 10 minutes. Okay. Correct. I just understood that, right. And by the way, I just thought it was funny you said pretty much only the Genesis block is final because that was more than 10 years ago. But anyway, um, So here's the thing though, that I find really fascinating. So, you know, both of us just said that if they had gotten the incentives right, which, you know, we're just,

you know, saying right now, like clearly they had the money to potentially get the incentives right. Then they, they potentially could have succeeded in reorganizing the chain and, and you know, sort of undoing the hacked, or the hack transactions, or at least diverting them in some fashion, which would reward the miners for doing that. But the thing is, they ultimately decided against. And so why do you think that is? That's a really good question. I think they decided against it because they were worried that this would challenge the value proposition of Bitcoin.

And CZ said as much. I mean, you know, CZ is one of the most transparent CEOs out there. It's amazing how transparent he is. And him revealing the entire thought process that went through Binance's executive leadership on thinking through this is a great case study that analysts like myself will use to study how major players in this industry would react to certain situations. So I really appreciate the transparency and the straightforwardness. unlike some other exchanges who've been hacked in the past, leading to regulatory trouble, et cetera. So I think that transparency is really great. Are you referring to anything that was in the news recently?

Maybe. Sorry. It was just too funny. Anyway, OK, keep going. So I think that in the future, if exchanges are prepared for this, and they have a plan ready to go to try and incentivize miners to do a block reorg within one or two or even six blocks of the hack transaction, that would not only be more economically feasible, but it would also be more socially acceptable because reorgs happen all the time.

That is not a strange thing. It's just the size of the reorg that matters. One block reorgs are totally normal. That happens all the time. Those are just uncoaled blocks. And that happens when two miners happen to both mine a valid block at the same time, or one mines a valid block without having seen the other one's valid block. And now all of the other miners that exist within the Bitcoin ecosystem have a choice to make. They can either mine on top of miner A's block or on miner B's block. And that choice is pretty much random. They don't really have a major incentive to pick one versus the other, unless there's some off-chain coordination about that ownership, et cetera.

So even a two-block reorg, Not crazy, less likely for sure, but not crazy. And this is why most exchanges and other players in this industry want six block confirmations, because at that point it becomes extremely unlikely that a block reorg will happen. So I think if the next time there is a hack, if an exchange is ready to go with a plan that says, hey, we're going to try and get this reorg within three blocks or something less than six, that would actually work. Yeah, but see, the difference there is that in the examples that you gave of the reorgs that happen quite commonly, those are ones where they're sort of accidental and it kind of doesn't matter which one you build on, right, for the next block.

But in this case, where they're like intentionally creating a reorg and intentionally creating this competing chain and then trying to reverse transactions by getting people to build on their chain, I just still wonder, will people really treat it as just a run-of-the-mill, kind of uncold block as you described it? I think, well, I don't know, actually. That's a really good question. I think that if it's a smaller block reorg, then why does it matter? the intentions were this is one of the things that attracts me to bitcoin and that i think is one of the most valuable things about bitcoin so bitcoin does not care what i think or what you think or what any of the people in the audience

think bitcoin just is you know no one's opinions matter um the the system is held together with game theory and economic incentives and that is it and so you know maybe some people would be really mad but this is the thing But isn't that what we've been saying so far in this podcast, which is that they could have crafted the economic incentives in a way where they could have gotten a reorg potentially pushed through, but they didn't do it. And so like, but why is that? You know, because this is not the first time I feel like I learned about, you know, some theory around how all this would play out. And then when we were presented with that situation, it didn't happen. Like with the 51% attack on Ethereum Classic, you know, last fall, before

then everyone was like, oh, the price would plummet. And, you know, obviously that didn't happen. So I just wonder here, like, is that the same thing where we, you know, think like, oh, you know, this, I like, I just feel like if the incentives actually were on the side of Binance, then why didn't they do it? And like, and but why is that? You know, I feel like there's something else at play. You're asking the right question, but I think the incentives were not there for Binance. The reality is, while this hack was painful for them, it was fully covered by their insurance fund, They could afford the loss and their business was not at risk. There's no existential threat to Binance from this. Binance

will continue to trade. It'll continue to be the world's top spot exchange and that's not going away. And so it wasn't worth it for Binance in this specific case to go after the reorg, even to recover $40 million because the reputational damage would have been greater than $40 million. However, let's imagine a scenario in the future where some other exchange or some custodian gets hacked for a larger amount of Bitcoin or something beyond what their insurance can handle. And they actually have existential risk on the business. Well, then the incentives would be different. And in that case, I would expect them to try everything before letting their customers' funds just be gone. But here, I just don't think the incentives existed for Binance

to pursue this because they were able to cover this out of the insurance fund that is created specifically for this scenario. Yeah, and there potentially, I guess, was the risk of creating a hard fork, like causing some kind of schism in the community. Yeah, it wouldn't have been a hard fork. That's one of the things that's different about this versus the Ethereum DAO incident. I've seen a lot of comparisons about that. in the community today. Oh, right. Because it wouldn't require the clients to update? Is that why? No one has to download and run new software. When you do a hard fork, you have to download and run new software. Something just outside of the system is changing. Whereas this would be within the system.

You could continue to run the same Bitcoin node that you are running today, and nothing would change for you. You wouldn't notice. You would notice if there was a reorg, but you don't have to do anything. Whereas if there's a hard fork, you need to download new software. Right. And okay, so one last question actually that I want to ask you about this topic is, so I did see some people on Twitter kind of growing frankly about the superiority, I think of like fast finality over probabilistic finality. So I wanted to ask, do you feel like this incident kind of says anything about the preference for some of the different blockchains or the

different entities in the ecosystem for proof of work versus proof of stake chains? That's another really good question. However, I think some ideas are being confused here. The idea of probabilistic finality versus quote unquote true finality is a separate idea from proof of stake or proof of work. You can implement quote unquote true finality into proof of work chains. For example, there was discussions and I forget, maybe this actually happened on Bitcoin Cash where they implemented checkpointing in order to protect against 51% attacks. And so checkpointing is the mechanism that is used to create

true finality, whereas probabilistic finality is just a system where there is no checkpointing. And so if you get control of enough of the block production, whether that's proof of work or proof of stake, you could have the ability to roll back you know, as far as you want. So those two concepts are unrelated. But what is checkpointing? So checkpointing is basically like you can say, you know, at after every 10 blocks, we are going to take a snapshot of what the system is. And now this is final and there's no reordering that away. This gets transmitted out to all the nodes and all the nodes agree. This is final. Right now. I have to just

caveat this with, I haven't seen many proof of work systems that implement checkpointing. And that is definitely more common in proof of stake systems. But there's nothing intrinsic about proof of work or proof of stake that says whether checkpointing should be allowed or not. It's a separate decision. Oh, okay. Okay. All right. Well, thank you for clarifying that for me because I was watching those conversations and wondered, you know, kind of whether or not that showed some sort of future direction that all this would go. Okay. All right. Well, this has been a truly fascinating discussion and thank you so much for coming on Unconfirmed.

Thank you for having me, Laura. Thanks so much for joining us today. To learn more about the topics we discussed, be sure to check out the links in the show notes of your podcast player. If you're not yet signed up for my email newsletter, go now to unchainedpodcast.com to get my thoughts on the top crypto stories of the week. And be sure to check out our new channel on YouTube. Unconfirmed is produced by me, Laura Shin, with helpful and fractional recording, Anthony Yoon and Daniel Ness. Thanks for listening.