Good morning list,
I would like to point out that one of the main issues with LSPs is that most of them are designed to lock in their customers to their platform. Hopefully, with a common open specification like this, it becomes significantly more feasible for Lightning end-user clients to be able to switch across different LSPs. In particular, I have always pointed out that unpublished channels leak information about your sends and receives to the published node end of the channel. Thus, if you are locked to a particular single LSP, your data belongs to them. You might trust your LSP today to not leak your data. But you might not want to trust your LSP tomorrow. LSPs can be bought out, their operators can change their minds, their servers can be hacked and your data stolen, many things can be done to take your data. And if one end is published while the other end is completely unpublished, an unpublished channel will always leak the sends and receives of the unpublished end, and not even PTLCs can hide that information. If you, as a client, are capable of using multiple LSPs simultaneously (which would be greatly assisted if multiple LSPs implemented this common specification) then you are able to spread out your information across multiple LSPs. That way, only part of your data is at risk of being leaked if one LSP goes rogue and sells your data. Wallet clients might also want to use different node IDs for each LSP (if you have your privkey always online --- which is likely since Lightning really wants online signing --- you can use an HMAC of the LSP node ID with your privkey to generate your per-LSP node ID) to further improve their privacy across LSPs. Thus, I strongly suggest that wallet implementors in particular look at the LSPS specifications and start planning to implement the client-side interfaces. The best Lightning Network, if we must have any unpublished channels at all (in my opinion, unpublished channels delenda est), is one where every published node is an LSP. -- I observe that there have been many new innovations in Lightning, such as "Lightning addresses", which are not even vaguely alluded to in lightning-dev. Thus, I would like to point out this post once again: https://lists.linuxfoundation.org/pipermail/lightning-dev/2023-April/003915.html I would like to continue this post with a short discussion of the so-called "LSPS0", which underlies the LSPS1 and LSPS2 we are asking review for. LSPS0 describes how a client makes requests to an LSP. In brief, it uses a single BOLT8 message ID, 37913, for all LSPS client and LSP intercommnications. The rationale for this is: * Every client needs to somehow talk the BOLT8 protocol to an LSP just to do normal channel opens, HTLC sends, HTLC receives, etc.; using the BOLT8 protocol means you do not have to add more dependencies just to be LSPS-compliant. * Using a single BOLT8 message ID, 37913, makes it more likely that new protocols will not conflict with LSPS. The message ID space is a common public good, and it is best to reduce its use as much as possible. All LSPS specification, no matter how many there will be in the future (and I have a fair number lined up after LSPS2....), will only use exactly this single BOLT8 message ID. Further, inside the LSPS0 37913 message is a JSON object. This use of JSON inside a BOLT8 message has been described as "disgusting" by at least one engineer, and has been controversial even among LSPS participants. The rationale for this requires a bit of philosophical information theory. In principle, a binary encoding is "just" a compressed encoding of some human-readable format. For example, if we assign some offset within the message as `minimum_depth`, we could consider that the offset is actually a magic number, and that magic number is really inside a compression dictionary, with that magic number expanding to the human-readable text `minimum_depth`. Now compressed encodings like this are fairly fine for computers to process, but humans trying to actually implement LSPS specifications would benefit more from the human-readable text. Thus, I argued that it is better to use a JSON encoding, as any binary encoding would just be equivalent to expanding to an equivalent JSON encoding where the offset of a particular binary-formatted field is really just a compression dictionary entry, mapping out to the text `"minimum_depth": `, and that the "real" uncompressed text would be a JSON encoding. This remains true even if you consider TLVs, as the type number is, again, just a magic number that is mapped, in a static compression dictionary (usually written down in some BOLT spec), to some human-readable label. Now compression is useful if you are doing something like designing a payment onion format. You want to fit a single onion with multiple hops into as few lower-level MTUs as you can, ideally fitting an entire multi-hop onion into a single 1500-byte MTU. This is why the onion format has been very stringent and tight; an onion is only 1366 bytes so that with various messaging overheads it can fit into a single 1500-byte MTU. It pays to have a binary format for the payment onion you are using to inform new HTLCs to your peers, as (1) you want payment to be fast and (2) onions need to be forwarded across multiple nodes (and thus need lots of data, each hop needs some bytes for it). However, for most LSPS requests and responses between a single hop --- between the client and the LSP --- even in uncompressed JSON, are less than 1000 byte. Adding compression --- i.e., forcing a binary format --- does not really improve the latency, as a 100-byte MTU takes as much time round-tripping as a 1000-byte MTU. And at least you can easily put the raw JSON from LSPS0 messages in your logs and then if something weird happens, you can copy-paste the JSON into a pretty-printer and get some nicely-formatted JSON you can analyze in detail; if you had to do that with binary formats, you would need to decide how to print it out yourself, and probably need to make your own pretty-printer for the data. This is why LSPS0 was designed the way it was: a JSON text inside a BOLT8 message, with all LSPS API calls sharing the same single BOLT8 message (keyed by a particular key in the JSON text). Regards, ZmnSCPxj _______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
