Open crisdut opened 1 year ago
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?
@crisdut very cool. Yes, several small PRs are clearly preferable over a single large one.
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:
lnp-node
Well, wish me luck, hehe!
Thanks
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?
Regarding taproot, how specifically you plan to add support?
I'm thinking of splitting it into two steps:
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.
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.
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...
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).
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.
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
watchd
;Nodes Tests I marked all tests I finish in the below list:
lnp
tolnp
;lnp
tolnd
;lnp
tocligntning
;lnd
tolnp
;cligntning
tolnp
;lnd
create an invoice andlnp
payed;cligntning
create an invoice andlnp
payed;lnp
create an invoice andlnp
payed;lnp
create an invoice andlnd
payed;lnp
create an invoice andcligntning
payed;lnp
unilaterally closes the channel and publish penalty transaction;lnd
unilaterally closes the channel and publish penalty transaction;cligntning
unilaterally closes the channel and publish penalty transaction;lnp
andlnp
closes the channel mutually;lnp
andlnd
closes the channel mutually;lnp
andcligntning
closes the channel mutually;Dependencies
Feedback are welcome, thanks!