- HTML Beautifier
- JS Beautifier
- JSON Beautifier
- XML Beautifier
These tools are all automated. Just copy/paste your text in one side, click a button, and a pretty version of your code shows up on the right side.
When it comes to whitepapers, we’re out of luck :-(
So, I took The Bitcoin Whitepaper and beautified it manually here.
Feel free to add comments in that Google Doc.
No information is missing or modified (except for the error I discovered and corrected)… It’s just reformatted to be easier to read and comprehend.
Enjoy!
My Observations
Below are my observations from beautifying the Bitcoin Whitepaper:
I. Satoshi Nakamoto is a:
1. Human
While manually prettifying the Bitcoin Whitepaper, I noticed an error in section 3 (Timestamp Server).
The Bitcoin Whitepaper says:
Each timestamp includes the previous timestamp in its hash, forming a chain, with each additional timestamp reinforcing the ones before it.
I believe it should say:
Each block includes the previous timestamp in its hash, forming a chain, with each additional hash reinforcing the ones before it.
"To err is human, to forgive is divine."
2. Genius
Satoshi was the first to combine cryptography, networking, game theory and economic incentives to create trust in a trustless, distributed environment to support a secure digital currency.
His genius was not in creating a digital currency, for that had already been attempted many times; it was in creating a system of economic incentives, based on cryptography, to drive a purely peer-to-peer version of digital currency that would allow online payments to be sent directly from one party to another without going through a financial institution.
This diagram from section 10 (Privacy) shows how Bitcoin breaks the flow of information only to identities; whereas, the traditional privacy model hides everything from the public.
3. Whitepaper Expert
The Bitcoin Whitepaper is a great study on the correct way to write a Whitepaper.
Frequently in the paper, Satoshi makes a factual statement, for example:
The incentive can also be funded with transaction fees.
And then provides supporting statements to provide insight into how it works:
-
If the output value of a transaction is less than its input value, then:
-
The difference is a transaction fee that is added to the incentive value of the block containing the transaction.
-
-
Once a predetermined number of coins have entered circulation, then:
-
The incentive can transition entirely to transaction fees and
-
Will be completely inflation free.
-
This format is concise, clearly describes business processes, and tells a good story.
LaTeX was the most likely software used to create the document, which is apparent when we observe the correctness and accuracy in the mathematical equations and diagrams.
Who used LaTex at the time of the writing of the Bitcoin Whitepaper?
-
Mathematicians
-
Statisticians
-
Engineers
-
Computer Scientists
-
Software Engineers from Academia
-
Linguists in the UK
-
Educators
-
Attorneys interested in the accuracy of their documents
-
Academic economists, especially those in the more math-y fields such as econometrics
-
Philosophers
-
Quantitative Psychologists
-
Formal Epistemologists
4. Sexist Male
Satoshi regularly used “he” (with no mention of “her”).
5. Helpful Realist
Satoshi is helpful and realistic when he suggested that businesses that receive frequent payments will probably still want to run their own nodes for more independent security and quicker verification.
6. Cypherpunk
The Cypherpunk Manifesto begins: Privacy is necessary for an open society in the electronic age. Privacy is not secrecy. A private matter is something one doesn't want the whole world to know, but a secret matter is something one doesn't want anybody to know. Privacy is the power to selectively reveal oneself to the world. … When my identity is revealed by the underlying mechanism of the transaction, I have no privacy. I cannot here selectively reveal myself; I must always reveal myself. Therefore, privacy in an open society requires anonymous transaction systems.
Since the Bitcoin protocol defines a means of eCommerce whereby parties participate in public yet completely anonymous transactions (free from a central authority) it appears that Satoshi was influenced by the doctrines of the cypherpunk movement.
7. Cryptoeconomics & Mechanism Design Expert
Cryptoeconomics combines cryptography and economic incentives to design decentralized protocols and applications.
Mechanism design is a field of economics that studies how to design protocols to incentivize rational actors to behave in desirable ways.
Mechanism design is the antipode of game theory. In game theory, we start with the game and analyze its outcomes according to the enjoyment derived by the player from their choices. In mechanism design, we start by defining desirable outcomes and work backwards to create a game that incentivizes players to act in ways that lead towards those outcomes.
Satoshi incentivized the Bitcoin miners to process transactions by providing them with two means of income:
- A block reward for solving the POW puzzle (it’s currently 12.5 BTC per block, which is currently $88,727.00) and
- A transaction fee for processing the transactions in that block that the miner adds to the Bitcoin blockchain. (Most transactions cost at least 0.5 mBTC and there are usually between a few dozen and 3,000 transactions per block. To see the latest blocks go here.)
“The iron rule of nature is: you get what you reward for. If you want ants to come, you put sugar on the floor.”
8. Investor, Trader, and Entrepreneur
Investors working in the field of high frequency trading would be most familiar with the concept of the Binomial Random Walk, as described in section 11 (Calculations). Satoshi understood that financial markets are not like a drunk, randomly staggering his/her way home; they can be manipulated by the profit-driven human psychology.
9. Insatiable Learner
Without being a voracious reader and thinker, could Satoshi have devised such an ingenious, peer-to-peer version of electronic cash that has changed the world?
10. C Programmer
Of the languages I’ve used in my professional career I can think of several that would be likely be more appropriate to use for a coding example rather than C, including:
-
Ruby
-
Go
-
Pascal
-
Javascript
-
Java
-
Scala
-
C#
-
Visual Basic
C is great for performance, not so great for illustrative purposes for a wide audience. In other languages, we can accomplish the same work with a lot fewer lines of code.
Note that the code snippet presented in the paper does not show the entire C program. I wanted to run it for myself to prove that the numbers presented were, indeed, correct.
Here’s the complete program:
/***************************************************************
* bwp-calc -- Calculations for the Bitcoin white paper *
* *
* Author: Lex Sheehan *
* *
* Purpose: Demonstration of Bitcoin white paper calculations *
* *
* Usage: Click the <Execute> button and see Results below. *
* *
* Notes: https://en.bitcoin.it/wiki/Bitcoin_whitepaper *
* *
* For a deep understanding of cryptocurrencies and *
* blockchain technology (including Ethereum) ... *
* Register at cryptocurrencies.developersclass.com *
***************************************************************/
#include <stdio.h>
#include <math.h>
double AttackerSuccessProbability(double q, int z) {
double p = 1.0 - q;
double lambda = z * (q / p);
double sum = 1.0;
int i, k;
for (k = 0; k <= z; k++) {
double poisson = exp(-lambda);
for (i = 1; i <= k; i++)
poisson *= lambda / i;
sum -= poisson * (1 - pow(q / p, z - k));
}
return sum;
}
int main() {
int num = 10;
int z;
double p;
double q = 0.1;
printf("q=%f\n", q);
for (z=0; z <= num; z++) {
p = AttackerSuccessProbability(q, z);
printf("z=%i P=%f\n", z, p);
}
int zTimes5;
q = 0.3;
printf("\nq=%f\n", q);
for (z=0; z <= num; z++) {
zTimes5=z*5;
p = AttackerSuccessProbability(q, zTimes5);
printf("z=%i P=%f\n", zTimes5, p);
}
puts("\nSolving for P less than 0.1%...\n");
q = 0.1;
puts("P < 0.001");
for (q=0.10; q <= 0.45; q+=0.05) {
p = 1;
for (z=0; p >= 0.001; z++) {
p = AttackerSuccessProbability(q, z);
//printf(">> q=%f z=%i p=%f\n", q, z, p);
}
// P is now >= 0.001, so take previous value of z
printf("q=%f z=%i\n", q, z-1);
}
}
// share URL: jdoodle.com/a/CNb
// embed URL: https://www.jdoodle.com/embed/v0/CNb
The output of running this code shows us that the probability of double spends drops exponentially to zero as the honest mining majority finds more blocks than potential attackers.
II. Error Discovered in Bitcoin Whitepaper
Yes, I found an error in the Bitcoin Whitepaper, albeit a minor one.
In section 2 (Timestamp Server) The Bitcoin Whitepaper says:
Each timestamp includes the previous timestamp in its hash, forming a chain, with each additional timestamp reinforcing the ones before it.
I believe it should say:
Each block includes the previous timestamp in its hash, forming a chain, with each additional hash reinforcing the ones before it.
First, let’s examine what a timestamp is and when it is created…
The timestamp is created at the moment the block of Bitcoin transactions is created. It is an Unix timestamp, which means it is an integer number. We can see it in the block header structure below:
Field
|
Description
|
Bytes
|
Version
|
Bitcoin protocol version number
|
4
|
hashPrevBlock
|
Hash of previous block in the chain
|
32
|
hashMerkleRoot
|
Hash of merkle tree root of this block’s transactions
|
32
|
Time
|
Creation time of this block (unix timestamp)
|
4
|
Bits
|
POW difficulty target for this block
|
4
|
Nonce
|
Counter used for POW algorithm
|
4
|
Next, let’s examine what a Unix timestamp is...
Bitcoin uses Unix timestamps, which are numbers that represent the numbers of seconds since Thursday, 1 January 1970.
We can use the developers console in our web browser to create a timestamp and print it out in an ISO8601 string format:
We can clearly see that a timestamp does not include another timestamp, or anything else for that matter; it is simply a number that represents the time (in seconds since 1 Jan 1970) at which the current block was created.
It’s the block header that includes the hashPrevBlock field.
Now, let’s examine what a hash consists of:
blockHash = SHA256Hash(Version, hashPrevBlock, hashMerkleRoot, Time, Bits, Nonce)
We see that a block’s hash is the result of sending all the data from the block’s header fields into our hash function; the result is a 64 byte string that looks like this:
00000000000000001588d80f3cb1d593cb198f485aef33ca926b58a62bcceda8
Clearly, Satoshi Nakamoto meant to say:
Each block includes the previous timestamp in its hashPrevBlock header field, forming a chain, with each additional hash reinforcing the ones before it.
To say ...
Each timestamp includes the previous timestamp in its hash, forming a chain, with each additional timestamp reinforcing the ones before it.
… is simply inaccurate.
Therefore, it’s the block hash that contains the previous timestamp and that’s what effectively links the blocks together (not the timestamp value)
The best visual explanation that I’ve found of how this works can be found here. There, you can see what happens; however, if you want to understand how it works, nothing beats implementing it yourself in your own blockchain.
That’s exactly what we do in the upcoming Cryptocurrencies Developers Class. Note that this class is conducted in person, in a small group seminar style. As such, places are strictly limited.
Other Bitcoin Whitepaper Mistakes
Implementation Inconsistencies
Others have cited mistakes, see below, but those mistakes are realized only after comparing the implementation to the words in the whitepaper.
Note that this article is limited to observations gleaned solely from The Bitcoin Whitepaper.
Below is a link to a description of known problems in Satoshi Nakamoto's paper, "Bitcoin: A Peer-to-Peer Electronic Cash System", as well as notes on terminology changes and how Bitcoin's implementation differs from that described in the paper.
Mathematics Notation Mistake
These mathematicians argue that the distribution of the number of blocks mined by the attacker should be called a Negative Binomial Distribution, rather than the Poisson law. They claim that luck should also be included in the calculations, but note that it really makes no difference in the end. In either case, the probability of double spends drops exponentially to zero as the honest mining majority finds more blocks, i.e., Bitcoin still works properly either way.
The Reference Client Mistake
Here it’s claimed that the biggest mistake of Bitcoin has to do with its source repository, where that one source repository defines how the protocol is implemented. The repository owners can change the block size, say whether Bitcoin addresses begin with a “1” or a “5”, etc. Nodes that run the Bitcoin protocol download client software from that single repository and generally accept it as as the reference client. This can be considered centralized form of development.
While this may be true, this is more of a deployment detail than a flaw in the whitepaper.
III. Unanswered Questions
Here’re some questions you may have after reading the Bitcoin Whitepaper:
-
What exactly is a Hash function and how does it work?
-
What really happens when miners solve those cryptographic puzzles? Doesn’t this imply that more and more energy will be consumed by more and more powerful CPUs over time? If so, how much heat do all these CPUs generate and how does this impact our global climate?
-
How does the consensus mechanism of rules and incentives actually work in practice?
-
Are RESTful APIs used in a peer to peer network, if not how do the nodes in the network communicate with other?
-
Aren’t there a Private Keys to go along with the Public Keys? (How are they created and stored?) How does the cryptography actually work?
-
How does the 51% Attack work in practice?
-
How can we trust the timestamp from trustless peers in a distributed network? How does that impact the Bitcoin protocol?
-
Why is the block hash 64 bytes, whereas the other hash values are 32 bytes? And why does it begin with a bunch of 0’s?
-
Is Bitcoin security determined more by the cryptographic proofs or by having a majority of honest nodes?
-
What is a practical example of a multi-input (or multi-output) transaction?
What questions do you have? (We’ll likely cover them all in our interactive class.)
IV. Gaining Understanding and Confidence
With all the scammers and talk about the Boom and Bust of Bitcoin, now more than ever is the time to deeply understand Bitcoin; not just the What’s of cryptocurrencies, but the How’s and the Why’s.
For me, the first time I really understood how Bitcoin works was after much effort:
-
Reading and studying Bitcoin for 15 weeks
-
Conferring with experts in the field
-
Programming peer-to-peer networking (Using Go and libp2p)
-
Creating and coding a gossip protocol (Of peers periodically picking and communicating its new favorite book)
-
Leveraging public key cryptography
-
Building Merkle Trees
-
And building a blockchain and my very own cryptocurrency: LexCoin
If you really want to “get it” that’s one way (the hard way).
Join me in class where I’ll:
-
Distill facts from fiction
-
Provide pertinent resources on a guided journey of learning
-
Provide well structured lab assignments
-
Provide starter projects (and completed solutions)
-
Provide insightful visual presentations
-
Provide a Certificate of Completion to attendees that finish the assignments
… and that’s just the 1st half of the course. In the 2nd half we cover the Ethereum blockchain.
I have condensed this class into an Immersive one week Master Class in Atlanta, GA.
The class location is TBD but will not be far from the airport.
I’m working on getting a package, discounted hotel deal for out-of-town attendees.
Register now, while seat are still available at https://cryptocurrencies.developersclass.com/products/register
Thanks, hope to see you in class! - Lex Sheehan
Lex Sheehan
Atlanta, GA
Software Engineer
LinkedIn lexsheehan