Stanford CS251: Lecture 9

Lecture 9: Wallet & Anonymity

Wallet

A user has a lot of bitcoin address, each of which is H(p_k) or H(script). A wallet manages p_k/s_k, post/verify transactions,  and show balances. A wallet can be Cloud wallets like Coinbase or desktop based like Electrum or hardware-based like Trezor. SPV or Simplified Payment Verification clients are not full mining nodes but can verify incoming payments. An SPV downloads all the block headers and then specifically requests a list of addresses which are in your wallet to fetch the transactions associated with those addresses from a server.  The server returns the relevant transactions associated with those addresses and the corresponding Merkle proof of that.

Wallet backup

Don’t generate random keys but have a 128-bit seed K0. S_ki = HMAC(K0, ). P_ki = g^S_ki. So, only K0 has to be backed up. Bitcoin has 2048 words (11-bit). 128-bit seed requires 13 words including error correction.

For further security, split the wallet into an offline cold Wallet which contains K0 and an online hot wallet which contains Pk1, Pk2,… but cannot spend funds.

Anonymity

Weak: pseudonymity has a reputation but suffers from linkability. If a single post/transaction links to you, then all posts link to you. Therefore, anonymity goes down over time.
Strong: Complete unlinkable posts/transactions. Fraud detection and spam filtering are hard in this.
Business needs anonymous payments. Individuals need it, even thieves need it.

Bitcoin is not anonymous. Linking different accounts/transactions of the same entity is almost always possible. Finding whether A paid B is almost always possible.

Bitcoin Deanonymization:

  1. Network Layer – If enough nodes collude, one can connect different addresses belonging to the same IP. To avoid this connect Bitcoin over Tor.
  2. Blockchain – “idioms of use”. H1 – If they are two inputs to a transaction, they belong to the same entity. H2 – change address is controlled by the same entity which controls the input address.
    Ex 1: In 2013, in an experiment, using these two heuristics, 12 M Bitcoin addresses were reduced to 3.3M clusters. They identified 1070 addresses by interacting with entities eg. depositing money in Coinbase => 2200 clusters (1.8M addresses, 15%) de-anonymized.
    Ex 2: 3171 BTC stolen from Betcoin. The thief slowly peeled small amounts ~ 10 BTCs at a time to a new address. As soon as the thief deposits even a single one to Coinbase or any other exchange, the identity would be revealed.
    Ex 3: Cryptolocker encrypts the disk and asks for 2 BTC for decryption. 1200 BTCs was paid in 800 transactions to Cryptolocker addresses.

Two ways to make Bitcoin anonymous

  1. Mixing
  2. Anonymous alt coins (in Lecture 10)

Fully trusted mixer provides a receiver address. Alice sends the funds and hopes that she will get the funds back from a different address. The mixer will generate a single transaction returning those coins to everyone including Alice.  Some mixers steal money. Chain multiple mixers for more privacy. Coinjoin is trustless mixing. Using an online forum.
in: A_in: 5, B_in: 3, C_in: 2
out: A_change: 3, B_change: 1 (not anonymous)
A_0: 2, B_0: 2, C_0: 2 (anonymous)

Stanford CS251: Lecture 8

Lecture 8 – Alternative consensus

Puzzle solutions are probabilistic proof of work. A typical puzzle utilization function can be modeled as P(challenge, randomness – nonce, difficulty, …) -> true/false

P(c, r, d) for Bitcoin is SHA256^2(c, r, d) <= 2^256-d

There are many objections to this. It wastes resources on a meaningless computation, it is highly parallelizable and has returns of scale, randomness, long wait time between blocks, and leads to the creation of the mining pools. It is possible to redesign the system to make mining pools impossible but that would lead to only big players doing the mining. The centralized signing also eliminates all these issues and “private blockchain” is just a misnomer for a centralized blockchain.

Improvements (Cosigning)

  1. Cosigning in Ripple – consensus k out of n
  2. Cosigning in Stellar – arbitrary topology of who has to sign before something is trusted

Improvements (Block throughput)

BTC: one block every 10 mins
Testnet: one block every 5 mins
If block production rate is increased then there will be more forks leading to stale blocks. Current stale block rate is 1%. If the stale block rate increases, the cost of 51% attack goes down drastically. For example, if the stale block rate is 50% then the network efficiency is halved, so, a 51% attack only requires 33% of the network power to execute. Ethereum avoids this issue by using GHOST which not only includes the parent blocks but the uncle blocks as well. This allows Ethereum to have a block throughput of one block every 15 seconds.

