Ch7.

Advanced transactions and scrip

ting

Myongji University
Introduction
 In this chapter we will look at more advanced scripting and how
we can use it to build transactions with complex conditions

 First, we will look at multi-signature scripts

 Next, we will examine the second most common transaction scrip

t, Pay-to-Script-Hash

 Then, we will examine new script operators that add a time dime
nsion to bitcoin, through timelocks

2
multi-signature - introduction
 multi-signature scripts set a condition where N public keys are re
corded in the script and at least M of those must provide signatu
res to unlock the funds.

 This is also known as an M-of-N scheme, where N is the total nu

mber of keys and M is the threshold of signatures required for va
lidation.

 For example, a 2-of-3 multi-signature is one where three public k

eys are listed and at least two of those must be used to create si
gnatures for a valid transaction to spend the funds.

3
multi-signature – Locking script
 The general form of a locking script setting an M-of-N multi-sign
ature condition is:

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

where N is the total number of listed public keys and M is the thr
eshold of required signatures to spend the output.

 For example, A locking script setting a 2-of-3 multi-signature con

dition looks like this:
2 <Public Key A> <Public Key B> <Public Key C> 3 CHECKMULTISIG

4
multi-signature – Unlocking script
 The preceding locking script can be satisfied with an unlocking sc
ript containing any combination of two signatures from the privat
e keys corresponding to the three listed public keys. :

<Signature B> <Signature C>

 The two scripts together would form the combined validation scri
pt:

5
multi-signature – Validation
 When executed, if the unlocking script matches the conditions set
by the locking script, this combined script will evaluate to TRUE.

 In this example, the condition is whether the unlocking script has

a valid signature from the two private keys that correspond to tw
o of the three public keys set as an encumbrance.

6
multi-signature – A bug in CHECKMULTISIG(1)
 When CHECKMULTISIG executes, it should consume M+N+2 item
s on the stack as parameters.

 However, due to the bug, CHECKMULTISIG will pop an extra valu

e or one value more than expected.

 Let’s look at this in greater detail using the previous validation ex

ample:

7
multi-signature – A bug in CHECKMULTISIG(2)
 First, CHECKMULTISIG pops the top item, which is N.

 Then it pops N items, which are the public keys that can sign.
In this example, public keys A, B, and C.

 Then, it pops one item, which is M(how many signatures are nee
ded).

 Here M = 2. At this point, CHECKMULTISIG should pop the final

M items, which are the signatures.

8
multi-signature – A bug in CHECKMULTISIG(3)
 However, a bug in the implementation causes CHECKMULTISIG to
pop one more item (M+1 total) than it should.

 The extra item is disregarded when checking the signatures so it

has no direct effect on CHECKMULTISIG itself.

 If it is not present, when CHECKMULTISIG attempts to pop on an

empty stack, it will cause a stack error and script failure (marking
the transaction as invalid).

 Because the extra item is disregarded it can be anything, but cust

omarily 0 is used.

9
multi-signature – A bug in CHECKMULTISIG(5)

 Thus the unlocking script actually used in multisig is not:

 but instead it is:

 Therefore the correct script validation would look like this:

10
multi-signature – A bug in CHECKMULTISIG(4)

11
Pay-to-Script-Hash (P2SH) – Introduction(1)

 Pay-to-Script-Hash (P2SH) greatly simplifies the use of complex tr

ansaction scripts.

 For example, Mohammed’s company uses bitcoin’s multi-signatur

e feature extensively for its corporate accounts.

 Mohammed’s company uses a multi-signature script for all custo

mer payments, known in accounting terms as “accounts receivabl
e,” or AR.

 With the multi-signature scheme, any payments made by custom

ers are locked in such a way that they require at least two signat
ures to release, from Mohammed and one of his partners or from
his attorney who has a backup key.

12
Pay-to-Script-Hash (P2SH) – Introduction(2)

 The resulting script is quite long and looks like this:

 The resulting transaction would be about five times larger than a

