May 21, 2023
Transactions are data structures that encode the transfer of value between participants in the bitcoin system. Each transaction is a public entry in bitcoin’s blockchain, the global double-entry bookkeeping ledger.
An actual transaction looks very different from a transaction provided by a typical block explorer.
In bitcoin, there are no coins, no senders, no recipients, no balances, no accounts, and no addresses. All those things are constructed at a higher level for the benefit of the user, to make things easier to understand.
The concept of a balance is created by the wallet application.
Outputs are discrete and indivisible units of value, denominated in integer satoshis. An unspent output can only be consumed in its entirety by a transaction.
If you have a UTXO worth 20 bitcoin and want to pay only 1 bitcoin, your transaction must consume the entire 20 bitcoin UTXO and produce two outputs: one paying 1 bitcoin to your desired recipient and another paying 19 bitcoin in change back to your wallet.Why is it done this way?
The exception to the output and input chain is a special type of transaction called the coinbase transaction, which is the first transaction in each block. This transaction is placed there by the “winning” miner and creates brand-new bitcoin payable to that miner as a reward for mining. This special coinbase transaction does not consume UTXO; instead, it has a special type of input called the “coinbase”. This is how bitcoin’s money supply is created during the mining process.
Transaction outputs consists of two parts:
As you can see, the transaction contains two outputs. Each output is defined by a value and a cryptographic puzzle.
When transactions are transmitted over the network or exchanged between applications, they areserialized.
Serialization is the process of converting the internal representation of a data structure into a format that can be transmitted one byte at a time, also known as a byte stream.
The process of converting back to POJO is called deserialization or transaction parsing.
Transaction inputs identify which UTXO will be consumed and provide proof of ownership through an unlocking script.
The input contains four elements:
Transactions on their own seem incomplete because they lack context. They reference UTXO in their inputs but without retrieving that UTXO we cannot know the value of the inputs or their locking conditions.
Fees = Sum(Input) - Sum(Output). That means you must account for all inputs, if necessary by creating change, or you will end up giving the miners a very big tip.
For e.g., if you consume a 20-bitcoin UTXO to make a 1-bitcoin payment, you must include a 19-bitcoin change output back to your wallet. Otherwise, the 19-bitcoin “leftover” will be counted as a transaction fee and will be collected by the miner who mines your transaction in a block.
Eugenia, the director of a children's charity in the Philippines, received numerous small donations totaling 50 bitcoin. When she tries to make a payment for school books, her wallet needs to combine many small payments (UTXOs) into a single transaction (increasing the size). This larger transaction size requires a higher fee, even though the amount being spent remains the same.
Bitcoin’s transaction validation engine relies on two types of scripts to validate transactions: a locking script and an unlocking script.
A simple script, 2 3 OP_ADD 5 OP_EQUAL demonstrates the arithmetic addition operator OP_ADD, adding two numbers and putting the result on the stack, followed by the conditional operator OP_EQUAL, which checks the resulting sum is equal to 5.
Any combination of locking and unlocking scripts that results in a TRUE value is valid.
For e.g., one can use the part of the arithmetic example (above) as the locking script:
3 OP_ADD 5 OP_EQUAL
combined with an unlocking script:
The validation software combines the locking and unlocking scripts and the resulting script is
2 3 OP_ADD 5 OP_EQUAL
When the above script is executed the result is OP_TRUE, making the transaction valid.
Not only is this valid transaction output locking script, but the resulting UTXO could be spent by anyone with the arithmetic skills to know that the number 2 satisfies the output.
Transactions are valid if the top result on the stack is TRUE (0x01), any other non zero value, or if the stack is empty after the script execution is FALSE or if script execution is halted explicitly by an operator, such as OP_VERIFY, OP_RETURN, or a conditional terminator such as OP_ENDIF.
In the original bitcoin client, the unlocking and locking scripts were concatenated and executed in sequence. For security reasons, this was changed in 2010, because of a vulnerability that allowed a malformed unlocking script to push data onto the stack and corrupt the locking script.
In the current implementation, the scripts are executed separately with the stack transferred between the two executions. (How will this prevent the exploit, since the stack is common?)
First, the unlocking script is executed, using the stack execution engine. If the unlocking script is executed without errors, the main stack is copied and the locking script is executed.
Let's consider an example: Alice makes a payment of 0.015 bitcoin to the cafe's bitcoin address. The transaction output is locked with a script that requires the following conditions to be met:
OP_DUP OP_HASH160 <Cafe Public Key Hash (their address)> OP_EQUALVERIFY OP_CHECKSIG
To satisfy this locking script, an unlocking script is needed, which takes the form:
<Cafe Signature> <Cafe Public Key>
When these two scripts are combined, they form a validation script:
<Cafe Signature> <Cafe Public Key> OP_DUP OP_HASH160 <Cafe Public Key Hash (their address)> OP_EQUALVERIFY OP_CHECKSIG
When this combined script is executed, it will result in TRUE only if the unlocking script fulfills the conditions set by the locking script. In simpler terms, the result will be TRUE if the unlocking script contains a valid signature from the cafe's private key that corresponds to the specified public key hash.Execution Pointer starts:
How can digital signatures present proof of ownership of a private key without revealing a private key?
The digital signature algorithm used in bitcoin is the Elliptic Curve Digital Signature Algorithm, or ECDSA.
ECDSA is used by the script functions OP_CHECKSIG, OP_CHECKSIGVERIFY, OP_CHECKMULTISIG, and OP_CHECKMULTISIGVERIFY.
A digital signature serves three purposes in bitcoin.
Each transaction input and any signature it may contain is completely independent of any other input or signature. Multiple parties can collaborate to construct transactions and sign only one input each.
A digital signature is a mathematical scheme that consists of two parts:
The signature generation algorithm uses a random key k, as the basis for an ephemeral private/public key pair. The value of k is not important, as long as it is random. If the same value k is used in the signing algorithm on two different transactions, the private key can be calculated and exposed to the world.
One should use an industry-standard algorithm for deterministic initialization of k defined in RFC 6979.-----> To Bitcoin Network
Subscribe to the newsletter to learn more about the decentralized web, AI and technology.