Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

LSPS4 - Let the client optionally determine channel size #65

Open
SeverinAlexB opened this issue Nov 2, 2023 · 3 comments
Open

LSPS4 - Let the client optionally determine channel size #65

SeverinAlexB opened this issue Nov 2, 2023 · 3 comments

Comments

@SeverinAlexB
Copy link
Collaborator

At the moment, there is no option for the client in LSPS2 to determine the channel size. Our mental model so far was that the channel size is determined automatically by the LSP mostly based on the payment size. This is great for casual users but has detrimental effects in other cases.

Let me make an example:
Alice, the owner of a small bar, makes an average daily revenue of $2000. Her guests pay their bills with an average value of $20. So Alice receives 100x $20 payments over the course of the night. In the current LSPS2 model, the LSP opens multiple channels to Alice until she reaches her revenue of $2000 for the night. Worst case, this can be 100 channels (see example). More realistic, the LSP would probably open 20 channel with $100 capacity each. As each channel open is an onchain tx, LSPS2 gets very expensive.

My proposal therefore: The client should be able to determine the channel size optionally. By default, the LSP still determines the channel size but if the client wishes to do so, it should be able to.
This would only be a small change in the api (add channelSize to the lsps2.buy method) and a little validation logic on the backend and it would improve the user experience heavily, especially for merchants.

Let me know what you think. If you agree I'll create a PR.
@ZmnSCPxj-jr
Copy link
Contributor

This was discussed a little during LSPS2 and the consensus at the time was that the LSP is the one that should determine the amount of risk it is exposed to (= channel size).

If we wanted the client to determine the channel size, then the cost of the channel should be proportional to the size of the channel requested. The argument was this was not a natural way of thinking about cost for an average mobile-wallet user, who is interested in how much it costs to receive a payment, so instead of having the client determine the channel size and being charged for the channel size, it was modified to use the payment size and then fees are charged based on the payment size. The LSP would then scale the channel it creates based on the payment size and any factors it might have about the client.

#22 (comment)

@SeverinAlexB SeverinAlexB changed the title LSPS2 - Let the client optionally determine channel size LSPS4 - Let the client optionally determine channel size Nov 2, 2023
@SeverinAlexB
Copy link
Collaborator Author

In our spec meeting today, we decided to battle this issue in LSPS4. LSPS2 is too close to being finalized to introduce such a major change.

@SeverinAlexB
Copy link
Collaborator Author

Note: BTCPay Server is interested in such a feature. https://t.me/LSPstandards/4124

ErikDeSmedt added a commit to ErikDeSmedt/lsp that referenced this issue Mar 4, 2024
@ErikDeSmedt
LSPS1: Explicitly support LSPS1 payment options
9beaa9a 
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 issue Mar 4, 2024
@ErikDeSmedt
LSPS1: Explicitly support LSPS1 payment options
7516434 
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 ErikDeSmedt mentioned this issue Mar 4, 2024
Merged
ErikDeSmedt added a commit to ErikDeSmedt/lsp that referenced this issue Apr 22, 2024
@ErikDeSmedt
LSPS1: Explicitly support LSPS1 payment options
d38f75e 
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 issue Jun 14, 2024
@ErikDeSmedt
LSPS1: Explicitly support LSPS1 payment options
33a5410 
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 issue Jun 21, 2024
@ErikDeSmedt @tnull
LSPS1: Explicitly support LSPS1 payment options (#101)
76bc908 
* 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
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@SeverinAlexB @ZmnSCPxj-jr