Tilsyneladende uforstyrret af 2020’s vanvid og stort set upåvirket af bitcoins vilde prissvingninger, der blev afsluttet med nye all-time højder i december, fortsætter Bitcoins tekniske samfund med at pløje fremad. Bitcoins software og de mange projekter omkring det blev gradvist forbedret i løbet af året, da software blev optimeret, bugs fikseret og privatlivslækninger patched. Hovedparten af ​​dette arbejde, så vigtigt som meget af det, tiltrækker ikke overskrifter.

Alligevel hjælper et fugleperspektiv på Bitcoins teknologiske udvikling i løbet af et år med at fremhæve nye milepæle i Bitcoins igangværende teknologiske march fremad. Også i 2020 introducerede det konstant voksende Bitcoin-udviklingssamfund en række nyttige nye funktioner, flere særligt vigtige opgraderinger og nogle især bemærkelsesværdige forbedringer.

Da dette ustabile år nærmer sig slutningen, var disse nogle af Bitcoins mest bemærkelsesværdige tekniske udvikling i løbet af de sidste 12 måneder …

Nye værktøjer til beskyttelse af personlige oplysninger med PayJoin og CoinSwap

På Bitcoins privatlivsfront repræsenterede PayJoin og CoinSwap-projekterne i år to lovende fremskridt.

PayJoin, også kendt som Pay to Endpoint (P2EP), er et trick, der lader modtagere af en transaktion deltage i transaktionen gennem en CoinJoin, for grundlæggende at sende penge til sig selv, samtidig med at de også modtager den faktiske betaling fra den rigtige afsender. Hvis en snoop, der gennemfører blockchain-analyse, skulle antage, at alle mønter, der blev sendt i en transaktion, tilhørte den samme person – som de normalt ville – de ville tage fejl. Dette er allerede til fordel for både afsender og modtageres privatliv, da snoopet ville forvirre (tidligere) mønt ejerskab mellem dem. Desuden, hvis nok mennesker bruger PayJoin, kan det gøre denne vigtige heuristik til blockchain-analyse ubrugelig helt, hvilket til gengæld gavner selv privatlivet for dem, der ikke selv foretog PayJoin-transaktioner.

Selvom demo-versioner af PayJoin-værktøjet allerede var implementeret til online-spil Bustabit og møntblandingssoftwaren JoinMarket i slutningen af ​​2018 og Samourai Wallet i 2019 frigivet sin egen – mere begrænsede – version under Cohoots-paraplyen (med lidt forskellige fortroligheder mellem privatlivets fred) blev PayJoin i år implementeret i flere populære Bitcoin-projekter. Dette omfattede især den meget anvendte betalingsbehandlingssoftware BTCPay i April, tillader BTCPay-brugere at acceptere PayJoin-transaktioner fra kompatible tegnebøger. Den fortrolighedsfokuserede Wasabi Wallet var den første tegnebog, der tilbyder denne kompatibilitet senere samme måned, mens JoinMarket (september), Blå tegnebog (oktober) og Sparrow Wallet (november) fulgte senere på året.

I mellemtiden satte Bitcoin-udvikler Chris Belcher sig for at realisere en implementering af CoinSwap, en fortrolighedsteknik først foreslået i 2013 af Bitcoin Core-bidragyder Gregory Maxwell. CoinSwap udnytter Atomic Swaps (det trick, der også understøtter Lightning Network) for at lade brugerne udveksle mønter uden at skulle stole på hinanden. Hver bruger ender med mønter, der ikke kan linkes til deres egen transaktionshistorik.

Belcher, en af ​​verdens førende eksperter inden for Bitcoin-privatliv, i Kan offentliggjorde en detaljeret oversigt over, hvordan CoinSwap-protokollen kunne implementeres for at sikre maksimal fortrolighed. Forslaget ville gøre CoinSwap-transaktioner skelne fra andre transaktioner, bruge opdelingsteknikker til at skjule beløb, rute betalinger for at frustrere snooping-deltagere og mere. Et par måneder senere, i juni, meddelte Human Rights Foundation, at dets første Bitcoin-udviklingsstipendium ville gå til Belcher og hans bestræbelser på at realisere projektet.

