Transactions and Blocks

Bitcoin and
Blockchain Technology
Transactions and Blocks
v2019.04.03
Comments, corrections, and questions: https://drive.google.com/open?id=1xEcBCyN3yLN40A3Ny8k-2PQ-xKJw1RlA
© 2019 Digital Gold Institute

View Slide

First Transaction, From Satoshi to Hal Finney
https://blockchain.info/tx/f4184fc596403b9d638783cf57adfe4c75c605f6356fbc91338530e9831e9e16
2/99

View Slide

First Bitcoin Purchase: 2 Pizzas for
BTC10,000
https://bitcointalk.org/index.php?topic=137.msg1195#msg1
3/99

View Slide

First Bitcoin Purchase: 2 Pizzas for
BTC10,000
https://blockchain.info/tx/a1075db55d416d3ca199f55b6084e2115b9345e16c5cf302fc80e9d5fbf5d48d
4/99

View Slide

Table of Contents
1. TxIns, TxOs, and UTxOs
2. Bitcoin Script Language
3. Standard Transaction Scripts
4. Transactions: Signatures and Smart Contracts
5. Blocks
© 2019 Digital Gold Institute 5/99

View Slide

Transactions
▪ Txs create new coins (transaction outputs TxOs) consuming
existing unspent coins (UTxOs) which are used as transaction
inputs (TxIns)
▪ Coinbase transactions create TxOs without TxIns
▪ The owner(s) of the TxIn coin(s) being spent must sign the Tx,
for authentication (as legitimate owner) and integrity (Tx non
being manipulated down the road)
▪ Txs can be created by any means, even offline, and can be
propagated to the network even by non secure channels

View Slide

TxOs and UTxO Pool
▪ TxOs are amount of bitcoins, recorded on the blockchain and
associated to addresses
▪ Blockchain has neither accounts nor balances
▪ A given address usually has its associated bitcoins as (possibly
many) TxOs scattered over (possibly many) blocks
▪ TxOs can only be spent once and fully as indivisible chunks
▪ bitcoins only exist as unspent TxOs (UTxOs)
▪ The UTxO pool is the LevelDB database cache used to record all
current UTxOs

View Slide

Unspent TxOs: Electrum Testnet
▪ 2 UTxO (2BTC + 1BTC) on the address
tb1qhd92h3tac67u2merxvyu3nen6cgf5y2k8q24hd
▪ 1 UTxO each (2.99 and 43.59) on the two other addresses

View Slide

TxIns reference and spend UTxOs
Software can empower the user with coin control, i.e. picking TxIns

View Slide

TxOs Locking Puzzle
▪ Every TxO is locked by a mathematical puzzle (encumbrance),
coded with Bitcoin Script language
▪ To spend the TxO, the corresponding TxIn must provide the
solution to (i.e. unlock) the puzzle, again coded in Bitcoin Script
language
▪ Unlocking a TxO puzzle usually involves a digital signature using
the private key related to the address the TxO is associated to
▪ Scripts are smart contracts

View Slide

TxIns
Each TxIn must hold:
▪ the reference to the UTxO being spent:
− hash pointer to the previous Tx (TxPrev) where the UTxO has
been created
− zero-based index identifying the UTxO among those created
in TxPrev
▪ the unlocking solution of the UTxO mathematical puzzle (usually
including private key signature)

View Slide

nLockTime
▪ Earliest time that a transaction is valid and can be relayed on
the network or added to the blockchain
▪ A transaction is finalized when its nLockTime has been reached
− nLockTime < 500,000,000 it is interpreted as block number
− nLockTime > 500,000,000 it is interpreted as Unix Epoch
timestamp (number of second since Jan 1, 1970)
▪ A TxIn include a sequence number used to override a
transaction prior to the expiration of its (nonzero) lock-time
(nLockTime is ignored when the sequence numbers of all TxIns
are set to UINT_MAX)

View Slide

Transaction Validity
All nodes validate all Txs before propagating them further.
A Tx is valid if:
1. It can be finalized (i.e. it is not time locked)
2. Its TxIns reference UTxOs only
3. Each TxIn provides the unlocking solution for the
mathematical puzzle of its referenced UTxO
4. The amounts of the newly generated TxOs is less than or equal
to the amount of TxIns
5. ...

View Slide

https://blockstream.info/tx/5a42590fbe0a90ee8e8747244d6c84f0db1a3a24e8f1b95b10c9e050990b8b6b
A Bitcoin Transaction
14/99

