Bitcoin Explained (V)

By | 2012-09-17

This is part V in my “Bitcoin Explained” series.

At the end of part IV we saw how a signature chain can be used to create an unstealable ownership record; but that a dishonest person in the chain can easily create multiple copies of a valid signature chain.

17283726152                17283726152
I will pay the owner...    I will pay the owner...
--------------------       --------------------
Alice owns this            Alice owns this
     signed Governor            signed Governor
Bob owns this              Bob owns this
     signed Alice               signed Alice
Charlie owns this          Charlie owns this
     signed Bob                 signed Bob
Dave owns this             Dave owns this
     signed Charlie             signed Charlie
Ernie owns this            Ernie owns this
     signed Dave                signed Dave
Harry owns this            Fred owns this
     signed Ernie               signed Ernie

Two valid signature chains, ending with two different owners.

The solution is one we have already seen. The block chain. Remember the block chain creates a timestamped public record. It’s not easy to create an analogy using our paper-based chain, but we can get the effect by making it temporarily centralised.

Imagine now that there is a central authority willing to accept and record copies of all bits of paper like this.

When Ernie signs ownership over to Harry; Harry wants to verify that this signature chain is valid. “Hello, central authority, this is Harry? Could you tell me the current owner of 17283726152?”, “Yes, send us a fax showing you are the new owner, and we will tell you.” … “Ernie was the previous owner, Harry is noted as the new owner”.

Done. It’s now impossible for Ernie to double-spend this paper, since as soon as Fred contacts the central authority for confirmation of Ernie’s ownership, they will tell Fred that that serial number has already been registered to Harry, with a signed confirmation from Ernie. Ernie, being the only person who could have done that will look suitably embarrassed at having been caught trying to double-spend.

Let’s unwind our analogy a little, the Bitcoin block chain is a public record. That means anyone can check it. The need for a central authority is now unnecessary. When a signed transaction is created, it is broadcast and will be part of the next payload added to the timestamping block chain. That timestamping, as we saw in part III, happens every ten minutes, which means for that ten minute period a transaction is susceptible to double spending attacks. Afterwards it is not. Note, as above, it is for Fred to check with the decentralised “central authority” that is the block chain that nobody else has already been given the coins Ernie is trying to give him.

Your identity in Bitcoin is not your name; it is your public key. That identity is then provable using your private key. So rather than your name as in the paper example above, making the public record a record of transfers from number to number, or public key to public key.

I will pay the owner...
28171 owns this
     signed 27371
10632 owns this
     signed 28171
99263 owns this
     signed 10632
63527 owns this
     signed 99263
23498 owns this
     signed 63527
19243 owns this
     signed 23498

New public keys can be created by anyone, on demand, whenever they wish. That means no identifiable information is stored in the public record (that’s not to say there can’t be some identifiable information stored elsewhere).

The “governor” in our analogy is representative of the coinbase transactions we spoke of in part IV, creating coins from nothing, which are given to the miners as their reward, and as the way in which new coins enter into the system. Once coins have been created, from then on, they are transferred forever; but that chain of transactions can always be traced back and back to the coinbase transaction that created them.

The Bitcoin software takes care of updating your balance, broadcasting ownership updates and checking for double spends automatically. All that faxing and ringing from our paper-chain analogy is unnecessary (obviously).

The Bitcoin network is going through these processes:

  • Listening for new blocks, and updating their local block chain copy and address balances as appropriate
  • Listening for new transactions (optionally, they don’t have to)
  • Miners including new transactions in their potential block
  • Miners broadcasting “solved” blocks with new transactions in
  • Generating new transactions as the user desires

What does a real double spend attempt look like though? Transactions are created by the spender, they construct a signed transaction block and broadcast it to the network. The transactions are relayed just as new blocks are, peer-to-peer. Either the beneficiary of the transaction has a client connected, or they don’t. If they are connected, then their software will note that a transaction sending them money is pending for inclusion in a block. If they aren’t connected then eventually that transaction will be included in a block by a miner and will be broadcast to the network. Eventually they will reconnect and their client will download all the latest blocks, and will again notice a transaction in their favour, and will update their balance. A double spend attempt will create a second transaction, spending coins that have already been used. Either nodes will have already seen the first transaction or they won’t. If they have, then the second attempt will simply be discarded and will never make it into a block. If some see the first and some see the second, then there is potential for a damaging block chain fork. However, block chain forks get resolved quickly (by chance, one miner will always find a block faster than another), and either the first spend or the second will be in the ongoing chain — so the winning chain will record the coins being spent only once.

The “successful” double spend then does not exist long term; it cannot, only one block chain can be valid. What can happen though is a single attacker spends the same coins in two places (possibly one of the places being to send the coins back to himself) within a very short window. It is up to acceptors of coins whether they want to risk giving up goods without confirmations in the chain.

Double spend attacks aren’t cheap in effort. To really try a double spend attempt, the attacker would need to have a large amount of computing power available to them on demand. They would have to synchronise their double spending attempts so that the two transactions are generated at logically separate points in the network (including their own subversive part of it) but at nearly simultaneous times; then they would still have a finite window before the honest nodes resolve the chain fork and discard one of the transactions. They also have to hope that the merchant isn’t using a double spend protection service — monitoring the network on their behalf for double spends. In short: nobody is going to be walking away with two yachts unless the yacht salesperson isn’t willing to wait an hour to be sure the funds have cleared.

Let’s recap then. Our transactions consist of a transfer of coins from a previously timestamped transaction, to a new recipient. That recipient, just like us, is identified by the public key part of a key pair they control. That means only they will be able to sign any future transaction spending those coins they have received. Broadcast transactions are validated and included in the distributed peer-to-peer timestamping block chain once every ten minutes (on average). More and more blocks are built on top of that block in an unfakeable chain. That chain is secured by the fact that each block requires a lot of computational effort to make it self-consistent; this makes it very difficult to replace by an attacker. Each block that is added adds to the work needed to replace all the previous blocks, so the timestamped transactions only become stronger as time passes.

That is, pretty much, it.

We’ll cover some miscellaneous outstanding details will be covered in part VI.

Leave a Reply