Common Bitcoin Misconceptions Among Programmers

By Owen PatelCryptography Tutorial

Common Bitcoin Misconceptions Among Programmers

Inspired by the article “Falsehoods Programmers Believe About Phone Numbers,” I decided to collect the most common misconceptions about Bitcoin.

Blocks

  1. The block height will only ever increase.
    The most legitimate or “honest” chain is not the one with the most blocks, but the one with the most accumulated work. The work required to find a valid proof depends on the difficulty target. So, it’s possible for a chain with more blocks to be less “honest” if its difficulty is lower. If a client first sees a chain with more blocks, but later discovers a more “honest” chain with more work, it will switch to the latter, even if it has fewer blocks. In this case, the valid block height from the node’s perspective can actually decrease.
    Thought experiment: Imagine a miner with a hash rate higher than the rest of the network. This miner keeps their found blocks private. After 2016 blocks, the hidden chain’s difficulty adjusts and increases significantly. All blocks in the hidden chain now contain more work than the corresponding public blocks. The miner adds a few more blocks, stops mining, and waits for the public chain to catch up in length. Then, the miner reveals their blocks. All nodes will switch to the chain with fewer blocks but more work.
    How likely is this? I’ll leave that as an exercise for the reader. If you come up with another scenario, please, for Satoshi’s sake, submit a pull request to the original article’s repository!
  2. The time required to create a new block will only increase.
  3. When a miner finds a new block, it will definitely be added to the blockchain.
  4. Okay, but if a solo miner finds a valid block, it will definitely be added to the blockchain.
    Not necessarily. If the new block’s hash matches an earlier block’s hash, the inventory vector of the new block will be a copy of an existing block’s vector, so nodes won’t request it. It will simply be ignored, as if it was never found. Everyone will believe that no new block was found at that height.
  5. Each block always generates exactly ${CURRENT_BLOCKREWARD} bitcoins.
    In block 124724, the coinbase transaction was missing one satoshi. In block 501726, there was no mining reward at all.
  6. The more leading zeros in a block’s hash (i.e., the lower the hash), the more work that block contributes to the total work.
    A common misconception is that blocks with lower hashes (more leading zeros) contribute more to the total work than blocks with higher hashes (fewer leading zeros). The block hash is calculated through many independent SHA256 hashing operations, continuing until a hash below the current target is found. The target is stored in the nBits field in the block header and is adjusted every 2016 blocks. Each hash attempt is independent. Since SHA256 outputs are pseudo-random, the probability of finding a valid hash depends only on the current target. Any hash below the target is valid, and the probability is the same for all values below the target (regardless of whether it has 15 or 30 leading zeros). Only the difficulty value (maximum target/current target) at the time of block generation is used to calculate total work. See validation.cpp#L3138 for where the current block’s work is added to nChainWork. Also, check GetBlockProof(…) in chain.cpp—block work is calculated only from the nBits field in the block header.
  7. Difficulty adjustments are based on the previous 2016 blocks.
    There’s an off-by-one bug in the difficulty adjustment algorithm. Calculations are based on the previous 2015 blocks, not exactly 2016.
  8. Empty blocks are truly empty.
    Empty blocks still contain data. They just don’t have any transactions other than the coinbase transaction. Since the block contains no mempool transactions, it’s considered empty. Empty blocks still require significant computational power, as they must also provide proof of work. They have block headers (80 bytes) and all the same fields as non-empty blocks.

Transactions

  1. If a valid transaction is in the mempool, it will eventually be included in the blockchain.
    Transactions can be dropped from the mempool. A node’s mempool can only use as much memory as set by maxmempool. Once this limit is reached, the node will evict transactions with the lowest fees and raise mempoolminfee. It will then notify other nodes of its new mempoolminfee, essentially telling them not to send transactions with lower fees. Each node does this independently, so nodes with larger mempools or different architectures may drop transactions sooner or later.
  2. Before a transaction is included in the blockchain, it must pass through the mempool.
  3. If I see a transaction in my mempool, I can be sure it’s in every node’s mempool.
    No. Here’s why:

    • Transactions take time to propagate to all nodes. If you see it, that doesn’t mean everyone does.
    • Each node is configured differently and has its own limits (e.g., maxmempool size).
    • A node is not required to accept a transaction into its mempool and can refuse for various reasons.
  4. If a transaction isn’t accepted into the mempool, it will never be considered valid or added to a block.
    A node may reject, not add, or not request a transaction for many reasons, such as the transaction fee being below the node’s minrelaytxfee. This parameter sets the minimum fee for the node’s mempool. The node won’t accept unconfirmed transactions below this fee and won’t relay them. minrelaytxfee is a configurable setting, and each node operator can set it independently. This doesn’t mean the transaction is invalid or can’t be included in a block.
  5. Okay, but once a transaction is included in a block, it will remain in the blockchain forever.
  6. Each transaction has exactly one recipient.
  7. Each transaction has exactly one sender.
  8. The destination for a Bitcoin transaction output is always an address.
  9. The miner always picks the transaction with the highest fee.
  10. All transaction hashes in the blockchain are unique.
  11. The fee is explicitly set in the transaction.
  12. If I create a transaction marked as RBF, I can always replace it with another until it’s confirmed.
  13. If I see a non-RBF transaction with a sufficient fee, I can be sure it will be accepted into the blockchain without changes.
  14. If I see an unconfirmed transaction sent to my address, I can save its ID—it will never change.
  15. If the ID of an unconfirmed transaction changes, it was definitely a malicious double-spend attempt.