Efter at have arbejdet med hans implementering det meste af året, Belcher i december annonceret en “stor dag for bitcoin-privatliv og fungibilitet”: han havde foretaget den første succesrige CoinSwap-transaktion nogensinde på Bitcoins testnetværk (testnet).

Lynnetværket blev mere robust med vagttårne ​​(og mere)

The Lightning Network, Bitcoins Layer 2-protokol til hurtigere, billigere og mere private betalinger, fortsatte med at forbedre sig overalt i 2020. Med Lightning-implementeringer LND, Eclair, C-Lightning og – siden juli – Electrum udrullede en række nye softwareudgivelser, og et stigende antal projekter, der byggede oven på protokollen, var Lynudvikling mere aktiv end nogensinde. Blandt de mere bemærkelsesværdige udviklinger løste Vagttårne ​​en af ​​Lightning Networks resterende svagheder, hvilket resulterede i en mere robust protokol.

En af Lightning Network’s kompromiser er, at brugerne skal holde øje med deres betalingskanaler for at sikre, at betalingskanalpartnere ikke prøver at snyde ved at udsende gamle kanalstater for at kræve flere midler, end de tilskrives dem. Lynbrugere kan træde ind, hvis en kanalpartner forsøger at snyde, men dette kræver overvågning af Bitcoin-blockchain, hvilket afslappede brugere måske ikke gør meget regelmæssigt.

For at mindske risikoen for, at et forsøg på snyd bliver savnet, tillader Lightning-protokollen, at kanalovervågning outsources til upartiske observatører kaldet Vagttårne. Tilføjelse til den første Vagttårnssoftware introduceret af LND i slutningen af ​​2019, februar i år så alfa frigivelse af den dedikerede Watchtower implementering Eye of Satoshi. Kort efter blev den foreslåede Vagttårnets protokolspecifikation blev opdateret, mens C-Lightning rullede ud støtte til Eye of Satoshi i Kan. Version 1 af Eye of Satoshi fulgte ind juli.

Andre bemærkelsesværdige lynudviklinger i 2020 inkluderer det fortsatte arbejde med ankerudgange for at sikre, at brugerne kan kræve midler fra en kanal ensidigt, selv når on-chain-gebyrer er steget mere end forventet siden den sidste betalingskanalopdatering, Multipath betalinger som giver brugerne mulighed for at foretage lynbetalinger i mindre stykker, den indbyggede beskedapplikation til Lynnetværk Juggernaut, kanaladministrationsværktøj Faraday, Lightning Loop beta-udgivelsen, men også nogle nyligt opdagede svagheder samt (foreslåede) løsninger og meget mere.

Efter Miniscript blev Bitcoin-programmering lettere med Minsc

Koden indlejret i Bitcoin-transaktioner, der specificerer, hvilke betingelser der skal opfyldes for at bruge mønterne i en næste transaktion, er skrevet på et programmeringssprog, der er specielt designet til Bitcoin, kaldet Script. Script kan dog være vanskeligt at arbejde med: i programmørjargon er det svært at “begrunde” script. Dette betyder, at det, især da det bliver lidt mere komplekst, kan være svært at forstå, hvad et stykke script faktisk tillader: en transaktion kan utilsigtet indeholde kode, der gør det muligt at bruge mønterne under andre forhold end oprindeligt beregnet. Dette er en af ​​grundene til, at mange Bitcoin-softwareapplikationer, som tegnebøger, afholder sig fra at udnytte Script’s fulde potentiale.

