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

UX for initial fee is terrible #138

Open
chrisguida opened this issue Jan 27, 2025 · 7 comments
Open

UX for initial fee is terrible #138

chrisguida opened this issue Jan 27, 2025 · 7 comments

Comments

@chrisguida
Copy link

chrisguida commented Jan 27, 2025

It appears that the fee for opening a channel is 23566 sat? That's more than US$23!

2025-01-27 19:20:16 purchased inbound liquidity: 2053416 sat (totalFee=23566 sat feePaidFromBalance=0 sat feePaidFromFeeCredit=0 sat feeRemaining=23566 sat purchaseType=fromfuturehtlc)

Please inform users somewhere how many sats they're going to need to send before a channel is opened, or lower the fee.

The current UX is dreadful; the user just has to keep depositing money until a channel is finally opened, and there's no way to withdraw their money until they've deposited this unknown quantity.

The only solution is just to keep adding more and more money. Then suddenly $23 disappears!

@pm47
Copy link
Member

pm47 commented Jan 29, 2025

The official release of phoenixd requires a manual acknowledgment from the user at first startup, with a clear warning that the fee credit is non refundable:

Continuous liquidity
Liquidity management is fully automated.
When receiving a Lightning payment that doesn't fit in your existing channel:
- If the payment amount is large enough to cover mining fees and service fees for automated liquidity, then your channel
- will be created or enlarged right away.
- If the payment is too small, then the full amount is added to your fee credit, and will be used later to pay for future fees.
The fee credit is non-refundable.

Please confirm by typing [I understand]: 

It appears that the fee for opening a channel is 23566 sat?

20k sat is the cost of purchasing 2M sat liquidity.

NB: This issue tracker is only for technical issues related to phoenixd. Please do not open issues for support requests or questions about phoenixd: use Github discussions instead (https://github.com/ACINQ/phoenixd/discussions).

@pm47 pm47 closed this as completed Jan 29, 2025
@chrisguida
Copy link
Author

@pm47 thanks for the response!

The official release of phoenixd requires a manual acknowledgment from the user at first startup, with a clear warning that the fee credit is non refundable:

Yes, but the warning does not say what the fee will be. The user is thinking, "okay, I can buy a little bit of inbound liquidity for the cost of a mining fee + a bit, maybe like $5, that sounds fine." $23 is a lot more than most users are probably assuming the initial fee will cost.

20k sat is the cost of purchasing 2M sat liquidity.

Great, where does anything says this? I'm glad that you're able to put this here, in the response to an issue, but it really should go somewhere in the warning that you referred to above, or maybe in the logs, or somewhere! There is no obvious way to discover what this fee will be, aside from simply trial and error. Again, this is an awful UX.

NB: This issue tracker is only for technical issues related to phoenixd. Please do not open issues for support requests or questions about phoenixd: use Github discussions instead (https://github.com/ACINQ/phoenixd/discussions).

This is not a "support request" or a "question about phoenixd". It is a bug report. The fact that nowhere in the warnings, docs, or logs, is there an easy way to discover what the initial fee will be before paying it, and the fact that there is no way to avoid paying less than $23 to use phoenixd at all, is a software bug in phoenixd, or at least a documentation bug.

@pm47
Copy link
Member

pm47 commented Jan 29, 2025

The doc is here: https://phoenix.acinq.co/server/auto-liquidity. It shows the default value and features two examples with the same default value:

Examples

With the default settings (2m sat auto-liquidity), and assuming that current mining fees are 10k sat, the total fee for a
liquidity operation will be: 10k sat (mining fee) + 20k sat (1% service fee for the liquidity) = 30k sat.

Continuous stream of tiny 100 sat incoming payments

  1. the first 299 incoming payments will be added to your fee credit
  2. when receiving the 300th payment, your credit reaches 30k sat and will immediately be used to create a 2m sat channel, with balance 0 sat on your side
  3. the next 20 thousand payments will be received in your channel and added to your balance, which ends up at 2m sat
  4. back to 1.

@chrisguida
Copy link
Author

chrisguida commented Jan 29, 2025

Okay, thanks! I did not see that document. I think maybe the easiest way to resolve this issue would be to simply link to this document in the warning about auto liquidity.

Something like "The initial fee to use phoenixd can be quite significant. Please see this doc for help estimating what yours will be: https://phoenix.acinq.co/server/auto-liquidity"

@chrisguida
Copy link
Author

Also, allowing the user choose a value between 0sat and 2Msat seems like it could improve the UX a lot as well.

@chrisguida
Copy link
Author

A slightly better UX would be to add a log entry whenever phoenixd receives an invoice.

"Received sats sent to feeCredit as we still don't have enough to open a channel. Add 19,245 sats more to trigger a channel open".

@pm47
Copy link
Member

pm47 commented Jan 29, 2025

I think maybe the easiest way to resolve this issue would be to simply link to this document in the warning about auto liquidity.
Something like "The initial fee to use phoenixd can be quite significant. Please see this doc for help estimating what yours will be: https://phoenix.acinq.co/server/auto-liquidity"

That seems reasonable

@pm47 pm47 reopened this Jan 29, 2025
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