Mime-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8
Date: Sun, 30 Apr 2023 17:22:01 +0200
Message-Id: <CSA6YMDAU8FF.1FEV1VYNWWH3K@vincent-arch>
From: "Vincenzo Palazzo" <vincenzopalazzodev@gmail.com>
To: "niftynei" <niftynei@gmail.com>, "Bitcoin Protocol Discussion"
 <bitcoin-dev@lists.linuxfoundation.org>, "Michael Folkson"
 <michaelfolkson@protonmail.com>
References: <aka4qP9Cig-OhfMlQ9y1kghZWExjpno4cs47KIgYwv4aLYtiQB37eHbj2X2hiDuoK0D1gSeKWP97P0bRADbTg1CZRBIpHGZ5WFFYPWIJ87Y=@protonmail.com>
 <fiR7LHbBUV54aYegN2eIGIwX5f8Sg5bfaSSoBT0niB1huGYNGyvNeDQ1q32o15PRMC4JfaZUv_H06zuChvRgsMD5QaqZTX_bm-MPVw52asc=@protonmail.com>
 <CAM1a7P0qEkydNQQt38UUvyX3SorfgPNyfO79j72roG0_zo22+w@mail.gmail.com>
In-Reply-To: <CAM1a7P0qEkydNQQt38UUvyX3SorfgPNyfO79j72roG0_zo22+w@mail.gmail.com>
Cc: Lightning Dev <lightning-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] [Lightning-dev] A new Bitcoin implementation
 integrated with Core Lightning
Precedence: list

Hi Michael and Lisa,

> Hi Michael,
>
> CLN as implemented is currently nicely decoupled from the block source; a=
s
> 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 t=
he
> 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=20
that allows experimentation with different types of Bitcoin Core=20
node alternatives (including core too), and it also supports BIP 157=20
with nakamoto [2].

In the upcoming months, I plan to allocate some time to work=20
directly on Nakamoto.

> There=E2=80=99s probably a real opportunity to =E2=80=9Ccomingle=E2=80=9D=
 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 go=
od
> 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 wi=
th
> developments there.

A missing piece at the moment is a unified approach to fee calculation.=20
This logic is critical for Lightning nodes, so if we don't have a uniform=
=20
way of estimating fees, it could lead to several issues.

P.S: The fee estimation problem may have already been solved by Neutrino,=
=20
but I'm not aware of it.

[1] https://github.com/coffee-tools/folgore
[2] https://github.com/cloudhead/nakamoto

Cheers!

Vincent.