Tilsynelatende uforstyrret av 2020-galskapen, og stort sett uberørt av bitcoins ville prissvingninger som ble avsluttet med nye heltidspunkter i desember, fortsetter Bitcoins tekniske samfunn å pløye fremover. Bitcoins programvare og de mange prosjektene rundt den ble gradvis forbedret gjennom året, ettersom programvaren ble optimalisert, feil løst og personvernlekkasjer lappet. Hovedtyngden av dette arbeidet, så viktig som mye av det, tiltrekker seg ikke overskrifter.
Likevel hjelper et fugleperspektiv på Bitcoins teknologiske utvikling i løpet av et år å markere nye milepæler i Bitcoins pågående teknologiske marsj fremover. Også i 2020 introduserte det stadig voksende utviklingssamfunnet for Bitcoin en rekke nyttige nye funksjoner, flere spesielt viktige oppgraderinger og noen spesielt bemerkelsesverdige forbedringer.
Ettersom dette ustabile året nærmer seg slutten, var dette noen av Bitcoins mest bemerkelsesverdige tekniske utvikling de siste 12 månedene …
Nye personvernverktøy med PayJoin og CoinSwap
På Bitcoins personvernfront representerte PayJoin og CoinSwap-prosjektene i år to lovende fremskritt.
PayJoin, også kjent som Pay to Endpoint (P2EP), er et triks som lar mottakere av en transaksjon delta i transaksjonen gjennom en CoinJoin, for i utgangspunktet å sende penger til seg selv mens de også mottar den faktiske betalingen fra den virkelige avsenderen. Hvis en snoop, som gjennomførte blockchain-analyse, skulle anta at alle mynter som ble sendt i en transaksjon tilhørte samme person – som de normalt ville – de hadde tatt feil. Dette kommer allerede personvernet til både avsender og mottaker til gode, da snoopet vil forvirre (tidligere) mynteierskap mellom dem. Videre, hvis nok folk bruker PayJoin, kan det gjøre denne viktige heuristikken for blockchain-analyse ubrukelig helt, i sin tur til fordel for selv personvernet til de som ikke foretok PayJoin-transaksjoner selv.
Selv om demoversjoner av PayJoin-verktøyet allerede hadde blitt implementert for online-spill Bustabit og myntblandingsprogramvaren JoinMarket i slutten av 2018, og Samourai Wallet i 2019 utgitt sin egen – mer begrensede – versjon under Cohoots-paraplyen (med litt forskjellige personvernkompromisser), ble PayJoin i år implementert i flere populære Bitcoin-prosjekter. Dette inkluderte særlig den mye brukte programvaren for betalingsbehandling BTCPay i april, slik at BTCPay-brukere kan akseptere PayJoin-transaksjoner fra kompatible lommebøker. Den personvernfokuserte Wasabi Wallet var den første lommeboken som tilbyr denne kompatibiliteten senere samme måned, mens JoinMarket (september), Blå lommebok (oktober) og Sparrow Wallet (november) fulgte senere på året.
I mellomtiden satte Bitcoin-utvikler Chris Belcher seg for å realisere en implementering av CoinSwap, en personvernsteknikk først foreslått i 2013 av Bitcoin Core-bidragsyter Gregory Maxwell. CoinSwap utnytter Atomic Swaps (trikset som også ligger til grunn for Lightning Network) for å la brukere bytte mynter uten å måtte stole på hverandre. Hver bruker vil ende opp med mynter som ikke kan knyttes til sin egen transaksjonshistorikk.
Belcher, en av verdens fremste eksperter på Bitcoin-personvern, i Kan publiserte en detaljert oversikt over hvordan CoinSwap-protokollen kunne implementeres for å sikre maksimal personvern. Forslaget vil gjøre CoinSwap-transaksjoner ikke å skille fra andre transaksjoner, bruke splittingsteknikker for å skjule beløp, rutebetalinger for å frustrere snooping-deltakere og mer. Noen måneder senere, i juni, kunngjorde Human Rights Foundation at det første Bitcoin-utviklingsstipendet ville gå til Belcher og hans innsats for å realisere prosjektet.
Etter å ha jobbet med implementeringen hans det meste av året, Belcher i desember kunngjort en “stor dag for bitcoin-personvern og soppbarhet”: han hadde gjort den første vellykkede CoinSwap-transaksjonen på Bitcoins testnettverk (testnet).
Lynnettverket ble mer robust med Vakttårnene (og mer)
The Lightning Network, Bitcoins Layer 2-protokoll for raskere, billigere og mer private betalinger, fortsatte å forbedre seg over hele linja i 2020. Med Lightning-implementeringer LND, Eclair, C-Lightning og – siden juli – Electrum lanserte en rekke nye programvareutgivelser, og et økende antall prosjekter som bygger på protokollen, var Lightning-utviklingen mer aktiv enn noensinne. Blant de mer bemerkelsesverdige utviklingene løste Vakttårnene en av Lightning-nettets gjenværende svakheter, noe som resulterte i en mer robust protokoll.
En av Lightning Network’s kompromisser er at brukerne må holde øye med betalingskanalene sine for å sikre at betalingskanalpartnere ikke prøver å jukse ved å kringkaste gamle kanalstater for å kreve mer penger enn tilskrevet dem. Lynbrukere kan gå inn hvis en kanalpartner prøver å jukse, men dette krever overvåking av Bitcoin blockchain, noe tilfeldige brukere kanskje ikke gjør veldig regelmessig.
For å redusere risikoen for at et forsøk på juks blir savnet, tillater Lightning-protokollen kanalovervåking å bli outsourcet til upartiske observatører kalt Vakttårnene. Legger til den første Watchtower-programvaren introdusert av LND innen slutten av 2019, februar i år så alfa utgivelsen av den dedikerte Watchtower implementeringen Eye of Satoshi. Kort tid etter ble den foreslåtte Spesifikasjoner for Watchtower-protokollen ble oppdatert, mens C-Lightning rullet ut støtte for Eye of Satoshi i Kan. Versjon 1 av Eye of Satoshi fulgte inn juli.
Andre bemerkelsesverdige lynutviklinger i 2020 inkluderer det fortsatte arbeidet med ankerutganger for å sikre at brukere kan kreve penger fra en kanal ensidig, selv når gebyrene på kjeden har økt mer enn forventet siden forrige oppdatering av betalingskanalen, Flerveisbetalinger som lar brukerne foreta lynbetalinger i mindre biter, Lightning Network-native messaging-applikasjonen Juggernaut, kanaladministrasjonsverktøy Faraday, Lightning Loop beta-utgivelsen, men også noen nylig oppdagede svakheter i tillegg til (foreslåtte) løsninger, og mye mer.
Etter Miniscript ble Bitcoin-programmering enklere med Minsc
Koden innebygd i Bitcoin-transaksjoner som spesifiserer hvilke vilkår som må oppfylles for å bruke myntene i en neste transaksjon, er skrevet på et programmeringsspråk som er spesielt designet for Bitcoin, kalt Script. Manus kan imidlertid være vanskelig å jobbe med: i programmeringssjargong er det vanskelig å “resonnere om”. Dette betyr at, spesielt ettersom det blir litt mer komplekst, kan det være vanskelig å forstå hva et skript egentlig tillater: en transaksjon kan utilsiktet inneholde kode som gjør at myntene kan brukes under andre forhold enn opprinnelig ment. Dette er en grunn til at mange Bitcoin-programvare, som lommebøker, avstår fra å utnytte Skripts fulle potensiale.
I løpet av de siste årene har (tidligere) Blockstream-forskere Andrew Poelstra, Pieter Wuille og Sanket Kanjalkar designet en “strippet ned” versjon av Script, kalt Miniscript. Miniscript er et utvalg av “verktøy” fra “Script toolkit” som er nøye valgt for å muliggjøre praktisk talt alt som kan gjøres med Script, men det er enklere å bruke og lettere å bekrefte av programmerere. Så selv om en linje med Miniscript fremdeles er en gyldig linje av skriptet, unngår den i hovedsak menneskelige feil ved å forhindre uventede, kanskje utilsiktede resultater av koden; Miniscript er lettere å resonnere om. I november i år, sjef for forskning og utvikling ved Rugged Bytes Dmitry Petukhov publiserte en formell spesifikasjon av Miniscript.
For å gjøre opprettelsen av Bitcoin-transaksjoner enda enklere hadde Wuille også designet et “policy-språk” for Miniscript, et eget programmeringsspråk som kunne kompilere (konvertere) til Miniscript, og dermed Script. Basert på Wuilles arbeid utviklet Bitcoin-utvikler Nadav Ivgi i år et nytt programmeringsspråk kalt Minsc. Først kunngjort i juli, og fulgt opp med en større oppgradering i november, Minsc er fortsatt et pågående arbeid, men er satt til å forenkle opprettelsen av Bitcoin-transaksjoner. Dette kan bidra til å låse opp en rekke lovende funksjoner som utnytter Bitcoins allsidighet fullt ut, som interoperable CoinJoin-lommebøker, smarte kontraktløsninger, Layer 2-protokoller og mer.
Smarte kontrakter ble smartere med DLC
Når smarte kontrakter er avhengige av eksterne data – data som ikke lever i blockchain – stoler de på en ekstern kilde for de dataene som kalles et “orakel”. Hvis to brukere for eksempel vil satse på utfallet av en sportskamp, må oraklet bruke resultatet av kampen for å avgjøre innsatsen til fordel for den som har spådd riktig (i hvert fall i tilfelle en tvist).
Et veldig grunnleggende sportsspilloppsett kan bestå av en to-av-tre multisignatur-adresse (multisig) -adresse hvor både spillere og oraklet har én tast hver, og oraklet blir informert om detaljene i innsatsen. Etter kampen kunne de to spillerne samarbeide om å sende midlene fra multisig til vinneren uten nøkkelen til oraklet. Men hvis taperen nekter å samarbeide, kan oraklet bruke sin tredje nøkkel til å samarbeide med vinneren for å sende dem midlene fra multisig. Dette systemet fungerer, men har to ulemper. En, begge spillerne må stole på at oraklet ikke samarbeider med motstanderen. Og to, oraklet må informeres om innsatsen og kanskje spille en aktiv rolle i oppgjørsprosessen: dette betyr at spillerne ikke har noe privatliv fra oraklet, mens oppsettet ikke skalerer veldig bra hvis flere enn noen få spillere vil vedde.
En bedre løsning var i 2017 foreslått av MIT Media Labs Digital Currency Initiative-forsker Thaddeus Dryja: diskrete loggkontrakter (DLC). DLC-er bruker et smart matematisk triks der oraklet publiserer en kryptografisk signatur som samsvarer med utfallet av en hendelse. I eksemplet ovenfor vil oraklet publisere en signatur hvis det første laget vinner, og en annen signatur hvis det andre laget vinner. Trikset: den smarte kontrakten er designet for å la den vinnende spilleren bruke den publiserte signaturen til å kreve pengene.
I en DLC blir orakelets engasjement med smartkontrakten minimert til publisering av en signatur; Dette kan for eksempel i sportsbettingeksemplet gjøres av en eksisterende nyhetstjeneste, som en del av den vanlige sendingen. Dette betyr også at oraklet ikke trenger å bli informert om detaljene i spillet, og faktisk ikke engang trenger å vite at det var et spill i det hele tatt. I mellomtiden kan et hvilket som helst antall mennesker bruke signaturene til å avgjøre sine spill uten ytterligere involvering fra oraklet, noe som i stor grad drar fordel av skalerbarhet. Og mens orakel i teorien fremdeles kunne samarbeide med noen og kringkaste feil resultat, ville en slik uredelig oppførsel være åpenbar for alle og sverte orakelets rykte fremover.
I januar i år kunngjorde konsernsjef Chris Stewart at hans selskap Suredbits, i samarbeid med Crypto Garage, hadde startet arbeidet med en spesifikasjon for DLC. I februar, Suredbits-ingeniør Nadav Kohen fulgte opp med den første arbeidskoden. Og av september, Suredbits og Crypto Garage hadde utviklet programvaren sin til det punktet den kunne brukes: Stewart og Bitcoin-utvikleren Nicolas Dorier engasjerte seg i Bitcoins første DLC for å satse på utfallet av det amerikanske presidentvalget. Stewart, som hadde satset på Biden, hevdet sine gevinster i desember.
Holding blir tryggere med Bitcoin-hvelv
Den lange listen over byttehacks og andre bitcoin-heists er vitnesbyrd om at sikker lagring av private nøkler fortsatt er en utfordring, spesielt der mange mynter står på spill.
Men sikrere løsninger for lagring av mynter er under utvikling. Bitcoin hvelv – et konsept som dateres tilbake til 2016 – er en type smart kontrakt som sikrer mynter, slik at det tar flere bekreftede transaksjoner og en tidsforsinkelse å virkelig bruke dem. Dette gir potensielle ofre muligheten til å tilbakeføre et heist før det er for sent.
I 2020 ble det gitt ut to typer prototyper for hvelv.
Den første hvelvprototypen ble kunngjort av Bitcoin Core-bidragsyter Bryan Bishop i april. Kort fortalt er Bishops design basert på en forhåndssignert (og ennå ikke kringkastet) transaksjon som bruker (noen av) myntene fra hvelvet til en brukers vanlige (“hot”) lommebok med en tidslåseforsinkelse, mens et alternativt forbruksalternativ uten tidlås kan omdirigere myntene til en alternativ adresse; kanskje et nytt og enda sikrere hvelv. Det er viktig at den private nøkkelen som brukes til å signere de pre-signerte transaksjonene, blir slettet når hvelvet er opprettet, så en angriper kan bare stjele den pre-signerte transaksjonen.
Oppsettet gjør det ekstremt vanskelig for en angriper å kreve myntene. Selv om den pre-signerte transaksjonen blir stjålet, kan tyven bare bruke myntene til den varme lommeboken, og hvis offeret ikke stoler på sikkerheten til den varme lommeboken, kan han bruke den innbakte tidsforsinkelsen til å flytte myntene til den ekstra sikre adressen i stedet. (For å forhindre at tyven stjeler myntene ved ganske enkelt å kompromittere den varme lommeboken og vente tålmodig til hvelvbrukeren sender myntene sine dit, lar Bishop’s design bare brukere trekke seg ut av hvelvet i små biter på den tiden.)
Litt senere april, Bitcoin-utvikler Antoine Poinsot kunngjorde en alternativ Vault-demo som han designet med Chainsmiths CEO Kevin Loaec, kalt Revault. Revault ligner på noen måter Bishop’s Vaults, som bruken av forhåndssignerte transaksjoner, men er spesielt designet for flerbrukeroppsett, ved hjelp av en multisig-adresse. Revault lar et forhåndsbestemt delsett av en gruppe brukere bruke mynter fra hvelvet til en varm lommebok, også med en tidsforsinkelse. Enhver hvelvdeltaker kan bruke denne tidsforsinkelsen til å returnere midlene til hvelvet hvis de er uenige med utgiftene, eller de kan omdirigere midlene til en alternativ, ekstra sikker adresse hvis de ikke stoler på det som skjer i det hele tatt.
I tillegg krever Revault at når brukeren trekker seg fra hvelvet, når tidslåsen sparker inn, oppretter brukerne umiddelbart en transaksjon fra den varme lommeboken, noe som også krever at en server signerer samtidig. Serveren er programmert til å signere enhver transaksjon, men aldri en motstridende transaksjon, så hvis en angriper kompromitterte (både hvelvet og) den varme lommeboken, måtte de prøve å kreve myntene før noen andre og før tidslåsen utløper. Dette burde gjøre det åpenbart hvis den varme lommeboken er kompromittert, og alarmer gruppen Revault-brukere, og lar dem omdirigere midlene før tidslås utløper.
Taproot er nå bra å gå, ettersom aktivering er under vurdering
Taproot er satt til å være den første Bitcoin-protokolloppgraderingen siden Segregated Witness ble aktivert i august 2017. Først foreslått av Bitcoin Core-bidragsyter Gregory Maxwell i januar 2018, lar Taproot brukere “skjule” smarte kontrakter i Bitcoin-transaksjoner med vanlig utseende: En kompleks multisig-konstruksjon kan ikke skilles fra en enkel betaling.
Taproot-oppgraderingen vil også inkludere Schnorr Signature-algoritmen. Mange kryptografer anser Schnorr-signaturskjemaet for å være det beste i feltet, da dets matematiske egenskaper gir et sterkt nivå av korrekthet, det lider ikke av formbarhet og er relativt raskt å verifisere. Schnorrs “lineære matematikk” vil også tillate en rekke nye muligheter, som mer kompakte typer multisig-løsninger, smarte smarte kontraktsoppsett og selvfølgelig Taproot selv.
Etter fortsatt utvikling gjennom 2020 ble Taproot-koden slått sammen i Bitcoin Core-kodebasen i oktober, og vil være en del av Bitcoin Core 0.21.0, som er satt til å bli utgitt en hvilken som helst dag nå, med utgivelseskandidater som for øyeblikket er tilgjengelige. Bitcoin Core 0.21.0 inkluderer imidlertid ikke aktiveringslogikk for Taproot. Dette vil trolig bli inkludert i en kommende mindre Bitcoin Core-utgivelse (sannsynligvis Bitcoin Core 0.21.1).
Aktiveringslogikken har i seg selv vært et diskusjonsemne gjennom store deler av 2020, men med en rekke potensialer aktiveringsmekanismer under vurdering. De fleste av disse ville i utgangspunktet utnytte hashkraftkoordinering, for til slutt å nå en frist der oppgraderingen aktiveres selv uten hashkraftstøtte. Men som en oktober meningsmåling publisert av Bitcoin Core-bidragsyter AJ Towns gjorde det klart, ikke alle Bitcoin Core-bidragsytere er enige om at fristen skal være forhåndsprogrammert, eller hvor langt ut fristen skal være (samt noen andre mindre uenigheter).
Men uavhengig av hvilken aktiveringsmekanisme som til slutt blir valgt, virker det stadig mer sannsynlig at Taproot kan aktiveres jevnt gjennom hashkraftkoordinering. I november lanserte det store gruvebassenget Poolin et initiativ som oppmuntret andre gruvebassenger til å uttale seg om Taproot og Taproot-aktivering. De respons så langt er det veldig gunstig for Taproot, med over 90 prosent av total hashkraft i støtte, og ingen gruvebassenger motarbeider den foreslåtte oppgraderingen.
For en enda mer omfattende og detaljert oppsummering av Bitcoins teknologiske utvikling i 2020, se også Bitcoin Optech 2020 Year-in-Review Special.