chore: Add implementations to main readme #92
Closed
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
|
Thanks. |
tnull
approved these changes
Feb 28, 2024
There was a problem hiding this comment.
LGTM
Two side-notes:
lightning-liquidity's LSPS1 support isn't functional yet, but we intend to at least get client-side support there real soon, so no harm it leaving it this way I think.- While it's currently of course a Rust crate with the main goal to support LSPS integration with LDK-based nodes, we intend to work towards making parts of it reusable with other implementations. E.g., initially others could at least reuse our Rust types and JSON de/serialzation, and, as a second step possibly even reuse (parts of) the client/service logic and interface with the modules through message queues that are independent from LDK internals.
SeverinAlexB
changed the title
|
You can add breez's lspd: |
ErikDeSmedt
added a commit
to ErikDeSmedt/lsp
that referenced
this pull request
Mar 4, 2024
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](BitcoinAndLightningLayerSpecs#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: BitcoinAndLightningLayerSpecs#92 See comment: BitcoinAndLightningLayerSpecs#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: BitcoinAndLightningLayerSpecs#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.
ErikDeSmedt
added a commit
to ErikDeSmedt/lsp
that referenced
this pull request
Mar 4, 2024
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](BitcoinAndLightningLayerSpecs#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: BitcoinAndLightningLayerSpecs#92 See comment: BitcoinAndLightningLayerSpecs#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: BitcoinAndLightningLayerSpecs#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.
ErikDeSmedt
added a commit
to ErikDeSmedt/lsp
that referenced
this pull request
Apr 22, 2024
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](BitcoinAndLightningLayerSpecs#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: BitcoinAndLightningLayerSpecs#92 See comment: BitcoinAndLightningLayerSpecs#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: BitcoinAndLightningLayerSpecs#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.
|
Closing because it has been added to the wiki. |
ErikDeSmedt
added a commit
to ErikDeSmedt/lsp
that referenced
this pull request
Jun 14, 2024
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](BitcoinAndLightningLayerSpecs#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: BitcoinAndLightningLayerSpecs#92 See comment: BitcoinAndLightningLayerSpecs#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: BitcoinAndLightningLayerSpecs#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.
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.
Adds implementations to the LSPSpec main readme. Closes #76.
FYI: @tnull @niteshbalusu11 @alexbosworth