The material in this presentation belongs to St. Francis Institute of Technology and is solely for educational purposes.

Distribution and modifications of the content is prohibited.

Blockchain
and DLT
(BLCH)
ITC801

Subject In-charge
Dr. Joanne Gomes
Professor Dept. of Information Technology SFIT
Room No. 317
email: jgomes@sfit.ac.in
Module 2
Lecture 6
Bitcoin
Topics:
• Bitcoin Concepts: Scripting Language and Transaction Scripts
• Block Structure
 Revision: UTXO
• Your wallet consists of bitcoins in the form of Unspent transactions (UTXO).
• After an output has been “used up” in a transaction, it cannot be used again.
• Unspent outputs (UTXO), however, are alive. They are available to be used in new
transactions
 Revision: Verifying Transactions
• A node will verify the transactions it receives by checking that its inputs have not
already been spent.
• If you try and use an output that has already been used in another transaction, your
transaction will be rejected by nodes.

Validated Rejected
 Revision: Wallet Balance
• Address Balances:
• If you want to work out the balance of an
address, add up all of the unspent outputs that
are locked to that address.
 Revision: Transactions Inputs and Outputs.
• Transactions Have Inputs and Outputs.
• Transaction inputs are the UTXOs being used, and transaction outputs are the
UTXO payment to the recipient plus any change.
• The difference between inputs and outputs is the fee, which miners collect for doing
the work.

• Sender will lock and receiver will unlock

 Revision: Output Lock
• An output lock is a set of requirements placed on an output. These requirements
must be met to be able to use the output in a transaction.

• It’s these locks that prevent us from spending each other’s outputs in a transaction,
as every output we receive is encumbered by a lock.
• A transaction is the process of taking existing outputs and creating new ones from
them; it’s during the creation of these outputs that we give each one a “lock”.
 Transaction Data Store on Blockchain
• So even though the blockchain is file of transactions, on a practical level you can
think of it as a storage unit for outputs.
• And when you want to send “your” bitcoins to someone, you simply refer to the
outputs in the blockchain that you are able to unlock:

• And when this transaction gets mined in to the blockchain, the outputs you used (as
inputs) will not be able to be used again.
.

locking scripts
Bob’s Bitcoin
address

locking scripts
Alice’s Bitcoin
address
unlocking
scripts
 Script Language
• Bitcoin uses a scripting language called script to implement transactions on the blockchain.
Scripting language is turing INCOMPLETE system (does not allow infinite loops.).

• Bitcoin Script is a simple, stack-based (LIFO) programming language that enables the
processing and validation of transactions on the Bitcoin blockchain.

• A script is simply a set of instructions that specifies how a UTXO is able to be spent.
• Script is used exclusively to lock and unlock bitcoin, not to build applications or run
programs.

• The use of scripts to lock outputs and unlock inputs.

• A bitcoin script restricts future spending of the sent bitcoins using the following;
– A hashed public key which is the destination Bitcoin address embedded in the script.
– A digital signature from the sender that proves ownership of the sent bitcoins by proving ownership
of the private key of the corresponding public key.
 Script Language
• The cryptocurrencies are programmable money.
• In Bitcoin, opcodes allow the programmability of the blockchain transactions.
• Bitcoin uses 256 opcodes(0 - 255), of these 116 are the most commonly used.

• They include opcodes to represent Constants, Flow Control operations, Stack Operations,
Splicing Operations, Bitwise Operations, Arithmetic Operations, Crypto Operations.

• Commonly used operations:

Opcode Operation
OP_TOTALSTACK Puts the input onto the top of the alt stack. Removes it from the main stack.
OP_ADD Pops two items off the stack, adds them together, and pushes the result back
onto the stack.
OP_IFDUP checking for duplicates on the stack
OP_EQUAL popping-comparison-pushing if equal
OP_CHECKSIG signature verification
 Script Language
