Pedro Moreno Sanchez [ARCHIVE] on Nostr: 📅 Original date posted:2017-11-25 📝 Original message: Hello Christian, Thanks ...
📅 Original date posted:2017-11-25
📝 Original message:
Hello Christian,
Thanks for your prompt reply. Please, see my minor comments and
questions below.
On 11/23/17 7:50 AM, Christian Decker wrote:
> 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.
When you say "we have mechanisms in place", you refer to the
descriptions available in
https://github.com/lightningnetwork/lightning-rfc?
Interesting to know that you have landmark-based routing in your plans.
Given the time, I would be obviously interested to talk to you more
about it and possibly collaborate on that if you find it suitable.
>
> 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.
Yes, I totally agree. I also think that this separation would help us to
better understand what are the necessary and/or sufficient guarantees
required in both layers for the LN to work.
>
>> 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.
Could you please point me to where this mechanism is described? I have
been thinking about this, but the solution is not completely clear in my
mind yet.
>
> Cheers,
> Christian
Thanks again,
Pedro.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20171125/578defda/attachment.sig>;
📝 Original message:
Hello Christian,
Thanks for your prompt reply. Please, see my minor comments and
questions below.
On 11/23/17 7:50 AM, Christian Decker wrote:
> 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.
When you say "we have mechanisms in place", you refer to the
descriptions available in
https://github.com/lightningnetwork/lightning-rfc?
Interesting to know that you have landmark-based routing in your plans.
Given the time, I would be obviously interested to talk to you more
about it and possibly collaborate on that if you find it suitable.
>
> 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.
Yes, I totally agree. I also think that this separation would help us to
better understand what are the necessary and/or sufficient guarantees
required in both layers for the LN to work.
>
>> 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.
Could you please point me to where this mechanism is described? I have
been thinking about this, but the solution is not completely clear in my
mind yet.
>
> Cheers,
> Christian
Thanks again,
Pedro.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20171125/578defda/attachment.sig>;