simple payment transaction, because this script contains very lon
g public keys

 The burden of that extra-large transaction would be borne by the

customer in the form of fees.

 Finally, a large transaction script like this would be carried in the

UTXO set in RAM in every full node, until it was spent.

13
Pay-to-Script-Hash (P2SH) – Redeem Script (1)

14
Pay-to-Script-Hash (P2SH) – Redeem Script (2)

 This shifts the burden in fees and complexity from the sender to t
he recipient (spender) of the transaction.

15
Pay-to-Script-Hash (P2SH) – Example(1)

 Let’s look at Mohammed’s company, the complex multi-signature

script, and the resulting P2SH scripts.

16
Pay-to-Script-Hash (P2SH) – Example (2)

 This entire script can instead be represented by a 20-byte crypto

graphic hash, by first applying the SHA256 hashing algorithm and
then applying the RIPEMD160 algorithm on the result.

 A P2SH transaction locks the output to this hash instead of the lo

nger script, using the locking script:

17
Pay-to-Script-Hash (P2SH) – Example (3)

18
P2SH Addresses – Introduction(1)

 P2SH addresses are Base58Check encodings of the 20byte hash o

f a script, just like bitcoin addresses are Base58Check encodings o
f the 20byte hash of a public key.

 P2SH addresses use the version prefix “5,” which results in Base58
Check-encoded addresses that start with a “3.”

Base58Check Encoding

19
P2SH Addresses – Introduction(2)

20
P2SH Addresses - Benefits

 Complex scripts are replaced by shorter fingerprints in the transa

ction output, making the transaction smaller.
 Scripts can be coded as an address, so the sender and the sende
r’s wallet don’t need complex engineering to implement P2SH.
 P2SH shifts the burden of constructing the script to the recipient,
not the sender.
 P2SH shifts the burden in data storage for the long script from th
e output (which is in the UTXO set) to the input (stored on the bl
ockchain).
 P2SH shifts the burden in data storage for the long script from th
e present time (payment) to a future time (when it is spent).
 P2SH shifts the transaction fee cost of a long script from the sen
der to the recipient, who has to include the long redeem script to
spend it.

21
P2SH Addresses - Loss

 The redeem script is not presented to the network until you atte
mpt to spend a P2SH output.

 If you lock an output with the hash of an invalid redeem script, it

will be processed regardless.

 However, you will not be able to spend it because the spending t

ransaction will not be accepted because it is an invalid script.

 The network will accept the P2SH locking script even if it corresp
onds to an invalid redeem script, because it is one of the standar
d types and the script hash gives no indication of the script it rep
resents.

22
Data Recording Output (RETURN) - Introduction
 The use of bitcoin’s blockchain to store data unrelated to bitcoin pay
ments is a controversial subject.

 Those who object to the inclusion of non-payment data argue that it

causes “blockchain bloat”.

 Such transactions create UTXO that cannot be spent, using the destin
ation bitcoin address as a freeform 20-byte field.

 Because the address is used for data, it doesn’t correspond to a privat

e key and the resulting UTXO can never be spent; it’s a fake payment.

 These transactions that can never be spent are therefore never remov
ed from the UTXO set and cause the size of the UTXO database to for
ever increase, or “bloat.”

23
Data Recording Output (RETURN) – RETURN(1)

 In version 0.9 of the Bitcoin Core client, a compromise was reach

ed with the introduction of the RETURN operator.

 RETURN allows developers to add 80 bytes of non-payment data

to a transaction output.

 RETURN operator creates an explicitly probably un-spendable out

put, which does not need to be stored in the UTXO set.

 RETURN consume disk space and contribute to the increase in th

e blockchain’s size, but they are not stored in the UTXO set and t
herefore do not bloat the UTXO memory pool and burden full no
des with the cost of more expensive RAM.

24
Data Recording Output (RETURN) – RETURN(2)

 RETURN scripts look like this:

