https://crocs.fi.muni.cz @CRoCS_MUNI
PV204 Security technologies
Bitcoin II.
Petr Švenda svenda@fi.muni.cz @rngsec
Centre for Research on Cryptography and Security, Masaryk University
Please provide any corrections and comments here (thank you!):
https://drive.google.com/file/d/15z8k8zltcBaxEcF18DGwdoTtUNQFd-9c/view?usp=sharing
https://crocs.fi.muni.cz @CRoCS_MUNI
Phase III
● Finalize the implementation
● Prepare and record a presentation of your project (10 minutes)
‒ Project design
‒ Implementation
‒ Issues and solutions
‒ Application demonstration
● Deadline: 16. 4. 2023
‒ Submit presentation slides and the recording to IS
‒ Submission from this phase will be made available to reviewing teams
https://crocs.fi.muni.cz @CRoCS_MUNI
Task: Questions to ask
• Write 2-3 questions you want to discuss about Bitcoin
• https://sli.do #pv204_2023
• We will cover it together towards second half of this lecture
– (and possibly during seminar)
3 | PV204 Bitcoin II.
4 | PV204 Bitcoin II.
Audience Q&A Session
ⓘ Start presenting to display the audience questions on this slide.
https://crocs.fi.muni.cz @CRoCS_MUNI
LEFTOVER FROM PREVIOUS LECTURE ☺
5 | PV204 Bitcoin II.
https://crocs.fi.muni.cz @CRoCS_MUNI
Pay to script hash (P2SH), BIP16, starts with ‘3’
• Lock script separated into two parts
– 1) commitment to the script (hash value, checked later)
– 2) actual lock script (hash value must match the commitment)
• Sending tx sets output’s ScriptPub to the commitment
– Shorter as only hash is posted, not whole lock script
– Lock script is provided only later when spending (privacy, fee to be paid)
– Lock script can have multiple spending paths (Merkle tree) and only the one
used is posted (better for privacy)
• Redeeming tx provides actual lock script + unlock script
6 | PV204 Bitcoin II.
https://crocs.fi.muni.cz @CRoCS_MUNI7 | PV204 Bitcoin II.
Commitment to
script
Check script hash
If initial script structure was
commitment and value on stack
is true, special code branch of
code is executed, using original
witness script
Witness script is executed
(here 2-of-3 multisig)
OP_FALSE is used to push
0 on stack (multisig bug)
…
Script
https://crocs.fi.muni.cz @CRoCS_MUNI
Interesting, non-standard scripts
• SHA1 collision bounty
– Bitcoins locked to script requiring two different inputs hashed to same SHA1 hash
– Redeemed shortly after Google published SHA1 collision blocks
• https://blockstream.info/tx/8d31992805518fd62daa3bdd2a5c4fd2cd3054c9b3d
ca1d78055e9528cff6adc
• https://nioctib.tech/#/transaction/8d31992805518fd62daa3bdd2a5c4fd2cd3054
c9b3dca1d78055e9528cff6adc
• More details: https://bitcoinjs-guide.bitcoin-studio.com/bitcoinjs-guide/v5/part-
three-pay-to-script-
hash/puzzles/computational_puzzle_sha1_collision_p2sh.html
• Similar bounties for other hash collisions
8 | PV204 Bitcoin II.
https://crocs.fi.muni.cz @CRoCS_MUNI
OP_RETURN
• If OP_RETURN is encountered during execution of
unlock+lock script, it is FALSE
– Such output is provably unspendable => not in UTXO set
• Somewhat controversial instruction
– Some feels, that blockchain shall not be used for nonfinancial
data (USDT was initially on Bitcoin via
OP_RETURN)
– But there were already ways how to store arbitrary data into
blockchain anyway (e.g., bytes of value, invalid address)
• Analysis of OP_RETURN data
– https://www.blockchainresearchlab.org/2020/03/13/how-do-
op-return-transactions-impact-bitcoin/
– https://opreturn.org/
• Relevant recent discussion with Inscriptions (later)
9 | PV204 Bitcoin II.
charley loves heidi
https://nioctib.tech/#/transaction/f2f398dace996dab12e0cf
b02fb0b59de0ef0398be393d90ebc8ab397550370b
https://crocs.fi.muni.cz @CRoCS_MUNI
BLOCKS AND MINING
10 | PV204 Bitcoin II.
https://crocs.fi.muni.cz @CRoCS_MUNI
Problem: Who will include next block in blockchain?
• Transactions (state updates) has to be included somehow into block
to be “permanently” valid
• Entity including new block has special position and power
– Can decide which transactions (state updates) will be included
• May lead to censorship of certain transactions
• May lead to transactions reordering impacting the financial value (e.g. MEV)
– Can decide where new block is appended
• Shall be last previous block, but can cause malicious forks abandoning part
of previously extended blockchain (e.g., 51% attack to rewrite history)
– Typically receive some reward (motivation for participation)
• May cause long-term centralized accumulation of underlying token
11 | PV204 Bitcoin II.
https://crocs.fi.muni.cz @CRoCS_MUNI
Who can include next block to blockchain?
• Proof of Work (PoW, Bitcoin, Ethereum 1.0, Zcash…)
– Solver of computationally hard puzzle can include new block
• Proof of Stake (PoS, Zcoin, Cardano, BNB, Ethereum 2.0…)
– More coins you own, higher the probability you will be selected to include next block
– Various variants, Stake pools…
• Merged Mining (Namecoin…)
– Hash of block from the chain is included in coinbase tx of other chain (typically Bitcoin)
– The chain is not performing own mining, Bitcoin miners are getting reward for inclusion of other chains
• Proof of Proof (PoP)
– Hash of block from other chain is included in Bitcoin transaction (typically OP_RETURN)
– Security of other chain is improved by security of Bitcoin blockchain
• Proof of Authority (PoA)
– Small number of trusted actors create new blocks
12 | PV204 Bitcoin II.
We will focus mainly on Proof
Of Work used in Bitcoin
https://crocs.fi.muni.cz @CRoCS_MUNI
https://blockgeeks.com/
Bitcoin block
• Header (80 B) + data (up to ~4MB)
– Version
– Previous block hash (linking to past blockchain)
– Merkle root of all included transactions (Coinbase tx + others)
– Timestamp (unix time)
– Bits (specification of required mining difficulty)
– Nonce (variable part for mining, now insufficient)
• Coinbase transaction (reward for miners, emission of new bitcoins)
– First transaction in every block (only one)
– Only one input, previous TX ID = 0x0000..00, prev. TX index = 0xffffffff
– (Typically) equal to block reward + all fees from included transactions
13 | PV204 Bitcoin II.
https://crocs.fi.muni.cz @CRoCS_MUNI
Bitcoin’s Proof of Work (SHA256 function)
• Crucial for security of blockchain (no rewrite of history)
• Initially on CPU (Satoshi: “Everyone can participate 1 CPU 1 vote”`)
• CPU→GPU →FPGA →ASIC
• Initially solo mining, later collaborative mining (too little chance alone)
• First mining pool: SlushPool in Prague (now Braiins Pool)
– Miners join their hashrate, fraction of reward based on number of partial solutions
• Cambridge university centre for alternative finance (CBECI)
– Where are the miners? https://cbeci.org/mining_map/
– More mining details: https://cbeci.org/cbeci/methodology
14 | PV204 Bitcoin II.
https://crocs.fi.muni.cz @CRoCS_MUNI
DEMO: SHOW EVOLUTION OF REWARDS
https://transactionfee.info/charts/block-coinbase-amount/?start=2009-01-09
15 | PV204 Bitcoin II.
https://crocs.fi.muni.cz @CRoCS_MUNI
Miner reward – coinbase output: block + fees
16 | PV204 Bitcoin II.
https://transactionfee.info/charts/block-coinbase-amount/?start=2009-01-09
• Reward halving
– Every ~4 years
– Block reward drops to ½
– Last halving in year 2140
https://crocs.fi.muni.cz @CRoCS_MUNI
Difficulty adjustment
• Bitcoin shall have one block every ten minutes (on average)
• Block must have overall hash with specific number of leading zeroes (March 2023 ~75 binary 0)
– Miners change part of block header to try different hashes until required found
• How to specify the number of leading zeroes for decades in future?
– Speed of new blocks found depends on the overall speed of hashing
– Overall speed of hashing depends on technology advancements (single chip) and number of chips deployed
– Impossible to predict technology and interest into distant future
– If # zeroes is too low => blocks are found too fast (and vice versa)
• Idea of difficulty adjustment (part of consensus protocol), https://en.bitcoin.it/wiki/Difficulty
– Check number of actually mined blocks every 2016 blocks (shall be ~14 days)
• Increase/decrease difficulty for next period based on actual number of mined blocks
– Every full node can deterministically compute expected difficulty (lower # zeroes rejected)
• Block hash must be below the “Target” number (computed to avg keep 1 block / ~10 min)
– “Target” is transformed to “Bits” (condensed 4 bytes number – coefficient (3B) + exponent (1B))
– Current difficulty is relative number of current Target with respect to Target of Genesis block
17 | PV204 Bitcoin II.
https://crocs.fi.muni.cz @CRoCS_MUNI
Hashrate in time (>320EH/s = 3.2*1020 hash/sec = 266 /sec)
Peak 26.3.2023: 400,000,000,000,000,000,000x SHA256
computations per second
18 | PV204 Bitcoin II.
https://mempool.space/graphs/mining/hashrate-difficulty#all
https://crocs.fi.muni.cz @CRoCS_MUNI
DEMO: SHOW DIFFICULTY ADJUSTMENT,
HASHRATE
https://mempool.space/
https://mempool.space/graphs/mining/hashrate-difficulty#all
19 | PV204 Bitcoin II.
https://crocs.fi.muni.cz @CRoCS_MUNI
Blockchain forks
20 | PV204 Bitcoin II.
• Occasional natural forks happen
– (not to be confused with softforks)
• Quickly resolved
– usually, next block
• Sometimes temporary doublespent
can occur
– Same input used in different txs
• https://forkmonitor.info/nodes/btc
https://crocs.fi.muni.cz @CRoCS_MUNI
DEMO: SHOW NATURAL FORKS
https://forkmonitor.info/nodes/btc
Double spent tx https://forkmonitor.info/stale/btc/782129
21 | PV204 Bitcoin II.
https://crocs.fi.muni.cz @CRoCS_MUNI
China mining dominance (09/2019→04/2020: 75.6%->65%)
22 | PV204 Bitcoin II.
09/2019
04/2020
https://crocs.fi.muni.cz @CRoCS_MUNI
Bitcoin mining map (January 2022)
23 | PV204 Bitcoin II.
• China used to be largest
– >80% (till 2018, slow decrease)
– Mining ASICS made in China
• China evicted “all” miners in
May 2021
– Officially 0% (unofficially still active)
– Now coming back 21.11%
• Resulted in strong increase in:
– US 37.84%, Kazakhstan 13.22%
– Canada 6.48%, other 9% …
https://cbeci.org/mining_map/
https://crocs.fi.muni.cz @CRoCS_MUNI24 | PV204 Bitcoin II.
https://twitter.com/thevonwong/status/1639690663846375424
@thevonwong
https://crocs.fi.muni.cz @CRoCS_MUNI
Is Bitcoin mining wasteful?
• Heavily discussed topic (“Bitcoin boils the oceans by 2020”)
• Some questions to ask (Do your own research!)
– What value you are getting for the energy expended? (neutral decentralized monetary system)
– Miners want the cheapest energy available to maximize profits => energy nobody wants =>
waste energy
– What is the source of the energy used? (btc mining ~60% “green” energy due to its low cost)
– Can mining help to stabilize electrical grid with intermittent (solar, wind) sources? (instant turn
on/off of mining ASICs, consumption only when cheap (= not demanded) energy)
– How long is mining hardware profitable before dismantling? (depends on energy price, 5+ years)
– Can miners finance construction of energy sources (hydro…) at places otherwise not viable
financially (stranded energy)?
– Can miners incentivize higher portion of intermittent (solar, wind) sources? (bigger source even
when low sun/wind?)
25 | PV204 Bitcoin II.
@thevonwong
https://crocs.fi.muni.cz @CRoCS_MUNI
UPGRADING BITCOIN FUNCTIONALITY
26 | PV204 Bitcoin II.
https://crocs.fi.muni.cz @CRoCS_MUNI27 | PV204 Bitcoin II.
https://crocs.fi.muni.cz @CRoCS_MUNI
Options for upgrades
• Upgrading software in centralized environment is relatively easy
• Who sets rules for upgrades of Facebook WhatsApp?
– Decision by FB management, implementation by FB developers
– State regulation (e.g., customer protection laws, GDPR…)
– Pressure of users (e.g., postponed date for EULA acceptation from February to May 2021)
• Who can influence technical consensus rules of Bitcoin?
– Bitcoin Core full node is open-source (everybody can modify)
– Softfork – backward compatible (non-actualized nodes will accept)
• Old nodes only cannot use new functionality
– Hardfork – backward incompatible (non-actualized nodes will reject)
• E.g., change of block reward, block size, mining difficulty (=> average time per block), PoW vs. PoS…
• Bitcoin performs only softforks (to keep valid rules from time when you acquired your “bitcoins”)
| PV204 Bitcoin II.28
https://crocs.fi.muni.cz @CRoCS_MUNI
How to agree on code changes in Bitcoin Core?
• Changes NOT influencing consensus rules
– E.g., code optimizations, changes in GUI/CLI…
– „Common“ development process, pull requests + discussion + thorough review
• Changes influencing consensus rules
– Discussion of the proposed change idea + example implementation
– After some time, an attempt to include change into main branch repository
• How to decide if change shall be accepted or rejected?
– Initially direct changes by Satoshi Nakamoto
– Later small group of Bitcoin Core developers
– Later development of various methods for signalization of readiness for acceptance or rejection
• Basic economic actors of Bitcoin ecosystem
– Developers, miners + pools, operators of full nodes, owners of wallets, exchanges…
| PV204 Bitcoin II.
Change
implementation
Selection of txs for
new block, mining
Selection of blocks deemed to
be correct, propagation of new
transactions (mempool)
Intent to own
bitcoin (investors)
29
https://crocs.fi.muni.cz @CRoCS_MUNI
Segregated witness (Segwit), softfork, August 2017
• Backward-compatible upgrade (soft fork) activated in August 2017
• Introduced the following changes:
– Block size increase (up to ~4MB, witness data bytes discounted by 1/4)
– Fixes transaction malleability (signature excluded from transaction ID computation)
– Support for clear future versioning (special code rule for OP_0 <20-byte hash>)
• Additional witness data send only to node which requests it
– Backward compatible, older nodes will not ask
– Segwit transaction looks to them as “anyone-can-spend” script
• Significant controversy called “Blocksize wars” (several hardforks)
– “Big blockers” wanted larger blocks or dynamic blocks to keep transaction fee low “forever”
• But larger blocks increase blockchain size => less people able to run fullnode => centralization
– New York Agreement, User Activate Soft Fork (UASF)
– Demonstrates problems of decentralized social consensus (Schelling point)
30 | PV204 Bitcoin II.
https://crocs.fi.muni.cz @CRoCS_MUNI
Taproot, softfork, October 2021
• Backward-compatible upgrade (soft fork) activated in October 2021
• Introduced the following changes:
– Added support for Schnorr signatures (more compact, easier MPC…)
– Increased privacy (Schnorr-based multiparty signature, Musig2, FROST…)
– More powerful “Tapscript” added
• Not controversial, generally believed to be wanted improvement
– “Speedy trial” used
31 | PV204 Bitcoin II.
https://crocs.fi.muni.cz @CRoCS_MUNI
Path to Taproot softfork
• 1990 publication of Schnorr signatures, 2008 expiration of patent
• Discussion for use in Bitcoin for a very long time
• 2018 formal Schnorr Bitcoin Improvement Proposals (BIPs 340, 341, 342)
• 2019 discussion of parameters, update of BIPs
• 2020 example implementation, available for testing on signet
• 2020/2021 discussion how to activate: signalization by miners vs. full nodes (UASF)
• Speedy trial – signalization by miners (according to BIP9)
– Approximately 3 months to achieve >90% blocks in last 2016 blocks
• Possible option: User Activated Soft Fork (UASF), BIP8
– If not activated by miners, some full nodes will start to reject mined blocks without Taproot signalization (possible
fork of blockchain, mined block will not receive reward if abandoned => economic pressure on miners to activate)
• 12.6.2021 Taproot locked-in
– Actualized implementations started to enforce Taproot rules from block 709632
• 14.11.2021 6:15UTC Taproot “activated” (first block mined)
32 | PV204 Bitcoin II.
https://crocs.fi.muni.cz @CRoCS_MUNI
https://taproot.watch/
| PV204 Bitcoin II.33
https://crocs.fi.muni.cz @CRoCS_MUNI
První „Taproot“ transakce (P2TR)
| PV204 Bitcoin II.
https://blockstream.info/tx/777c998695de4b7ecec54c058c73b2cab71184cf1655840935cd9388923dc288
34
https://crocs.fi.muni.cz @CRoCS_MUNI
Future Bitcoin upgrades
• Protocols tend to ossify with adoption (e.g., TCP protocol)
– Difficult to update software at once, increased probability of problems after change
• Many discussed future changes (some already tested on Signet)
– OP_VAULT (convenance)
– SIGHASH_ANYPREVOUT (Eltoo, channel factories)
– Cross-input signature aggregation (one signature for multiple inputs)
– Drivechains, spacechains…
– (Time representation in block will overflow in 2106)
• Potential hardforks?
– (Quantum computer breaking ECDSA)
35 | PV204 Bitcoin II.
https://crocs.fi.muni.cz @CRoCS_MUNI
THRESHOLD SIGNATURES VS. MULTISIG
VS. MULTI-PARTY COMPUTATION
36 | PV204 Bitcoin II.
https://crocs.fi.muni.cz @CRoCS_MUNI
Making fresh private keys (with backup) BIP32, BIP44…
37 | PV204 Bitcoin II.
• Deterministic derivation from:
– master seed (key)
– derivation path (data)
• m/purpose/coin/account/receive…
• Single master seed allows:
– Generate many distinct private keys
– Sharing sub-tree value allows:
• Generate keys in sub-trees
• Cannot generate keys from other trees
• Deterministic generation, Master Seed enough to recover whole tree
https://crocs.fi.muni.cz @CRoCS_MUNI
1. Shamir’s threshold secret sharing scheme
• Private key is recovered from
multiple shares
– Then used at single place
– An attacker can compromise private key
after its recovery from shares
• Network is unaware of key split,
single public key used in lock script
• Can be used to backup wallet seed
(e.g., Trezor wallet https://trezor.io/shamir/)
– n-out-of-n or k-out-of-n
38 | PV204 Bitcoin II.
https://trezor.io/shamir/
https://crocs.fi.muni.cz @CRoCS_MUNI
Multisignatures
• Lock script constructed to require multiple signatures
(OP_CHECKMULTISIG)
– transaction valid only if multiple signers provide signatures for unlock script
• n-out-of-n or k-out-of-n, https://en.bitcoin.it/wiki/Multisignature
• P2MS, P2MS wrapped in P2SH
– https://learnmeabitcoin.com/technical/p2ms
39 | PV204 Bitcoin II.
https://crocs.fi.muni.cz @CRoCS_MUNI
Secure multi-party computation (MPC)
• Single signature computed using multiple separated signers
– Each signer has own private key
– An attacker must comprise more than one entity
• Communication between signers
– During initial key generation
– Optionally during signing
• Legacy compatible schemes (produces valid ECDSA signature)
– 2-party ECDSA, n-out-of-n or k-out-of-n ECDSA (only since 2016)
• Taproot-compatible schemes (activated since Nov 2021)
– Schorr signatures, MuSig2, FROST…
• https://academy.binance.com/en/articles/threshold-signatures-explained
40 | PV204 Bitcoin II.
https://crocs.fi.muni.cz @CRoCS_MUNI
Frequency of different multisignature scripts
• Cannot tell for Shamir, MPC ECDSA and Schnorr (e.g., MuSig)!
– Resulting signature is standard signature, no change to lock/unlock scripts
• Can tell for P2MS
– Threshold and allowed public keys inside lock script
• Can tell for P2SH (if spent)
– Multisig script and used keys inside unlock script
• (analogically for Segwit variants)
41 | PV204 Bitcoin II.
https://crocs.fi.muni.cz @CRoCS_MUNI
Partially Signed Bitcoin Transaction (PSBT), BIP-174
• Standardized way how to represent unsigned Bitcoin transaction
– Transaction skeleton is created (inputs, outputs, amounts…)
– But unlock script not completed (actual signature/signatures are missing)
• Suitable for sharing PSBT between multiple signers in secure way
– Serialized transaction can be passed using USB, file, QRCode, NFC…
• When all signers sign, transaction can be broadcasted to p2p network
– Unless fully signed, transaction is invalid and would be rejected
• Binary format (for compactness), but can be decoded to json
– bitcoin-cli decodepsbt "psbt_as_hex_format"
42 | PV204 Bitcoin II.
https://crocs.fi.muni.cz @CRoCS_MUNI
Miniscript (A. Poelstra, P. Wuille, S. Kanjalkar, 2019)
• Language for easier and error-prone creation of Bitcoin scripts
– Subset of Bitcoin script language
– Human-readable, easy to express complex locking conditions
– https://bitcoin.sipa.be/miniscript/
• Simple building blocks (policies)
– Single-key, Multi-key,
– Time-locks, Check-sequence,
– Hash-lock…
• Compiler creates optimal script
– And cost analysis
43 | PV204 Bitcoin II.
https://crocs.fi.muni.cz @CRoCS_MUNI
Miniscript examples
44 | PV204 Bitcoin II.
A 3-of-3 that turns into a 2-of-3 after 90 days
A single key
Bitcoin script
https://crocs.fi.muni.cz @CRoCS_MUNI
Inheritance problem – degradable multisig?
• Copy of seeds – heirs can take your bitcoins
– Not really solving the problem, just shifting it
• Notary – requires trust to people, can take your btc
• Timelock for usage of other keys
– one key immediately, another key only after 1 year (timelock)
– Liana wallet (example), https://github.com/wizardsardine/liana
• https://wizardsardine.com/blog/liana-announcement/
– Requires periodic resend of the money to prevent heirs access
– Relative or absolute timelock use possible
• Degrading multisig
– 4-of-4 immediately, 3-of-4 after 9 months, 2-of-6 after year and half
45 | PV204 Bitcoin II.
https://crocs.fi.muni.cz @CRoCS_MUNI
HARDWARE WALLETS
46 | PV204 Bitcoin II.
https://crocs.fi.muni.cz @CRoCS_MUNI47 | PV204 Bitcoin II.
fullnode
Bitcoin
P2P network
fullnode
SW-only wallet
With hardware wallet
Blockchain
https://crocs.fi.muni.cz @CRoCS_MUNI48 | PV204 Bitcoin II.
Testbed with hardware wallets
https://crocs.fi.muni.cz @CRoCS_MUNI
Research done in CRoCS on hardware wallets
• Transparency of device build (HW/SW/TE)
• Multi-Party Computation (signatures, decryption) on limited
hardware
• Analysis of cryptographic implementations (ECDSA, BIP32…)
• Entropy analysis of keys extracted from blockchain
• Usable security
49 | PV204 Bitcoin II.
https://crocs.fi.muni.cz @CRoCS_MUNI
BITCOIN PRIVACY
50 | PV204 Bitcoin II.
https://crocs.fi.muni.cz @CRoCS_MUNI
Risks
• Risk of lost coins
– Lost wallet keys, forgotten access credentials
• Risk of stolen coins
– Malware on computer (wallet keys), phishing/scam (recovery phrase)
– Compromised trusted third party (exchange, web wallet…)
– Random burglary (don’t know you have btc)
– Targeted burglary (know you have btc), with(-out) you present
• Risk of traced coins
– blockchain analysis, additional metadata correlation analysis (KYC/AML, scans, tx
propagation, wallet peeling…)
– Crooks, governments, wife…
51 | PV204 Bitcoin II.
https://crocs.fi.muni.cz @CRoCS_MUNI
Attacker models
• Blockchain-only analysis
• Malware, phishing
• Active network analysis, metadata
• Cryptographic analysis of used algorithms
• Side-channel analysis
52 | PV204 Bitcoin II.
https://crocs.fi.muni.cz @CRoCS_MUNI
Improving privacy
• Hold your private keys (no custodial service like exchange…)
– Cannot steal, cannot observe, cannot “vote” on your behalf
• Store private key in hardware wallet (Trezor, ColdCard, Ledger…)
– Keys in “hot” software wallets are prone to malware attack
• Run own full node over Tor and connect your wallet to it
• Make on-chain analysis harder: https://en.bitcoin.it/wiki/Privacy
• Use manual coin selection, label coins by its origin (in your wallet only)
• Use CoinJoin, PayJoin (multiple users mix their inputs in single transaction)
• Have good opsec (no posting of own btc addresses, use Tor to broadcast tx,
delink via CoinJoin after KYC…)
53 | PV204 Bitcoin II.
https://crocs.fi.muni.cz @CRoCS_MUNI
CoinJoin
• Multiple users collaborates trustlessly in creating large transaction
• Outputs are all the same value => cannot be attributed to one of
senders based on the value
• Supported by more advanced wallets
– Wasabi wallet, Samurai wallet
54 | PV204 Bitcoin II.
https://en.bitcoinwiki.org/wiki/CoinJoin
https://cryptotesters.com/blog/what-are-coinjoins-and-how-do-they-improve-bitcoin-privacy
https://crocs.fi.muni.cz @CRoCS_MUNI
CoinJoin implementations
• Wasabi wallet https://github.com/zkSNACKs/WalletWasabi/
– Centralized trustless coordinator, Tor, selected number of rounds executed within hours
• https://docs.wasabiwallet.io/using-wasabi/CoinJoin.html
– Wasabi 2.0 (beta) offer non-equal output coinjoin https://blog.wasabiwallet.io/privacy-guarantees-of-wasabi-wallet-2-0/
– Anonymity set decrease over the time as people send their outputs to KYC exchanges
• Samourai Whirpool https://docs.samourai.io/en/whirlpool
– CoinJoin with variable number of rounds, centralized trustless coordinator
– CoinJoin runs until output is send away from Whirpool (days/months)
– If not fullnode then xpub must be provided => privacy risk, decreased anonymity set
• e.g., Samurai RoninDojo https://ronindojo.io/
– Clients: Samourai wallet / Whirpool cli, SparrowWallet (using Samourai code)
• JoinMarket
– No central coordinator, market Maker(s) run own fullnode and provide liquidity
– Coinjoin transaction creation is coordinated by Taker who is paying also fee (on-chain and to the Maker)
– JoininBox - JoinMarket cmdline-focused distribution https://github.com/openoms/joininbox
55 | PV204 Bitcoin II.
https://crocs.fi.muni.cz @CRoCS_MUNI
PayJoin
• PayJoin is special case of CoinJoin, but with less participants
(typically only two: sender, receiver) and without equal UTXO sizes
• Faster than CoinJoin, done during a normal payment
• https://cryptotesters.com/blog/what-are-coinjoins-and-how-do-they-improve-bitcoin-privacy
56 | PV204 Bitcoin II.
https://crocs.fi.muni.cz @CRoCS_MUNI
ON-CHAIN BITCOIN ALTERNATIVES
57 | PV204 Bitcoin II.
https://crocs.fi.muni.cz @CRoCS_MUNI
Why search for other options (L2/sidechain/altcoins)?
• Why something else than on-chain Bitcoin? List of typical reasons:
1. Cost of sending transaction
– Peak was tens of dollars (for every transfer), variable (from 1sat/vB), but has to increase in future due
to decreasing reward
2. Time to confirm transaction (+ limited block size)
– 4 blocks inside chain commonly required, ~10 minutes per block => ~40 min
3. Traceability of transactions
– Source, destination and amount is on public ledger
4. Limited scripting language (lock script)
– For more complicated smart contracts
5. Mining requirements
– Specialized mining equipment required (ASICs) => may cause centralization if not enough widespread
– Proof of Work is energy intensive (what it means?)
• …
58 | PV204 Bitcoin II.
https://crocs.fi.muni.cz @CRoCS_MUNI
LIGHTING NETWORK
59 | PV204 Bitcoin II.
https://crocs.fi.muni.cz @CRoCS_MUNI
Lighting network https://explorer.acinq.co/
60 | PV204 Bitcoin II.
https://crocs.fi.muni.cz @CRoCS_MUNI
Opening channel
61 | PV204 Bitcoin II.
https://medium.com/@jkendzicky16/the-bitcoin-lightning-network-a-technical-primer-d8e073f2a82f
Note: In future, P2TR will be
used - opening and
(collaborative) closing of
channel looks same as
ordinary payment
https://crocs.fi.muni.cz @CRoCS_MUNI
Some Lighting topics I.
• Custodial Lighting wallet (e.g., Wallet of Satoshi)
– Service hold your private key, full trust in service
• Semi-custodial Lighting wallet (e.g., default BlueWallet, Zap…)
– own key, but trust in 3rd party providing blockchain info
• Non-custodial (e.g., BlueWallet collected to own full node)
– own key, blockchain info and monitoring by own full node
• Inbound, outbound capacity of channel between A and B
– Initial value is given by initial on-chain 2-2 multisig transaction (x:0, x:y, 0:y)
– Changes with every off-chain transaction executed (between A and B)
62 | PV204 Bitcoin II.
https://crocs.fi.muni.cz @CRoCS_MUNI
Some Lighting topics II.
• Sentinel service
– trustless blockchain observer, broadcasts justice transaction in case of old state
detected
– No need for your full node to be always online
• Privacy considerations
– Most of the transactions are NOT recorded on the blockchain
• Good for speed as well as privacy
– Doesn’t mean that payments are not traceable
• Same as with internet connection => need to use Tor, ideally mixes…
• Privacy of sender is significantly better than receiver
– Taproot introduced ability to open channel indistinguishable from normal P2TR
63 | PV204 Bitcoin II.
https://crocs.fi.muni.cz @CRoCS_MUNI
Study materials
• Lighting network
– ‘What is the Lightning Network?’ by 99Bitcoins (7 minutes)
• https://www.youtube.com/watch?v=pBh4DcM-0pg
– Watch ‘A Technical Introduction to The Lightning Network’ by A. Antonopoulos
(43min)
• https://www.youtube.com/watch?v=E1n3sKKPD_k
64 | PV204 Bitcoin II.
https://crocs.fi.muni.cz @CRoCS_MUNI
Lightning network – study more
• Description of Lighting Network basic principles
– https://medium.com/@jkendzicky16/the-bitcoin-lightning-network-a-technical-
primer-d8e073f2a82f
• Presentation by original Lighting creators
– https://lightning.network/lightning-network.pdf
• List of Lighting nodes ready for channel opening
– Bottom of the https://store.blockstream.com/
65 | PV204 Bitcoin II.
https://crocs.fi.muni.cz @CRoCS_MUNI
CASE STUDY: ORDINALS/INSCRIPTIONS
66 | PV204 Bitcoin II.
https://crocs.fi.muni.cz @CRoCS_MUNI
Case study: Ordinals/Inscription (NFT)
• Non-Fungible Token (NFT)
– Unique digital asset, cannot be exchanged for other units of the same type
– Dollars or satoshis are fungible (1$ = 1$), while NFT is non-fungible
– Examples: jpegs, movie, music, numbered ticket, numbered equity…
– Ownership can be transferred (methods depends on the underlying chain)
• Frequently, tied to blockchain like Bitcoin (Colored Coins) or Ethereum
– Only URI and hash is stored in contract, actual picture/NFT stored elsewhere
– Centralized DB (S3), Decentralized filesystem (e.g., IPFS)…
• Problem: What if storage place is erased?
– Actual NFT is lost, only reference on-chain is kept
67 | PV204 Bitcoin II.
https://crocs.fi.muni.cz @CRoCS_MUNI
Case study: Ordinals/Inscriptions (NFT)
• NFT needs two principal components
– Non-fungible (transferable) reference for NFT [Ordinals]
– Storage place for actual NFT content (picture, movie, 3d model) [Inscriptions]
• Ordinals (https://docs.ordinals.com/overview.html)
– Virtual unambiguous numbering scheme for every satoshi mined so far
• xth satoshi mined, keeps its number
– When UTXO is spent, all its satoshies (already numbered) are distributed on
ordered basis (FIFO, first-satoshi-in-first-satoshi-out)
– Important: no “serial number” is put on blockchain, everything is just virtual overlay
– https://github.com/casey/ord/blob/master/bip.mediawiki
68 | PV204 Bitcoin II.
https://crocs.fi.muni.cz @CRoCS_MUNI
Case study: Ordinals/Inscriptions (NFT)
• Inscriptions (https://ordinals.com/inscriptions)
– Requires Taproot (P2TR address), first tx spends sats, second reveals script
– Embedding of data into witness script in non-spendable path (OP_FALSE)
– Inscription is on first sat of first output
– Ownership can be transferred to other person (ordinals)
• Transaction fee needs to be paid
– Data are in discounted Segwit bytes (¼ price)
– But inscriptions are typically significantly larger than tx
• Ordinary tx is 100-200 sats, data 1024 sats / kB
– Significant number of transactions in Jan-March 2023
69 | PV204 Bitcoin II.
https://mempool.space/tx/f4ebd57b33590f0eb7b9f391a0a5237d6e4b69f5846f20a87da1e9481e7b49a7
https://ordinals.com/inscription/f4ebd57b33590f0eb7b9f391a0a5237d6e4b69f5846f20a87da1e9481e7b49a7i0
https://crocs.fi.muni.cz @CRoCS_MUNI70 | PV204 Bitcoin II.
https://transactionfee.info/charts/block-size/
Segwit activation July 2017
(blocks can be up to 4MWU)
Ordinals/Inscription
Feb 2023
(non-financial data in
witness part)
https://crocs.fi.muni.cz @CRoCS_MUNI71 | PV204 Bitcoin II.
https://crocs.fi.muni.cz @CRoCS_MUNI
Case study: Ordinals/Inscriptions discussion
• Inscriptions are controversial and discussed (March 2023)
• What do you think?
72 | PV204 Bitcoin II.
https://crocs.fi.muni.cz @CRoCS_MUNI
Case study: Ordinals/Inscriptions discussion
• Inscriptions are controversial and discussed (March 2023)
• Discussion points (Do your own research!)
– Blockspace used for non-financial data, needs to be downloaded/stored by all
• Segwit part, only download, fast verification (OP_FALSE), no UTXO set bloat
– Legal implications (3d printed guns, child abuse material…)
– NFT getting discount price, spam
• Segwit data bytes are discounted, but ordinary tx is significantly more dense => shall
outprice Inscriptions
– Pricing out people wanting to do on-chain transactions for small value
• Mainnet not meant for small tx longer (Lighting, sidechains)
• Is now increasing rewards for miners => more blockchain security
– Impacting fungibility of Bitcoin, push for more smaller transactions (UTXO set)
73 | PV204 Bitcoin II.
https://crocs.fi.muni.cz @CRoCS_MUNI
Q&A
74 | PV204 Bitcoin II.
https://crocs.fi.muni.cz @CRoCS_MUNI75 | PV204 Bitcoin II.
Audience Q&A Session
ⓘ Start presenting to display the audience questions on this slide.
https://crocs.fi.muni.cz @CRoCS_MUNI
RUNNING OWN FULL NODE
76 | PV204 Bitcoin II.
https://crocs.fi.muni.cz @CRoCS_MUNI77 | PV204 Bitcoin II.
fullnode
Bitcoin
P2P network
fullnode
SW-only wallet
With hardware wallet
Blockchain
https://crocs.fi.muni.cz @CRoCS_MUNI
Running own full node
78 | PV204 Bitcoin II.
https://crocs.fi.muni.cz @CRoCS_MUNI
Additional software to run on “full node”
• Bitcoin Core basic client (bitcoind, bitcoin-qt)
– Many additional software packages possible
• Lighting network software (LND, c-Lighting, Eclaire, RTL, LNbits…)
• Payment servers (BTCPay server)
• Blockchain explorers / indexers (Electrum, mempool.space, Explorer…)
• CoinJoin clients (Whirpool, JoinMarket…)
• Multisignature coordinators (DoJo, Specter, CKBunker…)
• Pre-prepared fullnode distributions (software above included)
– MyNode, Umbrel, RaspiBlitz…
79 | PV204 Bitcoin II.
https://crocs.fi.muni.cz @CRoCS_MUNI
Summary
80 | PV204 Bitcoin II.
https://crocs.fi.muni.cz @CRoCS_MUNI81 | PV204 Bitcoin II.
https://crocs.fi.muni.cz @CRoCS_MUNI82 | PV204 Bitcoin II.
https://crocs.fi.muni.cz @CRoCS_MUNI
WALLET TOPICS
83 | PV204 Bitcoin II.
https://crocs.fi.muni.cz @CRoCS_MUNI
Generating new “wallet”
• A “wallet” is key management software controlling your private and public keys (ECDSA, Schnorr)
• The most important part of wallet is random number called root seed (128 or 256 bits)
• Root seed is used to deterministically generate practically unlimited number of keypairs
– Specified in BIP32, “root seed” and “derivation path” used to derive next private key => next public key => next address
• Clever construction allowing to compute future public keys (and only public keys) for specified
derivation path without the need for root seed (aka xpub or extended public key)
– Knowledge of xpub allows to compute all future public keys, but not private keys
– Owner of root seed can compute all future private keys and their corresponding public keys
– xpub allows to pay someone to fresh addresses noninteractively (no interaction with owner of root seed required),
receiver will only later compute candidate private keys and their public keys to check for total balance (== set of UTXOs)
• Wallet software is monitoring blockchain for addresses corresponding to stored root seed (or xpub)
• Root seed can be stored:
1. Directly in software wallet (file on harddisk, optionally encrypted) == aka hot wallet, least secure against malware
2. Loaded every time before use (e.g., from QR code), still vulnerable to malware during use
3. On external hardware signing device called hardware wallet (the most secure option)
84 | PV204 Bitcoin II.
https://crocs.fi.muni.cz @CRoCS_MUNI
• 128 or 256 bits of entropy (12 or 24 words)
• How to store securely?
– Write on paper, punch into metal plate, carve into stone…
– How to prevent human typing error (bits → mnemonics, BIP39)
– Do not write somewhere digitally (malware may steal it)
• How to prevent single point of failure?
– Make two copies (=> more robust against accidental loss)
– Make (threshold) parts Shamir (=> more robust against
intentional theft and loss - threshold)
– Require multiple signatures (multisig, MPC)
85 | PV204 Bitcoin II.
https://coldbit.com
Backing up entropy (“master seed”)
https://crocs.fi.muni.cz @CRoCS_MUNI
Making fresh private keys (with backup) BIP32, BIP44…
86 | PV204 Bitcoin II.
• Deterministic derivation from:
– master seed (key)
– derivation path (data)
• m/purpose/coin/account/receive…
• Single master seed allows:
– Generate many distinct private keys
– Sharing sub-tree value allows:
• Generate keys in sub-trees
• Cannot generate keys from other trees
• Deterministic generation, Master Seed enough to recover whole tree
https://crocs.fi.muni.cz @CRoCS_MUNI
Receiving (testnet) bitcoins
• You generate new “address”
– deterministically derived from your root seed and fresh derivation path (path + counter) => new ECDSA
keypair [BIP32]
– public key X is pasted into locking script (“who can sign with private key verifiable with X can move bitcoin
further”) and hashed => “address” [P2SH/P2WSH] (Pay to witness script hash)
• Service coinfaucet.eu owns multiple tBTC
– Service is providing limited number of test bitcoins (tBTC) for free
– Service owns UTXOs => someone previously locked some tBTC to their keypair(s)
– Service creates new transaction with some tBTC locked to your “address”
– New transaction is broadcasted to Bitcoin P2P network and stored in mempools (set of unconfirmed
transactions)
• Miners will eventually include this transaction into new block (head of blockchain)
– Confirmed and removed from mempools
– Your Sparrow wallet is monitoring both mempool and blockchain (instant notification about pending
transaction)
87 | PV204 Bitcoin II.
https://crocs.fi.muni.cz @CRoCS_MUNI
Blockchain explorers
• Everybody with access to Bitcoin P2P network can analyze blockchain
– Everybody running Bitcoin fullnode
– All past transactions, human-readable visualizations, search for address…
– Convenient quick check of funds send
• Third parties are operating public explorers (convenient, but privacy risk)
– It is very important to use Tor Browser when accessing public block explorers
– Explorer operator may log your IP address and transactions you are searching for and later
sell it (chain surveillance companies)
• Heuristic assumption that you are the owner of funds for searched transaction
• Ideally use your own full node with your own blockchain explorer
• Sparrow wallet allows you to visualize your transactions
– Inputs, outputs, feed paid
88 | PV204 Bitcoin II.