View Slide

TxIns, TxOs, and Fees
▪ σ
≤ σ
: the amounts of the newly generated TxOs must
be less than or equal to the amount of TxIns
▪ σ
− σ
= : the difference between TxIns and TxOs is
collected as additional fee reward in the coinbase transaction
▪ If the amount referenced by the used TxIns is greater than the
amount of the intended transaction, a change must be sent to a
change address
▪ The fee cannot be a TxO because the winning miner is not
known at transaction time

View Slide

Transaction Fees
▪ A minimum fee of 0.0001 BTC is used as disincentive against
"spam" transactions or system abuse
▪ Fees are an incentive for miners to prioritize a transaction for
inclusion in the next block, especially if blocks are full
▪ Fees depend on the size of the transaction in kilobytes, not the
transaction value in BTC
▪ The way transaction fees are calculated and the effect they have
on transaction prioritization has been evolving according to
market forces

View Slide

Transaction Fees
https://blockchain.info/charts/transaction-fees?timespan=all&showDataPoints=false&daysAverageString=1&show_header=true&scale=0&address
17/99

View Slide

Transaction Chaining and Orphans
▪ Transaction chaining: child transaction spends the outputs of the
parent transaction, which has not been confirmed yet
▪ Child might arrive before parent: it is put in the orphan
transaction pool while waiting for the arrival of its parent
▪ There is a limit MAX_ORPHAN_TRANSACTIONS to the number of
orphan transactions stored in memory, to prevent a denial-of-
service attack
▪ If a transaction is stuck because of a low fee, child-pay-for-
parent means that a child transaction can pay enough fee for
prioritizing both parent and child

View Slide

Replace By Fee (BIP125)
▪ RBF allows replacing a 0-confirmations transaction by
transmitting another transaction with a higher fee
▪ RBF is opt-in

View Slide

Table of Contents
5. Blocks

View Slide

Stack Data Structure
▪ Based on the Last In First Out (LIFO) principle
▪ Operators push data on the top of the stack or pop out data
from the top of the stack
▪ Conditional operators evaluate a condition, pushing a
TRUE/FALSE result on the top of the stack

View Slide

Bitcoin Script Language
A very simple Forth-like language that uses reverse-polish notation
1. no loops or complex flow control capabilities
2. ensure termination, i.e. finite time execution (implied by 1)
3. memory access is stack-based: there are no variables,
calculations are performed on the stack
Bitcoin Script is purposefully stateless and not Turing-complete
Limited flexibility is a deliberate security feature, preventing
vulnerability from the transaction validation mechanism

View Slide

Bitcoin Script Language: Rationale
“The nature of Bitcoin is such that once version 0.1 was released,
the core design was set in stone for the rest of its lifetime.
Because of that, I wanted to design it to support every possible
transaction type I could think of. The problem was, each thing
required special support code and data fields whether it was used
or not, and only covered one special case at a time. It would have
been an explosion of special cases. The solution was script, which
generalizes the problem so transacting parties can describe their
transaction as a predicate that the node network evaluates. The
nodes only need to understand the transaction to the extent of
evaluating whether the sender's conditions are met.”
(Satoshi Nakamoto)
https://bitcointalk.org/index.php?topic=195.msg1611#msg1611

View Slide

Bitcoin Script Language: Goals
Fundamentally different programming model than ordinary
programming: it favors a verification, not computation, model
− provability (prove proof in finite time)
− solvability (Turing complete)
It is possible to verify arbitrary code execution, without the need
for Turing-completeness
▪ Computational efficiency (all nodes will verify the script: provide
proofs, do not require excessive computation)
▪ Soundness (keep it simple: sophistication must not introduce
attack vectors)
▪ Privacy
▪ Compactness (small impact on blockchain, less data also
increases efficiency and privacy)

View Slide

Verify 2+3=5 Using Script
2 3 OP_ADD 5 OP_EQUAL
▪ 2
▪ 3
▪ OP_ADD
▪ 5
▪ OP_EQUAL
Stack

View Slide

→ 2
▪ 3
▪ OP_ADD
▪ 5
▪ OP_EQUAL
Stack
▪ 2

View Slide

▪ 2
→ 3
▪ OP_ADD
▪ 5
▪ OP_EQUAL
Stack
▪ 3
▪ 2

View Slide

