Uneasy Money: Is OpenAI Training on Your Private Chats to Win the AI Race?

Kain Warwick (0:00)

The way to think about this is like, it's like two tiger moms, right, that have really smart kids, and they are in a pitch battle to prove that their child is smarter. Think about what those ladies would do. Like, that's what's happening right now, right? They're like, look at what my son did. He's like solved a Millennium Prize, right? Hey everyone, I'm Kain Warwick, and welcome to Uneasy Money. That's what happens on Unchained, never stays.

Before we begin, here's a word from the sponsors that make this show awesome.

Taylor Monahan (0:36)

This episode is brought to you by 1inch Aqua, the shared liquidity layer from 1inch. Back multiple liquidity positions with one wallet balance, and keep your tokens in your wallet until a swap fills.

Kain Warwick (0:48)

See how it works at 1inch.com/aqua.

All right. I'm here with my co-host, Taylor Monahan, Security Expert, and we have two very special guests today. Alex Thorn, Head of Firmwide Research at Galaxy Digital, and Jon, Head of Strategy at Venice, and also co-founder of ShapeShift. Welcome, guys. Hi there. Thanks. All right. Let's kick it off. The first segment of the week is Liquid loses 95%, 93%, 98%, somewhere in the 90s percent of its BTC. A consensus bug in Elements, something I had not heard of until this week, allowed someone to mint LBTC out of nothing and peg it, and basically redeem it, which Tay, we can talk about this as well. You can walk us through the process here.

Because my expectation with these pegged assets, wrapped assets, is there's usually some set of redeemer people who are allowed to do redemptions, right? You can't just turn up and be like, oh, hey, I've got 3,000 BTC. Also, if that happens, the older BTC, can I redeem it? What's the deal? How did that happen?

Taylor Monahan (2:18)

I mean, there's ways to make it's basically, it's basically a bridge hack in the most simple sense of it. Because it's not EVM, the words that people are using and the exact mechanism that people are using is different than what we're usually familiar with. However, if you just zoom out and look at it generally, it's basically-

Kain Warwick (2:45)

Can you translate it into a theory for me so that I understand what's going on here?

Taylor Monahan (2:51)

I mean, Alex can probably do a better job, but basically assets that shouldn't have existed were spoofed into existing. That was the first half, bad half. Then the second half is that then they were able to bridge those assets to real Bitcoin and get real Bitcoin out.

That's the second half. That's also bad. But I think in Ethereum land, we typically say technically that code was valid, and did its job as the code was meant to do.

Alex Thorn (3:29)

The second half was fine.

Kain Warwick (3:30)

Someone turned up, they had a valid asset that the system recognized.

Taylor Monahan (3:36)

And it just happened to be all of the Bitcoin that the system held.

Kain Warwick (3:41)

Yeah, Alex, let's break it down for us.

Alex Thorn (3:46)

I mean, Tay is right. It is kind of a classic bridge hack in the attack purpose and execution. It is effectively fooling the bridge into allowing the underlying Bitcoin that collateralizes, effectively tokenize Bitcoin on this liquid side chain to be issued there. The way I understand it is like, so Elements is the code, is the side chain code, right? And it's a federated side chain. These withdrawals and other, I think, consensus actions there require 11 of 15 of these federated nodes. And that's like exchanges, this is like a closed validator set.

And they have a confidential transactions feature, which is like a, you know, ZK-ish, we'll say, right? But where you can send and receive assets among yourself on the side chain without revealing the amounts or other features of the transaction. And to do that, you have to submit a range proof and a balance proof, basically, that the nodes can use to verify that the, you're not create, that the in and out on the transaction equal each other and that you're not, there's not a negative number.

But I guess my understanding is it's computationally intensive to calculate the range proof. So if like an identical transaction were submitted, the one transaction is submitted and the nodes calculate that proof, they cache it, they put it in their cache and in their memory. And so these attackers submitted like a 1LBTC in, 1LBTC out transaction and the proof was cached. And then the bug itself was their ability to create a collision to insert a 1LBTC in, 4,000 LBTC out transaction and have it have the same like key, like hash basically as the prior proof. And because the nodes had already seen it, they said, oh, we don't have to commute this again. We know it's good, approved it. Now they have 4,000 LBTC on on liquid. And then they submit that to side swap one of the federation members that allows the pegging out back into the main Bitcoin network. And the funny. Yeah. But you asked the beginning.