I løbet af de sidste år har (tidligere) Blockstream-forskere Andrew Poelstra, Pieter Wuille og Sanket Kanjalkar designet en “strippet ned” version af Script, kaldet Miniscript. Miniscript er et udvalg af “værktøjer” fra “Script toolkit”, der er nøje udvalgt for at muliggøre praktisk talt alt, hvad der kan gøres med Script, men det er lettere at bruge og lettere at kontrollere af programmører. Så selvom en linje af Miniscript stadig er en gyldig linje af Script, undgår den i det væsentlige menneskelige fejl ved at forhindre uventede, måske utilsigtede resultater af koden; Miniscript er lettere at ræsonnere om. I november i år offentliggjorde leder af forskning og udvikling hos Rugged Bytes Dmitry Petukhov en formel specifikation af Miniscript.

For at gøre oprettelsen af ​​Bitcoin-transaktioner endnu nemmere, havde Wuille også designet et ”politiksprog” til Miniscript, et eget programmeringssprog, der kunne kompilere (konvertere) til Miniscript og dermed Script. På baggrund af Wuilles arbejde udviklede Bitcoin-udvikleren Nadav Ivgi i år endnu et nyt programmeringssprog kaldet Minsc. Først annonceret i juli, og fulgt op med en større opgradering i november, Minsc er stadig et igangværende arbejde, men er indstillet til at forenkle oprettelsen af ​​Bitcoin-transaktioner. Dette kan hjælpe med at låse op for en række lovende funktioner, der drager fuld fordel af Bitcoins alsidighed, som interoperable CoinJoin-tegnebøger, smarte kontraktløsninger, Layer 2-protokoller og mere.

Smarte kontrakter blev smartere med DLC’er

Når smarte kontrakter er afhængige af eksterne data – data, der ikke lever i blockchain – er de afhængige af en ekstern kilde for de data, der betegnes som et “orakel”. Hvis to brugere f.eks. Ønsker at satse på resultatet af en sportskamp, ​​skal oraklet bruge resultatet af kampen til at afvikle væddemålet til fordel for den, der forudsiger den korrekte forudsigelse (i det mindste i tilfælde af en tvist).

En meget grundlæggende sportsbetting-opsætning kunne bestå af en to-af-tre multisignatur (multisig) adresse, hvor begge spillere og oraklet alle har én tast hver, og oraklet informeres om detaljerne i væddemålet. Efter kampen kunne de to spillere samarbejde om at sende midlerne fra multisig til vinderen uden nøglen til oraklet. Men hvis taberen nægter at samarbejde, kan oraklet bruge sin tredje nøgle til at samarbejde med vinderen for at sende dem midlerne fra multisig. Dette system fungerer, men har to store ulemper. Den ene, begge spillere har brug for at stole på oraklet for ikke at samarbejde med deres modstander. Og to, oraklet skal informeres om væddemålet og måske spille en aktiv rolle i afviklingsprocessen: det betyder, at spillerne ikke har fortrolighed fra oraklet, mens opsætningen ikke skalerer meget godt, hvis mere end et par spillere vil vædde.

En bedre løsning var i 2017 foreslog af MIT Media Labs Digital Currency Initiative-forsker Thaddeus Dryja: diskrete logkontrakter (DLC’er). DLC’er bruger et smart matematisk trick, hvor oraklet udgiver en kryptografisk signatur, der svarer til resultatet af en begivenhed. I eksemplet ovenfor ville oraklet offentliggøre en signatur, hvis det første hold vinder, og en anden signatur, hvis det andet hold vinder. Tricket: den smarte kontrakt er designet til at lade den vindende spiller bruge den offentliggjorte signatur til at kræve pengene.

