Update to LDK 0.0.121

[optout21]

Updated to LDK 0.0.121 and bitcoin library 0.30.2.
Also updated MSRV to 1.63, as LDK requires that (since 0.0.119).

Fixes#125 .

TODO:

• Fix issue of circular type dep SimpleArcPeerManager <-> GossipVerifier
• squash commits

Relevant changes in LDK:

• Added temporary_channel_id to create_channel. #2699
• Replace maze of BOLT11 payment utilities with parameter generators #2727
• Drop non-anchor channel fee upper bound limit entirely #2696
• Update to rust-bitcoin v0.30.2 #2740
• Add peer_id and channel_id explicitly to log records #2314
• Pass Record by value to Logger
• GossipVerifier now takes a PeerManager type (leads to circular type deps)
• Onion routing: signature of send_onion_message() has changed, path is not needed
• New ConectionNeeded event, ignored
• DefaultMessageRouter takes a network graph
• In WalletSource, sign_tx() has been changed to sign_psbt()
• Event processor process_events_async() has additional argument for fetching duration, constant 0 used here
• and some others

[orbitalturtle]

Just curious if this is still in the works :)

[optout21]

LDK 0.0.119 is available for some time now -- unless at the time of creation of this PR. However, more adaption is needed, TODO.

[tnull]

LDK 0.0.119 is available for some time now -- unless at the time of creation of this PR. However, more adaption is needed, TODO.

Right, but do you intend to go ahead with this PR? If not, I'd be happy to take it over and upgrade ldk-sample.

[optout21]

Yes, I plan to do this in next 1-2 days, but no hard commitment :D

[optout21]

I run into a small problem here:
I'm up to date till LDK Dec 5 cbde4a7
PR #2773 simplified GossipVerifier, which takes now a PeerManager type parameter, but our PeerManager takes a GossipVerifier, which creates a circular dependency in the types.
@tnull@TheBlueMatt

[tnull]

I run into a small problem here: I'm up to date till LDK Dec 5 cbde4a7 PR #2773 simplified GossipVerifier, which takes now a PeerManager type parameter, but our PeerManager takes a GossipVerifier, which creates a circular dependency in the types. @tnull@TheBlueMatt

Ugh, that might indeed be an issue we should fix upstream. Not sure if we need to find a (likely ugly) workaround here and roll it back, or wait for the upstream change though. @TheBlueMatt Any opinion on this?

[optout21]

I did a workaround, by creating a version of GossipVerifier without a PeerManager, called SimpleGossipVerifier, in a separate file. This workaround probably BREAKS functionality, and is ugly.
Rest of the adaptations are done, but the GossipVerifier issue has to be finalized.

[optout21]

Also mentioning @johncantrell97 , the author of #2773 .

[TheBlueMatt]

Ugh, thanks for doing this! Sorry it took a while to get back to this. We'll want to (partially) revert [#2773.](lightningdevkit/rust-lightning#2773.

[optout21]

Update: PR #2773 was partially reverted by PR #2822 .
It looks like LDK v0.0.119 will have to be skipped, and wait for v0.0.120.
I plan to check into the changes as required by current LDK main, post-2822.

[optout21]

LDK v0.0.120 has been released, includes #2822.
These changes should bring ldk-sample up to date with LDK v0.0.120 (and bitcoin 0.30.2)

[optout21]

There's one CI test failure, one dependency lib was not found, object 0.32.2, seems unrelated to changes here, in stable build there was no failure.

[optout21]

Bumped from 120 to 121.

[optout21]

Also updated minimal tested Rust version to 1.63, as LDK requires that now (since 0.0.119), and previously tested 1.48 caused some dependency issues (tokio 1.35.1, backtrace 0.3.69, object 0.32.2 does not work for 1.48).

[tnull]

LGTM, mod one unwrap I missed before (sorry for that).

[tnull]

@optout21 I think this should be very close to landing, mod the nits above.

[optout21]

@optout21 I think this should be very close to landing, mod the nits above.

Done now. Thanks for reminding, it slid lower in my to-do.

[tnull]

LGTM, thanks!

[domZippilli]

Hey, dunno if anyone will see this, but I was wondering if the team considered using payment_parameters_from_invoice for cli::send_payment implementation. That was introduced by @TheBlueMatt in #2727, and we're considering using it for our upgrade, but noticed it wasn't used here. The implementation of payment_parameters_from_invoice does seem to have some key differences from what ended up here, like unwraps and not as much specificity to errors, so I'm wondering if it was a conscious choice not to use it, or it was just overlooked.

[jkczyz]

Hey, dunno if anyone will see this, but I was wondering if the team considered using payment_parameters_from_invoice for cli::send_payment implementation. That was introduced by @TheBlueMatt in #2727, and we're considering using it for our upgrade, but noticed it wasn't used here. The implementation of payment_parameters_from_invoice does seem to have some key differences from what ended up here, like unwraps and not as much specificity to errors, so I'm wondering if it was a conscious choice not to use it, or it was just overlooked.

payment_parameters_from_invoice would be preferable. The error checking here is probably overkill. The unwraps in payment_parameters_from_invoice are fine because PaymentParameters has a Payee, and some methods are only applicable to certain types of Payees.

