FITE3011

Distributed ledger and blockchain

Lecture 7 Cryptocurrency Technology (Bitcoin)

Notes by Prof. SM Yiu

Q: Do you know what a Merkle tree is?
Application:
We want to keep a sequence of records (e.g. a log file) and
(i) the owner wants to maintain the integrity of the records (i.e., make sure no one can
delete/modify any records);
(ii) Individual user wants to check the integrity of selected records, but the owner do
NOT want to disclose to him other records not belonging to him (privacy issue).

Q: How we can do it?

Solution 1:
For each record, we digitally sign it (or hash it and sign the hash: Q: difference?)
Q: Does it work?

No, someone may still delete individual records together with its hash & signature.
Solution 2:
How about we group the records into blocks, then hash each group and sign the hash?
No. (i) Someone can still delete a whole block, together with its hash & signature
without being noticed.
(ii) When a user wants to check a particular record, we may need to disclose all
records in the whole group (violate the privacy requirement too).
Solution 3:
How about we hash each record, concatenate the hash sequence, sign the hash
sequence?
Seems ok.
(i) The owner can recompute the hash sequence based on *all* records and check it so
that if one of the records has been tampered or deleted, he knows.
(ii) When a user wants to check a particular record, send him the record and hashes
of other records, he can re-create the hash sequence, then check the signature of
hash sequence. No need to give him other records (only hashes).
But overhead is large:
Every time if we need to verify a record,
- we need to send the record together with (n-1) hashes assuming we have n records
- # of hashes to be sent is O(n) or the length of the hash sequence is proportional to
O(n)
- So, the overall complexity for checking is O(n).

Q: Can we do better?
Ans: use a Merkle tree
R = H(x5x6) – public (sign it too)
x5 = H(x1x2) x6 = H(x3x4) Owner can easily
recompute R based
on all records to
x1 = H(H(y1)H(y2)) x2 = H(H(y3)H(y4)) make sure that no
x3 = … x4 = … records have been
deleted/tempered.

y1 y2 y3 y4 y5 y6 y7 y8
y1..y8: data
Q: How about individual users? E.g. What to provide to verify the integrity of y3, y6?
For y3, we need H(y4), x1, x6; for y6, we need H(y5), x4, x5 (R is known).
Only log n hashes need
Merkle proof Merkle proof
to be sent! 4
A brief technical details in bitcoin:
Block structure
Bitcoin Block Header Recall that multiple
transactions are in the
Previous block same block
Timestamp
header hash
Q: How about only odd
Merkle Tree # of transactions?
Nonce
Root
When computing the last
root = Hash( H12, H34 ) Tr, we double the Tr to
compute the hash:
H12 = Hash( H1, H2 ) H34 = Hash( H3, H4 )
Hash(H(Tr), H(Tr))

H1 = Hash( T1 ) H2 = Hash( T2 ) H3 = Hash( T3 ) H4 = Hash( T4 )

Merkle Root: Commitment to all transactions in the block

In more details (80 bytes header):
Definition of a valid block updated a
# of Usage few times: E.g. v1->v2: changes in
bitcoin protocol
bytes
4 Version #: which set of validation Q: What is coinbase?
rules should apply The only input in coinbase
32 256 bits hash value of the previous transaction created by miner for
header a block to get reward! *Must* be
32 Markle tree root (integrity for all the first Tr of a block.
transactions in this block) Q: What is block height?
4 Time stamp # of blocks preceeding this block.
4 Target threshold (how many starting Hash = SHA-256
0’s)
4 Nonce (found by the winning minner) Calculate elapsed time for every 2016
----- blocks: control to be 1209600 sec (2
80 Note: 4 bytes before header to show weeks), 600 sec per block => adjust
target threshold
the size of the block.
Remark:
If target threshold = only 1 leading zero
Expected # of random #s needs to be tried? 2

How about if 2 leading zeros?

00: ok, 01, 10, 11, not ok => Expected # of random #s need to be tried = 4

Use 1,209,600sec for 2016 blocks as a guideline:

If faster, increase # of zeros for target threshold.
If slower, decrease # of zeros

Q: Do you know how many zeros need to be increased or decreased

[depending on the time elapse (assuming the same hash rate)]?
An example header*: # of bytes Usage

4 Version #: which set of

validation rules should
apply
32 256 bits hash value of the
previous header
32 Markle tree root (integrity
for all transactions in this
block)
4 Time stamp
4 Target threshold (how
many starting 0’s)
4 Nonce (found by the
winning minner)

* Example from bitcoin.org (most of the examples are from this website, unless otherwise stated)
Q: Where are the transactions? Remarks:
Outpoint (TXID (hash) + Sequence #)
80 bytes header - Which output of which previous transaction
# of transactions
Total has a 1 bitcoin = 100,000,000 satoshis
Coinbase Tr
limit, say Total input – total output => transaction fee!
Transaction 2
1M
…….
Transaction x
Sign script needs to
Raw transaction: Each input has 2 key fields: match the
Outpoint, Signature script corresponding
4 bytes version # outpoint pubkey
# of inputs Outpoint reference Allows spending
script!
Input 1 a previous output the input
…….. E.g. OP_CHECKSIG
# of outputs Each output has 2 key fields: - Check signature using
Output 1 Value (how much), Pubkey script a public key
………. In unit of satoshis Set conditions for further spent
 Which version of transaction
data structure used

Raw transaction:
TXID (hash) – (from a
4 bytes version # previous transaction)
# of inputs
Input 1 Which output in
…….. Transaction TXID
# of outputs
Output 1
……….

Signature
Raw transaction:
(Value)
4 bytes version #
# of inputs
Input 1
……..
# of outputs
Output 1 (Pubkey script)
……….

Conditions
Hash of
public key
Unspent transaction
outputs (UTXO):
NO concept of
accounts
How about the coinbase transaction created by
miner to get reward for a block?*
Exactly one input: coinbase
Normal transaction input
TXID (hash)
Seq # (which output in TXID)
# of bytes in Sign script
Script
Seq #
vs coinbase
32 bytes null (no previous outpoint)
4 bytes null (no previous outpoint)
# of bytes in coinbase script
block height (do you remember?) – 4 bytes
Script
Seq #

Block height < 6,930,000, then entitles new bitcoins reward:

At the beginning: 50BTC, half every 210,000 blocks,
As at Nov 2017 approx: 12.5BTC
* Output of a coinbase transaction CANNOT be spent for at least 100 blocks. Q: why?
Sample coinbase (input)

Null as no previous outpoint

Q: what is the output part of

(block height)
coinbase transaction?

We actually do not need a

script (scriptSig) here (no
(coinbase script) need to unlock any input), so
can put arbitrary data (see
later lecture for a usage)
Only one output count Block Award: (25BTC +
(for putting the reward) transaction fee)

ECDSA public key hash

Q: Although bitcoin recommends not to re-use the same address, the
reality is not the case.
(i) Can we accumulate bitcoins in the same address? I.e., can we increase
the number of bitcoins in the same address in multiple transactions. Add 1
BTC into address A in a transaction, later add another 3.5 BTC to the same
account?

(ii) Can we only spend partial amount of BTC in an address in one

translation, i.e., if the address have 1000 BTC, can I only spend a partial
sum of it in ONE transaction?
References
• Documentations in www.bitcoin.org