From kgreenek at gmail.com Wed Jul 1 23:01:31 2015 From: kgreenek at gmail.com (Kevin Greene) Date: Wed, 1 Jul 2015 16:01:31 -0700 Subject: [Lightning-dev] Payment Re-routing In-Reply-To: References: <27F66CF8-85C5-409A-AC15-677C1898A31A@gmail.com> <877fqpvhte.fsf@rustcorp.com.au> <87381dvekf.fsf@rustcorp.com.au> Message-ID: On Wed, Jul 1, 2015 at 3:35 PM, Nick ODell 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 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 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 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 >>>> 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 >>>>> wrote: >>>>> >>>>>> Hi Rusty, >>>>>> >>>>>> On Sat, Jun 27, 2015 at 2:41 AM, Rusty Russell >>>>> > 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: