I dag markeres den offisielle utgivelsen av Bitcoin Core 0.21.0, den 21. største utgivelsen av Bitcoins opprinnelige programvareklient lansert av Satoshi Nakamoto for rundt 12 år siden. 

Overvåket av Bitcoin Core hovedansvarlig Wladimir van der Laan, ble denne siste store utgivelsen utviklet av godt hundre bidragsytere i løpet av omtrent seks måneder. Resultatet av over 600 sammenslåtte pull-forespørsler, Bitcoin Core 0.21.0, er en av de største Bitcoin Core-utgivelsene de siste årene, og introduserer forskjellige nye funksjoner, samt forbedringer av personvern og ytelse, mens du tar et stort skritt mot Schnorr / Taproot-protokolloppgraderingen..

Nedenfor er noen av de mer bemerkelsesverdige endringene.

Descriptor lommebøker

Når mynter sendes til en Bitcoin-adresse, er det som faktisk skjer under panseret at de er “låst” i en ubrukt transaksjonsoutput (UTXO), for bare å “låses opp” (brukt) i en senere transaksjon hvis forholdene er skjult i UTXO er oppfylt. En typisk tilstand er inkludering av en gyldig signatur som tilsvarer en bestemt offentlig nøkkel. Men forhold kan for eksempel også bestå av inkludering av en hemmelig kode, bortfall av tidssperre eller en kombinasjon av signaturer (multisig).

Inntil nå var Bitcoin Core designet for å administrere UTXO-ene i lommeboken rundt de tilsvarende private nøklene – selv om private nøkler bare er en av flere potensielle betingelser for å bruke mynter. Bitcoin Core 0.21.0 introduserer i stedet “deskriptor wallets.” Descriptor-lommebøker lar brukerne kategorisere sine UTXO-er basert på hvilke forhold som kreves for å bruke dem. (For eksempel: en lommebok for UTXO-er som bare krever en gyldig signatur, og en lommebok for multisig UTXO-er.)

Descriptor lommebøker er spesielt nyttige for applikasjonsutviklere som designer programvare på toppen av Bitcoin Core. En bestemt applikasjon kan nå enkelt utformes for å bruke bare en bestemt type UTXO, som multisig UTXOs, og ignorere alle ikke-multisig UTXOer.

Vanlige brukere kan også merke en forskjell nå som deskriptor lommebøker er implementert. Kanskje mest spesielt, vil det ikke opprettes noen standard lommebok når en ny Bitcoin Core-node startes opp. I stedet opprettes en ny lommebok bare når en bruker spesifikt velger å gjøre det, slik at de bare kan lage den spesifikt ønskede lommeboktypen. Descriptor-lommebøker støtter også Watch Only-lommebøker bedre: lommebøker som holder styr på visse UTXO-er, selv om noden ikke har de private nøklene som trengs for å bruke dem.

Bitcoin Core-brukere som oppgraderer til Bitcoin Core 0.21.0, vil fortsatt kunne bruke sin eldre lommebok for nå. (Legacy lommebøker vil etter hvert bli utfaset, noe som betyr at brukerne må migrere sin eldre lommebok til en deskriptor lommebok, men dette vil ikke være strengt nødvendig før en fremtidig Bitcoin Core-utgivelse.)

Serverer kompakte blokkfiltre over Peer-to-Peer-nettverket

“Lette klienter” er Bitcoin-lommebøker og applikasjoner som ikke laster ned og validerer hele Bitcoin-blockchain, men i stedet bare laster ned og validerer deler av blokker og transaksjoner som gjelder dem spesifikt. Dette er ikke optimalt sikkert, men er mye mindre ressurskrevende.

En populær måte å gjøre dette på er med Bloom Filters. Kort sagt, Bloom Filters er et kryptografisk triks for å be om relevante data fra mer eller mindre tilfeldige peer-noder på nettverket. Dessverre har det imidlertid blitt klart opp gjennom årene at Bloom Filters er ganske uvennlige for personvern: de avslører i hovedsak alle brukerens adresser til (mer eller mindre tilfeldig) peer-node, som selvfølgelig kan drives av en personverninvaderende snoke.

Et nyere og mye mer personvernbevarende alternativ til Bloom Filter-løsningen kalles “kompakt blokkeringsfiltrering på klientsiden” (BIP 157/158). Kompakt blokkeringsfiltrering på klientsiden vender i hovedsak Bloom Filter-trikset på hodet. I stedet for at lommebøker lager filtre for å sende til fulle noder, lager fulle noder filtre for hver blokk og sender disse til lette klienter på forespørsel. Lette klienter bruker deretter disse filtrene for å finne ut om transaksjoner som er relevante for dem, kan ha blitt inkludert i en blokk. I så fall vil den lette lommeboken hente hele blokken og velge relevant transaksjonsdata ut av den. (Det vil være noen falske positive; blokker som ikke har relevante transaksjonsdata i seg selv om filteret antydet at de kan.)

Eksisterende Bitcoin Core-utgivelser kan allerede opprette filtrene lokalt og gjøre dem tilgjengelige gjennom en RPC (Remote Procedure Call) for applikasjoner som kjører på toppen av noden (som lommebøker). Bitcoin Core 0.21.0 inkluderer nå også muligheten til å gjøre disse filtrene tilgjengelige over Bitcoins peer-to-peer-nettverk på forespørsel. Dette gjør det mulig å nå operere frittstående lysklienter som bruker blomstringsfiltre.

