The Waiting Game: The Mempool and Transaction Fees


Have you ever sent a Bitcoin transaction, only to panic and realize the money hasn’t shown up in the receiver’s wallet? Maybe you were sending from a mobile phone wallet to a hardware wallet or exchange, and became afraid that your money was lost! Don’t fret, you didn’t lose any money at all. Your transaction is simply stuck somewhere called the mempool, waiting for the confirmation. Let’s discuss what the mempool is, and how protocol rules effect transaction fees and confirmation times.

The Life of a Transaction

How do Transactions Get Processed?

In order to understand some of the issues surrounding transactions, let’s first understand how they are actually processed. When you use your cryptocurrency wallet to create a transaction (send money to another wallet), your wallet signs and broadcasts that transaction out to the network.

Your transaction is flooded out to all of the nodes (including miners) on that network. But they don’t immediately accept the transaction as valid, it must first be included in a block produced by a miner. You can think of a block as a “batch processing” of transactions. So, when a transaction is waiting to be included in the block, it is included in a data structure called the mempool. Each node constructs its own mempool based on the transactions it receives from other nodes, but for the most part each nodes mempool will have roughly the same set of unconfirmed transfers.

The Mempool and Block Construction

From this mempool, mining nodes put together a potential block of “batch processed” transactions while they work on the network’s proof-of-work problem that will finalize the block. The miner that solves this problem gets rewarded with new coins, as well as all the transaction fees from this block.

But before we can understand fees, we need to understand the constraints networks put on the processing of new blocks. First, blocks often have size limits. Bitcoin limits the size of a block to 4 weight units, a special calculation based on segregated witness rules. Historically, this limit was 1 megabyte, referring to the actual size of the transaction data. Many still (somewhat erroneously) refer to Bitcoin’s block size limit this way.

There’s also a rough block time. Bitcoin’s proof-of-work problem is adjusted so that new blocks are processed roughly every 10 minutes. Most Bitcoin forks such as Bitcoin Cash and Bitcoin SV follow this same time constraint.

Constraints’ Effect on Fees

Now that we understand the limits on transaction processing, it’s fairly intuitive to understand the fee market that emerges. On some networks like Bitcoin, there are more transactions in the mempool than can be processed in one block! That means we have a supply and demand problem!

If there is more transactions than can be processed in one block, miners will construct a block with the highest fee transactions – since that means they get the highest reward. Therefore, the more transactions are waiting in the mempool (a backlog), the higher fees will be on the network on average. Most user’s don’t want to wait, so they will pay a higher fee to have their transaction processed quickly.

Now, this is not the case for every network. There are ways to adjust these constraints so the mempool is usually cleared with every block. Some networks, such as Litecoin, use a faster block time. LTC processes blocks roughly every 2.5 minutes. Since blocks are processed faster, the mempool clears out faster. Some other networks, such as Bitcoin Cash, have a higher block size limit. BCH will process blocks much larger than 1MB, meaning that the mempool is always cleared out every 10 minutes.

With these adjustments, networks aim to keep fees very low with some tradeoffs. Some Bitcoin experts claim that these limits prevent centralization and keep full nodes affordable, while others (including myself) disagree with this premise. As well, faster block times can cause problems with “orphaned blocks”, blocks that are valid but are not included in the chain due to network lag (another miner solves the same block, which gets accepted first and propagated in a “race” scenario).

Transaction Troubles? Don’t Worry!

Now that we understand the mempool and transaction fees, you can see that a long-outstanding transaction does not mean you lost funds! It simply means your fee was too low for a clogged-up network. You will have to wait, but your money is not lost. If it takes a very long time for the network to clear, your transaction may be dropped from the mempool entirely. In that case, your funds are safely back in your wallet. Alternatively, some Bitcoin wallets also allow something called “Replace by Fee”, where you can rebroadcast a transaction with a higher fee to help speed things up. And finally, if you want fast transactions and low fees all the time, another cryptocurrency may fit your use cases better. Bitcoin Cash, Litecoin, and DigiByte are some currencies that I use for fast, low fees transfers. It’s up to you and your needs!

Indestructible Data: How Arbitrary Data is Added to the Blockchain


The blockchain is a very powerful tool – it’s a distributed, immutable database of all the transactions that have ever occurred on a cryptocurrency network. When you transact on Bitcoin, for example, that transfer of value is recorded on the blockchain forever. It cannot be modified or changed after just a few confirmations (blocks added on top of that block) from miners.

But it’s not just raw transaction data that can be added to blockchains. Many of the most popular allow arbitrary data to be added to chains. We’ll talk a bit about how data is added to Bitcoin and Bitcoin forks in particular.

Adding to the Database

Understanding Transaction Script Basics

When you transfer value from one party to another on the chain, there’s not one hard-coded transaction type. In reality, Bitcoin transactions are programmable, allowing the use of a small scripting language appropriately called Script. Here’s what you need to know about Bitcoin scripts: the end goal is to end up with a value of true on the Script stack, after the script finishes execution. If the end value of the program is true, then the transaction is considered valid.

For example, a typical script looks like this:

<Signature> <Public Key> OP_DUP OP_HASH160 <Public Key Hash> OP_EQUALVERIFY OP_CHECKSIG

This is called a “Pay to Public Key” transaction, and here the script evaluates to true as long as the spender provides a valid signature from their private key. This script is built from the original locking script (OP_DUP onward) on the UTXO at the spender’s address , concatenated to the unlocking script (sig and pubkey) created by the spender.

Data Scripts with OP_RETURN

So what does that have to do with adding data to the blockchain? Well, it turns out scripts have a great available operator called OP_RETURN. This operator simply marks the transaction as provably unspendable immediately! It is still considered a valid transaction.

And after the OP_RETURN, there is room leftover for arbitrary data. So when the transaction is included in the chain, the OP_RETURN allows the transaction to be valid, and the other data gets recorded on the blockchain!

For example, I could create a transaction with the data:

OP_RETURN chaintuts teaches bitcoin!

to forever record on the blockchain my enjoyment of teaching and explaining.

Now the amount of data one can store is not unlimited, for economic and scaling reasons. It would not be feasible for the chain to store users’ files and that sort of thing. For this reason Bitcoin BTC limits OP_RETURN transaction data to a size of 40 bytes. BCH allows 220 bytes, and BSV allows 100,000 bytes.

OP_RETURN Data Forever, and Cool Use Cases

Now it might be fun to record my love of teaching on chain, but it’s not really that useful. The amazing thing about OP_RETURN is the ability to built decentralized applications on top of Bitcoin. The Bitcoin Cash chain has applications like, where users can post on a “decentralized Twitter” hosted on the chain. BCH also uses OP_RETURN scripts for tokenization, using the SLP standard.

Although the amount of data is limited for economic and scaling reasons, there are tons of possibilities for this type of decentralized data storage, so long as it is used within reason. Imagine the Bitcoin apps that can be built!

Prototyping the Blockchain Lawnmower (Code Companion #3)


In my recent tutorial on tokenization, I showed a possible future where we might trade assets like homes, cars or even lawnmowers on the blockchain. I built a fun prototype to demonstrate this concept – using a Bitcoin Cash token, a Raspberry Pi, and my trusty lawn tractor! This tutorial is a technical look at how I developed that prototype, and how more advanced versions might be built.

Building the Blockchain Mower

Bitcoin Cash SLP Tokens

The first step in this process was to create a non-fungible token on a real blockchain that can represent my tradeable lawn tractor. For this, I felt the Bitcoin Cash blockchain would be the way to go. BCH offers a token standard called SLP (Simple Ledger Protocol) for both fungible and non fungible tokens. Using the Electron Cash SLP wallet, I issued a new token called chaintuts_bmower. This was simple through the wallet’s interface – I simply needed a little bit of BCH in the wallet for the transaction fees. SLP tokens are created using OP_RETURN transactions, which allow placing arbitrary data on the chain.

Issuing an SLP token with an OP_RETURN transaction

Now instead of using the full non-fungible token standard, I simply issued a token with a cap of 1 that is non divisible. So there’s only ever one mower token representing my real-world mower that can be traded around on SLP addresses. If you had a full fleet of mowers to track, you’d have to use a more advanced issuing standard.

Digital Signatures with Electron Cash

Now that I had a token at an address I owned, I needed to create the code that would prove and validate ownership of the asset. We have a token at a BCH SLP address, meaning that the asset is owned at a public key. The address owner has a private key for that address that proves ownership of the asset. So, the way that we can have a system where a starting mechanism validates the rightful owner of that asset, we can use a challenge-response mechanism based on digital signatures.

The asset is owned by a public key on the blockchain. That address has a private key. The starter knows the public key, but can’t know the owner’s private key for obvious security reasons. So, the starter module will request a digital signature from the owner that proves they have the private key. If the signature is valid, that means they are indeed the rightful owner of the asset!

Now how did I implement the code to do this? I went with the trusty code of Electron Cash SLP to help me generate and validate signatures. I trimmed down the library code as much as possible to allow me to import the modules I need directly in Python, rather than calling Electron Cash’s command line calls directly. This makes the code much faster and cleaner.

The client code for this prototype is a simple Python script that runs on a USB drive. This excerpt shows the signature generation:

# Fulfill the signing request using the owning key
def sign_request_electron(owning_address, message):

    signature = ""

    # First, fetch and decode the WIF key
    privkey_wif = load_privkey_file()
    _, privkey, compressed = deserialize_privkey(privkey_wif)
    ec_key = regenerate_key(privkey)

    # Create an EC Key instance and sign the message
    signature = ec_key.sign_message(message, compressed)
    signature = base64.b64encode(signature)

    return signature

On the starting module end, the signature is requested and verified:

# The driver function that generates a signing request, sends it, and verifies the result
def generate_and_verify():

    asset_id = owner.load_assetid()
    owning_address = owner.load_owner()
    timestamp = time.time()

    req_string = generate_message_request(asset_id, owning_address, timestamp)
    print(f"Generated signing request for\nAsset ID: {asset_id}\nOwned by: {owning_address}\nTimestamp: {timestamp}\nSigning request message: {req_string}")

    signature = send_signing_request(owning_address, req_string)
    print(f"Signature returned by device: {signature}")
    verified = verify_message(owning_address, base64.b64decode(signature), req_string.encode("utf-8"))
    if verified:
        print(f"Signature successfully verified! Asset is owned by {owning_address}")
        print("Signature is invalid. Cannot prove asset ownership")
    return verified

Actually Starting The Mower

This was the trickiest part…figuring out how to electronically control my lawn tractor and bypass the ignition switch needed much more thought and work. At first I thought that I might try to touch two bypass wires together using a solenoid, but this seemed a bit of an “unclean” solution. Then, I learned about the concept of relays!

A relay is an electronically controlled switch. On one end, small wires connect to the Raspberry Pi. On the other circuit, you can open and close a circuit. I connected that circuit from the lawn tractor’s battery to the starter solenoid signal terminal.

So, when the signature is verified by the owner from their USB “wallet”, I had the code light up a green LED indicating the push-start mechanism is live. Then, the user can press a button to activate the relay, closing the starter circuit and turning over the mower!

Breadboard with indicator green LED and push button. Private keys, push to start!

The Blockchain Mower Prototype – Lots of Parts and Fun!

This project was a blast to build! There’s lots of details, but the general idea is fairly straightforward. A token represents a real world asset on the blockchain. This asset has an address (public key). The user’s wallet can prove ownership of the private key for that asset with a digital signature. If the signature is valid, the “starter module” knows you’re the rightful owner, and will start up for you!

In the future, this can apply to more interesting projects than just a lawn tractor. This is a fun prototype, but the real use cases are with assets we currently title and trade through government agencies. Imagine trading your home on the blockchain, with your front door unlocking through cryptography. Or imagine selling your car as a token, and tapping your phone wallet to start it! The possibilities are exciting.

Hands Off My Keys! The Basics of Offline Wallets


In the cryptocurrency world, ownership of your money is controlled by cryptographic private keys. These keys are used for deriving your receiving addresses and ultimately for spending funds. For obvious reasons, secure storage of these keys is absolutely critical for any Bitcoin user, as anyone with the keys can control the funds at that address.

There’s varying levels of key ownership and storage, and today we’re going to talk about one of the most secure – offline wallets.

The What & Why of Offline Storage

How is Offline Storage Possible?

One of the interesting properties of cryptocurrencies is the ability to store funds offline in the first place. Bitcoin is digital cash after all, built on a peer-to-peer network. How can you store internet money without the internet?

It’s important to understand what Bitcoin actually is fundamentally, and a bit of how transactions work. When you operate a Bitcoin wallet, you don’t actually store bitcoin on the wallet. What you really store is private keys that unlock bitcoin. When you create a wallet, your wallet generates private keys. Those keys are used to generate your receiving addresses.

So, when someone sends you some Bitcoin, the blockchain stores a record saying that you now own some coins at that address. The blockchain is distributed around the world over the peer-to-peer bitcoin network, but the keys that unlock those coins for spending are stored in the wallet. When you go to spend that bitcoin at a later time, your wallet’s keys sign a new transaction that says that the receiver now owns those coins.

Based on this system, it turns out that a user doesn’t have to be online to receive some bitcoin at an address. If you generate a private key and its address totally offline, someone can send bitcoin to that address over the network without the wallet (keystore) having any internet connection at all. You only need to be online to spend the coins later, in order to sign and broadcast that transaction.

What are Offline Wallets?

Hence, the concept of offline wallets. It’s possible to generate a private key completely offline, generate the associated address, and send funds to that address without this wallet having any connection at all. It’s as simple as copying the generated offline address and giving it to the person that wants to send you Bitcoin (or copying it into your online wallet to send some savings offline).

So what do these wallets look like exactly? Well, there’s two common types of offline wallets, both serving the same general purpose: there’s paper wallets and hardware wallets.

A paper wallet is a simple keypair, generated offline and printed out on paper or another medium for long term storage. A paper wallet doesn’t have to be paper either, it could be a keypair engraved in a metal coin or metal wallet like the Coinstack. You could make a paper wallet by writing the key in icing on a cookie cake, although I wouldn’t advise it – longevity is important and I’d be sure to eat that cake if it was me…

Paper wallets are simple, and fairly trivial to generate. There are several programs that one can download and run offline, and connect to their hard-wired printer. They do have several pitfalls though – longevity and reuse issues. First, it’s important that the medium be preserved. Paper can be stained and ink ruined, so paper should be laminated and stored in a fireproof location. Metal wallets are better for this. As well, the address must only be used once and funds completely spent. Many users have lost funds by misunderstanding change addresses, thinking that they could spend small amounts from a paper wallet key. If you’re going to use a paper wallet, you must import all the funds to an online wallet at once and send the change back to a new address. For these reasons, paper wallets have fallen out of favor.

The latest innovations are with hardware wallets, electronic devices that generate keys/addresses, and also sign transactions. These are small USB devices that generate keys from a single seed phrase, and also allow you to plug the device into a computer for signing and broadcasting transactions. Wallets such as KeepKey, Trezor, and Ledger are popular solutions. These devices will give you a seed phrase you should securely back up (also offline), and offer increased usability and security over pure paper-wallet keypair solutions.

These devices are engineered first and foremost for security. Even when they’re plugged into a PC for transaction signing, they communicate with a limited protocol to the PC. They will only allow the transmission of data like signed transactions, and nothing else. So when you plug your hardware wallet into a PC to send some bitcoin, no virus or hacker can access the keys the way they could with an online wallet or full-filesystem wallet stored on a hard drive. The hardware wallet device simply won’t allow it.

Why Offline Wallets?

So why do this in the first place? Well again, it’s critical that private keys be kept safe. Anyone that finds or steals your private keys is now technically the owner of your crypto. So much like other data on your computer, keys are vulnerable to theft and corruption.

Malware can target online computers and mobile phones more easily, because malicious websites and network connections can drop viruses on the device fairly easily. As well, the network connection allows this malware to send the keys back to the thieft! Not only that, but things happen to computers and phones more often than they happen to special devices and metal/paper wallets kept in a safe. If you drop your phone in the toilet or your hard drive dies without a backup, you’ve lost your coins.

Offline solutions are the most secure because they provide an “airgap” between the keys and any prying eyes. A non-networked hardware wallet or metal wallet can’t be hacked over a network – because they’re not connected to one. For most of us, an offline device in a safe at our home or bank is much harder to steal, and much less of a target, than our online devices. This makes offline wallets by far the safest for long-term storage of cryptocurrency private keys.

Secure Long-Term Storage with Offline Wallets

Ultimately – your keys, your coins. By using offline wallet solutions, you can’t prevent malicious actors from gaining access to the private keys that prove ownership of your crypto funds. Online wallets like mobile wallets and full nodes are totally fine for day-to-day spending, and you should use them for that. You don’t want to have to import a paper wallet for every Bitcoin purchase. But for long-term safe keeping, offline storage provides a safe airgap between your keys and the dark parts of the internet. So if you’d like to save some of your coins for the long term, get a hardware wallet and keep those keys away from the bad guys!

The Blockchain Lawnmower! A Tokenization Tutorial


Several years ago during my early journey into the Bitcoin space, I heard Andreas Antonopoulos discuss the idea of tokenization on Joe Rogan’s podcast. He was imagining a future in which we no longer trade car titles or mortgage deeds through government agencies. Instead, we would represent those assets as tokens on a blockchain.

I was inspired by this discussion, and a friend from our local blockchain meetup that encouraged me to pursue this concept further. So I built a prototype of a “tokenized” lawnmower in order to teach this concept!

To understand what a tokenized future might look like, we need to discuss a few technical components. Let’s learn about the concept of non-fungible tokens, digital signatures, and then take a look at how this lawnmower prototype works!

Token Types, Proof-of-Keys, and a Prototype

Non-Fungible Tokens

First, in order to understand tokenizing real-world assets, we must understand the different types of digital tokens. There are “fungible” and “non-fungible” token types. Normal cryptocurrencies such as Bitcoin, Ethereum, etc. are generally considered “fungible” – this means that no one coin has different value than another. This is similar to US dollar bills – each dollar bill in your wallet is functionally no different than another. Each dollar bill represents an interchangeable one dollar in value.

But tokens that represent specific assets are called “non-fungible”. The popular “Crypto Kitties” tokens are an example of this. Each token represents a unique asset – the crypto kitty. Applying this to real-world tokenization, a non-fungible token can be used to represent a unique asset like a home or a car. Each car is unique, each home is unique – and therefore the tokens must be distinguishable from one another in this manner.

Digital Signatures

Next, we’ll need to understand digital signatures to build our future world of tokenization. If you’ve used a cryptocurrency like Bitcoin before, you know that coins are sent to and from various addresses. Addresses are derived using what’s called public key cryptography. A random “private key” is generated. Next, an elliptic curve algorithm is used to derive a “public key”. Finally, some further hashing and encoding is done to create the final address.

This process is one way – you cannot go back from the public key to the private key. However, the magic of public key cryptography is the ability to prove that one owns the private key for a particular public key by “signing” a message. Anyone with the signature, message, and public key can verify that this person owns the private key without that key having to be revealed.

This is a critical part of our tokenized future – users can prove they own an asset at a public key (address) by signing with their private key. However, they never have to trade or reveal that secret key at all!

A Prototype – The Blockchain Lawnmower

Based on these concepts, I built a prototype “tokenized asset” using a Raspberry Pi, a USB drive, and my trusty lawn tractor!

Here’s how this prototype works:

  • First, I created a non-fungible token to represent the tractor on the Bitcoin Cash blockchain, using the SLP standard
  • The Raspberry Pi serves as a “starter module”, which fetches the current owning address from the blockchain and stores it for offline use
  • The “starter module” sends a message to the user’s crypto wallet – in this case, a USB drive with the private key and some Python code on it. The message is based on the asset ID, address, and timestamp
  • The wallet (USB key) signs the message using the private key
  • The starter module verifies the signature is valid – meaning the wallet holder is the rightful owner of the mower
  • The mower can then be started using a push-button

The Blockchain Mower and a Tokenized World

This mower represents a proof-of-concept for a tokenized future. I don’t think it’s likely we’ll need to trade mower titles on the blockchain in the future, but it certainly shows the idea! We could some day see car titles, mortgage deeds, and more traded on blockchains instead of through government agencies. And instead of trading keys, we’ll simply use our own private crypto wallets to unlock and start our assets. With non-fungible tokens, digital signatures, and a bit of electronics know-how, we can show what this ecosystem might look like!

Bitcoin Cryptography – Hashing Algorithms


At the core of cryptocurrencies lies the science of cryptography. These mathematically secured and provable algorithms allow currencies like Bitcoin to be built in a way that’s peer-to-peer instead of based on corporate or governmental trust.

One of the key classes of cryptographic algorithms used in cryptocurrencies is hashing algorithms – powerful one-way functions with a broad set of interesting applications. Let’s learn about some of the important properties of hash functions and how they are used in Bitcoin.

All About Hashes

Properties of Hash Functions

Hash functions have a few key properties that make them incredibly useful and secure. Hash functions are one-way, they are preimage resistant (for crypto-secure versions), and are deterministic.

The first property is that hash functions are one-way – you cannot go backwards from a hash output (called the digest or the hash) back to the original input. These functions are sometimes referred to as “trapdoor functions”, because once an input falls into the trapdoor of the hash function, there is no coming back to the original message!

For example, let’s look at the SHA-256 hash of the message “Hello there!”:

>>> from hashlib import sha256
>>> sha256(b"Hello there!").hexdigest()

The message “Hello there!” is run through the function to create the digest “89b8b8e…”. There is no algorithm for going backwards – so if all you have is the hash output “89b8b8e…” and you want to know the original input, the only way to find it is to guess inputs until you find a matching digest! For example, this is how cracking passwords works. Attackers compromise a database of hashes, not plaintext passwords. They have dictionaries of common passwords that users use, and run those guesses through the hashing algorithm until a matching hash is found in the database.

This leads us to the second useful property of cryptographically secure hashing algorithms known as preimage resistance. These algorithms are designed such that there is not a predictable pattern from inputs to outputs that might make it easier to guess. If you have the hash output “89b8b8e…” from above, there’s nothing at all in that hash that points you in the direction of what the original input might be. An interesting part of good algorithms that relates to preimage resistance is the waterfall effect, where changing the input even slightly results in a drastically different output:

>>> from hashlib import sha256
>>> sha256(b"Hello there!").hexdigest()
>>> sha256(b"Hello there").hexdigest()

Notice that simply changing one character in the input (the ‘!’) results in a hash that’s nowhere near the first hash.

The third useful property of these functions is that they are deterministic. We know that they are one way – but it also turns out that the output is always the same for a particular input. From our example, feeding “Hello there!” into a properly-implemented SHA-256 function will always give the output value “89b8b83…”. This is critical for the use of hash functions, as it means someone with a hash and an input can verify the correctness of a message. For example, a software developer can give you an expected hash for their program along with the binary. You can then run the binary through the hash algorithm to verify the program has not been tampered with on its way to you!

Hashing in Bitcoin

There are two primary hash functions used in Bitcoin: SHA-256 and RIPEMD160. SHA2 was developed by the US National Security Agency (NSA) and first published in 2001. RIPE on the other hand was developed by a group of researchers in the EU and released in 1992 with an update in 1996. It’s interesting to note that Satoshi chose algorithms created in two very different ways, so if one does not trust the NSA or not trust open-source developed algorithms, there’s layers of security built in since both algorithms are used in the system.

Now what about how these are used? The first application is in Proof-of-Work Mining. POW is used to validate transactions and issue new coins on the peer-to-peer network without the need for trust. Every 10 minutes, miners construct a potential block of transactions. They take the block header information and a random value called the nonce through the SHA-256 algorithm. If the hash output treated as a 256 bit number is less than a difficulty target, the network accepts the Proof-of-Work solution as valid. It take millions of nonce guesses to get to a hash output that meets the difficulty, but once a solution is found anyone on the network can verify it’s correct in one step thanks to the deterministic nature of hashes.

Difficulty target is 0123abc...
"block header info" + 0 -> SHA-256 -> d3a2bb9...
"block header info" + 1 -> SHA-256 -> 110dbb9...
"block header info" + 2 -> SHA-256 -> 04a4173...

0123abc < 04a4173, so this meets POW difficulty requirement

The second application of hashes in Bitcoin is in address derivation. Bitcoin uses Elliptic Curve Cryptography as part of the address derivation scheme (which will be covered in a later tutorial :), but hashes are also a critical part of the algorithm. Deriving a Bitcoin address looks like this:

Ex (not real outputs):
Private key: 0123456789abc....
Public key: af325bc23d...
base58 encoding

ECDSA provides one layer of security, but the hashing algorithms provide another! When a user sends funds to another user’s address, they are not paying directly to the public key of the receiver. They are actually paying to a “Pay to Public Key Hash” address. The public key is hashed twice, once with SHA-256 and again with RIPEMD160, then encoded. What this does then is masks the receiver’s public key until the funds are later spent. So if a user avoids address reuse, other parties can never know the public key of an address containing any funds. If there’s a vulnerability in the way the wallet handles ECDSA or some future problem is found, this provides an extra layer of security over the owner’s funds.

Hashing – A Critical Part of Bitcoin

Looking at the fascinating properties of hashing algorithms, it’s clear why they’re so useful in a peer-to-peer application like Bitcoin. Thanks to the one-way, preimage resistant, deterministic nature of these algorithms, we can build systems where other users can verify things like mined transactions securely without the need for trust. As well, hashes provide layers of security over fund ownership on the blockchain, thanks to P2PKH addresses. Us Bitcoin fans trust the provability of math more than the fallibility of corporations and governments – who needs trust when you have cryptography!

Recovering BCH (Sent to BTC Address)


Many of the viewers of my tutorial on what happens when you send BCH to a BTC address have asked for more specific help on how to recover funds in this scenario. Fortunately, not all is lost if this happens – it just depends on the context. For non-custodial wallets (where the user controls the private key), it’s fairly straightforward to recover the lost BCH and send it back to a wallet the user would like to use. It is important to note, however, that this only works with these non-custodial wallets. If a user sends funds to a custodial wallet (like CashApp or an exchange), they’ll have to get in touch with that exchange’s customer service for help.

BCH Fund Recovery

What Actually Happens…

If a user sends BCH to a “BTC” address, the funds never really leave the Bitcoin Cash blockchain. The confusion happens because BCH and BTC legacy addresses are backward compatible – so when the user creates the BCH transaction with the BTC wallet address as the receiver, the transaction is totally valid and is sent.

But, the BTC and BCH addresses also share the same private key. Therefore, if the user has access to the BTC wallet’s recovery phrase (or the private key directly), they can import/sweep that key into a BCH wallet to get the funds back.

An Example Scenario, With Recovery Steps

For this tutorial, I “accidentally” sent some Bitcoin Cash to a Bitcoin address provided by a wallet. The funds do not show up in my BTC balance, because I actually did this on the BCH chain.

Looking at a block explorer, we can see the mistaken address for this transaction. In legacy format (BCH/BTC backward compatible), we see the address is `1Ka4YZ19kq87yXUAPXMt9KZLd2eap1pT4Y`

Now what we need to do is to get the associated private key for this address. In this case, provides a mnemonic seed phrase used to generate all the wallet’s private keys and associated addresses. Therefore, if we get this seed phrase we can extract the specific key for this address and import it into another wallet we control. The seed phrase for our test wallet here is:

water pulse panel anchor impulse brown effort cake open drastic bright aerobic 

It’s important that you don’t reuse this seed phrase for any of your own wallets – anyone who’s seen this tutorial could steal your money!

Now what we can do is import this seed phrase into a mnemonic tool. I’m a big fan of Ian Coleman’s Bip39 Mnemonic Code tool. An important note – if you’re doing this with real funds, download the webpage and run the tool when your PC is offline. Ian’s tool is trusted in the community, but it’s best practice to never but private information like seed phrases into online tools – your funds could be stolen by a nefarious website.

When the seed is put in the tool, the derived addresses and keys will be shown in a table like this:

Search for the address you mistakenly sent the funds to. If you’ve used your wallet a lot, you may have to generate more child addresses. Also, if you don’t see the address here, don’t panic – play around with some derivation settings. Different wallets use different paths and that sort of thing, but in this case our wallet used the defaults.

Now you need to copy the Wallet Import Format private key shown next to the address – this will allow you to unlock the funds. What we’ll do here is import or sweep the address into a BCH wallet we control to recover the funds. Note the distinction – an import keeps the funds in the same address. If you add this to a wallet with an existing backup phrase, the imported address will not be protected by that backup phrase. Sweeping is better – this will create a new transaction that sends the recovered funds to a new address controlled by the wallet’s phrase.

Your funds are back! For this sample recover, I imported the funds into an Electron Cash wallet on desktop.

Fund Recovery – It’s All About Keys

The most critical step in recovering lost funds is understanding that whoever controls the private keys owns the lost funds. If you’ve sent your funds off to an exchange or app like CashApp, you’ll need help from them because you don’t control the keys. But if you accidentally sent funds to an address provided by your own BTC wallet, you can follow these steps to get your BCH back into your normal BCH wallet. It’s a matter of getting the key for the mistaken address into a BCH wallet that recognizes the funds on the blockchain.

I hope this helps! It can be scary to lose funds in the cryptocurrency space, where things are a lot more final than in the world of banking. Ultimately though, cryptocurrency gives us more control over our own money and that’s a great thing.

Oh and as a little easter egg for my viewers – I left the BCH for this tutorial in the sample address. If you want it, it’s yours 🙂 First recovered, first served.

Why You Can’t Just Brute-Force a Bitcoin Private Key


Unfortunately, sometimes Bitcoin private keys are lost. Users destroy wallets, throw away hard drives, or simply never backup keys in the first place. A seemingly obvious solution to the problem of a lost key might be to try and “guess” all the possible keys until you find the one that unlocks your addresses. One can just spin up their gaming laptop, or maybe some Azure VM’s to get this done, right?

Well, no. In fact, there’s no practical chance at all that you could ever brute-force a Bitcoin private key. The scale of the problem is far larger than we as humans can even appreciate. Let’s dive in to the numbers and show why cracking your lost paper wallet simply isn’t going to happen.

Bits and Brute-Force: Understanding Key Cracking

A “Bit” on Binary Numbers

In order to understand the scale of the numbers involved in Bitcoin private keys, one must first understand a little bit about the binary number system used by computers. We’re used to a base 10 system, where each “place” in a number can have digits 0-9. The number 100, for example, has a 0 in the one’s place, a 0 in the 10’s place, and a 1 in the 100’s place. The number 100 when represented as a power of 10 is 10^2, or ten squared.

When it comes to binary numbers, similar principles apply. But force each “place”, we can only have 0 or 1. On or off. The number 18. in binary, for example, is 10010. There’s a 0 in the 1’s place, 2 in the 2’s place, 0 in the 4’s place, 9 in the 8’s place, and finally, 1 in the 16’s place. Each place is a power of 2! 10000 in binary is 16, or 2^4 – two to the fourth power.

The Scale of the Problem

Now this concept helps us understand a bit more about the scale of a particular keyspace. Let’s say, for example, we have an 8-bit private key for a cryptosystem. 8 bits, and each bit can be either 1 or 0. This means there’s a total of 2^8 possible combinations of 1’s and 0’s, giving us 2^8 = 256 possible private keys. If we have a 16-bit private key, we have 2^16 = 65536 possible private keys. You can apply this formula to any size keyspace you’d like.

You may have noticed something from our small sample size here. We only added 8 bits to the keysize going from 8 to 16 bits. However, we went from 256 possible keys to over 65 thousand! That’s a lot more possible keys, and therefore a lot more possible guesses we’d have to make to brute force the keyspace. It turns out that adding bits to a keysize makes it exponentially harder to brute-force that particular keyspace, and that’s why even a seemingly small keysize can make it practically impossible to brute-force those keys.

So, what about Bitcoin? Bitcoin uses 256-bit private keys. So given our little bit of math here, we can calculate the number of possible combinations:

2^256 = 115792089237316195423570985008687907853269984665640564039457584007913129639936 or 1.157921 x 10^77

Now that is an unfathomably large number of possible keys. For scale, the number of keys available in the space is on par with the number of atoms thought to be in the observable universe. That’s a lot of keys to guess.

A More Hands-On Look at the Scale of the Problem

Now one can stare at that large number of possible keys in awe, and still not quite understand how impossible it is to brute force Bitcoin keys. Computers are pretty good at dealing with large numbers, right? Yes, but still not good enough to deal with this many guesses.

I’ve created a program called PkTime written in C. This program will show us how long it takes to brute-force various keysizes on the machine it’s run on, or it can be given the number of ops (guesses) per second a machine is capable of. And of course, it’s available under a free and open source license!

Pktime will calculate the actual time to brute-force Bitcoin keys when run on the machine without a given ops/second value. It uses Trezor’s libraries to generate an actual Bitcoin Keypair, so it more accurately reflects the time to check one keypair in a brute-force attack.

This is the output of PkTime on my personal machine, an Asus laptop with an intel i5 processor. The program only uses a single core (no multithreading), and you’ll see why it makes no difference anyway:

josh@Josh-Asus:~/pktime/bin$ ./pktime
Calculating some real and estimated brute force times...please wait
Average optime for one keypair check: 0.00000959
Real time to bruteforce 8 bit keysize: 0.004566 seconds with 256 iterations
Real time to bruteforce 12 bit keysize: 0.035437 seconds with 4096 iterations
Real time to bruteforce 16 bit keysize: 0.457779 seconds with 65536 iterations
Real time to bruteforce 18 bit keysize: 1.902443 seconds with 262144 iterations
Real time to bruteforce 20 bit keysize: 7.585260 seconds with 1048576 iterations
Est. time to bruteforce 24 bit keysize: 2.68233088 minutes with 16777216 iterations
Est. time to bruteforce 28 bit keysize: 42.91729408 minutes with 268435456 iterations
Est. time to bruteforce 32 bit keysize: 11.44461175 hours with 4294967296 iterations
Est. time to bruteforce 36 bit keysize: 7.62974117 days with 68719476736 iterations
Est. time to bruteforce 40 bit keysize: 122.07585872 days with 1099511627776 iterations
Est. time to bruteforce 44 bit keysize: 5.34760777 years with 1.759219E+13 iterations
Est. time to bruteforce 48 bit keysize: 85.56172438 years with 2.814750E+14 iterations
Est. time to bruteforce 52 bit keysize: 1368.98759015 years with 4.503600E+15 iterations
Est. time to bruteforce 64 bit keysize: 5.607373E+06 years with 1.844674E+19 iterations
Est. time to bruteforce 128 bit keysize: 1.034378E+26 years with 3.402824E+38 iterations
Est. time to bruteforce 192 bit keysize: 1.908090E+45 years with 6.277102E+57 iterations
Est. time to bruteforce 256 bit keysize: 3.519805E+64 years with 1.157921E+77 iterations

It’s amazing to see just how much longer it takes to brute-force a keyspace by adding just a few bits. The jump from 28 to 36 bits takes the problem from minutes to days, and the jump from 40 to just 44 bits makes the difference between days and years. This is exponentially scaling.

A look at where we are for a 256-bit Bitcoin key…over 3 x 10^64 years. Trillions upon trillions upon trillions of years. Even a 50-some bit key is impossible to exhaust in any meaningful amount of time on a modern laptop.

Now you’re probably thinking – that’s a laptop though…what about the world’s best supercomputers, governments, etc. No need to fear for your keys; exponentially scaling still protects them!

Let’s re-run our estimation program and give an ops/second for the world’s fastest supercomputer. list’s IBM’s Summit as the current leader, with a theoretical maximum of 200795000000000000 flops, or floating-point operations per second. Let’s generously assume we have a supercomputer with this speed, and that it only takes 1 op to check a key (it takes quite a few more).

josh@Josh-Asus:~/pktime/bin$ ./pktime 200795000000000000
Average optime for one keypair check: 0.00000000
Est. time to bruteforce 24 bit keysize: 0.00000000 seconds with 16777216 iterations
Est. time to bruteforce 28 bit keysize: 0.00000000 seconds with 268435456 iterations
Est. time to bruteforce 32 bit keysize: 0.00000002 seconds with 4294967296 iterations
Est. time to bruteforce 36 bit keysize: 0.00000034 seconds with 68719476736 iterations
Est. time to bruteforce 40 bit keysize: 0.00000548 seconds with 1099511627776 iterations
Est. time to bruteforce 44 bit keysize: 0.00008761 seconds with 17592186044416 iterations
Est. time to bruteforce 48 bit keysize: 0.00140180 seconds with 281474976710656 iterations
Est. time to bruteforce 52 bit keysize: 0.02242884 seconds with 4503599627370496 iterations
Est. time to bruteforce 64 bit keysize: 1.53114238 minutes with 18446744073709551616 iterations
Est. time to bruteforce 128 bit keysize: 5.370103E+13 years with 3.402824E+38 iterations
Est. time to bruteforce 192 bit keysize: 9.906091E+32 years with 6.277102E+57 iterations
Est. time to bruteforce 256 bit keysize: 1.827351E+52 years with 1.157921E+77 iterations

Our supercomputer here is orders of magnitude faster than a laptop – in fact, it renders 64-bit keys completely insecure. But look how, once again, exponential scaling keeps 256-bit keys very, very safe. It would still take over 1 x 10^52 years to exhaust all the possible Bitcoin keys. Given that the universe is roughly 13 x 10^9 billion years old, I think it is safe to assume that brute-forcing the keys are an impossible task.

One last note – even if we could build a theoretical computer that could guess much faster, there are energy limits to computation. The amount of energy it would take to do all these operations far exceeds what humanity could harvest.

Brute-Forcing Bitcoin – Not Gonna Happen!

Given the enormity of the 256-bit keyspace, the speed of the world’s most amazing computers, and the limits of computation itself – you can clearly assume your Bitcoin keys are safe. As with all things security, there are other attack vectors that can get your coins stolen. But, there’s no way someone is spinning up a cloud computer to try and brute-force keys. The probabilities are far too low of finding a key, and the cost is simply too high. If you wanna steal those Bitcoin keys…just crack open a cold one and wait until the end of the universe. Even then, you might run out of time!

Fetching Live Balances on a Microntroller with WatchAddr (Code Companion #3)


One of the biggest perks of offline wallets (like paper wallets and hardware wallets) is the ability to store private keys away from prying eyes. In previous code companions, I talked about the challenges of building uBitAddr, a custom offline keypair generator that works with BCH, BTC, LTC, and ETH.

However, you probably want to keep tabs on your sweet, sweet offline savings. Many wallets have a “watch address” feature that lets you track the balances of an address without having the private key on hand for spending. In this project, I built a custom miniature “watch address” utility that runs on a wifi-enabled microcontroller!

Watching with Wifi

Fetching Data on an ESP8266 with MicroPython

The first part of my work involved connecting a wifi-enabled microprocessor to an API that would allow me to fetch live balance data. I wanted to be able to fetch data on addresses for my “big 4”, BCH, BTC, LTC, and ETH. So I chose to connect to the API for BCH, and BlockCypher for the other 3. Both provide an easy to use API that does not require an API key – an added layer of complexity that isn’t necessary for fetching totally public blockchain data.

Connecting to a network on this platform is surprisingly straightforward, and that makes building internet-connected projects a treat:

    # Connect to the wifi access point configured in
    def connect_wifi(self):

        conn = network.WLAN(network.STA_IF)

        conn.connect(auth.SSID, auth.PASS)


This code initializes a WLAN connection using the network module built into MicroPython and connects using the pre-configured network name (SSID) and password. This data is stored in a separate file called – anyone cloning this project will simply copy the sample and add their own configuration.

Building a Better API

Connecting directly to the APIs directly worked pretty well for just balance data, but I ran into two fairly serious issues fast.

First, connecting via HTTP isn’t secure or private – a man-in-the-middle attack could steal the user’s addresses. This isn’t a security issue per-se, as blockchain addresses are public data and can’t be used to steal funds. However, it does compromise the privacy of the user who might not want others on the network to discover their addresses and therefore wallet balances!

Second, it turns out that the buffer for TLS (HTTPS) connections on the ESP8266 are very small, around 5KB. Fetching balance and price data in JSON format (with a bunch of stuff I didn’t need) overflowed the buffer every time! The Cryptonator price API doesn’t support HTTP at all, so I needed to kill two birds with one stone and find a fix for this.

My solution was to essentially create my own API on top of the balance and price APIs I wanted to use. This “proxy” fetches the balance and price data and digests it down to only the very minimum data I need, the address balance and current USD value. I return this data in a comma-delimited string – no fuss and a very small data size.

		# Fetch the data in multiple threads to reduce IO latency
		data = {}
		t_bal = threading.Thread(target=self.fetch_bal, args=(address, currency.upper(), data))
		t_price = threading.Thread(target=self.fetch_price, args=(address, currency.upper(), data))


		bal = data["bal"]
		price = data["price"]
		usd = bal * price

		# Return the data in the form of a comma-separated list
		response = "{0:.8f},{1:.2f}".format(bal,usd)
		return response

There’s two functions in api/ not shown here that fetch the desired data from the API endpoints, parse, and return. This main code calls those functions and formats the data in the very basic string format before returning the response.

There’s also a fun optimization I added here: I’m fetching the data in two separate threads. Python doesn’t have “true” multithreading due to the Global Interpreter Lock, but it still works great for IO bound operations like waiting for a network response!

Screen Time!

Fetching the data and building a proxy is fun and all, but the ultimate goal is to run this off of a battery and not just off a USB cable connected to my laptop. So, I needed some way to display the information that wasn’t writing to my laptop’s console. In comes the delightfully small and powerful Adafruit OLED display.

This screen is more robust than the character screen I’ve used in past projects – it can display pixels! Fortunately it does come with a simple API for writing text which is all we need here. This screen is wired up to communicate over the i2c serial protocol, which I find nice and simple to use. I also have an SPI version of the screen I would like to add support for as well, and it would be easy to wire up a character LCD.

    # Initialize the OLED screen for display
    def init_oled(self):

        i2c = machine.I2C(-1, machine.Pin(5), machine.Pin(4))
        self.oled = ssd1306.SSD1306_I2C(128, 32, i2c)
        self.oled_line = 0

    # Define a flexible display function
    # This can simply print to serial or output to a peripheral
    def output_data(self, data):
        if self.output == self.OUTPUT_DISPLAY:
            self.oled.text(data, 0, self.oled_line)
            if self.oled_line == 30:
                self.oled_line = 0
                self.oled_line = self.oled_line + 10

These functions initialize the OLED screen and allow output of up to 3 rows of text (all that will fit on the screen).

Showing current crypto balances
Showing current USD value

Offline Addresses, Online Watching

This was another very fun project to build, and I’m proud of it! I love tinkering, and working with microcontrollers has been an exciting new avenue for learning and building interesting projects.

This utility is a nice companion for uBitAddr, so someone making offline wallets can keep tabs on their secure savings in a small, lightweight package. And as always, I think looking at this code can help folks understand more about how cryptocurrencies and software work.

How to Read the Bitcoin Whitepaper


On October 31st, 2008, Satoshi Nakamoto graced the world with his vision for a peer-to-peer electronic cash system called Bitcoin. The cryptocurrencies we use today started with this abstract and the ideas contained within. I highly recommend anyone interested in Bitcoin or other open blockchain projects read the original whitepaper, but it can be a bit technical and terse for the completely uninitiated.

Let’s walk through the whitepaper together, and get an idea of what each section discusses and why it’s important for creating the Bitcoin system. The whitepaper can be read here: and from many other sources.

Understanding The Whitepaper

Abstract and Section 1

The abstract and first section of the whitepaper lay the groundwork for why Bitcoin is important and how it solves several problems with the existing system used for online transactions. Whitepapers such as this are often oriented around solving a problem, and the Bitcoin whitepaper discusses the particular problem of creating a trustless system of internet money, in contrast to traditional systems that require intermediary processors and mints.

Section 2 – Digital Signatures

Section 2 describes what we now know as the system of private/public key pairs (addresses) and how they are used for transactions. In Bitcoin, the user holds their own private keys that prove they own their coins. When the user wants to spend these coins, they create a new transaction that sends coins to another address. That transaction contains a mathematical/cryptographic proof that they are the rightful owner of those funds, called a digital signature. The user can prove to the rest of the users on the network that they control a private key without revealing that key at all! Instead, they sign a message and provide a public key, allowing other users to verify they own some money without revealing the secret.

This is a powerful and important feature in Bitcoin – transactions are created and chained together without the need for secret information to be revealed. However, this doesn’t prevent the problem of double spending, where a user could simply do a digital signature twice to re-spend coins.

Sections 3-6 & 11 – Proof of Work Consensus

In order to prevent double spending and ensure consensus across the peer-to-peer network of users, Bitcoin uses an interesting system called proof-of-work. This system prevents fraud by requiring that users expend real-world resources in the form of electricity and computing power to solve a mathematical problem. Sections 3 & 4 describe the proof-of-work timestamp system used to create a consensus on what transactions are valid and when they occurred.

This mathematical problem requires taking a batch of transactions (batched every ten minutes, roughly) and solving a very difficult guessing game, essentially. The answer to this problem, based on data in the block, can only be solved by guessing a bunch. But once the answer is found, all the other nodes on the network can verify the answer is correct in an instant! This is based on the properties of the hashing algorithm used in the problem.

Now what does that mean for Bitcoin? It means that as a bunch of honest nodes on the network contribute to security through proof-of-work, attackers don’t have the resources to outcompete the honest chain. For an attacker to put a fraudulent transaction in a block, they would have to compute faster than the rest of the entire world acting honestly, and with a large network effect this becomes impossible to do at scale!

As well, part of the problem data for a new block is based on older block data (hence, blockchain as the blocks are cryptographically linked). So, if an attacker wanted to create a fraudulent transaction that is three blocks back in the history, they would have to do outcompute the rest of the world, doing thirty minutes of work in under ten. Section 11 shows that the probably of a successful attack becomes negligible after only a few blocks of history.

Sections 5 & 6 – Networking and Incentives

Now why act honestly in the first place? Sections 5 & 6 describe how the network interacts and rewards legitimate users.

Section 5 describes how transactions are flooded out across the peer to peer network for batch processing. Any node that wants to mine to help secure the chain can do so using their CPU power. When a solution is found, it is shared with other nodes that can verify it is correct, and the race to solve the next problem begins. Nodes running the Bitcoin software will always follow the longest chain of solved problems or the longest chain of “proof-of-work.

Section 6 describes one of the most important aspects of proof-of-work in Bitcoin, and that’s the system of economic incentives that rewards miners for acting honestly. The miner that finds solves the problem for a block gets two rewards – first, they get newly minted Bitcoin. They also receive all of the transaction fees in that block. The system is therefore designed so that it’s easier and more profitable to mine legitimately than to try and attack the network.

Sections 7, 8, & 9- Dealing with Block Data

Storing all of the data in blocks takes up a lot of space as time goes on. The Bitcoin blockchain is several hundreds of gigabytes in size as of the time of this writing. However, Satoshi found a way to keep validation secure without storing every bit of data and discusses in Section 7. Transaction data is cryptographically “summarized” in a Merkle Tree, so that the amount of data needed for secure validation is reduced through a process called pruning.

As well, thanks to Merkle trees, it is not necessary for every user on the network to store the whole blockchain and validate data. Section 8 describes a process known as Simplified Payment Verification that allow Bitcoin clients to create and receive payments securely without needing the entire history stored in the blockchain. This is especially critical for applications such as mobile wallets.

Section 9 describes the model Bitcoin uses to store data about who owns what. This is the UTXO blockchain model, where each wallet owns these Unspent Transaction Outputs that behave like dollar bills. A user can take multiple UTXOs and combine them to create a transaction, and send the “change” back to their own wallet.

Section 10 – A Privacy Primer

Everything in Bitcoin happens on a completely public blockchain. It is pseudonymous, but not anonymous! In order to prevent blockchain analysis from linking a bunch of transactions back to an individual user, Satoshi recommends in Section 10 that users create new addresses for each payment and not reuse old addresses. This makes linking transactions together much harder for observers.

Understanding Bitcoin, Right from the Source!

The Bitcoin whitepaper is a great place to get started in understanding Bitcoin. In only 8 pages of information, this work describes how to create a system of payments that doesn’t rely on any central, trusted authorities like our traditional monetary system does.

The paper itself is brief and to the point, which may make it tricky to understand at first. But with this companion, some re-reading, and exploring other works out there, it becomes easier to understand the magic of the ideas described. Happy Birthday to Bitcoin, and happy reading all!