On Rewriting Bitcoin (was Re: [Libbitcoin] Satoshi client: is a fork past 0.10 possible?) [combined summary]



Individual post summaries: Click here to read the original discussion on the bitcoin-dev mailing list

Published on: 2015-03-25T08:04:48+00:00


Summary:

In an email exchange dated February 14th, 2015, Peter Todd expressed frustration with the lack of transparency in the soft-forking process for Bitcoin. He suggested moving the consensus critical code out of Bitcoin Core and into a standalone libconsensus library to enable a more democratic decision-making process in future soft-forks. The email ended with a humorous comment from Todd's recipient.Mike Hearn clarified during a discussion about language bindings that while the project primarily focused on Java bindings, other languages' bindings would be separate projects. It was noted that Java/JNA bindings could still be used from other languages such as Python, Ruby, Javascript, PHP, Haskell, Lisp, Smalltalk, Scala, Kotlin, Ceylon, and more obscure languages. It was considered more practical to discuss bindings to particular runtimes rather than specific languages in today's world.A user recommended using Swig, a tool for generating bindings in an automated fashion, for creating Java bindings. Once generated with Swig, bindings for other languages can be easily adjusted. Java/JNA bindings can also be used from Python, Ruby, Javascript, PHP, as well as dialects of Haskell, Lisp, Smalltalk, and lesser-known languages like Scala, Kotlin, and Ceylon. It was suggested that it makes more sense to talk about bindings to particular runtimes rather than particular languages.On February 19, 2015, Tamas Blummer responded to Bryan Bishop's comment about language bindings in a project. Blummer clarified that the language binding would be a separate and independent project, solely using the C interface of the libconsensus library. Bishop had expressed his opinion that including all possible language bindings in a project would be unproductive. However, Blummer specified that only Java bindings were intended to be included, with other languages' bindings being separate projects.Bryan Bishop expressed his disagreement with voting for the lighthouse project on February 19, 2015. He clarified that he was referring to voting by pledging on the project rather than on the mailing list. Bishop also argued against squeezing all possible language bindings into a project, stating that it would be unproductive. However, Tamas Blummer suggested that the language binding would be a separate project hosted independently and only use the C interface of the libconsensus library.On February 18, 2015, Tamas Blummer launched the Lighthouse project aimed at adding Java Language Binding to lib consensus. However, Bryan disagreed with the idea of voting and squeezing all possible language bindings into one project. Instead, he suggested exploring a solution similar to what the webkit people did by having gobject bindings. This solution allows all languages to have their own gobject bridge. Blummer's contact information can be found at http://heybryan.org/ and he can be reached at 1 512 203 0507.Tamas Blummer initiated a Lighthouse project on February 19, 2015, aimed at adding Java language binding to the core consensus library. The proposed language binding would allow JVM application developers to innovate without raising concerns about network forks through incompatible alternate protocol implementations. It would be written using lightweight, immutable, and self-contained data classes that use only language standard libraries, making it suitable for any service framework.Tamas Blummer announced the launch of the Lighthouse project to integrate Java language binding to lib consensus. According to Blummer, this will create an alternative to the border router setup in a production environment. The announcement was made on Reddit's Lighthouse Projects page and Blummer hopes that it will lead to constructive debate and voting.Troy Benjegerdes suggests treating the consensus code as a buggy and poorly defined proof-of-concept rather than holy scripture. He recommends looking at the git commit history for the consensus-critical part of the Bitcoin Core codebase as much work has been done in cleaning it up and refactoring for v0.10.0/libconsensus.Tamas Blummer explains that he is using Bitcoin Core as a border router while talking to its P2P interface. His reimplementation of consensus code helps him understand the protocol better, aids debugging, and can be used to create a side chain. He argues that the quality of the consensus code could improve significantly if the community treated it as a buggy and poorly defined proof-of-concept that just happens to actually run.In an email exchange between Tamas Blummer and Peter Todd, Blummer defends his use of Bitcoin Core as a border router and explains how the reimplementation of consensus code has helped him. Todd criticizes Blummer's work and advises him to acquire prior experience before claiming its usefulness. The conversation ends with Blummer condemning Todd's behavior and accusing him of bad-mouthing the work of others.Adam Back and Peter Todd discuss the risks of consensus rewrite experiments in maintaining strict consensus between Bitcoin Core versions. They agree that rewriting the consensus protocol should be approached cautiously to avoid contributing to centralization.


Updated on: 2023-08-01T11:36:42.299486+00:00