Episode 26: Lloyd discusses his bitcoin journey, current projects (GUN CLI wallet & FROST multi-signature protocol), and Lightning Network privacy (including how payment hubs may provide a solution).
Discount link: https://hardblock.com.au/join/ozbitcoinpod
Guest: https://twitter.com/llfourn (https://github.com/llfourn) - Contact Lloyd to work on bitcoin development with him in Malaysia!
Host: https://twitter.com/mission_bitcoin
Notes
- Lloyd's bitcoin journey and getting into bitcoin (and cryptography) development
- Developing the GUN (Go Up Number) command line interface bitcoin wallet
- Developing the stripped-down DLC (discrete log contracts) betting/wager extension for GUN
- Working on FROST, a new multi-signature protocol that uses Schnorr threshold signatures with a single public key (rather than multiple public keys being disclosed on the blockchain like in 'traditional' multi-signature protocols)
- Privacy-improving and data-saving (leading to fee-reducing) affects of Schnorr signature aggregation
- History of why ECDSA (elliptic curve digital signature algorithm) was used initially over Schnorr signatures (spoiler: it's related to patents)
- Lightning Network (LN) privacy considerations:
- Where (on-chain) are your LN channel open transactions originating from?
- Practical tip: using coinjoins or coinswaps before opening LN channels can improve privacy
- Privacy versus convenience trade-offs when sending LN directly to your recipient versus sending via multiple intermediary hops first
- More hops on a LN payment pathway is not always better (eg, it can lead to payment failure, and could erode privacy if multiple of those routing nodes are surveilling the network))
- Practical tips: keep all your channels unannounced ("private") and only connect with nodes you trust are not performing network surveillance
- Will PTLCs (point time locked contracts) improve LN privacy more than currently-used HTLCs (hashed time lock contracts)?
- Channel probing attacks exist today to discover "private" (ie, unannounced) LN channels and to determine their channel balance; this is exacerbated by public channels announcing all of their identifying details (which makes process-of-elimination and brute-force attacks more viable on the remaining unannounced channels)
- What you do with your on-chain coins (UTXOs) after closing a LN channel can be important with regard to privacy; in fact, what your channel
partners do with their on-chain UTXOs post channel close can also impact your privacy!
- Practical tip: coinswap or coinjoin your left-over UTXO after closing a LN channel
- Cross-layer links (ie, base-layer and LN layer) are bad for privacy, but some improvements are coming (eg, using unique channel aliases/IDs with each LN node you connect with, rather than a reused channel ID that can be linked easily back to your on-chain UTXO)
- Practical tip: run your own node (but be mindful it can be done badly - there are cases when using a trusted third party may be better)
- LN sender-side privacy is generally better than receiver-side, as a LN invoice to receive a payment will leak private information (eg, which UTXO belongs to the node)
- Practical tip: don't re-use LN invoices
- A potential LN privacy and convenience solution: using payment hubs, similar to the Tumblebit proposal and Chaumian e-cash mints (eg, FediMint or MiniMint), but with added improvements with regards to custody of funds and transaction output size
- Attending the Asia-Pacific Bitcoin Socratic to help flesh out bitcoin improvements
References
https://bitcoinproblems.org
https://github.com/bitcoin-sydney/socratic
https://abytesjourney.com/lightning-privacy