justinmoon commented 7 months ago

Currently a poorly-run gateway can join a federation and cause a lot of payment failures because the client isn't smart about ignoring such a gateway. For this reason, we should have an optional mechanism to whitelist gateways enabling guardians to prevent such unknown gateways from registering.

Simplest way to do this is a FM_GATEWAY_WHITELIST parameter that you can set to a list of gateway_ids. But this might be something that should be under consensus and configurable via guardian dashboard in the future.

elsirion commented 7 months ago

I wouldn't restrict who can register gateways, but rather:

Add the necessary API to the LN client to select gateways manually
Define a meta field that specifies a set of vetted gateways. Clients can then choose to prefer these.

okjodom commented 7 months ago

I'm thinking the gateway meta filed should be a JSON list of hex encoded gateway ids. Would we need to add a meta field to LightningClientConfig, similar to GlobalClientConfig meta?

m1sterc001guy commented 7 months ago

I worry a little bit that, in practice, adding a concept of vetted gateways essentially enables selection of the gateways by the federation.

Could we add smarter logic on the client-side for gateway selection? We've talked in the past about adding gateway selection policies but today everything is still manual.

okjodom commented 7 months ago

I worry a little bit that, in practice, adding a concept of vetted gateways essentially enables selection of the gateways by the federation.

Yeah feels like vetting adds an element of censorship by the federation. Not sure if we should implement it anyways.

Regards to smarter selection logic, what parameters would a client consider when selecting a gateway, and how can we encode these in the gateway registration info? I'm imagining some kind of a reliability counter that updates with every failed send/receive payment

justinmoon commented 7 months ago

I'm imagining some kind of a reliability counter that updates with every failed send/receive payment

The hard part is not creating a system that can be easily gamed. If we just included the payment reliability, I could sabotage you're gateway by asking it to pay a bunch of invoices that don't correspond to any real lightning node.

m1sterc001guy commented 7 months ago

The hard part is not creating a system that can be easily gamed. If we just included the payment reliability, I could sabotage you're gateway by asking it to pay a bunch of invoices that don't correspond to any real lightning node.

Right. My initial thought is to "discover" gateway reliability but do it per client (kind of like probing in the lightning network). That way, if you spam a gateway with a bunch of failed payments, you're only hurting your own gateway reliability metric, but not for other clients.

One issue with this though is that it takes time (and failures) to discover these things, so new users might have a poor experience while discovering which gateways are reliable.

elsirion commented 6 months ago

I think having a vetted_gateways concept isn't in conflict with more intelligent GW selection logic, but can rather be seen as a starting point: other gateways can still be tried once we implement more client side logic and if vetted gateways don't perform they will be ignored.

But till we get better client side logic this is an adequate solution imo.