Improvements (Bitcoin-NG)

Between two majors blocks A and B signed by Ka and Kb, we can have micro blocks. 40% mining fee of each micro block will go to Ka and 60% to Kb. Due to some attack(???), Ka can only receive < 42% mining fee.

Features of SHA-256

  1. Anonymous
  2. Progress-free – Probability of success is linearly proportional to time and mining power invested. Note that SAH256-squared is not progress-free.
  3. Fast to verify
  4. Supports precise difficulty adjustments
  5. Compact specification

Improvements (ASIC-Resistance)

The eventual goal is to minimize advantage a custom ASIC has over a PC. There are a few possible approaches.

  1. Complex algorithms or advanced CPU instruction set – For example, X11 took 11 SHA-3 finalists and applies them in succession.
  2. Memory Hardness – ASICs cannot have too much memory. For example, Litecoin uses scrypt which references previously calculated values and requires a 16KB buffer. The worst part is that the verification is as slow as computation. Also, Litecoin ASIC mining advantage over Litecoin PC mining is higher than Bitcoin. An important problem is to come up with an algorithm which is memory-hard to compute but memory-easy to verify. Cuckoo hash works but is apparently broken.
  3. Moving target – Change the hash functions every few months. The question then remains is that who picks the new hash functions.

Do we want ASIC resistance?

  1. ASIC miners due to their investment are most loyal to the crypto they are mining.
  2. ASIC resistant cryptocurrency can be attacked via botnets or rented resources on the cloud.

Improvements (Proof of Storage)

Store something useful like the library of Congress. (ashishb’s note: Filecoin came out later)

Improvements (Useful Proof of work)

Rather than do the SHA256 calculation, perform useful work like SETI@Home or Folding@Home. Not all solutions are equally likely though. An example is PrimeCoin, where the proof of work is to calculate Cunnigham chain, p1, p2, … pk, such that, pi = 2 * p(i-1) + 1. The goal is to find a chain whose length is determined by the difficulty level. p1 is composed of a value from the previous block and a nonce.

Improvements (Proof of stake)

Based on the stake one can vote on the blockchain. This can lead to oligopoly. Peercoin implements the proof of stake. H(c, r) <= 2^(256 – d – s) where s is the coin stake which consists of the sum of the coins with each coin holding being weighted by the time it was last use. So, a crypto puzzle is easier for someone who is sitting on the coins for a while.

Improvements (Proof of Deposit)

Choose a time to such that the fund movement is not allowed for the ti time frame, and then you are allowed to mine.

Nothing at stake problem

All vanilla proof of stake consensus suffers from nothing at stake problem. In case of proof of work, you can only mine on one chain at a time. In case of proof of stake, since no resources are involved, one can build on as many chains in parallel as possible. Slasher mechanisms have been designed to punish anyone caught doing this.

Improvements (Round-robin signing)

NXT coin uses this approach where a signer is elected every key block and can sign a set of blocks between the two key blocks. All signers have to be online and the new signer is the owner of the coin r such that r = H(H(b1) || H(b2) || H(b3) …). Chance of being a miner is proportional to how much you own. If you skip a signer, you lose money (???)

Improvements (Casper)

Casper is Ethereum’s planned proof of stake. There will be node validators who will put tickets on the fork. One fork will win and everyone else will lose money.

Stanford CS251: Lecture 7

Lecture 7: Community, Economics, and Politics

  1. David Chaum – digital cash in 1981
  2. Satoshi Nakamoto – Oct 2008, bitcoin.org was registered in Aug 2008
  3. Genesis block was mined in Jan 2009
  4. First BTC payment – Feb 2010
  5. First online exchange – July 2010, the price went up 10x by then
  6. First GPU miner – Aug 2010
  7. First mining pool – Sep 2010, Satoshi disappeared at this point
  8. Silk road launched – Jan 2011
  9.  First BTC conference – Nov 2011

Bitcoin requires three levels of consensus

  1. Consensus on blockchain – transaction history
  2. Consensus on validity rules
  3. The consensus that BTC is valuable

A soft-fork happens when a certain miners start accepting a newer version of the transactions which is backward-compatible. This incentivizes other miners to move to that as well or else their mined blocks might not become part of the longest chain. Some examples of soft-fork are P2SH, Segwit, CLTV, CSTV. Such changes are made via Bitcoin Improvement Proposals (BIP).

A hard-fork happens where there is a disagreement on the blockchain rules. For example, bug fixes, crypto upgrades, Simplified Payment Verification (SPV).

Bitcoin block size is limited to 1 MB => 1 MB/10 mins => 1.7 KB/sec ~ 7 transactions per second are the system limits. Visa does ~20K transactions per second by comparison. In 2015, a hard-fork was tried to increase the block-size limit to 10 MB. Bitcoin community was split between Bitcoin core and Bitcoin XT. Bitcoin core wants to do nothing, they were supported by the miners. Bitcoin XT which wants to increase block size to 8 MB and double every year after that. XT lost. An accidental hard-fork happened in March 2013.

Economics

  1. Divisibility – 21M ~ 225 Bitcoins. 1 Bitcoin = 108 Satoshi ~ 227 Satoshi => 252 Satoshi units to trade
  2. Mining reward schedule has a deflationary impact on Bitcoin creation
  3. Tinkerbell effect – Everyone believes in something because everyone else does as well

Money is a means of exchange, a unit of account, and a store of value. Bitcoin is definitely a means of exchange, the other two questions are yet to be answered.

Stanford CS251: Lecture 6

Lecture 6: Bitcoin Miner interactions and Game Theory

Game Theory: P x S -> R x P
P: Players
S: Strategies
R: Rewards

Examples

  1. For the prisoner’s dilemma, tit-for-tat with some positive randomization is the best strategy.
  2. Trench soldiers in World War 2 decided to start aiming artillery at random “safe” locations instead of killing the enemy. This all happened without any communication.

Mechanism design: Design the rules of the game with the outcome you want.

If we thinking of Bitcoin mining as a game then miners are players and the different strategies they have to decide which transactions to choose (default: everything), which to relay (default: everything), which to extend(default: most accumulated work), etc.

Attacks

  1. Temporary block withholding – selfish mining
  2. Fee sniping attack
  3. Goldfinger attack
  4. Bribery attack
  5. Feather forking

Selfish mining

Miner generates a block but does not publish it. It keeps mining on top of that block. If someone else mines a block in the meanwhile then you don’t broadcast theirs but broadcast yours. It can be proven that if a miner has >= 33% mining power than withholding is a better strategy.

Fee Sniping

If an already mined block has a really high transaction fee then a miner might decide to re-mine that block to claim the transaction gee. Note that, Coinbase transactions mature after 100 blocks and cannot be spent till then.

Goldfinger attack

A 51% attack or something similar which destroys the value of Bitcoin completely. The attacker’s interest is that Bitcoin should go down in value

Bribery attack

A->B transaction has been added to the block and A might have received some physical goods as well in return. A bribes miners to mine on A->A’ transaction making A->B moot. There are multiple ways to bribe, apart from physical cash delivery, A can create a negative fee mining pool or pay-to-anybody transactions build on A->A’ to incentivize miners to mine on it.

Feather Forking

To censor a certain transaction. The attacker announces a credible threat that they will fork if a certain transaction makes into the blockchain. Miners will avoid including that certain transaction and the attacker pay no cost for this. For example, if the attacker has 20% mining power and is going to try up to 2 blocks to re-mine then the likelihood of success is 4%  but a miner does not want to take 4% chance of losing the mining fee.

Stanford CS251: Lecture 5

Lecture 5: Bitcoin mining

How to mine Bitcoin

  1. Download and run Bitcoin-core to run full Bitcoin node
  2. Listen for a new transaction, assemble a pre-block
  3. Solve the puzzle (~270 attempts)
  4. Broadcast the block
  5. Profit

The network runs on port 8333. Non-responding nodes are forgotten after 3 hours (5000-10000 nodes as of Sep 2016). Some seed nodes are hard-coded into the software. Zero transaction fee transactions were accepted until April 2012 before Satoshi Dice came around. Blocks are just an artifact of the mining process. Otherwise, it is just a stream of transactions. Changing the network layer is easy. Changing the protocol layer to add new opcodes is hard.

Types of mining

  1. CPU mining – 220 – 224 hash/sec => 246 seconds (4 million years) to mine a block
  2. GPU mining(2010-2011) – 227 hash/sec with a single card
  3. FPGA mining(2011-2012) – 230 hash/sec. FPGAs are not designed for continuous use though.
  4.  ASIC mining (late 2012-present) – 240 hash/sec for 100 USD (100 watt) for 16 nm feature size. 50% overclocking leads to 25% error => 12.5% more revenue!!!

70% of mining is in China due to the lower price.
Even with ASIC miner like Ant miner S9 which has 12 TH/sec (243 hash/sec), one has 66% chance of 0 blocks, 27% chance of 1 block, and 7% chance of 2 blocks in a year. Mining pool reduces this variance. The miners will show smaller work (240) regularly to prove that they are working.

Stanford CS251: Lecture 4

Lecture 4: Blockchains

80 bytes block consists of 32 bytes previous block hash, 32 bytes transactions Merkle tree hash, timestamp, bits, nonce, etc. Each block is <= 1MB to minimize the propagation times. Therefore, large transactions require more service fee to compensate miners to include the transaction in the block.

Miner’s transaction checks
  1. ScriptSig (from spending transaction) || ScriptPubKey (from funding transaction) executes and this should produce non-empty stack. Empty stack or zero is false.
  2. Transaction inputs are in the UTXO set.
  3. Sum of all outputs <= Sum of all inputs

As of Oct 2016, 43M UTXO, 475K unique addresses, and 15.9M BTC in circulation.

Transaction signature is over the whole transaction (except the signature itself) => miners cannot modify any portion of the transaction. P2PKH (Pay to public key hash) does not reveal the public key (but only its hash), this provides added security in terms of someone brute-forcing the public key. The signature scheme ECDSA does not have strong unforgeability which means that miner can change ECDSA pair (r, s) to (r, s’). This changes the transaction hash. Therefore, transaction hashes cannot be relied upon. Not knowing this fact lead to Mt. Gox collapse.  Segregated Witness, eventually, fixed this by moving signatures out of the transaction hash.

There are two types of transactions

  1. Pay to Public Key hash (P2PKH)
  2. Pay to script hash (P2SH)
    Funding transaction scriptPk: HASH160 H()  EQUAL  # Only hash of the script is exposed at the funding time
    Spending transaction scriptSig: <sig1> <sig2> ….<sigN> <redeemScript>
    Miner verifies that

    1. ScriptSig | ScriptPk -> true => script is correct
    2. ScriptSig -> true => script is satisfied
      This is different from what miner does for P2SH

Another example of P2SH is multi-sig: m out of n signatures required.
Redeem script: <2> <pk1> <pk2> <pk3> <3> CHECKMULTISIG
Bitcoin implement is buggy so it eats the first element of the ScriptSig, therefore, add a dummy first element <0>
ScriptSig: <0> <sig1> <sig3> <redeemScript>
Applications of multi-sig =>

  1. Co-signatory – 2 out of 2 signatures required
  2. Escrow – buyer will fund a 2-out-3 signatures transaction which two of the buyer, seller, and judge’s signatures.
  3. Micropayments – which accumulate and send together to save on the transaction fee.

Bitcoin Address

Base 58 – a-z, A-Z, 0-9 excluding {0,o, i, l} => 34 char addresses

Addresses for P2PKH starts with 1.
Addresses for P2SH starts with 3.

Stanford CS251: Lecture 3

Lecture 3: Bitcoin overview

There are three Bitcoin protocols

  1. Consensus Protocol – decides what the ledger is
  2. Transaction Protocol – assigns meaning to the ledger
  3. Network Protocol – the P2P protocol which decides what new should be added to the ledger

Consensus Protocol

Bitcoin fields
  1. (Virtual field) Hash – 4 bytes. SHA256-squared. This is not part of the block but calculated on the fly.
  2. Version – 4 bytes. Set to 3, might never change.
  3. Previous block – 32 bytes. Hash of the previous block on which we build this block.
  4. mrkl_root (Merkle root) – 32 bytes
  5. Time – 4 bytes. Timestamp of mining the block.
  6. Bits – 4 bits. This is the difficulty level.
  7. Lock time – 4 bytes. The transaction cannot be posted on the blockchain till the lock time constraint is met.
  8. Nonce – 4 bytes.  Random nonce tweaked to find a block with the right difficulty.
  9. n_tx & txn_data in the Merkle root is stored separately.

The nonce is only 32-bits, Changing that might not be sufficient to get the desired number of difficulty(70+ zeros). Therefore, changes can be made to the Coinbase transaction (explained below) to generate more randomness.

Block Validity Checks
  1. Puzzle solution – fastest check
  2. Correct difficulty
  3. Previous block
  4. The timestamp is plausible – (timestamp >2 hours local time or timestamp < median of last 11 blocks) then reject. Miner might want to collude and manipulate timestamp to keep the difficulty low – never happened but it is still a possibility.
  5. Valid transaction data, including the coinbase transaction – transaction check is the slowest since that involves checking multiple signatures.
Blockchain Validity checks
  1. The valid chain is the one that has the most difficulty in it. This is not the longest but commonly referenced as longest. The reason to prefer most work over longest is that anyone who is working in private can produce the longest chain with low difficulty.
  2. Rooted in the genesis block – This is hardcoded in the Bitcoin mining software

Coinbase transaction is the first transaction of the block where miner assigns new money to them based on the creation rate rules. It can contain an arbitrary string which can be changed to generate the hash of the desired difficulty. Order of transactions in the transaction Merkle tree also impacts the hash.

Difficulty calculation

Reset every 2016 blocks (= 2 weeks/10 minutes).
Dnew  = Dold * (tLast -tFirst)/(14 * 24 * 60)
This has an off-on-one error; it should have been 20150 and not by 20160. Difficulty goes up quickly. This cannot be changed, and it’s part of the Bitcoin ecosystem.

Transactions Merkle Tree

Binary tree with all the transactions in leaves. All parents are hashes of the children-concatenated. This is store outside the Bitcoin block hashes.

Transactions

Bitcoin has no notion of account and balances. Ethereum has. Bitcoin ledger consists of UTXO (unspent transaction outputs), which are outputs of a transaction. As soon as a UTXO is used as input of another transaction, it cannot be used again. Previous transaction output is reference via its hash and an index into its outputs. Therefore, each transaction uses all the UTXO inputs. This UTXO set is growing pretty rapidly as well. Small value UTXOs are nick-named dust.

Bitcoin is not limited to sending money to a public key address. All the money is spent via Bitcoin scripts. You send money to a function f(), and anyone who can produce an x such that f(x) is true can redeem it. The Bitcoin script is a stack-based language with no loops or backward jumps => code always finishes and is not Turing complete. It has no big number support or floating points either. What most transactions look like in theory is f(sig, key) { if key == k and verify(sig, key, transaction) { return true } }. This is expressed in a complicated Bitcoin script. This can be used for writing smart contracts. What happens in practice is more complicated. The UTXO (output transaction) has the redemption script “scriptPubKey” and the spending transaction (input transaction which is using the UTXO) specifies the signature “scriptSig”. Bitcoin VM runs “scriptSig || scriptPubKey” and waits for true as an output. Anything except true (including a crash) is a failure outcome. Try out the language here.

Some examples:

  1. OP_TRUE – Anybody can spend the script.
  2. <sig> <pubKey> – scriptSig and “OP_DUP OP_HASH160 <pubkeyhash?> OP_EQUALVERIFY OP_CHECKSIG” – scriptPubKey is the standard spending transaction.</pubkeyhash?>
  3. OP_RETURN – Nobody can spend. Proof of burn to get something else in return. OP_RETURN can be followed by 40 bytes of the data on the chain permanently.
  4. Multi-sig – k of n signers (joint control) or escrow.

Stanford CS251: Lecture 2

Lecture 2: Creating a digital currency

Desirable properties of a good digital ledger

  1. No deletion
  2. Temporal ordering
  3. Global consensus
  4. Semantic correctness
  5. Live – writable, no DOS, no censorship

Attempts to create a digital currency in the increasing order of sophistication.

  1. A signing key based approach can confirm the authenticity of the transaction but cannot prevent double-spend.
  2. Append-only ledger with signing keys ensures a temporal ordering and global consensus, thus, prevents double-spending. Sign “new transaction + hash of the previous transaction”.  But if there is a single trusted signing authority, it can still give different signing blocks to the different parties and engage in double-spend. Or it can append invalid transactions to the ledger.
  3. To reduce the risk, we can have n signers and require k <= n signers required for a transaction to be a valid part of the ledger.
  4. Further safety can be ensured by rotating the trusted signers. The signers will build on (one of the) longest valid chain. The signer will reject any chain with a bad block in it. If the majority of the signers is honest, this works. Otherwise, it does not. A malicious actor can perform a Sybil attack on the system by generating tons of signers who are participating in the system and hence, a majority of signers might end up representing a single entity.
  5. Bitcoin (Nakamoto consensus) treats everyone as a trusted signer. The signer in round n is the first signer to solve a proof-of-work (PoW) puzzle. There are no signing keys anymore. The random nonce of the block which leads to H(block) <2256 – d suffices as the valid proof of signing. Two signers can end up signing simultaneously, but eventually, one of the chains will become longest and wins. Each block ~ 1MB and each transaction ~512 bytes. After your transaction ends up in a block, wait for up to 6 blocks to ensure that a different chain won’t become the longest one. Majority of the mining power should be honest though, 51%  attack is possible on Bitcoin.

Stanford CS251: Lecture 1

Lecture 1: Introduction

Bitcoin is a cryptocurrency with distributed trust. The blockchain is a public append-only ledger. The append-only property is sufficient for having a currency.

Hash functions: H: M -> T where |M| >> |T| that is space of messages is larger than space of the hash. If H(m0) =H(m1) => collision. Hash function H is collision-resistant if it is hard to find the collision of H. For example, SHA-256 maps long strings to 256-bit hashes.

Bitcoin’s Hash function: H(m) = SHA256(SHA256(m)). Two rounds of SHA-256 are used since a single round is susceptible to Length Extension Attack.

Application of hash functions

  1. Binding commitments
    For software package T, publish H(T) on a secure location while T is distributed via insecure third-parties. The user will download T and verify that H(T) matches the published hash. For multiple files T1, … Tn, one needs individual commitments/hashes. A more space-efficient way is to use Merkle trees which still keeps the commitment size to one hash.
  2. Proof of Work
    For every email, the sender will solve a unique “puzzle” which takes ~ 1 second of CPU time. Solving this puzzle will cut down spamming drastically. The puzzle is to get Hash(email contents, s) < 2n/d. n is the bit-length of the hash function output. The value of d can be increased the difficulty of the puzzle. The sender would try different “s” until the solution is found.  It will take d * Time(H) to find the solution. A normal sender wouldn’t mind the amount of effort, but this will be a lot of work for a spammer sending millions of emails. This didn’t work because of sending email to mailing lists breaks down.

A hash function is Proof-of-work secure if the probability of finding a solution is proportional to time invested in it, or in other words, there is no way to do it better than the brute-force. It is strongly believed that SHA256-squared, the Bitcoin hash function, is POW-secure for difficulty d < 2128.

Digital Signatures

Three efficient algorithms

  1. Keygen – generates a Public Key (Pk) and Signing Key (Sk), latter remains secret.
  2. Sign – σ signature = sign(Sk, m)
  3. Verify – verify(Pk, m, σ) outputs “yes”/”no”

Given (mi, σi), the adversary cannot produce a new (m*, σ*).

Famous schemes

  1. RSA
  2. ECDSA – used by Bitcoin. Bitcoin specifically uses ECDSA Secp256k1. Sk– 256-bit. Pk – 512-bits (257-bits compressed). 512-bit uncompressed notation consists of 256-bit X and 256-bit Y coordinate, but since there are only two Y-coordinates, one positive and one negative, for a single X-coordinate, one can store X-coordinate + 1-bit polarity of the Y-coordinate in the compressed notation of 257-bits. The message is 256-bits and signature is 512-bits. The signature size is unusually large and newer schemes do much better on the signature size, but bitcoin is stuck with this. Since message length is 256-bits, ECDSA is used for signing the hash of the message. The transaction, thus, becomes an Authenticated Data Structure.
Append-only trusted ledger – an application of digital signatures
  1. Anyone can read
  2.  Anyone can ask the bank to add data to the ledger
  3. If the bank removes a transaction from the ledger, it will be caught

Setup – Bank will sign Transaction T0, then (T0, T1) then  (T0, T1, T2) and will publish these after every signature. If the bank now removes a transaction from the ledger, then everyone will notice that there are two blocks  (T0, T1, T2) and  (T0, T1, T3) with none being the prefix of the other => Transaction set “forked”.

Bitcoin takes this a step further to an append-only distributed ledger.

-->