Taproot slogs samman i Bitcoin Core i oktober 2020 och lämnade bara aktiveringsmetoden för den efterlängtade protokolluppgraderingen med fokus på smart kontraktsflexibilitet och mer transaktionsintegritet till Bitcoin.

Förra veckan samlades Bitcoin-utvecklingsgemenskapen via Internet Relay Chat (IRC) för att diskutera parametrarna för Taproot-aktivering och två koddragningsförfrågningar (PRs) för BIP 8-signalmekanismen.

“I ett försök att komma närmare mållinjen anordnar vi ett möte på IRC på ## taproot-aktiveringskanalen tisdagen den 2 februari kl 19:00 UTC,” Bitcoin utvecklingsarrangör Michael Folkson tillkännagavs via bitcoin-dev-e-postlistan. “Det primära målet kommer att vara att slutföra den reviderade BIP 8-aktiveringsmetoden …”

I slutändan gav det mötet mer insikt i hur Bitcoins viktigaste protokollförändring sedan SegWit kan gå framåt.

Redaktörens anmärkning: Uttalandena som återges från IRC nedan har redigerats något för tydlighetens skull men presenteras annars när de skrevs.

Ge form till förslaget

Bitcoin-utvecklare Anthony Towns har sammanställt förslag och möjliga scenarier för aktivering av Taproot. I mötet den 2 februari, de som verkar ha mest stöd är “BIP 8 (falskt, 1y)” och “BIP 8 (true, 1y).” Ingen röstning togs dock, det diskuterades bara varje alternativ aktiveringsmetod.

Men vad betyder detta? BIP 8 är en mekanism som gör det möjligt att uppgradera konsensus i Bitcoin-nätverket genom en mjuk gaffel, och särskilt en gruvarbetad mjukgaffel eller MASF med möjlighet att lägga till en användaraktiverad mjukgaffel (UASF) efter en tid. I den senaste konsensusuppdateringen (SegWit) användes en användaraktiverad mjukgaffel (UASF) utöver BIP 9: s MASF. Taproot verkar dock vara kontroversiell för gruvarbetare, så det verkar mindre troligt att en UASF skulle vara nödvändig den här gången.

När vi kommer tillbaka till förslaget är parametrarna “lockinontimeout” och “timeout”, där lockinontimeout i princip betyder om aktiveringen skulle tvingas eller inte och “timeout” betyder det fönster där den skulle aktiveras. En annan relevant parameter som inte fick tillräckligt med diskussion var “startheight”.

Om lockinontimeout är falskt och uppdateringen inte har tillräckligt med stöd avbryts den och ett nytt förslag definieras. (Bitcoin-utvecklare Luke Dashjr beskrev lockintimeout = falsk som att ge gruvarbetare en extra kraft som de aldrig var avsedda att ha),

”Om du börjar med (timeout = T, lockinontimeout = false) finns det tre möjligheter när T träffas: aktiveringen misslyckas, du försöker igen med en ny aktivering (timeout = T + 1 år, lockinontimeout = sant, t.ex.); innan du säger till alla att byta programvara till (timeout = T, lockinontimeout = true) vid vilken tidpunkt du har uppgraderat MASF till en UASF, “skrev Towns på IRC. ”Det finns också möjlighet att få alla att uppgradera till programvara som specificerar (timeout = T-6 månader, lockinontimeout = true), i vilket fall de som har uppgraderat kommer att börja avvisa block vid T-6 månader, och om den längsta kedjan aktiveras vid den tiden kommer både gammal och ny programvara att ha mjukgaffeln aktiverad. ”

Men Dashjr håller inte med om lockinontimeout = false:

“… är vi nöjda med lockingtimeout = falskt i allmänhet ?,” Bitcoin Developer Maxim Orlovsky frågade.

”Ja,” blixtutvecklare Rusty Russell svarade. “Vi har en UASF-hammare om vi behöver den, men det är bättre att inte använda den.”

