”Skjut tillbaka datumet två månader. OP_EVAL är bara inte redo än. ”

Det var den dom som Gavin Andresen hade arbetat så länge för att undvika. Med en enda tillrättavisning skickad från Russell O’Connors tangentbord, stannade en månadslång satsning på att uppgradera Bitcoin – den första i kölvattnet av grundaren Satoshi Nakamotos utgång – före genomförandet.

Som avslöjat av O’Connor kunde det föreslagna kommandot – som kallas Andresen vara den “snabbaste vägen” till säkrare Bitcoin-plånböcker – utnyttjas för att skapa transaktioner som skulle skicka programvaran till en oändlig beräkningsslinga i ett försök att validera dem.

Kort sagt kan OP_EVAL missbrukas för att krascha Bitcoin-noder och därmed Bitcoin-nätverket.

“Det tog mig alla 70 minuter att leta efter det här felet”, skrev O’Connor och fördömde en process som hade slagits ihop – och nästan drivit – dålig kod till live-programvaran. “Ni måste stoppa vad ni gör och verkligen förstå Bitcoin.”

Det var den första allvarliga bakslag för Andresen, projektets nya ledare, som var snabb att protestera. Enligt hans uppfattning skulle övergivande av OP_EVAL inte bara slösa bort månader av kodning och granskning, utan användarna utan verktyg för att skydda mot trojaner och virus och sedan plundra deras digitala plånböcker.

Detta var kärnan i OP_EVALs överklagande – enkla multisignaturplånböcker skulle tillåta användare att återställa bitcoin, även när säkerhetskopior förlorades; tjänster kan byggas för att skicka bankliknande varningar, avskräcka bedrägeri och stöld; och ännu bättre, allt detta kan uppnås i transaktioner som ser ut och beter sig som de användare visste och förstod.

Men O’Connors varningsord var tillräckligt för dem som hade sett sin oro över den eskalerande utvecklingshastigheten validerad.

“Jag vill påminna alla om att vi trasslar med en $ 20 + miljoner dollar sak”, skulle utvecklaren Alan Reiner skriva. “Det finns mer än bara en mjukvara som står på spel – allt som går in måste vara så hårt som diamant.”

Misslyckandet med OP_EVAL skulle ändå få större konsekvenser. Det var sant att Nakamoto hade lanserat världens första decentraliserade digitala valuta, men dess löfte var långt ifrån uppfyllt. Få i slutet av 2011 förstod dess kod, och färre hade fortfarande skickligheten och förtrogenheten för att skydda den.

Hur ska dessa utvecklare organisera sig? Vilket ansvar hade de gentemot användarna? Och hur skulle de anta förändringar när det inte var klart vem – om någon – skulle ha det sista ordet?

Sådana frågor skulle snart dras fram i den första stora striden om Bitcoin-programvaran.

En oortodox arv

Gratis och öppen källkodsprojekt leds oftast av grundare, som i sin tur måste anpassa ansträngningarna till bidragsgivare som deras arbete är beroende av. Men där riktningstvister uppstår är de genomsyrade av en naturlig auktoritet att agera som beslutsfattare för deras skapelser.

Bitcoin var tidigt inget undantag. Under de första två åren av dess existens spelade Nakamoto rollen som huvudutvecklare och välvillig diktator. Som Bitcoins obestridda ledare antog han så många som åtta protokolländringar utan att mycket liknade en bredare diskurs [1]. Det vill säga tills han gradvis gick bort från projektet.

I slutet av 2010 skulle Nakamoto radera sin pseudonym från Bitcoin.org-webbplatsen och lämna veteran 3-D grafikutvecklare Gavin Andresen att hävda manteln som projektets “de facto lead” [2].

Andresens föredragna ordval var lämpligt, eftersom omständigheterna kring denna övergång var ovanliga, vilket innebar ett kort offentligt meddelande, en privat överföring av uppgifter och utbyte av en nyckel som gjorde det möjligt för användaren att skicka ett systemomfattande varningsmeddelande.

Ändå utgjorde detta för närvarande få svårigheter för Bitcoins lilla men växande grupp kodare. De flesta var oroade över kritiska lösningar, och Andresen, makan till en fast professor, hade tid och entusiasm att leda arbetet [3].

Det fanns faktiskt många pressande behov – snabbare synkronisering, bättre testning – men de “ökade rapporterna om stulna plånböcker” och den “dåliga PR” som stölderna orsakade framgick snabbt som ett av de viktigaste problemen..

För en tid var det ett mål som Bitcoins nya grupp av bidragsgivare alla tycktes vara överens om [4].

Bare Multisig

Lyckligtvis hade planen för en lösning tillhandahållits av Nakamoto. Som Andresen skulle lära sig, gjorde Bitcoins kod redan det möjligt för användare att skapa säkra transaktioner som bara kunde spenderas när de undertecknades med flera privata nycklar [5].

Med multisignature, eller multisig för kort, kan privata nycklar lagras på flera enheter, i motsatta ändar av världen, eller delas mellan en användare och en plånbokstjänst, vilket innebär att hackare måste kompromissa med flera mål för att stjäla mynt.

Andresen blev förälskad i idén och blev dess första mästare och pennade en passionerad vädjan på e-postlistan för att inspirera bidragsgivarna till handling.

“Min största oro är att vi kommer att säga,” Visst, det tar bara ett par dagar att komma överens om hur man gör det rätt “, och om sex månader framöver finns det fortfarande ingen enighet,” skrev han [6]. “Och folks plånböcker [kommer] att fortsätta att gå vilse eller bli stulna.”

Bekymmerna var inte utan vikt – som implementerad av Nakamoto hade multisig betydande nackdelar. Den mest pressande av dessa var att transaktionerna var oförenliga med Bitcoins standardadressformat och i stället krävde mycket längre adresser.

På grund av detta var transaktioner som finansierade multisig-plånböcker större och krävde högre avgifter. Dessutom måste dessa avgifter betalas inte av den person som tar emot bitcoin med multisig-plånboken, utan av den som skickar bitcoin till dem.

På grund av dessa suboptimala egenskaper betecknades multisig-transaktioner som “icke-standard” i programvaran, vilket innebär att de inte nödvändigtvis skulle spridas till noder i nätverket. Om en nod fick en multisig-transaktion skulle den helt enkelt ignorera den. På samma sätt fanns det inga garantier som gruvarbetare skulle inkludera dessa transaktioner i block.

Om de inkluderades skulle noder acceptera dem (multisig-transaktioner var i slutändan giltiga). Men i praktiken gjorde beteckningen det omöjligt att få dessa transaktioner bekräftade.

Ange OP_EVAL

För att frigöra den potential som han såg, skulle Andresen fortsätta att slåss för en ny “op-kod”, en typ av kommando som noder kunde använda för att avgöra om och när nya typer av transaktioner skulle vara giltiga.

Designad för att tillgodose mer avancerade transaktioner som multisig, OP_EVAL lutade kraftigt på hash, det kryptografiska tricket som krypterar och komprimerar data deterministiskt, men oåterkalleligt till en unik talsträng.

Först föreslagen av den pseudonyma utvecklaren ByteCoin var grundtanken att användarna kunde hashinstruktioner som beskriver villkoren för att bitcoin senare skulle kunna spenderas (inklusive till och från multisig-plånböcker) genom att inkludera denna hash i en transaktion. Mynt skulle i huvudsak skickas “till” en hash.

Villkoren som krävs för att senare spendera bitcoin skulle bara avslöjas när mynten spenderades “från” hashen. En multisig-användare skulle betala för den extra transaktionsstorleken när hon spenderade mynt, medan den extra data som krävs utgjorde en mindre börda för nätverket.

Eftersom förslaget fick positiv feedback slösade Andresen ingen tid och föredrog att få OP_EVAL distribuerat snarare än senare.

”Säkerhet är riktigt högt på prioriteringslistan; Jag skulle vilja se säkra Bitcoin-adresser i folks forumunderskrifter inom ett år, ”skrev han [7].

