Idag markeras den officiella utgåvan av Bitcoin Core 0.21.0, den 21: a stora utgåvan av Bitcoins ursprungliga programvaruklient som lanserades av Satoshi Nakamoto för cirka 12 år sedan. 

Övervakad av Bitcoin Core ledande underhållare Wladimir van der Laan, den senaste stora utgåvan utvecklades av drygt hundra bidragsgivare på cirka sex månader. Resultatet av över 600 sammanslagna pull-förfrågningar, Bitcoin Core 0.21.0 är en av de största Bitcoin Core-utgåvorna de senaste åren, med olika nya funktioner samt integritets- och prestandaförbättringar, samtidigt som man tar ett stort steg mot Schnorr / Taproot-protokolluppgraderingen..

Nedan följer några av de mer anmärkningsvärda ändringarna.

Descriptor plånböcker

När mynt skickas till en Bitcoin-adress, vad som faktiskt händer under huven är att de är “låsta” i en outnyttjad transaktionsutmatning (UTXO), för att endast “upplåsas” (spenderas) i en senare transaktion om villkoren är dolda i UTXO uppfylls. Ett typiskt villkor är införandet av en giltig signatur som motsvarar en specifik offentlig nyckel. Men förhållanden kan till exempel också bestå av införandet av en hemlig kod, bortfallet av en tidlås eller en kombination av signaturer (multisig).

Hittills har Bitcoin Core utformats för att hantera UTXO: erna i sin plånbok runt motsvarande privata nycklar – även om privata nycklar bara är en av flera potentiella villkor för att spendera mynt. Bitcoin Core 0.21.0 introducerar istället “descriptor plånböcker.” Descriptor-plånböcker låter användare kategorisera sina UTXO: er baserat på de typer av villkor som krävs för att spendera dem. (Till exempel: en plånbok för UTXOs som bara kräver en giltig signatur och en plånbok för multisig UTXO.)

Descriptor-plånböcker är särskilt användbara för applikationsutvecklare som designar programvara ovanpå Bitcoin Core. En viss applikation kan nu enkelt utformas för att endast använda en specifik typ av UTXO, som multisig UTXOs, och ignorera alla icke-multisig UTXOs.

Vanliga användare kan också märka en skillnad nu när deskriptorplånböcker implementeras. Kanske framför allt kommer ingen standardplånbok att skapas när en ny Bitcoin Core-nod startas. Istället skapas en ny plånbok endast när en användare specifikt väljer att göra det, så att de bara kan skapa den specifikt önskade typen av plånbok. Descriptor-plånböcker stöder också bättre Watch Only-plånböcker: plånböcker som håller reda på vissa UTXOs även om noden inte har de privata nycklar som behövs för att spendera dem.

Bitcoin Core-användare som uppgraderar till Bitcoin Core 0.21.0 kan fortfarande använda sin äldre plånbok för tillfället. (Äldre plånböcker kommer så småningom att upphöra, vilket innebär att användare måste migrera sin äldre plånbok till en deskriptorplånbok, men detta är inte absolut nödvändigt förrän en framtida Bitcoin Core-utgåva.)

Serverar kompakta blockfilter över peer-to-peer-nätverket

”Ljusa klienter” är Bitcoin-plånböcker och applikationer som inte laddar ner och validerar hela Bitcoin-blockkedjan, utan istället bara laddar ner och validerar delar av block och transaktioner som berör dem specifikt. Detta är inte optimalt säkert men är mycket mindre resurskrävande.

Ett populärt sätt att göra detta är med Bloom Filters. Kort sagt, Bloom Filters är ett kryptografiskt trick för att begära relevant data från mer eller mindre slumpmässiga peer-noder i nätverket. Tyvärr har det dock blivit tydligt genom åren att Bloom Filters är ganska integritetsvänliga: de avslöjar i huvudsak alla användarens adresser till (mer eller mindre slumpmässig) peer-nod, som naturligtvis kan drivas av en integritetsinvaderande snoka.

Ett nyare och mycket mer integritetsbevarande alternativ till Bloom Filter-lösningen kallas “kompakt blockfiltrering på klientsidan” (BIP 157/158). Kompakt blockfiltrering på klientsidan vänder i huvudsak trick på Bloom Filter. Istället för att lätta plånböcker skapar filter för att skicka till hela noder, skapar fulla noder filter för varje block och skickar dessa till ljusklienter på begäran. Lätta klienter använder sedan dessa filter för att ta reda på om transaktioner som är relevanta för dem kan ha inkluderats i ett block. I så fall kommer den lätta plånboken att hämta hela blocket och välja relevant transaktionsdata ur det. (Det kommer att finnas några falska positiva; block som inte har relevant transaktionsinformation i sig trots att filtret föreslog att de skulle kunna göra det.)

Befintliga Bitcoin Core-utgåvor kan redan skapa filtren lokalt och göra dem tillgängliga via ett fjärrproceduranrop (RPC) för applikationer som körs ovanpå noden (som plånböcker). Bitcoin Core 0.21.0 inkluderar nu också möjligheten att göra dessa filter tillgängliga över Bitcoins peer-to-peer-nätverk på begäran. Detta gör det möjligt att nu driva fristående ljusklienter som använder blomfilter.

