search

lightningdevkit / rust-lightning

A highly modular Bitcoin Lightning library written in Rust. It's rust-lightning, not Rusty's Lightning!
Other
1.16k stars 364 forks source link

Lightning Protocol Tests #406

Open TheBlueMatt opened 4 years ago

TheBlueMatt commented 4 years ago

Rusty's been working on a protocol test framework including a protocol test language that we'd want to implement a parser for. We should probably play with doing it before we end up with a language that doesn't map well to our API.

Current branch is at https://github.com/ElementsProject/lightning-rfc-protocol-test

jkczyz commented 4 years ago

Writing a parser shouldn't be necessary for using the protocol test framework. Rather, we'd write a runner that implements the interface defined by the framework similar to c-lightning's runner.

Essentially, the runner acts as an adapter from the test framework interface to our own API. Do you envision using the framework in a different manner?

TheBlueMatt commented 4 years ago

I hadn't looked into it at all, feel free to do it any way you feel like if you're gonna tackle it. It may be more effort to add rust-lightning bindings in python to just use their python framework than write a parser for the events files at https://github.com/ElementsProject/lightning-rfc-protocol-test/tree/master/tests/events.

jkczyz commented 4 years ago

My main objection to writing a separate parser (not to mention a test framework) is that it adds an unnecessary maintenance burden.

Thinking about it more, this could be avoided instead by writing a rust binary implementing barebones functionality (similar to what we've discussed before). The runner then would call into this in some manner (e.g., RPC interface or similar).

TheBlueMatt commented 4 years ago

Right, fair enough. There’s a simple demo that uses Bitcoin Core RPC calls at https://github.com/TheBlueMatt/rust-lightning-bitcoinrpc which may be a reasonable starting point.

On Dec 4, 2019, at 14:53, Jeffrey Czyz notifications@github.com wrote:

 My main objection to writing a separate parser (not to mention a test framework) is that it adds an unnecessary maintenance burden.

Thinking about it more, this could be avoided instead by writing a rust binary implementing barebones functionality (similar to what we've discussed before). The runner then would call into this in some manner (e.g., RPC interface or similar).

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe.