Blockchain – Bitcoin as a Mainstream Case Study - II

Regular Bitcoin Transactions

I will intentionally ignore ‘coinbase’ transaction messages here because only miners use them and they are irrelevant to the rest of the bitcoin ecosystem participants, although they are the supply source of bitcoins that could be spent. Instead, I will focus mainly on explaining usage rules for ‘regular’ transaction messages, together with the mechanics of their validation by the bitcoin network and the ‘double spend’ protection.


Regular bitcoin transactions are bitcoin’s fundamental building blocks. Since every full node in the bitcoin network has the full current state of the bitcoin distributed ledger, they are all able to validate any new incoming message, which is about to impact the future state of the ledger. To make the process of validation easier and as efficient as possible, the regular bitcoin transaction messages must be formatted according to the agreed-upon standard.

Each bitcoin transaction message consists of (as shown at high-level picture above):

• Header (light blue portion), including ‘bitcoin protocol version’, ‘number of inputs’, ‘number of outputs’ and something called ‘block lock time’ (‘lock time’ basically specifies whether the transaction should be included in the blockchain block immediately after it is validated by the miner node or at some later time)
• One or more input records indexed from 0 up to (n-1) (light green portion)
• One or more output records indexed from 0 up to (m-1) (light orange portion)

Each current transaction input (shown as expanded on the right) contains:

• ‘Hash pointer’ to a previous transaction whose output is referenced by this input
• Index of the referenced output in the previous transaction. That output of the previous transaction always lists the bitcoin address of the initiator of the current transaction as the ‘receiver’ of some amount of bitcoins
• Unlocking script (called ‘scriptSig’) with an indication of its length. It contains the cryptographic proof supplied by the initiator of the current transaction that they are the owner of the key pair {‘sk’, ‘pk’} that can ‘unlock’ the ‘bitcoin spending conditions’, set in the previous transaction output and referenced by this input of the current transaction

Each output (shown as expanded on the right) contains:

• The amount of bitcoins being transferred from the bitcoin address, owned by the current transaction initiator, to some other bitcoin address
• Locking script (called ‘scriptPubKey’) with an indication of its length. Note that it is this Locking Script which specifies the ‘receiver’ bitcoin address together with the ‘bitcoin spending conditions’ for verifying that whoever later wants to ‘spend’ these bitcoins, is the legitimate owner of that ‘receiver’ bitcoin address.

Unspent Transaction Output (UTXO)

The unspent outputs of the previous transactions represent the so-called total Unspent Transaction Output (UTXO) waiting to be spent in future transactions. Bitcoin blockchain doesn’t maintain the individual balances for each of the bitcoin addresses. However, personal bitcoin wallet applications can scan the blockchain database content and the aggregate portion of the total UTXO for the specific bitcoin address (i.e., sums all UTXO outputs where the specific bitcoin address is listed as ‘receiver’ of bitcoins).

Bitcoin Transaction Verification

Who can spend bitcoins from the UTXO accumulated in the outstanding and ‘unclaimed’ outputs of the previous transactions? The answer is: whoever can prove that they are the legitimate owner of the {‘sk’, ‘pk’} key pair behind the bitcoin address, which was listed as the ‘receiver’ of bitcoins in the output of any of those previous transactions.


Let’s use the classic Bob and Alice example to explain how mining nodes verify that Bob is entitled to spend previously sent (i.e., transferred to) bitcoins to him by Alice. I will neglect paying the ‘miner fees’ as irrelevant to keep the description that follows as simple as possible.


Let’s assume that Alice, at some point in the past, owned a total of 1.6 BTCs (bitcoins), which she received in some earlier transaction. To make the diagram as uncluttered as possible, that transaction is not shown on the diagram.


At some point, Alice submitted the bitcoin transaction message (which is shown in the diagram below as Alice’s Transaction Message) in which she splits previously assigned 1.6 BTC into 2 transaction outputs: output #0 sends 0.8 BTC to Bob’s bitcoin address and output #1 sends 0.8 BTC back to her own bitcoin address (considered a simple ‘change’ equivalent). Both outputs of Alice’s transaction contain separate Locking Scripts. The output #0 Locking Script specifies spending conditions for Bob and output #1 Locking Script specifies spending conditions for Alice.

After network miners accept Alice’s transaction and put it in a block, its outputs are automatically considered as part of the new total UTXO. That’s why Alice’s transaction is labeled ‘previous’ – it is already part of the blockchain content.


Now, if Bob wants to ‘spend’ and send those 0.8 BTC (assigned to him by Alice) to Zoe’s bitcoin address, he must prepare his own bitcoin transaction message with 1 input and 1 output (sorry, no change left for Bob in this case).
Bob’s transaction input #0 references output #0 of Alice’s transaction and also contains the ‘Unlocking Script’. The Unlocking Script of Bob’s input #0 contains:

1. A digital signature (produced with Bob’s ‘sk’) of some selected standard transaction data combined from Alice’s and Bob’s transaction messages
2. Bob’s ‘pk’ that can be used to verify that digital signature

How will the verifying node ensure that the ‘Bob’ that submitted the ‘current’ transaction is the ‘real Bob’ who indeed owns the bitcoin address listed in the Locking Script of Alice’s transaction output #0? That’s where bitcoin scripting comes in handy as an automation tool. The verifying mining node simply executes the Unlocking Script from Bob’s transaction input #0, immediately followed by execution of Locking Script from Alice’s transaction output #0. If the final result of combined sequential execution of both scripts returns TRUE, Bob’s proven that he is entitled to spend those bitcoins from Alice’s output #0, otherwise, the transaction is discarded as invalid.


I won’t go into details of how the bitcoin scripting virtual machine manipulates the stack during the execution of the script commands. That has been explained in many articles already. Instead, I will try to describe the main goal of the execution of the script. Basically, the combined sequential execution of Bob’s Unlocking Script and Alice’s Locking Script must prove two things in order for Bob’s bitcoin transaction to be accepted as valid:

1. That Bob’s ‘pk’ when ‘double-hashed’ (first with SHA-256, then with RIPEMD-160) produces a 160-bit output, which exactly matches (bit by bit) the bitcoin address value that was specified inside Alice’s transaction output #0 Locking Script
2. That the supplied digital signature (inside Bob’s transaction input #0) of selected standard transaction data from Alice’s and Bob’s transactions, can be properly verified using the Bob’s supplied ‘pk’ (provided inside Bob’s transaction input #0).

If both steps 1 and 2 result in TRUE condition, then Bob’s right to spend these 0.8 BTC is successfully verified and the transaction can be added to the next blockchain block.

Double Spend Protection

After Bob’s transaction has been fully verified cryptographically, and Bob is proven as the legitimate owner of the ‘spendable’ bitcoins that were assigned to his bitcoin address, the miner must ensure that the referenced bitcoin amount of 0.8 BTC hasn’t already been spent by Bob in a different transaction. In order to protect the bitcoin network from double spending, the verifying mining nodes just need to scan the blockchain content between the blockchain block containing Alice’s transaction and the latest blockchain block. There is no need to go all the way back to the beginning of the blockchain, which makes the whole process of protecting against ‘double spending’ fairly efficient.

Conclusion

So as you could see, with bitcoin transactions, there is no need for any further transaction settlement. It is immediate, fully automated and very secure. The whole process behaves almost as if Alice gave Bob a 1$ bill first and then Bob handed it over to Zoe at a later time. The main difference is that in the case of physical cash, there is no need for proving cryptographically that Bob or Alice owns the cash. Physical possession of cash is the proof, while in the world of bitcoin digital currency, the ‘possession of bitcoins’ needs to be proven and verified cryptographically at the time when it is ‘virtually handed over’ to the next bitcoin address.


Although bitcoin-based payments avoid the need for settlement, they are currently having several orders of magnitude lower transaction processing throughput than the payment card-based systems, due to being completely public and open to everyone’s participation. All that must be managed with fairly complex consensus algorithms involving brute force proof-of-work, puzzle-solving calculations, etc.


But it is certainly an area to watch closely and study very carefully, because the underlying distributed ledger technology and the clever cryptography protection involved has the potential to make even existing EMV payment card payments ‘settlementless’ one day (why not when chips have all the cryptographic power the need?) and also to potentially improve efficiency of the clearing and settlement in any trading of other asset class.