Exploiting BTC

Last year’s btc++ hacking edition (2025) in Brazil was my first-ever Bitcoin event. I took part in it after the Bitcoin Dev Launchpad promoted by Vinteum (an awesome program, by the way). In it, I also took part in my first-ever hackathon and learned a bit more about how the Bitcoin ecosystem works. Fast forward 1 year, and I am now at my third Bitcoin event: btc++ Exploit edition. This year’s theme fits perfectly with my current focus as a QA Engineer, so I wanted to learn as much as I could from different topics that I usually do or do not have been in touch with. The first presentation I listened to was about Differential Fuzzing. In it, Erick Cestari explained how his work as a maintainer at BitcoinFuzz has been helping projects become more robust by the use of fuzzing, more specifically about differential fuzzing, which is taking two implementations of the same protocol, running a fuzz target in a specific area of code, and checking the behavior of both implementations by comparing the results. It could be comparing a simple sum implementation, where 1 + 1 is supposed to be equal to 2. So if implementation A evaluates to 2 and implementation B evaluates to, let’s say, 1.999999, we have a difference in implementation. Then Erick would compare both solutions and check where they differ. His and Bruno Garcia’s work has been crucial in finding bugs throughout the Bitcoin ecosystem.

Then I listened to Breno Brito talk on Agentic Engineering, finally understanding why LLMs are so bad at counting the R’s in “strawberry” (they don’t count) or performing math. His talk shed some light on how a developer can take advantage of the tools at his disposal. There is a bit of art to use an LLM tool in a good way, and I couldn’t help but make a direct correlation between his talk and the last series of posts written by Fabio Akita on how to correctly use LLMs on coding. Spoiler: it is not by typing “I want a full bitcoin node written entirely in Rust, make no mistakes, go go go”. To have success at complex tasks, one possible approach is to: Plan, Develop, Assert. “AI’s” have what is called a context window, which is basically how much it can process before it gets dumb. If you don’t manage this well, a lot of resources will be lost instead of having productive work. It is good to make the agent write down the plan, then YOU REVIEW IT, make it implement bit by bit (think of a clean code with TDD approach), and later compare the implementation with the original plan. It will often figure out that it missed a rule or something in the line of that. After this, YOU SHOULD REVIEW the code. Remember, you are signing the commits (or should be signing it at least).

In the afternoon, I went to Max Hillenbrand’s talk on an overview of the last three decades’ exploits or vulnerabilities in security. The main takeaway is that the government will usually try to insert backdoors, and they will be a foot gun because if there is a backdoor, this means another adversary can exploit it as well. One famous case is the “U.S. Wiretap Systems” (CALEA - 1994) exploited by China. Basically, the USA has put a law mandating all cellular companies to install a backdoor so authorities could intercept calls. The irony became that the very same backdoor used to assure the safety of USA citizens was being used by China. Such info only surfaced in 2024, but who knows for how long China has been spying on USA citizens. Then, Max proceeded to show how even secure messaging apps such as Signal could have flaws that would leak information (even plain text messages) or metadata. He is currently working on implementing Message Layer Security (RFC 9420) on Nostr, aiming at providing scalable encryption in peer-to-peer and group messages. His talk on PGP and encryption made me think of Jao Noctus’s talk on PGP and privacy as a right. Also, Noctus had a talk with Nifty about his Capture the Bitcoin challenge and different security issues faced by bitcoiners and Bitcoin in general.

Later, I went to Mike Tolkachev’s workshop on how hardware wallets could have flaws. Basically, he provided us with “toy-wallets” with bugs introduced with the purpose of showing common mistakes people make that could lead a device to be open to exploit. It was an awesome workshop, and I spent the rest of the day (and the next day) figuring out how to pwn the device. There were four main vulnerabilities:

1. Timing Side-Channel (used to guess PIN)
2. Buffer Over-Read (Memory Disclosure for function handlers addresses)
3. Stack Buffer Overflow (Return Address Hijack)
4. Return-Oriented Programming (ROP Chain)

Each one of them urged me to go on and figure out how to break it. It was my first time even trying these, and I was not familiar with many things such as reading Assembly (or Disassembly) snippets. Needless to say, it took me way more time than a regular person familiar with such things would take. But it was a great exercise, and I learned a few things in a hands-on experience. Thanks, Mike, for the patience in explaining things and great work on the workshop. It was really nice getting hands-on.

At the end of the day, we got together for one of the biggest Bitdevs Brazil has ever seen (with about 80+ people in it). I guess devs haven’t realized Bitcoin is dead (irony intended).

Friday started with people getting together for the hackathon (which began in the previous day). In the meantime, as I did not take part in this year’s hackathon, I was trying to hack the toy wallet and listen to Pinsdorf talk about 12 Real-World Failure Cases in Lightning. It was an explanation of Matt Morehouse’s discoveries of security flaws in that Layer 2. Some of them are easy to explore, but others might take a high level of expertise to deploy. I am glad to hear no one (AFAIK) has exploited them up to date. As for the hackathon projects, they were quite promising as most of them were tools to handle security (such as an AI-driven security audit tool) or bugs found in real projects.

Friday closed in with a debate on “Are Rollups Essential to Bitcoin?”. Jose Storopolli and Matthew Vuk got together for an Oxford-style debate. Jose works at Alpen, a company working to provide BitVM (similar to EVM) on Bitcoin, and Matthew works at Second, building Ark. Both projects are not antagonists, but the debate was not about their products; it was about Bitcoin needing Rollups. In the end, both had (as expected) diverging opinions. Jose defended the idea that Bitcoin is more than a p2p payment system, which should benefit from having a trust-minimized way of making Turing-complete computation backed by Bitcoin PoW for usage such as Bitcoin-backed loans and stable coins. Matthew, on the other hand, argued like a true maximalist, defending Bitcoin as only a p2p electronic, decentralized cash system, thus urging developers and the community to focus their efforts on layer 2 solutions such as Ark and Lightning. The debate finished with a win by Matthew (audience votes), and then a few people (me included) went to a whiteboard session with Jose. Congratulations, Matthew, for winning the debate. Jose is a great guy and an amazing professional. I have great consideration for his work, and every time he is going to teach something, I want to stick around. This time was no different. At the whiteboard session, Jose went through ZK- SNARKs, BitVM (1, 2, and 3), GLOCKS, BABE, PIPES, and last but not least, how it all fits together in the context of Bitcoin. BitVM was the theme of my first-ever presentation on Bitcoin, which I gave during my residence at BDL by Vinteum. So I have a fond curiosity for the theme. It seems so out of reach, yet, having someone like Jose explaining makes it seem like I can understand. Someday I will still grab my cryptography books and learn it, but as for now, I advise anyone who wants to know a bit more about the theme to check his website. Fun fact: this website is written in Rust (Dioxus) and aims at not having JavaScript due to Jose’s influence on my journey as a developer.

Saturday morning kick-off with Warnet on Lightning by Chaincode’s Zipnik as a host. I did not take part in it. I wanted to listen to Jose’s talk on BitVM3 intuitions. Here is a quick summary LLM made from my notes: “The BitVM bridge is a federation where only one honest member out of M cosigners is needed to guarantee that no one can steal deposits. BitVM2's fraud proof mechanism required about 6 MB on-chain, but BitVM3 slashes that to roughly 8.2 kB by using conditional disclosure of secrets: an operator posts a proof on-chain, and if a challenger finds it incorrect, a secret is revealed—if the proof is valid, the challenger learns nothing. Under the hood, this works through garbled circuits, an encryption technique developed by Yao (1986), where encrypted gates are composed so that input labels unlock the corresponding outputs, ultimately enabling an off-chain SNARK verifier and Turing-complete computation. Several garbled circuit schemes have since emerged—Glock (Eagen, 2025) handles circuits of hundreds of megabytes but relies on permissioned challenging and exotic cryptographic assumptions; Argo (Eagen, 2026) brings permissionless challenging with 32 MB circuits at a slightly larger on-chain cost; and Babe (Babylon, 2026) supports 50+ MB circuits but stays permissioned. In practice, a user deposits BTC into an N-of-N presigned bridge address; in the happy path, operators process the withdrawal directly, but if something goes wrong, a kick-off transaction triggers the fraud proof flow, allowing the funds to be burned or redirected. To push all of this forward, a BitVM Alliance of companies and foundations is working toward a canonical BitVM primitive, with Alpen using Glock paired with Groth16 verification instead of DM pairing.”

As I write this paragraph, I am listening to Stu’s talk on Bridge pwned. Quite a fun guy. “Bridges are used to cross a river” (Wikipedia citation). Orbit bridge hack possible due to missing checks on signatures and withdraw amounts; HECO bridge hack (87M); NOMAD bridge (180M) would enable copying, pasting the tx, and replacing the output address to a personal address; SUI bridge (223M) library-level vulnerability by overflow. Wormhole (326M) bridge withdrawal bypass; Binance (586M); Poly Network (42B) attacker brute-forced a 32-bit ID that allowed them to replace the bridge signers’ public keys with theirs. Ronin (624M) took 7 days to notice it. Ronin was hacked by phishing attack, getting 4 keys, and found a vulnerability in a 5th node by an update allowing them to sign in behalf of DOA. The main takeaway from this talk is there are several vulnerabilities on bridges, and moving forward to Bitcoin bridges, the developers and the community must be humble and understand the risks of implementing them or using them.

Mutation testing is a hot topic right now. Bruno Garcia went on with a talk about this, highlighting how mutation testing can be integrated with fuzzing to get a quality analysis on the fuzz targets. The idea is that even though most mutants are behavioral and will not necessarily crash or create a memory bug, a good fuzz target will eventually catch it. For example, it is good practice to use a roundtrip strategy when creating deserialization or decoding targets. A roundtrip means that after you deserialize the input, you serialize it and compare it to the original input.

All in all, this year’s btc++ in Brazil was a honeypot for those like me who are interested in this topic. Thanks to all of the talkers, presenters, organizers, staff, and Nifty for such an awesome event. Big shout out to Vinteum, Lucas, and Edil for the BDL program and Liberia de Satoshi for the B4OS.