Are alternate Bitcoin implementations dangerous?

2940 sats \ 31 comments \ @Scoresby 27 Oct 2022 bitcoin

Having multiple implementations of Bitcoin is dangerous.

Not having multiple implementations of Bitcoin is dangerous.

So should you run something other than Bitcoin Core?

(NOTE: many of you probably know all this, but I had to write it out to figure it out for myself, and I think the question is genuinely interesting. I'd love to hear where you stand. I think it makes sense to encourage multiple implementations even though there are risks--see the bottom of the post for reasons).

Although you may not have heard of all of them, there are several implementations of the Bitcoin consensus protocol.

The most popular by far is Bitcoin Core.

@LukeDashjr sees 44k nodes, 98% running BitcoinCore.

Something called Coin Dance sees 13k nodes, 96% running BitcoinCore.

Some of the other Bitcoin implementations that are still actively maintained are:

-Bitcoin Knots -Libbitcoin -nix-bitcoin -Gocoin -BTCD

@lopp maintains an excellent page with links to all of them.

Why aren't they popular?

The dominance of Bitcoin Core goes back to Satoshi.

Not only is Core the direct descendant of Satoshi's original code, he also wrote: "I don't believe a second, compatible implementation of Bitcoin will ever be a good idea."

The reason he gave was that "So much of the design depends on all nodes getting exactly identical results in lockstep that a second implementation would be a menace to the network."

Menace? What's the big deal?

The big deal is a chainsplit.

You've probably heard that the chain with the most proof of work is the true chain.

when two different miners find a block at the same time, the chain splits and other miners start building on whichever block they heard about first.

As soon as a new block is added to one side of the split, most nodes and miners accept that as the new true chain and abandon the other side of the split (these blocks are referred to as stale blocks, some people call them orphans).

Since the average time between blocks in Bitcoin is ten minutes, it is likely the whole network will learn about this new block before one is added to the losing side of the split, and the chain with the most work wins.

"Nodes will follow the valid chain with the most work...The key word here is valid. If the node receives a block that it determines invalid, it doesn't matter how much work is done on top of that block, the node will not accept that chain."

Like @achow101 says above, the key word is valid. The menace shows up when a miner finds a block that some other miners and nodes think isn't valid.

Miners who think it is valid will try to build new blocks on that chain. Miners who think it isn't valid will try to build on the last valid block they know about: Two chains and no way to know which is true.

How in the world would such a thing come to pass?

Well, if there is a bug in one implementation of Bitcoin that is not in other implementations, it could lead to a lack of consensus about whether a block is valid or not.

Bitcoin does not have a mechanism for fixing this. The community outside of the protocol has to decide what happens next. It sounds very unpleasant.

So much so, that @peterktodd has said other implementations need to match Bitcoin Core Bug-for-bug.

There you go: multiple implementations are dangerous!

But hang on a second, isn't Bitcoin the permissionless protocol of our FOSS dreams where everyone gets to put on blue facepaint and yell FREEDOOOOOOOOOM!!?

Bitcoin is permissionless.

Anyone can download the chain.

Anyone can interact with the network.

And nobody can stop you from coding or running an alternate implementation.

But this is about if you SHOULD.

A catastrophic chainsplit, where a significant portion of nodes and miners accidentally forked off, would not be good for Bitcoin (certainly not it's price). But it wouldn't threaten Bitcoin's permissionless nature.

A centralized development environment where everyone only builds Bitcoin Core could threaten permissionlessness.

It seems to me that the risk of a fork is less than the risk of increased centralization.

Therefore, I like the idea of running alternate implementations. For it to matter, though, I've probably got to use it to verify coins I receive and broadcast my own transactions. And I have to admit, that makes me nervous.

As @ODELL says, it's about trade-offs.

There is a great (though from 2016) article about this debate by @AaronvanW in Bitcoin Magazine.

You can also read an informative thread on BitcoinTalk from summer 2022 about it.

view all related items

204 sats \ 1 reply \ @clownworld 28 Oct 2022 freebie

It’s natural that the dominant implementation, in early stages, would basically end up defining the protocol. This happened with the web as well.

However, as protocols mature, everyone realizes that there need to be other implementations and there needs to be a specification everyone can rely on, so they improve the specs. Bitcoin has been bad about this, taking the lazy route of calling core the standard. That is not a helpful way to proceed for Bitcoin as a protocol, if there are to be any other implementations.

And why are multiple implementations good? If a catastrophic bug appeared in core, and even 1/3 of the network used other implementations, things would work out ok. Otherwise we could see downtime or worse. Decentralization and redundancy prevent the brittleness of a single implementation from catastrophic failures. Anyone who says otherwise should be viewed with extreme skepticism.

0 sats \ 0 replies \ @ek 28 Oct 2022

If a catastrophic bug appeared in core, and even 1/3 of the network used other implementations, things would work out ok.

It depends on where the bug is. In consensus code? Then we all are fucked. But we would be less fucked if there is only one implementation out there, since then no fork was created. We can fix the issue in one place.

I prefer to put all our brain power into one implementation to make sure no bugs happen at all instead of maintaining multiple implementations where bug / incompatibilities would be more probable.

627 sats \ 1 reply \ @nullcount 27 Oct 2022

Different implementations of Bitcoin are useful for non-consensus software.

LND uses btcd (both written in Golang). LDK uses rust-bitcoin (both written in Rust).

The Rust community is know for doing things "the right way". And they recommend against using rust-bitcoin for consensus code (i.e. fully validating blockchain data).

It technically supports doing this, but doing so is very ill-advised because there are many deviations, known and unknown, between this library and the Bitcoin Core reference implementation. In a consensus based cryptocurrency such as Bitcoin it is critical that all parties are using the same rules to validate data, and alternative implementations are simply unable to guarantee they implement the same rules as Core.

Given the complexity of both C++ and other languages, it is unlikely that this will ever be fixed.

0 sats \ 0 replies \ @ek 28 Oct 2022

It technically supports doing this, but doing so is very ill-advised because there are many deviations, known and unknown, between this library and the Bitcoin Core reference implementation. In a consensus based cryptocurrency such as Bitcoin it is critical that all parties are using the same rules to validate data, and alternative implementations are simply unable to guarantee they implement the same rules as Core.

^ This, thank you!

Also thank you for the distinction why LN can use different implementations but consensus code should not.

227 sats \ 6 replies \ @nerd2ninja 27 Oct 2022

I am pro multiple implementations. A situation where core has to adapt to an alternative implementation, is a situation where we don't have to accept the structure of how code is merged to core as the government of our money.

That being said, I do believe the way core does review BIPS and merge them to core is the best implementation we have, so I don't really feel like jumping to a different implementation XD

8 sats \ 0 replies \ @tomlaies 27 Oct 2022

This. YESSSSSS! Decentralize the whole stack!

0 sats \ 4 replies \ @ek 27 Oct 2022

Core will most likely never need to adapt. It can keep running its own rules while everyone else either forks away or also uses the same rules.

What we call Bitcoin will most likely be decided by who is compatible with the previous rules which were defined by core, the reference implementation.

3 sats \ 3 replies \ @nerd2ninja 27 Oct 2022

This assertion assumes core is the dominant implementation. It doesn't have to be, and a future of disagreeable developers could drive a shift to the alternative implementations which would make core the minority implementation.

0 sats \ 2 replies \ @ek 28 Oct 2022

Well, it is the dominant implementation. Yes, you can argue that this could change but I don't see how or why. Why would it need to change? If bitcoin is based on consensus, we all have to run the same code anyway (doesn't matter which programming language). Why take the risk to fork or rewrite core if what you end up with is code which requires to do the same as core or you just created a fork or risk your transactions not being valid to core nodes.

Other arguments:

A second version would be a massive development and maintenance hassle for me. It's hard enough maintaining backward compatibility while upgrading the network without a second version locking things in. If the second version screwed up, the user experience would reflect badly on both, although it would at least reinforce to users the importance of staying with the official version. If someone was getting ready to fork a second version, I would have to air a lot of disclaimers about the risks of using a minority version. This is a design where the majority version wins if there's any disagreement, and that can be pretty ugly for the minority version and I'd rather not go into it, and I don't have to as long as there's only one version.

I know, most developers don't like their software forked, but I have real technical reasons in this case.

-- https://bitcointalk.org/index.php?topic=195.msg1611#msg1611

Exactly. tl;dr: if you accept a block as valid due to a bug that others reject, you're forked and the world ends.

-- https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2014-November/006878.html

(reused the links from the original post)

5 sats \ 1 reply \ @nerd2ninja 28 Oct 2022

You didn't make any new points.

Yes it is the dominant implementation, and I currently like the core developers, but human nature being what it is, at some point there will be some key developer who determines who gets added and who gets kicked from the core repo who turns arrogant and ignores social consensus. Yes that is not the case now but don't miss the point.

Now, a new point. I like the idea of super soft forks. Wherein an alternative implementation soft forks, rather than merge with the majority implementation. If the soft fork has a bug that hard forks them from consensus, instead of accepting the bug as consensus, we can just fix the bug. Yes this would mean you'd be forked until the fix came in (or you imported your private keys to a working implementation in the meantime), but while it was working you had access to use a soft fork feature that the majority didn't have and the majority keeps their security in the meantime.

Being forked also doesn't mean the world ends. You just have to understand what you're getting yourself into and accept the risks with as much mitigation as you can.

0 sats \ 0 replies \ @ek 28 Oct 2022

Yes it is the dominant implementation, and I currently like the core developers, but human nature being what it is, at some point there will be some key developer who determines who gets added and who gets kicked from the core repo who turns arrogant and ignores social consensus. Yes that is not the case now but don't miss the point.

Now, a new point. I like the idea of super soft forks. [...]

Both are fair points.

Being forked also doesn't mean the world ends. You just have to understand what you're getting yourself into and accept the risks with as much mitigation as you can.

That's where I disagree.

But I think we can agree to disagree :)

