Bitcoin Core 0.13.0, den trettende generasjonen av Bitcoins referanseklient som først ble lansert av Satoshi Nakamoto for snart åtte år siden, er nå merket for utgivelse. Dette er et av de siste trinnene i programvareutgivelsesprosessen og starter Gitian-byggeprosessen.

Bitcoin Core 0.13.0 ble utviklet av rundt 100 bidragsytere over en periode på omtrent fem måneder. Og mens mye av utviklingsarbeidet over denne tiden også har vært fokusert på Segregated Witness, som bare vil bli aktivert i en fremtidig mindre utgivelse av programvaren, inkluderer Bitcoin Core 0.13.0 omtrent et dusin bemerkelsesverdige forbedringer sammenlignet med Bitcoin Core 0.12.0.

Dette er de viktigste endringene.

Barn betaler for foreldre

Antall transaksjoner i Bitcoin-nettverket har vokst jevnt over tid. Som et resultat har flere blokker fylt seg opp, og gruvearbeidere tar vanligvis høyere avgifter for å inkludere transaksjoner i blokker. Transaksjoner som ikke inkluderer tilstrekkelige gebyrer, tar vanligvis lengre tid å bekrefte, eller kanskje til og med aldri bekrefte i det hele tatt. Dette har vist seg å være noe problematisk, spesielt i perioder der såkalte “stresstester” ble utført på nettverket, med økninger i det totale antall transaksjoner på nettverket og betydelige forsinkelser i transaksjonen.

Individuelle brukere kan løse dette problemet ved å inkludere et høyere gebyr i transaksjonene sine, og stimulere gruvearbeidere til å prioritere disse transaksjonene. Dette er mulig selv etter at en transaksjon er sendt, ved hjelp av Opt-in Replace-by-Fee (RBF); imidlertid ikke mange lommebøker inkluderer dette alternativet ennå. I tillegg er RBF bare et alternativ for avsenderen av en transaksjon. Inntil nå hadde mottakeren ingen måte å støte på avgiften for en innkommende transaksjon for å øke bekreftelsen.

Dette problemet løses effektivt med et triks som heter “Child Pays for Parent” (CPFP). CPFP er en policy som brukes av gruvearbeidere for å velge hvilke transaksjoner som skal inkluderes i blokker. Med CPFP velger ikke gruvearbeidere nødvendigvis de mest betalte (og gyldige) transaksjonene, men velger de mest lønnsomme sett av transaksjoner. Med andre ord: de vil velge en lavavgiftstransaksjon hvis en påfølgende transaksjon det avhengig på lavavgift tilbyr transaksjonen et høyt nok gebyr for å kompensere. Gruvearbeideren vil inkludere begge samtidig.

I praksis betyr dette at mottakeren av en lavavgiftstransaksjon kan “feste” en høyavgiftstransaksjon og bruke de samme myntene til seg selv. Insentivisert av den nye, høye gebyrtransaksjonen, vil en gruvearbeider inkludere settet med transaksjoner. Som sådan trenger ikke mottakeren å vente så lenge på en bekreftelse, mens gruvearbeideren kan øke inntekten.

Kompakt blokkstøtte

Bitcoins peer-to-peer-protokoll er for tiden noe ineffektiv. Noder sender hverandre flest transaksjonsdata to ganger: en gang som en transaksjon slik den først sendes over nettverket, og en gang som en del av en blokk når transaksjonen er bekreftet.

Dette har noen ulemper. For det første krever sending av transaksjonsdata to ganger mer båndbredde enn den egentlig burde, noe som øker kostnadene ved å kjøre Bitcoin Core. For det andre, og kanskje enda viktigere, kan videresending av nye blokker til flere jevnaldrende samtidig føre til betydelige utgående båndbreddetopp. Dette forstyrrer potensielt bruken av internett hver gang en ny blokk blir funnet, noe som potensielt er irriterende for brukerne. Og kanskje, enda viktigere, det kan også redusere spredning av blokkering over nettverket. Langsom spredning av blokkering kan igjen favorisere større gruvebassenger og derved stimulere et mer sentralisert gruvelandskap.

Kompakte blokker (BIP 152), utviklet av Bitcoin Core og Blockstream utvikler Matt Corallo, er designet for å redusere overflødig dataoverføring. Når en ny blokk blir funnet, kommuniserer noder i utgangspunktet bare veldig kompakte hashes av transaksjonsdata. Siden noder allerede har mottatt fullstendige transaksjonsdata da de opprinnelig ble sendt over nettverket, kan de bruke disse hasjene for å finne ut hvilke transaksjoner som er inkludert i blokken og rekonstruere blokken selv.

