”Skub datoen tilbage to måneder. OP_EVAL er bare ikke klar endnu. ”

Det var den dom, Gavin Andresen havde arbejdet så længe for at undgå. Med en enkelt irettesættelse sendt fra Russell O’Connors tastatur blev en månedslang indsats for at opgradere Bitcoin – den første i kølvandet på grundlægger Satoshi Nakamotos udgang – brat stoppet forud for implementeringen.

Som afsløret af O’Connor kunne den foreslåede kommando – indvarslet af Andresen som den “hurtigste vej” til mere sikre Bitcoin-tegnebøger – udnyttes til at oprette transaktioner, der ville sende softwaren til en uendelig beregningssløjfe i et forsøg på at validere dem.

Kort sagt kan OP_EVAL misbruges til at nedbrudte Bitcoin-noder og dermed Bitcoin-netværket.

”Det tog mig alle 70 minutters søgen efter at finde denne fejl,” skrev O’Connor og fordømte en proces, der var slået sammen – og næsten skubbet – dårlig kode til live-softwaren. “I er nødt til at stoppe, hvad I laver, og virkelig forstå Bitcoin.”

Det var det første alvorlige tilbageslag for Andresen, projektets nye leder, der var hurtig til at protestere. Efter hans opfattelse ville opgivelse af OP_EVAL ikke bare spilde måneder med kodning og gennemgang, det ville efterlade brugere uden værktøjer til at beskytte mod trojanere og vira og derefter plyndre deres digitale tegnebøger.

Dette var kernen i OP_EVALs appel – nemme multisignatur tegnebøger ville give brugerne mulighed for at gendanne bitcoin, selv når sikkerhedskopier blev tabt; tjenester kan være bygget til at sende banklignende alarmer, afskrække svindel og tyveri; og endnu bedre, alt dette kunne opnås i transaktioner, der ser ud og opfører sig som de brugere kendte og forstod.

Men O’Connors advarselsord var nok for dem, der havde set deres bekymringer over det eskalerende tempo i udviklingen valideret.

”Jeg vil gerne minde alle om, at vi har rodet med en $ 20 + million dollar ting,” skriver udvikler Alan Reiner. “Der er mere end bare et stykke software på spil – uanset hvad der kommer ind, skal det være så hårdt som diamant.”

Mislykket OP_EVAL ville dog have større implikationer. Det var rigtigt, at Nakamoto havde lanceret verdens første decentrale digitale valuta, men dets løfte var langt fra opfyldt. Få i slutningen af ​​2011 forstod dens kode, og færre stadig havde færdigheder og fortrolighed til at beskytte den.

Hvordan skal disse udviklere organisere sig? Hvilket ansvar havde de over for brugerne? Og hvordan ville de vedtage ændringer, når det ikke var klart, hvem – hvis nogen – skulle have det sidste ord?

Sådanne spørgsmål vil snart blive fremhævet i den første store kamp om Bitcoin-softwaren.

En uortodoks arv

Gratis og open source-projekter ledes oftest af stiftere, som igen skal tilpasse indsatsen til bidragsydere, som deres arbejde afhænger af. Hvor retstvister opstår, er de stadig gennemsyret af en naturlig autoritet til at fungere som beslutningstagere for deres skabelser.

Bitcoin var tidligt ingen undtagelse. I de første to år af sin eksistens spillede Nakamoto rollen som hovedudvikler og velvillig diktator. Som Bitcoins ubestridte leder vedtog han så mange som otte protokolændringer uden meget lig en bredere diskurs [1]. Det vil sige, indtil han gradvist trådte væk fra projektet.

Ved udgangen af ​​2010 ville Nakamoto slette deres pseudonym fra Bitcoin.org-webstedet og efterlade veteran 3-D grafikudvikler Gavin Andresen til at hævde kappen som projektets “de facto lead” [2].

Andresens foretrukne valg af ord var passende, da omstændighederne omkring denne overgang var usædvanlige, svarende til en kort offentlig besked, en privat videregivelse af opgaver og udveksling af en nøgle, der tillod brugeren at sende en systemadvarsel.

Stadig på det tidspunkt udgjorde dette få vanskeligheder for Bitcoins lille, men voksende gruppe kodere. De fleste var bekymrede over kritiske rettelser, og Andresen, ægtefælle til en fast professor, havde tid og entusiasme til at lede arbejdet [3].

Faktisk var der mange presserende behov – hurtigere synkronisering, bedre testning – men de “øgede rapporter om stjålne tegnebøger” og den “dårlige PR”, som tyverierne forårsagede, kom hurtigt frem som et af de største bekymringer.

I en periode var det et mål, som Bitcoins nye gruppe af bidragydere alle syntes at være enige [4].

Bare Multisig

Heldigvis var planen for en løsning leveret af Nakamoto. Som Andresen ville lære, gjorde Bitcoins kode allerede det muligt for brugere at oprette sikre transaktioner, der kun kunne bruges, når de blev underskrevet med flere private nøgler [5].

Med multisignatur eller multisig for kort kan private nøgler gemmes på flere enheder, i modsatte ender af verden eller deles mellem en bruger og en tegnebogstjeneste, hvilket betyder, at hackere bliver nødt til at gå på kompromis med flere mål for at stjæle mønter.

Andresen blev begejstret for ideen og blev den første mester, der skrev en lidenskabelig bøn på postlisten for at inspirere bidragydere til handling.

“Min største bekymring er, at vi vil sige,” Sikker på, det tager kun et par dage at blive enige om, hvordan man gør det rigtigt, “og om seks måneder er der stadig ingen konsensus,” skrev han [6]. “Og folks tegnebøger [vil] fortsætte med at gå tabt eller stjålet.”

Bekymringerne var ikke uden vægt – som implementeret af Nakamoto havde multisig betydelige ulemper. Den mest presserende af disse var, at transaktionerne var uforenelige med Bitcoins standardadresseformat og i stedet krævede meget længere adresser.

På grund af dette var transaktioner, der finansierede multisig-tegnebøger, større og krævede højere gebyrer. Desuden skulle disse gebyrer ikke betales af den person, der modtager bitcoin med multisig-tegnebogen, men af ​​den person, der sender bitcoin til dem.

På grund af disse suboptimale egenskaber blev multisig-transaktioner udpeget som “ikke-standard” i softwaren, hvilket betyder, at de ikke nødvendigvis spredes til noder på netværket. Hvis en node modtog en multisig-transaktion, ville den simpelthen ignorere den. Tilsvarende var der ingen garanti, at minearbejdere ville inkludere disse transaktioner i blokke.

Hvis de blev inkluderet, ville noder acceptere dem (multisig-transaktioner var i sidste ende gyldige). Men i praksis gjorde betegnelsen det næsten umuligt at få disse transaktioner bekræftet.

Indtast OP_EVAL

For at frigøre det potentiale, han så, ville Andresen fortsætte med at forkæmpe en ny “op-kode”, en type kommando, som noder kunne bruge til at beslutte, om og hvornår nye typer transaktioner skulle være gyldige.

Designet til at imødekomme mere avancerede transaktioner som multisig, OP_EVAL lænet sig kraftigt på hashes, det kryptografiske trick, der krypterer og komprimerer data deterministisk, men uigenkaldeligt til en unik talrække.

Først foreslog af den pseudonyme udvikler ByteCoin var den grundlæggende idé, at brugerne kunne hashinstruktioner, der beskriver de betingelser, hvorunder bitcoin senere kunne bruges (inklusive til og fra multisig-tegnebøger) ved at medtage denne hash i en transaktion. Mønter ville i det væsentlige blive sendt “til” en hash.

Betingelserne, der kræves for senere at bruge bitcoin, afsløres kun, når mønterne blev brugt “fra” hashen. En multisig-bruger ville betale for den ekstra transaktionsstørrelse, når hun brugte mønterne, mens de nødvendige ekstra data udgjorde en mindre byrde for netværket..

Da forslaget fik positiv feedback, spildte Andresen ikke tid og foretrak at få OP_EVAL indsat hurtigere end senere.

”Sikkerhed er virkelig højt på prioritetslisten; Jeg vil gerne se sikrede Bitcoin-adresser i folks forumunderskrifter inden for et år, ”skrev han [7].

