Christian Decker [ARCHIVE] on Nostr: 📅 Original date posted:2017-11-23 📝 Original message: Thanks Pedro for the ...
📅 Original date posted:2017-11-23
📝 Original message:
Thanks Pedro for the paper, I'll read through it as soon as possible and
add more feedback :-) I just have some minor points to add regarding
your last mail.
> The onion-like packets used for *payments* in the current LN
> implementations inevitably assume that the sender knows the complete
> path from the sender to the intended receiver. The question/challenge
> that we are solving in this work is: how does the sender gets to know
> such path in the first place?
The current implementation requires the node to compute the entire
route, yes. However we have mechanisms in place for the two endpoints of a
route to collaboratively find such a route. This includes telling the
recipient ginving the sender hints as how best to reach the recipient,
e.g., adding channel information in the invoice. In the long-term we
also plan to add landmarks.
Personally I'd like to separate the base routing layer and the onion
routing layer eventually. The base layer would provide end-to-end
connectivity between any two nodes and the onion layer would then simply
chose some random nodes in the network and not be bound to the networks
topology. The same way IP and TOR are not mixed.
> One approach is that each user in the LN locally stores the complete set
> of opened channels either by looking at open channel transactions in the
> blockchain or by a gossip protocol. However, this approach has trivial
> privacy issues and it is not scalable for a growing number of users and
> channels between them. Moreover, this approach is no longer possible if
> open channel transactions can be modified such that they are
> indistinguishable from other Bitcoin transactions.
The funding transactions are currently indistinguishable from any other
P2SH transaction. We currently only rely on being able to reveal the
script behind the P2SH hash in order to prove that indeed the two
endpoints have setup a channel. The gossip protocol does not require the
information to be identifiable on-chain, only that we can verify some
commitment to what we are claiming.
Cheers,
Christian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20171123/d163a160/attachment.html>;
📝 Original message:
Thanks Pedro for the paper, I'll read through it as soon as possible and
add more feedback :-) I just have some minor points to add regarding
your last mail.
> The onion-like packets used for *payments* in the current LN
> implementations inevitably assume that the sender knows the complete
> path from the sender to the intended receiver. The question/challenge
> that we are solving in this work is: how does the sender gets to know
> such path in the first place?
The current implementation requires the node to compute the entire
route, yes. However we have mechanisms in place for the two endpoints of a
route to collaboratively find such a route. This includes telling the
recipient ginving the sender hints as how best to reach the recipient,
e.g., adding channel information in the invoice. In the long-term we
also plan to add landmarks.
Personally I'd like to separate the base routing layer and the onion
routing layer eventually. The base layer would provide end-to-end
connectivity between any two nodes and the onion layer would then simply
chose some random nodes in the network and not be bound to the networks
topology. The same way IP and TOR are not mixed.
> One approach is that each user in the LN locally stores the complete set
> of opened channels either by looking at open channel transactions in the
> blockchain or by a gossip protocol. However, this approach has trivial
> privacy issues and it is not scalable for a growing number of users and
> channels between them. Moreover, this approach is no longer possible if
> open channel transactions can be modified such that they are
> indistinguishable from other Bitcoin transactions.
The funding transactions are currently indistinguishable from any other
P2SH transaction. We currently only rely on being able to reveal the
script behind the P2SH hash in order to prove that indeed the two
endpoints have setup a channel. The gossip protocol does not require the
information to be identifiable on-chain, only that we can verify some
commitment to what we are claiming.
Cheers,
Christian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20171123/d163a160/attachment.html>;