“Skyv datoen tilbake to måneder. OP_EVAL er bare ikke klar ennå. ”

Det var dommen Gavin Andresen hadde jobbet så lenge for å unngå. Med en enkelt irettesettelse sendt fra Russell O’Connors tastatur, ble en måneders innsats for å oppgradere Bitcoin – den første i kjølvannet av grunnlegger Satoshi Nakamotos utgang – brått stoppet før implementering.

Som avslørt av O’Connor, kunne den foreslåtte kommandoen – varslet av Andresen som den “raskeste veien” til sikrere Bitcoin-lommebøker – bli utnyttet til å lage transaksjoner som ville sende programvaren til en uendelig beregningsløyfe i et forsøk på å validere dem..

Kort sagt, OP_EVAL kan misbrukes for å krasje Bitcoin-noder, og dermed Bitcoin-nettverket.

“Det tok meg hele 70 minutter å lete etter å finne denne feilen,” skrev O’Connor og fordømte en prosess som hadde slått sammen – og nesten presset – dårlig kode inn i programvaren. “Dere må stoppe det dere gjør og virkelig forstå Bitcoin.”

Det var det første alvorlige tilbakeslaget for Andresen, prosjektets nye leder, som var rask til å protestere. Etter hans oppfatning ville det å forlate OP_EVAL ikke bare kaste bort måneder med koding og gjennomgang, det ville etterlate brukere uten verktøy for å beskytte mot trojanere og virus og deretter plyndre deres digitale lommebøker.

Dette var kjernen i OP_EVALs appell – enkle multisignatur-lommebøker ville tillate brukere å gjenopprette bitcoin, selv når sikkerhetskopier gikk tapt; tjenester kan bygges for å sende banklignende varsler, avskrekke svindel og tyveri; og enda bedre, alt dette kan oppnås i transaksjoner som ser ut og oppfører seg slik brukerne kjente og forsto.

Men O’Connors advarselsord var nok for de som hadde sett bekymringene for det økende tempoet i utviklingen validert.

“Jeg vil minne alle om at vi har det med en $ 20 + million dollar ting”, skriver utvikler Alan Reiner. “Det er mer enn bare en programvare som står på spill – alt som går inn må være like hardt som diamant.”

Svikt i OP_EVAL vil ennå få større implikasjoner. Det var sant at Nakamoto hadde lansert verdens første desentraliserte digitale valuta, men løftet var langt fra oppfylt. Få i slutten av 2011 forsto koden sin, og færre hadde fortsatt ferdighetene og kjennskapen til å beskytte den.

Hvordan skal disse utviklerne organisere seg? Hvilket ansvar hadde de overfor brukerne? Og hvordan ville de vedta endring når det ikke var klart hvem – hvis noen – skulle ha det siste ordet?

Slike spørsmål vil snart komme frem i den første store kampen om Bitcoin-programvaren.

En uortodoks arv

Gratis og åpen kildekode-prosjekter blir ofte ledet av grunnleggere, som igjen må tilpasse innsatsen til bidragsytere som deres arbeid er avhengig av. Der det imidlertid oppstår rettskonflikter, er de gjennomsyret av en naturlig autoritet til å fungere som beslutningstakere for deres kreasjoner.

Bitcoin var tidlig ikke noe unntak. I de to første årene av eksistensen spilte Nakamoto rollen som hovedutvikler og velvillig diktator. Som Bitcoins ubestridte leder vedtok han hele åtte protokollendringer uten å ligne mye på en bredere diskurs [1]. Det vil si til han gradvis gikk bort fra prosjektet.

Ved utgangen av 2010 ville Nakamoto slette sitt pseudonym fra Bitcoin.org-nettstedet, og etterlot veteran 3-D grafikkutvikler Gavin Andresen til å hevde kappen som prosjektets “de facto lead” [2].

Andresens foretrukne ordvalg var hensiktsmessig, ettersom omstendighetene rundt denne overgangen var uvanlige, som utgjorde en kort offentlig melding, en privat pliktoverføring og utveksling av en nøkkel som tillot brukeren å sende en systemomfattende varselmelding.

