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: