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