Ikke alle delte Andresens følelse af haster, dog. OP_EVAL ville være en stor opgradering på et live system, der allerede har millioner af dollars i værdi. På tværs af havet fra Andresen foreslog en ung Amir Taaki udviklere at tage sig tid til at gennemgå forslaget.

“Det ser godt ud ved første øjekast,” skrev Taaki [8]. “Men hurtig sporing af dette i blockchain er sandsynligvis ikke en klog idé … Bitcoin eksploderer ikke i morgen, så der er ikke noget stort tab ved at holde ud med vigtige ændringer som disse.”

Yderligere komplicerende forhold antog udviklere at tilføje OP_EVAL til protokollen ville udgøre en betydelig koordineringsudfordring. I det væsentlige ville vedtagelse af det kræve risiko for, at blockchain, den endelige registrering af alle Bitcoin-transaktioner, håndhævet af den delte konsensus om dens softwareregler, kunne opdeles i inkompatible netværk.

Dette betød, at så snart OP_EVAL blev sat i live, skulle hver bruger skifte til en ny version af softwaren og en ny blockchain i det, der blev kaldt en “hård gaffel” -opgradering.

Mangler ikke at opgradere i fællesskab, og minearbejdere producerer måske ubevidst “ugyldige” blokke. Endnu værre, brugere accepterer muligvis ubevidst “ugyldige” transaktioner.

En ny slags blød gaffel

Snart nok indså Andresen imidlertid, at det var muligt at overtale sine modstandere.

Som et fedt trick afslørede han, at OP_EVAL kunne implementeres ved at omdefinere en af ​​flere inaktive op-koder, der oprindeligt blev inkluderet af Nakamoto som pladsholdere for fremtidige kommandoer.

Til alles overraskelse, inklusive Andresen, ville dette også være kompatibelt med noder, der ikke opgraderede til at acceptere OP_EVAL. Disse noder kontrollerer, at hashen matcher de nye instruktioner, men ikke håndhæver dem, men accepterer i stedet transaktionerne som standard.

Så længe et flertal af minearbejdere håndhævede de nye regler, betød det, at den nye blockchain ville blive betragtet som gyldig af både opgraderede og ikke-opgraderede noder. Opgraderede noder ville acceptere blockchain, fordi de nye regler blev håndhævet, mens noder, der ikke kunne opgradere, ville acceptere blockchain, fordi de ligeglad med de nye regler.

Sådanne bagudkompatible opgraderinger eller “bløde gafler” var allerede blevet implementeret af Nakamoto, men da netværket var vokset i størrelse, var udviklere begyndt at bekymre sig om det store antal mennesker, der skulle være involveret i enhver opgradering.

Ikke overraskende blev Andresens erkendelse af, at dette kunne undgås, hilst velkommen af ​​andre etablerede bidragydere, som han hurtigt delte nyheden med..

“Wow. Gavins pointe om, at [OP_EVAL] kan gøres uden en splittelse sprængte mig, ”bemærkede Gregory Maxwell og reagerede på opdagelsen i realtid [9]. “Bring [sic] -kampagnen ud.”

Med dette fortsatte udviklerne med at udvikle en endnu mere sikker metode til aktivering af bløde gafler. De teoretiserede, at de kunne gennemføre noget som en afstemning for at afgøre, hvornår en funktion havde bred nok støtte fra minearbejdere, som de derefter kunne bruge til at sikre en sikker opgradering.

Minearbejdere ville blive bedt om at medtage lidt data i de blokke, de udvindede, for at signalere, at de ville håndhæve de nye regler. Når et flertal var klar, kunne ændringen aktiveres [10].

Den fatale fejl

Men alt dette arbejde blev fortrydet af O’Connors fund [13].

Resultatet var en opdeling i fraktioner, hvor nogle mente, at OP_EVAL blev unødigt forsinket, og andre, der argumenterede for de foreslåede hurtige rettelser, ville forringe visse ønskede egenskaber ved Bitcoins essentielle script-sprog [14].

Udviklere inklusive Luke Dashjr, Pieter Wuille og Maxwell foreslog alternativer, der ligesom OP_EVAL brugte konceptet med at sende mønter “til” en hash. Men udfordringen var stadig at få denne logik, som de startede kaldte “betal til script-hash” eller “P2SH”, til Bitcoin som en blød gaffel og undgå en blockchain-split.

Eksisterende op-koder kunne kun gå så langt: ikke-opgraderede noder ville skulle acceptere transaktioner, der brugte mønter fra hash, uden at forstå de nye regler.

Det var Andresen, der fandt en vej fremad, og hans specifikke P2SH-løsning ville slet ikke kræve en ny op-kode. Andresens idé var snarere, at Bitcoin kunne programmeres til at genkende et bestemt format af transaktioner og derefter fortolke dette format på en ukonventionel måde for at validere det ved hjælp af nye instruktioner.

Enhver node, der ikke opgraderede, ville fortolke det ukonventionelle format ved hjælp af konventionel logik. Som med OP_EVAL vil transaktionen altid blive betragtet som gyldig af ikke-opgraderede noder. Dette betød, at P2SH kunne indsættes som en blød gaffel: så længe et flertal af hash-kraft håndhævede de nye regler, ville både gamle og nye noder være enige om den samme blockchain.

Andresens forslag syntes at være tilfredsstillende for de fleste. “Synes … acceptabelt fra første øjekast,” svarede O’Connor [15]. Taaki, der henviser til kodens ukonventionelle tilgang, sagde: ”Ideen er et hack…. men jeg kan lide det.”

På et efterfølgende udviklermøde holdt stemningen og deltagere enige om at gennemføre Andresens P2SH-forslag. Minearbejdere ville blive undersøgt i ugen frem til 1. februar, og hvis et flertal af hashkraft (55 procent) signaliserede støtte, ville en klient blive frigivet for at aktivere den bløde gaffel kun to uger senere.

Freden ville vare nogle få dage.

Hvorfor ikke bruge USD?

At bryde konsensus ville være Dashjr, som havde været nødt til at forlade mødet tidligt og først senere lærte Andresens version af P2SH havde været det accepterede kompromis.

Den ukonventionelle karakter af Andresens løsning irriterede Dashjr, der mente, at det komplicerede protokollen og bragte usikre konsekvenser ned ad linjen. Han rejste spørgsmålet med Andresen, men sidstnævnte var ikke overbevist om, at hans bekymringer fortjente en ændring af planerne [16].

Hans forslag forkælet, Dashjr ville bryde ud på det offentlige BitcoinTalk-forum i midten af ​​januar og fordømme P2SH og opkræve Andresen var “alene” til at støtte ændringen [17].

”Gavin tvinger alle, der bruger den nyeste Bitcoin-kode, til at stemme på [P2SH],” skrev han. “Hvis du vil modsætte dig denne sindssyge protokolændring, bliver du nødt til at ændre din BitcoinD-kildekode, ellers vil du stemme FAVOR FOR DET som standard.”

På grund af nuancen i hans indvendinger, den skarpe tenor, hvori de blev leveret, og hans beskyldninger om Andresen, var svarene på stillingen mindre end positive. I stedet for at begrænse den tekniske debat til udviklere opfattede nogle Dashjr som forsøg på at tilskynde en populær pøbel.

Det hjalp ikke, at Dashjr var en af ​​projektets mere quixotiske bidragydere, kendt for sine lange argumenter til forsvar for alternative nummersystemer og stærk kristen tro. En forumbruger sagde, at Dashjrs kommentarer fik ham til at se “mentalt ustabil [18]. ” En anden sagde, at han overhovedet ikke ville bekymre sig om detaljerne; han stolede simpelthen på Andresen [19].

Som svar lancerede Dashjr en vedvarende indsigelse mod P2SH-forslaget af filosofiske grunde og bestridte ikke kun dets tekniske fordele, men dets konsekvenser for regeringsførelse..

“Hvis du vil have en monarkial valuta, hvorfor så ikke bare bruge Feds USD?” Dashjr spurgte sine modstandere for kun at blive jaget af andre, der hævdede, at det var han, der kappede om magten [20].

Dashjr kodede ikke en anden version af P2SH, kaldet CheckHashVerify (CHV), ikke tilbage. CHV var i det væsentlige en anden P2SH-implementering – men det krævede ikke en ukonventionel fortolkning af transaktionsoutputs. I stedet tilføjede CHV en ny op-kode, der ligesom OP_EVAL kunne “forklædes” som en pladsholder-op-kode.