Inte alla delade dock Andresens känsla av brådskande. OP_EVAL skulle vara en stor uppgradering av ett live-system som redan har miljoner dollar i värde. Över havet från Andresen föreslog en ung Amir Taaki utvecklare att ta sig tid att granska förslaget.

“Det verkar bra vid första anblicken”, skrev Taaki [8]. “Men att snabbt spåra detta in i blockkedjan är förmodligen ingen klok idé … Bitcoin exploderar inte i morgon, så det finns ingen stor förlust av att hålla av med viktiga förändringar som dessa.”

Ytterligare komplicerade saker, utvecklare antog att lägga till OP_EVAL i protokollet skulle utgöra en betydande samordningsutmaning. I grund och botten skulle det krävas risk för att blockchain, den slutgiltiga registreringen av alla Bitcoin-transaktioner, som tvingas av det delade samförståndet om dess programvaruregler, kan delas upp i oförenliga nätverk..

Detta innebar att så snart OP_EVAL gick i drift, skulle varje användare behöva byta till en ny version av programvaran och en ny blockchain, i vad som kallades en “hård gaffel” -uppgradering.

Misslyckas att uppgradera unisont, och gruvarbetare kan omedvetet producera ”ogiltiga” block. Ännu värre, användare kan omedvetet acceptera ”ogiltiga” transaktioner.

En ny typ av mjuk gaffel

Snart nog insåg dock Andresen att det var möjligt att övertyga sina motståndare.

Som ett snyggt trick upptäckte han att OP_EVAL kunde distribueras genom att omdefiniera en av flera inaktiva op-koder som ursprungligen inkluderades av Nakamoto som platshållare för framtida kommandon.

Till överraskning för alla, inklusive Andresen, skulle detta också vara kompatibelt med noder som inte uppgraderade för att acceptera OP_EVAL. Dessa noder kontrollerar att hashen matchar de nya instruktionerna, men inte verkställer dem, istället accepterar transaktionerna som standard.

Så länge som en majoritet av gruvarbetare tillämpade de nya reglerna innebar detta att den nya blockkedjan skulle anses vara giltig av både uppgraderade och icke-uppgraderade noder. Uppgraderade noder accepterar blockchain eftersom de nya reglerna tillämpas, medan noder som misslyckades med att uppgradera accepterar blockchain eftersom de inte bryr sig om de nya reglerna på något sätt.

Sådana bakåtkompatibla uppgraderingar, eller “mjuka gafflar”, hade redan distribuerats av Nakamoto, men eftersom nätverket hade vuxit i storlek hade utvecklare börjat oroa sig för det stora antalet människor som skulle behöva involveras i någon uppgradering.

Inte överraskande välkomnades Andresens insikt att detta kunde undvikas av andra etablerade bidragsgivare, med vilka han snabbt delade nyheterna.

“Wow. Gavins poäng att [OP_EVAL] kan göras utan splittring sprängde mig, “påpekade Gregory Maxwell och reagerade på upptäckten i realtid [9]. “Ta fram [sic] -kampanjen.”

Med detta fortsatte utvecklarna att utveckla en ännu säkrare metod för att aktivera mjuka gafflar. De teoretiserade att de kunde genomföra något som en enkät för att avgöra när en funktion hade tillräckligt stort stöd från gruvarbetare, som de sedan kunde använda för att säkerställa en säker uppgradering.

Gruvearbetare ombads att inkludera lite data i blocken som de bryter för att signalera att de skulle tillämpa de nya reglerna. När en majoritet var redo kunde ändringen aktiveras [10].

The Fatal Flaw

Men allt detta arbete ångrades av O’Connors resultat [13].

Resultatet var en uppdelning i fraktioner, med vissa som hävdade att OP_EVAL försenades i onödan och andra som argumenterar för de snabba lösningar som föreslås skulle försämra vissa önskade egenskaper hos Bitcoins väsentliga skriptspråk [14].

