Interop with another LN implementations

[crisdut]

this PR completes all steps to interop with another lightning implementations.

I resolved open this PR as a draft because I will change many parts of the lnp-node and lnp-core and would like to get feedback from other contributors before finalizing the PR.

Pending items to Ready to Review

• Add support to minimum depth in watchd;
• Add Universal Invoice (LNPBP-38) to BOLT payments;
• Complete the Nodes Tests list (see bellow);
• Update crates with dependencies (see section "Dependencies").

Nodes Tests
I marked all tests I finish in the below list:

• Connect peer and open a channel from lnp to lnp;
• Connect peer and open a channel from lnp to lnd;
• Connect peer and open a channel from lnp to cligntning;
• Connect peer and open a channel from lnd to lnp;
• Connect peer and open a channel from cligntning to lnp;
• The lnd create an invoice and lnp payed;
• The cligntning create an invoice and lnp payed;
• The lnp create an invoice and lnp payed;
• The lnp create an invoice and lnd payed;
• The lnp create an invoice and cligntning payed;
• The lnp unilaterally closes the channel and publish penalty transaction;
• The lnd unilaterally closes the channel and publish penalty transaction;
• The cligntning unilaterally closes the channel and publish penalty transaction;
• The lnp and lnp closes the channel mutually;
• The lnp and lnd closes the channel mutually;
• The lnp and cligntning closes the channel mutually;

Dependencies

• Fix Commitment TX Signature lnp-core#29
• Fix Channel Type decode lnp-core#27
• Fix Script lightning decode lightning_encoding#4
• Bolt11 Converter LNP-BP/invoices#9

Feedback are welcome, thanks!

[crisdut]

Hi @dr-orlovsky, I'm almost done with all the work related to interoperability with other LN implementations. But have a lot of changes to review at once.

I think is good closing this PR and opening other smaller PRs. Whats your opnion?

[dr-orlovsky]

@crisdut very cool. Yes, several small PRs are clearly preferable over a single large one.

[crisdut]

Hi @dr-orlovsky, just an update:

I intend back to work on it next month.

Are you anticipating any changes to lnp-node in the next two months?

My plan is:

• Finish interop between other nodes
• Initial taproot support in lnp-node
• Test musig2 to create channels using rust (I'm studying some existing implementations)
• Some drafts of how the Bitfrost feature flag will work (not just code, but open discussions for updates to the LNPBPs)

Well, wish me luck, hehe!

Thanks

[dr-orlovsky]

Very exciting!

I do plan to move LNP Node to the new architecture based on io-reactor pattern from https://github.com/rust-amplify/io-reactor (instead of ZMQ-based current architecture). So I think we need to coordinate our efforts.

Regarding taproot, how specifically you plan to add support?

[crisdut]

Regarding taproot, how specifically you plan to add support?

I'm thinking of splitting it into two steps:

1. Understand the effort of updating project dependencies, such as amplify, descriptor-wallet, etc.. This allows us to work in a single code base without backports.

2. After I understand MuSig2, I will try embed it in the descriptor-wallet. This point is sensitive, as I understand that you have plans to discontinue the use of rust-bitcoin and rust-miniscript. Much of the descriptor-wallet would need to be redone in this process.

[crisdut]

Very exciting!

I do plan to move LNP Node to the new architecture based on io-reactor pattern from https://github.com/rust-amplify/io-reactor (instead of ZMQ-based current architecture). So I think we need to coordinate our efforts.

I agree.

We could take advantage of this restructuring to create a module within the project focused on functional tests, where we could spawn "nodes" in-memory. This would make it easier to automate tests related to the BOLT, interop nodes, crash-recovery scenarios, etc...

[dr-orlovsky]

It is not that I am against rust-bitcoin; the reason I removed it from RGB Core is the fact that it is severely unstable: each release breaks everything, which is unacceptable for RGB consensus level where APIs are fixed now.

I am not a big fun of the idea of rewriting rust-bitcoin wallet functionality; however, I find its API weird, ancient and constantly changing. Thus, eventually, it may be good to move out from it - but only when we have an alternative. Until that feel free to use it here and in descriptor-wallet (even when/if we will move from rust-bitcoin, it wouldn't change descriptor wallet which will continue to use it. The new alternative without rust-bitcoin will be a bp-wallet).

[crisdut]

It is not that I am against rust-bitcoin; the reason I removed it from RGB Core is the fact that it is severely unstable: each release breaks everything, which is unacceptable for RGB consensus level where APIs are fixed now.

Yes, I know, I didn't mean to say that you have something against the project, because you made countless contributions to it. Just wanted to say BP-WG have been working on a version that is more stable for RGB related projects

I am not a big fun of the idea of rewriting rust-bitcoin wallet functionality; however, I find its API weird, ancient and constantly changing. Thus, eventually, it may be good to move out from it - but only when we have an alternative. Until that feel free to use it here and in descriptor-wallet (even when/if we will move from rust-bitcoin, it wouldn't change descriptor wallet which will continue to use it. The new alternative without rust-bitcoin will be a bp-wallet).

Ok, good to known.