[optout21]

Updated to LDK 0.0.121 and bitcoin library 0.30.2.
Also updated MSRV to 1.63, as LDK requires that (since 0.0.119).

Fixes#125 .

TODO:

• Fix issue of circular type dep SimpleArcPeerManager <-> GossipVerifier
• squash commits

Relevant changes in LDK:

• Added temporary_channel_id to create_channel. #2699
• Replace maze of BOLT11 payment utilities with parameter generators #2727
• Drop non-anchor channel fee upper bound limit entirely #2696
• Update to rust-bitcoin v0.30.2 #2740
• Add peer_id and channel_id explicitly to log records #2314
• Pass Record by value to Logger
• GossipVerifier now takes a PeerManager type (leads to circular type deps)
• Onion routing: signature of send_onion_message() has changed, path is not needed
• New ConectionNeeded event, ignored
• DefaultMessageRouter takes a network graph
• In WalletSource, sign_tx() has been changed to sign_psbt()
• Event processor process_events_async() has additional argument for fetching duration, constant 0 used here
• and some others

[orbitalturtle]

Just curious if this is still in the works :)

[optout21]

LDK 0.0.119 is available for some time now -- unless at the time of creation of this PR. However, more adaption is needed, TODO.

[tnull]

LDK 0.0.119 is available for some time now -- unless at the time of creation of this PR. However, more adaption is needed, TODO.

Right, but do you intend to go ahead with this PR? If not, I'd be happy to take it over and upgrade ldk-sample.

[optout21]

Yes, I plan to do this in next 1-2 days, but no hard commitment :D

[optout21]

I run into a small problem here:
I'm up to date till LDK Dec 5 cbde4a7
PR #2773 simplified GossipVerifier, which takes now a PeerManager type parameter, but our PeerManager takes a GossipVerifier, which creates a circular dependency in the types.
@tnull@TheBlueMatt

[tnull]

I run into a small problem here: I'm up to date till LDK Dec 5 cbde4a7 PR #2773 simplified GossipVerifier, which takes now a PeerManager type parameter, but our PeerManager takes a GossipVerifier, which creates a circular dependency in the types. @tnull@TheBlueMatt

Ugh, that might indeed be an issue we should fix upstream. Not sure if we need to find a (likely ugly) workaround here and roll it back, or wait for the upstream change though. @TheBlueMatt Any opinion on this?

[optout21]

I did a workaround, by creating a version of GossipVerifier without a PeerManager, called SimpleGossipVerifier, in a separate file. This workaround probably BREAKS functionality, and is ugly.
Rest of the adaptations are done, but the GossipVerifier issue has to be finalized.

[optout21]

Also mentioning @johncantrell97 , the author of #2773 .

[TheBlueMatt]

Ugh, thanks for doing this! Sorry it took a while to get back to this. We'll want to (partially) revert [#2773.](lightningdevkit/rust-lightning#2773.

[optout21]

Update: PR #2773 was partially reverted by PR #2822 .
It looks like LDK v0.0.119 will have to be skipped, and wait for v0.0.120.
I plan to check into the changes as required by current LDK main, post-2822.

[optout21]

LDK v0.0.120 has been released, includes #2822.
These changes should bring ldk-sample up to date with LDK v0.0.120 (and bitcoin 0.30.2)

[optout21]

There's one CI test failure, one dependency lib was not found, object 0.32.2, seems unrelated to changes here, in stable build there was no failure.

[optout21]

Bumped from 120 to 121.

[optout21]

Also updated minimal tested Rust version to 1.63, as LDK requires that now (since 0.0.119), and previously tested 1.48 caused some dependency issues (tokio 1.35.1, backtrace 0.3.69, object 0.32.2 does not work for 1.48).

[tnull]

LGTM, mod one unwrap I missed before (sorry for that).

[tnull]

@optout21 I think this should be very close to landing, mod the nits above.

[optout21]

@optout21 I think this should be very close to landing, mod the nits above.

Done now. Thanks for reminding, it slid lower in my to-do.

[tnull]

LGTM, thanks!

[domZippilli]

Hey, dunno if anyone will see this, but I was wondering if the team considered using payment_parameters_from_invoice for cli::send_payment implementation. That was introduced by @TheBlueMatt in #2727, and we're considering using it for our upgrade, but noticed it wasn't used here. The implementation of payment_parameters_from_invoice does seem to have some key differences from what ended up here, like unwraps and not as much specificity to errors, so I'm wondering if it was a conscious choice not to use it, or it was just overlooked.

[jkczyz]

Hey, dunno if anyone will see this, but I was wondering if the team considered using payment_parameters_from_invoice for cli::send_payment implementation. That was introduced by @TheBlueMatt in #2727, and we're considering using it for our upgrade, but noticed it wasn't used here. The implementation of payment_parameters_from_invoice does seem to have some key differences from what ended up here, like unwraps and not as much specificity to errors, so I'm wondering if it was a conscious choice not to use it, or it was just overlooked.

payment_parameters_from_invoice would be preferable. The error checking here is probably overkill. The unwraps in payment_parameters_from_invoice are fine because PaymentParameters has a Payee, and some methods are only applicable to certain types of Payees.

