Hi Michael,
have you seen Mako? It might at least be a good start for what you would like
to achieve: https://github.com/chjj/mako
Best,
Fabian
------- Original Message -------
On Saturday, January 14th, 2023 at 9:26 PM, Michael Folkson via Lightning-dev
<lightning-dev@lists.linuxfoundation.org> wrote:
> I tweeted this [0] back in November 2022.
>
> "With the btcd bugs and the analysis paralysis on a RBF policy option in Core
> increasingly thinking @BitcoinKnots and consensus compatible forks of Core
> are the future. Gonna chalk that one up to another thing @LukeDashjr was
> right about all along."
>
> A new bare bones Knots style Bitcoin implementation (in C++/C) integrated
> with Core Lightning was a long term idea I had (and presumably many others
> 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 the
> Bitcoin Core project is being managed is not how I would like an open source
> project to be managed. Very little discussion is public anymore and decisions
> seem to be increasingly made behind closed doors or in private IRC channels
> (to the extent that decisions are made at all). Core Lightning seems to have
> the opposite problem. It is managed effectively in the open (admittedly 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 ultra
> conservatism that is needed when treating (potential) consensus code seems to
> permeate into parts of the codebase that no one is using, definitely isn't
> consensus code and should probably just be removed.
>
> The libbitcoinkernel project was (is?) an attempt to extract the consensus
> 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 codebase
> forks of Bitcoin Core seem to still the model. To what extent you can safely
> chop off this cruft and effectively maintain this less crufty fork of Bitcoin
> Core also isn't clear to me yet.
>
> Then there is the question of whether it makes sense to mix C and C++ code
> that people have different views on. C++ is obviously a superset of C but
> assuming this merging of Bitcoin Core and Core Lightning is/was the optimal
> final destination it surely would have been better if Core Lightning was
> written in the same language (i.e. with classes) as Bitcoin Core.
>
> 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 codebases.
> 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.
>
> Thanks
> Michael
>
> [0]:
> https://twitter.com/michaelfolkson/status/1589220155006910464?s=20&t=GbPm7w5BqS7rS3kiVFTNcw
>
> --
> Michael Folkson
> Email: michaelfolkson at [protonmail.com](http://protonmail.com/)
> Keybase: michaelfolkson
> PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
_______________________________________________
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
