Block validation logic in Bitcoin Core is surprisingly complex. After more than a decade of engineering towards improving performance, Bitcoin Core has accumulated many caching layers, sub-steps, and optimizations before the node even calls the script interpreter. In the following, I’ll describe in broad strokes what these are, first roughly describing what validation is done in which order (often skipping over some exact details), then explaining why it was implemented in the way it is and the tradeoffs involved. I skip over optimizations that do not affect the architecture in a significant way, like low-level CPU instructions. This is based on my own understanding, which may be wrong, and is definitely biased.

It has been nearly two years since I started working on the Bitcoin Core kernel library - a software library encapsulating the Bitcoin Core validation logic, or all the logic required to determine if a given block extends the current best-work chain. The library purposely does not include any P2P networking, JSON RPC, REST or ZMQ servers, a wallet, additional database indexes, or a user interface. Originally started by Carl Dong, it has been long desired by contributors and users of Bitcoin Core. He originally introduced it as a de-spaghettification of Bitcoin Core’s validation logic into a more distilled, maintainable order that cleanly separates validation from non-validation. The design of its API was left for a later point in time. Building upon this original work, the project is now at a point where this separation is largely complete. It is now later.

TLDR: Security researcher monokh discovered a flaw in the isolation of the transaction logic between coins. It allows coins from one cryptocurrency, e.g. bitcoin, to be spent by the transaction flow of another, e.g. Litecoin. I found two other hardware wallets that are vulnerable to this exploit, Keepkey and Coldcard. To this day, Keepkey has not patched the issue.

TLDR: In this last in a series of three monero unlock_time related posts, I dig into the privacy considerations of current unlock_time use and how it can be improved by either encrypting the field, restricting its content, tweaking ring selection or removing it altogether.

TLDR: Monero, and in general cryptonote based cryptocurrencies, transaction unlock_time values were interpreted with local time, allowing a host of non-critical exploits targeting the integrity of the blockchain. The issue is patched as of monero version 0.17.0.0. No harm towards user funds was found related to the issue.

TLDR: A lack of unlock time verification on the monero hardware wallets could have allowed a compromised host to permanently lock up a user’s XMR after a transaction. Both Trezor and Ledger patched the issue.

TLDR: The Coldcard does a factory reset when an existing PIN is changed to an empty PIN , contrary to Coldcard’s claims that a factory reset is impossible. This can be used to distribute tampered devices without much effort. Coldcard has not patched the issue to date.

Timelocks have been a long-standing fascination of mine, my first blog post even describing the usage of the checklocktimeverify opcode. Though I knew at the time what the rough role of checklocktimeverify was, I did not know how the different fields in a bitcoin transaction actually play together to enforce timelocks. As it turns out, there are a bunch of different things that usually get conflated with each other into this concept of a “timelock”. This is my attempt of disentangling them.

This is a dynamic document and changes as my understanding of these vulnerabilities changes and as new vulnerabilities get discovered

Since this is the first time for me on the reporting end of a disclosure, I decided to write this blog post to document my experiences and help me with formulating future write-ups. Even though the exploits presented here are not particularly intricate, I do consider them serious.

When compiling a static binary on one linux distribution, it is not guaranteed to be compatible with another distribution out of the box. This is even true when compiling statically. For example when I cross-compile monerod for aarch64 on an x86_64 machine running ubuntu 18.04, I get the following error upon running the binary on my debian 9 aarch64 system:

This post describes how to make your local lightning node connect to a remote node. First set up an ssh tunnel between you and your remote and make it listen to bitcoin’s default rpc port:

The following will contain a tutorial on how to create a 1 of 2 multisig address, spend some coins to it, and then transfer them back again to a regular adddress. While you can and should look at the given tx id’s in the block explorer, this recipe is definitely not fool proof. Hopefully a script can do this in the future. It is advisable to attempt this first, with a very small amount of coins, or best on testnet. Either pass in the following commands to the daemon, or to the debug console on the gui client, found in Help -> Debug window -> Console. I will walk through this example with keys I generated, so the values will change, if you try it yourself.

Alice and Bob each create their own keypair. Bob creates the following transaction script: