Libconsensus separated repository (was Bitcoin Core and hard forks)



Summary:

The author of this message has been pushing for greater modularization in Bitcoin since he started working with the currency. The lack of a layered protocol design presents a challenge to the project, as there is no standards process that is separate from updates to one specific reference implementation. This means that any major changes need to be agreed upon by everyone involved, in order to avoid contentious forks. The author notes that some people are pushing for relatively superficial yet highly controversial changes at the same time as lacking the proper infrastructure to handle these kinds of divergences of opinion without becoming polarized. While the author initially developed his own Bitcoin stack to avoid politics and focus on engineering, he now understands that politics are inevitable in a cooperative project like Bitcoin. He believes that modularization is essential to resolving serious political challenges. However, it doesn't seem like re-implementing an entire stack from scratch will ultimately be a convergent process, as it's easy to let ego and habit dictate preferences rather than rational engineering considerations. The author proposes taking a step back from implementation hackery and specifying some core protocol layers that focus on interfaces, specifically a consensus layer that doesn't try to specify networking, storage, wallets, UI, etc. Different people could then improve upon these things independently in their own implementations. What matters is that everyone converges on a common history and state. In a subsequent email thread, Tamas Blummer discusses the risks associated with reimplementation, refactoring, and copy-pasting in Bitcoin development. He argues that quality is achieved at a very high cost and is hard to uphold over generations of developers. He also notes that while Bit of Proof's own implementation of scripts was not practically relevant in his commercially successful deployments, it helped development by enabling easier debugging and precise error feedback. Blummer suggests that it would be nice if libconsensus offered VerifyTx, VerifyHeader, and VerifyBlock, alongside VerifyScript, since the storage and validation are interconnected.


Updated on: 2023-06-10T03:36:26.648681+00:00