I en DLC minimeres oraklets engagement med den smarte kontrakt til offentliggørelsen af ​​en signatur; dette kunne f.eks. i sportsvæddemål udføres af en eksisterende nyhedstjeneste som en del af dens regelmæssige udsendelse. Dette betyder også, at oraklet ikke behøver at blive informeret om detaljerne i væddemålet, og faktisk ikke engang behøver at vide, at der overhovedet var et væddemål. I mellemtiden kan et hvilket som helst antal mennesker bruge underskrifterne til at afregne deres væddemål uden yderligere involvering fra oraklet, hvilket i høj grad drager fordel af skalerbarhed. Og mens orakel i teorien stadig kunne kollidere med nogen og udsende det forkerte resultat, ville en sådan uærlig opførsel være åbenbar for enhver og plette orakelets omdømme fremadrettet.

I januar i år meddelte CEO Chris Stewart, at hans firma Suredbits i samarbejde med Crypto Garage var begyndt at arbejde på en specifikation for DLC’er. I februar, Suredbits-ingeniør Nadav Kohen fulgte op med den første arbejdskode. Og ved september, Suredbits og Crypto Garage havde udviklet deres software til det punkt, hvor den kunne bruges: Stewart og Bitcoin-udvikleren Nicolas Dorier beskæftigede sig med Bitcoins første nogensinde DLC for at satse på resultatet af det amerikanske præsidentvalg. Stewart, der havde satse på Biden, krævede sin gevinst i december.

Holding bliver sikrere med Bitcoin Vaults

Den lange liste over byttehacks og andre bitcoin-heists er et bevis på, at sikker opbevaring af private nøgler fortsat er en udfordring, især hvor mange mønter står på spil.

Men mere sikre løsninger til opbevaring af mønter er under udvikling. Bitcoin hvælvinger – et koncept, der går tilbage til 2016 – er en type smart kontrakt, der sikrer mønter, så det tager flere bekræftede transaktioner og en tidsforsinkelse at virkelig bruge dem. Dette giver potentielle ofre muligheden for at tilbageføre et heist, før det er for sent.

I 2020 blev der frigivet to typer prototyper til hvælving.

Den første hvælvingsprototype blev annonceret af Bitcoin Core-bidragyder Bryan Bishop i April. Kort fortalt er Bishop’s design baseret på en forunderskrevet (og endnu ikke udsendt) transaktion, der bruger (nogle af) mønterne fra hvælvingen til en brugers almindelige (“hot”) tegnebog med en tidslåseforsinkelse, mens en alternativ udgiftsmulighed uden tidslås kan omdirigere mønterne til en alternativ adresse; måske et nyt og endnu mere sikkert hvælving. Det er vigtigt, at den private nøgle, der bruges til at underskrive de præ-signerede transaktioner, slettes, når hvælven oprettes, så en angriber kun nogensinde kunne stjæle selve den præ-signerede transaktion.

Opsætningen gør det yderst vanskeligt for en angriber at kræve mønterne. Selv hvis den forunderskrevne transaktion stjæles, kan tyven blot bruge mønterne til den varme tegnebog, og hvis offeret ikke stoler på sikkerheden i sin varme tegnebog, kan han bruge den indbagte tidsforsinkelse til at flytte mønterne til den ekstra sikre adresse i stedet. (For at forhindre tyven i at stjæle mønterne ved blot at gå på kompromis med den varme tegnebog og vente tålmodigt, indtil hvælvningsbrugeren sender sine mønter derhen, lader Bishop’s design kun brugere trække sig ud af hvælvingen i små bidder på det tidspunkt.)

Lidt senere April, Bitcoin-udvikleren Antoine Poinsot annoncerede en alternativ Vault-demo, som han designede med Chainsmiths CEO Kevin Loaec, kaldet Revault. Revault ligner Bishop’s Vaults på nogle måder, ligesom brugen af ​​præ-signerede transaktioner, men er specielt designet til multi-user opsætninger ved hjælp af en multisig-adresse. Revault lader et forudbestemt undersæt af en gruppe brugere bruge mønter fra hvælvingen til en varm tegnebog, også med en tidsforsinkelse. Enhver hvælvedeltager kan bruge denne tidsforsinkelse til at returnere midlerne til hvælvingen, hvis de er uenige med udgifterne, eller de kan omdirigere midlerne til en alternativ ekstra sikker adresse, hvis de overhovedet ikke stoler på, hvad der foregår.

