<p>There are some clear upsides to having multiple implementations based on libbitcoinkernel that Carl Dong highlights in this short <a href="https://btctranscripts.com/chaincode-labs/2022-04-12-carl-dong-libbitcoinkernel/" rel="nofollow noreferrer">presentation</a> on libbitcoinkernel.</p>
<p>There are multiple approaches that can be experimented with (including rewriting a subsystem in a different language like Rust) when an alternative implementation doesn't have to worry about falling out of consensus with Bitcoin Core. Currently there can only be one approach widely used on the network because of Bitcoin Core's dominance and general perception that it is the reference implementation.</p>
<p>The stringent review culture required not to introduce bugs into the consensus engine often leaks into other subsystems that aren't as security critical (e.g. GUI, tests). It is very difficult to define contrasting review processes depending on the subsystem when they are all part of the same project. Hence reviewers and maintainers have needed to push back against <a href="https://twitter.com/orionwl/status/1528843631855009792?s=20&amp;t=AnCkdXkA-FgV_Pb30vkoIg" rel="nofollow noreferrer">scope creep</a> because the project is already too large to sustain a monoculture that generally runs on well reasoned NACKs preventing a change from being merged.</p>
<p>James O'Beirne highlighted some of the potential downsides though on <a href="https://twitter.com/jamesob/status/1529090064596205574?s=20&amp;t=9RGsOzlbLdGcBTPHHsTzpA" rel="nofollow noreferrer">Twitter</a>.</p>
<blockquote>
<p>I have a few arrows pointing in opposite directions on this one. On
one hand, I think having multiple &quot;shell&quot; implementations (shared
libbitcoinkernel used by different networking + mempool + ui designs)
is very important because multiple teams doing parallel
construction/cross-validation is good/resilient and forward progress
on mempool and other important problems is stuck in the mud because
it's hard to gather technical consensus to the point of merge.</p>
<p>These important problems become harder and harder to reason about in
the abstract, and need to be actually tried to gauge efficacy in the
real world. Hard to do experimentation in the wild given the sacred
nature of Core.</p>
<p>But, on the other hand, there are some issues with multiple
implementations beyond the classic &quot;but consensus bug can come from
non-obvious implementation details:&quot;</p>
<p>Policy, not just consensus has a very real impact on e.g. network
splits, or unupgraded miners not mining bad blocks after a soft fork
due to no standardness.  Having many implementations running around
significantly complicates this especially if they exist to experiment
with policy.</p>
<p>Part of the benefit of Core as the sole implementation is that it's
easier in practical terms to consolidate eyeballs and do review over a
single process/codebase. Review maximalism: if you have Core and some
other project that's double the overhead to stay on top of changes.</p>
<p>There are probably more arrows pointing in either direction, and this
is tough to reason about. In any case I'll keep reviewing and
advocating for libbitcoinkernel because it's the clear way forward in
either case.</p>
</blockquote>
<p>Carl Dong added on <a href="https://twitter.com/carl_dong/status/1529198318701662209?s=20&amp;t=3zwBY4if09CsT6ynPEHrGQ" rel="nofollow noreferrer">Twitter</a> that even if alternative implementations don't end up getting built around libbitcoinkernel it still brings many benefits:</p>
<blockquote>
<p>In the unfortunate event that there doesn’t end up being alternative
implementations built on top of libbitcoinkernel, the modularization
of the codebase as a result of the effort will have been well-worth
the trouble.</p>
<p>It will have achieved what orionwl pointed out here: “What kind of
frustrates me, personally, is that we didn't manage to clearly
separate out the consensus parts. Not to a library (which would be
useful for rust-bitcoin et al), but also not even to a separate
directory.”</p>
<p>libbitcoinkernel can actually do one better than having a separate
directory: after phase 1, any unintentional re-entaglement of
consensus and non-consensus code will make themselves obvious to devs
and reviewers by triggering linker errors.</p>
</blockquote>

CC BY-SA 4.0
2022-05-24T13:44:37.383Z
2022-05-25T10:39:52.113Z
2022-05-25T10:39:52.113Z
Michael Folkson
<p>Assuming the <a href="https://github.com/bitcoin/bitcoin/issues/24303" rel="nofollow noreferrer">libbitcoinkernel subproject</a> of Bitcoin Core is completed and successfully/safely extracts the consensus engine out of Bitcoin Core will having multiple widely used alternative implementations built around libbitcoinkernel be an overall net positive or net negative for the ecosystem?</p>

