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

Transaction fees for operators #455

Open
kiwiidb opened this issue Nov 28, 2023 · 1 comment
Open

Transaction fees for operators #455

kiwiidb opened this issue Nov 28, 2023 · 1 comment

Comments

@kiwiidb
Copy link
Contributor

kiwiidb commented Nov 28, 2023

  • A simple per-tx-fee would be adding an extra transaction fee entry in HandleSuccesfulpayment. It is however possible that such a payment might fail because it would put the account below 0. It would be possible to also take the extra fee into account when calculating the fee reserve. However this would further complicate things and it would also mean that users would be unable to send a Lightning payment even though they could pay for the Lightning transaction fee (if they could not pay the max LN fee + internal fee).
  • An alternative would be to charge fees for incoming payments, which has the benefit that it would never take the account below 0.
  • Another alternative would be automated payouts daily, weekly or monthly based on a users' volume or other factors. Like subscription payments, paid automatically.
@rolznz
Copy link
Contributor

rolznz commented Nov 29, 2023

@kiwiidb for the per-tx-fee, I think it's reasonable that if you cannot pay the total amount (amount + any fees) then you should not be able to make the payment. Why do you think this is an issue (apart from additional complexity?)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants