pull down to refresh
21 sats \ 0 replies \ @ACINQ 16 Nov 2023 \ parent \ on: Sending from Blink to Phoenix - Unable to find a route bitcoin
@BitByBit21 gave the correct answer.
Sender only pays the routing fee, not the mining fee needed to create (or increase the size of) the receiver's channel. Mining fees are paid by the receiver, deducted from the received amount.
To make the most out of self-custodial LN wallet, look at them like prepaid debit card. Load them infrequently with large amounts, then spend as you like.
21 sats \ 0 replies \ @ACINQ 17 Oct 2023 \ parent \ on: Help me Understand Phoenix Fee Concept bitcoin
Yes we are planning something like this. We already have a somewhat similar screen for unified invoices.
388 sats \ 0 replies \ @ACINQ 17 Oct 2023 \ parent \ on: Help me Understand Phoenix Fee Concept bitcoin
Yes, since Phoenix is only connected to the ACINQ node.
961 sats \ 3 replies \ @ACINQ 17 Oct 2023 \ parent \ on: Help me Understand Phoenix Fee Concept bitcoin
their fees can get up to and cross onchain fee equivalents
When that happens, consider sending on-chain instead, there is no overhead you will only pay the mining fee. Depending on amount/feerates/etc., on-chain makes more sense than Lightning sometimes. The new Phoenix precisely allows you to get the best of both world.
828 sats \ 1 reply \ @ACINQ 17 Oct 2023 \ parent \ on: Help me Understand Phoenix Fee Concept bitcoin
its not good to fight technical reality
Exactly, but we may have a little bit over corrected in that direction here and can probably do better.
437 sats \ 1 reply \ @ACINQ 17 Oct 2023 \ parent \ on: Help me Understand Phoenix Fee Concept bitcoin
Receiving fee = mining fee (when inbound liq is insufficient)
Sending fee = 0.4% + 4 sat
There is currently a silly rouding error in the iOS interface which shows 0.5% but it's really 0.4%
915 sats \ 2 replies \ @ACINQ 17 Oct 2023 \ parent \ on: Help me Understand Phoenix Fee Concept bitcoin
Buying inbound liquidity upfront (aka liquidity ads in LN protocol speak) is one of the options that we are exploring. Devil is in the details though.
Hi! ACINQ/Phoenix dev here.
The general idea is that Phoenix is geared toward use cases that make the most economical sense, as a self-custodial Lightning wallet. It is true that with v2 we have so far made little effort to accomodate use cases that we are not convinced are sustainable at scale. The reason is that there is a very fine line between "doing our best to allow everyone to play" and "actively incentivizing unsustainable usage". This is not at all to say things are frozen the way they are today, it just explains our approach and the order in which we are doing things.
What makes the most economical sense: loading Phoenix from time to time with large (compared to mining fees) amounts, and then spend anytime with any amount. It scales and incentives are aligned for everyone. This is the so-called "Visa use case", except that Phoenix/Lightning arguably does it already better (faster, cheaper, and more privately) than Visa -- a widely underappreciated fact, in our opinion.
Person-to-person micropayments are much more challenging to do in an economically scalable way. What you see as your inbound liquidity is in fact our balance. It is easy to foresee the potential issues when you scale to 1M users. Our starting point was to not take any fee on receive, and not provide any additional liquidity. This causes mining fees to deincentivize receiving tiny payments, which is what you are running into here. We are actively discussing that and already received interesting feedback on various options. Again we're not judging what should or should not be done in principle, just what service we can deliver reliably and sustainably at scale.
LN is supposed to be cheap and stay that way?
Lightning is only cheaper than on-chain, big difference (and also: instant and more private).
What happens with L1 payments if the miners fees don't adhere to my configured fee policy?
Missed that one. If that happens the swap will stay pending, and will be reattempted next time you start the wallet. As mentioned in our blog post, if you are not in a rush this allows you to minimize fees by allowing a certain max budget.
Hi! ACINQ dev here.
Their German is also not the best
Entschuldigung! Doing our best with mostly automated translation
Clicking on "Payment options" reveals a legacy LNURL authentication scheme. Interesting. Don't know anything about the details though. What is the difference to the standard scheme?
It's for backward compat. Our legacy app had a non-standard implementation of LNURL-auth. Migrated wallets will default to the legacy mode.
There is a swap-in wallet using descriptors and a final wallet using zpub now! I think this wasn't shown to the user before.
Yes, the swap-in wallet is new and derives from the seed (in the previous version it was controlled by ACINQ). The final wallet was there before.
There seems to be a minor bug regarding fiat currency however. I only see "?!
If it persists after restarting the app, please report to support.
So I still have to see splicing in effect. I'll report back when that was the case.
One way to try is to send funds to your own phoenix bitcoin address, and bump the fee of the on-chain transaction.
This way you will do:
- a splice-out (1 input, 2 outputs)
- then a splice-cpfp (1 input, 1 output)
- then finally a splice-in (2 inputs, 1 output) and go back to the initial state. You can follow all that on mempool.space and learn quite a bit. It will cost you a few thousand sat in mining fees.
GENESIS