På den tiden utgjorde dette likevel få vanskeligheter for Bitcoins lille, men voksende gruppe kodere. De fleste var bekymret for kritiske løsninger, og Andresen, ektefellen til en fast professor, hadde tid og entusiasme til å lede arbeidet [3].

Faktisk var det mange presserende behov – raskere synkronisering, bedre testing – men de “økte rapportene om stjålne lommebøker” og den “dårlige PR” tyveriene forårsaket raskt, kom frem som et hovedanliggende..

For en tid var det et mål som Bitcoins nye gruppe med bidragsytere alle syntes å være enige om [4].

Bare Multisig

Heldigvis hadde tegningen av en løsning blitt levert av Nakamoto. Som Andresen ville lære, gjorde Bitcoins kode allerede det mulig for brukere å opprette sikre transaksjoner som bare kunne brukes når de ble signert med flere private nøkler [5].

Med multisignatur, eller multisig for kort, kan private nøkler lagres på flere enheter, i motsatte ender av verden, eller deles mellom en bruker og en lommeboktjeneste, noe som betyr at hackere må gå på akkord med flere mål for å stjele mynter.

Forelsket i ideen, ville Andresen bli den første mesteren, og henviste til en lidenskapelig bønn på adresselisten for å inspirere bidragsytere til handling.

“Min største bekymring er at vi vil si:” Visst, det vil bare ta et par dager å bli enige om hvordan du gjør det riktig, “og om seks måneder er det fortsatt ikke enighet,” skrev han [6]. “Og folks lommebøker [vil] fortsette å gå seg vill eller bli stjålet.”

Bekymringene var ikke uten vekt – som implementert av Nakamoto, hadde multisig betydelige ulemper. Den mest presserende av disse var at transaksjonene var inkompatible med Bitcoins standard adresseformat, og i stedet krevde mye lengre adresser.

På grunn av dette var transaksjoner som finansierte multisig lommebøker større og krevde høyere avgifter. Dessuten måtte disse avgiftene ikke betales av personen som mottok bitcoin med multisig-lommeboken, men av personen som sendte bitcoin til dem.

På grunn av disse suboptimale egenskapene ble multisig-transaksjoner betegnet som “ikke-standard” i programvaren, noe som betyr at de ikke nødvendigvis vil spre seg til noder i nettverket. Hvis en node mottok en multisig-transaksjon, ville den bare ignorere den. På samme måte var det ingen garanti at gruvearbeidere ville inkludere disse transaksjonene i blokker.

Hvis de ble inkludert, ville noder akseptere dem (multisig-transaksjoner var til slutt gyldige). Men i praksis gjorde betegnelsen det hele, men umulig å få disse transaksjonene bekreftet.

Skriv inn OP_EVAL

For å frigjøre potensialet han så, ville Andresen fortsette å kjempe for en ny “op-kode”, en type kommando som noder kunne bruke til å avgjøre om og når nye typer transaksjoner skulle være gyldige.

Designet for å imøtekomme mer avanserte transaksjoner som multisig, OP_EVAL lente seg tungt på hashes, det kryptografiske trikset som krypterer og komprimerer data deterministisk, men irreversibelt til en unik tallstreng.

Først foreslått av den pseudonyme utvikleren ByteCoin, var den grunnleggende ideen at brukere kunne hasjinstruksjoner som beskriver forholdene under hvilke bitcoin senere kunne brukes (inkludert til og fra multisig lommebøker) ved å inkludere denne hashen i en transaksjon. Mynter vil i det vesentlige bli sendt “til” en hasj.

Betingelsene som kreves for senere bruk av bitcoin, vil bare bli avslørt når myntene ble brukt “fra” hasjen. En multisig-bruker ville betale for den ekstra transaksjonsstørrelsen når hun brukte myntene, mens ekstra data som kreves utgjorde en mindre belastning på nettverket.

Ettersom forslaget fikk positive tilbakemeldinger, kastet ikke Andresen bort tid, og foretrakk å få OP_EVAL distribuert før snarere enn senere.

“Sikkerhet er veldig høyt på prioritetslisten; Jeg vil gjerne se sikrede Bitcoin-adresser i folks forumunderskrifter innen et år, ”skrev han [7].

