Skip to content
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

Allow to set max base fee for withdrawals #1383

Closed
ekzyis opened this issue Sep 9, 2024 · 2 comments · Fixed by #1488
Closed

Allow to set max base fee for withdrawals #1383

ekzyis opened this issue Sep 9, 2024 · 2 comments · Fixed by #1488
Assignees
Labels
difficulty:easy feature new product features that weren't there before wallets

Comments

@ekzyis
Copy link
Member

ekzyis commented Sep 9, 2024

Is your feature request related to a problem? Please describe.

I configured 1% as the max fee for autowithdrawals to my phoenixd node. I noticed that withdrawals smaller than 100 sats don't seem to work with phoenixd. I see no route found errors in the wallet logs. I strongly suspect this is because the ACINQ node takes a base fee of 1 sat for receives which means that 1% of anything smaller than 100 sats is not enough.

Since the channel between SN and ACINQ is not public, I tested this by creating a 1 sat invoice from phoenixd and paid it using my sats on SN and noticed that indeed, there was 1 sat as a routing fee:

2024-09-09-143748_743x282_scrot

When we switch to non-custodial, this means that I would receive fee credits for any zap that is smaller than 100 sats.

Describe the solution you'd like

I am fine with paying 1 sat to receive 1 sat even if it means that I pay 50% as routing fees. That's just how lightning base fees work. I think we should allow to set a base fee and then use whatever is higher as the max fee: max_fee = max(max_percentage_fee, max_base_fee)

Describe alternatives you've considered

  • don't care about small zaps becoming fee credits in the future if I continue to use phoenixd
  • run node with private channel to SN again

Additional context

n/a

@ekzyis ekzyis added feature new product features that weren't there before wallets difficulty:easy labels Sep 9, 2024
@ekzyis ekzyis self-assigned this Oct 7, 2024
@ekzyis ekzyis mentioned this issue Oct 18, 2024
@ekzyis
Copy link
Member Author

ekzyis commented Oct 22, 2024

I realized #1488 only fixes pathfinding for autowithdrawals but not for p2p payments. Only during autowithdrawal will the user setting be used but during p2p payments, we use 2.5% as a buffer for network fees.

That is the case because during autowithdrawals, I can pay the 1 sat base fee out of my own balance but when I get zapped 1 sat, there is no other sat for the fee but only 2.5% of 1 sat. This means that anytime 2.5% of a zap can't pay for network fees, the zap must become fee credits. For 1 sat base fee, that's anything below 40 sats.

This brought me to the question: can we allow to use fee credits to pay for network fees? Then p2p payments could use the fee credits of the recipient to pay for network fees; fixing my pathfinding issue 👀

If we can go further, we could also make it possible to use fee credits to buy channels.

@huumn
Copy link
Member

huumn commented Oct 22, 2024

We can begin deducting from the receiver's account to pay for routing (or cut into the received amount), but it's not intuitive. Most people will be surprised by it. We already have people confused by lightning settlement times and paying for routing fees for comments.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
difficulty:easy feature new product features that weren't there before wallets
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants