Förändringar av bitcoin
Det är lätt att känna att förbättringar och uppgraderingar av Bitcoin går mycket, mycket långsamt. En del minns kanske den infekterade debatten kring Segwit, hur lång tid det tog innan konsensus slutligen nåddes och också hur långsamt det faktiska användandet av den nya funktionen har spridits. Att det går långsamt beror för det första på att utvecklingen av Bitcoin bedrivs på ett medvetet konservativt sätt bl.a. p.g.a de allvarliga följder som buggar kan få.
Det kan gå fel på många sätt, t.ex. så skulle en liten förbisedd detalj i en ändring kunna leda till att noderna på nätverket inte längre är överens om vilken som är den längsta kedjan, vilket förstås vore katastrofalt. Detta hände faktiskt 2013 när Bitcoin Core ändrade sin interna databas från BerkeleyDB till LevelDB vilket fick oväntade konsekvenser som gjorde att denna nya version av mjukvaran inte var överens med äldre versioner om vilken kedja som var den rätta, något som innebar att nätverket under ca 6 timmar var i ett högst oklart tillstånd.
Det ligger också i sakens natur att något som ska fungera som en värdebevarare inte kan förändras på ett nyckfullt sätt. Om dina bitcoin ska kunna behålla sitt värde över tid måste folk kunna lita på att reglerna för vad som är bitcoin inte plötsligt ändras. Ta t.ex. en sådan fundamental sak som att det aldrig kommer att finnas mer än ca 21 miljoner bitcoin. Skulle folk misstänka att denna regel kan komma att ändras så tappar bitcoin nästan all sin trovärdighet som värdebevarare.
Detta är alltså några av anledningarna till att bitcoins utveckling i praktiken går ganska långsamt. När en större ändring föreslagits är det även så att aktiveringsprocessen av en sådan förändring kan ta tid, vilket var vad som hände med ovan nämnda Segwit. Bitcoin har inte sedan de mycket tidiga dagarna gjort några planerade s.k. hard forks (läs mer om skillnaden mellan hard forks och soft forks) så för den typen av uppgraderingar som vi pratar om finns inget krav på den som kör en egen nod att uppgradera, den gamla mjukvaran kommer att fortsätta fungera oavsett om du väljer att göra det eller ej. Det spelar dock en roll för miners eftersom en miner som inte anpassar sig till de nya regler som andra använder sig av riskerar att producera block som inte accepteras av nätverket. På grund av detta vill man inte heller släppa ut soft forks hur som helst utan vill gärna göra det på ett synkroniserat sätt som garanterar att alla, eller åtminstone de flesta, miners är med på tåget innan ändringen sker. Vi återkommer till detta lite längre ned.
Taproot
Men först: Den ändring som just nu håller på att införas kallas Taproot och är en förändring av bitcoins script och signaturer som kommer att förbättra såväl skalbarhet som säkerhet och privacy. Den nya algoritmen för signaturer som kallas Schnorrsignaturer och nu alltså är på väg att bli verklighet skrev jag om redan för två år (vilket kanske är ett exempel på hur försiktigt sådana här ändringar hanteras av Bitcoin Core). Du kan läsa om denna nya typ av signaturer här:
Med Schnorrsignaturer kommer bl.a. möjligheten att använda en enda aggregerad signatur istället för en för varje input vilket minskar den totala storleken för många transaktioner. En fördel med detta är förstås att fler transaktioner kommer att få plats i varje block och att avgifterna för dessa transaktioner kommer att bli märkbart lägre.
Genom att kombinera Schnorrsignaturer med något som kallas Merkelized Abstract Syntax Trees (MAST) kan Taproot göra så att komplexa bitcointransaktioner som t.ex. de transaktioner som används för att sätta upp en Lightningkanal och andra multisig-transaktioner ser ut precis som en "vanlig" bitcointransaktion. Det är alltså här som förbättringarna kring privacy kommer in. Med Taproot kommer det att vara betydligt svårare för de som analyserar blockkedjan att dra slutsatser om vad specifika transaktioner gör.
Aktivering av Taproot
Så hur går då aktiveringen av den här funktionen till? Sättet man har valt är att kräva att under en given period av 2016 block (samma perioder mellan vilka svårighetsgraden för miners ändras) så måste minst 90% av alla block innehålla en aktiverings-signal, alltså ett på förhand bestämt sätt för en miner att signalera att denne är "redo" för uppgraderingen.
Får vi 1815 block som signalerar för förändringen under en av dessa 2016-blocksperioder så anses uppgraderingen vara "inlåst" och kommer därmed att genomföras. Detta måste ske under någon av perioderna innan 11:e augusti och gör det det så kommer själva uppgraderingen att ske i november. Skulle detta inte ske innan 11:e augusti så kommer ingen uppgradering att ske (och vi kommer i så fall säkerligen att få utdragna diskussioner om hur man ska gå vidare för att trots allt kunna genomföra dessa förändringar).
Svenske Hampus Sjöberg har gjort en utmärkt sajt, taproot.watch, där vi kan följa hur olika miners signalerar och hur prognosen ser ut. I skrivande stund verkar det mycket troligt att Taproot kommer att låsas in under denna period då 248 av 254 block (97,6 %) hittills har signalerat för förändringen.
Alla miningpooler utom ett par stycken små pooler verkar nu signalera konsekvent i varje block så det tycks mycket osannolikt att Taproot inte skulle bli av, och vi kan alltså alla glädjas åt en betydligt smidigare uppgradering än Segwit. Snyggt jobbat alla fantastiska bitcoinutvecklare!