Taproot ble slått sammen i Bitcoin Core i oktober 2020, og etterlot bare aktiveringsmetoden for denne etterlengtede protokolloppgraderingen, fokusert på å legge til smart kontraktsfleksibilitet og mer transaksjonelt personvern til Bitcoin.

I forrige uke samlet Bitcoin-utviklingssamfunnet seg via Internet Relay Chat (IRC) for å diskutere parametrene for Taproot-aktivering og to kodetrekkforespørsler (PRs) til BIP 8-signalmekanismen..

“I et forsøk på å komme dette nærmere målstreken organiserer vi et møte på IRC på ## taproot-aktiveringskanalen tirsdag 2. februar kl 19:00 UTC,” Bitcoin utviklingsarrangør Michael Folkson kunngjort via bitcoin-dev-postlisten. “Det primære målet vil være å fullføre den reviderte BIP 8-aktiveringsmetoden …”

Til slutt ga møtet mer innsikt i hvordan Bitcoins viktigste protokollendring siden SegWit kan komme videre.

Redaktørens merknad: Uttalelsene gjengitt fra IRC nedenfor har blitt redigert litt for tydelighets skyld, men blir ellers presentert slik de ble skrevet.

Gi form til forslaget

Bitcoin-utvikler Anthony Towns har samlet forslag og mulige scenarier for aktivering av Taproot. I møtet 2. februar, de som ser ut til å ha mest støtte er “BIP 8 (false, 1y)” og “BIP 8 (true, 1y).” Imidlertid ble det ikke avstemt, det ble bare diskutert hver alternativ aktiveringsmetode.

Men hva betyr dette? BIP 8 er en mekanisme som gjør det mulig å oppgradere konsensus i Bitcoin-nettverket gjennom en myk gaffel, og spesifikt en miner-aktivert myk gaffel eller MASF med muligheten til å legge til en brukeraktivert myk gaffel (UASF) etter en stund. I den siste konsensusoppdateringen (SegWit) ble en brukeraktivert soft fork (UASF) brukt i tillegg til BIP 9’s MASF. Taproot ser imidlertid ut til å være ikke-kontroversiell for gruvearbeidere, så det virker mindre sannsynlig at en UASF ville være nødvendig denne gangen.

Når vi kommer tilbake til forslaget, er parameterne “lockinontimeout” og “timeout”, hvor lockinontimeout i utgangspunktet betyr om aktiveringen ville bli tvunget eller ikke, og “timeout” betyr vinduet der den ville bli aktivert. En annen relevant parameter som ikke fikk nok diskusjon var “startheight”.

Hvis lockinontimeout er falsk, og oppdateringen ikke har nok støtte, blir den kansellert og et nytt forslag blir definert. (Bitcoin-utvikler Luke Dashjr beskrevet lockintimeout = false som gir gruvearbeidere en ekstra kraft som de aldri var ment å ha),

“Hvis du begynner med (timeout = T, lockinontimeout = false), er det tre muligheter når T treffes: aktiveringen mislykkes, du prøver igjen med en ny aktivering (timeout = T + 1 år, lockinontimeout = true, f.eks.); før da ber du alle om å bytte programvare til (timeout = T, lockinontimeout = true), på hvilket tidspunkt du har oppgradert MASF til en UASF, ”skrev Towns på IRC. “Det er også muligheten for å få alle til å oppgradere til programvare som spesifiserer (timeout = T-6 måneder, lockinontimeout = true). I så fall begynner de som har oppgradert å avvise blokker på T-6months, og hvis den lengste kjeden aktiveres innen den tiden vil både gammel og ny programvare ha soft-fork aktivert. ”

Imidlertid er Dashjr uenig i lockinontimeout = false:

“… er vi fornøyd med lockingtimeout = false generelt?”, Bitcoin Developer Maxim Orlovsky spurte.

“Ja,” Lynutvikler Rusty Russell svarte. “Vi har en UASF-hammer hvis vi trenger den, men det er bedre å ikke bruke den.”

