A digital signature is an example of an asymmetric or public-key cryptographic primitive. It operates using two related keys, a public and a private one. The public one can be given to anyone, and the pair is known as a keypair. A digital signature acts to verify the signing of a given message and involves three algorithms: KeyGen, Sign and Verify. Their interaction was illustrated by Professor Meiklejohn in her Figure 1:

There are several standardised digital signature schemes, with the one being used in Bitcoin known as ECDSA (Elliptic Curve Digital Signature Algorithm). The curve used in Bitcoin is secp256k1, and ECDSA signatures are usually encoded and expressed as 64 alphanumeric characters.

So, digital signature is a process designed to provide confidence that an entity has signed a given message. A randomised algorithm (Sign) allows the holder of a private key (one of the outputs of KeyGen) to produce a signature (σ) on a message (m). The recipient of a digital signature uses a deterministic verification algorithm (Verify) to check whether the signature conforms to the public key of the sender. The digital signature of a transaction involving bitcoins enables the recipient (R) to be satisfied that the sender was entitled to transfer the relevant sum.

However, if the transaction process ended at that point, the ‘double-spending problem’ would remain and the solution to this problem in the Bitcoin White Paper was the use of a peer-to-peer distributed timestamp server to generate computational proof of the chronological order of transactions using a ‘proof-of-work’ system.

Section 4 of the Bitcoin White Paper is headed ‘Proof-of-Work’ and it explained:

‘To implement a distributed timestamp server on a peer-to-peer basis, we will need to use a proof-of-work system similar to Adam Back's Hashcash [6], rather than newspaper or Usenet posts. The proof-of-work involves scanning for a value that when hashed, such as with SHA-256, the hash begins with a number of zero bits. The average work required is exponential in the number of zero bits required and can be verified by executing a single hash.

For our timestamp network, we implement the proof-of-work by incrementing a nonce in the block until a value is found that gives the block's hash the required zero bits. Once the CPU effort has been expended to make it satisfy the proof-of-work, the block cannot be changed without redoing the work. …’

However, when it came to the Bitcoin Source Code, Satoshi implemented an improved proof-of-work function which departed from the system described in the Bitcoin White Paper, which contemplated that the target value would be set with leading zeros – as in Dr Adam Back’s ‘Hashcash’ paper. Instead, the code used a numerical comparison (whether the hash of a Block Header is equal to or below a set target number). It is true that being equal to or below a long target number implies there will be a number of leading zeros in the target number, whether in binary or hex or any other base. However, the improvement meant that the target number could be set precisely, which in turn allowed the difficulty to be very precisely adjusted. This improvement is relevant to an issue raised in the cross-examination of Dr Back which I address later.