▪ 2
▪ 3
→ OP_ADD
▪ 5
▪ OP_EQUAL
Stack
▪ 5

View Slide

▪ 2
▪ 3
▪ OP_ADD
→ 5
▪ OP_EQUAL
Stack
▪ 5
▪ 5

View Slide

▪ 2
▪ 3
▪ OP_ADD
▪ 5
→ OP_EQUAL
Stack
▪ TRUE

View Slide

Interactive Script Playgrounds
▪ https://siminchen.github.io/bitcoinIDE/build/editor.html
▪ Bitcoin Debug Script Execution https://webbtc.com/script
▪ convert Script to JavaScript http://www.crmarsh.com/script-
playground/

View Slide

Operators
256 opcodes total (15 disabled, 75 reserved)
▪ Arithmetic
▪ If/then
▪ Logic/data handling
▪ Crypto
− Hashes
− Signature verification
− Multi-signature verification

View Slide

Operators
▪ OP_DUP duplicates the top stack value
▪ OP_HASH160 performs double hashing of the top stack value, first using
SHA256 and then RIPEMD160
▪ OP_HASH256 performs double hashing of the top stack value using SHA256
▪ OP_EQUAL returns TRUE if the two top stack values are exactly equal,
FALSE otherwise
▪ OP_VERIFY marks transaction as invalid if top stack value is not TRUE. The
top stack value is removed.
▪ OP_EQUALVERIFY is equivalent to OP_EQUAL followed by OP_VERIFY
▪ OP_CHECKSIG checks that the input signature is a valid signature using the
input public key for the hash of the current transaction
▪ OP_RETURN marks transaction as invalid. A standard way of attaching extra
data to transactions is to add a zero-value TxO with a
consisting of OP_RETURN followed by exactly one pushdata operator
https://en.bitcoin.it/wiki/Script
33/99

View Slide

Alternative to Script: e.g. Simplicity
▪ SegWit introduced the possibility of having alternative scripting
languages, affecting only the involved transactions
▪ E.g.: Simplicity
https://blockstream.com/2018/11/28/simplicity-github/

View Slide

Table of Contents
5. Blocks

View Slide

Transaction Script
▪ TxOs include a locking mathematical puzzle
(usually including, in some way, the bitcoin address or the
public key)
▪ The puzzle must be solved in order to spend the UTxO
▪ The spending TxIn provides unlocking solution
(usually including, in some way, the private key signature)

View Slide

Script Evaluation
▪ The Unlock+Lock script (+) is
evaluated
▪ If the script fails or its result is FALSE then the TxIn is invalid
▪ A UTxO is unaffected by failed attempts to spend it
▪ A TxIn that satisfies the UTxO conditions does spend it: the TxO
remains in the blockchain, but it is removed from the UTxO pool

View Slide

Script Execution
Scripts are not really concatenated anymore: executed separately
for security reason, stack being transferred between the two

View Slide

Standard Transactions
Many different scripts are possible, but for security reason a
transaction is usually relayed only if IsStandard(), i.e.
▪ does not violate good network behavior rules
▪ its scripts match a small set of believed-to-be-safe templates:
− pay-to-public-key (P2PK, the easiest and oldest)
− pay-to-public-key-hash (P2PKH, the most common)
− null data (OP_RETURN)
− multi-signature (limited to 15 keys)
− pay-to-script-hash (P2SH, the most versatile)
− {SegWit transactions}
Valid non-standard transactions, if included in blocks, are accepted

View Slide

Pay-To-Public-Key (P2PK)
The first transaction type was Pay-To-Public-Key (P2PK)
In the early days of Bitcoin
▪ coins were assigned to uncompressed Public keys
▪ spent using DER signatures

View Slide

Pay-To-Public-Key (P2PK): TX_PUBKEY
▪
▪
▪ OP_CHECKSIG
Stack
+

41/99

View Slide

→
▪
▪ OP_CHECKSIG
Stack
▪
+

42/99

View Slide

▪
→
▪ OP_CHECKSIG
Stack
▪
▪
+

43/99

View Slide

▪
▪
→ OP_CHECKSIG
Stack
▪ TRUE
+

44/99

View Slide

Quantum Resistance
Problem:
to publish a public key on the blockchain is not quantum resistant,
as such it is not future proof
Solution:
pay to the hash of the public key, publishing only the public key
hash (i.e. the address) on the blockchain
… or maybe not…

View Slide

