📅 Original date posted:2015-07-01
📝 Original message:
Interesting. It sounds like Joseph may have a solution already, but as a
thought experiment I'm curious how directory nodes could work with the
lightening network. I guess you would have a set of such authorities that
open payment channels with all known lightening processors (how would they
be discovered?), and have a protocol for periodically moving money back and
forth to verify connectivity. One difference here between Tor and
Lightening is that "verifying connectivity" on the Lightening network is
not as simple as connecting to a Tor node. For example, in the ABCD
example, what if C decides to attack only payments that come from B? It
could be non-malicious if C just had a datacenter fire or something that
took out the keys and tx data associated with their channel with B.
Anyways, if the directory nodes didn't test every possible route through
the network (which has exponential complexity), then I don't think they
could reliably tell you if C is trustworthy or not.
On Wed, Jul 1, 2015 at 9:55 AM, Nick ODell <nickodell at gmail.com> wrote:
> >There is no such central processor though in this case to enforce the
> reputation of lightening nodes.
>
> There's no reason why there couldn't be.
>
> Tor, for example, has nine "directory authorities." They attempt to reach
> nodes in the Tor network, and record whether they're available. Then, they
> vote among themselves to produce a directory consensus, and they all sign
> it. Lightning could use a similar system. Unlike Tor, we don't need to
> require everyone to use the same directory authorities, either.
>
> On Wed, Jul 1, 2015 at 10:53 AM, Nick ODell <nickodell at gmail.com> wrote:
>
>> >There is no such central processor though in this case to enforce the
>> reputation of lightening nodes.
>>
>> There's no reason why there couldn't be.
>>
>> Tor, for example, has nine "directory authorities." They attempt to reach
>> nodes in the Tor network, and record whether they're available. Then, they
>> vote among themselves to produce a directory consensus, and they all sign
>> it. Lightning could use a similar system. Unlike Tor, we don't need to
>> require everyone to use the same directory authority, either.
>>
>> On Wed, Jul 1, 2015 at 10:31 AM, Kevin Greene <kgreenek at gmail.com> wrote:
>>
>>> Blargh. The dumb solution here is to just shrug and say that you have to
>>> trust these processors to be highly available, and never try to do
>>> re-routing. That's pretty much equivalent to what would happen if one of
>>> the banks in the visa network had networking issues for example.
>>>
>>> The big difference here though is that visa will kick you out of the
>>> network if you're a bank that's consistently not meeting their
>>> strict SLA's, and that keeps the network honest. There is no such central
>>> processor though in this case to enforce the reputation of lightening
>>> nodes.
>>>
>>>
>>>
>>> On Monday, June 29, 2015, Stephen Morse <stephencalebmorse at gmail.com>
>>> wrote:
>>>
>>>> Hi Rusty,
>>>>
>>>> On Sat, Jun 27, 2015 at 2:41 AM, Rusty Russell <rusty at rustcorp.com.au>
>>>> wrote:
>>>>
>>>>>
>>>>> Yes, C can just get the preimage from E and collude to steal the funds,
>>>>> which is a nasty failure mode.
>>>>>
>>>>>
>>>> This scenario may even happen non-maliciously, if C has an honest
>>>> outage and attempts to pick up where it left off on each of its channels.
>>>> To fix the non-malicious case, C could get a refund from E (a new signed
>>>> transaction with a lower lock time), if C knows he has been offline for
>>>> longer than B's willingness to wait before re-routing. But this isn't
>>>> perfect, or even good, because E cannot know that C isn't just trying to
>>>> get a refund even though they have taken the payment from B. In fact, C is
>>>> guaranteed the payment from B, since they have the pre-image.
>>>>
>>>>
>>>>> Delaying the entire payment is a poor option; can anyone see a better
>>>>> one?
>>>>>
>>>>
>>>> Like you say, delaying the payment seems like a bad way to go, as then
>>>> the payments wouldn't be quite "Lightning" fast anymore. 99% of the payment
>>>> could be re-routed though. Perhaps the 99% could be re-routed, while A
>>>> waits for C to rejoin. Or if multiple paths are being used to process the
>>>> payment, just redistribute the remaining payments allotted for the broken
>>>> path among the other functioning paths.
>>>>
>>>> The bigger problem here seems to be that the incentives are slightly
>>>> skewed in favor of dishonestly. One can minimize the impact of that
>>>> dishonesty by breaking the payment into smaller chunks and across diverse
>>>> paths, but this comes at the cost of bandwidth and speed. Some sort of a
>>>> rating system could come into play possibly, if nothing can be
>>>> cryptographically worked out.
>>>>
>>>> Best,
>>>> Stephen
>>>>
>>>
>>> _______________________________________________
>>> Lightning-dev mailing list
>>> Lightning-dev at lists.linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20150701/33ad4caa/attachment-0001.html>;
Kevin Greene [ARCHIVE] /
npub1l3…hwq5p
2023-06-09 12:43:30
in reply to nevent1q…lglw
Author Public Key
npub1l3sj8amnurgf3cu3p2hhcaham90khafc4vgsmymqdnn0k3kanulsghwq5pPublished at
2023-06-09 12:43:30Event JSON
{
"id": "7d097193887d08ebb149ff530665f5a6e903788af8b7cc5c6a6eebdaac58ac70",
"pubkey": "fc6123f773e0d098e3910aaf7c76fdd95f6bf538ab110d93606ce6fb46dd9f3f",
"created_at": 1686314610,
"kind": 1,
"tags": [
[
"e",
"196e6f16c10286053bb98332e16b93c95556ba52d6b40e0d8239621281383083",
"",
"root"
],
[
"e",
"45490811d39db5a49359f2950c667b17c0353345e53581195aa5b6b4ff9148e6",
"",
"reply"
],
[
"p",
"2a9b7d3423041901b738be6b1d40a6e4dd3f9041e7a5fa4a2d3c662d296814c7"
]
],
"content": "📅 Original date posted:2015-07-01\n📝 Original message:\nInteresting. It sounds like Joseph may have a solution already, but as a\nthought experiment I'm curious how directory nodes could work with the\nlightening network. I guess you would have a set of such authorities that\nopen payment channels with all known lightening processors (how would they\nbe discovered?), and have a protocol for periodically moving money back and\nforth to verify connectivity. One difference here between Tor and\nLightening is that \"verifying connectivity\" on the Lightening network is\nnot as simple as connecting to a Tor node. For example, in the ABCD\nexample, what if C decides to attack only payments that come from B? It\ncould be non-malicious if C just had a datacenter fire or something that\ntook out the keys and tx data associated with their channel with B.\nAnyways, if the directory nodes didn't test every possible route through\nthe network (which has exponential complexity), then I don't think they\ncould reliably tell you if C is trustworthy or not.\n\nOn Wed, Jul 1, 2015 at 9:55 AM, Nick ODell \u003cnickodell at gmail.com\u003e wrote:\n\n\u003e \u003eThere is no such central processor though in this case to enforce the\n\u003e reputation of lightening nodes.\n\u003e\n\u003e There's no reason why there couldn't be.\n\u003e\n\u003e Tor, for example, has nine \"directory authorities.\" They attempt to reach\n\u003e nodes in the Tor network, and record whether they're available. Then, they\n\u003e vote among themselves to produce a directory consensus, and they all sign\n\u003e it. Lightning could use a similar system. Unlike Tor, we don't need to\n\u003e require everyone to use the same directory authorities, either.\n\u003e\n\u003e On Wed, Jul 1, 2015 at 10:53 AM, Nick ODell \u003cnickodell at gmail.com\u003e wrote:\n\u003e\n\u003e\u003e \u003eThere is no such central processor though in this case to enforce the\n\u003e\u003e reputation of lightening nodes.\n\u003e\u003e\n\u003e\u003e There's no reason why there couldn't be.\n\u003e\u003e\n\u003e\u003e Tor, for example, has nine \"directory authorities.\" They attempt to reach\n\u003e\u003e nodes in the Tor network, and record whether they're available. Then, they\n\u003e\u003e vote among themselves to produce a directory consensus, and they all sign\n\u003e\u003e it. Lightning could use a similar system. Unlike Tor, we don't need to\n\u003e\u003e require everyone to use the same directory authority, either.\n\u003e\u003e\n\u003e\u003e On Wed, Jul 1, 2015 at 10:31 AM, Kevin Greene \u003ckgreenek at gmail.com\u003e wrote:\n\u003e\u003e\n\u003e\u003e\u003e Blargh. The dumb solution here is to just shrug and say that you have to\n\u003e\u003e\u003e trust these processors to be highly available, and never try to do\n\u003e\u003e\u003e re-routing. That's pretty much equivalent to what would happen if one of\n\u003e\u003e\u003e the banks in the visa network had networking issues for example.\n\u003e\u003e\u003e\n\u003e\u003e\u003e The big difference here though is that visa will kick you out of the\n\u003e\u003e\u003e network if you're a bank that's consistently not meeting their\n\u003e\u003e\u003e strict SLA's, and that keeps the network honest. There is no such central\n\u003e\u003e\u003e processor though in this case to enforce the reputation of lightening\n\u003e\u003e\u003e nodes.\n\u003e\u003e\u003e\n\u003e\u003e\u003e\n\u003e\u003e\u003e\n\u003e\u003e\u003e On Monday, June 29, 2015, Stephen Morse \u003cstephencalebmorse at gmail.com\u003e\n\u003e\u003e\u003e wrote:\n\u003e\u003e\u003e\n\u003e\u003e\u003e\u003e Hi Rusty,\n\u003e\u003e\u003e\u003e\n\u003e\u003e\u003e\u003e On Sat, Jun 27, 2015 at 2:41 AM, Rusty Russell \u003crusty at rustcorp.com.au\u003e\n\u003e\u003e\u003e\u003e wrote:\n\u003e\u003e\u003e\u003e\n\u003e\u003e\u003e\u003e\u003e\n\u003e\u003e\u003e\u003e\u003e Yes, C can just get the preimage from E and collude to steal the funds,\n\u003e\u003e\u003e\u003e\u003e which is a nasty failure mode.\n\u003e\u003e\u003e\u003e\u003e\n\u003e\u003e\u003e\u003e\u003e\n\u003e\u003e\u003e\u003e This scenario may even happen non-maliciously, if C has an honest\n\u003e\u003e\u003e\u003e outage and attempts to pick up where it left off on each of its channels.\n\u003e\u003e\u003e\u003e To fix the non-malicious case, C could get a refund from E (a new signed\n\u003e\u003e\u003e\u003e transaction with a lower lock time), if C knows he has been offline for\n\u003e\u003e\u003e\u003e longer than B's willingness to wait before re-routing. But this isn't\n\u003e\u003e\u003e\u003e perfect, or even good, because E cannot know that C isn't just trying to\n\u003e\u003e\u003e\u003e get a refund even though they have taken the payment from B. In fact, C is\n\u003e\u003e\u003e\u003e guaranteed the payment from B, since they have the pre-image.\n\u003e\u003e\u003e\u003e\n\u003e\u003e\u003e\u003e\n\u003e\u003e\u003e\u003e\u003e Delaying the entire payment is a poor option; can anyone see a better\n\u003e\u003e\u003e\u003e\u003e one?\n\u003e\u003e\u003e\u003e\u003e\n\u003e\u003e\u003e\u003e\n\u003e\u003e\u003e\u003e Like you say, delaying the payment seems like a bad way to go, as then\n\u003e\u003e\u003e\u003e the payments wouldn't be quite \"Lightning\" fast anymore. 99% of the payment\n\u003e\u003e\u003e\u003e could be re-routed though. Perhaps the 99% could be re-routed, while A\n\u003e\u003e\u003e\u003e waits for C to rejoin. Or if multiple paths are being used to process the\n\u003e\u003e\u003e\u003e payment, just redistribute the remaining payments allotted for the broken\n\u003e\u003e\u003e\u003e path among the other functioning paths.\n\u003e\u003e\u003e\u003e\n\u003e\u003e\u003e\u003e The bigger problem here seems to be that the incentives are slightly\n\u003e\u003e\u003e\u003e skewed in favor of dishonestly. One can minimize the impact of that\n\u003e\u003e\u003e\u003e dishonesty by breaking the payment into smaller chunks and across diverse\n\u003e\u003e\u003e\u003e paths, but this comes at the cost of bandwidth and speed. Some sort of a\n\u003e\u003e\u003e\u003e rating system could come into play possibly, if nothing can be\n\u003e\u003e\u003e\u003e cryptographically worked out.\n\u003e\u003e\u003e\u003e\n\u003e\u003e\u003e\u003e Best,\n\u003e\u003e\u003e\u003e Stephen\n\u003e\u003e\u003e\u003e\n\u003e\u003e\u003e\n\u003e\u003e\u003e _______________________________________________\n\u003e\u003e\u003e Lightning-dev mailing list\n\u003e\u003e\u003e Lightning-dev at lists.linuxfoundation.org\n\u003e\u003e\u003e https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev\n\u003e\u003e\u003e\n\u003e\u003e\u003e\n\u003e\u003e\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20150701/33ad4caa/attachment-0001.html\u003e",
"sig": "097a735939e18f1d75775339ce2945af862e41296661bd454bbefb7eb59fa829c4349bdc5de44ca0a808e7b038ded05a499b08150d731b7b0ef8a7325bbcaac8"
}