Michael Folkson [ARCHIVE] on Nostr: 📅 Original date posted:2023-01-16 🗒️ Summary of this message: Michael is ...
📅 Original date posted:2023-01-16
🗒️ Summary of this message: Michael is considering the idea of creating a bare bones Knots-style Bitcoin implementation integrated with Core Lightning, as he believes the current management of Bitcoin Core is not how he would like an open-source project to be managed.
📝 Original message: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 contributors) to try something ambitious than just trim Core. I'll see if it is something the Core Lightning contributors might be interested in helping out on. I remember that Rusty said on a podcast that if he had another life he'd have liked to have worked on Core. This way he could potentially do both :)
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 at protonmail.com> wrote:
> Hi Michael,
>
> 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 privacy. Example: https://github.com/bitcoinknots/bitcoin/issues/50
>
> 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 gui, wallet, less RPCs etc.
>
> https://github.com/jeremyRubin/bitcoin/commits/delete-it-all
>
>
> /dev/fd0
> floppy disc guy
>
> Sent with Proton Mail secure email.
>
> ------- Original Message -------
> On Sunday, January 15th, 2023 at 1:56 AM, Michael Folkson via Lightning-dev lightning-dev at 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
> >
> > --
> > Michael Folkson
> > Email: michaelfolkson at protonmail.com
> > Keybase: michaelfolkson
> > PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
🗒️ Summary of this message: Michael is considering the idea of creating a bare bones Knots-style Bitcoin implementation integrated with Core Lightning, as he believes the current management of Bitcoin Core is not how he would like an open-source project to be managed.
📝 Original message: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 contributors) to try something ambitious than just trim Core. I'll see if it is something the Core Lightning contributors might be interested in helping out on. I remember that Rusty said on a podcast that if he had another life he'd have liked to have worked on Core. This way he could potentially do both :)
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 at protonmail.com> wrote:
> Hi Michael,
>
> 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 privacy. Example: https://github.com/bitcoinknots/bitcoin/issues/50
>
> 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 gui, wallet, less RPCs etc.
>
> https://github.com/jeremyRubin/bitcoin/commits/delete-it-all
>
>
> /dev/fd0
> floppy disc guy
>
> Sent with Proton Mail secure email.
>
> ------- Original Message -------
> On Sunday, January 15th, 2023 at 1:56 AM, Michael Folkson via Lightning-dev lightning-dev at 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
> >
> > --
> > Michael Folkson
> > Email: michaelfolkson at protonmail.com
> > Keybase: michaelfolkson
> > PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3