-
Notifications
You must be signed in to change notification settings - Fork 224
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Configurable Gateway Fees #2246
Conversation
ad96585
to
8ee869f
Compare
Is the next step making an API so that the fees are configurable? |
Yes. Left that out because I believe we have opportunity to introduce better configurable fee declaration before we introduce the api to configure the fees. Additionally, we might want to make design decisions like supporting dynamic fee configuration per federation, vs some global fee configuration, vs automated fee configuration (based on route hints?) |
b133005
to
b2faeaa
Compare
Codecov ReportPatch coverage:
Additional details and impacted files@@ Coverage Diff @@
## master #2246 +/- ##
==========================================
+ Coverage 61.18% 61.22% +0.03%
==========================================
Files 180 180
Lines 36185 36286 +101
==========================================
+ Hits 22141 22217 +76
- Misses 14044 14069 +25
☔ View full report in Codecov by Sentry. |
b2faeaa
to
544ff96
Compare
b833c5f
to
b9906aa
Compare
@@ -379,6 +379,29 @@ impl Encodable for lightning_invoice::Invoice { | |||
} | |||
} | |||
|
|||
impl Encodable for lightning::routing::gossip::RoutingFees { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not sure if it"s a good idea to depend for our own encodings on data-structures from external crates (that possibly could change).
Also how we are going to implement gateway fees and LN gateway fees, are probably two different things.
Could have fees paid in different currencies supported by federation, or maybe "no gateway fee tuesdays", or some other things? If not, then whatever, let"s just go with this, seems reasonable. If possibly yes, maybe we should go with an enum. But the main variant of that enum should probably be this thing. Not sure if we should copy&paste or use directly.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
RE: Also how we are going to implement gateway fees and LN gateway fees, are probably two different things.
Could have fees paid in different currencies supported by federation, or maybe "no gateway fee tuesdays", or some other things? If not, then whatever, let"s just go with this, seems reasonable. If possibly yes, maybe we should go with an enum. But the main variant of that enum should probably be this thing. Not sure if we should copy&paste or use directly.
Fantastic idea IMO. If I adopt it as a proposal, we"d have
#[non_exhaustive]
pub enum FeeStructure {
LnRouting { fees: RoutingFees }
}
To open up future possibility of:
#[non_exhaustive]
pub enum FeeStructure {
LnRouting { fees: RoutingFees },
Discount { ... }
}
Because "Free Gateway Tuesdays" is a fantastic thing :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
RE: Not sure if it"s a good idea to depend for our own encodings on data-structures from external crates (that possibly could change).
We are also guilty in these other accounts, and I"m not keen on maintaining a variant of RoutingFees because we already have a dependency on the crate and type in other scenarios.
Can we fully rely on version control to alert breaks in encodings? Is maintaining our own types the only way to avoid encoding extern types?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Proposing flexible fee structure as a quick follow up to the current PR: #2287
Thinking about this a little more, I think we need to achieve the following:
So the first conclusion is that I think we need separate fees for incoming and outgoing payments. They fundamentally represent costs of different resources: outgoing lightning liquidity, and incoming lightning liquidity + cost and risk of holding ecash. Another conclusion is that no matter how we express these fees in the outgoing case, we need to take them into consideration when the gateway pays the actual invoice. We’ll need to pass these fee calculations on to PayInvoiceRequest.max_fee_percent field in our gRPC spec. Without doing this, the gateway only controls the fees they charge the end-user, but could still lose money routing the payment if routing fees exceed fees charged to the user. I’m also not sure if Edit: Client currently hard-codes a routing fee of 0 for the gateway for incoming payments. |
b9906aa
to
dab8069
Compare
dab8069
to
7a99ba0
Compare
@@ -47,6 +49,11 @@ pub struct GatewayOpts { | |||
/// Gateway webserver authentication password | |||
#[arg(long = "password", env = "FM_GATEWAY_PASSWORD")] | |||
pub password: String, | |||
|
|||
/// Configured gateway routing fees | |||
/// Format: <base_msat>,<proportional_millionths> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nit: For me I know I would be confused by this format, would probably just prefer separate parameters
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actually I would want us to remove this gateway config soon as we have an API from #2271
let fees = gateway.fees; | ||
let base_fee = fees.base_msat as u64; | ||
let margin_fee: u64 = if fees.proportional_millionths > 0 { | ||
let fee_percent = 1000000 / fees.proportional_millionths as u64; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What does 1000000 represent? Would prefer constant
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
huh. it"s just the number 1 million used to compute percentage here :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, let"s iterate on it
thanks for review. @justinmoon, take a look if you still need this change asap |
Enable configurable gateway fees for routing outgoing payments.
Fees are declared using known RoutingFees structure from lightning crate, and can be configured when setting up the gateway.
Example:
export FM_GATEWAY_FEES= "10,2000"
means the gateway will run declare a10 msat
base fee and a2%
liquidity based fee to federations servedBy default, gatewayd configures a base fee of 0 msat and a marginal fee of 1%, which is on par with current behavior.
Next, we need to introduce a gateway API for configuring routing fees
Longer term, we need more comprehensive definition for gateway fees, as tracked by Discussion #2392