📅 Original date posted:2015-07-01
📝 Original message:
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>;
Kevin Greene [ARCHIVE] /
npub1l3…hwq5p
2023-06-09 12:43:30
in reply to nevent1q…qeag
Author Public Key
npub1l3sj8amnurgf3cu3p2hhcaham90khafc4vgsmymqdnn0k3kanulsghwq5pPublished at
2023-06-09 12:43:30Event JSON
{
"id": "54048ab1ec142c425fd2a53c16372ed8aaf0a040b71dff342c7dc4bb1fe6118a",
"pubkey": "fc6123f773e0d098e3910aaf7c76fdd95f6bf538ab110d93606ce6fb46dd9f3f",
"created_at": 1686314610,
"kind": 1,
"tags": [
[
"e",
"196e6f16c10286053bb98332e16b93c95556ba52d6b40e0d8239621281383083",
"",
"root"
],
[
"e",
"862c1568cfd52244789ee225d47a09f14819aae7b4312870bc769c9b81f90765",
"",
"reply"
],
[
"p",
"2a9b7d3423041901b738be6b1d40a6e4dd3f9041e7a5fa4a2d3c662d296814c7"
]
],
"content": "📅 Original date posted:2015-07-01\n📝 Original message:\nOn Wed, Jul 1, 2015 at 3:35 PM, Nick ODell \u003cnickodell at gmail.com\u003e wrote:\n\n\u003e \u003e(how would they be discovered?)\n\u003e Two major ways I can see:\n\u003e * Each Lightning node keeps track of peers it has seen, and provides part\n\u003e of this list to anyone who asks. Directory authorities run spiders, like\n\u003e the one at getaddr.bitnodes.io. This could be overlaid onto the Bitcoin\n\u003e protocol by setting one of the service bits when the node is an active\n\u003e lightning processor. (getaddr approach)\n\u003e * Your node tells all of the directory authorities it knows about itself.\n\u003e (Tor approach)\n\u003e\n\u003e\n\u003e \u003eOne difference here between Tor and Lightening is that \"verifying\n\u003e connectivity\" on the Lightening network is not as simple as connecting to a\n\u003e Tor node.\n\u003e I think the two of those are similar. Tor can detect various sorts of\n\u003e accidental connectivity issues. For example, if you tell Tor in its config\n\u003e file that it has a gigabit connection, and it doesn't, it will figure that\n\u003e out by itself. However, the most important kind of intentional misbehavior,\n\u003e logging connections, cannot be detected remotely.\n\u003e\n\u003e Lightning is similar. We can detect when someone's internet connection\n\u003e goes down. We can detect (with some plumbing) when their Bitcoin node is\n\u003e not synchronized yet. But we can't detect the most important kind of\n\u003e intentional misbehavior, stealing money, without actually sending money\n\u003e through the network.\n\u003e\n\u003e (Or someone else trying to send money, and complaining when it doesn't go\n\u003e through. That would work better if the sender of the payment had some kind\n\u003e of log of signed statements made by the nodes involved, though.)\n\u003e\n\u003e From a privacy perspective, active scanning (sending money through the\n\u003e network yourself) is much easier to secure than passive scanning (acting on\n\u003e an audit log of someone whose payments got stolen.)\n\u003e\n\u003e \u003eFor example, in the ABCD example, what if C decides to attack only\n\u003e payments that come from B? It could be non-malicious if C just had a\n\u003e datacenter fire or something that took out the keys and tx data associated\n\u003e with their channel with B.\n\u003e It doesn't seem like you can catch everybody who's selectively scamming\n\u003e through active scanning. For example, if someone stole one out of every\n\u003e million payments, the directories would never notice. Personally, I'd more\n\u003e worried about someone trying to defeat active scanning by fingerprinting\n\u003e wallet software. (e.g. this wallet software always puts zero in this field,\n\u003e or this directory authority always connects from Tor addresses.)\n\u003e\n\u003e WRT the non-malicious example: It seems like a non-malicious node would\n\u003e ask for the channel to be closed ASAP, if it no longer remembered the data\n\u003e that would show who owned what. This would still leave the payments that it\n\u003e was processing just before the data loss in limbo, though, so that's not a\n\u003e cure-all.\n\u003e\n\u003e \u003eAnyways, if the directory nodes didn't test every possible route through\n\u003e the network (which has exponential complexity), then I don't think they\n\u003e could reliably tell you if C is trustworthy or not.\n\u003e I don't think they need to test every route. In the ABCD example, the only\n\u003e nodes that C should know about are B and D. Therefore, the routes EBCD and\n\u003e ABCD are equivalent from C's point of view.\n\u003e\n\u003e That's still superlinear, though.\n\u003e\n\nYeah. Also, how will A know what nodes B is connected to? B could\nadvertise its connected peers ala BGP AS-Paths.\n\nSpeaking of which, how does routing work in the lightening network? Forgive\nme if that's already documented somewhere. Is that designed already?\n\n\n\u003e\n\u003e On Wed, Jul 1, 2015 at 12:19 PM, Kevin Greene \u003ckgreenek at gmail.com\u003e wrote:\n\u003e\n\u003e\u003e Interesting. It sounds like Joseph may have a solution already, but as a\n\u003e\u003e thought experiment I'm curious how directory nodes could work with the\n\u003e\u003e lightening network. I guess you would have a set of such authorities that\n\u003e\u003e open payment channels with all known lightening processors (how would they\n\u003e\u003e be discovered?), and have a protocol for periodically moving money back and\n\u003e\u003e forth to verify connectivity. One difference here between Tor and\n\u003e\u003e Lightening is that \"verifying connectivity\" on the Lightening network is\n\u003e\u003e not as simple as connecting to a Tor node. For example, in the ABCD\n\u003e\u003e example, what if C decides to attack only payments that come from B? It\n\u003e\u003e could be non-malicious if C just had a datacenter fire or something that\n\u003e\u003e took out the keys and tx data associated with their channel with B.\n\u003e\u003e Anyways, if the directory nodes didn't test every possible route through\n\u003e\u003e the network (which has exponential complexity), then I don't think they\n\u003e\u003e could reliably tell you if C is trustworthy or not.\n\u003e\u003e\n\u003e\u003e On Wed, Jul 1, 2015 at 9:55 AM, Nick ODell \u003cnickodell at gmail.com\u003e wrote:\n\u003e\u003e\n\u003e\u003e\u003e \u003eThere is no such central processor though in this case to enforce the\n\u003e\u003e\u003e reputation of lightening nodes.\n\u003e\u003e\u003e\n\u003e\u003e\u003e There's no reason why there couldn't be.\n\u003e\u003e\u003e\n\u003e\u003e\u003e Tor, for example, has nine \"directory authorities.\" They attempt to\n\u003e\u003e\u003e reach nodes in the Tor network, and record whether they're available. Then,\n\u003e\u003e\u003e they vote among themselves to produce a directory consensus, and they all\n\u003e\u003e\u003e sign it. Lightning could use a similar system. Unlike Tor, we don't need to\n\u003e\u003e\u003e require everyone to use the same directory authorities, either.\n\u003e\u003e\u003e\n\u003e\u003e\u003e On Wed, Jul 1, 2015 at 10:53 AM, Nick ODell \u003cnickodell at gmail.com\u003e wrote:\n\u003e\u003e\u003e\n\u003e\u003e\u003e\u003e \u003eThere is no such central processor though in this case to enforce the\n\u003e\u003e\u003e\u003e reputation of lightening nodes.\n\u003e\u003e\u003e\u003e\n\u003e\u003e\u003e\u003e There's no reason why there couldn't be.\n\u003e\u003e\u003e\u003e\n\u003e\u003e\u003e\u003e Tor, for example, has nine \"directory authorities.\" They attempt to\n\u003e\u003e\u003e\u003e reach nodes in the Tor network, and record whether they're available. Then,\n\u003e\u003e\u003e\u003e they vote among themselves to produce a directory consensus, and they all\n\u003e\u003e\u003e\u003e sign it. Lightning could use a similar system. Unlike Tor, we don't need to\n\u003e\u003e\u003e\u003e require everyone to use the same directory authority, either.\n\u003e\u003e\u003e\u003e\n\u003e\u003e\u003e\u003e On Wed, Jul 1, 2015 at 10:31 AM, Kevin Greene \u003ckgreenek at gmail.com\u003e\n\u003e\u003e\u003e\u003e wrote:\n\u003e\u003e\u003e\u003e\n\u003e\u003e\u003e\u003e\u003e Blargh. The dumb solution here is to just shrug and say that you have\n\u003e\u003e\u003e\u003e\u003e to trust these processors to be highly available, and never try to do\n\u003e\u003e\u003e\u003e\u003e re-routing. That's pretty much equivalent to what would happen if one of\n\u003e\u003e\u003e\u003e\u003e the banks in the visa network had networking issues for example.\n\u003e\u003e\u003e\u003e\u003e\n\u003e\u003e\u003e\u003e\u003e The big difference here though is that visa will kick you out of the\n\u003e\u003e\u003e\u003e\u003e network if you're a bank that's consistently not meeting their\n\u003e\u003e\u003e\u003e\u003e strict SLA's, and that keeps the network honest. There is no such central\n\u003e\u003e\u003e\u003e\u003e processor though in this case to enforce the reputation of lightening\n\u003e\u003e\u003e\u003e\u003e nodes.\n\u003e\u003e\u003e\u003e\u003e\n\u003e\u003e\u003e\u003e\u003e\n\u003e\u003e\u003e\u003e\u003e\n\u003e\u003e\u003e\u003e\u003e On Monday, June 29, 2015, Stephen Morse \u003cstephencalebmorse at gmail.com\u003e\n\u003e\u003e\u003e\u003e\u003e wrote:\n\u003e\u003e\u003e\u003e\u003e\n\u003e\u003e\u003e\u003e\u003e\u003e Hi Rusty,\n\u003e\u003e\u003e\u003e\u003e\u003e\n\u003e\u003e\u003e\u003e\u003e\u003e On Sat, Jun 27, 2015 at 2:41 AM, Rusty Russell \u003crusty at rustcorp.com.au\n\u003e\u003e\u003e\u003e\u003e\u003e \u003e wrote:\n\u003e\u003e\u003e\u003e\u003e\u003e\n\u003e\u003e\u003e\u003e\u003e\u003e\u003e\n\u003e\u003e\u003e\u003e\u003e\u003e\u003e Yes, C can just get the preimage from E and collude to steal the\n\u003e\u003e\u003e\u003e\u003e\u003e\u003e funds,\n\u003e\u003e\u003e\u003e\u003e\u003e\u003e which is a nasty failure mode.\n\u003e\u003e\u003e\u003e\u003e\u003e\u003e\n\u003e\u003e\u003e\u003e\u003e\u003e\u003e\n\u003e\u003e\u003e\u003e\u003e\u003e This scenario may even happen non-maliciously, if C has an honest\n\u003e\u003e\u003e\u003e\u003e\u003e outage and attempts to pick up where it left off on each of its channels.\n\u003e\u003e\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\u003e\u003e transaction with a lower lock time), if C knows he has been offline for\n\u003e\u003e\u003e\u003e\u003e\u003e longer than B's willingness to wait before re-routing. But this isn't\n\u003e\u003e\u003e\u003e\u003e\u003e perfect, or even good, because E cannot know that C isn't just trying to\n\u003e\u003e\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\u003e\u003e guaranteed the payment from B, since they have the pre-image.\n\u003e\u003e\u003e\u003e\u003e\u003e\n\u003e\u003e\u003e\u003e\u003e\u003e\n\u003e\u003e\u003e\u003e\u003e\u003e\u003e Delaying the entire payment is a poor option; can anyone see a better\n\u003e\u003e\u003e\u003e\u003e\u003e\u003e one?\n\u003e\u003e\u003e\u003e\u003e\u003e\u003e\n\u003e\u003e\u003e\u003e\u003e\u003e\n\u003e\u003e\u003e\u003e\u003e\u003e Like you say, delaying the payment seems like a bad way to go, as\n\u003e\u003e\u003e\u003e\u003e\u003e then the payments wouldn't be quite \"Lightning\" fast anymore. 99% of the\n\u003e\u003e\u003e\u003e\u003e\u003e payment could be re-routed though. Perhaps the 99% could be re-routed,\n\u003e\u003e\u003e\u003e\u003e\u003e while A waits for C to rejoin. Or if multiple paths are being used to\n\u003e\u003e\u003e\u003e\u003e\u003e process the payment, just redistribute the remaining payments allotted for\n\u003e\u003e\u003e\u003e\u003e\u003e the broken path among the other functioning paths.\n\u003e\u003e\u003e\u003e\u003e\u003e\n\u003e\u003e\u003e\u003e\u003e\u003e The bigger problem here seems to be that the incentives are slightly\n\u003e\u003e\u003e\u003e\u003e\u003e skewed in favor of dishonestly. One can minimize the impact of that\n\u003e\u003e\u003e\u003e\u003e\u003e dishonesty by breaking the payment into smaller chunks and across diverse\n\u003e\u003e\u003e\u003e\u003e\u003e paths, but this comes at the cost of bandwidth and speed. Some sort of a\n\u003e\u003e\u003e\u003e\u003e\u003e rating system could come into play possibly, if nothing can be\n\u003e\u003e\u003e\u003e\u003e\u003e cryptographically worked out.\n\u003e\u003e\u003e\u003e\u003e\u003e\n\u003e\u003e\u003e\u003e\u003e\u003e Best,\n\u003e\u003e\u003e\u003e\u003e\u003e Stephen\n\u003e\u003e\u003e\u003e\u003e\u003e\n\u003e\u003e\u003e\u003e\u003e\n\u003e\u003e\u003e\u003e\u003e _______________________________________________\n\u003e\u003e\u003e\u003e\u003e Lightning-dev mailing list\n\u003e\u003e\u003e\u003e\u003e Lightning-dev at lists.linuxfoundation.org\n\u003e\u003e\u003e\u003e\u003e https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev\n\u003e\u003e\u003e\u003e\u003e\n\u003e\u003e\u003e\u003e\u003e\n\u003e\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/e7a8f1ab/attachment-0001.html\u003e",
"sig": "ff43486aa7b7de9325214fceacb94664deebd6fd22fc17d3721c9b62e0e1e208b3d1be775e726578629b2738133ed37973e4f712845a45f56f3cb13673a78d48"
}