RETURN <data>

 The data portion is limited to 80 bytes and most often represents

a hash, such as the output from the SHA256 algorithm (32 bytes).

 Many applications put a prefix in front of the data to help identif

y the application.

8byte prefix : DOCPROOF

ASCII code : 44 4f 43 50 52 4f 4f 46

 There is no “unlocking script” that corresponds to RETURN.

25
Data Recording Output (RETURN) – RETURN(3)

 RETURN is usually an output with a zero bitcoin amount

 The execution of RETURN essentially causes the script to “RETUR

N” with a FALSE and halt.

 If a RETURN is referenced as an input in a transaction, the script

validation engine will halt the execution of the validation script a
nd mark the transaction as invalid.

 A standard transaction (one that conforms to the isStandard() che

cks) can have only one RETURN output.

26
Timelocks
 Timelocks are restrictions on transactions or outputs that only all
ow spending after a point in time.

 Bitcoin has had a transaction-level timelock feature from the begi

nning – nLocktime field in an transaction

 Two new timelock features were introduced(UTXO-level timelock

s)
– CHECKLOCKTIMEVERIFY
– CHECKSEQUENCEVERIFY

27
Transaction Locktime(nLocktime)
 Transaction locktime defines the earliest time that a transaction is
valid and can be relayed on the network or added to the blockch
ain.

 0(Zero)
– in most transaction to indicate immediate propagation and execution
.

 1 ~ 500 million
– It is interpreted as a block height.

 Above 500 million

– It is interpreted as a Unix Epoch timestamp(in second).

28
Transaction Locktime Limitation
 nLocktime has the limitation that while it makes it possible to spe
nd some outputs in the future.

 But, it does not make it impossible to spend them until that time.
– If Alice signs a transaction spending one of her outputs to Bob’s add
ress, and sets the transaction nLocktime to 3 months in the future.
– Bob cannot transmit the transaction to redeem the funds until 3 mon
ths have elapsed.
– But, Alice can create another transaction. Thus, Alice can spend the s
ame UTXO before the 3 months have elapsed.

 It means, the only guarantee is that Bob will not be able to redee
m it before 3 months have elapsed. There is no guarantee that B
ob will get the funds.

29
Check Lock Time Verify(CLTV)
 CLTV is a per-output timelock, rather than a per-transaction timel
ock as is the case with nLocktime.

 By adding the CLTV opcode in the redeem script of an output it r

estricts the output, so that it can only be spent after the specified
time has elapsed.

 CLTV restricts specific UTXO such that they can only be spent in f
uture transaction with nLocktime set to a greater or equal value.

30
CLTV example
 If Alice is paying Bob’s address, the output would contain P2PKH
script like below:
– DUP HASH160 <Bob's Public Key Hash> EQUALVERIFY CHECKSIG

 To lock it to a time, say 3 months from now

– <[current Unix epoch + 7,760,000] or [current block height + 12,96
0]> CHECKLOCKTIMEVERIFY DROP DUP HASH160 <Bob's Public Key
Hash> EQUALVERIFY CHECKSIG
– 7,760,000 = 90(days) * 24(hours) * 60(minutes) * 60(seconds)
– 12,960 = 90(days) * 24(hours) * 6

31
CLTV example(2)
 <expiry time> CHECKLOCKTIMEVERIFY DROP DUP HASH160 <Bob's Publ
ic Key Hash> EQUALVERIFY CHECKSIG

 When Bob tries to spend this UTXO, he constructs a transaction that refe
rences the UTXO as an input with his signature and public key.

 And Bob sets the transaction nLocktime to be equal or greater to the ti

melock in the CHECKLOCKTIMEBERIFY Alice set. And broadcasts the tran
saction.

32
CLTV example(3)

<expiry time> CHECKLOCKTIMEVERIFY DROP

33
CLTV example(4)
 CHECKLOCKTIMEVERIFY fails and halts execution, marking the transactio
n invalid if
– the stack is empty; or
– the top item on the stack is less than 0; or
– the lock-time type (height versus timestamp) of the top stack item a
nd the nLocktime field are not the same; or
– the top stack item is greater than the transaction’s nLocktime field; o
r
– the nSequence field of the input is 0xffffffff.

 Alice locked the UTXO itself, it is now impossible for either Bob a
nd Alice to spend it before the 3 month locktime has expired.

34
Relative Timelocks
 nLocktime and CLTV are both absolute timelock in that they spe
cify an absolute point in time.

 There are two relative timelocks in that they specify, as a conditio

n of spending an output, an elapsed time from the confirmation
of the output in the blockchain.

 The clock doesn’t start counting until the UTXO is recorded on th

e blockchain.

 Relative timelocks are implemented with both a transaction-level

feature and a script-level feature.

35
Relative Timelocks with nSequence
original meaning of nSequence

 nSequence
  is transaction-level relative timelock and can be set in
every transaction input.

 The nSequence field was originally intended (but never properly i

mplemented) to allow modification of transactions in the mempo
ol.

 Inputs with nSequence value below -1 (0xFFFFFFFF) indicated a tr

ansaction that was not yet “finalized.”
– It would be held in the mempool until it was replaced by another tra
nsaction spending the same inputs with a higher nSequence.

 Once a transaction was received whose inputs had an nSequence

value of -1 it would be considered “finalized” and mined.

36
nSequence as a consensus-enforced relative timelock

 
 Since the activation of BIP-68, new consensus rules apply for any transactio
n containing an input whose nSequence value is less than (bit 1<<31 is n
ot set).

 If the most significant (bit 1<<31) is not set, it is a flag that means “relativ
e locktime.”
– Transaction inputs with nSequence values less than are interpreted as having a
relative timelock.
– Such a transaction is only valid once the input has aged by the relative timelock
amount.

 Otherwise (bit 1<<31 set), the nSequence value is reserved for other uses
such as enabling CHECKLOCKTIMEVERIFY, nLocktime, Opt-In-Replace-By-Fe
e, and other future developments.

 A transaction can include both timelocked inputs (nSequence < ) and input
s without a relative timelock (nSequence >= ).

37
nSequence as a consensus-enforced relative timelock(2)

 The nSequence value is specified in either blocks or seconds, but

in a slightly different format than we saw used in nLocktime.

 A type-flag is used to differentiate between values counting block

s and values counting time in seconds.

 The type-flag is set in the 23rd least-significant bit (i.e., value 1

<<22).

 If the type-flag is set, then the nSequence value is interpreted as

a multiple of 512 seconds.

 If the type-flag is not set, the nSequence value is interpreted as a

number of blocks.

38
nSequence as a consensus-enforced relative timelock(3)

 When interpreting nSequence as a relative timelock, only the 16 l

east significant bits are considered. Once the flags (bits 32 and 2
3) are evaluated, the nSequence value is usually “masked” with a
16-bit mask (e.g., nSequence & 0x0000FFFF).

39
Relative Timelock with CSV
 There is a script opcode for relative timelocks that leverages the
nSequence value in scripts.

 That opcode is CHECKSEQUENCEVERIFY(CSV)

 The CSV opcode when evaluated in a UTXO’s redeem script allow

s spending only in a transaction whose input nSequence value is
greater than or equal to the CSV parameter. Essentially, this restri
cts spending the UTXO until a certain number of blocks or secon
ds have elapsed relative to the time the UTXO was mined.

 Relative timelocks with CSV are especially useful when several (ch
ained) transactions are created and signed, but not propagated,
when they’re kept “off-chain.”

40
Median-Time-Past
 In bitcoin there is a subtle, but very significant, difference between wall
time and consensus time.
– each participant has his or her own perspective of time.

 The timestamps set in block headers are set by the miners.

– However, miners can lie about the time in a block so as to earn extra fees
by including timelocked transaction.(It’s going to be handled in next sectio
n)

 Median-Time-Past is calculated by taking the timestamps of the last 11

blocks and finding the median.

 The consensus time calculated by Median-Time-Past is always approxi

mately one hour behind wall clock time. If you create timelock transact
ions, you should account for it when estimating the desired value to e
ncode in nLocktime, nSequence, CLTV, and CSV.

41
Timelock Defense Against Fee Sniping
 Fee-sniping is a theoretical attack scenario.
– where miners attempting to rewrite past blocks “snipe” higher-fee tran
sactions from future blocks to maximize their profitability.

 T is the transaction has a large transaction fee.

 Honest miner will try to extend b3.
 However, If you succeed in appending both b4 and b5 before any
other miner extends b3, then b3 is orphaned, b4 and b5 get author
ized, and you collect T’s large transaction fee.

42
Timelock Defense Against Fee Sniping(2)
 Today, reward is much higher than total fees per block. But trans
action fees will be the majority of the reward (or even the entiret
y of the reward).

 Bitcoin Core sets the nLocktime on all new transactions to <curre

nt block # + 1> and sets the nSequence on all the inputs to 0xFF
FFFFFE to enable nLocktime by default.

43
Scripts with Flow Control – Conditional Clauses(1)

 One of the more powerful features of Bitcoin Script is flow contro

l, also known as conditional clauses. (IF...THEN...ELSE)

 At a basic level, bitcoin conditional opcodes allow us to construct

a redeem script that has two ways of being unlocked, depending
on a TRUE/FALSE outcome of evaluating a logical condition.

 Bitcoin conditional expressions can be nested infinitely, consensus

rules impose a limit on the maximum size.

 Bitcoin implements flow control using the IF, ELSE, ENDIF, and N
OTIF opcodes. Additionally, conditional expressions can contain b
oolean operators such as BOOLAND, BOOLOR, and NOT.

44
Scripts with Flow Control – Conditional Clauses(2)

 Because Bitcoin Script is a stack language, you may find the bitco
in’s flow control scripts confusing first.

 The same way that 1 + 1 looks “backward” when expressed as 1

1 ADD, flow control clauses in bitcoin also look “backward.”

45
Scripts with Flow Control – VERIFY

 Another form of conditional in Bitcoin Script is any opcode that e

nds in VERIFY.

 The VERIFY suffix means that if the condition evaluated is not TR

UE, execution of the script terminates immediately and the transa
ction is deemed invalid.

 Unlike an IF clause, which offers alternative execution paths, the V

ERIFY suffix acts as a guard clause, continuing only if a preconditi
on is met.

46
Scripts with Flow Control – Example(1)

 For example, the following script requires Bob’s signature and a p

re-image (secret) that produces a specific hash. Both conditions
must be satisfied to unlock:

 To redeem this, Bob must construct an unlocking script that pres

ents a valid pre-image and a signature:

 Without presenting the pre-image, Bob can’t get to the part of th

e script that checks for his signature.

47
Scripts with Flow Control – Example(2)

 This script can be written with an IF instead:

 Bob’s unlocking script is identical:

 The script with IF does the same thing as using an opcode with a
VERIFY suffix

 They both operate as guard clauses. However, the VERIFY construc

tion is more efficient, using one fewer opcode.

48
Scripts with Flow Control – Example(3)

 So, when do we use VERIFY and when do we use IF?

 If all we are trying to do is to attach a precondition (guard claus

e), then VERIFY is better.

 If, however, we want to have more than one execution path (flow
control), then we need an IF...ELSE flow control clause.

49
Scripts with Flow Control – Script(1)

 A very common use for flow control in Bitcoin Script is to constru

ct a redeem script that offers multiple execution paths, each a dif
ferent way of redeeming the UTXO.

 With multisig, this would be expressed as a 1-of-2 multisig script.

For the sake of demonstration, we will do the same thing with an
IF clause:

