Feature: Multi-Implementation Support

[carlaKC]

Add alternative implementations of LightningNode trait for:

• Core Lightning
• Eclair
• LDK Node

[carlaKC]

I'd suggest starting with CLN or LDK-node first, so those are likely the easiest.

[carlaKC]

CLN: https://crates.io/crates/cln-grpc ?

[okjodom]

New tasks. Blocked by incompleteness in CLN rpc types

• CLN track payment needs to report failure reason
• CLN track payment needs to report htlc count
  • fix: we use listpays number_of_parts where available, or default to 1

We use lightning-listpays rpc, from which we don't get either of the above response fields

[sr-gi]

New tasks. Blocked by incompleteness in CLN rpc types

• CLN track payment needs to report failure reason

• CLN track payment needs to report htlc count

  • fix: we use listpays number_of_parts where available, or default to 1

We use lightning-listpays rpc, from which we don't get either of the above response fields

Let me take a look at that payment error data and how to parse it

[carlaKC]

Taking a look at LND's failure codes - some are spec-defined and some are "user friendly"/LND specific:

Custom LND Errors

These are not related to spec failure_code, and are just additional information that LND API surfaces.

LND could not find a route (due to timeout / no route / no local liquidity):

• FAILURE_REASON_TIMEOUT PaymentFailureReason = 1
• FAILURE_REASON_NO_ROUTE PaymentFailureReason = 2
• FAILURE_REASON_INSUFFICIENT_BALANCE PaymentFailureReason = 5

Spec errors:

Spec failure codes related to the details for the final hop are represented by a single LND API value.

FAILURE_REASON_INCORRECT_PAYMENT_DETAILS PaymentFailureReason = 4 represents spec failure_codes:

• 18 / final_incorrect_cltv_expiry
• 19/ final_incorrect_htlc_amount

Any other failure code is expressed with a generic error value: FAILURE_REASON_ERROR PaymentFailureReason = 3

[carlaKC]

I think we're probably going to have to go with our own mapping - something like this:

PAYMENT_NOT_SENT represents:

• LND/FAILURE_REASON_TIMEOUT
• LND/FAILURE_REASON_NO_ROUTE
• LND/FAILURE_REASON_INSUFFICIENT_BALANCE

INCORRECT_DETAILS represents:

• LND/FAILURE_REASON_INCORRECT_PAYMENT_DETAILS
• failure_code / 18
• failure_code / 19

PAYMENT_FAILED represents:

• LND/FAILURE_REASON_ERROR
• failure_code/ any other value

[sr-gi]

For the record: ElementsProject/lightning#6634

[carlaKC]

Dropping this down to medium now that we have LND and CLN.

[sb1752]

So I spent some time looking into LDK-Node integration and wanted to share some of my findings here in case there were any suggestions before I move forward.

1. LDK-Node is in a library form and not a daemon with a CLI like LND or CLN. So the node needs to be configured, built and started within the code, rather than connected to as is done here with LND and CLN. I think that should be fine as it can be configured to point to an existing storage directory. So it can start up an existing node so long as it is not already running.
2. Setting up LDK-Node in a local regtest environment is a little tricky as there’s not very good documentation for that, it's not a daemon like LND, and it does not yet work with bitcoind (needs to connect to an esplora server for chain sync). I was eventually able to set it up and send/receive keysend payments between an LDK-Node and an LND node in regtest.
3. LDK-Node does not provide access to or customization of NodeFeatures. By default, the rust-lightning library sets the keysend_optional feature bit (55): https://github.com/lightningdevkit/rust-lightning/blob/3c9d88af2636422000402adb5aa4eab7c0845e81/lightning/src/ln/channelmanager.rs#L9490. One solution is to manually pass in the default NodeFeatures for Sim-LN.
4. Separately, however, it does not allow keysend payments for mpp. https://github.com/lightningdevkit/rust-lightning/blob/3c9d88af2636422000402adb5aa4eab7c0845e81/lightning/src/util/config.rs#L825.
5. For tracking payments, I would probably implement this the same as CLN, leveraging the list_payments method on the Node api, and waiting 500ms. However, the payment details don't return an HTLC count from my understanding. This is the extent of the details: https://docs.rs/ldk-node/latest/ldk_node/struct.PaymentDetails.html.

I'm working on a PR and that will provide more clarity on where other shortcomings / blockers might be, but thought I would just point this all out here in case you had any suggestions / concerns before I continue on.

[carlaKC]

Re 1 + 2:

While I'm not against our spinning up LDK nodes within Sim-LN some day, I don't really see it as a high priority if not yet pulled together into a usable daemon. Reasoning being that a) people probably aren't really using it right now if it's difficult to run and b) our value proposition is to add payment simulation to existing networks.

If you'd be interested, I think that working on eclair support would be a massive value add as it's one of the major players in the routing network and would be a great addition to be able to simulate more realistic networks.

That said, if the work of pulling together LDK node is minimal it could be something we could look - but I'd need some convincing tbh. Answers to the rest anyway:
3. Passing defaults in seems fine to me 👍
4. That's okay, I don't think that LND has MPP keysend either (we've already accepted that we have to add invoice based payments if we want MPP in sim-ln)
5. SGTM

[sb1752]

Got it thanks @carlaKC! That makes sense to me and I agree it's prob not ready at this stage to be considered. I was eager to play with it and see what it is about, so this was a good learning experience regardless. 👍