”Lot = true betyder inte att vi använder det, lot = false betyder att avsikten är att låta gruvarbetare bestämma”, skrev Dashjr. “BIP8 (falskt) är en regression.”

Men Russell argumenterade mot det som han ser som en utvecklarimission: “Jag tycker att det är viktigt att undvika att utvecklarmandat framträder över protokollet, och jag gillar också att ha en flyktlucka om det skulle finnas problem före aktivering”, skrev han. “Således föredrar jag att börja med lockin = falskt och se över vid 6 månader om det inte har aktiverats.”

“Det finns inget utvecklarmandat … meningsfullare att göra 1 år, falskt än 1 år, sant under samma 1-årsperiod [vid två efterföljande distributioner],” svarade Dashjr.

Men Russell verkade inte svängas:

“Jag håller inte med”, skrev han. ”Gruvarbetare får samordningsförmåga eftersom vi på ett tillförlitligt sätt kan mäta dem på ett decentraliserat sätt, till skillnad från andra grupper. Det innebär förmågan att * inte * samordna, ja. Men vi har en plan för det också, eftersom BIP-8 gör en UASF mycket mindre benägna att orsaka en splittring. Det är så bra som vi kan göra. ”

“Mycket = sann IS-planering för det”, skrev Dashjr som svar, “det hindrar inte gruvarbetare från att göra MASF.”

Andra i chatten föreslog att lockinontimeout = falskt valfritt, men standard:

“Lot = false är säkrare än lot = true, så det är värt att göra lot = false först med tanke på att vi vet att hashpower är ~ 90% redan pro-taproot,” skrev CoinSwap-utvecklaren Chris Belcher.

Iif-användare kan enkelt byta lot = falskt till parti = sant någon gång utan att behöva en ny kärnaversion, jag skulle stödja att lämna lot = falskt som standard, ” Keagan McClelland skrev.

UASF-hammaren

Att förtydliga:

BIP8 w / LockinOnTimeout är en MASF med UASF-reserv.

Så länge gruvarbetare aktiveras inträffar ingen UASF.

Den förplanerade UASF säkerställer också att MASF händer:

Det undviker att ge gruvarbetarna vetorätt och skapar rätt incitament för att säkerställa att en MASF uppstår.#Bitcoin #Pålrot

– Luke Dashjr (@LukeDashjr) 2 februari 2021

Dashjr vill använda “BIP 8 (true)”, en UASF-reserv, som en spelteori-enhet för att se till att gruvarbetare kommer att aktivera Taproot, och inte ge dem möjlighet att “veto”, precis som vad som hände med SegWit.

“Med tanke på signalkraven, vilken typ av stalling eller sorgsangrepp kan en gruvpool uppnå om de värdesätter stående taproot?” frågade en användare som heter “handskad” i IRC den 2 februari. “Till exempel missbruk av det marginella hashrat som krävs för aktivering.”

Som en påminnelse handlar signalering om att minska gaffelriskerna och har inget att göra med politiskt stöd eller röstning.

“MASF är den föredragna vägen, med UASF som en reserv om gruvarbetare misslyckas med att signalera”, skrev Dashjr tillbaka. “Samhället kan flytta UASF tidigare om det är tydligt att någon stoppar den.”

PR 1020 och 1021

För att BIP 8 ska fungera måste den ändras. Detta innebär förändringar i signalmekanismen och det här är kod-PR: erna som syftar till att göra det:

  • 1020: Skulle göra gruvsignalering onödig efter LOCKED_IN-fasen, eftersom denna mjuka gaffel redan definitivt kommer att aktiveras av denna fas.
  • 1021: Tillåt att vissa MUST_SIGNAL-block inte signalerar.

1020 hade fått bekräftelse vid mötet den 2 februari och 1021 ansågs ursprungligen onödigt.

“Ok, så 1021 är bara relevant när gruvarbetare INTE har aktiverat gaffeln”, skrev Dashjr. “1021 är ENDAST i UASF-scenariot … det gör att upp till 5% av blocken saknar den nödvändiga signalen … IMO detta är meningslöst och ökar bara komplexiteten.”