50
Scripts with Flow Control – Script(2)

 The condition is not part of the redeem script. Instead, the condit
ion will be offered in the unlocking script, allowing Alice and Bob
to “choose” which execution path they want.

 Alice redeems this with the unlocking script:

<Alice's Sig> 1

 The 1 at the end serves as the condition (TRUE) that will make th
e IF clause execute the first redemption path for which Alice has
a signature.

51
Scripts with Flow Control – Script(3)

 For Bob to redeem this, he would have to choose the second exe
cution path by giving a FALSE value to the IF clause:

<Bob's Sig> 0

 Bob’s unlocking script puts a 0 on the stack, causing the IF clause

to execute the second (ELSE) script, which requires Bob’s signatur
e.

 Using this construct, we can build redeem scripts with tens or hu

ndreds of execution paths, each offering a different way to redee
m the UTXO.

52
Scripts with Flow Control – Complex Script Example (1)

 Mohammed wishes to construct a company capital account with flexible rules.

 The scheme he creates requires different levels of authorization depending on

timelocks.

 The participants in the multisig scheme are Mohammed, his two partners Sae
ed and Zaira, and their company lawyer Abdul.

 The three partners make decisions based on a majority rule, so two of the thr
ee must agree.

 However, in the case of a problem with their keys, they want their lawyer to b
e able to recover the funds with one of the three partner signatures.

 Finally, if all partners are unavailable or incapacitated for a while, they want th
e lawyer to be able to manage the account directly.

53
Scripts with Flow Control – Complex Script Example (2)

 Mohammed wishes to construct a company capital account with flexible rules.

 The scheme he creates requires different levels of authorization depending on

timelocks.

 The participants in the multisig scheme are Mohammed, his two partners Sae
ed and Zaira, and their company lawyer Abdul.

 The three partners make decisions based on a majority rule, so two of the thr
ee must agree.

 However, in the case of a problem with their keys, they want their lawyer to b
e able to recover the funds with one of the three partner signatures.

 Finally, if all partners are unavailable or incapacitated for a while, they want th
e lawyer to be able to manage the account directly.

54
Scripts with Flow Control – Complex Script Example (2)

55
Scripts with Flow Control – Complex Script Example (3)

 In the first execution path, this script operates as a simple 2-of-3

multisig with the three partners.

 This execution path consists of lines 3 and 9. Line 3 sets the quor
um of the multisig to 2 (2-of-3).

 This execution path can be selected by putting TRUE TRUE at the

end of the unlocking script:

0 <Mohammed's Sig> <Zaira's Sig> TRUE TRUE

56
 Scripts with Flow Control – Complex Script Example (2)

1
2
3
4
5
6
7
8
9
10
11
12
13
0 <Mohammed's Sig> <Zaira's Sig> TRUE TRUE

57
Scripts with Flow Control – Complex Script Example (3)

 The second execution path can only be used after 30 days have e
lapsed from the creation of the UTXO.

 At that time, it requires the signature of Abdul the lawyer and on

e of the three partners (a 1-of-3 multisig).

 This is achieved by line 5 ~ 7, which sets the quorum for the mul
tisig to 1. To select this execution path, the unlocking script woul
d end in FALSE TRUE:

0 <Saeed's Sig> <Abdul's Sig> FALSE TRUE

58
 Scripts with Flow Control – Complex Script Example (2)

1
2
3
4
5
6
7
8
9
10
11
12
13
0 <Saeed's Sig> <Abdul's Sig> FALSE TRUE

59
Scripts with Flow Control – Complex Script Example (3)

 Finally, the third execution path allows Abdul the lawyer to spend
the funds alone, but only after 90 days.

 This is achieved by line 11 ~ 12.

 To select this execution path, the unlocking script has to end in F

ALSE:

<Abdul's Sig> FALSE

60
 Scripts with Flow Control – Complex Script Example (2)

1
2
3
4
5
6
7
8
9
10
11
12
13
<Abdul's Sig> FALSE

61
END