[optout21]

Updated to LDK 0.0.121 and bitcoin library 0.30.2.
Also updated MSRV to 1.63, as LDK requires that (since 0.0.119).

Fixes#125 .

TODO:

• Fix issue of circular type dep SimpleArcPeerManager <-> GossipVerifier
• squash commits

Relevant changes in LDK:

• Added temporary_channel_id to create_channel. #2699
• Replace maze of BOLT11 payment utilities with parameter generators #2727
• Drop non-anchor channel fee upper bound limit entirely #2696
• Update to rust-bitcoin v0.30.2 #2740
• Add peer_id and channel_id explicitly to log records #2314
• Pass Record by value to Logger
• GossipVerifier now takes a PeerManager type (leads to circular type deps)
• Onion routing: signature of send_onion_message() has changed, path is not needed
• New ConectionNeeded event, ignored
• DefaultMessageRouter takes a network graph
• In WalletSource, sign_tx() has been changed to sign_psbt()
• Event processor process_events_async() has additional argument for fetching duration, constant 0 used here
• and some others

[orbitalturtle]

Just curious if this is still in the works :)

[optout21]

LDK 0.0.119 is available for some time now -- unless at the time of creation of this PR. However, more adaption is needed, TODO.

[tnull]

LDK 0.0.119 is available for some time now -- unless at the time of creation of this PR. However, more adaption is needed, TODO.

Right, but do you intend to go ahead with this PR? If not, I'd be happy to take it over and upgrade ldk-sample.

[optout21]

Yes, I plan to do this in next 1-2 days, but no hard commitment :D

[optout21]

I run into a small problem here:
I'm up to date till LDK Dec 5 cbde4a7
PR #2773 simplified GossipVerifier, which takes now a PeerManager type parameter, but our PeerManager takes a GossipVerifier, which creates a circular dependency in the types.
@tnull@TheBlueMatt

[tnull]

I run into a small problem here: I'm up to date till LDK Dec 5 cbde4a7 PR #2773 simplified GossipVerifier, which takes now a PeerManager type parameter, but our PeerManager takes a GossipVerifier, which creates a circular dependency in the types. @tnull@TheBlueMatt

Ugh, that might indeed be an issue we should fix upstream. Not sure if we need to find a (likely ugly) workaround here and roll it back, or wait for the upstream change though. @TheBlueMatt Any opinion on this?

[optout21]

I did a workaround, by creating a version of GossipVerifier without a PeerManager, called SimpleGossipVerifier, in a separate file. This workaround probably BREAKS functionality, and is ugly.
Rest of the adaptations are done, but the GossipVerifier issue has to be finalized.

[optout21]

Also mentioning @johncantrell97 , the author of #2773 .

[TheBlueMatt]

Ugh, thanks for doing this! Sorry it took a while to get back to this. We'll want to (partially) revert [#2773.](lightningdevkit/rust-lightning#2773.

[optout21]

Update: PR #2773 was partially reverted by PR #2822 .
It looks like LDK v0.0.119 will have to be skipped, and wait for v0.0.120.
I plan to check into the changes as required by current LDK main, post-2822.

[optout21]

LDK v0.0.120 has been released, includes #2822.
These changes should bring ldk-sample up to date with LDK v0.0.120 (and bitcoin 0.30.2)

[optout21]

There's one CI test failure, one dependency lib was not found, object 0.32.2, seems unrelated to changes here, in stable build there was no failure.

[optout21]

Bumped from 120 to 121.

[optout21]

Also updated minimal tested Rust version to 1.63, as LDK requires that now (since 0.0.119), and previously tested 1.48 caused some dependency issues (tokio 1.35.1, backtrace 0.3.69, object 0.32.2 does not work for 1.48).

[tnull]

LGTM, mod one unwrap I missed before (sorry for that).

[tnull]

@optout21 I think this should be very close to landing, mod the nits above.

[optout21]

@optout21 I think this should be very close to landing, mod the nits above.

Done now. Thanks for reminding, it slid lower in my to-do.

[tnull]

LGTM, thanks!

[domZippilli]

Hey, dunno if anyone will see this, but I was wondering if the team considered using payment_parameters_from_invoice for cli::send_payment implementation. That was introduced by @TheBlueMatt in #2727, and we're considering using it for our upgrade, but noticed it wasn't used here. The implementation of payment_parameters_from_invoice does seem to have some key differences from what ended up here, like unwraps and not as much specificity to errors, so I'm wondering if it was a conscious choice not to use it, or it was just overlooked.

[jkczyz]

Hey, dunno if anyone will see this, but I was wondering if the team considered using payment_parameters_from_invoice for cli::send_payment implementation. That was introduced by @TheBlueMatt in #2727, and we're considering using it for our upgrade, but noticed it wasn't used here. The implementation of payment_parameters_from_invoice does seem to have some key differences from what ended up here, like unwraps and not as much specificity to errors, so I'm wondering if it was a conscious choice not to use it, or it was just overlooked.

payment_parameters_from_invoice would be preferable. The error checking here is probably overkill. The unwraps in payment_parameters_from_invoice are fine because PaymentParameters has a Payee, and some methods are only applicable to certain types of Payees.

