From decker.christian at gmail.com Tue Nov 23 11:55:15 2021 From: decker.christian at gmail.com (Christian Decker) Date: Tue, 23 Nov 2021 12:55:15 +0100 Subject: [Lightning-dev] INTEROPERABILITY In-Reply-To: References: Message-ID: <87sfvnkrx8.fsf@nox.i-did-not-set--mail-host-address--so-tickle-me> ZmnSCPxj via Lightning-dev 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