Er det farligt at have flere implementeringer af Bitcoin?

Dette er en meningsredaktion af Bill Scoresby, a bitcoin-based small business owner and writer of several guides for bitcoin self-custody.

The bugs that recently caused many LND nodes to fall out of sync with the Bitcoin blockchain were sandsynligvis forårsaget af en alternativ implementering.

Måske undrer du dig over, "Hvem i alverden bruger andet end Bitcoin Core?” You might not have known that other implementations of Bitcoin existed. Maybe you’re not sure what a different implementation even means.

Bitcoin Core began as the software that Satoshi Nakamoto wrote in C++ and released to the world. It has been updated with new versions leading to the present day. An alternate implementation is software that does the same thing as Bitcoin Core — enforces the same consensus rules — but is written differently, most often in a different coding language.

Hvordan knækkede en alternativ implementering noder på Lightning-netværket?

En af de store Lightning Network-nodeversioner (Lnd) relies on an alternate Bitcoin implementation called btcd. When a developer created a very large multisig transaction, btcd did not see it as valid because it contained too much witness data. Other Bitcoin implementations — most importantly Bitcoin Core — had no such limit on Taproot transaction witness data, and therefore accepted the transaction and the block that contained it as valid.

Resultatet var, at minearbejdere blev ved med at tilføje nye blokke på kæden, fordi de ikke brugte btcd, og ifølge deres regler var der intet galt, men LND Lightning noder kunne ikke genkende nogen af ​​disse nye blokke, fordi de blev bygget oven på blokken, der indeholdt den ene transaktion, de så som ugyldig.

When the bug happened again on November 1, it wasn’t just LND nodes that were affected. Some electrs instances (an implementation of the backend server for Electrum Wallet) also failed to reach consensus with the rest of the chain. While the LND nodes were put out of consensus because of a similar issue in btcd, it was animplementation of Bitcoin written in Rust that fik elektrikerknuderne til at komme bagud, herunder nogle meget synlige servere drevet af mempool.space.

The limit on the size of witness dataexists for at forhindre DoS-angreb, and is a part of Bitcoin Core as well ( although Core has a larger limit for Taproot transactions). It seems that the other two implementations that fell out of sync had code that fastholdt den mindre grænse.

Meget små forskelle i implementeringer kan føre til manglende konsensus.

Having Multiple Implementations Of Bitcoin Is Dangerous

Satoshi didn’t like the idea of multiple implementations of Bitcoin. “I don’t believe a second, compatible implementation of Bitcoin will ever be a good idea.” Grunden til han gav var, "Så meget af designet afhænger af, at alle noder får nøjagtigt identiske resultater i låst trin, at en anden implementering ville være en trussel for netværket."

Trussel? Hvad er den store sag?

Du har sikkert hørt, at kæden med mest bevis-på-arbejde er den sande kæde. Når to forskellige minearbejdere finder en blok på samme tid, splittes kæden, og andre minearbejdere begynder at bygge på den blok, de hører om først.

Så snart en ny blok er tilføjet til den ene side af splittet, accepterer de fleste noder og minearbejdere det som den nye sande kæde og forlader den anden side af splittelsen. Disse blokke omtales som uaktuelle blokke, selvom nogle mennesker kalder dem forældreløse blokke.

Since the average time between blocks in Bitcoin is 10 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.

"Noder vil følge den gyldige kæde med mest arbejde ... Nøgleordet her er gyldigt. Hvis noden modtager en blok, som den fastslår ugyldig, er det lige meget, hvor meget arbejde der udføres oven på den blok, noden vil ikke acceptere den kæde." — Andrew Chow

Nøgleordet er "gyldig". Truslen dukker op, når en minearbejder finder en blok, som nogle andre minearbejdere og noder mener ikke er gyldige. Minearbejdere, der tror, ​​det er gyldigt, vil forsøge at bygge nye blokke på den kæde. Minearbejdere, der mener, at det ikke er gyldigt, vil forsøge at bygge videre på den sidste gyldige blok, de kender til. Resultatet: To kæder og ingen måde at vide, hvad der er sandt.

