Skip to content

Latest commit

 

History

History
297 lines (201 loc) · 20.7 KB

FALSEHOODS.md

File metadata and controls

297 lines (201 loc) · 20.7 KB
Raw

Falsehoods Programmers Believe About Bitcoin

In the spirit of Falsehoods Programmers Believe About Phone Numbers, here is a list of mistaken perspectives on Bitcoin.

Blocks

  1. Block height will only increase.

    Not the chain with the highest number of blocks is considered as the majority chain (honest chain), but the chain with the most cumulated chainwork. As the work needed to find a valid block proof is dependent on the block target (see also difficulty), it is possible that a chain with a higher number of blocks than the majority chain exists, if the difficulty was lower in this chain. If a client for some reason first only sees the minority chain (with higher block count) and then gets presented the majority chain (with a higher chainwork) it will drop the minority chain in favor of the majority chain. In this case the valid block height (as seen by this node) might actually decrease.

    It is a very difficult exercise to even imagine a scenario of how this could happen.

    Thought experiment: Suppose a miner with massive hash power outperforming the majority chain, but not publicly announcing the blocks. After 2016 blocks a difficulty adjustment takes place and the difficulty on the hidden chain increases by a lot. All blocks mined now on the hidden chain contain more chainwork than corresponding blocks on the public chain. The miner produces a few more blocks, stops mining and waits for the other chain to catch up to his blocksize + 1 and then announces his blocks. All nodes will follow the chain with lesser blockheight because it includes more chainwork.

    It is left as an exercise for the reader to imagine how likely the occurrence of this case may be.

    A curious situation that impacted applications relying on a constantly increasing block height is the March 2013 Chain Fork. If you can come up with an additional scenario, please - for the sake of Satoshi - create a PR!

  2. Block time will only increase.

    No. That's not how time works in Bitcoin. A block does not necessarily have to have a higher timestamp than its predecessor. The network has no physical connection to the real world - so how does it know what time it is? The only way for Bitcoin to know is by integrating a concept of time in the consensus rules.

    Clocks are imprecise and time is a difficult concept. There is no single source of truth. It is even stated in the comment of function GetTimeOffset():

    Never go to sea with two chronometers; take one or three.

    A beautiful explanation on why this has no negative impact on the proper functioning of the network has been described by dergigi:

    For Bitcoin, the fact that our human timestamps are imprecise doesn’t matter too much. It also doesn’t matter that we have no absolute reference frame in the first place. They only have to be precise enough to calculate a somewhat reliable average across 2016 blocks. To guarantee that, a block’s "meatspace" timestamp is only accepted if it fulfills two criteria:

    1. The timestamp has to be greater than the median timestamp of the previous 11 blocks.
    2. The timestamp has to be less than the network-adjusted time plus two hours. (The “network-adjusted time” is simply the median of the timestamps returned by all nodes connected to you.)

    The whole article "Bitcoin is Time" by dergigi is well worth reading.

    It is these rules that allow a block with a lower timestamp than its predecessor to be considered valid.

    However, if a block violates these rules either "time-too-old: block's timestamp is too early" or "time-too-new: block timestamp too far in the future" validation errors in ContextualCheckBlockHeader() will keep it from being accepted.

    Bitcoin has three sources of time:

    • System clock
    • Median of other nodes clocks (see GetMedianTimePast())
    • The user (asking the user to fix the system clock if the first two disagree)

  3. When a miner finds a valid block, it is guaranteed to be included in the blockchain.

  4. Okay, but when a miner finds a valid block single-handedly, it is guaranteed to be included in the blockchain.

    Not if the block's hash collides with the hash of an earlier block. As the inventory vector of the described new block would be a duplicate of an already known block, no other node would request this block. It would just be ignored, as if never discovered in the first place. Everybody would be convinced that no new block has been found at that height yet.

  5. Each block always generates ${CURRENT_BLOCKREWARD} amount of new Bitcoin.

    In block 124724 the coinbase transaction is missing one Satoshi. Block 501726 is even missing the whole block reward.

  6. The more leading 0's a block hash has (i.e. the lower the hash is), the more does the block contribute to total chainwork.

    It's a common misbelief that blocks with a lower block hash (i.e. more leading zeros) contribute more to the cumulated chainwork than a block with a larger hash (less leading zeros). Calculating the block hash consists of many (independent) SHA256 hashing operations until a hash is found which is lower than the current target (which is stored in the nBits field of the blockheader and gets adjusted every 2016 blocks as part of the difficulty adjustment algorithm). Each of this hashing operations is independent of all hashing operations before. As the result of SHA256 is pseudorandomly distributed the probability of finding a hash meeting the target requirements is only dependent on the current target value itself. Any hash below the target will be considered as a valid block proof, but the probability of finding such a hash is the same for all values below the target (no matter if it has 15 or 30 leading zeros). For this reason only the difficulty value (= highest target / current target) which was active at the time of block generation is accounted to the amount of total work (see validation.cpp#L3138 to see where the work of current block is added to nChainWork and see GetBlockProof(…) in chain.cpp to see how the block work is calculated only from the blockheader's nBits (=current target) header field).

  7. Difficulty adjustment is based off of the previous 2016 blocks.

    The difficulty adjustment algorithm has an off-by-one bug that leads to the calculation based off of the previous 2015 blocks, rather than precisely 2016.

  8. Empty blocks are empty.

    Empty blocks still contain data. They aren't devoid of data, they simply do not have transactions other than the coinbase transaction in them. Since an empty block does not contain any transactions from the mempool, it is considered to be empty. Empty blocks are still computationally expensive because miners still have to produce a Proof of Work. They still have block headers which are 80 bytes and have all the fields that non-empty blocks do.