“Mye = sant betyr ikke at vi bruker det, mye = falsk betyr at hensikten er å la gruvearbeidere bestemme,” skrev Dashjr. “BIP8 (falsk) er en regresjon.”

Men Russell argumenterte mot det han ser på som en utviklerimposisjon: “Jeg føler at det er viktig å unngå utseendet til utviklermandat over protokollen, og jeg liker også å ha en fluktluke hvis det skulle oppstå problemer før aktivering,” skrev han. “Dermed foretrekker jeg å starte med lockin = false, og gå tilbake til 6 måneder hvis den ikke har aktivert.”

“Det er ikke noe utviklermandat … er mer fornuftig å gjøre 1 år, falsk og 1 år, sant for den samme 1-årsperioden [i tilfelle to påfølgende distribusjoner],” svarte Dashjr.

Men Russell så ikke ut til å bli påvirket:

“Jeg er uenig,” skrev han. “Gruvearbeidere får koordineringskraft fordi vi pålitelig kan måle dem på en desentralisert måte, i motsetning til andre grupper. Det innebærer muligheten til å * ikke * koordinere, ja. Men vi har en plan for det også, ettersom BIP-8 gjør en UASF mye mindre sannsynlig å forårsake en splittelse. Det er så bra som vi kan gjøre. “

“Mye = sann IS-planlegging for det,” Dashjr skrev som svar, “det hindrer ikke gruvearbeidere i å gjøre MASF.”

Andre i chatten foreslo å gjøre lockinontimeout = false valgfritt, men standard:

“Lot = false er tryggere enn lot = true, så det er verdt å gjøre mye = false først gitt at vi vet at hashpower allerede er ~ 90% pro-taproot,” skrev CoinSwap-utvikler Chris Belcher.

Hvis brukere enkelt kan endre mye = usant til mye = sant på et tidspunkt uten å kreve en ny kjerneutgivelse, støtter jeg å la lot = falsk standard, ” Keagan McClelland skrev.

UASF-hammeren

Å avklare:

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

Så lenge gruvearbeidere aktiveres, forekommer ingen UASF.

Den forhåndsplanlagte UASF sørger også for at MASF skjer:

Det unngår å gi gruvearbeiderne vetorett, og skaper riktig insentiv for å sikre at en MASF oppstår.#Bitcoin #Taproot

– Luke Dashjr (@LukeDashjr) 2. februar 2021

Dashjr vil bruke “BIP 8 (true)”, en UASF-reserve, som en spillteorienhet for å sikre at gruvearbeidere vil aktivere Taproot, og ikke gi dem mulighet til å “veto” makt, akkurat som det som skjedde med SegWit.

“Gitt signalkravene, hvilken type stalling eller sorgangrep kan et gruvebasseng oppnå hvis de verdsetter stalling av taproot?” spurte en bruker kalt “hansket” i IRC 2. februar. “F.eks. misbruke den marginale hashraten som kreves for aktivering.”

Som en påminnelse handler signalering om å redusere gaffelrisiko og har ingenting å gjøre med politisk støtte eller avstemning.

“MASF er den foretrukne banen, med UASF som en tilbakeslag hvis gruvearbeidere ikke signaliserer,” skrev Dashjr. “Samfunnet kan flytte UASF raskere hvis det er klart noen stopper den.”

PRs 1020 og 1021

For å gjøre BIP 8 funksjonell, må den endres. Dette innebærer endringer i signalmekanismen, og dette er kodene PR som tar sikte på å gjøre det:

  • 1020: Ville gjøre gruvearbeidersignalering unødvendig etter LOCKED_IN-fasen, da den myke gaffelen allerede definitivt vil bli aktivert av denne fasen.
  • 1021: La noen MUST_SIGNAL-blokker ikke signalisere.

1020 hadde fått bekreftelse på møtet 2. februar, og 1021 ble opprinnelig ansett som unødvendig.

“Ok, så 1021 er bare relevant når gruvearbeidere IKKE har aktivert gaffelen,” skrev Dashjr. “1021 er KUN i UASF-scenariet … det tillater opptil 5% av blokkene å mangle det nødvendige signalet … IMO dette er meningsløst og øker bare kompleksiteten.”

