Hi Michael, On Wed, Apr 19, 2023 at 2:40 AM Michael Folkson via bitcoin-dev < bitcoin-...@lists.linuxfoundation.org> wrote:
> Any thoughts on this from the Core Lightning contributors? The way I see > it with upcoming proposed changes to default policy (primarily though not > exclusively for Lightning) and a soft fork activation attempt of APO/APOAS > (primarily though not > Could you please point me to a resource that describes the default policy changes (that are happening for lightning)? I have seen discussions here and there but it would help if they are aggregated somewhere for reviewing. > exclusively for Lightning) that a tighter coupling between the full node > and the Lightning node could eventually make sense. In a world where > transaction fees were much higher you'd think almost every full node would > also want to be a Lightning node and so the separation of concerns would > make less sense. > Separation of concerns always makes sense to manage complexity. One would need to have really strong incentives to counter the complexity argument. I might be missing some context here but what would the actual benefit of integrating them be? Not having to install lightning node separately and maybe a more intuitive UX? Having two separate P2P networks and two separate P2P protocols also > wouldn't make much sense in this scenario. You could obviously still opt > out of Lightning P2P messages if you weren't interested in Lightning. > > The alternative would be just to focus on Knots style consensus compatible > forks of Core with limited additional functionality. But I think we've > reached the point of no return on Core dominance and not having widely used > "distros". As the ecosystem scales systems and processes should be > constantly evolving and improving and to me if anything Core's seem to be > going backwards. > > Personally, I have great difficulty seeing lightning as something other than an L2 build on top of Bitcoin. There will be other L2s. Regards, Kostas PS. Besides, the amount of effort would be significant. Wouldn't that effort be better spent on, say, separating the consensus logic (i.e. a second libbitcoinkernel attempt)? > 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 Saturday, January 14th, 2023 at 20:26, Michael Folkson < > michaelfolk...@protonmail.com> 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 > Keybase: michaelfolkson > PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3 > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-...@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > -- https://twitter.com/kkarasavvas
_______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