• Flow Control operations • Stack Operations
OP_CODE DESCRIPTION OP_CODE DESCRIPTION
OP_NOP Does nothing. OP_TOALT Puts the input onto the top of the alt stack.
OP_IF If the top stack value is True, the statements are STACK Removes it from the main stack.
executed. The top stack value is removed. OP_FROM Puts the input onto the top of the main stack.
ALTSTACK Removes it from the alt stack.
OP_NOTIF If the top stack value is False, the statements OP_IFDUP If the top stack value is not 0, duplicate it.
are executed. The top stack value is removed.
OP_DEPTH Puts the number of stack items onto the stack.
OP_ELSE If the preceding OP_IF or OP_NOTIF or
OP_DROP Removes the top stack item.
OP_ELSE was not executed then these
statements are and if the preceding OP_IF or OP_DUP Duplicates the top stack item.
OP_NOTIF or OP_ELSE was executed then OP_NIP Removes the second-to-top stack item.
these statements are not. OP_OVER Copies the second-to-top stack item to the top.
OP_ENDIF Ends an if/else block. All blocks must end, or OP_PICK The item n back in the stack is copied to the top.
the transaction is invalid. An OP_ENDIF
OP_ROLL The item n back in the stack is moved to the top.
without OP_IF earlier is also invalid.
OP_VERIFY Marks transaction as invalid if top stack OP_ROT 3rd item down the stack is moved to the top.
value is not true. Top stack value is removed. OP_SWAP The top two items on the stack are swapped.
 Script Language
• Bitwise Operations • Arithmetic Operations
OP_CODES DESCRIPTION
OP_CODES DESCRIPTION OP_1ADD 1 is added to the input.
OP_INVERT Flips all of the bits in the OP_NEGATE The sign of the input is flipped.
input. disabled. OP_ABS The input is made positive.
OP_AND Boolean and between each bit in the OP_NOT If the input is 0 or 1, it is flipped.
inputs. disabled. OP_ADD a is added to b.
OP_OR Boolean or between each bit in the OP_SUB b is subtracted from a.
inputs. disabled. OP_MUL a is multiplied by b. disabled.
OP_XOR Boolean exclusive or between each bit OP_DIV a is divided by b. disabled.
in the inputs. disabled. OP_MOD Returns the remainder after dividing a by b.
OP_EQUAL Returns 1 if the inputs are exactly OP_LSHIFT Shifts a left b bits, preserving sign. disabled.
equal, 0 otherwise. OP_RSHIFT Shifts a right b bits, preserving sign. disabled.
OP_EQUALV Same as OP_EQUAL, but runs OP_BOOLAND If both a and b are not 0, the output is 1.
ERIFY OP_VERIFY afterward. OP_BOOLOR If a or b is not 0, the output is 1. Otherwise 0.
OP_NUMEQUAL Returns 1 if the numbers are equal, 0 otherwise.
OP_LESSTHAN Returns 1 if a is less than b, 0 otherwise.
OP_MIN Returns the smaller of a and b.
OP_MAX Returns the larger of a and b.
 Script Language
• Crypto Operations:
OP_CODES DESCRIPTION
OP_RIPEMD160 The input is hashed using RIPEMD-160.
OP_SHA1 The input is hashed using SHA-1.
OP_SHA256 The input is hashed using SHA-256.
OP_HASH160 The input is hashed twice: first with SHA-256 and then with RIPEMD-160.
OP_HASH256 The input is hashed two times with SHA-256.
OP_CHECKSIG Compares the signature against each public key.
OP_CHECKMULTISIG Compares the first signature against each public key until it finds an ECDSA
match. Starting with the subsequent public key, it compares the second signature
against each remaining public key until it finds an ECDSA match. The process is
repeated until all signatures have been checked or not enough public keys remain
to produce a successful result. All signatures need to match a public key.
OP_CHECKMULTISIGVERIFY Same as OP_CHECKMULTISIG, but OP_VERIFY is executed afterward.
 Transaction Scripts
