Remove website from LSPS1 #96
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
I don't think advertising a website should be in the scope of LSPS1. We should probably move icons, websites and pricing info to a separate LSPS.
SeverinAlexB
approved these changes
Feb 29, 2024
tnull
approved these changes
Mar 1, 2024
JssDWt
approved these changes
Mar 21, 2024
Would LSPS0 be that |
|
Merge decision made in the meeting today |
As far as I remember, we talked about a separate LSPS.
Feel free to create a LSPS6 proposal PR :) |
ErikDeSmedt
added a commit
to Blockstream/cln-lsps
that referenced
this pull request
Apr 9, 2024
tnull
added a commit
to tnull/lightning-liquidity
that referenced
this pull request
Apr 9, 2024
ErikDeSmedt
added a commit
to Blockstream/cln-lsps
that referenced
this pull request
Apr 9, 2024
ErikDeSmedt
added a commit
to ErikDeSmedt/lsp
that referenced
this pull request
Apr 24, 2024
This commit changes `LSPS1.get_info` response. # Don't wrap data in the options-field All data was wrapped in the `options`-field. This field is useless since [we removed the website from LSPS1](BitcoinAndLightningLayerSpecs#96). @tnull suggested to not use the field anymore. # Drop all payment related fields I had included an `supports_onchain_payment`-field. We don't include this data in `lsps1.get_info` anymore. The client has to create an order and can see the payment options subsequently. Suggested-By: Elias Rohrer <dev@tnull.de>
ErikDeSmedt
added a commit
to ErikDeSmedt/lsp
that referenced
this pull request
Jun 14, 2024
This commit changes `LSPS1.get_info` response. # Don't wrap data in the options-field All data was wrapped in the `options`-field. This field is useless since [we removed the website from LSPS1](BitcoinAndLightningLayerSpecs#96). @tnull suggested to not use the field anymore. # Drop all payment related fields I had included an `supports_onchain_payment`-field. We don't include this data in `lsps1.get_info` anymore. The client has to create an order and can see the payment options subsequently. Suggested-By: Elias Rohrer <dev@tnull.de>
SeverinAlexB
pushed a commit
that referenced
this pull request
Jun 21, 2024
* LSPS1: Explicitly support LSPS1 payment options This PR aims to address a few problems in LSPS1. I'll provide a few motivating examples of why I believe the changes proposed in this MR are desirable. # 1. Use seprate fee for onchain vs lightning payment Onchain payments are more expensive for the LSP than lightning payments because they create their own utxo. The LSP will have to carry the cost of spending that new utxo at a later point in time. This PR provides LSP's the option to set a different fee depending on the payment method. On a related note @2Fast2BCn [noted](#95 (comment)) that a similar argument could be made for the `expiry_date` of an order. The LSP might want to set a different `expiry_date` depending on the chosen payment option. See issue: #92 See comment: #95 (comment) # 2. Extensibility for additional payment methods This PR allows to add additional payment options later. In this section I'll provide a few motivating example. ## 2.1. Dual funding Recently, dual-funding got merged to the spec. The spec describes a new channel open protocol in which both the client and server can contribute funds. This approach provides a superior trust model. The client doesn't have to trust the LSP to open the channel. The benefit is especially clear if `client_balance_sat` is high. In the current version of LSPS1 the LSP could take the money and run. ## 2.2. BOLT-12 support Today, BOLT-11 invoices are commonly used to make payments over lightning. Personally, I'd describe myself as a BOLT-12 maxi. This PR makes it easier to add BOLT-12 as a payment option later. ### 2.3 Withhold from first payment We see a demand for JIT-channels where the client specifies the channel-size. This is currently not possible on LSPS2 or LSPS4. See issue: #65 # Breaking changes: Why (not) to merge this MR? We are in a bit of tension here. The spec is marked as `FOR IMPLEMENTATION` but we are seeing some usage on mainnet. This PR is breaking in the sense that clients will not be able to purchase channel if either the client or server uses this new revision. However, there will be some hassle for users but merging this MR should not put any funds at risk. * Added newline Suggested-By: 2Fast2Bcn * Update LSPS1/README.md Co-authored-by: Elias Rohrer <dev@tnull.de> * Update LSPS1/README.md Co-authored-by: Elias Rohrer <dev@tnull.de> * Fixes suggested by tnull * LSPS1: JSON formatting * LSPS1: Fix examples * Update LSPS1/README.md Co-authored-by: Elias Rohrer <dev@tnull.de> * LSPS1: Clean up lsps1.get_info response This commit changes `LSPS1.get_info` response. # Don't wrap data in the options-field All data was wrapped in the `options`-field. This field is useless since [we removed the website from LSPS1](#96). @tnull suggested to not use the field anymore. # Drop all payment related fields I had included an `supports_onchain_payment`-field. We don't include this data in `lsps1.get_info` anymore. The client has to create an order and can see the payment options subsequently. Suggested-By: Elias Rohrer <dev@tnull.de> * Fix typo * LSPS1: Do not allow null-fields in `onchain` An LSP should only include the `onchain` payment-option if it is willing to accept `onchain` payments for that order. Previously, we set the `onchain_address` to `null` to indicate that the LSP did not accept `onchain` payments. This is no longer needed. * LSPS1: Remove onchain payment tracking The client should not rely on the LSP for transaction details of their own payments. Removing this fields simplifies the spec * LSPS1: Rename `REFUNDED` to `CANCELLED` For lightning invoice the `REFUNDED` state existed. This name is not approriate cause in many scenario's the payment has never happened in the first place. * LSPS1: Use full lightning invoices --------- Co-authored-by: Elias Rohrer <dev@tnull.de>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
I don't think advertising a website should be in the scope of LSPS1.
We should probably move icons, websites and pricing info to a separate LSPS.