Utvecklare inklusive Luke Dashjr, Pieter Wuille och Maxwell föreslog alternativ som, liksom OP_EVAL, använde konceptet att skicka mynt “till” en hash. Men utmaningen var fortfarande att få denna logik, som de började kallas “betala till skript hash” eller “P2SH,” till Bitcoin som en mjuk gaffel och undvika en blockchain split.

Befintliga op-koder kan bara gå så långt: icke-uppgraderade noder skulle behöva acceptera transaktioner som spenderade mynt från hash, utan att förstå de nya reglerna.

Det var Andresen som hittade en väg framåt, och hans specifika P2SH-lösning skulle inte alls behöva en ny op-kod. Snarare var Andresens idé att Bitcoin kunde programmeras för att känna igen ett visst format av transaktioner och sedan tolka detta format på ett okonventionellt sätt för att validera det med hjälp av nya instruktioner.

Varje nod som inte uppgraderar skulle tolka det okonventionella formatet med konventionell logik. Liksom med OP_EVAL anses transaktionen alltid vara giltig av icke-uppgraderade noder. Detta innebar att P2SH kunde distribueras som en mjuk gaffel: så länge som en majoritet av hashkraften tillämpade de nya reglerna, skulle både gamla och nya noder komma överens om samma blockchain.

Andresens förslag verkade tillfredsställande för de flesta. ”Verkar … acceptabelt från första anblicken”, svarade O’Connor [15]. Taaki, med hänvisning till kodens okonventionella tillvägagångssätt, sa: ”Idén är ett hack … men jag gillar det.”

Vid ett efterföljande utvecklarmöte höll sentimentet och deltagarna enades om att genomföra Andresens P2SH-förslag. Gruvarbetare skulle undersökas under veckan fram till den 1 februari, och om en majoritet av hashkraft (55 procent) signalerade stöd, skulle en klient släppas för att aktivera mjukgaffeln bara två veckor senare.

Freden skulle pågå några dagar.

Varför inte använda USD?

Att bryta samförståndet skulle vara Dashjr, som hade varit tvungen att lämna mötet tidigt och först senare fick veta Andresens version av P2SH hade varit den accepterade kompromissen.

Den okonventionella karaktären av Andresens lösning irriterade Dashjr, som trodde att det komplicerade protokollet och medför osäkra konsekvenser. Han tog upp frågan med Andresen, men den senare var inte övertygad om att hans oro förtjänade en förändring av planerna [16].

Hans förslag förkastade, Dashjr skulle bryta ut på det offentliga BitcoinTalk-forumet i mitten av januari, och fördömde P2SH och laddade Andresen var “på egen hand” för att stödja förändringen [17].

”Gavin tvingar alla som använder den senaste Bitcoin-koden att rösta på [P2SH],” skrev han. “Om du vill motsätta dig den här vansinniga protokolländringen, måste du ändra din BitcoinD-källkod, annars kommer du att rösta TILLFÄLLIGT PÅ DET som standard.”

På grund av nyanserna i hans invändningar, den fräcka tenoren i vilken de levererades och hans anklagelser om Andresen, var svaren på inlägget mindre än positiva. I stället för att begränsa den tekniska debatten till utvecklare upplevde vissa Dashjr som att försöka anspela en populär mobb.

Det hjälpte inte att Dashjr var en av projektets mer quixotiska bidragsgivare, känd för sina långa argument för att försvara alternativa talsystem och stark kristen tro. En forumanvändare sa att Dashjrs kommentarer fick honom att se “mentalt instabil [18]. ” En annan sa att han inte alls ville bry sig om detaljerna; han litade helt enkelt på Andresen [19].

Som svar inledde Dashjr en ihållande invändning mot P2SH-förslaget av filosofiska skäl, och bestred inte bara dess tekniska fördelar utan dess konsekvenser för styrning.

“Om du vill ha en monarkvaluta, varför inte bara använda Fed: s USD?” Dashjr frågade sina motståndare, bara för att jagas av andra som hävdade att det var han som tävlade om makten [20].