Færre forsøk på å sende på nytt

Foruten Bloom Filters, kan snoops også bryte privatlivet til Bitcoin-brukere gjennom nettverksanalyse. Hvis de kan finne ut fra hvilken node en bestemt transaksjon stammer, kan den nodenes Bitcoin-adresse (r) knyttes til IP-adressen, som igjen kan knyttes til en identitet i den virkelige verden.

Inntil nå, da Bitcoin Core-noder sendte en transaksjon til Bitcoin-nettverket, ville de prøve å kringkaste transaksjonen hvert femte minutt, til transaksjonen ble inkludert i en blokk. Dette betydde at hvis disse Bitcoin Core-nodene var koblet til en snooping-peer, ville det være åpenbart for snoopet at Bitcoin Core-noden som prøvde å kringkaste en bestemt transaksjon hvert 15. minutt, også var noden der den transaksjonen stammer..

Bitcoin Core 0.21.0 reduserer frekvensen med å prøve å kringkaste transaksjoner sterkt: bare en gang hver 12. til 36. time. Å måtte kringkaste sjeldnere, gjør det mye mer sannsynlig at transaksjonen er bekreftet siden den første sendingen, så det er mindre sannsynlig at noden i det hele tatt trenger å kringkaste.

I fremtidige Bitcoin Core-utgivelser vil denne personvernlekkasjen bli løst helt. En Bitcoin Core-node vil da bare kringkaste transaksjoner som burde vært bekreftet basert på egen mempool- og gebyrberegning. Videre vil den også kringkaste andre transaksjoner, ikke bare sine egne.

Tor V3-støtte

På grunn av en nylig oppgradering av den personvernbevarende Tor-protokollen, er nye V3 (versjon 3) Tor-adresser lengre enn V2 (versjon 2) -adressene som kom før dem. V2-adresser er fortsatt i bruk, men avvikles om et år fra nå.

Utfasing av V2-adresser ville ha utgjort et problem for Bitcoin Core-brukere som ønsker å bruke Bitcoin over personvernettverket. Bitcoin Core-noder finner jevnaldrende ved å dele med hverandre Tor-adresser til kjente Tor-brukende Bitcoin-noder. De delte dette gjennom den samme meldingen de bruker til å dele andre nodes vanlige IP-adresser. Mens Tor V2-adresser kan være “skjult” i det vanlige IP-adresseformatet (IPV6), er Tor V3-adressene for lange til det; med andre ord, de nåværende meldingene er for begrenset til å være kompatible med Tor-oppgraderingen.

Bitcoin Core 0.21.0 introduserer derfor et nytt format for å dele IP / Tor-adresser med jevnaldrende. Disse meldingene kan være store nok til å dele Tor V3-adressene.

Schnorr / Taproot-kode og Signet / Regtest-distribusjon

Schnorr / Taproot er klar til å være Bitcoins første protokolloppgradering siden Segregated Witness (SegWit) i august 2017. Etter å ha vært i utvikling i godt over to år, regnes Schnorrs signaturalgoritme som en allsidig forbedring i forhold til Bitcoins nåværende ECDSA-signaturalgoritme. I kombinasjon med Taproot – et smart triks for å skjule ulike forhold for å bruke mynter i et kryptografisk hash-tre – løfter oppgraderingen å tilby mer smart kontraktsfleksibilitet på en skalerbar og personvernbevarende måte.

Schnorr / Taproot-koden er nå inkludert i Bitcoin Core 0.21.0. Hvis du sperrer uventet utvikling, betyr det at det ikke vil bli endret mer, noe som for eksempel betyr at applikasjonsutviklere kan begynne å designe programvare rundt oppgraderingen. I tillegg er Schnorr / Taproot nå tilgjengelig på Signet (en nyere og mer pålitelig variant av testnet, brukt av utviklere for å teste ny Bitcoin-programvare) og potensielt også på Regtests (ekstra lokale testnet-varianter).

Schnorr / Taproot vil imidlertid ikke være tilgjengelig på Bitcoins mainnet ennå. For dette må oppgraderingen først aktiveres, noe som krever aktiveringslogikk som ennå ikke er inkludert i denne Bitcoin Core-utgivelsen. Aktiviseringslogikk forventes å bli inkludert i en mindre Bitcoin Core-utgivelse, muligens et sted de neste månedene.

Annen…

I tillegg til endringene ovenfor inkluderer Bitcoin Core 0.21.0 forskjellige feilrettinger og ytelsesforbedringer som ikke vil være like tydelige for vanlige brukere. Bitcoin Core-lommeboken vil for eksempel bytte fra å bruke Berkeley DB til SQLite-databasen, som er bedre egnet som en applikasjonsdatafil og gir flere garantier med hensyn til kompatibilitet, støtte og testing. Av interesse er også at Bitcoin Core 0.21.0 inkluderer en revisjon av transaksjonsforespørsler: den nye meldingsprotokollen som Bitcoin-noder bruker for å lære om nye transaksjoner er bedre testet, bedre spesifisert og lettere å vedlikeholde og gjennomgå.

For en mer omfattende liste over oppgraderinger, se også Utgivelsesmerknader for Bitcoin Core 0.21.0, eller se dette blogginnlegget av Bitcoin Core bidragsyter Andrew Chow for en mer omfattende forklaring på deskriptor lommebøker (så vel som eldre lommebøker) og SQLite (samt Berkeley DB).

Takk til John Newbery for informasjon og tilbakemelding.