Reimagining Onion Messages as an Overlay Layer

Protocol Design
8

So what you’re saying is that in practice your proposal wouldn’t change the network topology at all? What’s the point, then?

The fact that you arrived at the conclusion after reading my last post shows an impressive ability to make logical leaps. If one carefully reads the OP and my initial reply, they’d arrive at the conclusion that: the onion overlay doesn’t necessarily mirror the topology of the existing channel graph. This is due to the fact that: nodes that don’t have direct channels with each other can create+advertise an onion link.

The spec doesn’t say that it has to be on the same connection, which implies that nodes are free to do whatever they want. Also, there’s no need for a separate port for this? You can just open a second connection on the same port.

The very first BOLT is pretty clear on this point:

Implementations MUST use a single connection per peer; channel messages (which include a channel ID) are multiplexed over this single connection.

Again, can you point me to the where in the spec literally any of what you’re describing is outlined?

which implies that nodes are free to do whatever they want

Sure, nodes implementation can implement pretty much anything they want to. However, interoperability requires that the behavior be specified so all implementations are on the same page. This is why we write explicit specs.

Yes, TCP is all about applying backpressure from an application through to the sender to ensure the sender can do these things without making the recipient unable to respond

You seem to have repeatedly missed the nuance in this example. So here’s a simplified scenario that you should be able to understand:

  • Alice has an FIFO internal queue that contains 5 messages: 3x channel_update, 1x commit_sig, and 1x onion_message.
  • Bob only processes a single message a time, he’s entirely single threaded. He’s slow, and a single channel_update can take him 5 seconds to process. Bob never drops incoming messages, they’re processed in order.
  • Alice sends her first channel update, to Bob, the TCP parameters have been arbitrary restricted s.t only a single message can be outstanding at a time.
  • In this scenario, only 15+ seconds after the first channel_update is sent can Alice send the onion_message.

Can you see how using a distinct TCP (or even a single QUIC connection!) connection would allow Alice to send/propagate her onion_message more expediently? If not, then I’m not sure we can continue to have a productive conversation on this matter.

Head-of-line blocking isn’t some death curse

I’m not presenting it as such, that’s just a strawman you seem to enjoy wrangling with. My statement is pretty simple: onion messaging over a distinct TCP eliminates unnecessary blocking, and sidesteps networking+processing contention w/ other node functionality.