Dashjr kodar inte en alternativ version av P2SH, som heter CheckHashVerify (CHV). CHV var i huvudsak en annan P2SH-implementering – men det krävde ingen okonventionell tolkning av transaktionsutgångar. Istället lade CHV till en ny op-kod som, liksom OP_EVAL, kunde “förklädas” som en platshållare-op-kod.

Men för Andresen var det för sent för mer debatt [21]. Rymtar över allmänhetens utbrott svarade han med sitt eget och skrev:

”Luke, du försöker mitt tålamod. Jag kommer att gå bort från koden i några dagar för att lugna mig innan jag gör något dumt. ”

Genjix blir offentlig

Eftersom Andresens P2SH-design (nu bara kallad P2SH) i stor utsträckning betraktades som en tillräckligt bra lösning som projektledarens utvecklare föredrog, befann sig Dashjr med få försvarare.

Det skulle falla på Taaki att vara minoritetsröst att ta oroskänslor på allvar – men inte för att han motsatte sig Andresens lösning eller nödvändigtvis instämde i Dashjrs.

Utvecklaren, då han var i början av 20-talet, var redan en av Bitcoins mest uttalade bidragsgivare, och medan han ännu inte hade blivit den rubrikfångande anarkisten som hackade från knäböj och reste med 3D-tryckta kanonlöpare, hans vision för programvaran som en anti-etableringsrörelse hade redan drivit honom ur projektets inre cirkel.

Detta hade i sin tur gjort Taaki misstro mot projektets påskyndande utvecklingsprocess. Han föredrog det om beslutsprocessen tog tid och involverade den bredare användarbasen.

Enligt hans uppfattning betjänades Bitcoin inte bra av en liten utvecklare som kallar skotten. Taaki ansåg starkt att alla som var intresserade av projektet borde vara medvetna om avvägningarna och så långt möjligt delta i beslutsfattandet.

“Jag skulle hellre vilja ha folk att säga till i saken även om det gör livet svårare för utvecklare att förklara sina beslut”, sa han till andra utvecklare [22]. “Jag känner mig lite orolig för att berätta för våra användare så är det, du har inget att säga och sedan ge dem fingret.”

Även om Taaki var överens om att skillnaden mellan Andresens P2SH och Dashjrs CHV-förslag var liten, hävdade han att det var en viktig övning att engagera användare i utvecklingsprocessen..

”[M] y oro är en dag Bitcoin blir skadad. Se denna extra granskning som en möjlighet att bygga en öppenhetskultur, argumenterade han.

För detta ändamål skrev Taaki ett blogginlägg där han redogjorde för P2SH- och CHV-uppgraderingarna och skillnaderna mellan de två [23].

Användarna hade ett val, var Taakis budskap, och: “Röstning baseras på gruvdrift.”

En F * cked-Up-situation

Med sitt val av ord hade Taaki tagit en elefant i rummet. Det var sant, Nakamoto hade antagit mjuka gafflar, men i slutet av 2011 fungerade nätverket inte längre som det gjorde de första dagarna.

När Nakamoto publicerade vitboken 2008 antog han att bevis på arbete skulle tillhandahållas av användare som bidrog med beräkningar via persondatorer. “Bevis på arbete är i huvudsak en CPU-en-röst”, hade Nakamoto skrivit.

Enligt denna design kan alla användare vara en gruvarbetare och säkra nätverket genom att föreslå block, validera transaktioner som skickas av kollegor och genomdriva koden som skapats av utvecklare.

Men under åren sedan programvarans lansering hade denna modell varit föråldrad av företagare. Eftersom Lazlo Hanyesz (av Bitcoin pizza berömmelse) hade kommit fram till hur man skulle generera bitcoin med mer kraftfulla grafikbearbetningsenheter, hade specialister varit upptagna med att göra gruvdrift från en hobby till ett litet företag.

Ungefär samma tid introducerade Marek “Slush” Palatinus en metod för att tillåta gruvarbetare att slå samman den hashkraft som behövs för att föreslå block och dela vinsten. Detta gjorde att gruvdrift effektivt blev mindre av ett lotteri och mer av en stabil inkomstkälla.