Ikke alle delte Andresens følelse av haster, derimot. OP_EVAL ville være en stor oppgradering på et live system som allerede har millioner av dollar i verdi. Over havet fra Andresen foreslo en ung Amir Taaki utviklere å ta seg tid til å gjennomgå forslaget.

“Det virker bra ved første øyekast,” skrev Taaki [8]. “Men hurtigsporing av dette i blockchain er sannsynligvis ikke en klok idé … Bitcoin eksploderer ikke i morgen, så det er ikke noe stort tap å holde ut med betydningsfulle endringer som disse.”

Ytterligere kompliserende forhold antok utviklere å legge til OP_EVAL i protokollen ville utgjøre en betydelig koordineringsutfordring. I hovedsak ville det å vedta det kreve å risikere at blockchain, den endelige oversikten over alle Bitcoin-transaksjoner, håndhevet av den delte konsensus om programvarereglene, kan splitte seg i inkompatible nettverk..

Dette betydde at så snart OP_EVAL ble satt i live, ville hver bruker måtte bytte til en ny versjon av programvaren, og en ny blockchain, i det som ble kalt en “hard fork” -oppgradering.

Unnlater å oppgradere i kor, og gruvearbeidere kan uvitende produsere “ugyldige” blokker. Enda verre, brukere kan uvitende akseptere “ugyldige” transaksjoner.

En ny slags myk gaffel

Men raskt nok skjønte Andresen at det var mulig å overtale motstanderne hans.

Som et kjipt triks avdekket han at OP_EVAL kunne distribueres ved å omdefinere en av flere inaktive op-koder som Nakamoto opprinnelig inkluderte som plassholdere for fremtidige kommandoer.

Til overraskelse for alle, inkludert Andresen, vil dette også være kompatibelt med noder som ikke oppgraderte for å godta OP_EVAL. Disse nodene vil sjekke at hasjen samsvarer med de nye instruksjonene, men vil ikke håndheve dem, i stedet for å godta transaksjonene som standard.

Så lenge et flertall av gruvearbeidere håndhevet de nye reglene, betydde dette at den nye blockchain ville bli ansett som gyldig av både oppgraderte og ikke-oppgraderte noder. Oppgraderte noder ville akseptere blockchain fordi de nye reglene ble håndhevet, mens noder som ikke klarte å oppgradere, ville godta blockchain fordi de ikke brydde seg om de nye reglene på noen måte.

Slike bakoverkompatible oppgraderinger, eller “myke gafler”, hadde allerede blitt utplassert av Nakamoto, men ettersom nettverket hadde vokst i størrelse, hadde utviklere begynt å bekymre seg for det store antallet mennesker som ville trenge å være involvert i enhver oppgradering..

Ikke overraskende ble Andresens innsikt om at dette kunne unngås velkommen av andre etablerte bidragsytere, som han raskt delte nyheten med..

“Wow. Gavins poeng om at [OP_EVAL] kan gjøres uten splitt, sprengte meg, ”bemerket Gregory Maxwell og reagerte på oppdagelsen i sanntid [9]. “Ta ut [sic] -kampanjen.”

Med dette fortsatte utviklerne å utvikle en enda sikrere metode for å aktivere myke gafler. De teoretiserte at de kunne gjennomføre noe som en avstemning for å avgjøre når en funksjon hadde bred nok støtte fra gruvearbeidere, som de deretter kunne bruke for å sikre en sikker oppgradering.

Gruvearbeidere vil bli bedt om å inkludere litt data i blokkene de utvunnet for å signalisere at de vil håndheve de nye reglene. Når flertallet var klare, kunne endringen aktiveres [10].

Den fatale feilen

Men alt dette arbeidet ble angret av O’Connors funn [1. 3].

Resultatet var en splittelse i fraksjoner, med noen som mente at OP_EVAL ble unødvendig forsinket, og andre som argumenterte for de raske løsningene som ble foreslått, ville svekke visse ønskede egenskaper ved Bitcoins essensielle skriptspråk14].

Utviklere inkludert Luke Dashjr, Pieter Wuille og Maxwell foreslo alternativer som, i likhet med OP_EVAL, benyttet konseptet med å sende mynter “til” en hasj. Men utfordringen var fortsatt å få denne logikken, som de startet referert til som “betal til skript hash” eller “P2SH,” til Bitcoin som en myk gaffel og unngå en blockchain split.

Eksisterende op-koder kunne bare gå så langt: ikke-oppgraderte noder ville trenge å godta transaksjoner som brukte mynter fra hasj, uten å forstå de nye reglene.

Det var Andresen som fant en vei fremover, og hans spesifikke P2SH-løsning ville ikke kreve en ny op-kode i det hele tatt. Snarere var Andresens idé at Bitcoin kunne programmeres til å gjenkjenne et bestemt format for transaksjoner, og deretter tolke dette formatet på en ukonvensjonell måte for å validere det ved hjelp av nye instruksjoner..

Enhver node som ikke oppgraderte, ville tolke det ukonvensjonelle formatet ved hjelp av konvensjonell logikk. Som med OP_EVAL, vil transaksjonen alltid bli ansett som gyldig av ikke-oppgraderte noder. Dette betydde at P2SH kunne distribueres som en myk gaffel: så lenge et flertall av hash-kraft håndhever de nye reglene, vil både gamle og nye noder være enige om den samme blockchain.

Andresens forslag virket tilfredsstillende for de fleste. “Virker … akseptabelt fra første øyekast,” svarte O’Connor [15]. Taaki, med henvisning til kodens ukonvensjonelle tilnærming, sa: “Ideen er et hack…. men jeg liker det.”

På et påfølgende utviklermøte holdt følelsen, og deltakerne enige om å implementere Andresens P2SH-forslag. Gruvearbeidere ville bli undersøkt i uken frem til 1. februar, og hvis et flertall av hashkraft (55 prosent) signaliserte støtte, ville en klient bli frigitt for å aktivere den myke gaffelen bare to uker senere.

Freden ville vare noen dager.

Hvorfor ikke bruke USD?

Å bryte konsensus ville være Dashjr, som hadde måttet forlate møtet tidlig og først senere fikk vite at Andresens versjon av P2SH hadde vært det aksepterte kompromisset.

Den ukonvensjonelle naturen til Andresens løsning irriterte Dashjr, som mente det kompliserte protokollen og førte til usikre konsekvenser. Han tok opp spørsmålet med Andresen, men sistnevnte var ikke overbevist om at hans bekymringer fortjente en planendring [16].

Hans forslag forkastet, Dashjr ville bryte ut på det offentlige BitcoinTalk-forumet i midten av januar, og fordømte P2SH og lade Andresen var “alene” for å støtte endringen [17].

“Gavin tvinger alle som bruker den nyeste Bitcoin-koden til å stemme på [P2SH],” skrev han. “Hvis du vil motsette deg denne vanvittige protokollendringen, må du endre BitcoinD-kildekoden din, ellers vil du stemme på FAVOR OF IT som standard.”

På grunn av nyansen i hans innvendinger, den friske tenoren de ble levert i og hans anklager om Andresen, var svarene på innlegget mindre enn positive. I stedet for å begrense den tekniske debatten til utviklere, oppfattet noen Dashjr som å prøve å anspore til en populær pøbel.

Det hjalp ikke at Dashjr var en av prosjektets mer kikotiske bidragsytere, kjent for sine lange argumenter for å forsvare alternative tallsystemer og sterk kristen tro. En forumbruker sa at Dashjrs kommentarer fikk ham til å se “mentalt ustabil ut [18]. ” En annen sa at han ikke ville bry seg med detaljene i det hele tatt; han bare stolte på Andresen [19].

Som svar lanserte Dashjr en vedvarende innsigelse mot P2SH-forslaget av filosofiske grunner, og bestred ikke bare dets tekniske fordeler, men dets implikasjoner for styring.

“Hvis du vil ha en monarkial valuta, hvorfor ikke bare bruke Fed’s USD?” Dashjr spurte sine motstandere, bare for å bli jaget av andre som hevdet at det var han som konkurrerte om makt [20].

Dashjr koder ikke for en annen versjon av P2SH, kalt CheckHashVerify (CHV). CHV var egentlig en annen P2SH-implementering – men det krevde ikke en ukonvensjonell tolkning av transaksjonsutgangene. I stedet la CHV til en ny op-kode som, i likhet med OP_EVAL, kunne “forkles” som en plassholder-op-kode..

