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

------- Original Message -------
On Saturday, January 14th, 2023 at 9:26 PM, Michael Folkson via Lightning-dev 
<lightning-...@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
bitcoin-dev mailing list

Reply via email to