Men for Andresen var det for sent til mere debat [21]. Rummende over det offentlige udbrud svarede han med sit eget og skrev:

”Luke, du prøver min tålmodighed. Jeg vil gå væk fra koden i et par dage for at roe mig ned, før jeg gør noget dumt. ”

Genjix bliver offentlig

Da Andresens P2SH-design (nu kun kaldet P2SH) i vid udstrækning blev betragtet som en god nok løsning foretrukket af projektets hovedudvikler, befandt Dashjr sig med få forsvarere.

Det ville falde på Taaki at være mindretalsstemme til at tage frynseproblemer alvorligt – men ikke fordi han modsatte sig Andresens løsning eller nødvendigvis var enig med Dashjrs.

Udvikleren, der i begyndelsen af ​​20’erne, var allerede en af ​​Bitcoins mest åbenlyse bidragydere, og mens han endnu ikke var blevet den overordnede anarkist, der hackede fra squats og rejste med 3D-trykte pistolløbere, var hans vision for softwaren som en anti-etableringsbevægelse havde allerede skubbet ham ud af projektets indre cirkel.

Dette havde til gengæld gjort Taaki mistroisk med projektets accelererende udviklingsproces. Han foretrak det, hvis beslutningsprocessen tog tid og involverede den bredere brugerbase.

Efter hans opfattelse blev Bitcoin ikke tjent godt af en lille kabal af udviklere, der kalder skuddene. Taaki følte stærkt, at enhver med interesse i projektet skulle være opmærksom på kompromiserne og så vidt muligt deltage i beslutningsprocessen.

“Jeg vil hellere have folk at sige noget om sagen, selvom det gør livet sværere for udviklere at forklare deres beslutninger,” sagde han til andre udviklere [22]. “Jeg er lidt ængstelig ved at fortælle vores brugere, at det er sådan, det er, du har intet at sige og derefter give dem fingeren.”

Selvom Taaki var enig i, at forskellen mellem Andresens P2SH og Dashjrs CHV-forslag var lille, fastholdt han, at det var en vigtig øvelse at få brugere involveret i udviklingsprocessen..

”[M] y bekymring er en dag, at Bitcoin bliver ødelagt. Se denne ekstra kontrol som en mulighed for at opbygge en kultur af åbenhed, ”argumenterede han.

Til dette formål skrev Taaki et blogindlæg, hvor han lagde P2SH- og CHV-opgraderingerne og forskellene mellem de to [23].

Brugere havde et valg, var Taakis besked, og: “Afstemning er baseret på minedrift.”

En f * cked-up situation

Med sit valg af ord havde Taaki givet en elefant i rummet. Det var sandt, Nakamoto havde vedtaget bløde gafler, men i slutningen af ​​2011 fungerede netværket ikke længere som i de tidlige dage.

Da Nakamoto offentliggjorde hvidbogen i 2008, antog han, at bevis for arbejde ville blive leveret af brugere, der bidrog med beregninger via personlige computere. “Bevis for arbejde er i det væsentlige en CPU-en-stemme,” havde Nakamoto skrevet.

Under dette design kan enhver bruger være en minearbejder og sikre netværket ved at foreslå blokke, validere transaktioner sendt af peers og håndhæve den kode, der er oprettet af udviklere.

Men i årene siden softwarens lancering var denne model blevet forældet af iværksættere. Da Lazlo Hanyesz (af Bitcoin pizza-berømmelse) havde fundet ud af, hvordan man kunne generere bitcoin med mere kraftfulde grafikbehandlingsenheder, havde specialister haft travlt med at gøre minedrift fra en hobby til en lille virksomhed.

Omkring samme tid introducerede Marek “Slush” Palatinus en metode, der tillader minearbejdere at samle den hashkraft, der er nødvendig for at foreslå blokke og dele overskuddet. Dette gjorde minedrift effektivt mindre af et lotteri og mere af en stabil indtægtskilde.