I slutet av 2011 kontrollerade bara tre pooler – DeepBit, Slush Pool och BTC Guild – över hälften av den globala hashkraften. Istället för en CPU-en-röst koncentrerades de flesta av “rösterna” nu till bara några få gruvpooloperatörer, som om de vore representanter för sina cyberkomponenter..

För vissa var det ett bevis på att något var fel i Bitcoin-nätverket. “Jag ser [en gruvbassäng] besluta om en förändring i nätverket som en farce för en omröstning,” hävdade tidig gruvarbetare Midnightmagic [24].

För andra var gruvcentralisering en olycklig krycka, ett sätt att göra en mjuk gaffeluppgradering mer hanterbar och därför mindre riskabel. (När allt kommer omkring krävde en säker utrullning nu deltagande av bara en handfull gruvpooloperatörer.)

Maxwell, till exempel, var mer berättigad till en otillfredsställande verklighet till hands [25].

“Om det fanns en icke-trivial pushback skulle både devs och pooler gå tillbaka, men ingen verkar mycket emot det nu i alla fall”, svarade han. “[Jag] är en bra mekanism att använda för framtiden … när vi förhoppningsvis inte kommer att få den här knullade situationen där Bitcoin inte längre är decentraliserat.”

Att rösta eller inte rösta

Att Andresen och Dashjrs stridande förslag skulle innebära motsatta åsikter om Bitcoin-styrning skulle bara komplicera saker.

Fram till dess hade utvecklare alltid talat om den kommande mjuka gaffeluppgraderingen som en slags röst: gruvarbetare kunde genomdriva de nya reglerna som P2SH (eller OP_EVAL) skisserade med en hashmakt majoritet, så en omröstning var avsedd att mäta sannolikheten för detta resultat.

Men medan terminologin hade blivit en del av lexikonet utelämnade detta viss teknisk nyans. Vid genomförandet av en omröstning frågade utvecklare inte precis gruvarbetare vad de tyckte om de nya reglerna. Snarare såg de detta som ett sätt att se om gruvarbetare var redo att säkerställa en säker uppgradering.

Ur det perspektivet var det vettigt för utvecklare att bara ett förslag skulle läggas till programanvändarna och gruvarbetare skulle springa för att genomdriva nätverksreglerna.

”Bitcoin-systemet är _NOT_ upp för majoritetsval. Inte en majoritet av hashpower, inte en majoritet av människor, inte en majoritet av pengar, ”hävdade Maxwell, irriterad över Taakis utformning av beslutet som omröstning [26].

Maxwell ansåg starkt att minaröster skulle vara begränsade eftersom de fanns i själva programvaran för att genomföra ordern på transaktioner – inte reglerna i hela nätverket.

”Vad händer om en supermajoritet – till och med 100% – av de nuvarande gruvarbetarna beslutar att subventionen ska vara 50 BTC för alltid? INGENTING. Gruvarbetare som ändrar denna regel i sin programvara slutar helt enkelt att existera ur Bitcoin-nätverkets perspektiv, ”skrev han.

Dashjr var inte oense med Maxwell, men i praktiken var det svårt för honom att se hur Bitcoin skulle förbli säkert om utvecklare driver förändringar utan gruvarbetare..

”Gruvarbetare kan helt enkelt vägra att bryta P2SH-transaktioner för att vara immuna mot” utvecklingsteamets förändringar ”, svarade han [27]. “Om” utvecklarna “låser ut alla gruvarbetare, gissa vad som händer? Enkla attacker på 50%, nätverket lämnas oskyddat! ”

Sett i detta ljus är det lättare att förstå varför Dashjr trodde att Andresen missbrukade sin roll som huvudutvecklare genom att försöka driva P2SH ensam. Om en gruvarbetare använde standardprogramvaran för att bryta ett block skulle den automatiskt avge en “röst” till förmån för P2SH [28].

Som svar skrev Dashjr lappar som skulle införa hans föredragna förslag i hashmaktens “val” och introducerade möjligheten för gruvarbetare att rösta både för och emot P2SH och CHV.