Men senere i utvekslingen, Blockstream-forsker Nick Jonas påpekte 1021 kan være nødvendig.

“Re # 1021, hvis du bestemmer deg for å kjøre bip8 (true) med de fleste noder som fortsatt kjører bip8 (false), vil du virkelig ikke kjøre kode som ikke implementerer # 1021 fordi du kan havne i feil kjede ellers,” skrev Jonas.

“Nick har et sterkt punkt,” svarte Dashjr, senere i IRC. “Uten 1021 kan du kjøre LOT = true og ikke klare å følge den Taproot-aktiverte kjeden!”

I en annen utveksling som var relevant for disse PR-ene, bemerket Towns hvordan disse PR-ene kunne være relevante for potensialet til dårlige skuespillere.

“(1) argumentet her er at under en UASF, som krever signalering, skaper en risiko for kjedesplitt – hvis en blokk ikke signaliserer, vil en ikke-UASF-gruvearbeider bygge videre på det, men alle vet at begge blokkene vil bli avvist, så det er en mulighet for angripere å doble utgifter. å akseptere så mange ikke-signaliserende blokker som mulig (dvs. opptil 5%) begrenser angrepet, ”skrev Towns. “(2) det andre hensynet er hvis du starter med en lengre tidsavbrudd (timeout = 2 år, lockinontimeout = true / false) og deretter vil øke hastigheten på aktiveringen, fordi alle er oppgradert, markedene sier at de vil ha det, og det er 6% av gruvearbeidere som prøver å overbevise alle om at bitcoin suger, og vi bør flytte til en annen kjede, så kan vi stille (timeout = 1 år, lockinontimeout = true). ”

“Men disse gruvearbeiderne vil skape et problem når vi uansett når 5%, ikke sant?” Spurte Dashjr.

“” Lag et problem når vi når 5% “- ja,” svarte Towns, “hvis det er >terskelgruvearbeidere de kan skape et problem; hvis det bare er 2% eller så, unngår dette at det er et problem hvis vi gjør kortere timeout med lockinontimeout = true, så hvis vi treffer timeout, og får 98% av blokkene som signaliserer, men ikke 100%, sikrer dette at alle forblir i konsensus , og selv om det er 98% -kjeden som fortsetter med den lengste vekten, trenger ikke folk som gjorde den raske UASF-bip148-stilen, nedgradere programvaren. ”

“Gitt 1021 er det bare UASF-scenariet som trenger å bli slått sammen til et usannsynlig punkt der det er behov for det?” Spurte Folkson.

“Ja, det er bare meningsfullt hvis” gamle “noder kjører denne koden,” svarte bruker ghost43.

Til slutt ble begge PR-ene slått sammen.

Oppsummert

BIP 8 (som er en variant av BIP 9) ser ut til å være den mest alvorlige aktiveringsmekanismen for øyeblikket. Men det er kontrovers om aktiveringen skal være fast, selv om den representerer risikoen for en UASF, som nekter gruvearbeidere en vetorett; gjør det trygt med sannsynligheten for å forsinke aktivering i tilfelle utilstrekkelig signalering; eller sett false som standard, og aktiver om nødvendig sant. Tilhengerne av det første alternativet mener at gruvearbeidere ikke skal være i stand til å forstyrre en samfunnsprosess, mens tilhengere av det andre alternativet mener at en UASF-tilbakefall er unødvendig og viser en uberettiget pålegg siden gruvearbeidere har vist aksept av Taproot.

PR 1021 er en tryggere generell feilkorrigering av BIP 8, siden det i noen tilfeller forhindrer en kjedesplitt der mer enn 95 prosent, men mindre enn 100 prosent av all hashkraft støtter den myke gaffelen.

Neste Taproot-aktiveringsmøte (tirsdag 16. februar kl. 19:00 UTC) er satt til å fokusere på kodegjennomgang, som vil bli fulgt av et nytt møte for å diskutere parametrene. Etter hvert som diskusjonen fortsetter, kommer Bitcoin nærmere den viktigste protokolloppgraderingen på flere år.