Men for Andresen var det for sent for mer debatt [21]. Rastende over det offentlige utbruddet svarte han med sitt eget og skrev:

“Luke, du prøver min tålmodighet. Jeg kommer til å gå vekk fra koden i noen dager for å roe meg ned før jeg gjør noe dumt. “

Genjix blir offentlig

Ettersom Andresens P2SH-design (nå bare referert til som P2SH) i stor grad ble sett på som en god nok løsning foretrukket av prosjektets hovedutvikler, fant Dashjr seg selv med få forsvarere.

Det ville falle på Taaki å være mindretallets stemme for å ta alvorlige bekymringer – men ikke fordi han motsatte seg Andresens løsning eller nødvendigvis var enig med Dashjrs.

Utvikleren, da i begynnelsen av 20-årene, var allerede en av Bitcoins mest frittalende bidragsytere, og mens han ennå ikke hadde blitt den overordnede anarkisten som hacket fra knebøy og reiste med 3D-trykte våpenløpere, hans visjon for programvaren en anti-etableringsbevegelse hadde allerede presset ham ut av prosjektets indre sirkel.

Dette hadde på sin side gjort Taaki mistillit til prosjektets akselererende utviklingsprosess. Han foretrakk det hvis beslutningsprosessen tok tid og involverte den bredere brukerbasen.

Etter hans syn ble Bitcoin ikke tjent godt av en liten kabal av utviklere som kalte skuddene. Taaki følte sterkt at alle med interesse for prosjektet burde være klar over kompromissene, og i den grad det er mulig delta i beslutningstaking.

“Jeg vil heller at folk skal si noe om saken, selv om det gjør livet tøffere for utviklere å forklare sine beslutninger,” sa han til andre utviklere [22]. “Jeg føler meg litt bekymret for å fortelle brukerne våre at det er slik det vil være. Du har ikke noe å si og gir dem fingeren.”

Selv om Taaki var enig i at forskjellen mellom Andresens P2SH og Dashjrs CHV-forslag var liten, fortsatte han at det å få brukere involvert i utviklingsprosessen var en viktig øvelse.

“[M] y bekymring er en dag at Bitcoin blir ødelagt. Se denne ekstra granskningen som en mulighet til å bygge en kultur av åpenhet, ”argumenterte han.

For å gjøre dette skrev Taaki et blogginnlegg der han la opp P2SH- og CHV-oppgraderingene og forskjellene mellom de to [23].

Brukerne hadde et valg, var Taakis budskap, og: “Stemmegivning er basert på gruvedrift.”

En oppfylt situasjon

Med sitt valg av ord hadde Taaki utelatt en elefant i rommet. Det var sant, Nakamoto hadde vedtatt myke gafler, men i slutten av 2011 fungerte nettverket ikke lenger slik det gjorde i de første dagene.

Da Nakamoto publiserte stortingsmeldingen i 2008, antok han at bevis på arbeid ville bli levert av brukere som bidro med beregninger via personlige datamaskiner. “Bevis for arbeid er egentlig en-CPU-en-stemme,” hadde Nakamoto skrevet.

Under denne utformingen kan enhver bruker være gruvearbeider og sikre nettverket ved å foreslå blokker, validere transaksjoner sendt av jevnaldrende og håndheve koden forfattet av utviklere.

Men i årene siden programvarens lansering hadde denne modellen blitt foreldet av gründere. Siden Lazlo Hanyesz (av Bitcoin pizza-berømmelse) hadde funnet ut hvordan man skulle generere bitcoin med kraftigere grafikkbehandlingsenheter, hadde spesialister vært opptatt av å gjøre gruvedrift fra en hobby til et lite selskap.

Rundt samme tid introduserte Marek “Slush” Palatinus en metode for å la gruvearbeidere samle hashkraften som trengs for å foreslå blokker og dele overskuddet. Dette gjorde gruvedrift effektivt mindre av et lotteri, og mer av en stabil inntektskilde.