Transactions

  1. Once a valid transaction is in the mempool, it will end up in the blockchain.

    Transactions can be dropped from the mempool. A node's mempool can only occupy as much memory as is configured through maxmempool. When this limit is reached, it will drop the transactions with the lowest feerate and increase its mempoolminfee. It will communicate its new mempoolminfee to its peers, basically telling peers not to forward transactions below that feerate for the time being. Note that every node does this individually, so a node with a larger mempool or different architecture may drop transactions earlier or later.

  2. Before a transaction becomes part of the blockchain it must be in the mempool.

  3. If I see a transaction in my mempool I can be sure it is in all nodes' mempool.

    No.

    • Transactions need time to be propagated to every node. If you see it, it does not mean everybody sees it.
    • Every node is configured differently and has certain constraints (e.g. maxmempool size reached).
    • A node is not obligated to include a transaction in the mempool and can decline to do so at will.

  4. If a transaction is not accepted in the mempool it cannot be accepted as valid in a block.

    There are various reasons a transaction might not be accepted, propagated or requested by nodes, e.g. a transaction has a fee rate below the minrelaytxfee.

    The minrelaytxfee specifies a feerate acting as a lower bound for a node's mempool. A node will not admit unconfirmed transactions below that feerate to its mempool and thus will not relay them to its peers. The minrelaytxfee is a configuration setting and can be specified by each node operator independently.

    This does not mean it is invalid or cannot be included in a block.

  5. Yeah, but once it is in a block, it will stay in the blockchain forever.

  6. Each transaction has exactly one receiver.

  7. Each transaction has exactly one sender.

  8. The destination of a Bitcoin transaction (output) is always an address.

  9. A miner will always select the transactions with the highest fees.

  10. All transaction hashes in the blockchain are unique.

  11. Fees are a specified explicitly in a transaction.

  12. If I make a RBF marked transaction I can always replace it by a different one, as long as it is still unconfirmed.

  13. If I see a none-RBF marked transaction with enough fee, I can be pretty sure it will end up in the blockchain as it is.

  14. If I see an unconfirmed payment to an address of mine, I can store the transaction ID as it will never change.

  15. If the transaction ID of an unconfirmed payment has changed, it was clearly a malicious double-spend attempt.

Wallets

  1. All wallets support p2pkh transactions.

  2. All wallets use standardized derivation paths.

  3. Brain wallets are secure.

  4. The 12 (or 15, 18, 21, 24) words of my seed phrase are everything I need to recover my wallet.

  5. There is only one standard for mnemonic seed phrases (12/24 words).

  6. Each derivation path (eg. m/44'/0'/0'/0/0, m/44'/0'/0'/0/1, ...) is guaranteed to derive a valid address.

    BIP 32 key derivation consists of applying HMAC-SHA512 (see BIP 32 for all details) and using the first 256 bits of the result as key material. Bitcoin uses the secp256k1 elliptic curve for its underlying signature operations. Not all numbers from 0 to 2^256 are valid keys for secp256k1, especially the number 0 and all numbers > n (where n is the order of the curve) are not valid keys (per definition of secp256k1). As n of the secp256k1 curve is very close to the possible maximum of 2^256 it is very unlikely (probability of less than 1 in 2^127) that the value derived as part of BIP 32 key derivation is not a valid private key. If such a case ever happens BIP 32 specifies that a wallet should just skip this index and proceed with the next higher index (see specification of key derivation for details).

    So it is possible that wallets exist where the index of derived keys might have a gap. For these missing indexes then simply no address exists, and the missing index should be silently ignored by wallets. However, this case is so highly unlikely it's very likely that nobody will ever see this case in practice. (Trivia: The author of pycoin even prepared a very special error message for the case should this ever happen. :) ).

  7. If I sweep only parts of the funds on a paperwallet, the remaining rest will always stay on the paper wallet.

  8. But if I use a wallet providing a dedicated "sweep paperwallet" function and spend only parts of the funds, the remaining funds will always end up at the exactly same address printed on the paper wallet.

Keys

  1. Each private key corresponds to exactly one address.

  2. Compressed WIF Bitcoin private keys are shorter than uncompressed keys.

  3. Every integer from 1 to 2^256 is a valid private key for a Bitcoin address.

  4. It is possible to convert an existing Bitcoin private key to a BIP39 mnemonic seed (12/24 words seed).

  5. It is safe to handout the single private key of an address which was (non hardly) derived from an extended key (xpub/xprv) to a person who also knows the xpub (not the xprv) from which the address was derived from.