Pay-To-Public-Key-Hash (P2PKH)
TX_PUBKEYHASH
+

▪
▪
▪ OP_DUP
▪ OP_HASH160
▪
▪ OP_EQUALVERIFY
▪ OP_CHECKSIG
Stack

View Slide

TX_PUBKEYHASH
→
▪
▪ OP_DUP
▪ OP_HASH160
▪
▪ OP_EQUALVERIFY
▪ OP_CHECKSIG
Stack
▪
+

47/99

View Slide

TX_PUBKEYHASH
▪
→
▪ OP_DUP
▪ OP_HASH160
▪
▪ OP_EQUALVERIFY
▪ OP_CHECKSIG
Stack
▪
▪
+

48/99

View Slide

TX_PUBKEYHASH
▪
▪
→ OP_DUP
▪ OP_HASH160
▪
▪ OP_EQUALVERIFY
▪ OP_CHECKSIG
Stack
▪
▪
▪
+

49/99

View Slide

TX_PUBKEYHASH
▪
▪
▪ OP_DUP
→ OP_HASH160
▪
▪ OP_EQUALVERIFY
▪ OP_CHECKSIG
Stack
▪
▪
▪
+

50/99

View Slide

TX_PUBKEYHASH
▪
▪
▪ OP_DUP
▪ OP_HASH160
→
▪ OP_EQUALVERIFY
▪ OP_CHECKSIG
Stack
▪
▪
▪
▪
+

51/99

View Slide

TX_PUBKEYHASH
▪
▪
▪ OP_DUP
▪ OP_HASH160
▪
→ OP_EQUALVERIFY
▪ OP_CHECKSIG
Stack
▪
▪
+

52/99

View Slide

TX_PUBKEYHASH
+

▪
▪
▪ OP_DUP
▪ OP_HASH160
▪
▪ OP_EQUALVERIFY
→ OP_CHECKSIG
Stack
▪ TRUE

View Slide

▪ Public keys are revealed at redemption time only
▪ Problem: multiple UTxOs associated to the same address would
see their common public key revealed when the first UTxO is
spent
▪ Solution: use a different address (i.e. public key) for each TxO!

View Slide

Blockchain for Data Unrelated to
Transactions
▪ The 20-byte destination address can be used to store any data
in the blockchain, e.g. file hash for proof-of-existence of the file
on the transaction date
▪ Blockchain as distributed and time-stamped ledger system for
digital notary services, stock certificates, smart contracts, etc.
Blockchain abuse or clever use?
▪ Waste: if the address does not correspond to a private key the
UTxO can never be spent, associated bitcoins are lost
▪ Bloat: blockchain disk storage, UTxO cache RAM

View Slide

A Better Approach: OP_RETURN
▪ 80 bytes of nonpayment data are allowed after OP_RETURN
▪ OP_RETURN forces the failure of any script including it; the
associated TxO cannot be spent
▪ As such, its TxO is provably unspendable: it is stored in the
blockchain but prunable from the UTxO pool (limited bloat)
▪ The TxO can have zero bitcoin associated (no waste)
see www.eternitywall.com, www.eternitywall.com/notarize, and www.opentimestamps.org

View Slide

+

▪
▪ OP_WHATEVER
▪ OP_RETURN
▪
Stack
OP_RETURN makes the TxO
unspendable
OP_RETURN TX_NULL_DATA
57/99

View Slide

▪ OP_0
▪
▪ …
▪
▪
▪
▪ …
▪
▪
▪ OP_CHECKMULTISIGVERIFY
Multisignature (M-of-N) Transaction
TX_MULTISIG
+

Stack
58/99

View Slide

▪ N
▪
▪ …
▪
▪ M
▪
▪ …
▪
▪ 0
▪ OP_0
▪
▪ …
▪
▪
▪
▪ …
▪
→
▪ OP_CHECKMULTISIGVERIFY OP_CHECKMULTISIG
VERIFY bug: it
consumes one extra
ignored data element
Fast forward
here
+

TX_MULTISIG
Stack
59/99

View Slide

▪ OP_0
▪
▪ …
▪
▪
▪
▪ …
▪
▪
→ OP_CHECKMULTISIGVERIFY
TX_MULTISIG
+

Stack
▪ TRUE
60/99

View Slide