• All Bitcoin transactions use Script to define how unspent outputs (UTXO) can be spent.
• Bitcoin’s transaction validation engine relies on two types of scripts to validate transactions: a
locking script and an unlocking script.
• A locking script
– It is a restriction placed on an output, and it specifies the conditions that must be met to spend the
output in the future.
– The locking script was called a scriptPubKey, because it contained a public key or bitcoin address.
• An unlocking script
– It is placed on the input is a script that “solves,” or satisfies, the conditions placed on an output by a
locking script and allows the output to be spent.
– Unlocking scripts are part of every transaction input, and most of the time they contain a digital
signature produced by the user’s wallet from his or her private key.
– The unlocking script is called scriptSig, because it usually contained a digital signature.
• When a transaction is validated, the unlocking script in each input is executed alongside the
corresponding locking script in the output to see if it satisfies the spending condition.
 Transaction Scripts
• A transaction can be seen as a collection of inputs and outputs. Inputs refer to
previously created UTXOs, while outputs generate new UTXOs. Therefore, when
creating a transaction each input spends a UTXO and each outputs creates one.

unlocking
scripts locking
scripts
 Transaction Scripts for Validation
• Every bitcoin client will validate transactions by executing locking and unlocking scripts together.

• For each transaction, the validation software will first retrieve the UTXO referenced by the input. That UTXO
contains a locking script defining the conditions required to spend it.
• The validation software will then take the unlocking script contained in the input that is attempting to spend
this UTXO and execute the two scripts.
• In the bitcoin client, the unlocking and locking scripts are executed separately with the stack transferred
between the two executions.
• First, the unlocking script is executed, using stack execution engine. If unlocking script executed without
errors, main stack (not the alternate stack) is copied and then locking script is executed.
• If result of executing the locking script with stack data copied from the unlocking script is “TRUE,” the
unlocking script has succeeded in resolving conditions and the input is a valid authorization to spend UTXO.
 Transaction Scripts
• The five standard types of transaction scripts are
– pay-to-public-key-hash (P2PKH),
– pay-to-public-key (P2PK)
– Pay-to-multi-signature (limited to 15 keys),
– pay-to-script-hash (P2SH), and
– data output (OP_RETURN)
 Pay-to-Public-Key-Hash (P2PKH)
• P2PKH is most commonly used script in bitcoin transactions
• These contain a locking script that restricts the output with a public key hash, more
commonly known as a bitcoin address.
• Transactions that pay a bitcoin address contain P2PKH scripts.
• An output locked by a P2PKH script can be unlocked (spent) by presenting a public key and
a digital signature created by the corresponding private key.

• Example: let’s look at Alice’s payment to Bob’s Cafe.

• Alice made a payment of 5 bitcoin to the Bob’s cafe’s bitcoin address.
• That transaction output would have a locking script of the form:

OP_DUP OP_HASH160 <Cafe Public Key Hash> OP_EQUAL OP_CHECKSIG

– The Cafe Public Key Hash is equivalent to the bitcoin address of the café.
• To satisfy above locking script, an unlocking script of the form is used:
<Cafe Signature> <Cafe Public Key>
 Transaction Validation P2PKH Example
• locking script:
OP_DUP OP_HASH160 <Cafe Public Key Hash> OP_EQUAL OP_CHECKSIG
• unlocking script: (Supplied by Bob to other nodes for validation)
<Cafe Signature> <Cafe Public Key> Validaton = Unlock script, Locking script
Locked Output by Alice
Bob’s Wallet Bob’s Transactions
Unlock lock
Blockchain 5 BTC Input Output
1 BTC 5 BTC 3 BTC
0.5 BTC 2 BTC

Bob’s UTXO
Bob’s New
Transactions
<Cafe Signature> <Cafe Public Key> OP_DUP OP_HASH160 <Cafe Public Key Hash>
OP_EQUAL OP_CHECKSIG
• <Cafe Signature>
• <Cafe Public Key>

• OP_DUP
• OP_HASH160
• <Cafe Public Key Hash>
• OP_EQUAL
• OP_CHECKSIG
• <Cafe Signature>
• <Cafe Public Key>

