Bitcoin whitepaper. I recommended @longsilver read it today, and I hadn't done so. Now I have. It's only 9 pages! Get to it! :)

Here's a link to it. It's so short, I'm surprised I haven't read it previously!

It's very interesting to me, reading what started this all off, after having had about half a decade of involvement in the field!

Page 1

The abstract is quite informative:

Abstract. A purely peer-to-peer version of electronic cash would allow online payments to be sent directly from one party to another without going through a financial institution. Digital signatures provide part of the solution, but the main benefits are lost if a trusted third party is still required to prevent double-spending. We propose a solution to the double-spending problem using a peer-to-peer network. The network timestamps transactions by hashing them into an ongoing chain of hash-based proof-of-work, forming a record that cannot be changed without redoing the proof-of-work. The longest chain not only serves as proof of the sequence of events witnessed, but proof that it came from the largest pool of CPU power. As long as a majority of CPU power is controlled by nodes that are not cooperating to attack the network, they'll generate the longest chain and outpace attackers. The network itself requires minimal structure. Messages are broadcast on a best effort basis, and nodes can leave and rejoin the network at will, accepting the longest proof-of-work chain as proof of what happened while they were gone.

I wanted to state when the whitepaper had been written, so I looked it up and came across a Wikipedia page for Satoshi Nakamoto: https://en.wikipedia.org/wiki/Satoshi_Nakamoto

The page mentions that the first mined block, which is unlike all other blocks in that it has no parent block, contains this text which indicates that it's very unlikely it was created prior to 2009-01-03: "The Times 3 January 2009 Chancellor on brink of second bailout for banks".

It goes on to mention that Satoshi's BTC accounts have around 1 million BTC in them, currently worth around 18 billion dollars, and that the coins haven't moved at all since 2009. This is deflationary; it means that out of Bitcoin's 21 million coins that will ultimately be mined by 2140, a million of them appear to be "locked up" by the creator. They might be used at some point in the future, so they're not the same as the "burned/lost coins" others have analyzed. Looks like around a quarter of them are gone for good, according to articles from the past few months.

Anyway, back to the whitepaper. The first page ends with a description of the challenge of creating a system which doesn't require "trust", which is rather neat.

Page 2

Page 2 has a diagram, showing how the blocks are generated using the previous block as input (and also, shows how the first block doesn't have input from a previous block, as mentioned above). It goes on to describe a "timestamp server" which is one basis for the blockchain -- every block has a timestamp (and, by extension and somewhat common-sensical "duh" -- every block occurred in the past).

Okay, my parenthetical "duh" started me down a line of thinking, "what if we could create future blocks"? I think it would end badly, because if I created a "future block" that spent some coins, I could then create a "not-quite-as-far-in-the-future block" which spent the coins first, leading to a double-spend situation. So, I won't be working on a time-traveling coin. :)

Page 3

Page 3 starts with the heading, "Proof-of-Work" and references "Hashcash" which I hadn't heard of; this Wikipedia article describes it, mentioning that it was written up twice, once in 1992 and again by someone else in 1997.

That section describes how the blockchain is composed of "blocks stacked on top of other blocks" and if an older block needs to be redone, then all the blocks after it do as well. And mentions that later in the whitepaper it will be shown how "confirmations" make a double-spend attacker much less likely -- which is why we need to wait longer for our transactions to arrive.

Section 5 discussed how the network operations will behave. A neat aspect of it is that nodes will choose to work on "the longest chain" and will switch from a shorter chain to a longer chain, automatically, if one exists. Also, that nodes are "self-correcting" -- if it receives a block that's after the block it's expecting, it will know to request the block it doesn't have.

Page 4

Section six on page 4 starts with an excellent sentence, describing the block reward:

By convention, the first transaction in a block is a special transaction that starts a new coin owned by the creator of the block.

I really like the last paragraph, describing how an attacker who managed to assemble more CPU power than the honest nodes might be better off using that CPU power to generate new coins, rather than undermining the system. I really like how that relates to an observation I made about criminality a long time ago: if criminals were smarter, they'd go about accumulating their wealth in honest ways.

Section 7 describes saving disk space by reducing the blocks using a "Merkle Tree"; I'm not really familiar with this, although the diagram makes sense.

The section ends with a seemingly short-sighted quote at the end of page 4 (of 9! It's only nine pages long! Read it!!! We're almost halfway through! :) ) --

A block header with no transactions would be about 80 bytes. If we suppose blocks are generated every 10 minutes, 80 bytes * 6 * 24 * 365 = 4.2MB per year. With computer systems typically selling with 2GB of RAM as of 2008, and Moore's Law predicting current growth of 1.2GB per year, storage should not be a problem even if the block headers must be kept in memory.

The blockchain is currently around 155 GB, and cannot be kept in memory in any of the (rather powerful) computers I have. My laptop has 16 GB of RAM, and my tower has 32 GB.

And, I said "seemingly" because after careful re-reading, I almost deleted the above -- but then wanted to keep it in case others had the same (wrong) impression I did. Turns out he's just talking about empty block headers, not the block contents, so the blockchain being 155 GB is unrelated to his assertion, that all the block headers should fit in memory, since the maximum the block header size would grow would be 4.2 MB per year. I'm glad I took a second look! :)

Page 5

Section 8 starts page 5, discussing payment verification, and what an attacker would need to do to violate that. It ends with noting that:

Businesses that receive frequent payments will probably still want to run their own nodes for more independent security and quicker verification.