From TX_MULTISIG To TX_SCRIPTHASH
TX_MULTISIG: up to 15-of-15 (1650 bytes signature script limit)
Problems:
▪ Public keys are published on the blockchain
▪ A multisig is bigger than the P2PKH one
▪ Expensive for the sender, beneficial for the receiver
Solution: create a new type of UTxO that shifts the burden into the
redemption

View Slide

From TX_MULTISIG To TX_SCRIPTHASH
▪ A 2-of-3 multising script is 65*2+3 bytes = 133 bytes
<1 pubk1 pubk2 2 OP_CHECKMULTISIG>
▪ This redeem script can be represented by its much shorter 20
bytes HASH160:
▪ Lock the transaction with:
OP_HASH160 OP_EQUAL
▪ Unlock with: <1 pubk1 pubk2 3 OP_CHECKMULTISIG>

View Slide

BIP16 Pay-To-Script-Hash (P2SH)
▪ Move the script from TxO to TxIn
▪ Scripts are hashed and encoded as addresses: complex scripts
are replaced by shorter fingerprints in the TxO
▪ Pay to a script matching this hash: script will be presented in
the future to spend UTxO. A future spending TxIn will contain
the redeem script whose hash is contained in the UTxO
▪ Sender does not handle the complexity of receiver’s policy
▪ Smaller in the (present) UTxO set, larger
in the (future) blockchain
▪ Fee cost for a complex script is shifted from sender to recipient
at future spending time
▪ Public keys and full script are revealed at redemption time only

View Slide

BIP16 Pay-To-Script-Hash (P2SH)
▪ P2SH transactions can contain any valid script allowing for
experimentation with new and complex types of transactions
▪ Transactions that redeem P2SH TxO are considered standard if
the redeem script is, itself, one standard transaction type
▪ A TxO locked with the hash of an invalid script is valid, but
cannot be spent with a valid TxIn
▪ P2SH can be nested without becoming recursive
▪ Redeem script cannot include OP_RETURN

View Slide

P2SH Addresses (BIP16)
▪ Base58Check encode of a P2SH use version prefix of 5 (instead
of 0), resulting in an address starting with a “3” (instead of “1”)
▪ P2SH “3” addresses designate the beneficiary of a bitcoin
transaction as the hash of a script
▪ Bitcoins sent to “3” P2SH addresses require something more
than the presentation of one public key (hash) and one private
key signature to be spent
▪ Requirements are designated at the time the address is created,
within the script

View Slide

+

▪
▪ {[Pubkey] OP_CHECKSIG}
▪ OP_HASH160
▪ [20-byte-hash of {[Pubkey]
OP_CHECKSIG}]
▪ OP_EQUAL
Stack
P2SH Example: Hash of a P2PK script
66/99

View Slide

+

→
▪ OP_HASH160
OP_CHECKSIG}]
▪ OP_EQUAL
Stack

67/99

View Slide

+

▪
→ {[Pubkey] OP_CHECKSIG}
▪ OP_HASH160
OP_CHECKSIG}]
▪ OP_EQUAL
Stack
{[pubkey] OP_CHECKSIG}

68/99

View Slide

+

▪
→ OP_HASH160
OP_CHECKSIG}]
▪ OP_EQUAL
Stack
[20-byte-hash of {[pubkey]
OP_CHECKSIG}]

69/99

View Slide

+

▪
▪ OP_HASH160
→ [20-byte-hash of {[Pubkey]
OP_CHECKSIG}]
▪ OP_EQUAL
Stack
OP_CHECKSIG}]
OP_CHECKSIG}]

70/99

View Slide

+

▪
▪ OP_HASH160
OP_CHECKSIG}]
→ OP_EQUAL
Stack

71/99

View Slide

▪ [Pubkey]
▪ OP_CHECKSIG
Stack

Now keep validating using the current stack and the redeem script as
72/99

View Slide

→ [Pubkey]
▪ OP_CHECKSIG
Stack
[pubkey]

73/99

View Slide

▪ [Pubkey]
→ OP_CHECKSIG
Stack
TRUE
P2SH Example: Hash of P2PK
74/99

View Slide

https://p2sh.info/dashboard/db/home-dashboard?orgId=1&from=now-5y&to=now
Pay-to-script-hash (P2SH)
75/99

View Slide

Table of Contents
5. Blocks

View Slide

