Date: Mon, 16 Jan 2023 15:45:36 +0000
To: alicexbt <alicexbt@protonmail.com>
From: Michael Folkson <michaelfolkson@protonmail.com>
Message-ID: <tU0pTKOODHenOeHhFqEIC0uBDz_jj5mjVpQJcJun4uDm9YaNNHXSsLXsCSY-tMzb5dgQVcaEEdYF5zwGvlJ-OUfDH6KlJqzEpiArB3Kv2cA=@protonmail.com>
In-Reply-To: <KdDQGItU-BH7EotUQ9DoiUZRPM9TRnflf4P664Ue2ynCyj6ts1zFIoHxf4q-EsaM8b_GVrvXZZA9TtPX6BVY6CfSvXcme12lxLe_1RoAwZw=@protonmail.com>
References: <aka4qP9Cig-OhfMlQ9y1kghZWExjpno4cs47KIgYwv4aLYtiQB37eHbj2X2hiDuoK0D1gSeKWP97P0bRADbTg1CZRBIpHGZ5WFFYPWIJ87Y=@protonmail.com>
 <KdDQGItU-BH7EotUQ9DoiUZRPM9TRnflf4P664Ue2ynCyj6ts1zFIoHxf4q-EsaM8b_GVrvXZZA9TtPX6BVY6CfSvXcme12lxLe_1RoAwZw=@protonmail.com>
Feedback-ID: 27732268:user:proton
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] [Lightning-dev] A new Bitcoin implementation
	integrated with Core Lightning
Precedence: list

Hi alicexbt

Thanks for the suggestion. I'll take a look at the branch.

I'm personally pretty bullish on Lightning and Core Lightning is criminally=
 underused. Plus it is more exciting (and hopefully will attract more contr=
ibutors) to try something ambitious than just trim Core. I'll see if it is =
something the Core Lightning contributors might be interested in helping ou=
t on. I remember that Rusty said on a podcast that if he had another life h=
e'd have liked to have worked on Core. This way he could potentially do bot=
h :)

Thanks
Michael

--
Michael Folkson
Email: michaelfolkson at protonmail.com
Keybase: michaelfolkson
PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3


------- Original Message -------
On Sunday, January 15th, 2023 at 12:58, alicexbt <alicexbt@protonmail.com> =
wrote:


> Hi Michael,
>=20
> If I were to fork bitcoin core and maintain an implementation, I wouldn't=
 integrate any lightning implementation with it. Instead remove some things=
 from bitcoin core and keep it simple. There is also scope for improving pr=
ivacy. Example: https://github.com/bitcoinknots/bitcoin/issues/50
>=20
> You might find the commits in this branch interesting if you are looking =
to remove things from bitcoin core and maintain an implementation with no g=
ui, wallet, less RPCs etc.
>=20
> https://github.com/jeremyRubin/bitcoin/commits/delete-it-all
>=20
>=20
> /dev/fd0
> floppy disc guy
>=20
> Sent with Proton Mail secure email.
>=20
> ------- Original Message -------
> On Sunday, January 15th, 2023 at 1:56 AM, Michael Folkson via Lightning-d=
ev lightning-dev@lists.linuxfoundation.org wrote:
>=20
>=20
>=20
> > I tweeted this 0 back in November 2022.
> >=20
> > "With the btcd bugs and the analysis paralysis on a RBF policy option i=
n Core increasingly thinking @BitcoinKnots and consensus compatible forks o=
f Core are the future. Gonna chalk that one up to another thing @LukeDashjr=
 was right about all along."
> >=20
> > A new bare bones Knots style Bitcoin implementation (in C++/C) integrat=
ed with Core Lightning was a long term idea I had (and presumably many othe=
rs have had) but the dysfunction on the Bitcoin Core project this week (if =
anything it has been getting worse over time, not better) has made me start=
 to take the idea more seriously. It is clear to me that the current way th=
e Bitcoin Core project is being managed is not how I would like an open sou=
rce project to be managed. Very little discussion is public anymore and dec=
isions seem to be increasingly made behind closed doors or in private IRC c=
hannels (to the extent that decisions are made at all). Core Lightning seem=
s to have the opposite problem. It is managed effectively in the open (admi=
ttedly with fewer contributors) but doesn't have the eyeballs or the usage =
that Bitcoin Core does. Regardless, selfishly I at some point would like a =
bare bones Bitcoin and Lightning implementation integrated in one codebase.=
 The Bitcoin Core codebase has collected a lot of cruft over time and the u=
ltra conservatism that is needed when treating (potential) consensus code s=
eems to permeate into parts of the codebase that no one is using, definitel=
y isn't consensus code and should probably just be removed.
> >=20
> > The libbitcoinkernel project was (is?) an attempt to extract the consen=
sus engine out of Core but it seems like it won't achieve that as consensus=
 is just too slippery a concept and Knots style consensus compatible codeba=
se forks of Bitcoin Core seem to still the model. To what extent you can sa=
fely chop off this cruft and effectively maintain this less crufty fork of =
Bitcoin Core also isn't clear to me yet.
> >=20
> > Then there is the question of whether it makes sense to mix C and C++ c=
ode that people have different views on. C++ is obviously a superset of C b=
ut assuming this merging of Bitcoin Core and Core Lightning is/was the opti=
mal final destination it surely would have been better if Core Lightning wa=
s written in the same language (i.e. with classes) as Bitcoin Core.
> >=20
> > I'm just floating the idea to (hopefully) hear from people who are much=
 more familiar with the entirety of the Bitcoin Core and Core Lightning cod=
ebases. It would be an ambitious long term project but it would be nice to =
focus on some ambitious project(s) (even if just conceptually) for a while =
given (thankfully) there seems to be a lull in soft fork activation chaos.
> >=20
> > Thanks
> > Michael
> >=20
> > --
> > Michael Folkson
> > Email: michaelfolkson at protonmail.com
> > Keybase: michaelfolkson
> > PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3