[optout21]

Updated to LDK 0.0.121 and bitcoin library 0.30.2.
Also updated MSRV to 1.63, as LDK requires that (since 0.0.119).

Fixes#125 .

TODO:

• Fix issue of circular type dep SimpleArcPeerManager <-> GossipVerifier
• squash commits

Relevant changes in LDK:

• Added temporary_channel_id to create_channel. #2699
• Replace maze of BOLT11 payment utilities with parameter generators #2727
• Drop non-anchor channel fee upper bound limit entirely #2696
• Update to rust-bitcoin v0.30.2 #2740
• Add peer_id and channel_id explicitly to log records #2314
• Pass Record by value to Logger
• GossipVerifier now takes a PeerManager type (leads to circular type deps)
• Onion routing: signature of send_onion_message() has changed, path is not needed
• New ConectionNeeded event, ignored
• DefaultMessageRouter takes a network graph
• In WalletSource, sign_tx() has been changed to sign_psbt()
• Event processor process_events_async() has additional argument for fetching duration, constant 0 used here
• and some others

[orbitalturtle]

Just curious if this is still in the works :)

[optout21]

LDK 0.0.119 is available for some time now -- unless at the time of creation of this PR. However, more adaption is needed, TODO.

[tnull]

LDK 0.0.119 is available for some time now -- unless at the time of creation of this PR. However, more adaption is needed, TODO.

Right, but do you intend to go ahead with this PR? If not, I'd be happy to take it over and upgrade ldk-sample.

[optout21]

Yes, I plan to do this in next 1-2 days, but no hard commitment :D

[optout21]

I run into a small problem here:
I'm up to date till LDK Dec 5 cbde4a7
PR #2773 simplified GossipVerifier, which takes now a PeerManager type parameter, but our PeerManager takes a GossipVerifier, which creates a circular dependency in the types.
@tnull@TheBlueMatt

[tnull]

I run into a small problem here: I'm up to date till LDK Dec 5 cbde4a7 PR #2773 simplified GossipVerifier, which takes now a PeerManager type parameter, but our PeerManager takes a GossipVerifier, which creates a circular dependency in the types. @tnull@TheBlueMatt

Ugh, that might indeed be an issue we should fix upstream. Not sure if we need to find a (likely ugly) workaround here and roll it back, or wait for the upstream change though. @TheBlueMatt Any opinion on this?

[optout21]

I did a workaround, by creating a version of GossipVerifier without a PeerManager, called SimpleGossipVerifier, in a separate file. This workaround probably BREAKS functionality, and is ugly.
Rest of the adaptations are done, but the GossipVerifier issue has to be finalized.

[optout21]

Also mentioning @johncantrell97 , the author of #2773 .

[TheBlueMatt]

Ugh, thanks for doing this! Sorry it took a while to get back to this. We'll want to (partially) revert [#2773.](lightningdevkit/rust-lightning#2773.

[optout21]

Update: PR #2773 was partially reverted by PR #2822 .
It looks like LDK v0.0.119 will have to be skipped, and wait for v0.0.120.
I plan to check into the changes as required by current LDK main, post-2822.

[optout21]

LDK v0.0.120 has been released, includes #2822.
These changes should bring ldk-sample up to date with LDK v0.0.120 (and bitcoin 0.30.2)

[optout21]

There's one CI test failure, one dependency lib was not found, object 0.32.2, seems unrelated to changes here, in stable build there was no failure.

[optout21]

Bumped from 120 to 121.

[optout21]

Also updated minimal tested Rust version to 1.63, as LDK requires that now (since 0.0.119), and previously tested 1.48 caused some dependency issues (tokio 1.35.1, backtrace 0.3.69, object 0.32.2 does not work for 1.48).

[tnull]

LGTM, mod one unwrap I missed before (sorry for that).

[tnull]

@optout21 I think this should be very close to landing, mod the nits above.

[optout21]

@optout21 I think this should be very close to landing, mod the nits above.

Done now. Thanks for reminding, it slid lower in my to-do.

[tnull]

LGTM, thanks!

[domZippilli]

Hey, dunno if anyone will see this, but I was wondering if the team considered using payment_parameters_from_invoice for cli::send_payment implementation. That was introduced by @TheBlueMatt in #2727, and we're considering using it for our upgrade, but noticed it wasn't used here. The implementation of payment_parameters_from_invoice does seem to have some key differences from what ended up here, like unwraps and not as much specificity to errors, so I'm wondering if it was a conscious choice not to use it, or it was just overlooked.

[jkczyz]

Hey, dunno if anyone will see this, but I was wondering if the team considered using payment_parameters_from_invoice for cli::send_payment implementation. That was introduced by @TheBlueMatt in #2727, and we're considering using it for our upgrade, but noticed it wasn't used here. The implementation of payment_parameters_from_invoice does seem to have some key differences from what ended up here, like unwraps and not as much specificity to errors, so I'm wondering if it was a conscious choice not to use it, or it was just overlooked.

payment_parameters_from_invoice would be preferable. The error checking here is probably overkill. The unwraps in payment_parameters_from_invoice are fine because PaymentParameters has a Payee, and some methods are only applicable to certain types of Payees.