Mot slutten av 2011 kontrollerte bare tre bassenger – DeepBit, Slush Pool og BTC Guild – godt over halvparten av den globale hashkraften. I stedet for en-CPU-en-stemme, var de fleste av “stemmene” nå konsentrert i bare noen få gruvebassengoperatører, som om de var representanter for deres nettbestanddeler..

For noen var det et bevis på at noe var galt i Bitcoin-nettverket. “Jeg ser [et gruvebasseng] bestemme en endring i nettverket som en farse av en avstemning,” argumenterte den tidlige gruvearbeideren Midnightmagic [24].

For andre var gruvesentralisering en uheldig krykke, en måte å gjøre en myk gaffeloppgradering mer håndterbar og derfor mindre risikabel. (Tross alt krevde en sikker utrulling nå deltakelse fra bare en håndfull gruvebassengoperatører.)

Maxwell, for eksempel, var mer resignert overfor en utilfredsstillende virkelighet for hånden [25].

“Hvis det var ikke-triviell pushback, ville både devs og bassenger trekke seg tilbake, men ingen virker i det minste tilfelle imot det nå,” svarte han. “[Jeg] er en god mekanisme å bruke for fremtiden … når vi forhåpentligvis ikke får denne oppslitte situasjonen der Bitcoin ikke lenger er desentralisert.”

Å stemme eller ikke å stemme

At Andresen og Dashjrs stridende forslag ville komme til å legemliggjøre motstridende synspunkter på Bitcoin-styring, ville bare komplisere saken.

Frem til da hadde utviklere alltid snakket om den kommende soft gaffeloppgraderingen som en slags stemme: gruvearbeidere kunne håndheve de nye reglene skissert av P2SH (eller OP_EVAL) med et hashmaktflertall, så en avstemning var ment å måle sannsynligheten for dette utfall.

Men mens terminologien hadde blitt en del av leksikonet, utelatt dette teknisk nyanse. I løpet av en avstemning spurte utviklere ikke akkurat gruvearbeidere hva de syntes om de nye reglene. Snarere så de dette som en måte å se om gruvearbeidere var klare til å sikre en sikker oppgradering.

Fra dette perspektivet var det fornuftig for utviklere at bare ett forslag ville bli lagt til programvarebrukere og gruvearbeidere ville kjøre for å håndheve nettverksreglene.

“Bitcoin-systemet er _NOT_ på valg for flertall. Ikke et flertall av hashpower, ikke et flertall av mennesker, ikke et flertall av penger, ”argumenterte Maxwell, irritert over Taakis innramming av avgjørelsen som en avstemning [26].

Maxwell følte sterkt at miner “stemmer” burde være begrenset slik de var i selve programvaren, til å håndheve rekkefølgen på transaksjoner – ikke reglene i hele nettverket.

“Hva skjer hvis et stort flertall – til og med 100% – av de nåværende gruvearbeiderne bestemmer at tilskuddet skal være 50 BTC for alltid? INGENTING. Gruvearbeidere som endrer regelen i programvaren, slutter ganske enkelt å eksistere fra Bitcoin-nettverkets perspektiv, ”skrev han.

Dashjr var ikke uenig med Maxwell, men i praksis var det vanskelig for ham å se hvordan Bitcoin ville forbli sikker hvis utviklere presser på endringer uten gruvedriftstøtte.

“Gruvearbeidere kan rett og slett nekte å bryte P2SH-transaksjoner for å være immun mot” utviklingsteamets endringer, “svarte han [27]. “Hvis” utviklerne “låser ut alle gruvearbeidere, gjett hva som skjer? Enkle 50% angrep, nettverket er usikret! ”

Sett i dette lyset er det lettere å forstå hvorfor Dashjr mente Andresen misbrukte sin rolle som hovedutvikler ved å forsøke å presse P2SH alene. Hvis en gruvearbeider brukte standardprogramvaren til å bryte en blokk, ville den avgi en “stemme” til fordel for P2SH automatisk [28].

Som svar skrev Dashjr lapper som ville legge inn hans foretrukne forslag i hashmaktens “valg”, og introduserte muligheten for gruvearbeidere å stemme både for og mot P2SH og CHV.

