Hi Laolu, Thanks a lot for bringing this topic to the list as well as your comments and pointers to your code. I'll just share what I wrote in the PR below.
One of the motivations I had for having the segment explicit was to be able to handle disconnects/reconnects without requiring access to the low level network layer. Granted it might not be the best reason, but another reason I can think of was mentioned by Christian Decker [1], the ability to send an urgent message in the middle of sending a large one (I cannot think how this could be achieved without headers, but I might just lack imagination). That being said, I don't have a strong opinion on what is the best, and if there is a need for something similar in LN it'd be really nice that we use the same thing (less thing for our small community to maintain, and we already rely on quite some of the LN messages anyway so I think it'd make sense). Also thanks to all the other developers who provided comments/feedback (and to Chris for asking them), I really appreciate it. Cheers, Thibaut [1]: https://github.com/discreetlogcontracts/dlcspecs/pull/192#discussion_r894383344 On Sat, Jul 2, 2022 at 9:16 AM Olaoluwa Osuntokun <laol...@gmail.com> wrote: > Hi y'all, > > Quick post... > > A few weeks ago, some of the dlcspecs developers reached out to ask for > feedback on this PR [1] that attempts to specify a way to send messages > larger > than 65 KB using BOLT 8 (Noise based encrypted transport). After taking a > glance at the PR, I realized that it isn't totally obvious from reading > BOLT > 8 that it's actually possible to do this w/o adding any new application > layer messages (as the PR proposes). > > As I explained in my comment [2], all the sender needs to do is chunk their > messages, and the receiver reads out messages into a read buffer exposed > over > a stream-like interface. This is no different than using TCP/IP to send a > 65 > KB message over the wire: a series of messages below the Maximum > Transmission Unit at each hop are sent, w/ the receiver > collecting/re-ordering them all before delivering up the API stack. > > This was actually in the OG spec, but then was removed to make things a bit > simpler. Here's my commit from way back when implementing this behavior > [3]. > If we wanted to re-introduce this behavior (so we can do things like > increase the max HTLC limit w/o having to worry about messages being to > large due to all the extra sigs), afaict, we could just add a new wumbo > message feature bit. This bit indicates that a peer knows how to properly > chunk and aggregate larger messages. > > > [1]: https://github.com/discreetlogcontracts/dlcspecs/pull/192 > [2]: > https://github.com/discreetlogcontracts/dlcspecs/pull/192#issuecomment-1171569378 > [3]: > https://github.com/lightningnetwork/lnd/commit/767c550d65ef97a765eabe09c97941d91e05f054 > > -- Laolu > _______________________________________________ > Lightning-dev mailing list > Lightning-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev >
_______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