[optout21]

Updated to LDK 0.0.121 and bitcoin library 0.30.2.
Also updated MSRV to 1.63, as LDK requires that (since 0.0.119).

Fixes#125 .

TODO:

• Fix issue of circular type dep SimpleArcPeerManager <-> GossipVerifier
• squash commits

Relevant changes in LDK:

• Added temporary_channel_id to create_channel. #2699
• Replace maze of BOLT11 payment utilities with parameter generators #2727
• Drop non-anchor channel fee upper bound limit entirely #2696
• Update to rust-bitcoin v0.30.2 #2740
• Add peer_id and channel_id explicitly to log records #2314
• Pass Record by value to Logger
• GossipVerifier now takes a PeerManager type (leads to circular type deps)
• Onion routing: signature of send_onion_message() has changed, path is not needed
• New ConectionNeeded event, ignored
• DefaultMessageRouter takes a network graph
• In WalletSource, sign_tx() has been changed to sign_psbt()
• Event processor process_events_async() has additional argument for fetching duration, constant 0 used here
• and some others

[orbitalturtle]

Just curious if this is still in the works :)

[optout21]

LDK 0.0.119 is available for some time now -- unless at the time of creation of this PR. However, more adaption is needed, TODO.

[tnull]

LDK 0.0.119 is available for some time now -- unless at the time of creation of this PR. However, more adaption is needed, TODO.

Right, but do you intend to go ahead with this PR? If not, I'd be happy to take it over and upgrade ldk-sample.

[optout21]

Yes, I plan to do this in next 1-2 days, but no hard commitment :D

[optout21]

I run into a small problem here:
I'm up to date till LDK Dec 5 cbde4a7
PR #2773 simplified GossipVerifier, which takes now a PeerManager type parameter, but our PeerManager takes a GossipVerifier, which creates a circular dependency in the types.
@tnull@TheBlueMatt

[tnull]

I run into a small problem here: I'm up to date till LDK Dec 5 cbde4a7 PR #2773 simplified GossipVerifier, which takes now a PeerManager type parameter, but our PeerManager takes a GossipVerifier, which creates a circular dependency in the types. @tnull@TheBlueMatt

Ugh, that might indeed be an issue we should fix upstream. Not sure if we need to find a (likely ugly) workaround here and roll it back, or wait for the upstream change though. @TheBlueMatt Any opinion on this?

[optout21]

I did a workaround, by creating a version of GossipVerifier without a PeerManager, called SimpleGossipVerifier, in a separate file. This workaround probably BREAKS functionality, and is ugly.
Rest of the adaptations are done, but the GossipVerifier issue has to be finalized.

[optout21]

Also mentioning @johncantrell97 , the author of #2773 .

[TheBlueMatt]

Ugh, thanks for doing this! Sorry it took a while to get back to this. We'll want to (partially) revert [#2773.](lightningdevkit/rust-lightning#2773.

[optout21]

Update: PR #2773 was partially reverted by PR #2822 .
It looks like LDK v0.0.119 will have to be skipped, and wait for v0.0.120.
I plan to check into the changes as required by current LDK main, post-2822.

[optout21]

LDK v0.0.120 has been released, includes #2822.
These changes should bring ldk-sample up to date with LDK v0.0.120 (and bitcoin 0.30.2)

[optout21]

There's one CI test failure, one dependency lib was not found, object 0.32.2, seems unrelated to changes here, in stable build there was no failure.

[optout21]

Bumped from 120 to 121.

[optout21]

Also updated minimal tested Rust version to 1.63, as LDK requires that now (since 0.0.119), and previously tested 1.48 caused some dependency issues (tokio 1.35.1, backtrace 0.3.69, object 0.32.2 does not work for 1.48).

[tnull]

LGTM, mod one unwrap I missed before (sorry for that).

[tnull]

@optout21 I think this should be very close to landing, mod the nits above.

[optout21]

@optout21 I think this should be very close to landing, mod the nits above.

Done now. Thanks for reminding, it slid lower in my to-do.

[tnull]

LGTM, thanks!

[domZippilli]

Hey, dunno if anyone will see this, but I was wondering if the team considered using payment_parameters_from_invoice for cli::send_payment implementation. That was introduced by @TheBlueMatt in #2727, and we're considering using it for our upgrade, but noticed it wasn't used here. The implementation of payment_parameters_from_invoice does seem to have some key differences from what ended up here, like unwraps and not as much specificity to errors, so I'm wondering if it was a conscious choice not to use it, or it was just overlooked.

[jkczyz]

Hey, dunno if anyone will see this, but I was wondering if the team considered using payment_parameters_from_invoice for cli::send_payment implementation. That was introduced by @TheBlueMatt in #2727, and we're considering using it for our upgrade, but noticed it wasn't used here. The implementation of payment_parameters_from_invoice does seem to have some key differences from what ended up here, like unwraps and not as much specificity to errors, so I'm wondering if it was a conscious choice not to use it, or it was just overlooked.

payment_parameters_from_invoice would be preferable. The error checking here is probably overkill. The unwraps in payment_parameters_from_invoice are fine because PaymentParameters has a Payee, and some methods are only applicable to certain types of Payees.