I slutningen af ​​2011 kontrollerede kun tre puljer – DeepBit, Slush Pool og BTC Guild – godt over halvdelen af ​​den globale hashkraft. I stedet for en-CPU-en-stemme var de fleste af “stemmerne” nu koncentreret i blot nogle få minedrift-pooloperatører, som om de var repræsentanter for deres cyber-bestanddele..

For nogle var det bevis for, at der var noget galt på Bitcoin-netværket. “Jeg ser [en minedrift] beslutte en ændring i netværket som en farce til afstemning,” hævdede den tidlige minearbejder Midnightmagic [24].

For andre var minedriftcentralisering en uheldig krykke, en måde at gøre en blød gaffelopgradering mere håndterbar og derfor mindre risikabel. (Når alt kommer til alt krævede en sikker udrulning nu deltagelse af kun en håndfuld minedriftpooloperatører.)

Maxwell var for eksempel mere resigneret over for en utilfredsstillende virkelighed ved hånden [25].

“Hvis der var ikke-triviel pushback, ville både devs og pools vende tilbage, men ingen synes meget imod det nu under alle omstændigheder,” svarede han. “[Jeg] er en god mekanisme, der skal bruges til fremtiden … når vi forhåbentlig ikke får denne futtede situation, hvor Bitcoin ikke længere er decentraliseret.”

At stemme eller ikke at stemme

At Andresen og Dashjrs stridende forslag ville komme til at omfatte modstridende synspunkter om Bitcoin-styring, ville kun komplicere sagerne.

Indtil da havde udviklere altid talt om den kommende soft fork-opgradering som en slags stemme: minearbejdere kunne håndhæve de nye regler, der er skitseret af P2SH (eller OP_EVAL) med et hash-magtflertal, så en afstemning var beregnet til at måle sandsynligheden for dette resultat.

Men mens terminologien var blevet en del af leksikonet, udelod dette en vis teknisk nuance. Ved gennemførelsen af ​​en afstemning spurgte udviklere ikke ligefrem minearbejdere, hvad de syntes om de nye regler. Snarere så de dette som en måde at se, om minearbejdere var klar til at sikre en sikker opgradering.

Fra det perspektiv var det for udviklere fornuftigt, at kun et forslag ville blive tilføjet til softwarebrugerne og minearbejdere ville køre for at håndhæve netværksreglerne.

”Bitcoin-systemet er _NOT_ op til flertalsvalg. Ikke et flertal af hashpower, ikke et flertal af mennesker, ikke et flertal af penge, ”hævdede Maxwell irriteret over Taakis indramning af beslutningen som afstemning [26].

Maxwell følte stærkt, at miner “stemmer” skulle begrænses, da de var i selve softwaren, til at håndhæve rækkefølgen af ​​transaktioner – ikke reglerne i hele netværket.

”Hvad sker der, hvis et stort flertal – endda 100% – af de nuværende minearbejdere beslutter, at tilskuddet skal være 50 BTC for evigt? IKKE NOGET. Minearbejdere, der ændrer denne regel i deres software, stopper simpelthen med at eksistere fra Bitcoin-netværks perspektiv, ”skrev han.

Dashjr var ikke uenig med Maxwell, men i praksis var det svært for ham at se, hvordan Bitcoin ville forblive sikker, hvis udviklere skubber ændringer uden minearbejderstøtte.

”Minearbejdere kan simpelthen nægte at udvinde P2SH-transaktioner for at være immune over for” udviklingsteamets ændringer ”, svarede han [27]. ”Hvis“ udviklerne ”låser alle minearbejdere ud, gæt hvad der sker? Nemme 50% angreb, netværket efterlades usikret! ”

Set i dette lys er det lettere at forstå, hvorfor Dashjr mente, at Andresen misbrugte sin rolle som hovedudvikler ved at forsøge at skubbe P2SH alene. Hvis en minearbejder brugte standardsoftwaren til at udvinde en blok, ville den automatisk afgive en “stemme” til fordel for P2SH [28].

Som svar skrev Dashjr patches, der ville komme med hans foretrukne forslag i hash-magt “valg”, der introducerede muligheden for minearbejdere til at stemme både for og imod P2SH og CHV.

