Replies: 7 comments 11 replies
-
|
|
Beta Was this translation helpful? Give feedback.
-
|
Interesting... do you have the link for that post at the bottom? |
Beta Was this translation helpful? Give feedback.
-
|
Dynamic commit fees can be a surprising event for people managing their own channels: https://www.reddit.com/r/Bitcoin/comments/cjtgf6/lightning_network_question_commit_fee/ The commit fee is some satoshi's your channel reserves so it can be closed when the time comes to close it.
|
Beta Was this translation helpful? Give feedback.
-
|
Not knowing if it’s beneficial or possible to activate multi-path payments. I went to pay an invoice yesterday (~150k sats) with Zeus wallet. I was shown a prediction of ~18% likelihood of success, so I attempted MPP. Failed twice. I then attempted a standard payment, which completed almost immediately. |
Beta Was this translation helpful? Give feedback.
-
|
Incoming channels and liquidity for users running their own nodes is always a challenge. They are usually referred to bitrefill, lnbig etc in order to get started. In BTCPay we're trying to find a ways on how to offer these different providers via UI, but also communicate it to the user easily enough on why they may or may not want to use a provider for an immediate incoming liquidity. |
Beta Was this translation helpful? Give feedback.
-
|
Sorry, didn't mean to reply this in a thread GitHub for mobile is weird. |
Beta Was this translation helpful? Give feedback.
-
|
I wonder why Zeus asks if MPP should be used |
Beta Was this translation helpful? Give feedback.
-
|
I'm unsure. It seems to be an option for all sends. Here's a screenshot of an invoice payment I just set up in Zeus. Also—and with full props to Evan, because I really like Zeus—the probability seems way off. The below invoice is from custodial (default) Blue Wallet, so I would assume it's almost guaranteed to succeed.
|
Beta Was this translation helpful? Give feedback.
-
|
I forwarded your comment to Evan, he said he'll look into it. |
Beta Was this translation helpful? Give feedback.
-
|
Few from me:
|
Beta Was this translation helpful? Give feedback.
-
|
On the lightning-dev list i just came across someone trying to propose an on-chain fallback address for lightning invoices. This already exists in the BOLT11 spec though but the problem with routing they encountered is one that is worth exploring design solutions for. I've documented some of this here even though the emphasis was on using BIP21 URIs (because of support for non-lightning applications, idealy everything would default to BOLT11, even on-chain as it's a more expressive format).
In the graphic above the sender scans a QR code that contains a lightning invoice, and a bitcoin on-chain address. The wallet by default attempts to make a lightning payment but encounters a routing error. The sender can at this point choose to make the payment on-chiain instead (or to open a channel with the receiver?). |
Beta Was this translation helpful? Give feedback.
-
|
Is this the same technique that Muun is using? |
Beta Was this translation helpful? Give feedback.
-
|
An interesting UX possibility that this concept could open up is the ability to have one QR code rather than separate receive QRs for LN invoices / on-chain addresses (A BLIP standard maybe?). For more technical focused wallets having them separate would probably be preferred but for a average user wallet like Muun it would be more user friendly imo. I know when I've on boarded people into Bitcoin through Muun the first usability issue they experience is why is there a on-chain and Lightning method of receiving a payment? This could somewhat resolve that issue. You could have it so when this 'One QR' is shared to the sender and they scan it they get the option to either send via the on-chain address or the LN invoice (depending on what wallet they are using / what layer they hand funds on etc.) Users who have already received Bitcoin are likely more familiar with the two concepts thus this extra burden falling on them (having to pick which option to pay with) rather than a user who has never received a payment would lead to less on boarding friction which is critical for user retention. You could even take this a step further and on the sending side have the two options as something like 'Send payment' for on-chain and 'Send instant payment' for the LN option. |
Beta Was this translation helpful? Give feedback.
-
|
A few comments from Twitter to better keep track of them:
|
Beta Was this translation helpful? Give feedback.
-
|
I think micro-copy/UX copy is a big area of opportunity. It’s a domain of its own, but maybe something like this has a place in a design guideline. |
Beta Was this translation helpful? Give feedback.
-
https://twitter.com/EndlessBullrun/status/1423246882202030081?s=20 Possibly related to submarine swaps Muun is using for easier onboarding. https://twitter.com/EndlessBullrun/status/1423246882202030081?s=20 |
Beta Was this translation helpful? Give feedback.
-
|
On-chain has been so cheap lately I'd imagine many people have been experiencing this issue. |
Beta Was this translation helpful? Give feedback.
-
Expiring invoices were mentioned as a problem a few times during Community Call #18. What else have you come across?
Here's an error @ConorOkus encountered when trying to buy a t-shirt.
Paid using an on-chain transaction in the end when the intention was to use lightning.
Beta Was this translation helpful? Give feedback.
All reactions