[optout21]

Updated to LDK 0.0.121 and bitcoin library 0.30.2.
Also updated MSRV to 1.63, as LDK requires that (since 0.0.119).

Fixes#125 .

TODO:

• Fix issue of circular type dep SimpleArcPeerManager <-> GossipVerifier
• squash commits

Relevant changes in LDK:

• Added temporary_channel_id to create_channel. #2699
• Replace maze of BOLT11 payment utilities with parameter generators #2727
• Drop non-anchor channel fee upper bound limit entirely #2696
• Update to rust-bitcoin v0.30.2 #2740
• Add peer_id and channel_id explicitly to log records #2314
• Pass Record by value to Logger
• GossipVerifier now takes a PeerManager type (leads to circular type deps)
• Onion routing: signature of send_onion_message() has changed, path is not needed
• New ConectionNeeded event, ignored
• DefaultMessageRouter takes a network graph
• In WalletSource, sign_tx() has been changed to sign_psbt()
• Event processor process_events_async() has additional argument for fetching duration, constant 0 used here
• and some others

[orbitalturtle]

Just curious if this is still in the works :)

[optout21]

LDK 0.0.119 is available for some time now -- unless at the time of creation of this PR. However, more adaption is needed, TODO.

[tnull]

LDK 0.0.119 is available for some time now -- unless at the time of creation of this PR. However, more adaption is needed, TODO.

Right, but do you intend to go ahead with this PR? If not, I'd be happy to take it over and upgrade ldk-sample.

[optout21]

Yes, I plan to do this in next 1-2 days, but no hard commitment :D

[optout21]

I run into a small problem here:
I'm up to date till LDK Dec 5 cbde4a7
PR #2773 simplified GossipVerifier, which takes now a PeerManager type parameter, but our PeerManager takes a GossipVerifier, which creates a circular dependency in the types.
@tnull@TheBlueMatt

[tnull]

I run into a small problem here: I'm up to date till LDK Dec 5 cbde4a7 PR #2773 simplified GossipVerifier, which takes now a PeerManager type parameter, but our PeerManager takes a GossipVerifier, which creates a circular dependency in the types. @tnull@TheBlueMatt

Ugh, that might indeed be an issue we should fix upstream. Not sure if we need to find a (likely ugly) workaround here and roll it back, or wait for the upstream change though. @TheBlueMatt Any opinion on this?

[optout21]

I did a workaround, by creating a version of GossipVerifier without a PeerManager, called SimpleGossipVerifier, in a separate file. This workaround probably BREAKS functionality, and is ugly.
Rest of the adaptations are done, but the GossipVerifier issue has to be finalized.

[optout21]

Also mentioning @johncantrell97 , the author of #2773 .

[TheBlueMatt]

Ugh, thanks for doing this! Sorry it took a while to get back to this. We'll want to (partially) revert [#2773.](lightningdevkit/rust-lightning#2773.

[optout21]

Update: PR #2773 was partially reverted by PR #2822 .
It looks like LDK v0.0.119 will have to be skipped, and wait for v0.0.120.
I plan to check into the changes as required by current LDK main, post-2822.

[optout21]

LDK v0.0.120 has been released, includes #2822.
These changes should bring ldk-sample up to date with LDK v0.0.120 (and bitcoin 0.30.2)

[optout21]

There's one CI test failure, one dependency lib was not found, object 0.32.2, seems unrelated to changes here, in stable build there was no failure.

[optout21]

Bumped from 120 to 121.

[optout21]

Also updated minimal tested Rust version to 1.63, as LDK requires that now (since 0.0.119), and previously tested 1.48 caused some dependency issues (tokio 1.35.1, backtrace 0.3.69, object 0.32.2 does not work for 1.48).

[tnull]

LGTM, mod one unwrap I missed before (sorry for that).

[tnull]

@optout21 I think this should be very close to landing, mod the nits above.

[optout21]

@optout21 I think this should be very close to landing, mod the nits above.

Done now. Thanks for reminding, it slid lower in my to-do.

[tnull]

LGTM, thanks!

[domZippilli]

Hey, dunno if anyone will see this, but I was wondering if the team considered using payment_parameters_from_invoice for cli::send_payment implementation. That was introduced by @TheBlueMatt in #2727, and we're considering using it for our upgrade, but noticed it wasn't used here. The implementation of payment_parameters_from_invoice does seem to have some key differences from what ended up here, like unwraps and not as much specificity to errors, so I'm wondering if it was a conscious choice not to use it, or it was just overlooked.

[jkczyz]

Hey, dunno if anyone will see this, but I was wondering if the team considered using payment_parameters_from_invoice for cli::send_payment implementation. That was introduced by @TheBlueMatt in #2727, and we're considering using it for our upgrade, but noticed it wasn't used here. The implementation of payment_parameters_from_invoice does seem to have some key differences from what ended up here, like unwraps and not as much specificity to errors, so I'm wondering if it was a conscious choice not to use it, or it was just overlooked.

payment_parameters_from_invoice would be preferable. The error checking here is probably overkill. The unwraps in payment_parameters_from_invoice are fine because PaymentParameters has a Payee, and some methods are only applicable to certain types of Payees.

