Money for the streets

Reactor online. Sensors online. Weapons online. All systems nominal.

This manual first covers high level fundamentals of bitcoin and then decends into technical details.


The value of bitcoin is derived entirely from its leaderless-consensus (known as Nakamodo Consensus).

The word consensus maybe makes people think of a jury where members need to find a verdict. Or perhaps they think of a distributed system relying on a quorum achieving consensus. In both these scenarios, there is trust put in relatively few leaders in order to pragmatically create consensus.

Trust is power. And humans tend to abuse it. Thus bitcoin’s value proposition: consensus, but without leaders. There is no power to abuse. Whether this is valuable or not…well, that is a question for yourself.

From a high level, Nakamodo Consensus is achieved through a combination of applied cryptography and game theory. The applied cryptography allows consensus responsibility to be shared among all users. The game theory allows users to assume which rules are the agreed upon rules. So, all users agree on the rules while having equal responsibilities. That’s leaderless consensus.

proof of work

There is a common characteristic of applied cryptography which is used over and over in the bitcoin system: hard to calculate, easy to verify. A real world metaphor might be cooking pancakes. Its very easy for someone to try a bite of pancakes and verify “Yep, these are pancakes”. It is harder for them to guess the exact recipe used to cook (a.k.a. calculate) these pancakes.

This cryptographic property can be chained together. Back to the pancake metaphor, there could be a new recipe, recipe2, which is just recipe1 plus a new secret ingredient. This means though that if recipe1 changes, the pancakes produced by recipe2 will also change.

The bitcoin protocol defines a system which utilizes these characteristics to create Nakamodo Consensus. The crux of this system is a strategy called Proof of Work. In bitcoin, the proof of work outputs a ledger of bitcoin transactions which holds the entire history of bitcoin and the rules used to get there. This is called the blockchain.

Proof of Work uses the hard to calculate, easy to verify characteristic to enable random, short-term leaders who get to add one block on the blockchain. Users have incentives to be the leader, they then get to collect the fees in a block, but they must contribute work in order to have the chance. The more work, the higher the chance (its linear). When a new block is added by the leader, all other users are able to quickly validate that the leader was random and followed the rules (prove the work).

Proof of Work uses the chaining principle to link the blocks on the blockchain together. This allows users to quickly agree that the entire blockchain is valid and follows the rules.

What differentiates the bitcoin blockchain from another one which follows the same rules? The one with the most blocks (longest) has the most work poured into it and is the blockchain. This is where game theory gets involved to allow users to assume the longest blockchain is the real blockchain.

Bitcoin minimizes the complexity of achieving consensus by minimizing the scope of what consensus is covering. The consensus only producing a log (ledger) of events. In other words, “these things happened in this order”. Even the allowed “things” is a fairly minimal set of transaction types. Compare this to Ethereum where consensus is covering a much broader set of things. This requires more complexity in the how consensus is achieved. That complexity bears risks, known and unknown.

Sybil attack

A 51% attack, or Sybil attack, is the most well known attack on bitcoin which Proof of Work also defends against. The work in Proof of Work allows users to agree on a blockchain, but it also helps protect from this kind of attack.

A Sybil attack is when someone controls at least 51% of the work being poured into bitcoin. At this point, chances are they will guess the next block and thus be the short term leader. And as long as they hold at least 51% of the work, chances are that will happen again and again. With this power they could: 1. control what transactions get in to the blockchain and 2. mine a “shadow” blockchain and perform a double-spend by swapping it with the public blockchain. I think (1) is way more powerful given the cost to perform a 51% attack.

How does Proof of Work protect against this attack? As of 2021, the cost to control 51% of the bitcoin hashing power for just an hour is in the billions of USD. The sheer amount of work required protects bitcoin from a central power.

Proofm of Work incentivices miners with transactions fee per-mined-blocked. If a miner invests more power into bitcoin, increasing their share of all the power being poured into bitcoin from say 20% to 25%, there is a 5% higher chance they will mine a block and get more fees. They do not however, “control” 5% more of bitcoin. They have the same amount of influece as they did before due to the leaderless consensus: zero.

transaction fee market

There is an “artificial” blocksize which limits the amount of transaction per second on the bitcoin blockchain. Transactions which pay higher fees are selected into a block. The scarce resource in this market is bytes on the blockchain.

This leads to a few questions.

The blocksize debate back in 2015 is bitcoin’s most famous holy war. As with all holy wars, there was a lot of noise coming from parties with different interests. I personally believe most of the noise was generated by parties which valued bitcoin succeeding quickly over bitcoin succeeding at all (e.g. my company survives if bitcoin is mass adopted in 2 years or my company fails, in which case I don’t care about bitcoin cause my company just failed).

My take on answering the above questions with the least amount of noise:

Bitcoin’s only value proposition is consensus without leaders, if that is degraded there is no point to bitcoin (might as well use a simple, centralized database). The limit should be kept low to encourage the highest value consensus. Second layer applications are responsible for increasing transactions per second and developing more value on top of the layer one consensus.

value as currency

Bitcoin’s value is entirely determined by it’s blockchain consensus. That is all it offers. Compare this to a cryptocurrency like Ethereum which promises more features. It’s value is not only its consensus, but the features it offers. I think it is much harder to put a number on this than bitcoin’s robust simplicity. In some sense the value of Ethereum is circular. Its measuring its own ever growing feature set. I don’t think this is a desired characteristic of currency.

further reading


Bitcoin is transactions, and the blockchain orders them.

Transaction outputs are indivisible chunks of bitcoin currency

  "version": 1,
  "locktime": 0,
  "vin": [
      "txid": "7957a35fe64f80d234d76d83a2a8f1a0d8149a41d81de548f0a65a8a999f6f18",
      "vout": 0,
      "scriptSig" : "3045022100884d142d86652a3f47ba4746ec719bbfbd040a570b1deccbb6498c75c4ae24cb02204b9f039ff08df09cbe9f6addac960298cad530a863ea8f53982c09db8f6e3813[ALL] 0484ecc0d46f1918b30928fa0e4ed99f16a0fb4fde0735e7ade8416ab9fe423cc5412336376789d172787ec3457eee41c04f4938de5cc17b4a10fa336a8d752adf",
      "sequence": 4294967295
  "vout": [
      "value": 0.01500000,
      "scriptPubKey": "OP_DUP OP_HASH160 ab68025513c3dbd2f7b92a94e0581f5d50f654e7 OP_EQUALVERIFY OP_CHECKSIG"
      "value": 0.08450000,
      "scriptPubKey": "OP_DUP OP_HASH160 7f9b1a7fb68d60c536c2fd8aeaa53a8f3cc025a8 OP_EQUALVERIFY OP_CHECKSIG",



Inputs are more interesting!

Each input contains:



Theoretically, the scriptPubKey could contain any script. But back in the early days, bitcoin limited this to a handful of “standard” types probably to keep stupid things from happening. This can be circumvented with P2SH.


Pay to Public Key Hash

Why did the OG bitcoin support both P2PK and P2PKH (key vs. key hash)?

Hash indirection was added to lower space requirements and make it marginally easier (less mistakes) for human users to copy/paste things. Hashes also hide keys from public view until they actually want to be spent.


Tough to find a more influential opcode in Script than OP_CHECKSIG. There isn’t a “do less” opcode so it sets the bar for bare minimum requirements of a transaction. It forces an owner to prove they are the owner and prove that they agree to where they are now sending their bitcoin.


Pay to Script Hash

OP_HASH160 [20-byte-hash-value] OP_EQUAL

Not sure what triggers bitcoin to run this special execution, but looks like the scriptPubKey must be encoded with the 05 version: base58check.Encode("05", redeemScriptHash). It sounds like it might just look for the OP_HASH160 [20-byte-hash-value] OP_EQUAL pattern in the scriptPubKey.

<OP_0> <sig A> <sig C> <redeemScript> <OP_HASH160> <redeemScriptHash> <OP_EQUAL>

To identify a P2SH transaction on the blockchain to a user, the user can construct the agree’d upon script and generate the P2SH address, then scan the blockchain




A timelock can be applied on the transaction to make it valid only after the time has passed. Useful for signed, offchain transactions that you don’t want spent right away and could still invalidate by spending out of the same output as the timelocked transaction.

Inputs can be timelocked.

Outputs can be timelocked through opcodes.


same amount input/outputs

For example, let’s take two transactions, one from Alice to Carol and one from Bob to Dave. Alice has two chunks of coins worth 2.3 and 1.4 bitcoin, and she wants to pay Carol 3.2 bitcoin. Bob has chunks of 3 and 2 bitcoin, and wants to pay Dave 4 bitcoin.

Simplified, these transactions look like so:

2.3 + 1.4 = 3.2 + 0.5


3 + 2 = 4 + 1

(The 0.5 BTC and 1 BTC outputs are change.)

Merged together, the CoinJoin transaction would look like so:

3 + 2.3 + 2 + 1.4 = 4 + 3.2 + 1 + 0.5

Although the transactions were merged, it’s trivial to rediscover which inputs paid which outputs, and, therefore, also which inputs can be matched together as belonging to the same sender.

Unequal amounts discussion


BIP47 // Reusable Payment Code

A way to easily have a new address on every payment Reusable Payment Codes.

BIP141 // Segwit

a weird name for moving signature data out of transactions

Move witness data into a separate data structure in a block. The transaction data that describes its effects remains in the original location.

Introduced 2 new transaction types to match the most used P2PKH and P2SH: P2WPKH and P2WSH



BIP340 + BIP341 + BIP342 // Taproot

This proposal covers a lot of ground.

Schnorr signatures

All the new features depend on Schnorr signatures replacing ECDSA signatures.

In BIP340.

Schnorr signatures history

Merklized Abstract Syntax Trees (MAST)

P2SH has a few weaknesses

A Merkle Tree is a hash tree which allows efficient and secure verification of the contents.

An Abstract Syntax Tree is splitting a program flow into a tree. Since Script doesn’t have loops, this can easily be described as a DAG.



Deep dive