In December 2020, Bitcoin Association launched the Bitcoin SV Academy with an introductory course on Bitcoin Theory.
This Introduction to Bitcoin Theory course covers the design of Bitcoin as a system as prescribed by Satoshi Nakamoto. This course is open to anyone who is interested in Bitcoin and is the beginner course in this series. Some technical experience would be helpful to complete the course, however it is open to anyone regardless of experience.
To help you gauge whether this course is a good match for your academic aspirations, we’ve provided you with an outline of the course material, course reviews and feedback from one of the course alumni.
To give you further insight in the course, this blog offers you a compilation of insightful questions from our Discord channel - with answers provided by the very individuals who create the course material.
Introduction to Bitcoin Theory Course - FAQ
Q: "When a coin or combination of coins cannot be found in the user’s wallet that makes an exact value as requested for the payment, the wallet creates a second output which is paid to another address from within the user’s wallet. It sends the overflow amount which was over and above the required payment value back to the sending party as ‘change’. This money is spent back into a script that the wallet knows how to spend and is immediately received back into the wallet’s balance as spendable funds."
Does this mean we will always need more than one address to send funds from that address?
In other words, is there a minimum number of addresses a wallet software should have to send funds?
Does this mean an address can only spend exact funds??
A: Not exactly, the same address can have multiple coins sent to it via different transactions as well. When you spend them, the wallet needs to include those multiple UTXOs. The quoted statement was using an example where even multiple addresses can be used to collect the coins to be spent. It's quite flexible really.
Q: I have a question on proof-of-work (POW). Do hashers keep track of already-tried Nonce value? Or do they use certain rules (ex> sequentially) to prevent duplicate computation? I was wondering because if they do, it could be a disincentive for hashers to constantly add new tx as it would change the merkle root and they will need to start hashing from the beginning.
A: This is true only for the current block discovery. After every block the rest of the data apart from the nonce changes, so any old nonce values won’t matter. Also the difficulty is adjusted every 2016 blocks.
Q: I am at the compacting blocks section of the course. If the nodes don’t store the transaction data, who does? What I mean is, when I upload a file or picture using an app like bitcoinfiles or Twetch, where does the file get saved for me to retrieve using the tx id if the nodes do not store them?
A: This is dependent on the application you have used. There is no guarantee that commercial storage providers will store and make data available. They could offer this service for a fee.
Q: Within the current block discovery, the Merkle root keeps changes as new txs are added, so hashers will need to try random nonce every attempt, am I correct?
If they don't add any new tx, then the Merkle root will remain the same, and the chance of finding the nonce will keep increasing if they try the nonce with a certain rule (ex> sequentially).
What is preventing hashers from doing this?
A: Typically miners will keep the merkle root fixed (so does the block template they have prepared for the current cycle) and change the nonce during block discovery. The transactions received during this period will go to mempool and shall be added to the next block.
Q: Block header also has Time field for the current block timestamp as seconds since 1970-01-01T00:00 UTC.&
If hashers want to have merkle root fixed for the purpose of optimisation, how do they keep the Time field fixed? They cannot know the timestamp for when the block will be found in advance.
A: The time (stamp) for each block is calculated as per the specifications described in the IEEE open-source IEC 61850 ‘uint32_t’ implementation (also known as unix time) : 32-bit calculation of the number of seconds since 1970.
There is a flexibility allowed in the protocol for having a latency between different nodes as long as that difference is within an acceptable range. The latency or discrepancy allowed in Bitcoin for timestamps between miners is calculated based on two factors:
The timestamp in a block needs to be greater than the statistical median ‘distance’ from the timestamps stored in the last 11 mined blocks. This means that you can’t have a time lower than the time stored in the 6th block before the candidate block (the minimum value limit).
It must be lower than the ‘network-adjusted time’ plus 7,200 seconds (the maximum value limit).
Basically your node software will keep track of the time (unix time) difference between all the nodes it is connected to. It takes all of these times and calculates a median of these and the current approximate unix time to give the network adjusted time.
Q: Why can't spammers DDOS miner's tx pools with invalid transactions/signatures, as miners don't know whether they are valid or not before they have checked them? Or can they but there are just too many (distributed) miners?
A: Miners can simply ban IP addresses that send invalid transactions. This is basically the same as a website banning an IP that tries to login too many times with the wrong password.
Q: When a node rejoins the network, they connect to other nodes and request the records of all transactions and blocks that have been seen on the network since they were disconnected
If I join the network in 2050, does that mean I will have to download the entire transaction history?
A: If we are talking about nodes as defined in the white paper then yes, they ought to download the entire ledger.
If you are saying you want to join in 2050 as a user then you will either just get the headers, or build a working blockchain from the headers plus selective information you are interested in. There is no reason for a user to download the entire ledger, nor for even an application to run a fully synced version of the node software as only entities actively involved in block production, validation and publication should do that.
Q: ‘When a node joins the network, it downloads the entire ledger.’ Is that the same as saying downloading the 4.2mb header per year?
A: No, it will at least download the headers and the UTXO set. The UTXO set will be every spendable coin relating to their application’s users (their working blockchain). They should not need to get early transactions whose outputs have all been spent and can be stubbed off the merkle trees by keeping only the branches they are part of.
Q: What are the different transaction types?
A: Most transactions up until recently were Pay-to-Public-Key-Hash (P2PKH), where the recipient will provide a (ripemd160(sha256(pubkey)) to the payer. In future there will likely be many more transactions transferring tokens, iterated payment channels for streamed content, calculations and R-Puzzles.
Bitcoin was designed to support every kind of business transaction that can be conceived. The solution was to create a fully featured script language. It will be up to businesses and their specific use cases for how they will leverage script for their stack.
If an enterprise has many transactions of a particular type being pushed to the network they may strike a deal with a transaction processor to have them specialise in processing theirs, or offering processing for a discounted rate on provision the transactions can be included in a block in a less timely manner.