TxIn signature: Hash Type
When signing TxIns, the sighash marker indicates which of the newly
created TxOs are also covered by the signature
1. SIGHASH_ALL (default): all TxOs, so modifying any TxO would
require the TxIn to be signed again
2. SIGHASH_NONE: no TxO, so all TxOs in the transaction can be
changed (used in cooperative transaction construction)
3. SIGHASH_SINGLE: the equal index TxO (i.e. the TxO of the same
index as the TxIn), so that one cannot be changed
2-3 does allow other TxIns to update their sequence numbers, 1 does not
SIGHASH_ANYONECANPAY is combined with the previous ones to indicate
which TxIn is covered by the signature: only the current TxIn if TRUE, all
TxIns if FALSE

View Slide

Transaction Malleability
▪ Transaction signature does not cover all the data in a transaction that
is hashed to create the transaction hash ID
▪ One can alter a Tx, without changing the Tx economics (TxIn, TxOut,
and spendability conditions), resulting in a different Tx ID e.g.:
− DER-encoded ASN.1 octet representation (fixed by BIP66)
− for every ECDSA signature (r, s), the signature (r, N-s) is a valid
signature of the same message (fix with canonical low-s encoding)
− is not signed and can be manipulated with additional
data then removed with OP_DROP, etc. (fixed by SegWit)
▪ This breaks everything relying on Tx ID
▪ A transaction’s hash can be manipulated without altering

View Slide

Segregated Witness (SegWit)
"witness" is a solution to a cryptographic puzzle, e.g.:
▪ every TxIn in a transaction is followed by the witness data that
unlocks its corresponging TxO.
▪ Segregated Witness moves the outside of the
transaction data structure, into a separate witness data
structure that complements the transaction
▪ Clients may request transaction data with or without the
accompanying witness data.

View Slide

SegWit Benefits
▪ Transaction malleability fix
▪ Signature verification optimization (linear scaling of sighash
operations)
▪ Increased security for multisig via pay-to-script-hash (P2SH)
▪ Script versioning
▪ Network and storage scaling
▪ Offline signing improvement
https://bitcoincore.org/en/2016/01/26/segwit-benefits/
80/99

View Slide

Empty
▪ Anyone could spend an empty with a
consisting of OP_TRUE only
▪ + = OP_TRUE

View Slide

HTLC

View Slide

Merkelized Abstract Script Tree
▪ Scripts involves OR combinations of keys, lock-times, hash-
locks, etc. and reveal all of them
▪ MAST introduces branches in script
▪ Merkle tree of scripts
− TxO includes (and reveal) only the Merkle tree root
− TxIn will include the spending script, the path along the tree
to the root, and signatures
▪ Only reveal the actually used spending condition, not all the
other alternatives

View Slide

MAST Application: Taproot
▪ Tweak keys with redeem script hash :
2
= 1
+ ℎℎ 1
||
2
= 1
+ ℎℎ 1
||
▪ Pay-to-contract combines P2PK and P2SH, allowing to spend
either using Pubkey or redeem script:
− Key spending: sign with 2
− Script spending: 1
, , inputs
▪ Graftroot is an evolution of the above using delegation instead
of Merkle Tree (requires interactive key setup)

View Slide

Homework (1/2)
▪ Create a Hashlock transaction, i.e. an output locking script
including a hash value, spendable with an input
unlocking script composed only by the hash pre-
image
▪ Preferably use the hash value with seven leading zero you
obtained in the first lesson homework
(hint: use OP_HASH265 and OP_EQUAL)
▪ Check the result with online script engines or python code
▪ Why is such a transaction not secure?
(hint: who see your spending transaction? What attack could be performed?
Why do we usually rely on asymmetric cryptography?)

View Slide

Homework (2/2)
▪ See also:
https://webbtc.com/tx/09f691b2263260e71f363d1db51ff3100d285956a40cc0e4f8c8c2c4a80559b1
▪ Study the script logic at:
https://webbtc.com/script/09f691b2263260e71f363d1db51ff3100d285956a40cc0e4f8c8c2c4a80559b1:0

View Slide

Table of Contents
5. Blocks

View Slide

Transaction Bundling
▪ Transactions are bundled in blocks for practical reasons (shorter
chain, single unit of work for validators, faster history
validation)
▪ Transactions in a block are actually packaged in a Merkle Tree
prev_hash
nonce
Tx
Tx
Tx
prev_hash
nonce
Tx
Tx
Tx
prev_hash
nonce
Tx
Tx
Tx
prev_hash
nonce
Tx
Tx
Tx
prev_hash
nonce
Tx
Tx
Tx