Selvom kun få minearbejdere brugte koden, havde Dashjrs modstand en effekt. Tycho, operatøren af ​​DeepBit, dengang netværkets største minedrift, begyndte at blive ubehagelig med sin rolle i vurderingen af ​​den konkurrerende kode.

Han hævdede, at det var klart, at der endnu ikke var opnået enighed blandt udviklere, og han skrev: ”Jeg vil ikke blive den eneste enhed, der beslutter dette [29]. ”

Dødlås

Ved at afvise ideen, kunne en minedrift, selv som en bekvemmelighed, bruges til at svinge en opgraderingsbeslutning, tilføjede Tycho endnu et twist til den aktuelle debat. Uden hans støtte, der udgør over 30 procent af al hashkraft, ville P2SH have svært ved at blive aktiveret.

I slutningen af ​​januar var den første P2SH-afstemningsrunde ved at nærme sig slutningen, og det så ikke ud til at den ville nå den krævede tærskel. Opgraderingen skal forsinkes, en virkelighed, der frustrerede ikke kun Andresen, men også andre udviklere.

På IRC beklagede Maxwell offentligt, at der ikke syntes at være nogen ende i blindløbet.

“Denne ‘skynde’ meme er lort, Gavin startede på [pay-to-script-hash] ruten i, hvad, oktober?” han skrev[30]. “Så vidt jeg kan fortælle, medmindre nogen trækker en deadline, vil denne proces aldrig konvergere, fordi der altid vil være en NÆSTE fyr, som har en god idé, der blev udeladt.”

Andresen ville lægge skylden for forsinkelsen ikke på fremkomsten af ​​minepuljer, men på DeepBits operatør Tycho personligt. ”Lige nu ser det ud til, at en person har tilstrækkelig hashingkraft til at nedlægge veto mod enhver ændring,” skrev han [31].

Dette generede Andresen, der så Tychos holdning som uetisk. ”Jeg synes det er forkert af dig at bruge din position som den største pooloperatør til at gå imod den generelle konsensus,” skrev han [32].

Selv når Andresen gik så langt som at anvende offentligt pres, skubbede brugerne til at bede deres minedrift om at opgradere – og tilbød at tilbagebetale alle DeepBits midler i tilfælde af at P2SH førte til ethvert økonomisk tab – Tycho var uvillig til at “stemme” på forslaget[33].

Stillet over for forsinkelsen gjorde Andresen et forsøg på at skubbe offentligheden til sagen, vedholdende i sin overbevisning, at valget mellem P2SH og CHV ville have ringe indvirkning på brugerne.

Andresen skrev:

”Alle [P2SH / CHV] ting er for det meste ingeniører, der diskuterer, om det er bedre at bruge et søm, en skrue eller lim til at sætte to træstykker sammen. Enhver af løsningerne fungerer, og almindelige brugere bemærker ikke nogen forskel [34]. ”

At dømme efter svarene i tråden, accepterede Bitcoin-brugere Andresens ramme og beskyldte Tycho for at holde gaffelen tilbage og pressede ham til at aktivere.

Tycho modsatte sig igen hårdt Andresens påstand. Selv med 30 procent af hashkraften vidste han, at de resterende minearbejdere kunne tilsidesætte ham, og han ønskede ikke at være den afgørende faktor.

Runde 2

Da P2SH hidtil ikke har kunnet akkumulere tilstrækkelig hash-strømstøtte, ville Andresen i stigende grad blive tvunget til at diskutere strategi for sit forslag i det fri, og han begyndte især at acceptere CHV som et potentielt alternativ til at bryde dødvandet..

Svarene trak stadig en skillelinje mellem dem, der troede, at valget mellem P2SH og CHV var for minearbejdere at tage, og dem, der favoriserede en mere meritokratisk beslutningstagning.

“I sidste ende er minearbejdere de eneste mennesker, der har noget at sige om spørgsmål som dette,” argumenterede BitcoinTalk-bruger dooglus [35]. “De er de eneste, der bestemmer, hvilke transaktioner der opstår i blokke.”

Forumets administrator, Theymos, afviste denne idé direkte. ”Ikke-minearbejdere kan afvise blokke. Hvis nok klienter gør dette, bliver mine mønter minearbejdere værdiløse. [36] ”

