Alin Mihai Barbatei - Securing BTCfi

Hello. So, my name is Alen and I'm here to present to you about how Bitcoin Bitcoin's expansion into DeFi brought with it a lot of security abs security assumptions at layered and new trust models. A bit a very quick bit about me. I worked in cyber security as a malware analyst for eight years in B defender. I then went into DeFi and smart contact auditing and over the years I've specialized in Bitcoin L2s mostly stacks going into the other ones and made my own company at one point.

So I'm here in the long run and I will secure as long as I am here. Okay, I'll start off with Bitcoin core assumptions for what we use Bitcoin, but from a security point of view, we need to presume and have some assumptions. We assume that this chain works by a specific trades and rules. I listed here seven assumptions which are more relevant to an interaction with Bitcoin. These are pretty straightforward.

This the first one is that honest majority of hash power. We all know the classical 51% attack where you say that an attacker controls more than 51% of the network and proof of work they can decide it. We're always interacting with Bitcoin presuming that the current or majority are honest. This is a normal assumption. The cryptogate primitives again we're presuming that they will hold but these are like low-level ones.

We're literally presuming that shaw 256 doesn't break or the elliptic curve algorithm doesn't break. We have such assumptions. Now I presenting these because I want to add the following rhetorical question over the years. How many of them do you think have actually been uh broken historically? I mean they're not broken now but over the years they have been broken.

And to answer actually almost all of them especi just the first two they haven't been broken the other ones have at one point in the existence of Bitcoin have been broken in one way or another. We'll go quickly to them. The one that consensus rules are correctly implemented. This is from a code point of view that the node implements the software correctly. This was actually broken in 2018 when a bug allowed uh to in to have double inputs validation which means that you could have minted more bitcoin that you could have that existed.

This was the most severe bug in bitcoin at that time. Also a bit of um side of an information you see here CVE in security we usually define we usually assign uh ID to more relevant bugs called common vulnerabilities and exposures. That's a more of a fancy way to allow the public to know what vulnerability instead of giving it fancy names like heartbleleed or dirty cow or other media and PR designations. So that's just an idea. Now network livveness there have been over 19 denial of service error vulnerabilities in the Bitcoin node software up to today.

That means that at one point at 19 different points the network could have been blocked partially nodes could have been stalled transaction livveness was at risk. Now we're interacting with Bitcoin hoping and expecting it in about 10 minutes give or take a transaction to be mended. That's our assumption and again we have assumptions about everything we're using. The node integrity is that we we're presuming simply that the software that runs it is not malicious and cannot execute malicious code. There were three cases of potential remote code execution the IC's in which one was actually almost confirmed.

You could have executed malicious code on the node software. Again bugs introduced but were fixed and resolved but it did break for a short while the invari and this the what what we are expecting. Coming back to the example of the uh consensus implementation break at the same bug introduced allowed more than 21 million bitcoins to be minted. We know how everyone says that, hey, Bitcoin must has a fine cap. Yes, it does.

But that wasn't implemented correctly at one point. Actually, for two versions, I believe it was a problem. Oh, either way. Now, the last one is a bit interesting. The canonical source of tooth.

We're presuming when it nodes and anything interacting with Bitcoin presumes that Bitcoin is the source of tooth and we look at it and it's okay. whatever we see it is the valid state. But there were two issues of bugs and vulnerabilities that allowed software to see different versions at the same time. So that assumption that what we're looking at is valid would have been different. You had a different output depending on who was watching it.

This is again a critical and a major problem. Imagine an exchange seeing a transaction done but other exchange does do not seeing it. You could have have double spending very interesting bugs just mentioning them. Basically five out of seven. The other two which was honest majority and cryptographic primitives.

Well if you break those you break a lot. Well if you break the cryptographic primitives you bake a lot of the internet. And the honest majority one you kind of need incentive there and no one has an incentive to do that. over overall if we treat the Bitcoin software itself as like an audit report we can this we can see that there were 25 different vulnerabilities and about okay one was critical the 4% yeah 40% in mediums and high and lows these were all the issues over the years another interesting observation here okay bitcoin had issues and they were disclosed But the Bitcoin core team since since everyone is looking at Bitcoin and if you see an issue there, they're going to mass media to to as much as they can. They actually had a quite a bit gap until when they they found the bug, they fixed it and they release and they publicly disclose it like years.

I mean, the only one that was almost instant was the critical, but that was 2018. Up till that point, you have an average over the two years. I mean, if history holds, there could have been bugs now, critical ones that have been fixed, and we'll only hear about them in three years, four years. This is just an thing about assumptions and discussing it. That's an interesting observation from what issues there were in BTC.

DOS denial of service is vastly m the majority of it. Now you may be thinking okay n of service we're blocking nodes at the most we're delaying transactions so that's fine. Well that's not really fine. You can do a lot of things with the denial of service in a network. Depends on maybe you are using it to leverage a g with a different attack.

I'll give you a side quest, not a side, a side story about Litecoin and how a DOS helped attackers do a specific hack. Litecoin is a fork of Bitcoin, a software fork, not a blockchain fork of the as in they took the code in 2011, they added stuff over it. 2024 they added some random meimblewimble extensions. I don't know how they got that name. And in March they were hacked.

That meimblewimble extension added an inflation attack. That means that they could create infinite Litecoin. Okay. They fixed it and it was silently resolved as a white hacker uh white hack operation as in the attacker gave the money back a part of it. Okay.

They fixed it but and APL another again it would is it was hacked again but this time uh it was not a white hack operation and it was a subtlety here because what actually happened was they reused the same logic as in they created a uh malicious block which the correctly patched nodes had an issue with it and they were dosed the unpatched nodes because you cannot really presume that the entire network patched the April one. Let's say there were like 5% of nodes. Those 5% of node became the majority and they allowed the previously fixed influ inflation attack to still continue. So for half an hour, 13 blocks until the devs at uh Litecoin patched the patched. There was almost eight Bitcoin that were offchained to a near intense.

There were some to chain but like 10 Litecoin. This was very interesting as in if the DOSs would have not existed then the correct patched nodes would have not had any issue but it existed the patch note that had a problem and by the time the chain reared hey offchain swaps crosschain swaps they main the money was stolen and the NIA protocol um ecosystem absorbed the loss basically because there is no counter on the Litecoin part. This was an example of issues that simply can appear due to to a doss and I wanted to make this parallel because imagine if it was Bitcoin. Imagine that now you have a version let's say of the inflation bug node that still exists and you find a DOSs for the entire network and use that. You could still do something bad as you can doss parts of the network while using a bug on the other ones.

You can create a lot of issues. You can spun up as a malware out of your own network while you're dossing the your own nodes while you're dossing the other ones. But that's kind of costly. Either way, nodes do DOSs is irrelevant and every bage to every assumptions can be abused. Now, we have discussed about Bitcoin and security assumptions that go into BTCI.

BTCI is a fancy way of saying Bitcoin on DeFi, but you're combining it saying BTCI. Basically using Bitcoin as an asset over the years. I mean, why do we want to do this liquidity? Liquidity is the main problem in any ecosystem today, besides security, of course. And to fix it, we're looking what's the most liquid asset, Bitcoin.

When I was making this presentation, it was $1.6 6 trillion but BTC according to DeFi Lama Llama Aai something around 5.7 billion so we're not even 1% of the entire Bitcoin t market cap being used in DeFi to produce yield to actually help with something so people will try to do this they will invest a lot of money in this and they want to do this and will do this one way or another that means that we need to accept some tail some assumptions and work around them. The BTC BTC stack at this point there are a lot of experiments chains and modes in which people are doing BTCI. I want to go to three major major categories.

the the self existing smart contact layers like stacks which is independent its own ecosystem and all its own consensus but they're anchored to bitcoin they are the zk rollups that use bitvm type technology I'll go into that a bit to have the that availability layer on bitcoin and have cryptographic primitives which allow it to show that the transaction was validated on chain. And another example is Babylon which they're doing novel cryptography with the staking mechanism each their own way. Of course there are other L2s because everyone wants to be the next Ethereum but for Bitcoin. So they're doing their own implementation. These are the majority I mean the majority of research is going into these at this point.

Okay. overview of stacks they're using something there's an independent L L1 considering as an L2 to Bitcoin because they have their own consensus they have their own tokens but they are anchored to Bitcoin as in their transactions the consensus mechanism binds a final output to Bitcoin so you actually need to yo Bitcoin in order to them it's pretty transparent from that point of view they also implement entered their own SB um BTC native rapper which is called SBTC and they're using a 70% threshold for 15 signers. Now from a security point of view what assumptions we have here? We have an assumptions that 11 out of the 15 um signers are trusted. So if they are not trusted we we have a theft.

We also have an indirect assumption that if they're not on line 11 of them, the funds cannot be moved from chain to chain. Again, we're using BTC. So, you need to have some test assumptions. This is one of them. And the point uh proof of transfer, in case you didn't know this, proof of stake, proof of stance, proof of history, proof of liquidity, proof of whatever proof of transfer is not economically viable, may have will appear and no one's going to use the chains.