27 sats \ 0 replies \ @BITC0IN 27 Oct 2022

my two satoshis. so long as there is one dominant implementation then it's fine to have multiple implementations and even healthy, since edge cases can be uncovered through such bugs.

these different implementations are also potential safe havens in a worse case scenario.

overall, they're a net good as it currently stands.

25 sats \ 10 replies \ @WaraiOtoko 27 Oct 2022

Feel free to run an alternative implementation, you are absolutely right on bitcoin being permissionless and FOSS.

However, as you mentioned, a chainsplit is a risk and the outcome can be messy. When things get messy, it is safer to be on the side of the majority. So Bitcoin Core may not be your implementation, but a bug in Bitcoin Core could very well be your problem.

231 sats \ 6 replies \ @tomlaies 27 Oct 2022

Chain split is not a problem. Where does this FUD even comes from.

Implementation follows specification.

That's how computer science always works, that's how the Bitcoin protocol works. Not the other way round, why should the Bitcoin-core implementation be the authority.

I can truly only shake my head about this. Why do Bitcoiners suddenly forget that decentralization was the whole point from the beginning. Why are we forgetting this and becoming defensive when it's about the Bitcoin implementation? Is it cognitive dissonance? I truly truly don't get it.

561 sats \ 0 replies \ @WaraiOtoko 27 Oct 2022