Dette trikset fungerer ikke alltid perfekt. Hvis en node ennå ikke mottok den første transaksjonen før den mottok hashene, kan den noden selvfølgelig ikke velge transaksjonen. I tillegg, i sjeldne tilfeller a feil transaksjonen kan hasj inn i en Ikke sant hash, lure noden til å tro at den mottok riktig transaksjon til den prøver å rekonstruere blokken og finner at den ikke legger opp.

I begge disse tilfellene av feil, ber noden ganske enkelt bare om de spesifikke transaksjonsdataene. Selv med bare noen komplette transaksjoner i dem, vil Compact Blocks overføre mye raskere over nettverket og kreve betydelig mindre båndbredde.

Hierarkisk deterministisk nøkkelgenerering

Inntil nå genererte Bitcoin Core et nytt og helt tilfeldig offentlig og privat nøkkelpar for hver nye Bitcoin-adresse. Selv om dette er viktig av sikkerhets- og personvernhensyn, kan det også være litt av en byrde for brukerne. For å sikre alle private nøkler mot tap, må de ta regelmessige sikkerhetskopier.

Hierarkisk deterministisk (HD) nøkkelgenerering (BIP 32), et kryptografisk triks utviklet gjennom 2012 og 2013 av Bitcoin Core-utviklerne Gregory Maxwell og Dr. Pieter Wuille, og Armory-utvikler Alan Reiner, løser dette problemet. Med HD-nøkkelgenerering skaper Bitcoin Core et helt nytt nøkkelpar for hver nye adresse, men alle disse nøklene er avledet fra et enkelt, 12-ords frø. Så lenge brukerne husker dette ordet på 12 ord, kan de generere alle private nøkler på nytt og få tilgang til alle pengene sine.

Det bør bemerkes at HD Key Generation ikke er en ny funksjon i Bitcoin-verdenen. Mange lommebøker inkluderte allerede muligheten i flere år. Det eksisterte bare aldri i Bitcoins referanseklient – til nå.

Opptreden & Sikkerhet

Og selvfølgelig introduserer Bitcoin Core 0.13.0 en betydelig liste over ytelse og sikkerhetsoppgraderinger. Det fulle omfanget av disse forbedringene er utenfor omfanget av denne artikkelen (se Bitcoin Core 0.13.0’s utgivelsesmerknader for alle detaljer), men kort sagt …

Databuffeminnet er økt, noe som gjør at noder kan øke hastigheten på valideringen av transaksjonen og mer. Med kommandolinjeverktøyet Bitcoin kan brukerne nå skrive passord og annen sensitiv informasjon interaktivt, noe som forbedrer sikkerheten ved ikke å lagre denne informasjonen i ren tekst. Programvaren er oppdatert for å bruke C ++ 11 og Python 3, nyere versjoner av programmeringsspråkene, som gir mulighet for kraftigere funksjoner. ARM (en spesifikk mikroprosessorarkitektur) binærfiler for Linux er nå en del av utgivelsen, så brukerne trenger ikke å kompilere dette for seg selv. Data om hvilke transaksjoner i en mempool som er avhengige av hverandre (som brukt med CPFP) kan kommuniseres til eksterne programmer. Noder i nettverket kan be om å motta bare transaksjoner som oppfyller en viss gebyrterskel for å forhindre DoS-angrep. Og til slutt har det vært mange forbedringer på lavt nivå i protokollene for peer-to-peer, ekstern prosedyreanrop og meldingssystem (ZMQ).

Takk til Bitcoin Core hovedansvarlig Wladimir van der Laan og Bitcoin Core utvikler og Ciphrex CEO Eric Lombrozo for informasjon og tilbakemelding.

Merk: Bitcoin Core 0.13.0 ble offisielt utgitt 23. august; den opprinnelige tittelen på denne artikkelen, som kunngjorde utgivelsen den 22. august, var feil. Den hadde blitt merket for utgivelse, noe som vanligvis betyr at den vil bli utgitt i løpet av et par dager. Bitcoin Core 0.13.0 kan nå lastes ned på bitcoincore.org og bitcoin.org. (Men før du laster ned, merk deg dette sikkerhetsadvarsel på bitcoin.org.)