Add bLIP 52: JIT Channel Negotiation (LSPS2)

[tnull]

Based on #52.

A "JIT Channel" is a channel opened in response to an incoming payment from the public network to a client, via the LSP.
This allows a client with no Lightning channels to start receiving on Lightning, and have the cost of their inbound liquidity be deducted from their first received payment.

The given protocol is based on LSPS0/blip-0050 and has been previously stabilized by the LSP Spec group and is live in production with several LSP and client implementations today.

As previously discussed on multiple occasions, the LSP Spec group is however moving to a bLIP-centric process, which is why we 'upstream' these previously-stabilized specifications here.

(cc the original author @ZmnSCPxj-jr)

[ZmnSCPxj-jr]

So.... what is the general process for getting this P.R. merged in?

[tnull]

So.... what is the general process for getting this P.R. merged in?

I think @t-bast recently mentioned he'd be interested in taking a look a these newly-opened PRs.

[t-bast]

I'll try to take a look at those new PRs soon. But I'd be interested in people reviewing my own pending PRs on this repository as well: doing some tit for tat helps motivate reviewers 🙏 (especially when reviewing PRs for stuff I'm not implementing).

[t-bast]

Same here, please add a link to a reference implementation.

It's still really surprising to me that you went ahead with a scheme like this instead of forwarding onions to recipients that don't have enough inbound capacity and really negotiating the channel at the time of the payment, like we were already doing in Phoenix before LSP specs started and like we specified in #36, but I guess that ship has sailed for this version (but I don't expect people to use this scheme in the future given its limitations?).

[tnull]

Same here, please add a link to a reference implementation.

Done!

It's still really surprising to me that you went ahead with a scheme like this instead of forwarding onions to recipients that don't have enough inbound capacity and really negotiating the channel at the time of the payment, like we were already doing in Phoenix before LSP specs started and like we specified in #36, but I guess that ship has sailed for this version

Well, there are a few different answers to this. Back then it was (and to be honest to a degree still is) unclear how/whether all implementations would be able to support a more complex protocol that requires low-level access to onion encryption, custom messages, etc. The given JIT flow is already a pretty complex protocol and the additional communication does not make it simpler. So the decision was made to go with the simpler version to first to get started, and then explore what else needs to be done (and what possibly even would take advocating for changes in the respective Lightning implementations).

(but I don't expect people to use this scheme in the future given its limitations?).

Yes, I think most people by now agree that longer term we probably end up needing the more complex version afterall (i.e., your proposed LiqAds JIT flow, plus maybe some extensions), but it will still take some time to fully spec it out and ship it. While we're now aware of some shortcomings of the LSPS2 approach, it should work for the most part in the meantime.

[tnull]

Rebased after #55 landed (and squashed one fixup).

[tnull]

Rebased on master to resolve some minor conflicts.

[tnull]

Based on #52.

A "JIT Channel" is a channel opened in response to an incoming payment from the public network to a client, via the LSP.
This allows a client with no Lightning channels to start receiving on Lightning, and have the cost of their inbound liquidity be deducted from their first received payment.

The given protocol is based on LSPS0/blip-0050 and has been previously stabilized by the LSP Spec group and is live in production with several LSP and client implementations today.

As previously discussed on multiple occasions, the LSP Spec group is however moving to a bLIP-centric process, which is why we 'upstream' these previously-stabilized specifications here.

(cc the original author @ZmnSCPxj-jr)

[ZmnSCPxj-jr]

So.... what is the general process for getting this P.R. merged in?

[tnull]

So.... what is the general process for getting this P.R. merged in?

I think @t-bast recently mentioned he'd be interested in taking a look a these newly-opened PRs.

[t-bast]

I'll try to take a look at those new PRs soon. But I'd be interested in people reviewing my own pending PRs on this repository as well: doing some tit for tat helps motivate reviewers 🙏 (especially when reviewing PRs for stuff I'm not implementing).

[t-bast]

Same here, please add a link to a reference implementation.

It's still really surprising to me that you went ahead with a scheme like this instead of forwarding onions to recipients that don't have enough inbound capacity and really negotiating the channel at the time of the payment, like we were already doing in Phoenix before LSP specs started and like we specified in #36, but I guess that ship has sailed for this version (but I don't expect people to use this scheme in the future given its limitations?).

[tnull]

Same here, please add a link to a reference implementation.

Done!

It's still really surprising to me that you went ahead with a scheme like this instead of forwarding onions to recipients that don't have enough inbound capacity and really negotiating the channel at the time of the payment, like we were already doing in Phoenix before LSP specs started and like we specified in #36, but I guess that ship has sailed for this version

Well, there are a few different answers to this. Back then it was (and to be honest to a degree still is) unclear how/whether all implementations would be able to support a more complex protocol that requires low-level access to onion encryption, custom messages, etc. The given JIT flow is already a pretty complex protocol and the additional communication does not make it simpler. So the decision was made to go with the simpler version to first to get started, and then explore what else needs to be done (and what possibly even would take advocating for changes in the respective Lightning implementations).

(but I don't expect people to use this scheme in the future given its limitations?).

Yes, I think most people by now agree that longer term we probably end up needing the more complex version afterall (i.e., your proposed LiqAds JIT flow, plus maybe some extensions), but it will still take some time to fully spec it out and ship it. While we're now aware of some shortcomings of the LSPS2 approach, it should work for the most part in the meantime.

[tnull]

Rebased after #55 landed (and squashed one fixup).

[tnull]

Rebased on master to resolve some minor conflicts.

[tnull]

Based on #52.

A "JIT Channel" is a channel opened in response to an incoming payment from the public network to a client, via the LSP.
This allows a client with no Lightning channels to start receiving on Lightning, and have the cost of their inbound liquidity be deducted from their first received payment.

The given protocol is based on LSPS0/blip-0050 and has been previously stabilized by the LSP Spec group and is live in production with several LSP and client implementations today.

As previously discussed on multiple occasions, the LSP Spec group is however moving to a bLIP-centric process, which is why we 'upstream' these previously-stabilized specifications here.

(cc the original author @ZmnSCPxj-jr)

[ZmnSCPxj-jr]

So.... what is the general process for getting this P.R. merged in?

[tnull]

So.... what is the general process for getting this P.R. merged in?

I think @t-bast recently mentioned he'd be interested in taking a look a these newly-opened PRs.

[t-bast]

I'll try to take a look at those new PRs soon. But I'd be interested in people reviewing my own pending PRs on this repository as well: doing some tit for tat helps motivate reviewers 🙏 (especially when reviewing PRs for stuff I'm not implementing).

[t-bast]

Same here, please add a link to a reference implementation.

It's still really surprising to me that you went ahead with a scheme like this instead of forwarding onions to recipients that don't have enough inbound capacity and really negotiating the channel at the time of the payment, like we were already doing in Phoenix before LSP specs started and like we specified in #36, but I guess that ship has sailed for this version (but I don't expect people to use this scheme in the future given its limitations?).

[tnull]

Same here, please add a link to a reference implementation.

Done!

It's still really surprising to me that you went ahead with a scheme like this instead of forwarding onions to recipients that don't have enough inbound capacity and really negotiating the channel at the time of the payment, like we were already doing in Phoenix before LSP specs started and like we specified in #36, but I guess that ship has sailed for this version

Well, there are a few different answers to this. Back then it was (and to be honest to a degree still is) unclear how/whether all implementations would be able to support a more complex protocol that requires low-level access to onion encryption, custom messages, etc. The given JIT flow is already a pretty complex protocol and the additional communication does not make it simpler. So the decision was made to go with the simpler version to first to get started, and then explore what else needs to be done (and what possibly even would take advocating for changes in the respective Lightning implementations).

(but I don't expect people to use this scheme in the future given its limitations?).

Yes, I think most people by now agree that longer term we probably end up needing the more complex version afterall (i.e., your proposed LiqAds JIT flow, plus maybe some extensions), but it will still take some time to fully spec it out and ship it. While we're now aware of some shortcomings of the LSPS2 approach, it should work for the most part in the meantime.

[tnull]

Rebased after #55 landed (and squashed one fixup).

[tnull]

Rebased on master to resolve some minor conflicts.

[tnull]

Based on #52.

A "JIT Channel" is a channel opened in response to an incoming payment from the public network to a client, via the LSP.
This allows a client with no Lightning channels to start receiving on Lightning, and have the cost of their inbound liquidity be deducted from their first received payment.

The given protocol is based on LSPS0/blip-0050 and has been previously stabilized by the LSP Spec group and is live in production with several LSP and client implementations today.

As previously discussed on multiple occasions, the LSP Spec group is however moving to a bLIP-centric process, which is why we 'upstream' these previously-stabilized specifications here.

(cc the original author @ZmnSCPxj-jr)

[ZmnSCPxj-jr]

So.... what is the general process for getting this P.R. merged in?

[tnull]

So.... what is the general process for getting this P.R. merged in?

I think @t-bast recently mentioned he'd be interested in taking a look a these newly-opened PRs.

[t-bast]

I'll try to take a look at those new PRs soon. But I'd be interested in people reviewing my own pending PRs on this repository as well: doing some tit for tat helps motivate reviewers 🙏 (especially when reviewing PRs for stuff I'm not implementing).

[t-bast]

Same here, please add a link to a reference implementation.

It's still really surprising to me that you went ahead with a scheme like this instead of forwarding onions to recipients that don't have enough inbound capacity and really negotiating the channel at the time of the payment, like we were already doing in Phoenix before LSP specs started and like we specified in #36, but I guess that ship has sailed for this version (but I don't expect people to use this scheme in the future given its limitations?).

[tnull]

Same here, please add a link to a reference implementation.

Done!

It's still really surprising to me that you went ahead with a scheme like this instead of forwarding onions to recipients that don't have enough inbound capacity and really negotiating the channel at the time of the payment, like we were already doing in Phoenix before LSP specs started and like we specified in #36, but I guess that ship has sailed for this version

Well, there are a few different answers to this. Back then it was (and to be honest to a degree still is) unclear how/whether all implementations would be able to support a more complex protocol that requires low-level access to onion encryption, custom messages, etc. The given JIT flow is already a pretty complex protocol and the additional communication does not make it simpler. So the decision was made to go with the simpler version to first to get started, and then explore what else needs to be done (and what possibly even would take advocating for changes in the respective Lightning implementations).

(but I don't expect people to use this scheme in the future given its limitations?).

Yes, I think most people by now agree that longer term we probably end up needing the more complex version afterall (i.e., your proposed LiqAds JIT flow, plus maybe some extensions), but it will still take some time to fully spec it out and ship it. While we're now aware of some shortcomings of the LSPS2 approach, it should work for the most part in the meantime.

[tnull]

Rebased after #55 landed (and squashed one fixup).

[tnull]

Rebased on master to resolve some minor conflicts.

[tnull]

Based on #52.

A "JIT Channel" is a channel opened in response to an incoming payment from the public network to a client, via the LSP.
This allows a client with no Lightning channels to start receiving on Lightning, and have the cost of their inbound liquidity be deducted from their first received payment.

The given protocol is based on LSPS0/blip-0050 and has been previously stabilized by the LSP Spec group and is live in production with several LSP and client implementations today.

As previously discussed on multiple occasions, the LSP Spec group is however moving to a bLIP-centric process, which is why we 'upstream' these previously-stabilized specifications here.

(cc the original author @ZmnSCPxj-jr)

[ZmnSCPxj-jr]

So.... what is the general process for getting this P.R. merged in?

[tnull]

So.... what is the general process for getting this P.R. merged in?

I think @t-bast recently mentioned he'd be interested in taking a look a these newly-opened PRs.

[t-bast]

I'll try to take a look at those new PRs soon. But I'd be interested in people reviewing my own pending PRs on this repository as well: doing some tit for tat helps motivate reviewers 🙏 (especially when reviewing PRs for stuff I'm not implementing).

[t-bast]

Same here, please add a link to a reference implementation.

It's still really surprising to me that you went ahead with a scheme like this instead of forwarding onions to recipients that don't have enough inbound capacity and really negotiating the channel at the time of the payment, like we were already doing in Phoenix before LSP specs started and like we specified in #36, but I guess that ship has sailed for this version (but I don't expect people to use this scheme in the future given its limitations?).

[tnull]

Same here, please add a link to a reference implementation.

Done!

It's still really surprising to me that you went ahead with a scheme like this instead of forwarding onions to recipients that don't have enough inbound capacity and really negotiating the channel at the time of the payment, like we were already doing in Phoenix before LSP specs started and like we specified in #36, but I guess that ship has sailed for this version

Well, there are a few different answers to this. Back then it was (and to be honest to a degree still is) unclear how/whether all implementations would be able to support a more complex protocol that requires low-level access to onion encryption, custom messages, etc. The given JIT flow is already a pretty complex protocol and the additional communication does not make it simpler. So the decision was made to go with the simpler version to first to get started, and then explore what else needs to be done (and what possibly even would take advocating for changes in the respective Lightning implementations).

(but I don't expect people to use this scheme in the future given its limitations?).

Yes, I think most people by now agree that longer term we probably end up needing the more complex version afterall (i.e., your proposed LiqAds JIT flow, plus maybe some extensions), but it will still take some time to fully spec it out and ship it. While we're now aware of some shortcomings of the LSPS2 approach, it should work for the most part in the meantime.

[tnull]

Rebased after #55 landed (and squashed one fixup).

[tnull]

Rebased on master to resolve some minor conflicts.

[tnull]

Based on #52.

A "JIT Channel" is a channel opened in response to an incoming payment from the public network to a client, via the LSP.
This allows a client with no Lightning channels to start receiving on Lightning, and have the cost of their inbound liquidity be deducted from their first received payment.

The given protocol is based on LSPS0/blip-0050 and has been previously stabilized by the LSP Spec group and is live in production with several LSP and client implementations today.

As previously discussed on multiple occasions, the LSP Spec group is however moving to a bLIP-centric process, which is why we 'upstream' these previously-stabilized specifications here.

(cc the original author @ZmnSCPxj-jr)

[ZmnSCPxj-jr]

So.... what is the general process for getting this P.R. merged in?

[tnull]

So.... what is the general process for getting this P.R. merged in?

I think @t-bast recently mentioned he'd be interested in taking a look a these newly-opened PRs.

[t-bast]

I'll try to take a look at those new PRs soon. But I'd be interested in people reviewing my own pending PRs on this repository as well: doing some tit for tat helps motivate reviewers 🙏 (especially when reviewing PRs for stuff I'm not implementing).

[t-bast]

Same here, please add a link to a reference implementation.

It's still really surprising to me that you went ahead with a scheme like this instead of forwarding onions to recipients that don't have enough inbound capacity and really negotiating the channel at the time of the payment, like we were already doing in Phoenix before LSP specs started and like we specified in #36, but I guess that ship has sailed for this version (but I don't expect people to use this scheme in the future given its limitations?).

[tnull]

Same here, please add a link to a reference implementation.

Done!

It's still really surprising to me that you went ahead with a scheme like this instead of forwarding onions to recipients that don't have enough inbound capacity and really negotiating the channel at the time of the payment, like we were already doing in Phoenix before LSP specs started and like we specified in #36, but I guess that ship has sailed for this version

Well, there are a few different answers to this. Back then it was (and to be honest to a degree still is) unclear how/whether all implementations would be able to support a more complex protocol that requires low-level access to onion encryption, custom messages, etc. The given JIT flow is already a pretty complex protocol and the additional communication does not make it simpler. So the decision was made to go with the simpler version to first to get started, and then explore what else needs to be done (and what possibly even would take advocating for changes in the respective Lightning implementations).

(but I don't expect people to use this scheme in the future given its limitations?).

Yes, I think most people by now agree that longer term we probably end up needing the more complex version afterall (i.e., your proposed LiqAds JIT flow, plus maybe some extensions), but it will still take some time to fully spec it out and ship it. While we're now aware of some shortcomings of the LSPS2 approach, it should work for the most part in the meantime.

[tnull]

Rebased after #55 landed (and squashed one fixup).

[tnull]

Rebased on master to resolve some minor conflicts.

[tnull]

Based on #52.

A "JIT Channel" is a channel opened in response to an incoming payment from the public network to a client, via the LSP.
This allows a client with no Lightning channels to start receiving on Lightning, and have the cost of their inbound liquidity be deducted from their first received payment.

The given protocol is based on LSPS0/blip-0050 and has been previously stabilized by the LSP Spec group and is live in production with several LSP and client implementations today.

As previously discussed on multiple occasions, the LSP Spec group is however moving to a bLIP-centric process, which is why we 'upstream' these previously-stabilized specifications here.

(cc the original author @ZmnSCPxj-jr)

[ZmnSCPxj-jr]

So.... what is the general process for getting this P.R. merged in?

[tnull]

So.... what is the general process for getting this P.R. merged in?

I think @t-bast recently mentioned he'd be interested in taking a look a these newly-opened PRs.

[t-bast]

I'll try to take a look at those new PRs soon. But I'd be interested in people reviewing my own pending PRs on this repository as well: doing some tit for tat helps motivate reviewers 🙏 (especially when reviewing PRs for stuff I'm not implementing).

[t-bast]

Same here, please add a link to a reference implementation.

It's still really surprising to me that you went ahead with a scheme like this instead of forwarding onions to recipients that don't have enough inbound capacity and really negotiating the channel at the time of the payment, like we were already doing in Phoenix before LSP specs started and like we specified in #36, but I guess that ship has sailed for this version (but I don't expect people to use this scheme in the future given its limitations?).

[tnull]

Same here, please add a link to a reference implementation.

Done!

It's still really surprising to me that you went ahead with a scheme like this instead of forwarding onions to recipients that don't have enough inbound capacity and really negotiating the channel at the time of the payment, like we were already doing in Phoenix before LSP specs started and like we specified in #36, but I guess that ship has sailed for this version

Well, there are a few different answers to this. Back then it was (and to be honest to a degree still is) unclear how/whether all implementations would be able to support a more complex protocol that requires low-level access to onion encryption, custom messages, etc. The given JIT flow is already a pretty complex protocol and the additional communication does not make it simpler. So the decision was made to go with the simpler version to first to get started, and then explore what else needs to be done (and what possibly even would take advocating for changes in the respective Lightning implementations).

(but I don't expect people to use this scheme in the future given its limitations?).

Yes, I think most people by now agree that longer term we probably end up needing the more complex version afterall (i.e., your proposed LiqAds JIT flow, plus maybe some extensions), but it will still take some time to fully spec it out and ship it. While we're now aware of some shortcomings of the LSPS2 approach, it should work for the most part in the meantime.

[tnull]

Rebased after #55 landed (and squashed one fixup).

[tnull]

Rebased on master to resolve some minor conflicts.

[tnull]

Based on #52.

A "JIT Channel" is a channel opened in response to an incoming payment from the public network to a client, via the LSP.
This allows a client with no Lightning channels to start receiving on Lightning, and have the cost of their inbound liquidity be deducted from their first received payment.

The given protocol is based on LSPS0/blip-0050 and has been previously stabilized by the LSP Spec group and is live in production with several LSP and client implementations today.

As previously discussed on multiple occasions, the LSP Spec group is however moving to a bLIP-centric process, which is why we 'upstream' these previously-stabilized specifications here.

(cc the original author @ZmnSCPxj-jr)

[ZmnSCPxj-jr]

So.... what is the general process for getting this P.R. merged in?

[tnull]

So.... what is the general process for getting this P.R. merged in?

I think @t-bast recently mentioned he'd be interested in taking a look a these newly-opened PRs.

[t-bast]

I'll try to take a look at those new PRs soon. But I'd be interested in people reviewing my own pending PRs on this repository as well: doing some tit for tat helps motivate reviewers 🙏 (especially when reviewing PRs for stuff I'm not implementing).

[t-bast]

Same here, please add a link to a reference implementation.

It's still really surprising to me that you went ahead with a scheme like this instead of forwarding onions to recipients that don't have enough inbound capacity and really negotiating the channel at the time of the payment, like we were already doing in Phoenix before LSP specs started and like we specified in #36, but I guess that ship has sailed for this version (but I don't expect people to use this scheme in the future given its limitations?).

[tnull]

Same here, please add a link to a reference implementation.

Done!

It's still really surprising to me that you went ahead with a scheme like this instead of forwarding onions to recipients that don't have enough inbound capacity and really negotiating the channel at the time of the payment, like we were already doing in Phoenix before LSP specs started and like we specified in #36, but I guess that ship has sailed for this version

Well, there are a few different answers to this. Back then it was (and to be honest to a degree still is) unclear how/whether all implementations would be able to support a more complex protocol that requires low-level access to onion encryption, custom messages, etc. The given JIT flow is already a pretty complex protocol and the additional communication does not make it simpler. So the decision was made to go with the simpler version to first to get started, and then explore what else needs to be done (and what possibly even would take advocating for changes in the respective Lightning implementations).

(but I don't expect people to use this scheme in the future given its limitations?).

Yes, I think most people by now agree that longer term we probably end up needing the more complex version afterall (i.e., your proposed LiqAds JIT flow, plus maybe some extensions), but it will still take some time to fully spec it out and ship it. While we're now aware of some shortcomings of the LSPS2 approach, it should work for the most part in the meantime.

[tnull]

Rebased after #55 landed (and squashed one fixup).

[tnull]

Rebased on master to resolve some minor conflicts.