<bitcoin-core-development><consensus>
In future will multiple widely used implementations around libbitcoinkernel be an overall net positive or net negative for the ecosystem?
Michael Folkson
# In future will multiple widely used implementations around libbitcoinkernel be an overall net positive or net negative for the ecosystem?

(Asked by: username_0 on 2022-05-24)

Assuming the [libbitcoinkernel subproject](https://github.com/bitcoin/bitcoin/issues/24303) of Bitcoin Core is completed and successfully/safely extracts the consensus engine out of Bitcoin Core will having multiple widely used alternative implementations built around libbitcoinkernel be an overall net positive or net negative for the ecosystem?

**Tags:** bitcoin-core-development, consensus


---

## 1 answers

### Answer by username_0 on 2022-05-24. Score: 0 | Accepted answer

There are some clear upsides to having multiple implementations based on libbitcoinkernel that Carl Dong highlights in this short [presentation](https://btctranscripts.com/chaincode-labs/2022-04-12-carl-dong-libbitcoinkernel/) on libbitcoinkernel.

There are multiple approaches that can be experimented with (including rewriting a subsystem in a different language like Rust) when an alternative implementation doesn't have to worry about falling out of consensus with Bitcoin Core. Currently there can only be one approach widely used on the network because of Bitcoin Core's dominance and general perception that it is the reference implementation.

The stringent review culture required not to introduce bugs into the consensus engine often leaks into other subsystems that aren't as security critical (e.g. GUI, tests). It is very difficult to define contrasting review processes depending on the subsystem when they are all part of the same project. Hence reviewers and maintainers have needed to push back against [scope creep](https://twitter.com/orionwl/status/1528843631855009792?s=20&t=AnCkdXkA-FgV_Pb30vkoIg) because the project is already too large to sustain a monoculture that generally runs on well reasoned NACKs preventing a change from being merged.

James O'Beirne highlighted some of the potential downsides though on [Twitter](https://twitter.com/jamesob/status/1529090064596205574?s=20&t=9RGsOzlbLdGcBTPHHsTzpA).

> I have a few arrows pointing in opposite directions on this one. On
> one hand, I think having multiple "shell" implementations (shared
> libbitcoinkernel used by different networking + mempool + ui designs)
> is very important because multiple teams doing parallel
> construction/cross-validation is good/resilient and forward progress
> on mempool and other important problems is stuck in the mud because
> it's hard to gather technical consensus to the point of merge.
>
> These important problems become harder and harder to reason about in
> the abstract, and need to be actually tried to gauge efficacy in the
> real world. Hard to do experimentation in the wild given the sacred
> nature of Core.
>
> But, on the other hand, there are some issues with multiple
> implementations beyond the classic "but consensus bug can come from
> non-obvious implementation details:"
>
> Policy, not just consensus has a very real impact on e.g. network
> splits, or unupgraded miners not mining bad blocks after a soft fork
> due to no standardness. Having many implementations running around
> significantly complicates this especially if they exist to experiment
> with policy.
>
> Part of the benefit of Core as the sole implementation is that it's
> easier in practical terms to consolidate eyeballs and do review over a
> single process/codebase. Review maximalism: if you have Core and some
> other project that's double the overhead to stay on top of changes.
>
> There are probably more arrows pointing in either direction, and this
> is tough to reason about. In any case I'll keep reviewing and
> advocating for libbitcoinkernel because it's the clear way forward in
> either case.

Carl Dong added on [Twitter](https://twitter.com/carl_dong/status/1529198318701662209?s=20&t=3zwBY4if09CsT6ynPEHrGQ) that even if alternative implementations don't end up getting built around libbitcoinkernel it still brings many benefits:

> In the unfortunate event that there doesn’t end up being alternative
> implementations built on top of libbitcoinkernel, the modularization
> of the codebase as a result of the effort will have been well-worth
> the trouble.
>
> It will have achieved what orionwl pointed out here: “What kind of
> frustrates me, personally, is that we didn't manage to clearly
> separate out the consensus parts. Not to a library (which would be
> useful for rust-bitcoin et al), but also not even to a separate
> directory.”
>
> libbitcoinkernel can actually do one better than having a separate
> directory: after phase 1, any unintentional re-entaglement of
> consensus and non-consensus code will make themselves obvious to devs
> and reviewers by triggering linker errors.


---

