Lull and light clients | 2023 Jan 29-Feb 4

This week I wanted to mix things up and start trying to use LDK to build something myself. I figure I should probably use the software if I want to contribute to it. Although I didn’t produce very much output, I learned a lot from just trying my hand at this for a week. Otherwise, I felt sort of slow this week, partly because I got a migraine for the first time, and just generally was more distracted than normal. When I couldn’t focus enough to do any real lightning work, I could still do some cryptopals challenges. I feel like I’m getting very familiar with the basics through these exercises.

Wallet Development

Part of the reason I wanted to contribute to LDK in the first place was because I align with it’s goal of making non-custodial lightning meaningfully practical on resource-constrained devices, such as mobile. So when starting to try and use LDK I wanted to start in this general direction (not mobile yet, but a wallet).

I learned a lot about wallet development and light clients in particular through the process.

I barely got through even just LDK’s building a node tutorial in Rust, but it led me to look into aspects of wallet development I previously had little background knowledge on, and I got a better understanding of all the pieces that plug into lightning and particularly in the context of making a mobile wallet.

Biggest thing was learning about light clients: SPV, Electrum, and BIP 157/158. My big takeaways were:

1. It’s only reasonably safe to use light clients if the majority of the network is run by full nodes. Light clients are sheep, and will blindly follow even if there are consensus changes from miners. Full nodes take a stance by validating consensus. If miners were to fork (to say increase block rewards), it would be important that the majority of user-facing software would be in communication with full nodes validating consensus such that miners can’t independently change consensus for many users. When people say Segwit showed that the users control Bitcoin, “the users” are people running full nodes. That’s really cool, and a nuanced concept that never really set in until now (as always, the process of writing is so valuable).
2. There are two relatively safe models for light clients. 1. connect to your own personal/trusted node, or 2. connect to multiple nodes and reconnect to different ones intermittently. With light clients if you’re connected to public nodes, you can’t be sure they’re giving you the correct blocks, so you can’t rely on just a single one, similar to how a full node discovers the chain with the most work on the normal Bitcoin network.
3. Compact block filters (BIP 157/158) are important for lightning because you have higher assurances that you’re not missing blocks, and lightning requires you to take action upon certain transactions being confirmed. It takes more bandwidth because you’re often downloading filters/headers that you don’t necessarily need (as the filter is essentially a compressed set of scriptpubkeys where filters are provided in response to a request for blocks that include a certain scriptpubkey, i.e. producing false positives, from what I understand), but also it can be more private because you’re not revealing the exact transaction you’re looking for.

It seems to me BIP 157/158 is probably a better way to go, but it seems Electrum is the most widely used/supported: used in Blockstream’s explorer and public server API esplora, used by Phoenix, and supported in BDK (while BIP 157/158 is currently experimental), among others.

Those were the main things. Still lots more the learn, but nevertheless, learned a lot this week.