- Libbitcoin,
Bitcoin's Swiss Army Knife - (Two app ideas built with Libbitcoin)
- 28/07/18 Beijing Bitcoin Meetup
- James Chiang
- Blockchain Tech Consultant
- james.chiang@protonmail.com
Libbitcoin Overview
- C++ Bitcoin Library
- Lead Maintainer: Eric Voskuil
- Initiator: Amir Taaki
- First alternative implementation to Satoshi prototype
- Modular Design
- Independent component builds
- API exposes Bitcoin protocol
- Focus on readability
- Scalable Server-Client Design
- Performant Services
- Scalable client-server interface design
- Useful Toolkit for Bitcoin Applications
App Ideas: Building with Libbitcoin
- Multi-Fork Wallet
- Hierarchical Deterministic Wallets
- Hard Forks & TX Replays
- Building a Multi-fork Wallet
- Lightning Watchtower
- Simple Payment Channel
- State Outsourcing
- Building & Scaling Watchtower
Hierarchical Deterministic Wallets
- HD Tree from Mnemonic
- HD: Hierarchical Determinstic
- Mnemonic: Word-Encoded Secret
- Fresh keys can be derived indefinitely
- HD Wallet Libbitcoin API
- BIP32/39 HD wallet primitives implemented
- HD Tree Structure
- Specific key derivation paths depend on wallet usage
Chain Fork & TX Replays
- At fork height: Same UXTO set
- Wallet keys valid can sign on both chains
- Transaction replay across chains
- Signatures can be valid on both chains
- Hard forked chains have replay projection
- Requires modification of transaction signature algorithm
- Support new chain parameters required...
Replay Protection: Modified Sighash
- Signature hash is signed by private key
- Bcash modifies signature hash marker
- Sighash marker with forkID
- Libbitcoin API parameterises signing
- Sighash marker
- Serialisation Algorithm (e.g. with BIP143)
Multi-Fork Wallet
- Wallet reconstructs HD tree for forked chain
- HD structure regenerated after each fork
- Wallet queries forked chain node for unspent UXTOs
- Libbitcoin Server w/ new chain parameters
- New server for each set of chain parameters
- Wallet can independently broadcast TXs on each forked chain
App Ideas: Building with Libbitcoin
- Multi-Fork Wallet
- Hierarchical Deterministic Wallets
- Hard Forks & TX Replays
- Building a Multi-fork Wallet
- Lightning Watchtower
- Simple Payment Channel
- State Outsourcing
- Building & Scaling Watchtower
Payment Channel: Naive Implementation
- Funding TX and Commitment TX 1
- Funding TX signed by A
- Commitment TX 1 signed by both parties
- Valid Channel Close
- Latest commitment TX is broadcast by either party
- Problem: Invalid Channel Close
- Nothing prevents either party from broadcasting old state
RSMC Outputs
- Revocable Sequence Maturity Contract
- Can be unlocked under two conditions
- Spendable after time-out
- RSMC A is spendable by A after a delay
- Spendable by secret R
- Public key R is generated by both parties
- Public key R is generated without knowledge of secret R
- If R is revealed, the output is no longer exclusively spendable by A
Payment Channel with RSMC's
- Old states are revoked
- RSMC can be spent by counterparty
- Old broadcast states are swept
- Penalty TX by counterparty broadcast
- Chain needs to be watched
- Both parties must monitor chain for invalid commitment transactions
- Watchtower
- Channel participant outsources the monitoring of commitment transactions
Watchtower
- Watchtower watches for broadcast commitment TXID
- Watches chain for first half of commitment TXID
- Stores encrypted penalty TX
- Revoked commitment TX is broadcast
- Watchtower observes TXID of revoked commitment
- Watchtower decrypts and broadcasts penalty TX
Building a Watchtower
- Watchtower stores Tuple (TXID, Blob)
- Each tuple can be monitored independently
- Tuple can be outsources to different watchtowers
- Watchtower parses new blocks for TXIDs
- If TXID is found in store, penalty TX is decrypted and broadcast
- Scaling Watchtower with Libbitcoin
- Performant subscription & query service
- ZMQ interface ideal for scaling