📅 Original date posted:2017-11-25
📝 Original message:
On Sat, Nov 25, 2017 at 11:13 AM Pedro Moreno Sanchez <pmorenos at purdue.edu>
wrote:
> When you say "we have mechanisms in place", you refer to the
> descriptions available in
> https://github.com/lightningnetwork/lightning-rfc?
>
I think he's referring to the ability to add "routing" hints to the BOLT 11
payment requests.
>
> > 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.
>
>
Not quite sure what y'all mean by this. If there doesn't exist a direct
path,
then how can one use onion routing to complete the transfer?
>
> 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.
>
>
At my talk at Scaling Bitcoin, I outlined two possible paths:
1. Assuming a schnorr-like signature protocol eventually gets into
Bitcoin, nodes would use a cooperative signature in lieu of
mulit-sig.
2. Or today, use a 2-party ECDSA protocol to generate a joint key, and
sign using that to update the channel.
-- Laolu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20171125/891c0bb9/attachment.html>;
Olaoluwa Osuntokun [ARCHIVE] /
npub19h…zkvn4
2023-06-09 12:47:50
in reply to nevent1q…ctxf
Author Public Key
npub19helcfnqgk2jrwzjex2aflq6jwfc8zd9uzzkwlgwhve7lykv23mq5zkvn4Published at
2023-06-09 12:47:50Event JSON
{
"id": "e38c678d8dd4b3f90506b7f572f7b82f2acf4432319f6966bef95364d026a7db",
"pubkey": "2df3fc2660459521b852c995d4fc1a93938389a5e085677d0ebb33ef92cc5476",
"created_at": 1686314870,
"kind": 1,
"tags": [
[
"e",
"1afe922a5f0d29bed0b74cfea6fe77562b605b3dfcb4a5279a568cb6c55b7eeb",
"",
"root"
],
[
"e",
"e8ab370ea1b9f64b0a9624c2932a7b5e851725b5532af7a4d8fc13d4095791e8",
"",
"reply"
],
[
"p",
"09a83e0f6f66d100ceebb189a58e2c614066ea251fcc549978ded78771b9c728"
]
],
"content": "📅 Original date posted:2017-11-25\n📝 Original message:\nOn Sat, Nov 25, 2017 at 11:13 AM Pedro Moreno Sanchez \u003cpmorenos at purdue.edu\u003e\nwrote:\n\n\u003e When you say \"we have mechanisms in place\", you refer to the\n\u003e descriptions available in\n\u003e https://github.com/lightningnetwork/lightning-rfc?\n\u003e\n\nI think he's referring to the ability to add \"routing\" hints to the BOLT 11\npayment requests.\n\n\u003e\n\u003e \u003e Personally I'd like to separate the base routing layer and the onion\n\u003e \u003e routing layer eventually. The base layer would provide end-to-end\n\u003e \u003e connectivity between any two nodes and the onion layer would then simply\n\u003e \u003e chose some random nodes in the network and not be bound to the networks\n\u003e \u003e topology. The same way IP and TOR are not mixed.\n\u003e\n\u003e Yes, I totally agree. I also think that this separation would help us to\n\u003e better understand what are the necessary and/or sufficient guarantees\n\u003e required in both layers for the LN to work.\n\u003e\n\u003e\nNot quite sure what y'all mean by this. If there doesn't exist a direct\npath,\nthen how can one use onion routing to complete the transfer?\n\n\n\u003e\n\u003e Could you please point me to where this mechanism is described? I have\n\u003e been thinking about this, but the solution is not completely clear in my\n\u003e mind yet.\n\u003e\n\u003e\nAt my talk at Scaling Bitcoin, I outlined two possible paths:\n\n 1. Assuming a schnorr-like signature protocol eventually gets into\n Bitcoin, nodes would use a cooperative signature in lieu of\nmulit-sig.\n 2. Or today, use a 2-party ECDSA protocol to generate a joint key, and\n sign using that to update the channel.\n\n-- Laolu\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20171125/891c0bb9/attachment.html\u003e",
"sig": "0927b46e17a16d74be5fdf0c94c8c0345046180a0bce7c8030fcf01f3cdbeb3e13c85744160885a58b9755fb12ddde43a8214bc4bc0ad7ac3bea8595b7829369"
}