2022 Dec 26

• Went through these slides on Lightning as a more secure communications layer distinct from the web. I need to look into the lightning part more (BOLT 08 + 10). From what I understand, the big problem with the web is TLS. HTTPS relies on people trusting certificate authorities (CA), which can be compromised, particularly intermediary certificate authorities, e.g. actually happened with the Iranian government snooping on Gmail traffic. To establish an encrypted connection, the client first verifies the public key of a server by checking if it has a digital certificate from a trusted CA (on TLS). However CAs actually delegate to intermediary CAs which our browser also just trusts I guess? Intermediary CAs (and technically root CAs) can be compromised, i.e. inauthentic certificates can be made, and now we’re sending messages to someone that isn’t who they say they are.

  • I’m honestly not sure how communicating over lightning solves this, as with any communication with someone over the web for the first time without prior contact, won’t you need some level a trust? I think Lightning may be more secure because you can directly communicate between nodes instead of having to host stuff on a separate web server that you have to trust?

  • Another thing: DH is forward secret while RSA is not. Forward secrecy means if an attacker finds out a long-term secret in the future, they cannot decrypt previous conversations. Anything that’s not like DH is pretty much not forward secret, as a private key is used to decrypt messages, so if it’s revealed then the attacker can decrypt. DH is forward secret because even if an attacker discovers one person’s secret, they don’t necessarily have the shared key. The only way would be for the attacker to also record the initial handshake in order to obtain the other necessary information to find the shared key. (asked GPT)

• Learned about Valera Labs through this podcast episode that I saw posted in the LDK discord. They are building lightning infrastructure, mainly back-end services that enable easier non-custodial lightning usage. Sounds like they’re doing a lot of things. One is indra, which is a “node runtime,” which is basically software that manages many different nodes at once, solving the “always online” problem by spinning them up in an instant whenever needed. Uses LDK for custom nodes. In the talk Azz also mentioned they have a great LSP going, as well as how their whole architecture is meant to operate very well with cold wallets, similar to VLS. Also a large emphasis on custom hardware. Note: this tweet talking about indra progress. The main guy Azz is 16 years old, and the company is based in Cayman Islands. Seems pretty hardcore. Another cool resource on Indra.

  • One thing I will note is although it’s technically non-custodial, they are right to say it’s “semi-trusted.” You own your own keys, but all of the channel state and node data is on their servers. Nevertheless, this is a huge value add, and serves its own purpose in the ecosystem. I think for many users, what Valera is building will probably end up being their preferred sweet spot between self-custody and ease of use.

• Zero-conf channels. Basically exactly what they sound like. Funding transaction doesn’t need to be included in a block yet to start using lightning. Only fit for use with trusted peers. Can enhance UX with trusted LSP/wallet provider. Was added to rust-lightning in June 2022.

• Rapid Gossip Sync. A big performance bottleneck is that when a node comes back online, it needs to get up to date on the state of it’s channels, and also other public channels in order to do routing. Up until now, the basic Gossip protocol to communicate this information is assumed to deal with nodes that are online, that are continuously listening for channel updates and announcements. Given this, they include a lot of redundant information. If you are trying to run a node on a mobile device, it might take up to a couple minutes to get synced, which hurts UX if you just want to open the app and send a payment. With rapid gossip sync, you can deploy a server to take snapshots on some regular interval, and it can significantly reduce (50MB → 5MB! ~0.4 sec sync!) bandwidth required to sync because it can omit a lot of data knowing your node is receiving this big batch. This can make it more practical to route privately on a mobile device without giving up your privacy to third-party servers or sacrificing UX.

• Found new issue to do that will be good for helping me learn about other parts of the repo: persisting payments data to disk

• Commented on new issue and started looking into it: CLI history/up-down keys