2023 Feb 07

• In the discord, someone asked about exposing the ip:port info of connected peers, and someone said that they didn’t even keep that info until recently. My question: how do nodes communicate without ip:port???

  • It’s not magic lol, LDK just doesn’t keep the state itself, it holds the abstracted TCP connection (which uses ip:port on a lower level) and has the option to provide ip:port to LDK but doesn’t have to

• Learned about interactive staging/commiting with git add -p and git commit -p. Pretty cool if you want to split up a commit, or only stage certain changes.

• PR was merged! This one took < 24 hours, whereas my first one took ~2 weeks. Lesson: look for good issues, i.e. ones that are straightforward, but more importantly very directly helpful.

• Opened this followup PR.

• Learned about ZFR (Zero Fee Routing). A guy did an experiment where he ran a huge node where he allowed zero fee routing, although he would charge a fee to open a channel with him. Super cool.

  • During the interview, when asked “If there was one thing you could change about the lightning protocol, what would it be?” he answered with the ability to overpay a MPP, i.e. to pay a 10 sat over MPP, send 1 sat over 15 paths, and cancel the other paths after 10 have been received.

  • This interview was only 3 months ago, so I’m assuming it’s not implemented. Would be cool to develop this, because it makes a lot of sense that it could really help success rate of MPP for large nodes.

• Looking into MPP. Confused right now what is the point of payment_secret? And how are MPP tied together? Are they atomic (i.e. either all is paid or none is paid)?

  • Something important I’m understanding: how probing works is that some intermediate hop on a route can probe for final nodes by adding an HTLC with that node and checking the response (or at least something like this…?). It knows the right payment hash and the amount which is (basically..) enough to pretend to be the last intermediate node. payment_secret is another field that is included in the invoice + final node’s onion payload that verifies that the payment/HTLC was actually sent from the intended sender.

  • payment_secret is also said to “tie MPP HTLCs together.” I guess does that just verify that different payments in an MPP all came from the same recipient?

  • From what I can tell, only Base AMP (idk why it’s Amp when it’s not atomic) is implemented in the current spec, i.e. MPP are not atomic…but at least partial payments are incentivized against…? Confirmed they are not “truly” atomic!

  • Questions for the ldk discord:

    • Payment secret verification: I’ve got a clarification question on payment_secret:

      • Because it’s communicated through an invoice, do keysend payments not have them? And does it mean that keysend payments are subject to probing attacks that payment_secret prevents?

        • Answer: the preimage in the keysend payments serves the same purpose!!

      • When it’s said to tie together MPP HTLCs, does that just mean the final node identifies that all the partial payments are connected because they have the same secret, i.e. were sent by the same sender?

        • Answer: yes

    • Do nodes currently only try routes one at a time? Is there a way to overpay/try multiple routes at the same time?

      • Answer: there is a proposal for this somewhere! although likely relies on onion messages

• Lightning-dev mailing list page. Interesting it used to be called a “caching layer”

• Got a bit ahead of myself getting excited about possibly trying to develop the “overpaying” feature that would increase routing success rate. Realized I should really just focus on the problems we face currently, because there’s really still a lot to do.