I stedet foreslog Theymos, at en bestemt indre kreds af eksperter skulle deltage i en to-ugers diskussion og udsende en afstemning i slutningen [37]. Enten på grund af forslaget eller tilfældet oprettede Dashjr snart en Wiki, hvor en liste over respekterede udviklere kunne give udtryk for deres præference.

I løbet af de næste par dage antydede Maxwell, Thomas og Wuille alle, at de ville være glade for at acceptere enten P2SH eller CHV, skønt de gjorde det klart, at de foretrak P2SH. O’Connor og Dashjr var enige om, at P2SH var acceptabelt, men udtrykte en præference for CHV [38].

Måske overraskende sørgede Andresen for at svinge afstemningen til fordel for P2SH og registrere et rungende “nej” mod CHV-forslaget.

Endnu vigtigere var det måske, at meget få minearbejdere støttede CHV. I midten af ​​februar blev P2SH understøttet af 30 procent af hashkraft, mens Dashjrs alternativ var fast omkring 2 procent.

Under et møde om IRC sagde Dashjr, at han overvejede, om han helt ville trække CHV tilbage, idet han modvilligt accepterede P2SHs dominans [39]. På det samme møde blev deltagerne enige om at fastsætte en anden frist for afstemning til 1. marts.

Da den nye frist nærmede sig, samlede flere minearbejdere sig bag P2SH og bragte hash-strømstøtte tæt på 55 procent tærsklen. Snart fik både Tycho og Dashjr intet andet valg end at acceptere deres kammeraters præferencer [40].

Med det meddelte Andresen, at den bløde gaffel ville blive implementeret og aktiveret inden for 10 dage, og inden den 1. april 2012 blev de nye regler håndhævet [41].

P2SH, den første protokolopgradering siden Satoshis afgang, var blevet vedtaget.

Storm i en tekande

Den vanskelige politiske proces, der havde ført til passage af P2SH, ville fortsat have en varig indvirkning uden for selve softwaren.

I sidste ende havde Andresen været i stand til at implementere den løsning, han både designede og favoriserede. Hvis det kan siges, at hans ledelse blev afhørt midt i krisen, var den til sidst fast cementeret.

Den offentlige mening, der ikke er bekymret over detaljerne, faldt stort set sammen med Dashjrs handlinger og i mindre grad Taaki og anså dem for unødvendige og inflammatoriske [42]. Andresen gik så langt som at bede Dashjr om at stoppe med at bidrage helt til Bitcoin, selvom det ser ud til, at han enten trak sig tilbage fra den trussel, ellers Dashjr simpelthen ignorerede det [43].

I mellemtiden blev Maxwell en af ​​Bitcoins “kerneudviklere”, der delte adgangsadgang til projektet med Andresen og bidragsydere Wladimir van der Laan og Jeff Garzik.

Tonen var sat: Når det kom til Bitcoin-udvikling, blev en støttende, pragmatisk holdning belønnet, og modsatte bidragydere blev afskediget. Mens ideologiske forskelle var dukket op, forblev de – og kunne uden tvivl kun forankres af – proceduren.

Da flere brugere strømmer til Bitcoin om dagen, gik P2SH kort efter i lore, selvom det især ville fortsætte med at fungere som et flammepunkt i uenighed blandt udviklere.

Andresen mindede om begivenhederne et år senere som reaktion på en ny krise og ville prale af måder, der tyder på, at han mente, at P2SH validerede hans lederskab og vision for projektet [44].

“Blokstørrelsen hæves,” skrev han som svar på en video produceret af udvikleren Peter Todd, der talte for forhøjelsen af ​​grænsen i begyndelsen af ​​2013 [45]. “Din video vil bare få mange til at bekymre sig om ingenting, på nøjagtig samme måde som Luke-Jrs [CHV] -forslag sidste år kun gjorde noget storm i en tekande.”

Hvordan skal beslutninger tages for den første decentrale digitale valuta? Hvis spørgsmålet endelig var blevet stillet, ville det tage en bredere krig, stadig år i fremtiden, at løse det …

Kampen om P2SH: Den utallige historie om den første Bitcoin-krigKampen om P2SH: Den utallige historie om den første Bitcoin-krig

Se denne video på YouTube