Taproot blev fusioneret i Bitcoin Core i oktober 2020, hvilket kun efterlod aktiveringsmetoden til denne meget forventede protokolopgradering med fokus på at tilføje smart kontraktfleksibilitet og mere transaktionsretligt privatliv til Bitcoin.

I sidste uge samledes Bitcoin-udviklingssamfundet via Internet Relay Chat (IRC) for at diskutere parametrene for Taproot-aktivering og to kodetrækanmodninger (PR’er) i BIP 8-signalmekanismen.

“I et forsøg på at komme dette tættere på målstregen organiserer vi et møde om IRC på ## taproot-aktiveringskanalen tirsdag den 2. februar kl. 19:00 UTC,” Bitcoin udviklingsorganisator Michael Folkson annonceret via bitcoin-dev-postlisten. “Det primære mål er at færdiggøre den reviderede BIP 8-aktiveringsmetode …”

I sidste ende gav dette møde mere indsigt i, hvordan Bitcoins mest betydningsfulde protokolændring siden SegWit muligvis bevæger sig fremad.

Redaktørens bemærkning: Udsagnene gengivet fra IRC nedenfor er redigeret lidt af hensyn til klarheden, men præsenteres ellers som de blev skrevet.

At give form til forslaget

Bitcoin-udvikler Anthony byer har samlet den forslag og mulige scenarier til aktivering af Taproot. I mødet den 2. februar, dem, der synes at have mest støtte, er “BIP 8 (falsk, 1y)” og “BIP 8 (sand, 1y).” Der blev dog ikke afstemt, der var bare diskussion af hver alternativ aktiveringsmetode.

Men hvad betyder dette? BIP 8 er en mekanisme, der giver mulighed for at opgradere konsensus i Bitcoin-netværket gennem en blød gaffel, og specifikt en miner-aktiveret blød gaffel eller MASF med mulighed for at tilføje en brugeraktiveret blød gaffel (UASF) efter nogen tid. I den sidste konsensusopdatering (SegWit) blev der anvendt en brugeraktiveret soft fork (UASF) ud over BIP 9’s MASF. Taproot synes imidlertid at være ikke-kontroversiel for minearbejdere, så det synes mindre sandsynligt, at en UASF ville være nødvendig denne gang.

Når vi kommer tilbage til forslaget, er parametrene “lockinontimeout” og “timeout”, hvor lockinontimeout grundlæggende betyder, om aktiveringen ville være tvunget eller ej, og “timeout” betyder det vindue, hvori det ville blive aktiveret. En anden relevant parameter, der ikke fik nok diskussion, var “starthøjde”.

Hvis lockinontimeout er falsk, og opdateringen ikke har tilstrækkelig support, annulleres den, og der defineres et nyt forslag. (Bitcoin-udvikler Luke Dashjr beskrevet lockintimeout = falsk som at give minearbejdere en ekstra strøm, som de aldrig var beregnet til at have),

“Hvis du starter med (timeout = T, lockinontimeout = false) er der tre muligheder, når T er ramt: aktiveringen mislykkes, du prøver igen med en ny aktivering (timeout = T + 1 år, lockinontimeout = sand, f.eks.); inden da beder du alle om at skifte deres software til (timeout = T, lockinontimeout = true), på hvilket tidspunkt du har opgraderet MASF til en UASF, ”skrev Towns på IRC. ”Der er også muligheden for at få alle til at opgradere til software, der specificerer (timeout = T-6 måneder, lockinontimeout = true), i hvilket tilfælde de mennesker, der har opgraderet, begynder at afvise blokke ved T-6 måneder, og hvis den længste kæde aktiveres inden den tid vil både gammel og ny software have soft-fork aktiveret. ”

Dog er Dashjr uenig i lockinontimeout = false:

“… Er vi tilfredse med lockingtimeout = falsk generelt ?,” Bitcoin Developer Maxim Orlovsky spurgt.

“Ja,” Lynudvikler Rusty Russell svarede. “Vi har en UASF-hammer, hvis vi har brug for den, men det er bedre at ikke bruge den.”