Även om få gruvarbetare använde koden, hade Dashjrs opposition en effekt. Tycho, operatören av DeepBit, då nätverkets största gruvpool, började bli obekväm med sin roll i utvärderingen av den konkurrerande koden.

Han hävdade att det var uppenbart att det ännu inte nåddes någon enighet bland utvecklarna och skrev: ”Jag vill inte bli den enda enheten som beslutar om detta [29]. ”

Dödläge

Genom att förkasta idén att en gruvpool, även som en bekvämlighet, kunde användas för att leda ett uppgraderingsbeslut, lade Tycho till en annan vridning till den aktuella debatten. Utan hans stöd, som uppgår till över 30 procent av all hashkraft, skulle P2SH ha svårt att aktiveras.

I slutet av januari närmade sig den första P2SH-omröstningen, och det såg inte ut att den skulle nå den nödvändiga tröskeln. Uppgraderingen måste försenas, en verklighet som inte bara frustrerade Andresen utan även andra utvecklare.

På IRC beklagade Maxwell offentligt att dödläget inte tycktes synas.

“Det här” skynda “-meme är skitsnack, Gavin började på [betala-till-skript-hash] -vägen, vad, oktober?” han skrev[30]. “Såvitt jag kan säga, såvida inte någon drar en tidsfrist, kommer denna process aldrig att konvergera eftersom det alltid kommer att finnas någon NÄSTA kille som har en bra idé utelämnades.”

Andresen skulle lägga skulden för förseningen inte på tillkomsten av gruvpooler utan på DeepBits operatör Tycho personligen. “Just nu ser det ut som att en person har tillräckligt med hashkraft för att lägga veto mot alla förändringar”, skrev han [31].

Detta stör Andresen, som såg Tychos inställning som oetisk. “Jag tycker att det är fel av dig att använda din position som den största pooloperatören för att gå emot det allmänna samförståndet”, skrev han [32].

Till och med när Andresen gick så långt att de utövade offentligt tryck och pressade användarna att be sina gruvpooler att uppgradera – och erbjöd sig att ersätta alla DeepBits medel i händelse av att P2SH ledde till någon ekonomisk förlust – Tycho var ovillig att “rösta” för förslaget[33].

Inför förseningen gjorde Andresen ett försök att samla allmänheten mot orsaken och fortsatte i sin övertygelse att valet mellan P2SH och CHV skulle ha liten inverkan på användarna.

Andresen skrev:

”Allt [P2SH / CHV] är mestadels ingenjörer som diskuterar om det är bättre att använda en spik, en skruv eller lim för att sätta ihop två träbitar. Någon av lösningarna skulle fungera och vanliga användare märkte ingen skillnad [34]. ”

Att döma av svaren i tråden accepterade Bitcoin-användare Andresens ram och skyllde Tycho för att hålla tillbaka gaffeln och pressade honom att aktivera.

Tycho motsatte sig i sin tur häftigt Andresens påstående. Även med 30 procent av hashkraften visste han att de återstående gruvarbetarna kunde överstyra honom, och han ville inte vara den avgörande faktorn.

Runda 2

Med P2SH hittills misslyckats med att samla tillräckligt med hashkraftsstöd skulle Andresen i allt högre grad tvingas diskutera strategi för sitt förslag i det fria, och han började särskilt acceptera CHV som ett potentiellt alternativ för att bryta dödläget..

Svaren drog fortfarande en skiljelinje mellan dem som trodde att valet mellan P2SH och CHV var för gruvarbetare att göra, och de som gynnade ett mer merokratiskt beslutsfattande.

“I slutändan är gruvarbetare ENDAST de som har något att säga om frågor som detta”, argumenterade BitcoinTalk-användaren dooglus [35]. “De är de enda som bestämmer vilka transaktioner som går i block.”

Forumets administratör, Theymos, avvisade denna idé direkt. ”Icke-gruvarbetare kan avvisa block. Om tillräckligt många klienter gör detta kommer mynarna att bli värdelösa. [36] ”

