Taproot og storm i eit vassglas

Taproot (norsk: pålerot) er ei planlagt oppgradering av Bitcoin-protokollen som vil føra til mange og viktige forbetringar. Det vil gi Bitcoin betre og meir fleksible skript (smarte kontraktar) og på same tid gi betre personvern. Sjølv kompliserte smarte kontraktar vil bli uråd å skilja frå vanlege transaksjonar. 

Schnorr-signaturar
Mykje av grunnen er endring av metoden for digitale signaturar. I dag brukar Bitcoin ECDSA (Elliptic Curve Digital Signature Algorithm), men med Taproot blir denne erstatta med Schnorr-signaturar, etter den tyske matematikaren og kryptografen Claus-Peter Schnorr. Fordelen med Schnorr-signaturar er at dei er enkle og tek liten plass. 

Sidan Claus-Peter Schnorr patenterte den nye signaturmetoden, burde me ikkje heidra han med å kalla det Schnorr-signaturar, men det er det dei blir kalla. Patentet gjekk ut i februar 2008. Satoshi Nakamoto var sikkert kjende med dette, men truleg var arbeidet med Bitcoin komme så langt at det var for seint å ta inn Schnorr-signaturar.

Bitcoin og smarte kontraktar
Alle bitcoin er låste til eit skript som fortel kva som skal til for å få eigarskap til innhaldet (bitcoin). Å få eigarskap til bitcoin og kunna bruka dei vidare i nye transaksjonar, krev ein digital signatur for å bevisa eigarskap. Vilkåra for bruk kan vera koda inn i skriptet:

• bitcoin kan berre brukast etter ei viss tid (etter eit visst tal nye blokker)
• bitcoin kan berre brukast ved bruk av fleire signaturar (multisig.)

Slike vilkår kan kombinerast til relativt kompliserte strukturar som eigentleg er smarte kontraktar. Begrepet smart kontrakt blir gjerne ikkje assosiert med Bitcoin fordi skript-språket ikkje er Turing-komplett, men det er faktisk det det er.

MAST

Gjennom overføringsmåten Pay To Script Hash (P2SH), som kom i 2012), blir vilkåra "gøymde" i ein hash av eit skript. Den som krev eigarskap til transaksjonen, må visa skriptet og løysinga på skriptet. Problemet er at det "lek" ein god del data og er dårleg for personvernet. For å komma rundt dette, blir MAST (Merkelized Abstract Syntax Tree) føreslått. Det vil føra for langt å gå inn på detaljane, men poenget er at med MAST treng ikkje skriptet avslørast for at eigarskapen skal kunna bevisast.

Aktivering av Taproot
Taproot er klart til å bli innlemma i Bitcoin-koden og aktivering skjer etter at 90 % av gravarane har signalisert støtte, dvs. 90 % av blokkene (BIP 9). Taproot blir innført som ei mjuk forgreining (soft fork), i tråd med Bitcoins forsiktige endringsfilosofi. Men sjølv ei mjuk forgreining kan skapa problem, og problemet er sjølve aktiveringa.

Ei mjuk forgreining tvingar ikkje brukarane (fullnodar) til å oppgradera programvara, Bitcoin vil fungera sjølv utan ei oppgradering. Men gravarane må oppgradera, elles risikerer dei å produsera blokker som ikkje blir godkjende. Det er her faren for ei splitting av nettverket ligg. 

Førestill deg at Bitcoin godtek blokker av typen A og B. Etter ei mjuk splitting, skal berre blokker av typen A godtakast. Fullnodar som ikkje oppgraderer, vil framleis godta nye blokker fordi dei alltid har godteke blokker av type  A. Men for ein gravar er det annleis: dersom han set saman ei blokk av typen B, vil den ikkje bli godkjent av fullnodane som har oppgradert til nyaste versjon av programmet, og faren for ei (hard) splitting av nettverket er til stades.

Maktkamp til grunn?

Det er stor einigheit om innføringa av Taproot, så eigentleg er ikkje problemet noko problem. Når det likevel ser ut til å kunna bli eit problem, er det fordi maktkampen mellom brukarar (fullnodar) og gravarar spøker i bakgrunnen. Det er striden frå 2017 som lurer i bakgrunnen, og brukarane har igjen trua med å tvinga gjennom Taproot sjølv om 90 %-terskelen ikkje blir nådd innan fristen. Denne artikkelen i Bitcoin Magazine forklarer den innfløkte situasjonen (men du risikerer å bli endå meir forvirra etter å ha lese den!).

Sommaren 2017 utspelte det seg ein intens maktkamp i Bitcoin i diskusjonen om større blokker (tidlegare blogginnlegg om SegWit og SegWit2X). Det vart ein "game of chicken" der spørsmålet var kven som ville bøyga av først. Brukarane lanserte UASF (User-Activated Soft Fork) for å trua gjennom SegWit, men til slutt var det kompromiss-forslaget BIP 91 som vann fram. Om det hadde skjedd utan trugsmålet frå brukarane (UASF), veit me ikkje. Det spelte truleg ei viktig rolle.

Mange ønskjer ikkje å setja saka på spissen gjennom ein UASF, og leitar etter kompromiss. Eit nyleg framlagt forslag heiter Speedy Trial ("forsert rettsak") og går ut på å gi gravarane ein periode på tre månader for å signalisera støtte til Taproot. Viss eit tilstrekkeleg fleirtal signaliserer støtte, vil Taproot bli innført ei viss tid etter. Viss det ikkje er tilstrekkeleg større frå gravarane, blir ein annan aktiveringsplan lansert.