[optout21]

Updated to LDK 0.0.121 and bitcoin library 0.30.2.
Also updated MSRV to 1.63, as LDK requires that (since 0.0.119).

Fixes#125 .

TODO:

• Fix issue of circular type dep SimpleArcPeerManager <-> GossipVerifier
• squash commits

Relevant changes in LDK:

• Added temporary_channel_id to create_channel. #2699
• Replace maze of BOLT11 payment utilities with parameter generators #2727
• Drop non-anchor channel fee upper bound limit entirely #2696
• Update to rust-bitcoin v0.30.2 #2740
• Add peer_id and channel_id explicitly to log records #2314
• Pass Record by value to Logger
• GossipVerifier now takes a PeerManager type (leads to circular type deps)
• Onion routing: signature of send_onion_message() has changed, path is not needed
• New ConectionNeeded event, ignored
• DefaultMessageRouter takes a network graph
• In WalletSource, sign_tx() has been changed to sign_psbt()
• Event processor process_events_async() has additional argument for fetching duration, constant 0 used here
• and some others

[orbitalturtle]

Just curious if this is still in the works :)

[optout21]

LDK 0.0.119 is available for some time now -- unless at the time of creation of this PR. However, more adaption is needed, TODO.

[tnull]

LDK 0.0.119 is available for some time now -- unless at the time of creation of this PR. However, more adaption is needed, TODO.

Right, but do you intend to go ahead with this PR? If not, I'd be happy to take it over and upgrade ldk-sample.

[optout21]

Yes, I plan to do this in next 1-2 days, but no hard commitment :D

[optout21]

I run into a small problem here:
I'm up to date till LDK Dec 5 cbde4a7
PR #2773 simplified GossipVerifier, which takes now a PeerManager type parameter, but our PeerManager takes a GossipVerifier, which creates a circular dependency in the types.
@tnull@TheBlueMatt

[tnull]

I run into a small problem here: I'm up to date till LDK Dec 5 cbde4a7 PR #2773 simplified GossipVerifier, which takes now a PeerManager type parameter, but our PeerManager takes a GossipVerifier, which creates a circular dependency in the types. @tnull@TheBlueMatt

Ugh, that might indeed be an issue we should fix upstream. Not sure if we need to find a (likely ugly) workaround here and roll it back, or wait for the upstream change though. @TheBlueMatt Any opinion on this?

[optout21]

I did a workaround, by creating a version of GossipVerifier without a PeerManager, called SimpleGossipVerifier, in a separate file. This workaround probably BREAKS functionality, and is ugly.
Rest of the adaptations are done, but the GossipVerifier issue has to be finalized.

[optout21]

Also mentioning @johncantrell97 , the author of #2773 .

[TheBlueMatt]

Ugh, thanks for doing this! Sorry it took a while to get back to this. We'll want to (partially) revert [#2773.](lightningdevkit/rust-lightning#2773.

[optout21]

Update: PR #2773 was partially reverted by PR #2822 .
It looks like LDK v0.0.119 will have to be skipped, and wait for v0.0.120.
I plan to check into the changes as required by current LDK main, post-2822.

[optout21]

LDK v0.0.120 has been released, includes #2822.
These changes should bring ldk-sample up to date with LDK v0.0.120 (and bitcoin 0.30.2)

[optout21]

There's one CI test failure, one dependency lib was not found, object 0.32.2, seems unrelated to changes here, in stable build there was no failure.

[optout21]

Bumped from 120 to 121.

[optout21]

Also updated minimal tested Rust version to 1.63, as LDK requires that now (since 0.0.119), and previously tested 1.48 caused some dependency issues (tokio 1.35.1, backtrace 0.3.69, object 0.32.2 does not work for 1.48).

[tnull]

LGTM, mod one unwrap I missed before (sorry for that).

[tnull]

@optout21 I think this should be very close to landing, mod the nits above.

[optout21]

@optout21 I think this should be very close to landing, mod the nits above.

Done now. Thanks for reminding, it slid lower in my to-do.

[tnull]

LGTM, thanks!

[domZippilli]

Hey, dunno if anyone will see this, but I was wondering if the team considered using payment_parameters_from_invoice for cli::send_payment implementation. That was introduced by @TheBlueMatt in #2727, and we're considering using it for our upgrade, but noticed it wasn't used here. The implementation of payment_parameters_from_invoice does seem to have some key differences from what ended up here, like unwraps and not as much specificity to errors, so I'm wondering if it was a conscious choice not to use it, or it was just overlooked.

[jkczyz]

Hey, dunno if anyone will see this, but I was wondering if the team considered using payment_parameters_from_invoice for cli::send_payment implementation. That was introduced by @TheBlueMatt in #2727, and we're considering using it for our upgrade, but noticed it wasn't used here. The implementation of payment_parameters_from_invoice does seem to have some key differences from what ended up here, like unwraps and not as much specificity to errors, so I'm wondering if it was a conscious choice not to use it, or it was just overlooked.

payment_parameters_from_invoice would be preferable. The error checking here is probably overkill. The unwraps in payment_parameters_from_invoice are fine because PaymentParameters has a Payee, and some methods are only applicable to certain types of Payees.

