Author: Michael Folkson 2023-04-18 17:06:14
Published on: 2023-04-18T17:06:14+00:00
The author of the email is suggesting a tighter coupling between the full node and the Lightning node in light of proposed changes to default policy, as well as a potential soft fork activation attempt of APO/APOAS. The idea is that if transaction fees were much higher, almost every full node would also want to be a Lightning node, making the separation of concerns less necessary. Additionally, having two separate P2P networks and protocols would not make sense in this scenario. However, users could still opt out of Lightning P2P messages if they weren't interested.The alternative to this proposal would be to focus on Knots style consensus compatible forks of Core with limited additional functionality. However, the author believes that the ecosystem should be constantly evolving and improving, and that Core's systems and processes seem to be going backwards. The author suggests integrating a bare bones Bitcoin implementation with Core Lightning into one codebase, but acknowledges that the current way the Bitcoin Core project is being managed is not ideal for an open source project. The libbitcoinkernel project was an attempt to extract the consensus engine out of Core, but it seems like it won't achieve that, and Knots style consensus compatible codebase forks of Bitcoin Core still seem to be the model.The author also raises the question of whether it makes sense to mix C and C++ code, and suggests that it would have been better if Core Lightning was written in the same language (i.e. with classes) as Bitcoin Core. Overall, the author is floating the idea to 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 given the lull in soft fork activation chaos, it would be nice to focus on some ambitious projects.
Updated on: 2023-06-03T11:34:12.657787+00:00