Christian Decker [ARCHIVE] on Nostr: 📅 Original date posted:2021-11-23 📝 Original message: ZmnSCPxj via ...
📅 Original date posted:2021-11-23
📝 Original message:
ZmnSCPxj via Lightning-dev <lightning-dev at lists.linuxfoundation.org>
writes:
> Are you proposing as well to provide the hardware and Internet
> connection for these boxes?
Having implemented and operated the lightning integration testing
framework [1,2] in the past this is something near and dear to my
heart. However I have since become convinced that this kind of
artificial setup is unlikely to catch any but the most egregious issues,
given their different usage pattern. Much like the bitcoin testnet is
not representative of what happens on the mainnet, I don't think a
separate network would be able to reproduce all the issues that occur on
the lightning mainnet.
I agree with ZmnSCPxj that testing on the mainnet is much more likely to
catch more involved issues, and therefore a solid process with release
candidates and nightly builds, in combination with lnprototest [3] to test
the nodes for spec adherence in isolation is the way to go.
> I know of one person at least who runs a node that tracks the
> C-Lightning master (I think they do a nightly build?), and I run a
> node that I update every release of C-Lightning (and runs CLBOSS as
> well). I do not know the actual implementations of what they connect
> to, but LND is very popular on the network and LNBIG is known to be an
> LND shop, and LNBIG is so pervasive that nearly every long-lived
> forwarding node has at least one channel with *some* LNBIG node. I
> consider this "good enough" in practice to catch interop bugs, but
> some interop bugs are deeper than just direct node-to-node
> communications. For example, we had bugs in our interop with LND
> `keysend` before, by my memory.
We should differentiate between spec compliance, and compatibility of
extensions. `keysend` wasn't and still isn't specd which resulted in us
having to reverse engineer the logic from the first experimental
implementation, and I did get some details wrong. For example I expected
nodes to explicitly opt-into keysend via featurebit 55, but they just
yolo it...
As these primitives become more widespread and more users rely on them,
I think it is paramount that we actually spec them out (something that
the new bLIP process should cover), but until we do there is no way of
saying what's correct and what isn't.
Cheers,
Christian
[1] https://github.com/cdecker/lightning-integration
[2] https://cdecker.github.io/lightning-integration/
[3] https://github.com/rustyrussell/lnprototest
📝 Original message:
ZmnSCPxj via Lightning-dev <lightning-dev at lists.linuxfoundation.org>
writes:
> Are you proposing as well to provide the hardware and Internet
> connection for these boxes?
Having implemented and operated the lightning integration testing
framework [1,2] in the past this is something near and dear to my
heart. However I have since become convinced that this kind of
artificial setup is unlikely to catch any but the most egregious issues,
given their different usage pattern. Much like the bitcoin testnet is
not representative of what happens on the mainnet, I don't think a
separate network would be able to reproduce all the issues that occur on
the lightning mainnet.
I agree with ZmnSCPxj that testing on the mainnet is much more likely to
catch more involved issues, and therefore a solid process with release
candidates and nightly builds, in combination with lnprototest [3] to test
the nodes for spec adherence in isolation is the way to go.
> I know of one person at least who runs a node that tracks the
> C-Lightning master (I think they do a nightly build?), and I run a
> node that I update every release of C-Lightning (and runs CLBOSS as
> well). I do not know the actual implementations of what they connect
> to, but LND is very popular on the network and LNBIG is known to be an
> LND shop, and LNBIG is so pervasive that nearly every long-lived
> forwarding node has at least one channel with *some* LNBIG node. I
> consider this "good enough" in practice to catch interop bugs, but
> some interop bugs are deeper than just direct node-to-node
> communications. For example, we had bugs in our interop with LND
> `keysend` before, by my memory.
We should differentiate between spec compliance, and compatibility of
extensions. `keysend` wasn't and still isn't specd which resulted in us
having to reverse engineer the logic from the first experimental
implementation, and I did get some details wrong. For example I expected
nodes to explicitly opt-into keysend via featurebit 55, but they just
yolo it...
As these primitives become more widespread and more users rely on them,
I think it is paramount that we actually spec them out (something that
the new bLIP process should cover), but until we do there is no way of
saying what's correct and what isn't.
Cheers,
Christian
[1] https://github.com/cdecker/lightning-integration
[2] https://cdecker.github.io/lightning-integration/
[3] https://github.com/rustyrussell/lnprototest