Wallets

  1. All wallets support p2pkh transactions.
  2. All wallets use standardized derivation/output paths.
  3. Brain wallets are secure.
  4. 12 (or 15, 18, 21, 24) mnemonic words are all you need to restore your wallet.
  5. There is only one standard for mnemonics (12/24 words).
  6. Every derivation/output path (e.g., m/44’/0’/0’/0/0, m/44’/0’/0’/0/1, etc.) will always produce a valid address.
    A BIP32 key is derived by applying HMAC-SHA512 (see BIP32 for details), and the first 256 bits of the result become the key. Bitcoin uses the secp256k1 elliptic curve for signing. Not all numbers from 0 to 2256 are valid secp256k1 keys. For example, 0 and all numbers > n (where n is the curve order) are invalid. Since n for secp256k1 is very close to 2256, it’s extremely unlikely (less than 1 in 2127) that a derived BIP32 key will be invalid. If it ever happens, BIP32 specifies that the wallet should skip that index and move to the next one (see the key derivation spec for details).
    So, it’s possible for wallets to have skipped indices. For those, no address exists, and they’re simply ignored. The probability is so low that it’s unlikely anyone will ever encounter this. Fun fact: the author of pycoin even prepared a special error message in case it ever happens!
  7. If I partially sweep a paper wallet, the remaining funds will always stay on that wallet.
  8. But if I use an app with a sweep function and transfer only part of the funds, the rest will definitely return to the paper wallet’s address.

Keys

  1. Each private key corresponds to exactly one address.
  2. Private keys in WIF format are shorter than non-WIF keys.
  3. Every integer from 1 to 2256 is a valid Bitcoin private key.
  4. You can convert an existing Bitcoin key into a BIP39 mnemonic (12/24 words).
  5. If I have a private key derived from an extended (xpub/xprv) key, it’s safe to share it with someone who knows the parent xpub (not xprv).

Addresses

  1. Each Bitcoin address has exactly one private key.
  2. You can always derive an address from input or output data.
  3. All Bitcoin addresses are the same length (number of characters).
  4. All Bitcoin addresses are case-sensitive.

Privacy

  1. Bitcoin is anonymous.
    Every coin has a clear ownership history traceable back to its creation. The blockchain allows anyone to see all transactions. Any network participant can audit transactions, addresses, and the total coin supply. Addresses are just strings of letters and numbers, not inherently tied to a specific user or wallet. Users and wallets can use any number of addresses, and multisig addresses can hold coins for multiple users. So, Bitcoin is better described as pseudonymous, not anonymous.
  2. All coins spent in a single transaction (inputs) are controlled by the same entity or person.

Other

  1. There are exactly 21 million bitcoins.
    The total number of bitcoins approaches 21 million due to the blockchain’s structure (specifically, transaction outputs are integers). The more precise number is 20,999,999.9769 bitcoins. Due to underpaid mining rewards, the actual total is even lower. So, it’s impossible to know exactly how many bitcoins will exist in 2140, but it will definitely be less than 21 million.
  2. Okay, but at least I can be sure that no more than 21 million bitcoins will ever be issued.
    Well… not exactly. In August 2010, there was a small incident at block #74638. Someone discovered that transaction sums weren’t checked to ensure they didn’t exceed the wallet balance (there was no such check at the time). This person created a transaction with two outputs, each for 92,233,720,368.54277039 BTC (92 billion!). All nodes considered this transaction valid because the sum of inputs plus fees appeared to match the outputs, but in reality, it caused an integer overflow. The Bitcoin community quickly noticed and fixed the bug within a few hours. Once most miners upgraded, the chain with that block was rejected as invalid, and all nodes dropped it. In the new main chain, that block no longer existed, so you won’t see it in today’s blockchain. However, you can still see traces of this event in the timestamps of block 74637 and block 74638. There’s a gap of several hours between them, which is exactly how long the invalid chain existed before being replaced by the honest chain supported by the majority.
    So, technically, there was a brief period when the total number of bitcoins exceeded 21 million. If the bitcoin-cli gettxoutsetinfo RPC command had existed in 2010, then on August 15, 2010, between 17:02 and 23:53, it would have shown more than 21 million bitcoins.
  3. All UTXOs (unspent transaction outputs) can be spent.
    Some are provably unspendable (for example, the 50 BTC output in the genesis block). There are also outputs with OP_RETURN scripts and others that are almost certainly unspendable. For example, addresses that look “generated” (like 1CounterpartyXXXXXXXXXXXXXXXUWLpVr or 1BitcoinEaterAddressDontSendf59kuE) are likely not the result of a real hash operation. It’s safe to assume those coins are lost forever. There are also many addresses whose private keys have been lost.

Leave a Reply