These are some assumptions on stacks. I want to go to SIA but before it BitVM is one of the most interesting mech one of the interesting mechanism being researched today. Basically they're trying to compute verification on Bitcoin but offchain they're doing as much calculations and cryptography as possible and just doing optimistic verification onchain. They're putting some proofs and someone can challenge it. And the challenging costs in order to challenge a bit VM proof you're going to need in this case for BitV uh for BitVN type two for example you need one gigabyte on Bitcoin which is split into multiple transactions.

So it's not actually feasible. Research has been done into this and has three versions at this point. In BitVM1 had it was more theoretical. It took it required a bit like a month of off-chain calculations. So you can have one onchain validation because you need to do as much as you can offchain and as less as you can onchain very impractical.

Bitvm2 there's actually two chains that have deployed this have deployed and used this mechanism site and bite layer bit layer and but it's kind of costly and the bitvmv3 version something that it uses garbled circuits that's another cryptographic primitives in a way that you can show that you can validate two parties can validate an outcome by the private inputs without showing them. It's an somewhat odd but they found that they can use that and have it onchain on Bitcoin and be implemented as it is with the L1 itself. Remember I'm talking about the L1 itself logic. Okay. So SATA took that implemented it and they have the test abion is very nice.

It's basically one of N. You need only one challenger to be trusted because everyone can put whatever they want but one can should be trusted because he's going to check and if it's false uh then he is incentivized to do that and it invalidates the transaction. They implemented ZK EVM itself. So this is already EVM using the entire assumption tree from Bitcoin to to BitVM. You already have an EVM compatible chain here that has nativeish Bitcoin bridging.

In this case, we're again assumptions. We're assumptions. The ZK logic works. The verify itself is correct. with the challenger aliveness.

I mean I am incentivized by the fee to actually do this. There are again assumptions. The Babylon BTC staking logic itself. They're trying to the funds are as a as a staker are staked on Bitcoin using tap time locks. So technically they're still somewhat yours.

you're deploying on for each of your staking. And they're using a different another novelty algorithm that again uses as little of a footprint on chain on the Bitcoin chain itself to ensure that uh the transaction of bridging the pegging out or in is valid. In this case, they also added a slashing mechanism which again brings again um brings more assumptions. We assume that their novel algorithm is okay. We assume that the slashing is incentivized enough.

The they're calling operators finality providers. Either the operators, their challengers, the whatever third party entities probably something working as whoever has a data center whatever the idea they're presuming someone they're naming it as such. Of course the consensus should work. If you look at it at all of them, we see something interesting that uh I try to put them in such a way that from left to right on left we pres we have more trust in individual entities and on right we have more trust in the technology. So basically on stacks we trust the bridging of 15 signers honesty we on site we trust that the BVM implementation goes further on Babylon we test that their logic but funds still remain there we have how trust is how who holds the BTC a multisig each of the uh challenger gives the multisigs worst cases and how you are disputing it.

General entities and institutions try to not not focus try to reduce human entities as much as possible. Basically the idea is going to technology as much as possible and not to individual entities. But there's also here I have no idea which one of these technology will actually be the best. I know they're working on all of them and each of them has its own assumptions which bridge someone who uses it institutions or banks or whatever and they need to accept their own tradeoffs again as an overview that I said that we're talking about how would you would bridge to Bitcoin to Ethereum or EVM ecosystems we have a layered test system. We are trusting that Bitcoin itself and its assumptions hold.

I showed that some assumptions did not hold historically. Okay, now they're all held holding up. We are trusting that the bridge pegging mechanism exists. We're touching that the consensus mechanism exists. We testing that all of these which stack one upon the other and up until the application layer that they are all correctly implemented.

Now we as security researchers need to ensure all of these are actually safe. We ensure we try to ensure that nothing breaks because anything that breaks anywhere compounds. And the more we are up in the stack, the more assumptions we have and the more space to hack, the more attack surface there is. Guess this is the key takeaways as in okay Bitcoin has had bugs over the years. It's not a bug free or not a bug free chain and there probably still will be some bugs at one point relevant or not bugs we remain to see.

All bugs compound upwards. So a bug in the base layer Bitcoin itself will reach the bridge and the EVM implementation itself. A bug directly in the EVM implementation that uses the bridge mechanism may only lose their their compounding. You cannot bypass it. The by stacking layers we stack more assumptions.

We stack more attack surface. I mentioned this before. BitVM is one of the more more interesting and leading technology at least it's very in researched at this point I expect we'll see something with the garble circuits uh valid implementation soon for now I don't know that there is anyone that have implemented on that that big attack surface always audit always be secure Okay.