Adds daily spending receive guidance for BOLT 12 and splicing #1194
Conversation
✅ Deploy Preview for bitcoin-design-site ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
There was a problem hiding this comment.
Pull Request Overview
This PR updates the daily spending wallet guidance to incorporate BOLT 12 offers and splicing technology for improved Lightning Network functionality. The changes reflect current wallet capabilities and provide a more streamlined approach to Bitcoin transactions.
- Adds BOLT 12 offers to unified payment requests alongside lightning invoices and on-chain addresses
- Replaces submarine swap mechanism with splicing for simplified balance management
- Updates BIP21 references to BIP(3)21 to reflect the extended standard
Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
There was a problem hiding this comment.
As mentioned in #1191, very cool to see splicing starting to be added to guidance now that all lightning implementations support it (i think).
IIUC splicing is pretty cool tech addressing following use-cases:
- modify channel size without closing-reopening
- (receive) lightning payments larger than receive limit
- (receive) on-chain payments into the existing lightning channel so a single lightning-only balance can be maintained.
Currently (73ae18a) the PR starts by tackling point (3).
I do think the critical use-case might end up being (2), since
- as lightning adoption increases, this scenario will be faced by more and more users
- splicing on-chain fees are likely to be orders of magnitude higher than usual routing fees, which would be a nasty surprise if the user is not informed properly
Would like to see content added/updated at appropriate places in the Guide regarding these such as:
- lightning liquidity (possibly add to illustrations, would be super-useful) (point 1 above)(also coz this page is linked in the content that the PR adds)
- Requesting bitcoin > Fees (soft mention)
- Requesting bitcoin > Receiving > Receiving lightning payments (point 2)
- Requesting bitcoin > Receiving > Receiving on-chain payments (like you already mentioned in #1191) (point 3)
- payment request formats to mention BIP321.
| This wallet utilizes 'swap addresses' for all on-chain transactions. These are used to facilitate the transfer of received Bitcoin into the user's Lightning balance. Consequently, the wallet maintains a single Lightning balance, avoiding the need for a separate on-chain balance. This simplifies the user experience and is trust-minimized and non-custodial, courtesy of [submarine swaps](https://thebitcoinmanual.com/articles/btc-submarine-swaps/). We cover these more in our [lightning services]({{ "/guide/how-it-works/lightning-services/#swaps" | relative_url }}) and receiving pages. | ||
|
|
||
| As unified requests [aren't widely supported yet](https://bitcoinqr.dev/), and users may want to request just from lightning or on-chain, they have options to share the lightning invoice or on-chain address independently. | ||
| This wallet utilizes **splicing** for all on-chain transactions. Splicing allows the seamless transfer of received Bitcoin into the user's Lightning balance without maintaining a separate on-chain balance. As a result, the wallet presents a single Lightning balance, greatly simplifying the user experience. This approach is trust-minimized and non-custodial, as channel capacity can be increased or decreased directly on-chain without relying on external swap services. We cover these more in our [lightning liquidity]({{ "/guide/how-it-works/liquidity" | relative_url }}) and receiving pages. |
There was a problem hiding this comment.
This is existing language, but "for all on-chain transactions" tripped me up. I assume it only means receive-only?
Since added text mentions lightning liquidity and receiving pages, content will also have to be added/updated on those pages.
| This wallet utilizes **splicing** for all on-chain transactions. Splicing allows the seamless transfer of received Bitcoin into the user's Lightning balance without maintaining a separate on-chain balance. As a result, the wallet presents a single Lightning balance, greatly simplifying the user experience. This approach is trust-minimized and non-custodial, as channel capacity can be increased or decreased directly on-chain without relying on external swap services. We cover these more in our [lightning liquidity]({{ "/guide/how-it-works/liquidity" | relative_url }}) and receiving pages. | |
| This wallet utilizes **splicing** for on-chain transactions. Splicing allows the seamless transfer of received Bitcoin into the user's Lightning balance without maintaining a separate on-chain balance. As a result, the wallet presents a single Lightning balance, greatly simplifying the user experience. This approach is trust-minimized and non-custodial, as channel capacity can be increased or decreased directly on-chain without relying on external swap services. We cover this in detail in our [lightning liquidity]({{ "/guide/how-it-works/liquidity" | relative_url }}) and receiving pages. |
There was a problem hiding this comment.
Hm, if the full balance is always on lightning, then a splice would also be needed for sending, no? To get the ₿ out of the channel?
There was a problem hiding this comment.
Good question. This being the Requesting page, shouldn't the commentary be restricted to receiving anyways? On this front, this is a bit of a nit.
(disclaimer: lightning is not my wheelhouse, so I'd love to know what you and others who understand this better, think.)
Re: the meat of your question:
My understanding is that one of the main benefits of splicing for on-chain, is that it increases your channel size, which is strictly good, which also benefits other use cases. But using splicing for on-chain sends will reduce channel size, which is not desirable. For e.g. this might make subsequent lightning receives (use case 2 above) more likely, to require splicing with associated on-chain cost.
Perhaps swaps is an alternative approach that could be used (retained?) for on-chain sends. I know there are issues (costs, third party reliance?) with this too. I've asked Phoenix on twitter, let's see if they respond.
There was a problem hiding this comment.
update: phoenix uses splice outs, but also – https://x.com/phoenixwallet/status/1970891555704799740
There was a problem hiding this comment.
Reducing channel size can be desirable, no? When I have a big balance and want to move it to cold storage or so?
There was a problem hiding this comment.
That's a good point, and a proper splice out use-case... (i wonder if there should be a proper flow for this to allow users to do this?)..,
| ### Payment link | ||
|
|
||
| Payment links use a BIP21 [URI]({{ "/guide/how-it-works/payment-request-formats/#uniform-resource-identifier-uris-schemes" | relative_url }}) `bitcoin:` which makes these readable by other bitcoin applications. These can be included as part of a button or hyperlink. Also see the [wallet selector UI pattern]({{ "/guide/how-it-works/wallet-selector/" | relative_url }}). | ||
| Payment links use a BIP(3)21 [URI]({{ "/guide/how-it-works/payment-request-formats/#uniform-resource-identifier-uris-schemes" | relative_url }}) `bitcoin:` which makes these readable by other bitcoin applications. These can be included as part of a button or hyperlink. Also see the [wallet selector UI pattern]({{ "/guide/how-it-works/wallet-selector/" | relative_url }}). |
There was a problem hiding this comment.
"BIP(3)21" tripped me up since I didn't know about BIP321, but it might be just me.
The linked page (payment request formats) only mentions BIP21, so this could be updated to mention and link to BIP321.
There was a problem hiding this comment.
Probably fine to just write BIP21 here. The (3) part reads funny, and BIP21 covers the relevant functionality.
I've added a recommendation to also include BOLT 12 in the default BIP(3)21 URI. We are now at a stage where prominent bitcoin wallets are supporting it as evidenced at bolt12.org. It will also be supported soon in bLIP-52/LSPS2 for inbound liquidity.
The mockups should include the ability to generate a QR code with a BOLT 12 offer.
Splicing also offers significant advantages for managing Lightning Network channels, making the user experience more fluid and cost-effective. It doesn't require a third party to help facilitate the swap. Phoenix wallet offer this functionality by default.