Bitcoin part 7: Transactions

(By a timely coincidence, the total value of all Bitcoins in the world first exceeded $1 billion this week.)

Enough intellectual wanderlust. Let’s build Bitcoin.

First, we need a digital signature scheme. This is just a template for creating individual, unique trapdoor one-way functions, where each unique function is defined by a value called its public key. Each public key has a corresponding private key that permits inversion of the function. For example, in the Rabin scheme (introduced in part 4 that you skipped), the template is $f(x)=x^2\pmod{n}$, the public key is n, and the private key is the factorization of n.

There are many such beasts in the cryptological zoo. We will choose the “Digital Signature Algorithm over the Elliptic Curve secp256k1“. I did not invent the names, and the details are not important.

Hey, wake up!

What is important is that I can stop saying things like “You generate your personal trapdoor one-way function g(x) and announce it to the world”, and start saying “You generate your personal public/private key pair and announce the public key to the world”.

As we saw last time, digital signatures need a good cryptographic hash function. Here again, the cages in the cryptological zoo are crowded with them. We will use the NSA-sanctioned “Secure Hash Algorithm 2”. That is not important right now, either.

To summarize: A private key is just a number (or a few numbers) that let you generate digital signatures. The corresponding public key is just a number (or a few numbers) that let anyone verify those signatures.

Definition: A Bitcoin address is a public key.

Definition: A Bitcoin transaction is an instruction to transfer Bitcoins from one address to another, digitally signed using the private key corresponding to the “from” address.

(As usual, I am exaggerating a bit; both addresses and transactions are somewhat more elaborate than this. Especially transactions. We will revisit both later.)

If you like, you can think of a Bitcoin address as an “account”, and a transaction as a “signed check” drawing on that account. What makes these “accounts” so interesting, among other things, is that you can create them yourself — any time you want and as many as you want — without showing any ID to anybody. Assuming your private keys remain private (and, ahem, the digital signature scheme remains unbroken), it is literally impossible for anybody other than you to write a “check” against one of your “accounts”.

Suppose I want to transfer BTC 1.00 to you. How does that work? First, you give me one of your addresses; let’s call that “address #1”. Next, I need an address with some money in it; let’s call that “address #2”. I create an instruction that says “transfer 1.00 from address #2 to address #1”. I digitally sign the instruction using the private key for address #2, thus creating a transaction; let’s call that “Transaction A”. Remember an address is just a public key, so you can verify the signature using the public key.

Next, you check that there actually is BTC 1.00 associated with address #2. To prove that, I show you Transaction B, a properly signed transaction transferring 1.00 from address #3 to address #2. Then I show you Transaction C transferring 1.00 from address #4 to address #3. And so on…

…until we get all the way back to Transaction Z, a transaction that created BTC 1.00 from nothing and transferred it to address #26. We will come back to Transaction Z in a moment.

Notice that this scheme almost works. Each transaction (aside from Z) has one input (aka. “from address”) and one output (aka. “to address”). The input of each transaction is the output of a prior transaction. Only the person who controls the appropriate private key can transfer money from an address, but they can transfer money to any address they want. And anybody can verify the entire sequence of transactions without relying on any central authority.

Also, all of the addresses could belong to me, or all but #2 could belong to other people; you neither know nor care, because the transactions themselves contain all of the information you need to verify the signatures. This is a key feature of Bitcoin’s design: The separation of identity from account.

The only problem — other than that little detail about Transaction Z — is that this scheme permits double spending. I can sign one transaction transferring money to you, and another transferring the same money to someone else, and neither of you will know about the other.

Back in part 2, I mentioned that Bitcoin is ledger-based. This is why.

Bitcoin relies on a transaction ledger that is visible to the entire world. Until a transaction is on the ledger, it has not happened. In the example above, Transaction Z appears on the ledger first, then Transaction Y, and so on, all the way until Transaction A. Once Transaction A is on the ledger, you can be sure I have paid you, and that I cannot pay the same money to anyone else, because the ledger will reject any attempt to double-spend.

A transaction that creates money, like Transaction Z, is called a “coinbase transaction”. The Bitcoin ledger records ordinary transactions, coinbase transactions, and… that’s all.

We will see the details of the ledger soon enough. But first, what can someone do if they control the ledger? Well, they can create coinbase transactions, which means they can create money. That is obviously pretty important. Also they can add transactions, refuse to add transactions, or reverse (remove) transactions.

What they cannot do is spend other people’s money. Even complete control over the ledger does not allow anyone to create a valid transaction without knowing the private key for the transaction’s input.

I know, this installment was not my best. But at least now you know what appears on Bitcoin’s ledger. Up next is how the ledger itself gets maintained…

…after another brief detour.