Färre försök på nytt

Förutom Bloom Filters kan snoops också bryta Bitcoin-användarnas integritet genom nätverksanalys. Om de kan ta reda på från vilken nod en viss transaktion härstammar, kan den nodens Bitcoin-adress (er) knytas till dess IP-adress, som i sin tur kan associeras med en verklig identitet.

Fram till nu, när Bitcoin Core-noder sände en transaktion till Bitcoin-nätverket, skulle de försöka sända om transaktionen var femton minut tills transaktionen ingick i ett block. Detta innebar att om dessa Bitcoin Core-noder var anslutna till en snooping-peer, skulle det vara uppenbart för snoopet att Bitcoin Core-noden som försökte sända om en viss transaktion var 15: e minut också var noden där transaktionen härstammade.

Bitcoin Core 0.21.0 minskar kraftigt frekvensen med vilken den försöker sända om transaktioner: bara en gång var 12: e till 36: e timme. Att behöva sända mindre ofta gör det mycket mer troligt att transaktionen har bekräftats sedan den första sändningen, så det är mindre troligt att noden alls behöver sändas igen.

I framtida Bitcoin Core-utgåvor kommer denna integritetsläcka att åtgärdas helt. En Bitcoin Core-nod kommer då endast att sända om transaktioner som borde ha bekräftats baserat på dess egna mempool- och avgiftsberäkningar. Dessutom kommer den också att sända ut andra transaktioner, inte bara sina egna.

Tor V3-stöd

På grund av en nyligen uppgradering av det sekretessbevarande Tor-protokollet är nya V3 (version 3) Tor-adresser längre än de V2 (version 2) -adresserna som kom före dem. V2-adresser används fortfarande men kommer att upphöra om ungefär ett år från och med nu.

Avskrivning av V2-adresser skulle ha utgjort ett problem för Bitcoin Core-användare som vill använda Bitcoin över sekretessnätverket. Bitcoin Core-noder hittar kollegor genom att dela med varandra Tor-adresser till kända Tor-användande Bitcoin-noder. De delade detta genom samma meddelande som de använder för att dela andra nodes vanliga IP-adresser. Medan Tor V2-adresser kan “döljas” i det vanliga IP-adressformatet (IPV6), är Tor V3-adresserna för långa för det. med andra ord är de aktuella meddelandena för begränsade för att vara kompatibla med Tor-uppgraderingen.

Bitcoin Core 0.21.0 introducerar därför ett nytt format för att dela IP / Tor-adresser med kamrater. Dessa meddelanden kan vara tillräckligt stora för att dela Tor V3-adresserna.

Schnorr / Taproot-kod och Signet / Regtest-distribution

Schnorr / Taproot är redo att vara Bitcoins första protokolluppgradering sedan Segregated Witness (SegWit) i augusti 2017. Efter att ha varit under utveckling i över två år anses Schnorrs signaturalgoritm vara en allomfattande förbättring jämfört med Bitcoins nuvarande ECDSA-signaturalgoritm. I kombination med Taproot – ett smart trick för att dölja olika villkor för att spendera mynt i ett kryptografiskt hashträd – lovar uppgraderingen att erbjuda mer smart kontraktsflexibilitet på ett skalbart och sekretessbevarande sätt.

Schnorr / Taproot-koden ingår nu i Bitcoin Core 0.21.0. Uteslutande av oväntad utveckling innebär det att det inte kommer att ändras mer, vilket till exempel innebär att applikationsutvecklare kan börja designa programvara kring uppgraderingen. Dessutom är Schnorr / Taproot nu tillgänglig på Signet (en nyare och mer tillförlitlig variant av testnet, som används av utvecklare för att testa ny Bitcoin-programvara) och eventuellt även på Regtests (ytterligare lokala testnetvarianter).

Schnorr / Taproot kommer dock inte att finnas tillgängligt på Bitcoins mainnet ännu. För detta måste uppgraderingen först aktiveras, vilket kräver aktiveringslogik som ännu inte ingår i denna Bitcoin Core-utgåva. Aktiveringslogik förväntas ingå i en mindre Bitcoin Core-utgåva, möjligen någonstans under de kommande månaderna.

Övrig…

Utöver ändringarna ovan innehåller Bitcoin Core 0.21.0 olika buggfixar och prestandaförbättringar som inte kommer att vara lika uppenbara för vanliga användare. Bitcoin Core-plånboken byter till exempel från att använda Berkeley DB till SQLite-databasen, vilket är bättre lämpad som en applikationsdatafil och erbjuder flera garantier när det gäller kompatibilitet, support och testning. Av intresse är också att Bitcoin Core 0.21.0 inkluderar en översyn av en transaktionsbegäran: det nya meddelandeprotokollet som Bitcoin-noder använder för att lära sig om nya transaktioner är bättre testat, bättre specificerat och lättare att underhålla och granska.

För en mer omfattande lista över uppgraderingar, se även Versionsnoteringar för Bitcoin Core 0.21.0, eller se detta blogginlägg av Bitcoin Core-bidragsgivare Andrew Chow för en mer omfattande förklaring av deskriptorplånböcker (liksom äldre plånböcker) och SQLite (liksom Berkeley DB).

Tack till John Newbery för information och feedback.