[Lightning-dev] Payment Re-routing

Kevin Greene kgreenek at gmail.com
Wed Jul 1 23:01:31 UTC 2015


On Wed, Jul 1, 2015 at 3:35 PM, Nick ODell <nickodell at gmail.com> wrote:

> >(how would they be discovered?)
> Two major ways I can see:
>  * Each Lightning node keeps track of peers it has seen, and provides part
> of this list to anyone who asks. Directory authorities run spiders, like
> the one at getaddr.bitnodes.io. This could be overlaid onto the Bitcoin
> protocol by setting one of the service bits when the node is an active
> lightning processor.  (getaddr approach)
>  * Your node tells all of the directory authorities it knows about itself.
> (Tor approach)
>
>
> >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.
> I think the two of those are similar. Tor can detect various sorts of
> accidental connectivity issues. For example, if you tell Tor in its config
> file that it has a gigabit connection, and it doesn't, it will figure that
> out by itself. However, the most important kind of intentional misbehavior,
> logging connections, cannot be detected remotely.
>
> Lightning is similar. We can detect when someone's internet connection
> goes down. We can detect (with some plumbing) when their Bitcoin node is
> not synchronized yet. But we can't detect the most important kind of
> intentional misbehavior, stealing money, without actually sending money
> through the network.
>
> (Or someone else trying to send money, and complaining when it doesn't go
> through. That would work better if the sender of the payment had some kind
> of log of signed statements made by the nodes involved, though.)
>
> From a privacy perspective, active scanning (sending money through the
> network yourself) is much easier to secure than passive scanning (acting on
> an audit log of someone whose payments got stolen.)
>
> >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.
> It doesn't seem like you can catch everybody who's selectively scamming
> through active scanning. For example, if someone stole one out of every
> million payments, the directories would never notice. Personally, I'd more
> worried about someone trying to defeat active scanning by fingerprinting
> wallet software. (e.g. this wallet software always puts zero in this field,
> or this directory authority always connects from Tor addresses.)
>
> WRT the non-malicious example: It seems like a non-malicious node would
> ask for the channel to be closed ASAP, if it no longer remembered the data
> that would show who owned what. This would still leave the payments that it
> was processing just before the data loss in limbo, though, so that's not a
> cure-all.
>
> >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.
> I don't think they need to test every route. In the ABCD example, the only
> nodes that C should know about are B and D. Therefore, the routes EBCD and
> ABCD are equivalent from C's point of view.
>
> That's still superlinear, though.
>

​Yeah. Also, how will A know what nodes B​ is connected to? B could
advertise its connected peers ala BGP AS-Paths.

Speaking of which, how does routing work in the lightening network? Forgive
me if that's already documented somewhere. Is that designed already?


>
> On Wed, Jul 1, 2015 at 12:19 PM, Kevin Greene <kgreenek at gmail.com> wrote:
>
>> 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/e7a8f1ab/attachment-0001.html>


More information about the Lightning-dev mailing list