Selv om få gruvearbeidere brukte koden, hadde Dashjrs motstand en effekt. Tycho, operatøren av DeepBit, den gang nettverkets største gruvebasseng, begynte å bli ubehagelig med sin rolle i å evaluere den konkurrerende koden.

Han hevdet at det var klart at det ennå ikke var nådd enighet blant utviklere, og skrev: “Jeg vil ikke bli den eneste enheten som skal bestemme dette [29]. ”

Dødlås

Ved å avvise ideen om at en gruvebasseng, selv som en bekvemmelighet, kunne brukes til å svinge en oppgraderingsbeslutning, la Tycho til en annen vri på debatten. Uten hans støtte, som utgjorde over 30 prosent av all hashkraft, ville P2SH ha vanskelig for å bli aktivert.

Mot slutten av januar nærmet den første P2SH-avstemningsrunden seg slutt, og det så ikke ut som om den skulle oppfylle den nødvendige terskelen. Oppgraderingen måtte forsinkes, en virkelighet som frustrerte ikke bare Andresen, men også andre utviklere.

På IRC beklaget Maxwell offentlig at det ikke syntes noen ende i sikte med fastlåsen.

“Denne ‘skynde’ meme er tull, Gavin startet på [betal-til-skript-hash] -ruten i, hva, oktober?” han skrev[30]. “Så vidt jeg kan se, med mindre noen trekker en frist, vil denne prosessen aldri konvergere fordi det alltid vil være noen NESTE fyr som har en god ide som ble utelatt.”

Andresen ville legge skylden for forsinkelsen ikke på ankomsten av gruvebassenger, men på DeepBits operatør Tycho personlig. “Akkurat nå ser det ut som en person har nok hashing-kraft til å nedlegge veto mot enhver endring,” skrev han [31].

Dette plaget Andresen, som så på Tychos holdning som uetisk. “Jeg synes det er galt av deg å bruke din posisjon som den største bassengoperatøren til å gå imot den generelle konsensusen,” skrev han [32].

Selv når Andresen gikk så langt som å bruke offentlig press, presset brukerne til å be gruvedriftene sine om å oppgradere – og tilbød seg å tilbakebetale alle DeepBits midler i tilfelle P2SH førte til økonomisk tap – Tycho var ikke villig til å “stemme” på forslaget[33].

I møte med forsinkelsen gjorde Andresen et forsøk på å skare publikum til saken, og vedvarte i sin overbevisning at valget mellom P2SH og CHV ville ha liten innvirkning på brukerne.

Andresen skrev:

“Alle [P2SH / CHV] -tingene er for det meste ingeniører som krangler om det er bedre å bruke en spiker, en skrue eller et lim for å sette to trebiter sammen. Noen av løsningene vil fungere, og vanlige brukere vil ikke merke noen forskjell [34]. ”

Bedømt av svarene i tråden, godtok Bitcoin-brukere Andresens ramme, og beskyldte Tycho for å holde tilbake gaffelen og presset ham til å aktivere.

Tycho motsatte seg på det sterkeste Andresens påstand. Selv med 30 prosent hasjkraft visste han at de gjenværende gruvearbeiderne kunne overstyre ham, og han ønsket ikke å være den avgjørende faktoren.

Runde 2

Med P2SH som hittil ikke har klart å samle tilstrekkelig hash-kraftstøtte, ville Andresen i økende grad bli tvunget til å diskutere strategi for forslaget sitt i det fri, og han begynte særlig å akseptere CHV som et potensielt alternativ for å bryte fastlåsen..

Svarene trakk likevel en skillelinje mellom de som trodde valget mellom P2SH og CHV var for gruvearbeidere å ta, og de som favoriserte en mer merokratisk beslutningstaking..

“Til slutt er gruvearbeidere de eneste menneskene som har noe å si om problemer som dette,” hevdet BitcoinTalk-bruker dooglus [35]. “De er de eneste som bestemmer hvilke transaksjoner som blir blokkert.”

Forumets administrator, Theymos, avviste denne ideen direkte. “Ikke-gruvearbeidere kan avvise blokker. Hvis nok klienter gjør dette, vil myntene som gruvearbeiderne mine blir verdiløse. [36] ”

