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.