Derudover kræver Revault, at når brugeren trækker sig ud af hvælvingen, når tidslåsen starter, opretter brugerne straks en transaktion fra den hot wallet, hvilket også kræver, at en server co-signerer. Serveren er programmeret til at underskrive en hvilken som helst transaktion, men aldrig en modstridende transaktion, så hvis en angriber kompromitterede (både hvælvingen og) den varme tegnebog, skulle de prøve at kræve mønterne før nogen anden, og inden tidslåsen udløber. Dette skulle gøre det indlysende, hvis den varme tegnebog er kompromitteret, alarmerer gruppen af ​​Revault-brugere og giver dem mulighed for at omdirigere midlerne inden tidslåsens udløb.

Taproot er nu godt at gå, da aktivering overvejes

Taproot er indstillet til at være den første Bitcoin-protokolopgradering, siden Segregated Witness blev aktiveret i august 2017. Først foreslog af Bitcoin Core-bidragsyder Gregory Maxwell i januar 2018, giver Taproot brugerne mulighed for at “skjule” smarte kontrakter i Bitcoin-transaktioner med regelmæssig udseende: En kompleks multisig-konstruktion kan ikke skelnes fra en simpel betaling.

Taproot-opgraderingen vil også omfatte Schnorr Signature-algoritmen. Mange kryptografer betragter Schnorr-signaturskemaet som det bedste i marken, da dets matematiske egenskaber tilbyder et stærkt niveau af korrekthed, det lider ikke under formbarhed og er relativt hurtigt at kontrollere. Schnorrs “lineære matematik” ville også give mulighed for en række nye muligheder, som mere kompakte typer multisig-løsninger, smarte smarte kontraktopsætninger og selvfølgelig Taproot selv.

Efter fortsat udvikling i hele 2020 blev Taproot’s kode flettet ind i Bitcoin Core-kodebasen i oktober og vil være en del af Bitcoin Core 0.21.0, som forventes frigivet enhver dag nu, med frigivelseskandidater, der i øjeblikket er tilgængelige. Bitcoin Core 0.21.0 inkluderer dog ikke aktiveringslogik for Taproot. Dette vil sandsynligvis blive inkluderet i en kommende mindre Bitcoin Core-udgivelse (sandsynligvis Bitcoin Core 0.21.1).

Aktiveringslogikken har i sig selv været et diskussionsemne gennem store dele af 2020 med en række potentialer aktiveringsmekanismer under overvejelse. De fleste af disse vil i første omgang udnytte hashkraftkoordinering for til sidst at nå en deadline, hvor opgraderingen aktiveres, selv uden hashkraftsupport. Men som en oktober meningsmåling offentliggjort af Bitcoin Core-bidragyder AJ Towns gjorde det klart, ikke alle Bitcoin Core-bidragsydere er enige om, at deadline skal være forprogrammeret, eller hvor langt deadline skal være (samt nogle andre mindre uenigheder).

Men uanset hvilken aktiveringsmekanisme der i sidste ende vælges, synes det mere og mere sandsynligt, at Taproot kan aktiveres jævnt gennem hashkraftkoordinering. I november lancerede store minepool Poolin et initiativ, der tilskyndede andre minepuljer til at udtale sig om Taproot og Taproot-aktivering. Det respons hidtil er meget gunstig for Taproot, med over 90 procent af den samlede hashkraft i støtte, og ingen minepuljer modsætter sig den foreslåede opgradering.

For en endnu mere omfattende og detaljeret oversigt over Bitcoins 2020 teknologiske udvikling, se også Bitcoin Optech 2020 Year-in-Review Special.