[optout21]

Updated to LDK 0.0.121 and bitcoin library 0.30.2.
Also updated MSRV to 1.63, as LDK requires that (since 0.0.119).

Fixes#125 .

TODO:

• Fix issue of circular type dep SimpleArcPeerManager <-> GossipVerifier
• squash commits

Relevant changes in LDK:

• Added temporary_channel_id to create_channel. #2699
• Replace maze of BOLT11 payment utilities with parameter generators #2727
• Drop non-anchor channel fee upper bound limit entirely #2696
• Update to rust-bitcoin v0.30.2 #2740
• Add peer_id and channel_id explicitly to log records #2314
• Pass Record by value to Logger
• GossipVerifier now takes a PeerManager type (leads to circular type deps)
• Onion routing: signature of send_onion_message() has changed, path is not needed
• New ConectionNeeded event, ignored
• DefaultMessageRouter takes a network graph
• In WalletSource, sign_tx() has been changed to sign_psbt()
• Event processor process_events_async() has additional argument for fetching duration, constant 0 used here
• and some others

[orbitalturtle]

Just curious if this is still in the works :)

[optout21]

LDK 0.0.119 is available for some time now -- unless at the time of creation of this PR. However, more adaption is needed, TODO.

[tnull]

LDK 0.0.119 is available for some time now -- unless at the time of creation of this PR. However, more adaption is needed, TODO.

Right, but do you intend to go ahead with this PR? If not, I'd be happy to take it over and upgrade ldk-sample.

[optout21]

Yes, I plan to do this in next 1-2 days, but no hard commitment :D

[optout21]

I run into a small problem here:
I'm up to date till LDK Dec 5 cbde4a7
PR #2773 simplified GossipVerifier, which takes now a PeerManager type parameter, but our PeerManager takes a GossipVerifier, which creates a circular dependency in the types.
@tnull@TheBlueMatt

[tnull]

I run into a small problem here: I'm up to date till LDK Dec 5 cbde4a7 PR #2773 simplified GossipVerifier, which takes now a PeerManager type parameter, but our PeerManager takes a GossipVerifier, which creates a circular dependency in the types. @tnull@TheBlueMatt

Ugh, that might indeed be an issue we should fix upstream. Not sure if we need to find a (likely ugly) workaround here and roll it back, or wait for the upstream change though. @TheBlueMatt Any opinion on this?

[optout21]

I did a workaround, by creating a version of GossipVerifier without a PeerManager, called SimpleGossipVerifier, in a separate file. This workaround probably BREAKS functionality, and is ugly.
Rest of the adaptations are done, but the GossipVerifier issue has to be finalized.

[optout21]

Also mentioning @johncantrell97 , the author of #2773 .

[TheBlueMatt]

Ugh, thanks for doing this! Sorry it took a while to get back to this. We'll want to (partially) revert [#2773.](lightningdevkit/rust-lightning#2773.

[optout21]

Update: PR #2773 was partially reverted by PR #2822 .
It looks like LDK v0.0.119 will have to be skipped, and wait for v0.0.120.
I plan to check into the changes as required by current LDK main, post-2822.

[optout21]

LDK v0.0.120 has been released, includes #2822.
These changes should bring ldk-sample up to date with LDK v0.0.120 (and bitcoin 0.30.2)

[optout21]

There's one CI test failure, one dependency lib was not found, object 0.32.2, seems unrelated to changes here, in stable build there was no failure.

[optout21]

Bumped from 120 to 121.

[optout21]

Also updated minimal tested Rust version to 1.63, as LDK requires that now (since 0.0.119), and previously tested 1.48 caused some dependency issues (tokio 1.35.1, backtrace 0.3.69, object 0.32.2 does not work for 1.48).

[tnull]

LGTM, mod one unwrap I missed before (sorry for that).

[tnull]

@optout21 I think this should be very close to landing, mod the nits above.

[optout21]

@optout21 I think this should be very close to landing, mod the nits above.

Done now. Thanks for reminding, it slid lower in my to-do.

[tnull]

LGTM, thanks!

[domZippilli]

Hey, dunno if anyone will see this, but I was wondering if the team considered using payment_parameters_from_invoice for cli::send_payment implementation. That was introduced by @TheBlueMatt in #2727, and we're considering using it for our upgrade, but noticed it wasn't used here. The implementation of payment_parameters_from_invoice does seem to have some key differences from what ended up here, like unwraps and not as much specificity to errors, so I'm wondering if it was a conscious choice not to use it, or it was just overlooked.

[jkczyz]

Hey, dunno if anyone will see this, but I was wondering if the team considered using payment_parameters_from_invoice for cli::send_payment implementation. That was introduced by @TheBlueMatt in #2727, and we're considering using it for our upgrade, but noticed it wasn't used here. The implementation of payment_parameters_from_invoice does seem to have some key differences from what ended up here, like unwraps and not as much specificity to errors, so I'm wondering if it was a conscious choice not to use it, or it was just overlooked.

payment_parameters_from_invoice would be preferable. The error checking here is probably overkill. The unwraps in payment_parameters_from_invoice are fine because PaymentParameters has a Payee, and some methods are only applicable to certain types of Payees.