I stedet foreslo Theymos at en viss indre krets av eksperter skulle delta i en to ukers diskusjon og avgi en avstemning på slutten [37]. Enten på grunn av forslaget eller tilfeldigheten opprettet Dashjr snart en Wiki der en liste over respekterte utviklere kunne gi uttrykk for deres preferanser.

I løpet av de neste dagene antydet Maxwell, Thomas og Wuille at de gjerne ville akseptere enten P2SH eller CHV, selv om de gjorde det klart at de foretrakk P2SH. O’Connor og Dashjr var enige om at P2SH var akseptabelt, men uttrykte en preferanse for CHV [38].

Kanskje ikke overraskende, sørget Andresen for å svinge stemmeseddelen til fordel for P2SH og registrere et rungende “nei” mot CHV-forslaget..

Enda viktigere, kanskje veldig få gruvearbeidere støttet CHV. I midten av februar ble P2SH støttet av 30 prosent av hashkraften, mens Dashjrs alternativ satt fast rundt 2 prosent.

Under et møte på IRC sa Dashjr at han vurderte om han skulle trekke CHV helt ut, med motvilje mot å akseptere P2SHs dominans [39]. På det samme møtet ble deltakerne enige om å sette en andre frist for avstemming for 1. mars.

Da den nye fristen nærmet seg, samlet flere gruvearbeidere seg bak P2SH, og brakte hashkraftstøtte nær 55 prosent terskelen. Snart fikk både Tycho og Dashjr ikke annet valg enn å akseptere sine jevnalders preferanser [40].

Med det kunngjorde Andresen at den myke gaffelen ville bli distribuert og aktivert innen ti dager, og innen 1. april 2012 ble de nye reglene håndhevet [41].

P2SH, den første protokolloppgraderingen siden Satoshis avgang, ble vedtatt.

Storm i en tekanne

Den vanskelige politiske prosessen som hadde ført til passering av P2SH, ville fortsatt ha en varig innvirkning utenfor selve programvaren.

Til slutt hadde Andresen klart å distribuere løsningen han både designet og favoriserte. Hvis det kan sies at hans ledelse ble avhørt midt i krisen, var den til slutt sementert.

Den offentlige opinionen, som ikke var bekymret for detaljer, falt i stor grad sammen med Dashjrs handlinger, og i mindre grad Taaki, og anså dem unødvendige og inflammatoriske [42]. Andresen gikk så langt som å be Dashjr om å slutte å bidra til Bitcoin helt, selv om det ser ut til at han enten rykket ned fra den trusselen, ellers så ignorerte Dashjr den bare [43].

I mellomtiden ble Maxwell en av Bitcoins “kjerneutviklere”, og delte tilgang til prosjektet med Andresen og bidragsyterne Wladimir van der Laan og Jeff Garzik.

Tonen hadde blitt gitt: Når det gjaldt Bitcoin-utvikling, ble en støttende, pragmatisk holdning belønnet og motstridende bidragsytere ble avskjediget. Mens ideologiske forskjeller hadde dukket opp, forble de – og uten tvil bare forankret av – prosessen.

Med flere brukere som strømmer til Bitcoin om dagen, gikk P2SH snart over i lore, selv om det spesielt ville fortsette å fungere som et flammepunkt i uenighet blant utviklere..

Andresen minnet hendelsene et år senere som svar på en ny fremvoksende krise, og ville skryte av måter som antyder at han mente P2SH validerte sin ledelse og visjon for prosjektet [44].

“Blokkstørrelsen vil bli hevet,” skrev han, som svar på en video produsert av utvikleren Peter Todd som talte for økningen av grensen tidlig i 2013 [45]. “Videoen din vil bare få mange til å bekymre seg for ingenting, på nøyaktig samme måte som Luke-Jrs [CHV] -forslag i fjor ikke gjorde annet enn å forårsake storm i en tekanne.”

Hvordan skal beslutninger tas for den første desentraliserte digitale valutaen? Hvis spørsmålet endelig hadde blitt stilt, ville det ta en bredere krig, fremdeles år i fremtiden, for å løse det …

Kampen om P2SH: Den utallige historien til den første Bitcoin-krigenKampen om P2SH: Den utallige historien til den første Bitcoin-krigen

Se denne videoen på YouTube