Implementation is not the same as specification. Bugs happen, and they are never specified. Chain splits are a risk and have happened in the past. When it happens either there is a hardfork into two coins, or one of the two chains is abandoned. Neither is a positive outcome, and bitcoin will be (seen as) damaged either way.

Bitcoin is open source, and open source is decentralized. If you are not happy with Bitcoin Core feel free to fork the code or start your own implementation.

0 sats \ 3 replies \ @ek 27 Oct 2022

The thing is: you can run your own implementation. No one stops you.

It just doesn't make sense since bitcoin is also based on consensus. So your implementation (or should we say, fork if you don't abide by the rules of core?) doesn't matter if it has no consensus and you just risk forking yourself away from the chain (assuming there are also miners who run your implementation).

Shaking your head about only one implementation being out there is the same as shaking your head that bitcoin woris only one chain with the most consensus behind it.

There is no cognitive dissonance at play here. Just pure game theory of bitcoin at work.

If you want to change the protocol, you have to contribute to core since that's the best way to make sure enough people will in the end actually run your code.

Just my 2 sats

1001 sats \ 1 reply \ @Scoresby OP 27 Oct 2022

The question I was trying to get at is whether we should spend time and effort trying to increase the percent of nodes/miners who use implementations other than Core (even though it increases the severity of a chain split).

Bitcoin is permission less, but it's also political.

