If we just use 1 permanent SCID we don't need an expiry_time? In general, we could simplify the whole scid part of this spec enormously in case of only 1 permanent scid.

We do still need an expiry, for example if the client is trying to DoS and waste the storage of the LSP by reserving and then disconnecting forever. The LSP and the client need to agree on how long that period would be before the LSP can safely forget the client if the client never comes back again.

Why do we need to expire the permanent SCID? Can't we just use the same SCID for a node pubkey all the time?
In this case, I don't see how the client can DDoS the LSP as there is the same SCID returned every time.

In theory, the LSP can even derive the permanent SCID from the node pubkey. Of course, there needs to be a secret included so others can't guess the SCID.

Permanent SCID = hmac(client pubkey + lsp pubkey + randomLspSecret)?

In this case, I don't see how the client can DDoS the LSP as there is the same SCID returned every time.

A client can always generate a new node pubkey, you can literally treat the private key as a large 256-bit number and increment it each time, no need to even use a CSPRNG if you are just using throwaway keypairs for the purpose of DoS. With e.g. Tor or a botnet the IP address is not the same too.

Not sure I can follow. Let's discuss it on the call today.

Not resolved in previous call.

@SeverinAlexB proposes that an actual LSP implementation can use a 63-bit hash of the client node ID, so that the permanent SCID does not need to be remembered.

However, some software such as LDK has its own way of doing SCID interception. LDK gets "first dibs" at the data so LSPs built on top of LDK cannot change the way that LDK creates interception SCIDs.

In addition, something like a hash is a one-way function. So if the LSP receives an interception SCID, it has to iterate through all connected peers and hash each of their node IDs to get the SCID, then find the correct SCID. The LSP can cache this. However, how about disconnected peers? Ideally if the LSP receives an SCID for a peer that is disconnected, it would wake it up (e.g. via LSPS5). So LSP needs to remember the SCID->client mapping, and I think we need to nail down how long the mapping is retained by the LSP after the peer disconnects without making a channel.

Why remove this? Payer can only use MPP if payee (client in this context) supports it. In theory a payee can be simplified to the point that it does not support MPP at all, so it should signal whether it supports it or not. LSPs are forced to always consider the possibility of MPP, as this lets us also consider the case of multiple unrelated tiny payments by using all of them to fund a single channel open.

Ah, I thought this was a remnant of the LSPS2 spec. If the client doesn't support MPP, he can totally put that in the invoice, but I didn't think it was relevant for this spec, because it works regardless of MPP signaling or not.

I think this should be 'characters'. Why 24? Assuming a sha256 hash is a good identifier, you would get 64 hex characters here.

Anything finite is fine. Could go 64. Characters is fine too, as we specify ASCII and in ASCII 1 char = 1 byte.

Let's make it 64 then, to have the hash option.

Yeah this text talks about parts, not payments.

The PPP Map is an implementation detail. I think everything in the spec can be described with a PPP that is being held. In what data structure it is being held is not relevant to the spec.

"Map" is intended to be a very generic term, not a specific structure. It is just some mapping from PPP identifier to whatever internal details structure your node software needs.

Why is this important?
If the LSP crashes (or restarts), and the PPP identifier would be based on the internal htlc identifier of the lightning node, the flow could continue? The only downside I see is that LSP might send duplicate notifications for the same PPP.

Assuming the LSP is able to persist the PPP Map somehow.

In LDK, on restart any intercepted HTLCs are failed automatically with no way for the LSP code to re-send to the client. So we need to specify this (LDK-based LSPs cannot actually store the PPP Map).

(This is the main reason why we talk about the PPP Map, some software can recover on restart, some (LDK) cannot)

In LND the htlcs are replayed when reconnecting to the grpc stream.
In lspd (breez lsp implementation), we replay htlcs from CLN as well when lspd reconnects.

This allows for a 'stateless' handling of these htlcs. When the node restarts, lspd still has the same state, and ignores replayed htlcs. When lspd restarts, the htlcs are replayed and lspd can continue without remembering the previous state.

So maybe just change MUST to MAY here, in case the LSP can recover after crash.

It could be useful for the client to have the option to bypass the LSPS4 spec by issuing invoices with the real alias scid. In that case it is just a normal forward, without the PPP overhead.

Client can be simpler if it always just uses the LSPS4 SCID. It can issue invoices with 0 regard for current inbound liquidity, or if it issues multiple invoices (some of which may or may not be paid, e.g. merchant application) and does not want to have to allocate inbound liquidity to invoices.

For example, suppose the client currently has 1 unit of inbound. Then it issues two invoices of 1 unit each, with no assurance of whether or not it is going to get paid. If it used the "real" SCID then if both invoices are paid, then the second one will fail due to lack of capacity.

An LSP can ameliorate this by putting the second one in a PPP even though it did not use the LSPS4 SCID. This is equivalent to saying that "the real and/or alias SCID of a channel with a client is an alias of the LSPS4 SCID". But it is much much simpler to just say "client always uses the LSPS4 SCID" for implementation.

Say the client selects a new LSP to get its future channels from, it doesn't want new channels from the old LSP. It can still use the channel with the old LSP, by including a 'normal' hop hint in the invoice, and perhaps another hop hint for the new LSP.

Say the client selects a new LSP to get its future channels from, it doesn't want new channels from the old LSP. It can still use the channel with the old LSP, by including a 'normal' hop hint in the invoice, and perhaps another hop hint for the new LSP.

And the "normal" routehint in this case would be the result from lsps4.reserve_scid.

Next to the extra_fee TLV, every lsps4 update_add_htlc probably needs a ppp_id TLV, to correlate the actual HTLC with the PPP.

Why though? The PPP exists only as a way to implement onion oracles (where the oracle is the client). In the end an HTLC is an HTLC.

(boring) name suggestion:lsps4.new_ppp

But that is so boring.... "You have new mail!!!"

(boring) name suggestion: lsps4.fee_update

BOOOOOOOOOOORING :P

I was not able to find nd answer in LSPS0 so just asking here.

What is motivation behind

The value of that key is the JSON Boolean true.

instead of storing extension names in extensions array?

so that response will look like:

{
  "api_version": 1,
   "extensions": ["ephemeral_scids"]
}

or to allow extensions to have some parameterized "nuances", then something like:

{
  "api_version": 1,
   "extensions": [ { "name": "ephemeral_scids" }]
}

The later will allow for more extensibility while keeping the same data format also some more things can be added to lsps4.select_version if necessary.

For example in cases with different expiry_time (518400000 - 6 days), or updated fee rates

{
  "api_version": 1,
   "extensions": [ { 
        "name": "ephemeral_scids", 
         "expiry_time": 518400000,
         "ln_base_fee_msat": 10, 
         "ln_prop_fee": 1,
          "cltv_expiry_delta": 121
 }]
}

Also not sure where the mechanism for notification in case of https://github.com/BitcoinAndLightningLayerSpecs/lsp/blob/db0e99e8b65641a18c2d9b9fdf22c2dbae2af32d/LSPS4/README.md#lightning-forwarding-feerate-change are described