• OP_DUP
• OP_HASH160
• <Cafe Public Key Hash>
• OP_EQUAL
• OP_CHECKSIG
 Pay-to-Public-Key (P2PK)
• Pay-to-public-key (P2PK) is a simpler form of a bitcoin payment than P2PKH.
• With this script form, the long public key itself is stored in the locking script, rather
than a public-key-hash as with P2PKH earlier, which was much shorter.
• Pay-to-public-key-hash was invented by Satoshi to make bitcoin addresses shorter,
for ease of use. Pay-to-public-key is now most often seen in coinbase transactions,
generated by older mining software that has not been updated to use P2PKH.

• A pay-to-public-key locking script looks like this:

<Public Key A> OP_CHECKSIG
• Unlocking script to unlock above type of output is a simple signature, like this:
<Signature from Private Key A>
• Combined script:
<Signature from Private Key A> <Public Key A> OP_CHECKSIG
• CHECKSIG operator, validates the signature, matches the public key and returns
TRUE on the stack.
 Pay-to-Multi-signature-Script
• Multi-signature scripts set a condition where N public keys are recorded in the script
and at least M of those must provide signatures to release the burden.
• This is also known as an M-of-N scheme, where N is the total number of keys and M
is the threshold of signatures required for validation.
• For example, a 2-of-3 multi-signature is one where three public keys are listed as
potential signers and at least two of those must be used to create signatures for a
valid transaction to spend the funds.
• Earlier, standard multi-signature scripts are limited to at most 15 listed public keys.
• The general form of a locking script setting an M-of-N multi-signature condition is:

M <Public Key 1> <Public Key 2> ... <Public Key N> N OP_CHECKMULTISIG

• An unlocking script containing pairs of signatures and public keys:

OP_0 <Signature B> <Signature C>

 Pay-to-Multi-signature-Script
• E.g. A locking script setting a 2-of-3 multi-signature condition looks like this:
2 <Public Key A> <Public Key B> <Public Key C> 3 OP_CHECKMULTISIG

• An unlocking script containing pairs of signatures and public keys:

OP_0 <Signature B> <Signature C>
– OP_0 is simply a placeholder and is ignored by CHECKMULTISIG. It is required because
of a bug in the original implementation of CHECKMULTISIG where one item too many is
popped off the stack.

• The two scripts together would form the combined validation script:
OP_0 <Signature B> <Signature C> 2 <Public Key A> <Public Key B> <Public Key C> 3
OP_CHECKMULTISIG
• The condition is whether the unlocking script has a valid signature from the two
private keys that correspond to two of the three public keys set as an encumbrance.
 Disadvantage of pay to multi-signature script
• Ex: Mohammed, an electronics importer based in Dubai. Mohammed’s company
uses bitcoin’s multi-signature feature extensively for its corporate accounts.
• Mohammed’s company uses a multi-signature script for all customer payments,
known in accounting terms as “accounts receivable,” or AR.
• With the multi-signature scheme, any payments made by customers are locked in
such a way that they require at least two signatures to release, from Mohammed
and one of his partners or from his attorney who has a backup key.
• Pay-to-Multi-signature-Script is quite long (each key 520 bit long) and looks like this:
2 <Mohammed's Public Key> <Partner1 Public Key> <Partner2 Public Key> <Partner3
Public Key> <Attorney Public Key> 5 OP_CHECKMULTISIG
Each customer would have to use special bitcoin wallet software with the ability to
create custom transaction scripts.
Furthermore, the resulting transaction would be about five times larger than a simple
payment transaction, because this script contains very long public keys. The burden of
that extra-large transaction would be borne by the customer in the form of fees.
 Pay-to-Script-Hash (P2SH)
• Pay-to-script-hash (P2SH) was developed to resolve the practical difficulties of Pay-
to-Multi-signature-Script and to make the use of complex scripts as easy as a
payment to a bitcoin address.

• With P2SH payments, the complex locking script is replaced with its digital
fingerprint, i.e. a cryptographic hash.
• When a transaction attempting to spend the UTXO, it must contain the script that
matches the hash, in addition to the unlocking script.
• In simple terms, P2SH means “pay to a script matching this hash, a script that will
be presented later when this output is spent.”