“Lot = true betyder ikke, at vi bruger det, lot = false betyder, at hensigten er at lade minearbejdere beslutte,” skrev Dashjr. “BIP8 (falsk) er en regression.”

Men Russell argumenterede imod, hvad han ser som en pålægning af en udvikler: ”Jeg føler, at det er vigtigt at undgå udseendet af udviklermandat over protokollen, og jeg kan også godt lide at have en flugtluge, hvis der skulle opstå problemer inden aktivering,” skrev han. “Således foretrækker jeg at starte med lockin = false, og besøge igen efter 6 måneder, hvis det ikke er aktiveret.”

“Der er ikke noget udviklermandat … giver mere mening at gøre 1 år, falsk derefter 1 år, sandt i den samme 1-årige periode [i tilfælde af to efterfølgende implementeringer],” svarede Dashjr.

Men Russell syntes ikke at blive påvirket:

”Jeg er uenig,” skrev han. ”Minearbejdere får koordineringsevne, fordi vi pålideligt kan måle dem på en decentral måde i modsætning til andre grupper. Det indebærer evnen til at * ikke * koordinere, ja. Men vi har også en plan for det, da BIP-8 gør en UASF meget mindre tilbøjelig til at forårsage en splittelse. Det er så godt, som vi kan gøre. ”

“Parti = sand IS-planlægning for det,” skrev Dashjr som svar, “det forhindrer ikke minearbejdere i at lave MASF.”

Andre i chatten foreslog at gøre lockinontimeout = falsk valgfri, men standard:

“Lot = false er sikrere end lot = true, så det er værd at gøre lot = false først, da vi ved, at hashpower allerede er ~ 90% pro-taproot,” skrev CoinSwap-udvikler Chris Belcher.

Hvis brugere let kan ændre lot = falsk til masse = sand på et eller andet tidspunkt uden at kræve en ny kerneudgivelse, vil jeg støtte at lade lot = falsk standard, ” Keagan McClelland skrev.

UASF Hammer

For at præcisere:

BIP8 m / LockinOnTimeout er en MASF m / UASF-reserve.

Så længe minearbejdere aktiveres, forekommer der ingen UASF.

Den forudplanlagte UASF sikrer også, at MASF sker:

Det undgår at give minearbejderne vetoret og skaber det rette incitament til at sikre, at en MASF opstår.#Bitcoin #Taproot

– Luke Dashjr (@LukeDashjr) 2. februar 2021

Dashjr ønsker at bruge “BIP 8 (true)”, en UASF-reserve, som en spilteori-enhed for at sikre, at minearbejdere aktiverer Taproot, og giver dem ingen mulighed for “veto” -magt, ligesom hvad der skete med SegWit.

“I betragtning af signalkravene, hvilken type stalling eller sorgsangreb kan en minedrift opnå, hvis de værdsætter stalling af taproot?” spurgte en bruger kaldet “handsker” i IRC den 2. februar. “F.eks. misbruge den marginale hashrate, der kræves til aktivering.”

Som en påmindelse handler signalering om at reducere gaffelrisici og har intet at gøre med politisk støtte eller afstemning.

“MASF er den foretrukne vej, med UASF som en reserve, hvis minearbejdere ikke signalerer,” skrev Dashjr tilbage. “Samfundet kunne flytte UASF hurtigere, hvis det er klart, at nogen stopper det.”

PRs 1020 og 1021

For at BIP 8 skal fungere, skal den ændres. Dette indebærer ændringer i signaleringsmekanismen, og det er de kode PR’er, der sigter mod at gøre det:

  • 1020: Ville gøre minearbejdssignalering unødvendig efter LOCKED_IN-fasen, da den bløde gaffel i denne fase allerede bestemt vil blive aktiveret.
  • 1021: Tillad, at nogle MUST_SIGNAL-blokke ikke signalerer.

1020 havde opnået anerkendelse på mødet den 2. februar, og 1021 blev oprindeligt anset for unødvendig.

”Ok, så 1021 er kun relevant, når minearbejdere IKKE har aktiveret gaffelen,” skrev Dashjr. “1021 er KUN i UASF-scenariet … det tillader op til 5% af blokke at mangle det krævede signal … IMO dette er meningsløst og øger bare kompleksiteten.”

