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


bitcoin-dev mailing list

Reply via email to