Notes on Bitcoin Transactions

A transaction is a transfer of value that is broadcast to the network and collected into blocks by miners.

A transaction typically references a previous transaction output to new transaction inputs. The bitcoin input values are mapped to the bitcoin output values.

Bitcoin uses a counter intuitive UTXO (Unspent transaction output) model unlike traditional accounting models where old coins are destroyed and new coins are created for each transaction.

Naively lets say Alice owns 100 satoshis and wants to send/spend 50 satoshis to Bob, the transaction will reference the output with 100 and create 2 inputs each of 50 satoshis (assuming no transaction fees)

Practically for a transaction to be picked by miners a fee has to be collected.

The fee is the difference between the input value & output value

txFee = inputValue - outputValue

In its simple for standard transaction outputs nominates addresses and require a signature to spend it.

Lets look at the serialized transaction over the wire format:

Field Description Size in Bytes
Version Current blockchain version number (1) 4
Flag If present represent witness data (0001) 2 byte array
InCounter VarInt to represent the number of following input transactions 1-9 bytes
List of inputs the first transaction of a list of input transactions is the coinbase ListofTransactions
Witnesses A list of witnesses for each input transaction, omitted if flag is missing Variable
LockTime if non-zero 0xFFFFFFFF: block height or timestamp when transaction is final 4 bytes

Pay to Public Key Hash (P2PKH)

This is by far the most basic and common payment script on the bitcoin network.

The lock key contains a hash of the recipient public key unlike the P2PK

Lets try to understand the construction of it and how can we build a transaction using libbitcoin (C++) or btcd (golang) then broadcast it using any transaction broadcasting service https://en.bitcoin.it/wiki/Transaction_broadcasting

The ScriptPubKey or easily thought of as locking script. Its a script you put on the output to lock its spending by un intended recipients.
<[OP_DUP] [OP_HASH160] <Public Key HAsh> [OP_EQUALVERIFY] [OP_CHECKSIG]

76a914{hex of public key hash}88ac

You can only unlock this script if you have the private key to the public key hash in the script.

The owner of the public key hash need to present the original public key along with a valid signature in whats called

The ScriptSig is the unlocking script for the ScriptPubKey will go inside the input transaction that is redeeming the output

<Signature> <Public Key>

Lets rearrange and combine the ScriptPubKey and ScriptSig into a stack (Last In First Out) or (First In Last Out) to examine the mechanics of how the bitcoin script interpreter will process it

// ScriptSig Part
<{Signature}>

<{Public Key}>

// ScriptPubKey
[OP_DUP]

[OP_HASH160]

<Public Key Hash>

[OP_EQUALVERIFY]

[OP_CHECKSIG]
  • Push the signature

    <{Signature}>
  • Push the public key

    <{Public Key}>
    <{Signature}>
  • OP_DUP: the op code will duplicate the last item on the stack and push it to the stack

    <{Public Key}>
    <{Public Key}>
    <{Signature}>
  • OP_HASH160: the op code will hash the last item on the stack and push to the stack

    <{Public Key Hash}>
    <{Public Key}>
    <{Signature}>
  • Push the

    <{Public Key Hash}>
    <{Public Key Hash}>
    <{Public Key}>
    <{Signature}>
  • OP_EQUALVERIFY: the op code will check the the last 2 items are equal if not it will invalidate the transaction

    <{Public Key}>
    <{Signature}>
  • OP_CHECKSIG: the opcode will poop out the last remaining items and checks the validity of the signature for the public key and pushes true on the stack

Simply put:

  • Alice (sender) will put the hash of the public key of the recipient into the output of a transaction
  • Bob (receiver) to spend he will refer to the previous transaction output created by Alice and provide the correct public key and signature to redeem this output
0