Istället föreslog Theymos att en viss inre krets av experter skulle delta i en två veckors diskussion och avge en omröstning i slutet [37]. Antingen på grund av förslaget eller händelsen skapade Dashjr snart en Wiki där en lista över respekterade utvecklare kunde uttrycka sina preferenser.

Under de närmaste dagarna indikerade Maxwell, Thomas och Wuille att de gärna skulle acceptera antingen P2SH eller CHV, även om de gjorde klart att de föredrog P2SH. O’Connor och Dashjr enades om att P2SH var acceptabelt, men uttryckte en preferens för CHV [38].

Kanske inte överraskande, såg Andresen till att svänga omröstningen till förmån för P2SH och registrera ett rungande “nej” mot CHV-förslaget.

Ännu viktigare, kanske, väldigt få gruvarbetare stödde CHV. I mitten av februari fick P2SH stöd av 30 procent av hashkraften, medan Dashjrs alternativ satt fast omkring 2 procent.

Under ett möte om IRC sa Dashjr att han övervägde att helt och hållet dra tillbaka CHV och accepterade motvilligt P2SHs dominans [39]. Vid samma möte gick deltagarna överens om att fastställa en andra röstfrist för den 1 mars.

När den nya tidsfristen närmade sig samlades fler gruvarbetare bakom P2SH, vilket gav hashkraftsstöd nära 55 procents tröskel. Snart fick både Tycho och Dashjr inget annat val än att acceptera sina kamraters preferenser [40].

Med detta meddelade Andresen att den mjuka gaffeln skulle distribueras och aktiveras inom tio dagar, och senast den 1 april 2012 tillämpades de nya reglerna [41].

P2SH, den första protokolluppgraderingen sedan Satoshis avgång, hade antagits.

Storma i en tekanna

Den svåra politiska processen som hade lett till att P2SH passerade skulle fortsätta att ha en bestående effekt utanför själva programvaran.

Till slut hade Andresen kunnat distribuera den lösning som han både designade och gynnade. Om det kan sägas att hans ledarskap ifrågasatt mitt i krisen, till slut, var det ordentligt cementerat.

Den allmänna opinionen, som inte är bekymrad över detaljerna, överensstämde till stor del med Dashjrs handlingar, och i mindre utsträckning Taaki, och ansåg dem onödiga och inflammatoriska [42]. Andresen gick så långt som att be Dashjr att sluta bidra till Bitcoin helt, även om det verkar som om han antingen backade från det hotet eller annars ignorerade Dashjr det helt enkelt [43].

Samtidigt blev Maxwell en av Bitcoins “kärnutvecklare” och delade åtkomst till projektet med Andresen och bidragsgivarna Wladimir van der Laan och Jeff Garzik.

Tonen hade satts: när det kom till Bitcoin-utveckling belönades en stödjande, pragmatisk attityd och motsatta bidragsgivare avskedades. Medan ideologiska skillnader hade dykt upp förblev de – och förmodligen bara förankrade av – förfarandet.

Med fler användare som flockar till Bitcoin för dagen, gick P2SH snart in i lore, även om det särskilt skulle fortsätta att fungera som en flampunkt i oenigheter mellan utvecklare..

Med tanke på händelserna ett år senare som svar på en ny framväxande kris skulle Andresen skryta på sätt som tyder på att han trodde att P2SH validerade sitt ledarskap och sin vision för projektet [44].

“Blockstorleken kommer att höjas”, skrev han, som svar på en video som producerats av utvecklaren Peter Todd och förespråkade mot gränsökningen i början av 2013 [45]. “Din video kommer bara att göra att många oroar sig för ingenting, på exakt samma sätt som Luke-Jrs [CHV] förslag förra året gjorde ingenting annat än att orsaka storm i en tekanna.”

Hur ska beslut fattas för den första decentraliserade digitala valutan? Om frågan äntligen hade ställts skulle det kräva ett bredare krig, fortfarande år i framtiden, för att lösa det …

Slaget om P2SH: Den otydliga historien om det första Bitcoin-krigetSlaget om P2SH: Den otydliga historien om det första Bitcoin-kriget

Titta på den här videon på YouTube