📅 Original date posted:2022-12-09
📝 Original message:
> I don't think so - today there are at least three different routing goals to maximize - (a) privacy,
> (b) fees, (c) success rate. For "live" payment, you probably want to lean towards optimizing for
> success rate, and many nodes do today by default. But that isn't the full story - many nodes do
> background rebalancing and they prefer to take paths which optimize for fees, trying many paths they
> think are likely to fail to see if they can rebalance with lower fees. I don't think we should tell
> those users/use-cases that they aren't allowed to do that or they're doing something "wrong" - I
> think choosing to optimize for fees (or, in the future, privacy) is an important thing to allow, and
> ideally make as reliable as possible, without charging extra for it.
Right, the trade-offs here are really tricky to navigate and to whatever extent this is possible the choice of what trade-offs to make should be pushed to the user. For example, not knowing the real time channel balances clearly hurts routing success. If this degraded routing success from 95 percent to say 90 percent the network as a whole would probably be willing to pay that routing success "cost" to ensure better balance privacy. But if it degraded routing success from 95 percent to say 50 percent I expect much of the network wouldn't be willing to put up with that terrible routing success percentage and routing nodes would probably seek to broadcast their channel balances either in gossip or out of band.
Similarly a routing node not knowing the source of the payment and the intermediate nodes on the route is fine (it is clearly *much* better for privacy) assuming jamming attacks occur rarely. But if the network is being paralyzed regularly by jamming attacks a routing node is going to show a lot more interest in which Lightning node it is routing payments for and which other Lightning nodes are also part of the route. You aren't going to want to continue to be subject to jamming attacks by the same Lightning node.
Hence I stick by this from a protocol developer perspective.
"Decisions protocol developers make will impact what data can be collected and how easy that data is to collect (there are already some tricky trade-offs with regards to privacy, routing success and transparency for when things go wrong) but beyond that protocol developers should leave it to others."
A protocol developer (and individual implementation developer I guess) is going to have to wrestle with these trade-offs and to what extent options can be pushed to the user. But protocol reputation tokens that can be sold or transferred to an attacker or worse collected through gaming the system, ouch. The protocol developer has taken a problem (jamming attacks) that already exists and added an additional problem (reputation) which no doubt will be addressed by adding an additional problem on top of that and another on top of that etc etc.
--
Michael Folkson
Email: michaelfolkson at protonmail.com
Keybase: michaelfolkson
PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
------- Original Message -------
On Sunday, December 4th, 2022 at 02:03, Matt Corallo <lf-lists at mattcorallo.com> wrote:
>
> On 11/15/22 12:09 PM, Clara Shikhelman wrote:
>
> > Matt – I don't know that I agree with "... upfront payments kinda kill the lightning UX ...". I
> > think that upfront fees are almost essential, even outside the context of jamming. This also helps
> > with probing, general spam, and other aspects. Furthermore, I think that the UX is very explainable,
>
>
> Indeed, it may be explainable, but its still somewhat painful, I think. I do wonder if we can enable
> probing via a non-HTLC message and do immediate pre-send-probing to avoid paying upfront fees on
> paths that will fail.
>
> > and in general nodes shouldn't be motivated to send a lot of failed payments, and should adopt
> > better routing strategies.
>
>
> I don't think so - today there are at least three different routing goals to maximize - (a) privacy,
> (b) fees, (c) success rate. For "live" payment, you probably want to lean towards optimizing for
> success rate, and many nodes do today by default. But that isn't the full story - many nodes do
> background rebalancing and they prefer to take paths which optimize for fees, trying many paths they
> think are likely to fail to see if they can rebalance with lower fees. I don't think we should tell
> those users/use-cases that they aren't allowed to do that or they're doing something "wrong" - I
> think choosing to optimize for fees (or, in the future, privacy) is an important thing to allow, and
> ideally make as reliable as possible, without charging extra for it.
>
> Matt
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Michael Folkson [ARCHIVE] /
npub103…2kpam
2023-06-09 13:07:36
in reply to nevent1q…r6g2
Author Public Key
npub103ycruxnchhvja33mcnnkfdkgd0s7vlqlfkvufcdm5lnhpuh6f4q82kpamPublished at
2023-06-09 13:07:36Event JSON
{
"id": "7e8cdd09ef1aa9921b27e82540eca7d25b0d54c76acea7056b29e464415c098b",
"pubkey": "7c4981f0d3c5eec97631de273b25b6435f0f33e0fa6cce270ddd3f3b8797d26a",
"created_at": 1686316056,
"kind": 1,
"tags": [
[
"e",
"93282dcc4ea7a997849d920e084837fc742e7c3d85028117dd7b704981f38e80",
"",
"root"
],
[
"e",
"66cae724c3403e1c989ac42a3b5523bbc1efe0a6976196486f6c9d718db317e6",
"",
"reply"
],
[
"p",
"e12e808a938266c6ff00dc723941b2ec1a50b73dccb395b9766737bd6c31e4be"
]
],
"content": "📅 Original date posted:2022-12-09\n📝 Original message:\n\u003e I don't think so - today there are at least three different routing goals to maximize - (a) privacy,\n\u003e (b) fees, (c) success rate. For \"live\" payment, you probably want to lean towards optimizing for\n\u003e success rate, and many nodes do today by default. But that isn't the full story - many nodes do\n\u003e background rebalancing and they prefer to take paths which optimize for fees, trying many paths they\n\u003e think are likely to fail to see if they can rebalance with lower fees. I don't think we should tell\n\u003e those users/use-cases that they aren't allowed to do that or they're doing something \"wrong\" - I\n\u003e think choosing to optimize for fees (or, in the future, privacy) is an important thing to allow, and\n\u003e ideally make as reliable as possible, without charging extra for it.\n\nRight, the trade-offs here are really tricky to navigate and to whatever extent this is possible the choice of what trade-offs to make should be pushed to the user. For example, not knowing the real time channel balances clearly hurts routing success. If this degraded routing success from 95 percent to say 90 percent the network as a whole would probably be willing to pay that routing success \"cost\" to ensure better balance privacy. But if it degraded routing success from 95 percent to say 50 percent I expect much of the network wouldn't be willing to put up with that terrible routing success percentage and routing nodes would probably seek to broadcast their channel balances either in gossip or out of band.\n\nSimilarly a routing node not knowing the source of the payment and the intermediate nodes on the route is fine (it is clearly *much* better for privacy) assuming jamming attacks occur rarely. But if the network is being paralyzed regularly by jamming attacks a routing node is going to show a lot more interest in which Lightning node it is routing payments for and which other Lightning nodes are also part of the route. You aren't going to want to continue to be subject to jamming attacks by the same Lightning node.\n\nHence I stick by this from a protocol developer perspective.\n\n\"Decisions protocol developers make will impact what data can be collected and how easy that data is to collect (there are already some tricky trade-offs with regards to privacy, routing success and transparency for when things go wrong) but beyond that protocol developers should leave it to others.\"\n\nA protocol developer (and individual implementation developer I guess) is going to have to wrestle with these trade-offs and to what extent options can be pushed to the user. But protocol reputation tokens that can be sold or transferred to an attacker or worse collected through gaming the system, ouch. The protocol developer has taken a problem (jamming attacks) that already exists and added an additional problem (reputation) which no doubt will be addressed by adding an additional problem on top of that and another on top of that etc etc.\n\n--\nMichael Folkson\nEmail: michaelfolkson at protonmail.com\nKeybase: michaelfolkson\nPGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3\n\n\n------- Original Message -------\nOn Sunday, December 4th, 2022 at 02:03, Matt Corallo \u003clf-lists at mattcorallo.com\u003e wrote:\n\n\n\u003e \n\u003e On 11/15/22 12:09 PM, Clara Shikhelman wrote:\n\u003e \n\u003e \u003e Matt – I don't know that I agree with \"... upfront payments kinda kill the lightning UX ...\". I\n\u003e \u003e think that upfront fees are almost essential, even outside the context of jamming. This also helps\n\u003e \u003e with probing, general spam, and other aspects. Furthermore, I think that the UX is very explainable,\n\u003e \n\u003e \n\u003e Indeed, it may be explainable, but its still somewhat painful, I think. I do wonder if we can enable\n\u003e probing via a non-HTLC message and do immediate pre-send-probing to avoid paying upfront fees on\n\u003e paths that will fail.\n\u003e \n\u003e \u003e and in general nodes shouldn't be motivated to send a lot of failed payments, and should adopt\n\u003e \u003e better routing strategies.\n\u003e \n\u003e \n\u003e I don't think so - today there are at least three different routing goals to maximize - (a) privacy,\n\u003e (b) fees, (c) success rate. For \"live\" payment, you probably want to lean towards optimizing for\n\u003e success rate, and many nodes do today by default. But that isn't the full story - many nodes do\n\u003e background rebalancing and they prefer to take paths which optimize for fees, trying many paths they\n\u003e think are likely to fail to see if they can rebalance with lower fees. I don't think we should tell\n\u003e those users/use-cases that they aren't allowed to do that or they're doing something \"wrong\" - I\n\u003e think choosing to optimize for fees (or, in the future, privacy) is an important thing to allow, and\n\u003e ideally make as reliable as possible, without charging extra for it.\n\u003e \n\u003e Matt\n\u003e _______________________________________________\n\u003e Lightning-dev mailing list\n\u003e Lightning-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev",
"sig": "76ac61d6284ae347bc4b1c29cec0fed051fec0029308ea9942a497265bedfc003639c2d2b21162c207d9c132b832736f3673ac15535ea3bd5862bfed0b9c38d1"
}