View Slide

trans: H( )
prev: H( )
Block Structure
trans: H( )
prev: H( )
trans: H( )
prev: H( )
H( ) H( )
H( ) H( ) H( ) H( )
transaction transaction transaction transaction
Hash chain of blocks
Hash tree (Merkle
tree) of transactions in
each block

View Slide

Block structure
Block size
4 bytes
Block header
80 bytes
Number of Transactions
1-9 bytes
Transactions
Variable bytes
Block structure
The average block
contains more than
2000 transactions.
The maximum block
size, as fixed in Bitcoin
Core, is 1MB
Block header
80 bytes

View Slide

Block size
4 bytes
Block header
80 bytes
Number of Transactions
1-9 bytes
Transactions
Variable bytes
Block structure
Field Description Size
Version
Block version
number
4 bytes
Previous
block hash
Reference to the hash
of the previous
block
32
bytes
Timestamp
Block time creation
time (seconds from
Unix Epoch)
4 bytes
Difficulty
target
Nonce
Merkle root
Hash of the root of
the Merkle tree of
the block’s transaction
32
bytes
New software is
released
A new block comes
in
Every few seconds
A transaction is
accepted
Updated when
Nonce
Number used for the
proof-of-work
4 bytes
Partial Inversion
Hash Puzzle is
solved
Block header
4 bytes
Every 2016 blocks

View Slide

Block structure: example

View Slide

https://blockexplorer.com/block/0000000000000000016a4f0250796c29542d6821c42b4837f3e41a6cca20cfaf
Block details example
93/99

View Slide

Block details example
94/99

View Slide

Genesis Block

View Slide

Genesis Block
https://blockchain.info/tx/4a5e1e4baab89f3a32518a88c31bc87f618f76673e2cc77ab2127b7afdeda33b
Number Of Transactions: 1; Difficulty: 1; Nonce: 2083236893; Block
Reward: 50 BTC
Hash:
000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f
Merkle Root:
4a5e1e4baab89f3a32518a88c31bc87f618f76673e2cc77ab2127b7afdeda33b
The genesis block reward can't be spent due to a quirk in the way that
the genesis block is expressed in the code. It is not known if this was
intentional or an accident
https://en.bitcoin.it/wiki/Genesis_block
https://github.com/bitcoin/bitcoin/blob/9546a977d354b2ec6cd8455538e68fe4ba343a44/src/main.cpp#L1668

View Slide

Homework
▪ First halving: provide block height and hash pointer of the first
25BTC coinbase transaction
▪ Last halving: provide block height and hash pointer of the last
halving coinbase transaction
Hint: use https://blockstream.info, https://blockexplorer.com/ or any other block explorer

View Slide

Bibliography
▪ A. Narayanan, et al., “Bitcoin and Cryptocurrency Technologies”
http://bitcoinbook.cs.princeton.edu/
− chapter 3 «Mechanics of Bitcoin»
▪ Pedro Franco, “Understanding Bitcoin”, Wiley
− chapter 6 «Transactions»
− chapter 7 «The Blockchain»
▪ Andreas Antonopoulos, “Mastering Bitcoin” 2nd edition, O'Reilly
https://github.com/bitcoinbook/bitcoinbook
− chapter 6 «Transactions»
− chapter 7 «Advanced Transactions and Scripting»
− chapter 8 «The Blockchain»
▪ https://en.bitcoin.it/wiki/Script

View Slide

Takeaways
▪ Bitcoin is programmable money: Script allows simple and
powerful smart contracts
▪ Block headers are a succinct view of the blockchain data set
▪ The Bitcoin protocol has moved forward in term of privacy,
security, and scalability
▪ SegWit fixed transaction malleability and added many
improvement, it was not just block size increase

View Slide

Ferdinando M. Ametrano
Executive Director
[email protected]
Paolo Mazzocchi
Chief Operating Officer
[email protected]
www.github.com/dginst
www.facebook.com/DigitalGoldInstitute
www.twitter.com/DigitalGoldInst
www.dgi.org/feed.xml
[email protected]
www.dgi.io
www.linkedin.com/company/digital-gold-institute
"Scarcity in the Digital Realm"

View Slide

Transactions and Blocks

Transactions and Blocks

Ferdinando M. Ametrano

More Decks by Ferdinando M. Ametrano

Other Decks in Technology

Featured

Transcript