This is the difference between a "lightweight" wallet, like Exodus, and the "heavyweight" wallets, like Bitcoin Core which takes up 155 GB of my hard drive (and growing). It would be better for a business which did frequent transactions to have a "heavyweight" Bitcoin client (wallet), as it is less likely to be compromised. Meaning, the entity that created the "lightweight" wallet might be able to compromise the account (and, not just my account -- all accounts held in that lightweight wallet!). Exodus doesn't hold the private keys, and I've tested recovering coins from an Exodus wallet using the "pass phrase" (12 random words) which worked; but, it's still better to have to trust nobody, than to have to trust somebody.

Section 9 mentions something I just noticed today -- when I sent some coins to Changelly, it took a while (and I don't think it worked, so I've asked them for a refund) and after a little bit, I clicked on the "view this transaction on the blockchain" link. I saw the small amount (X) I had sent, but the transaction actually has two sends -- one for X, and another for the total in my wallet minus X! Those funds are still in my (Exodus) wallet, so it must be the case that the Exodus wallet creates new addresses internally? If I click on Wallet, then Bitcoin, then Receive, I see a ">" on the right; clicking that, I get one other address that coins could be sent to, to enter my wallet. However, that second address has been there for a while; and, the address that "all minus X" were sent to is not either of those two addresses.

So, there's more going on than I currently understand -- and that's okay! An analogy I like to make is, "I don't need to know the internals of a thing in order to be productive with it. For instance, a sales guy doesn't need to know the inner workings of a telephone and the telephone system, in order to make sales calls to benefit his organization."

That said, I do like to understand the inner workings of things, even if my productivity doesn't depend on it. I like to think this comes from my upbringing, especially watching The Greatest American Hero, who received a suit from aliens but lost the instruction book.

Which rhymes with a sign on the CFO's door at a company I used to work at, "Life is the only game in which the goal is to learn the rules." I love that. The more I understand how a thing works (and, how several things interact with each other), the closer I am to learning "the rules."

[Edit: Note that I didn't really describe this very well at all. @amec asked me about it, and I responded to him below with a much better version than the above -- which I'm keeping, for posterity, so search for "amec" to find the better version. Enjoy!]

Page 6

Section 10 starts page 6, and describes that even though all transactions are broadcast, the identity of the sender and receiver are hidden. This has later been "not-so-hidden" because the IP address of the sender is embedded in the transaction. And it ends describing exactly that risk, neat!

Section 11 has calculations in it so it's a little more complex. It starts with stating that even if an attacker gains more than 50% power, it still won't be able to arbitrarily give itself every coin in existence. The only mischief it would be able to do, would be to modify its own transactions, and specifically, can only take back money that it spent.

It includes a mention of "Gambler's Ruin" so I looked it up; it's a neat mathematical way of describing why the house wins in a casino -- even before the house uses games that favor the house!

All the calculations in this section lead to: waiting for a few confirmations makes it infinitesimally small that an attacker will be able to "claw back" the coins he just spent -- and above, it's described that this is the only way an attacker can modify the system: the attacker first needs to spend coins, and then manipulate the blockchain so the spend disappears.

An aside (who am I kidding, I think most of this is "asides" :) ), it mentions "Poisson distribution" and that makes me think of fish. :) (That's the word for it, in French, which I took in high school and recall very little of...)

Page 7

Pages 7 and 8 are mostly calculations (which seem to leave out defining the variables, but I didn't study statistics much); C code representing them; and output -- all to show that the probability of an attack succeeding reduces significantly, the more blocks one waits for.

Within the current block that the sender sent the coins in, there's a 100% chance that they'd be able to attack. The next block, though, there's only a 20% chance, and it goes down to 5%, 1%, 0.3%, 0.09%, and finally 0.02% chance to be able to successfully attack after six blocks have passed.

Reversing that, we get a 99.98% confidence level that, if we've waited six blocks, an attacker with unlimited credit won't be able to win against the "Gambler's Ruin" scenario which matches the blockchain's design. Really, really neat! Especially because all attackers will have less than unlimited credit.

@longsilver, thank you for motivating me to read the white paper!

Page 8

The conclusion starts and ends on page 8; page 9 is just references. It is also just a single paragraph, so I'll reproduce it here, and then marvel at it. :)

We have proposed a system for electronic transactions without relying on trust. We started with the usual framework of coins made from digital signatures, which provides strong control of ownership, but is incomplete without a way to prevent double-spending. To solve this, we proposed a peer-to-peer network using proof-of-work to record a public history of transactions that quickly becomes computationally impractical for an attacker to change if honest nodes control a majority of CPU power. The network is robust in its unstructured simplicity. Nodes work all at once with little coordination. They do not need to be identified, since messages are not routed to any particular place and only need to be delivered on a best effort basis. Nodes can leave and rejoin the network at will, accepting the proof-of-work chain as proof of what happened while they were gone. They vote with their CPU power, expressing their acceptance of valid blocks by working on extending them and rejecting invalid blocks by refusing to work on them. Any needed rules and incentives can be enforced with this consensus mechanism.

I find it fascinating that they took a problem, and provided a solution -- and, that this paper seems so "academic". This "simple solution" created an industry which currently has over a half-trillion dollar market cap (and Bitcoin makes up 55% of it!), and will surpass a trillion next year most likely!

From https://coinmarketcap.com/:

---

I hope this has been educational for you -- it definitely has been for me, and I thought I knew a lot about this stuff. :)

Enjoy!

---