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: <T> OP_CLTV DROP <B's Key> OP_CHECKSIG
ScriptSig: <Sig> [must also include lock_time >= T]
Example 2 (B can spend, A can reclaim after time T):
ScriptPK: IF <B's Key> ELSE <T> OP_CLTV DROP <A's Key> ENDIF OP_CHECKSIG
B's ScriptSig: <B's Sig> OP_0
A's ScriptSig: <A' Sig> 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 <y> OP_EQUAL <B's Key> OP_CHECKSIG
ScriptSig: <Sig> <x>
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 <y> OP_EQUALVERIFY <B's Key>
ELSE <T> OP_CLTV DROP <A's Key> ENDIF OP_CHECKSIG
B's ScriptSig: <B's Sig> <x> OP_0
A's ScriptSig: <A' Sig> 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 <<T
So build skiplist. Each block contains not just prev pointer, but
Array where prev[i] is most recent block with hash <= T/2^i
Intuition: can return compact proof by returning higher-difficult subchains
Return last k blocks always, then for previous height - k blocks:
- return m blocks linked by prev[i] for greatest i
- for lesser i's return up to 2m most recent blocks
Non-Interactive Proof of Proof of Work (NIPoPoW) <https://nipopows.com/>
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 <NewCoin address> (destroys BTC)
Submit special NewCoin tx with SPV proof you destroyed bitcoin
NewCoin ruls will issue proportional number of coins to <NewCoin address>
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* <https://blockstream.com/sidechains.pdf>

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