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 gridcoind, 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.
The following site provides a comprehensive, graphical view on mining and securing a blockchain, that is fun to use: https://anders.com/blockchain/
Alice and Bob each create their own keypair. Bob creates the following transaction script: