Understanding Bitcoin via classroom exercise

Example: Requires 9 / 11 people

• 1 Customer
• 1 Merchant
• 7 to 9 Bitcoin nodes

• Set up:
  • See diagrams/explainer in the attached Figjam - Activity Schematic.
  • Get three student volunteers to play the roles of Customer (Alice), Merchant (Bob), and Bank.
• Act out the sequence of events:
  • Customer- browsing the store online and finds an item for $25, which they want, and informs the Merchant they would like to purchase
  • Merchant- asks for payment.
  • Customer- sends card information to Merchant
  • Merchant- forwards information to the Bank (identifying both their own and the identity/information), requesting payment of $25
  • Bank collects information about the Customer and Merchant (Alice and Bob) and checks that the customer’s balance is sufficient.
  • Deducts $25 from Alice’s account, adds $24 to Bob’s account, takes $1 for the service
  • The Merchant receives a thumbs-up from the Bank and ships the item to the customer.
• Comments:
  • Bob and Alice must have a relationship with a bank.
  • Bank collects identifying information about both Bob and Alice.
  • Bank takes a cut.
  • Bank must be trusted to hold the custody of each participant’s money at all times.

• Set up:
  • See diagrams/explainer in the attached Figjam - Activity Schematic.
  • Replace Bank with nine students who will play the role of a Computer (Bitcoin Nodes/Miners) in a network to replace the Bank.
• Each of the 9 Computers has a complete historical record of all past transactions ever made (thus accurate balances without forgeries), as well as a set of rules:
  • Verify transaction is properly signed (thekeyfitsthelock)
  • Broadcast and receive valid transactions to peers in the network, throw out invalid ones (including any that attempt to spend the same funds twice)
• Update/Add records periodically with new transactions received from “random” computer provided all contents are valid (note: we are ignoring, for now, the Proof of Work component to all this, for simplicity), otherwise reject these and continue as before until the next “random” computer sends an update
  • The proper amount was rewarded if the contents were valid.
• Act out the sequence of events:
  • Customer- browsing the store online and finds an item for $25 that they want, and informs the Merchant they’d like to purchase
  • Merchant- asks for payment by sending the customer an invoice/address from their wallet.
  • Customer- constructs a transaction (sending $25 worth of BTC to an address provided by the Merchant) and broadcasts it to the Bitcoin Network.
• Computers- receive the transaction and verify:
  • There is at least $25 of BTC in the address being sent from
  • The transaction is signed properly (“unlocked” by the customer)
  • If not the case, then the transaction will not be propagated through the network, and if so, then it propagates and is held in waiting.
  • Merchants can check that the transaction is pending and waiting.
• One computer is “randomly” chosen to propose to finalize the proposed transaction by broadcasting “a block” containing it; if it checks out, they will receive a BTC reward.
  • OPTIONAL/ADVANCED - instead of randomly selecting a Computer, simulate mining by having Computers roll dice until some predetermined outcome occurs (e.g., the first one to roll double sixes is selected)
  • It can also play out what would happen if two Computers win approximately simultaneously, resulting in a chain split.
  • Computers check the validity, update/add records to their ledgers if rules are met, and broadcast the transaction block to peers.
  • The randomly chosen computer receives a reward for proposing a valid block.
  • Merchant checks transaction was finalized; thus, funds were received, and the item was sent to the customer.
• Comments:
  • Notice there was no need for a pre-existing banking relationship.
  • No third party needed to facilitate; replaced by code/incentives.
  • No data collection by anyone outside the direct exchange, and only the necessary amount must be exchanged between participants (e.g., shipping address).
  • No trust is required between the people (other than the Merchant sending the item), like a cash purchase in many ways.
  • The money is owned directly by the individuals.
  • The Bitcoin ledger is depicted in dollars for simplicity, but in reality, it is BTC.
  • We simulate a single transaction being broadcast, but in reality, multiple transactions are pending in the network, and blocks include thousands of transactions at once. Nodes also verify that no double-spend transactions are pending (I would discard all but one in this case).
• Cheating scenarios:
  • What if the customer did not have $25 BTC?
    • They would not be able to create the transaction because “unlocking” and “ownership” are the same thing, and computers check that the transaction is properly signed; otherwise, they reject it
  • What if the randomly chosen computer attempts to “change the ledger”?
    • The block would be rejected, as every other computer has a complete history and would notice the change, violating one of their rules.
    • Random Computer would not get a reward, and no transactions from their block would be finalized.