Hvordan i alverden skulle sådan noget ske?

Well, as we saw in the case of the recent bug with LND nodes, if there is a bug in one implementation of Bitcoin that is not in other implementations, it can 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 Bitcoin developer Peter Todd has said that other implementations need to match Bitcoin Core bug-for-bug.

Der går du: Flere implementeringer er farlige!

What Are The Other Implementations Of Bitcoin And Why Do They Exist?

First of all, most everyone runs Bitcoin Core.

Luke Dashjr ser omkring 43,000 noder, 98% of which are running Bitcoin Core og noget kaldet Coin Dance ser tæt på 15,000 noder, 96% of which are running Bitcoin Core. Så i øjeblikket ser det ud til, at meget få mennesker bruger alternative implementeringer.

Nevertheless, there are active projects that are trying to build and maintain other codebases that implement the Bitcoin protocol. They include:

Jameson Lopp har en fremragende side med en mere udtømmende liste og links til alle de andre implementeringer.

Alle disse projekter har ekstremt dygtige udviklere, der arbejder på dem, og hver har eksisteret i mere end et par år. Hvorfor bruge så mange kræfter på noget, der virker som sådan et problem?

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.

Alligevel klart nogle mennesker har ansvaret of making changes to the Bitcoin repository and the process for choosing them seems informal. While there is the Bitcoin Improvement Proposal (BIP) process for suggesting changes to Bitcoin Core, it is also pretty informal.

Intet af dette er et direkte problem. Som Marty Bent påpeger, grov konsensus kan være en styrke. If the process of changing Bitcoin is difficult and unclear, it means that changes will be more thoroughly vetted.

Det næste trin i grov konsensus er at have mere end én populær implementering.

Ikke at have flere implementeringer kan være mere farligt

There can be no doubt that it is already a very difficult job to be one of the people who has commit access to Bitcoin Core. In a world where Bitcoin plays a central role as a monetary instrument, this job will get much more difficult. A small group of developers could become a very worthwhile target. At the very least, their attention will be sought in order to lobby for various inclusions or exclusions in the next software release.

Think about the lobbying industry that currently exists in politics. Why wouldn’t such a thing develop around the people who have commit access to the only implementation of the Bitcoin protocol?

Ligesom politikere nu, vil de blive opfattet som at have adgang til magten. Som sådan vil folk målrette dem, bortset fra at disse udviklere ikke har en stats muskler til at forsvare dem. Hvad er det for et liv? Hvem ville frivilligt vælge det?

I slutningen af ​​dagen er det globale finansielle system en temmelig tung vægt at hvile på skuldrene af den lille gruppe mennesker, der har forpligtet adgang til ét GitHub-lager. Måske ikke så forskelligt fra det globale finansielle system, vi forsøger at komme væk fra, hvor folks monetære fremtid afhænger af nogle få centralbankers beslutninger.

Flere implementeringer til redning!

The presence and widespread use of multiple implementations on the Bitcoin network can mitigate these pressures by making it much more difficult for a malicious actor to change the Bitcoin protocol.

If participants in the Bitcoin network are more evenly distributed among different implementations, there is more room for good ideas to surface. Proposing changes to Bitcoin or rejecting them is a lot more decentralized if it isn’t all done in one camp.

Clearly, using different implementations of Bitcoin increases the risk of a chain split. A catastrophic chain split — where a significant portion of nodes and miners accidentally forked off — would not be good for Bitcoin, and certainly not its price. But it wouldn’t threaten Bitcoin’s permissionless nature.

A centralized development environment where everyone only builds on Bitcoin Core could threaten permissionless-ness. The conversation about the topic needs to address the risks of relying so heavily on Bitcoin Core rather than focusing solely on what problems might be caused by an alternate implementation.

Der er en stor, ældre artikel om denne debat af Aaron van Wirdum. Du kan også læse en nyere, informativ tråd om det.

This is a guest post by Bill Scoresby. Opinions expressed are entirely their own and do not necessarily reflect those of BTC Inc or Bitcoin Magazine.