Men senere i udvekslingen, Blockstream-forsker Nick Jonas påpegede 1021 kunne være nødvendigt.

“Re # 1021, hvis du beslutter at køre bip8 (true) med de fleste noder, der stadig kører bip8 (false), ville du virkelig ikke køre kode, der ikke implementerer # 1021, fordi du ellers kan ende i den forkerte kæde,” skrev Jonas.

”Nick har et stærkt punkt,” svarede Dashjr senere i IRC. “Uden 1021 kunne du køre LOT = true og ikke følge den Taproot-aktiverede kæde!”

I en anden udveksling, der er relevant for disse PR’er, bemærkede Towns, hvordan disse PR’er kunne være relevante for dårlige aktørers potentiale.

“(1) argumentet her er, at der under en UASF, der kræver signalering, skaber en risiko for kædesplit – hvis en blok ikke signalerer, vil en ikke-UASF-minearbejder bygge videre på det, men alle ved, at begge blokke vil blive afvist, så det er en mulighed for angribere at fordoble. at acceptere så mange ikke-signaliserende blokke som muligt (dvs. op til 5%) begrænser det angreb, ”skrev Towns. “(2) den anden overvejelse er, hvis du starter med en længere timeout (timeout = 2 år, lockinontimeout = true / false) og derefter vil fremskynde aktiveringen, fordi alle er opgraderet, markeder siger, at de vil have det, og der er 6% af minearbejdere, der prøver at overbevise alle om, at bitcoin suger, og vi skal flytte til en anden kæde, så kan vi indstille (timeout = 1 år, lockinontimeout = sandt). ”

“Men disse minearbejdere vil skabe et problem, når vi alligevel når 5%, ikke?” Spurgte Dashjr.

“” Opret et problem, når vi når 5% “- ja,” svarede byerne, “hvis der er >tærskelminearbejdere, de kan skabe et problem; hvis der kun er 2% eller deromkring, undgår dette, at der er et problem, hvis vi gør kortere timeout med lockinontimeout = true, så hvis vi rammer timeout og får 98% af blokke signalering, men ikke 100%, dette sikrer, at alle forbliver i konsensus , og selvom det er 98% kæden, der fortsætter med den længste vægt, behøver de mennesker, der udførte den hurtige UASF i bip148-stil, ikke nedgradere deres software. ”

“Givet 1021 er UASF-scenariet kun nødvendigt at flette det indtil et usandsynligt punkt, hvor det er nødvendigt?” Spurgte Folkson.

“Ja, det er kun meningsfuldt, hvis ‘gamle’ noder kører denne kode,” svarede bruger ghost43.

I sidste ende blev begge PR’er fusioneret.

Sammenfattende

BIP 8 (som er en variant af BIP 9) ser ud til at være den mest seriøse aktiveringsmekanisme i øjeblikket. Men der er kontroverser om, hvorvidt aktiveringen skal være fast, selvom den udgør risikoen for en UASF, der nægter minearbejdere en vetomagt; gøre det sikkert med sandsynligheden for at forsinke aktivering i tilfælde af utilstrækkelig signalering eller sæt falsk som standard, og aktiver om nødvendigt sand. Tilhængerne af den første mulighed mener, at minearbejdere ikke skal være i stand til at forstyrre en samfundsproces, mens tilhængere af den anden mulighed mener, at et UASF-tilbagefald er unødvendigt og viser en ubegrundet pålæggelse, da minearbejdere har vist accept af Taproot.

PR 1021 er en sikrere generel bugfix af BIP 8, da det i nogle tilfælde forhindrer en kædedeling, hvor mere end 95 procent, men mindre end 100 procent af al hashkraft understøtter den bløde gaffel.

Det næste Taproot-aktiveringsmøde (tirsdag den 16. februar kl. 19:00 UTC) er indstillet til at fokusere på kodegennemgang, som efterfølges af et andet møde for at diskutere parametrene. Efterhånden som diskussionen fortsætter, kommer Bitcoin tættere på den mest betydningsfulde protokolopgradering i år.