Open rolznz opened 3 months ago
From Megalith:
For the onchain payments, keep in mind that confirmation of the channel can take time, so you likely should poll the get_order endpoint so you can keep the user informed of the status of the order: https://docs.megalithic.me/lightning-services/lsp1-get-inbound-liquidity-for-mobile-clients#step-5-your-client-checks-the-status-of-the-order
Also, whoever is implementing onchain payments needs to to know that the LSPS1 has two confusing fields in the /create_order
response...... order_total_sat
and min_fee_for_0conf
-- you'll need to understand both of these -- we cover them in this part of our documentation:
Update: The LSPS1 spec has a late-breaking change ... https://github.com/BitcoinAndLightningLayerSpecs/lsp/commit/76bc908ba109fbdf7fc92aee53f2ce67cba2314d ... which solves a lot of the complexity around onchain payments. We've updated our API and documentation to match: https://docs.megalithic.me/lightning-services/lsp1-get-inbound-liquidity-for-mobile-clients
When building the user interface for onchain payments, we recommend that you set the minimum channel size at 1,000,000
satoshis.
This is because our LSPS1 API currently sets the minimum onchain payment at 25,000
satoshis -- we need to do this because accumulating lots of small onchain payments on our end is somewhat dangerous in an unpredictable fee environment.
It will depending on the current onchain fee rates, as that impacts both the lightning and onchain price.... but, typically if your user requests a channel of 1,000,000
satoshis or more, they should see that the cost of opening a channel with an onchain payment, vs. a lightning payment, is very similar, and this should lead to a more understandable and predictable user experience.