Nick ODell [ARCHIVE] on Nostr: 📅 Original date posted:2015-07-01 📝 Original message: >There is no such central ...
📅 Original date posted:2015-07-01
📝 Original message:
>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/83839504/attachment.html>;
📝 Original message:
>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/83839504/attachment.html>;