Bastien TEINTURIER [ARCHIVE] on Nostr: 📅 Original date posted:2020-10-12 📝 Original message: Good morning, For ...
📅 Original date posted:2020-10-12
📝 Original message:
Good morning,
For instance, Tor is basically two-layer: there is a lower-level TCP/IP
> layer where packets are sent out to specific nodes on the network and this
> layer is completely open about where the packet should go, but there is a
> higher layer where onion routing between nodes is used.
> We could imitate this, with HTLC packets that openly show the next
> destination node, but once all parts reach the destination node, it decodes
> and turns out to be an onion to be sent to the next destination node, and
> the current destination node is just another forwarder.
That's an interesting comment, it may be worth exploring.
IIUC you're suggesting that payments may look like this:
* Alice wants to reach Dave by going through Bob and Carol
* An onion encodes the route Alice -> Bob -> Carol -> Dave
* When Bob receives that onion and discovers that Carol is the next node,
he finds a route to Carol
and sends it along that route, but it's not an onion, it's "clear-text"
routing
* When Carol receives that message, she unwraps the Alice -> Bob -> Carol
-> Dave onion to discover
that Dave is the next hop and applies the same steps as Bob
It looks a lot like Trampoline, but Trampoline does onion routing between
intermediate nodes.
Your proposal would replace that with a potentially more efficient but less
private routing scheme.
As long as the Trampoline route does use onion routing, it could make
sense...
For your proposal, how sure is the receiver that the input end of the
> trampoline node is "nearer" to the payer than itself?
Invoices to the rescue!
Since lightning payments are invoice-based, recipients would add to the
invoice a few nodes that
are close to them (or a partial route, which would probably be better for
privacy).
Thanks,
Bastien
Le dim. 11 oct. 2020 à 10:50, ZmnSCPxj <ZmnSCPxj at protonmail.com> a écrit :
> Good morning t-bast,
>
> > Hey Zman,
> >
> > > raising the minimum payment size is another headache
> >
> > It's true that it may (depending on the algorithm) lower the success
> rate of MPP-split.
> > But it's already a parameter that node operators can configure at will
> (at channel creation time),
> > so IMO it's a complexity we have to deal with anyway. Making it dynamic
> shouldn't have a high
> > impact on MPP algorithms (apart from failures while `channel_update`s
> are propagating).
>
> Right, it should not have much impact.
>
> For the most part, when considering the possibility of splicing in the
> future, we should consider that such parameters must be made changeable
> largely.
>
>
> >
> > To be fully honest, my (maybe unpopular) opinion about MPP is that it's
> not necessary on the
> > network's backbone, only at its edges. Once the network matures, I
> expect channels between
> > "serious" routing nodes to be way bigger than the size of individual
> payments. The only places
> > where there may be small or almost-empty channels are between end-users
> (wallets) and
> > routing nodes.
> > If something like Trampoline were to be implemented, MPP would only be
> needed to reach a
> > first routing node (short route), that routing node would aggregate the
> parts and forward as a
> > single HTLC to the next routing node. It would be split again once it
> reaches the other edge
> > of the network (for a short route as well). In a network like this, the
> MPP routes would only have
> > to be computed on a small subset of the network, which makes brute-force
> algorithms completely
> > reasonable and the success rate higher.
>
> This makes me wonder if we really need the onions-per-channel model we
> currently use.
>
> For instance, Tor is basically two-layer: there is a lower-level TCP/IP
> layer where packets are sent out to specific nodes on the network and this
> layer is completely open about where the packet should go, but there is a
> higher layer where onion routing between nodes is used.
>
> We could imitate this, with HTLC packets that openly show the next
> destination node, but once all parts reach the destination node, it decodes
> and turns out to be an onion to be sent to the next destination node, and
> the current destination node is just another forwarder.
>
> HTLC packets could be split arbitrarily, and later nodes could potentially
> merge with the lower CLTV used in subsequent hops.
>
> Or not, *shrug*.
> It has the bad problem of being more expensive on average than purely
> source-based routing, and probably having worse payment latency.
>
>
> For your proposal, how sure is the receiver that the input end of the
> trampoline node is "nearer" to the payer than itself?
>
> Regards,
> ZmnSCPxj
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20201012/8dcb280a/attachment.html>;
📝 Original message:
Good morning,
For instance, Tor is basically two-layer: there is a lower-level TCP/IP
> layer where packets are sent out to specific nodes on the network and this
> layer is completely open about where the packet should go, but there is a
> higher layer where onion routing between nodes is used.
> We could imitate this, with HTLC packets that openly show the next
> destination node, but once all parts reach the destination node, it decodes
> and turns out to be an onion to be sent to the next destination node, and
> the current destination node is just another forwarder.
That's an interesting comment, it may be worth exploring.
IIUC you're suggesting that payments may look like this:
* Alice wants to reach Dave by going through Bob and Carol
* An onion encodes the route Alice -> Bob -> Carol -> Dave
* When Bob receives that onion and discovers that Carol is the next node,
he finds a route to Carol
and sends it along that route, but it's not an onion, it's "clear-text"
routing
* When Carol receives that message, she unwraps the Alice -> Bob -> Carol
-> Dave onion to discover
that Dave is the next hop and applies the same steps as Bob
It looks a lot like Trampoline, but Trampoline does onion routing between
intermediate nodes.
Your proposal would replace that with a potentially more efficient but less
private routing scheme.
As long as the Trampoline route does use onion routing, it could make
sense...
For your proposal, how sure is the receiver that the input end of the
> trampoline node is "nearer" to the payer than itself?
Invoices to the rescue!
Since lightning payments are invoice-based, recipients would add to the
invoice a few nodes that
are close to them (or a partial route, which would probably be better for
privacy).
Thanks,
Bastien
Le dim. 11 oct. 2020 à 10:50, ZmnSCPxj <ZmnSCPxj at protonmail.com> a écrit :
> Good morning t-bast,
>
> > Hey Zman,
> >
> > > raising the minimum payment size is another headache
> >
> > It's true that it may (depending on the algorithm) lower the success
> rate of MPP-split.
> > But it's already a parameter that node operators can configure at will
> (at channel creation time),
> > so IMO it's a complexity we have to deal with anyway. Making it dynamic
> shouldn't have a high
> > impact on MPP algorithms (apart from failures while `channel_update`s
> are propagating).
>
> Right, it should not have much impact.
>
> For the most part, when considering the possibility of splicing in the
> future, we should consider that such parameters must be made changeable
> largely.
>
>
> >
> > To be fully honest, my (maybe unpopular) opinion about MPP is that it's
> not necessary on the
> > network's backbone, only at its edges. Once the network matures, I
> expect channels between
> > "serious" routing nodes to be way bigger than the size of individual
> payments. The only places
> > where there may be small or almost-empty channels are between end-users
> (wallets) and
> > routing nodes.
> > If something like Trampoline were to be implemented, MPP would only be
> needed to reach a
> > first routing node (short route), that routing node would aggregate the
> parts and forward as a
> > single HTLC to the next routing node. It would be split again once it
> reaches the other edge
> > of the network (for a short route as well). In a network like this, the
> MPP routes would only have
> > to be computed on a small subset of the network, which makes brute-force
> algorithms completely
> > reasonable and the success rate higher.
>
> This makes me wonder if we really need the onions-per-channel model we
> currently use.
>
> For instance, Tor is basically two-layer: there is a lower-level TCP/IP
> layer where packets are sent out to specific nodes on the network and this
> layer is completely open about where the packet should go, but there is a
> higher layer where onion routing between nodes is used.
>
> We could imitate this, with HTLC packets that openly show the next
> destination node, but once all parts reach the destination node, it decodes
> and turns out to be an onion to be sent to the next destination node, and
> the current destination node is just another forwarder.
>
> HTLC packets could be split arbitrarily, and later nodes could potentially
> merge with the lower CLTV used in subsequent hops.
>
> Or not, *shrug*.
> It has the bad problem of being more expensive on average than purely
> source-based routing, and probably having worse payment latency.
>
>
> For your proposal, how sure is the receiver that the input end of the
> trampoline node is "nearer" to the payer than itself?
>
> Regards,
> ZmnSCPxj
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20201012/8dcb280a/attachment.html>;