0 sats \ 0 replies \ @ek 28 Oct 2022

I think we should prevent the risks of having a single implementation (censorship, centralization) with repository mirrors, more transparent release process (don't know how transparent it already is), node signalling for features instead of only miners etc. for example.

But I think the solution is not to create multiple implementations which will be very hard to be 100% compatible with each other for ever while also making it harder to upgrade the network since now you need to maintain/care about multiple implementations.

You initiated a very good discussion, thank you. Here, have some more sats, the original post is "undervalued".

0 sats \ 0 replies \ @ek 27 Oct 2022

Just saw my typo:

same as shaking your head that bitcoin woris only one chain with the most consensus behind it.

Wanted to say "that bitcoin works by having only one (valid) chain ..."

0 sats \ 0 replies \ @Scoresby OP 27 Oct 2022

I don't come from the computer science world, but the main impression I get from Bitcoiners is that 90%+ nodes and miners running Bitcoin Core is no big deal. It is surprising that there isn't a larger push to develop different implementations and the communities that support them.

1 sat \ 2 replies \ @Scoresby OP 27 Oct 2022

It's not so much a defense against bugs, as it is a defense against the centralization of protocol development (that carries with it the risk of increasing the damage done by bugs).

It may be safer to be on the side of the majority, but the question is should we try to make the majority less major, or is that too risky (something that many people seem to believe)?

5 sats \ 0 replies \ @clownworld 28 Oct 2022 freebie

It’s both.

0 sats \ 0 replies \ @ek 27 Oct 2022

Bitcoin is based on consensus. And consensus by definition needs a majority. So it makes sense that the majority runs the same code.

Since they agree on the rules already anyway. So why use another implementation?

33 sats \ 5 replies \ @sommerfeld 27 Oct 2022

The risk of a chain split is worth it.

If the bitcoin-core repo is state captured, a competing implementation is a safe haven.

Even though anyone can (software) fork the bitcoin-core repo, relying solely on that would create a period of great instability with multiple software forks and redistributions of the pre-state-capture bitcoin-core.

0 sats \ 4 replies \ @ek 28 Oct 2022

If the bitcoin-core repo is state captured, a competing implementation is a safe haven.

How would it be state captured? And why would a competing implementation not be state captured?

11 sats \ 3 replies \ @sommerfeld 28 Oct 2022

How would it be state captured?

They can just take over the repo, replace the devs, etc. Stare capture is just an example. The current devs can also be paid off, go rogue, there could be a civil war inside the main devs (different from the blocksize war where all devs were aligned).

And why would a competing implementation not be state captured?

It can, but it's easier to capture 1 software project than to capture multiple.

5 sats \ 2 replies \ @rolator 28 Oct 2022

So, They capture the software... and then what? The code is still open source and everyone can audit it and decide for themselves if they want to run it.

51 sats \ 1 reply \ @sommerfeld 28 Oct 2022

Software needs to be constantly maintained, node operators will need to pick either a maintained software fork or an alternative implementation. Staying on an unmaintained version for a long time is just asking for trouble.

As I mentioned in my original comment, if there is no alternative implementation, there can be a period of instability with no clear winning software fork. There could be potentially disastrous with constant chainsplits and undefined chain states.

0 sats \ 0 replies \ @rolator 29 Oct 2022

I see your point, but in order for that to happen the gov would have to buy off pretty much every single developer, no? If the 'main' repo starts to hard fork it needs the networks approval as well, or another code-fork will become the 'main' repo. We haven't seen that happen yet, but that's how i imagine it to go down. Bitcoin is kinda unique in that regard, that splits can happen both in the code and in the network. I agree with your statement that in such a case there could be instability if no clear winner arises. If the attack is launched systematically the attacker would probably make sure to devide the network in as many parties as possible, to make sure there is no clear 'rival'.

0 sats \ 0 replies \ @faithandcredit 28 Oct 2022

Risk of chain split and orphans go up with multiple implementations, so bad for miners, and bad for people who accept 1 confirmation payments. But the chain splits and orphans would still be uncommon and it would only be a minor issue I think.

0 sats \ 0 replies \ @selfish_gene 27 Oct 2022

здорово... просто будем это использовать. если прижевется то останется в системе... если нет, то просто исчезнет... все просто