Nick ODell [ARCHIVE] on Nostr: 📅 Original date posted:2015-07-01 📝 Original message: >(how would they be ...
📅 Original date posted:2015-07-01
📝 Original message:
>(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.
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/04e5f863/attachment.html>;
📝 Original message:
>(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.
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/04e5f863/attachment.html>;