Hi Michael and Lisa, > Hi Michael, > > CLN as implemented is currently nicely decoupled from the block source; as > a project we assume that the node runner will choose a block backend that > fits their self-sovereignty goals. > > This provides us with a nice separation of concerns. The block source is > responsible for ensuring that only consensus valid data is delivered to the > node, which in turn allows us to focus on processing and reacting to that > data, as necessary.
Let me just mention that [1] I have been working on a plugin that allows experimentation with different types of Bitcoin Core node alternatives (including core too), and it also supports BIP 157 with nakamoto [2]. In the upcoming months, I plan to allocate some time to work directly on Nakamoto. > There’s probably a real opportunity to “comingle” the peering of LN gossip > + block data networks, this has been suggested a few times but never > seriously pursued from the LN side. Having the peering functions of > bitcoin-core broken out into a more composable/reusable piece may be a good > first step here, and as a project would largely be on the bitcoin core > side. Maybe this work is already in progress? I havent been keeping up with > developments there. A missing piece at the moment is a unified approach to fee calculation. This logic is critical for Lightning nodes, so if we don't have a uniform way of estimating fees, it could lead to several issues. P.S: The fee estimation problem may have already been solved by Neutrino, but I'm not aware of it. [1] https://github.com/coffee-tools/folgore [2] https://github.com/cloudhead/nakamoto Cheers! Vincent. _______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
