Cross-chain transactions ======================== For HW2 prob. 5, assume you can break 64-bit security [after all, Bitcoin is breaking 74-bit security every 10 minutes] As Bitcoin block rewards go down, transaction fees may become significant If blocks not full, could "re-mine" previous block won by someone else "fee sniping" - capture last block's fees plus fees of pending transactions But weakens blockchain security with orphan blocks Warm-up: How can wallets discourage fee sniping? Hint: Recall 32-bit *lock_time* field in each Bitcoin transaction If <500M, specifies min block height at which transaction can execute If >= 500M, represents min unix time at which it can execute [Only applies if sequence != 0xffffffff though] Have wallets by default generate lock_time with next block height Now if you re-mine last block, can't include new transactions But randomly set older time_lock as cover traffic for slow anonymizers Example 1: How can A irreversibly give B coins B can only spend *after* time T? A pays coins to 2-of-2 multisig address owned by A and B, creating UTXO A creates+signs transaction sending this UTXO to B, with lock_time T A gives new transaction to B. B can sign, but can't submit until time T Example 2: How can A give B coins but reclaim them if not spent *before* time T? A creates+signs but doesn't submit tx1 paying coins to B A sends hash of tx1 to B B creates+signs transaction tx2 paying tx1 back to A with lock_time T B sends tx2 to A, and A submits tx1 Annoyances with protocol of Example 2 1. A requires B's interactive participation--A can't just submit 2. Signatures are malleable--why is this a problem? Someone could change signature on tx1 in mempool, now tx2 doesn't work Solution: New Bitcoin opcode OP_CheckLockTimeVerify (OP_CLTV) Spending transaction must have lock_time greater than stack top (Because opcode use to be no-op, must then manually pop time with DROP) Example 1 (B can spend after time T): ScriptPK: OP_CLTV DROP OP_CHECKSIG ScriptSig: [must also include lock_time >= T] Example 2 (B can spend, A can reclaim after time T): ScriptPK: IF ELSE OP_CLTV DROP ENDIF OP_CHECKSIG B's ScriptSig: OP_0 A's ScriptSig: OP_1 [with lock_time >= T] Example 3: A pays B coins, but B must reveal x where y=SHA256(x) to claim ScriptPK: OP_HASH256 OP_EQUAL OP_CHECKSIG ScriptSig: This is known as a *hashlock* transaction [Note these examples could use P2PKH, too, but I'm simplifying] Example 4: A pays B, B must reveal x by time T or else A can reclaim coins ScriptPK: IF OP_HASH256 OP_EQUALVERIFY ELSE OP_CLTV DROP ENDIF OP_CHECKSIG B's ScriptSig: OP_0 A's ScriptSig: OP_1 [with lock_time >= T] This is a *Hashed TimeLock Contract* (HTLC) Now say A has Bitcoin, B has Litecoin and they want to swap Each wants to prevent the other from stealing or wasting coins - A picks random value x, computes y = SHA256(x) - A submits HTLC paying BTC to B with hash y and timelock now + 2 days - B submits HTLC paying LCT to A with hash y and timelock now + 1 day - A claims LTC, revealing x - B uses x to claim BTC This is an *atomic cross-chain swap* What happens if A fails to claim LTC? B gets back LTC in 1 day What happens if B fails to submit HTLC? A gets back BTC in 2 days Can this work for a 3-way trade? Yes - A picks random value x, computes y = SHA256(x) - A submits HTLC for B with hash y, timelock now + 3 days - B submits HTLC for C with hash y, timelock now + 2 days - C submits HTLC for A with hash y, timelock now + 1 day Say you want to verify transaction happened w/o downloading entire blockchain Enlist help of server with full blockchain, but don't trust server Server sends you just block headers + Merkle path to transactions Download just block headers + Merkle path in one block with your transaction What you get from this is Simple Payment Verification (SPV) security You know work was invested in transaction Don't know that miners were honest (could be in ill-formed block) Can we make this even smaller? Yes with a Proof-of-Proof-of-Work Observation: In a blockchain with target T, some hashes should be < But some serious gotchas, so check out details before implementing Say you have brilliant Blockchain idea, but incompatible with Bitcoin Very hard to upgrade Bitcoin--all miners would need to upgrade So just build new clean-slate blockchain NewCoin? Two problems: 1. How do you distribute the coins and convince people they have value? 2. How do you secure the mining? Bit of chicken-and-egg problem (saw Goldfinger attacks last time) Idea for #1: Let people trade Bitcoin for NewCoin Send BTC to address with ScriptPK RETURN (destroys BTC) Submit special NewCoin tx with SPV proof you destroyed bitcoin NewCoin ruls will issue proportional number of coins to So now NewCoin worth 1 BTC? No only costs 1 BTC, because can't go back Could use atomic cross-chain swap to go back, but no guarantee of taker Idea for problem #2: Merged mining Embed NewCoin block header in Bitcoin block header Example: namecoin header marked by fabe6d6d in BTC coinbase ScriptSig Not every Bitcoin miner needs to do this--namecoin has own prev pointer But represents free additional income to miners, so why not? We want a two-way *pegged sidechain* Idea: Add one Bitcoin feature to understand SPV proofs in other blockchains Now move Bitcoin to NewCoin as follows: [Show fig 1 p. 10 of Sidechain paper] - Send to SPV-locked BTC address (requires proof of destruction on sidechain) - Wait for a long *confirmation period* (1-2 days) - Submit SPV proof of locked-up coins to NewCoin - Wait for *contest period* (1-2 days) If anyone submits BTC fork w/o your tx's block, invalidates NewCoin Can try again with new block if your tx still committed Want to Move NewCoin to Bitcoin, just do same in reverse This is really slow (2-4 days). Do we care? Most uses will use atomic cross-chain swap Arbitragers can keep prices roughly in balance with slower sidechain ops How do we do this without Bitcoin script SPV parsing feature? Federated pegs Emulate OP_SideChainProofVerify by semi-trusted consortium of functionairies Send payments to MultiSig BTC address of consortium instead of SPV-locking Maybe BTS later implements OP_SideChainProofVerify as security improvement Blockstream Liquid does this today How do sidechains compensate miners without huge transaction fees? Seigniorage? Tricky, because now more NewCoins than locked up Bitcoins Could fiddle with exchange rate, but demands more of Bitcoin Demurrage - debit people's accounts for parking coins in dormant accounts Send debited coins to miners; keeps # NewCoin = # locked-up Bitcoins Similar to inflationary mining (share of all funds decreases) But as if ever legal contract had to be specified in inflation-adjusted USD Negates some of the advantages of moderate inflation # -- saved for scalability lecture Even better than sidechains, how about no chains... A buys coffee from B every day, only wants to hit blockchain once/month Idea 1: Place deposit 30 coins in 2-of-2 A+B multisig escrow account E Day 1: A signs tx on E paying B 1 coin, and A 29 coins change Day 2: A signs tx on E paying B 2 coins, and A 28 coins change End of month: B co-signs and submits only last transaction to close tab What's wrong here? If B disappears, A loses unspent funds! How to fix? Use timelock--let A reclaim funds if B doesn't close tab