search

lightningdevkit / lightning-liquidity

Other
27 stars 17 forks source link

allow user selected user_channel_id #71

Closed johncantrell97 closed 10 months ago

johncantrell97 commented 11 months ago

Fixes #70

johncantrell97 commented 10 months ago

Hm, I'm generally wondering if we could switch to index everything by user_channel_id or intercept_id rather than scid. It seems the latter is really only ever necessary when constructing the BuyResponse, and using SCIDs in the interface is always confusing as it's unclear which one (real, inbound/outbound alias, intercept-scid) exactly is meant. I'm probably overlooking something here? Could we migrate away from tracking by SCID and just generate one when needed?

The issue is htlc intercepted only gives us scid and so it's the only way we can lookup what channel the htlc is for

tnull commented 10 months ago

Hm, I'm generally wondering if we could switch to index everything by user_channel_id or intercept_id rather than scid. It seems the latter is really only ever necessary when constructing the BuyResponse, and using SCIDs in the interface is always confusing as it's unclear which one (real, inbound/outbound alias, intercept-scid) exactly is meant. I'm probably overlooking something here? Could we migrate away from tracking by SCID and just generate one when needed?

The issue is htlc intercepted only gives us scid and so it's the only way we can lookup what channel the htlc is for

Mhh, it would also provide the intercept_id, but I see that that is probably not an option. Could we then at least do s/scid/intercept_scid/g or so in the whole LSPS2 project (and adjust comments) to make it really clear what scid the user needs to plug in here?

johncantrell97 commented 10 months ago

Hm, I'm generally wondering if we could switch to index everything by user_channel_id or intercept_id rather than scid. It seems the latter is really only ever necessary when constructing the BuyResponse, and using SCIDs in the interface is always confusing as it's unclear which one (real, inbound/outbound alias, intercept-scid) exactly is meant. I'm probably overlooking something here? Could we migrate away from tracking by SCID and just generate one when needed?

The issue is htlc intercepted only gives us scid and so it's the only way we can lookup what channel the htlc is for

Mhh, it would also provide the intercept_id, but I see that that is probably not an option. Could we then at least do s/scid/intercept_scid/g or so in the whole LSPS2 project (and adjust comments) to make it really clear what scid the user needs to plug in here?

Yeah I think calling it intercept_scid makes sense since that is what the method is called on ChannelManager that they need to use to generate it.

johncantrell97 commented 10 months ago

@tnull ok, renamed scid to intercept_scid

tnull commented 10 months ago

@tnull ok, renamed scid to intercept_scid

Thanks! It seems there are two instances of short_channel_id left that we might want to align while we're at it (?): in PendingPayment and invoice_params_received

johncantrell97 commented 10 months ago

@tnull ok, renamed scid to intercept_scid

Thanks! It seems there are two instances of short_channel_id left that we might want to align while we're at it (?): in PendingPayment and invoice_params_received

Thanks, got them.