Addresses

  1. Each Bitcoin address has exactly one private key.

  2. It is always possible to derive an address from an input (or output).

  3. All Bitcoin addresses have the same length (number of characters).

  4. All Bitcoin addresses are case-sensitive.

Privacy

  1. Bitcoin is anonymous.

    All coins have a clear and visible history of ownership tracing back to their creation. In addition, the blockchain allows all transactions to be viewed by anyone in the network, so transactions, addresses, and supply can be easily audited by any and all network participants.

    Addresses are merely strings of letters and numbers, and are not inherently connected to a given user or wallet. Both users and wallets can use an arbitrary number of addresses to store bitcoin, and multisig addresses can hold bitcoin belonging to multiple users. Thus, Bitcoin is most accurately defined as pseudonymous rather than anonymous.

  2. All coins spent within a single transaction (inputs) are controlled by the same entity (owned by the same person).

Exchanges

  1. Exchanges will always allow withdrawal of funds.

  2. The coins in my exchange account are mine.

  3. The coins in my exchange account actually exist.

  4. Orders which are successfully placed on exchanges are guaranteed to be executed.

  5. Ask price will always be equal or higher than bid price.

Misc

  1. There are exactly 21 million bitcoin to ever exist.

    The total number of bitcoins has an asymptote at 21 million, due to a side-effect of the data structure of the blockchain – specifically the integer storage type of the transaction output – the exact value would be 20,999,999.9769 bitcoin. However, due to miner underpayment, the total number is even less.

    It is therefore impossible to know exactly how many bitcoin will exist in the year 2140, but it will be less than 21 millions.

  2. Okay, but at least I can be sure the supply is never going to be greater than 21 million.

    Well.. no.

    Back in August 2010 there was an incident at blockheight #74638: Someone discovered that transaction amounts had no overflow check implemented (back then) and created a transaction which included 2 outputs each with 92233720368.54277039 BTC (92 billion!). This transaction was considered as valid by all nodes in the network, because the sum of the inputs (+ fees) seemed to be equal to the sum of these 2 outputs (because the sum caused an integer overflow). This was recognized quickly by the Bitcoin community and within a few hours a bugfix was developed. As soon as the majority of miners ran the bugfixed version, the chain containing this block was rejected as invalid and dropped by all nodes, and the new majority chain did no longer contain this block (so you will not see this block anymore in today's blockchain). You can still see the traces of this incident in the blockchain by looking at the timestamps of block 74637 (2010-08-15 17:02) and block 74638 (2010-08-15 23:53). They are several hours apart because that is the time in which the chain with the invalid transaction existed until it was later discarded in favor of the honest majority chain.

    So, technically, there was a short period in time, where the total amount of Bitcoin was higher than 21 million. If the RPC call bitcoin-cli gettxoutsetinfo would already have existed in 2010, it would have returned a total amount of over 184 billion total BTC between 17:02 and 23:53 on 2010-08-15.

  3. All UTXOs are spendable.

    Some outputs are provably unspendable (for example the 50 BTC output in the genesis block can never be spent) as well as all outputs with a OP_RETURN script and others where it is highly likely the coins can never be spent (for example addresses which look "generated" in a way that somebody just tried to find a valid checksum for the address string, but it is very, very unlikely that the address really resulted from an actual random hashing operation). Examples: 1CounterpartyXXXXXXXXXXXXXXXUWLpVr or 1BitcoinEaterAddressDontSendf59kuE. One can safely assume, that these coins are unspendable forever. Besides all this, there are lots of addresses where the private key is lost.

  4. Bitcoin never had a double spend.

    Ouch! There was a little problem on March 11, 2013, starting at blockheight #225430 during an upgrade from v0.7 to v0.8 ...

    A user described an interesting situation on that day that led to OKPay suffering a $10,000 double spend.

    08:08 – Well before I knew what later have happened, [...], I paid OKPAY address 12z2n8YCJw1BEsJhhQPLCTuLqwH341nKnE 211.9093 BTC and 0.0005 BTC as transaction fee.

    09:30 – The transaction was included in version 0.8's fork, block 225446

    10:08 – Deposit completed [...]

    12:53 – After some study, I recognized, the transaction, though included in version 0.8's fork, was never confirmed by the pre-0.8 fork, so I decided to make two double spend transactions on two of the vins of the OKPAY transaction [...]

    13:01 – The double spend transaction was included in pre-0.8 fork block 225446

    Even waiting for confirmations would not have mitigated this scenario and could have had even bigger impacts by making hostile miners more motivated to attempt a Goldfinger attack. After five years, no block explorer shows the original transactions anymore. That's why it's up for debate whether it was a real double spend. See March 2013 Chain Fork Post-Mortem (BIP50) or read the full story of the 2013 Bitcoin fork - it's fascinating.