Men senare i utbytet, Blockstream-forskare Nick Jonas påpekade 1021 kan vara nödvändigt.

“Re # 1021, om du bestämmer dig för att köra bip8 (true) med de flesta noder som fortfarande kör bip8 (false) skulle du verkligen inte köra kod som inte implementerar # 1021 eftersom du annars kan hamna i fel kedja”, skrev Jonas.

“Nick har en stark punkt”, svarade Dashjr, senare i IRC. “Utan 1021 kan du köra LOT = true och inte följa den Taproot-aktiverade kedjan!”

I ett annat utbyte som är relevant för dessa PR noterade Towns hur dessa PR kunde vara relevanta för dåliga aktörers potential.

“(1) argumentet här är att under en UASF, som kräver signalering, skapar en risk för kedjesplittringar – om ett block inte signalerar kommer en icke-UASF-gruvarbetare att bygga på det, men alla vet att båda blocken kommer att avvisas, så det är en möjlighet för angripare att dubbla utgifterna. att acceptera så många icke-signalblock som möjligt (dvs. upp till 5%) begränsar attackerna, ”skrev Towns. “(2) det andra övervägandet är om du börjar med en längre timeout (timeout = 2 år, lockinontimeout = true / false) och sedan vill påskynda aktiveringen, eftersom alla är uppgraderade, marknader säger att de vill ha det, och det finns 6% av gruvarbetare som försöker övertyga alla bitcoin suger och vi ska flytta till en annan kedja, då kan vi ställa in (timeout = 1 år, lockinontimeout = true). ”

“Men dessa gruvarbetare kommer att skapa ett problem när vi ändå når 5%, eller hur?” Frågade Dashjr.

“” Skapa ett problem när vi når 5% “- ja,” svarade Towns, “om det finns >tröskelgruvarbetare kan de skapa problem; om det bara är 2% eller så undviker detta att det finns ett problem om vi gör kortare timeout med lockinontimeout = true, då om vi träffar timeout och får 98% av blockeringssignaleringen men inte 100%, detta säkerställer att alla förblir i konsensus , och även om det är 98% -kedjan som fortsätter med den längsta vikten, behöver inte de människor som gjorde den snabba UASF i bip148-stil nedgradera sin programvara. ”

“Med tanke på 1021 är UASF-scenariot bara behöver det slås samman tills en osannolik punkt där det behövs?” Frågade Folkson.

“Ja, det är bara meningsfullt om” gamla “noder kör den här koden,” svarade användaren ghost43.

Till slut slogs båda PR-enheterna samman.

Sammanfattningsvis

BIP 8 (som är en variant av BIP 9) verkar vara den allvarligaste aktiveringsmekanismen just nu. Men det finns kontroverser om huruvida aktiveringen ska vara fast, även om den utgör en risk för en UASF, som förnekar gruvarbetarna vetorätt; göra det säkert med sannolikheten att fördröja aktiveringen vid otillräcklig signalering; eller ange falskt som standard och aktivera vid behov sann. Anhängarna av det första alternativet tycker att gruvarbetare inte borde behöva störa en samhällsprocess, medan anhängare av det andra alternativet tycker att en UASF-reserv är onödig och visar en oberättigad påläggning eftersom gruvarbetare har visat sig acceptera Taproot.

PR 1021 är en säkrare allmän bugfix av BIP 8, eftersom det i vissa fall förhindrar en kedjedelning där mer än 95 procent men mindre än 100 procent av all hashkraft stöder den mjuka gaffeln.

Nästa Taproot-aktiveringsmöte (tisdag 16 februari kl 19:00 UTC) är inställt på att fokusera på kodgranskning, vilket kommer att följas av ett annat möte för att diskutera parametrarna. När diskussionen fortsätter kommer Bitcoin närmare sin viktigaste protokolluppgradering på flera år.