• In P2SH transactions, the locking script that is replaced by a hash is referred to as

the redeem script because it is presented to the system at redemption time rather
than as a locking script.
 Pay-to-Script-Hash (P2SH)
• Complex script without P2SH
Locking Script 2 PubKey1 PubKey2 PubKey3 PubKey4 PubKey5 5 OP_CHECKMULTISIG
Unlocking Script Sig1 Sig2

• Complex script as P2SH

Redeem Script 2 PubKey1 PubKey2 PubKey3 PubKey4 PubKey5 5 OP_CHECKMULTISIG
Locking Script OP_HASH160 <20-byte hash of redeem script> OP_EQUAL
Unlocking Script Sig1 Sig2 redeem script

• Since the redeem script itself is presented later, as part of the unlocking script when
the output is spent, it shifts the burden in fees and complexity from the sender to the
recipient (spender) of the transaction.
 Pay-to-Script-Hash (P2SH)
• Redeem Script hash (20-byte): 54c557e07dde5bb6cb791c7a540e0a4796f5e97e
• A customer making a payment to Mohammed’s company need only include this
much shorter locking script in his payment.
• When Mohammed wants to spend this UTXO, they must present the original
redeem script (the one whose hash locked the UTXO) and the signatures necessary
to unlock it, like this:
<Sig1> <Sig2> <2 PK1 PK2 PK3 PK4 PK5 5 OP_CHECKMULTISIG>
• The two scripts are combined, First, the redeem script is checked against the
locking script to make sure the hash matches:
<2 PK1 PK2 PK3 PK4 PK5 5 OP_CHECKMULTISIG> OP_HASH160 <redeem
scriptHash> OP_EQUAL
• If the redeem script hash matches, the unlocking script is executed on its own, to
unlock the redeem script
<Sig1> <Sig2> 2 PK1 PK2 PK3 PK4 PK5 5 OP_CHECKMULTISIG
 Pay-to-Data Output (OP_RETURN)
• Bitcoin’s distributed and timestamped ledger, the blockchain, has potential uses far beyond
payments for applications such as digital notary services, stock certificates & smart contracts.
• Early attempts to use bitcoin’s script language for these purposes involved creating
transaction outputs that recorded data on the blockchain; for example, to record a digital
fingerprint of a file in such a way that anyone could establish proof-of-existence of that file on
a specific date by reference to that transaction.

• The use of bitcoin’s blockchain to store data unrelated to bitcoin payments was discouraged
because
– It burdened those running full bitcoin nodes with carrying the cost of disk storage for data that the
blockchain was not intended to carry.
– Moreover, such transactions create UTXO that cannot be spent, using the destination bitcoin
address as a free-form 20-byte field.
– Because the address is used for data, it doesn’t correspond to a private key and the resulting UTXO
can never be spent; it’s a fake payment.
– These transactions that can never be spent are therefore never removed from the UTXO set and
cause the size of the UTXO database to forever increase, or “bloat.”
 Pay-to-Data Output (OP_RETURN)
• In version 0.9 of the Bitcoin Core client, a compromise was reached with the introduction of
the OP_RETURN operator.
• OP_RETURN allows developers to add 80 bytes of nonpayment data to a transaction output.
• However, unlike the use of “fake” UTXO, the OP_RETURN operator creates an explicitly
provably unspendable output, which does not need to be stored in the UTXO set.
• OP_RETURN outputs are recorded on the blockchain, so they consume disk space and
contribute to the increase in the blockchain’s size, but they are not stored in the UTXO set
and therefore do not bloat the UTXO memory pool and burden full nodes with the cost of
more expensive RAM.

• OP_RETURN scripts look like this:

OP_RETURN <data>
• There is no “unlocking script” that corresponds to OP_RETURN that could possibly be used
to “spend” an OP_RETURN output. OP_RETURN is usually an output with a zero bitcoin
amount.
Thank You