Bitcoin Core 24.0 udgivet: Her er hvad der er nyt

En ny version af den originale Bitcoin-software lanceret af Satoshi Nakamoto i 2009 er udkommet.

Bitcoin Core 24.0 blev arbejdet på af 112 udviklere i omkring syv måneder for at bringe håndgribelige forbedringer til Bitcoin Cores tegnebog, peer-to-peer (P2P) kommunikation, grafisk brugergrænseflade (GUI) og meget mere.

Denne artikel udforsker nogle af de vigtigste ændringer.

Tegnebogsopdateringer

Indledende Miniscript Support

Bitcoin Core 24.0 introducerer support til Miniscript ved at udvide wsh() output deskriptor. Selvom det er en indledende og rudimentær integration, baner tiltaget vejen for, at mere kompleks scripting kan implementeres til Bitcoin på en enklere og mere sikker måde.

Miniscript kan tænkes som en ramme (eller skabelon) til Bitcoin script, Bitcoins oprindelige programmeringssprog. Bitcoin Script er ansvarlig for at aktivere al programmeringsfunktionalitet, der er tilgængelig for Bitcoin, herunder for eksempel det, der måske er den mest simple af dem: at bestemme, hvem der må bruge en given mønt. For hver Bitcoin-transaktion anmoder afsenderen om modtagerens adresse og konstruerer med den information et script, der låser den bitcoin, der sendes, på en måde, så kun modtageren vil være i stand til at bruge den. Selvom det er ret nemt at konstruere simple scripts som ovenstående med Bitcoin Script, jo mere komplekst scriptet bliver, jo større er chancen for menneskelige fejl. Det er her Miniscript kommer ind i billedet.

Miniscript giver mulighed for at skrive en delmængde af Bitcoin Scripts i en struktureret vej. Det muliggør blandt andet analyse, sammensætning og generisk signering, hvilket giver mulighed for, at avancerede scripts kan skrives mere sikkert af udviklere. Med andre ord, Miniscript "indeholder" en vis funktionalitet af forudindstillede Bitcoin Scripts til et forventet adfærdsmønster, hvilket begrænser eventuelle risici, da uventet adfærd minimeres. I praksis giver det en "værktøjskasse" for udviklere at pille ved og skabe avancerede og komplekse scripts til Bitcoin i stedet for at skulle gøre det hele manuelt gennem Bitcoin Script.

Fra og med Bitcoin Core 24.0 kan brugere nu oprette en tegnebog, der indeholder et Miniscript-script, oprette adresser til den tegnebog og finansiere dem med bitcoin. Udgifter fra disse adresser understøttes endnu ikke af Bitcoin Core-pungen, hvilket betyder, at Miniscript-aktiverede tegnebøger på Bitcoin Core kun er se-kun for øjeblikket.

Foranderlige transaktioner

En ny RPC er blevet introduceret, sendall, der lader brugere bruge specifikke ubrugte transaktionsoutput (UTXO'er) i deres helhed. RPC'en sender beløbet i de angivne UTXO'er til en eller flere modtagere uden at generere ændringer. (Som standard, sendall vil bruge hver UTXO i tegnebogen.)

Denne adfærd kan være ønskelig i nogle få situationer. For det første vil brugeren naturligvis gerne tømme sin tegnebog. At kalde den nye RPC med standardkonfigurationer vil gøre netop det på en nem måde. For det andet vil brugeren måske forbedre deres privatliv ved at give afkald på ændringer.

Skift adresser er vanskelige, fordi brugere ofte mister overblikket over, hvor de stammer fra, og som sådan kan blande dem med andre UTXO'er som input i en fremtidig transaktion. Dette ville udgøre et privatlivsproblem på grund af fælles-input-ejerskab heuristik, en meget brugt præmis i kædeanalyse, der antager, at alle input i en transaktion tilhører den samme bruger. I eksemplet med ændringsoutput ville brugeren lave det link, og reelt risikere en deanonymisering af flere af deres mønter, da en kædeanalytiker ville være i stand til at gruppere nogle af brugerens adresser som en tegnebog.

En uforanderlig betaling bekæmper dette problem ved at oprette en transaktion, der bruger hele de valgte UTXO'er. Da der ikke er nogen ændring, kan brugeren ikke begå den ovenfor nævnte fejl. Desuden giver en uforanderlig betaling en rimelig tvivl for en kædeanalytiker, der spekulerer på, om det nye output ejes af den samme enhed, der sendte betalingen (en simpel flytning af midler til en ny adresse) eller faktisk nu ejes af en anden bruger.

Skift outputrandomisering for at undgå fingeraftryk

Som forklaret ovenfor, ændring af output kan være en privatlivslækage. Mens sendall begrænser brugen af ​​en ændring af adresse helt, i virkeligheden vil der være få gange, hvor brugeren ejer en UTXO af den nøjagtige størrelse af betalingen, der skal udføres. At sikre, at en observatør ikke kan se, hvilken af ​​udgangene der er ændringsadressen, hjælper brugeren med at få en smule privatliv, fordi det ikke vil være trivielt at forbinde en nyoprettet adresse (ændre output) med det nu brugte input til den pågældende transaktion .

Normalt, når der ikke er en UTXO med betalingens nøjagtige beløb, vælger de fleste tegnebøger og brugere intuitivt den, der er tættest på det nummer. Som en konsekvens kan en observatør, der ser blockchain, se, hvilket output der er betalingen (større), og hvilken der er ændringen (mindre). Dette medfører mange af de førnævnte risici.

For at mindske sandsynligheden for, at en observatør kan udpege ændringsoutput og klyngebrugeradresser, randomiserer Bitcoin Core nu ændringsoutputværdier.

Fra og med version 24.0 vælger Bitcoin Core-pungen et tilfældigt tal mellem betalingsstørrelsen og tre gange betalingsstørrelsen. Dette nummer vil informere dets UTXO-valg til udgifter. Dette betyder effektivt, at nogle gange vil algoritmen vælge en UTXO, hvis værdi er tættere på betalingen, og andre gange vil den vælge en UTXO, hvis værdi er tættere på den øvre grænse på tre gange betalingsbeløbet. Førstnævnte scenarie vil producere det typiske ændrings-output-lavere-end-betaling-scenarie, mens sidstnævnte vil producere det omvendte - et ændringsoutput, der er større end betalingen. I betragtning af, at der ikke er nogen måde for en blockchain-observatør at fortælle, hvornår hvert scenarie sker på et givet tidspunkt, bør brugeren være i stand til at nyde større privatlivsforsikringer.

Opdateringer, der skal erstattes med gebyr

RBF giver mulighed for en Bitcoin-bruger, når de sender en transaktion til netværket. Ofte ønsker en bruger ikke at betale for meget for minearbejdergebyrer, og kan som sådan vælge en "mellemvej" mellem det betalte gebyr og den hastighed, hvormed transaktionen bliver inkluderet i en blok. Men hvis gebyrværdien valgt af brugeren er for lav, eller mempoolen er overbelastet, kan det tage for lang tid for transaktionen at blive inkluderet i en blok (eller den kan blive hængende i mempoolen helt). RBF giver brugeren mulighed for at "bumpe" gebyret for deres transaktion i et sådant tilfælde, hvilket oftere end ikke muliggør en hurtigere afvikling.

Under motorhjelmen bumper RBF faktisk ikke gebyret. Hvad der sker i baggrunden er, at softwareklienten vil udsende en ny transaktion med de samme input og de fleste af de samme output. (Nogle outputværdier ændrer sig; gebyrværdien vil naturligvis ændre sig for at afspejle det nye nummer, og normalt bliver forskellen fratrukket det beløb, der blev sendt til ændringsadressen.)

Historisk set ville noder kun videresende den første version af en transaktion, de så. Med fremkomsten af ​​RBF blev der indført en mekanisme til at lade brugere markere, at de sendte en transaktion, der i sidste ende kunne blive gebyrbelastet, dvs. erstattet af en version med et højere gebyr. Dette tjente som en heads-up til noder, der fortalte dem, at versioner med højere gebyrer af denne transaktion kunne sendes på et senere tidspunkt, og at de også skulle videresendes. Sandsynligvis vil den højere gebyrversion af transaktionen have en tendens til at være mere attraktiv for minearbejdere og som sådan valgt først. Når det sker, og det bliver inkluderet i en blok, vil transaktionen med lavere gebyr blive droppet fra nodernes mempools, da det ville være et forsøg på et dobbeltforbrug.

Bitcoin Core 24.0 introducerer to opdateringer til RBF-funktionalitet.

For det første giver det nu brugerne mulighed for at konfigurere deres noder for at videresende udskiftelige transaktioner uden håndhævelse af RBF-flaget. Dette kan gøres gennem det nye mempoolfullrbf mulighed. Det vil blive sat til off som standard, men de, der er interesserede i at aktivere det, kan slå det til.

For det andet er RBF nu sat som en standard i Bitcoin Cores tegnebog. Transaktioner tilvælger nu RBF som standard og -walletrbf opstartsindstillingen er som standard sand. Brugere kan fravælge RBF ved at justere en given transaktion i byggeprocessen eller indstille -walletrbf opstartsmulighed til false.

Descriptor Wallet Migration

Bitcoin Core 23.0 gjort descriptor-punge til standard. Deskriptorer letter brugerens liv ved at sikkerhedskopiere deres tegnebog og senere gendanne denne backup i et standardformat.

Før deskriptorer eksisterede, skulle brugerne kende deres tegnebogs afledningssti, som dikterer, hvordan tegnebogens hovednøgle udleder adresser, der skal bruges til at modtage og sende bitcoin. Da tegnebøger kunne have forskellige afledningsstier, var det ikke nok, at en sikkerhedskopi udelukkende indeholdt frøsætningerne. Nogle gange kunne brugeren være heldig og forsøge at gendanne en sikkerhedskopi med en tegnebog, der udnyttede den samme afledningssti, men i betragtning af den lave sandsynlighed for, at det sker, er hele websteder dedikeret til at hjælpe brugerne med at finde ud af, hvilken afledningssti de skal bruge til gamle og nye tegnebøger opstået.

Deskriptoren løser dette problem ved at være beskrivende om, hvilken afledningssti den sikkerhedskopierede tegnebog bruger, hvilket i høj grad forbedrer brugeroplevelsen. Ideen er, at en descriptor wallet backup selv indeholder alle de nødvendige oplysninger, for at den kan blive korrekt gendannet af enhver softwareklient (forudsat at klienten er descriptor-aktiveret).

Nu introducerer Bitcoin Core 24.0 et nyt værktøj til at migrere legacy wallets til et descriptor wallet-format, hvilket gør det muligt for brugere at drage fordel af denne nye standard for bedre at beskytte deres dyrebare bitcoin. Selvom det stadig er eksperimentelt, er en ny RPC (migratewallet) er blevet indført. Dette dokument giver flere detaljer om dens funktionalitet.

GUI ændringer

Bitcoin Core GUI har været kendt for ikke at levere det samme niveau af funktionalitet, som remote procedure calls (RPC'er) og kommandolinjeværktøjer kan opnå. Bitcoin 24.0 tager nogle skridt for at ændre lidt på det.

Bitcoin Cores nyeste version bringer et nyt menupunkt på GUI, der lader brugere gendanne en tegnebog fra backup, hvilket gør det lettere for ikke-tekniske folk at gendanne sikkerhedskopier. Tidligere fandtes denne mulighed kun på kommandolinjen.

En anden mangel, som GUI'en havde sammenlignet med RPC-grænsefladen, var relateret til Bitcoin Core-klientens indstillinger. Den kendte bitcoin.conf fil er den hellige gral i Bitcoin Core-konfigurationen, men igen kunne den primært justeres via kommandolinjen. Der eksisterede en mulighed for at justere indstillinger i GUI, men en advarsel gjorde det klart bitcoin.conf havde forrang over GUI'en i tilfælde af, at både filen og GUI'en forsøgte at indstille data til den samme konfiguration. Selvom GUI'en gav en enkel mulighed for at ændre indstillinger, var konfigurationsfilen stadig den mest pålidelige måde at tilpasse sin Bitcoin Core-klient på.

Bitcoin Core 24.0 ændrer det. Den nye opdatering forener siden med GUI-indstillinger med bitcoin.conf fil. Nu, når en bruger åbner klientens indstillinger på GUI'en, trækkes de viste indstillinger fra konfigurationsfilen. På samme måde afspejles konfigurationsændringer foretaget i GUI nu i bitcoin.conf. (Det er værd at påpege, at forholdet der er indirekte, fordi ændringer i GUI faktisk er sat til settings.json, en fil, der har forrang over bitcoin.conf.)

Ændringer til P2P-kommunikation

Ny logik til download af overskrifter

Bitcoin Core 24.0 bringer en opdatering til den måde, peers i netværket indhenter til spidsen af ​​kæden, enten fordi de starter op for første gang eller har brugt lang tid uden at oprette forbindelse til Bitcoin-netværket.

Før denne udgivelse ville en ny peer, der sluttede sig til Bitcoin, begynde at lede efter peers, hvorfra man kunne downloade blokoverskrifter. Peeren downloader ikke hele blokke i starten, fordi den er tilskyndet til at kontrollere, om den følger den rigtige kæde, før den downloader blokkene for den kæde. Ellers risikerer den at downloade blokke til den forkerte kæde og derved spilde ressourcer.

Mens download af overskrifter hjælper med at spare tid og ressourcer, kan et ressourceudmattelsesangreb stadig ske, hvor en ondsindet aktør spammer peeren med millioner af falske blokoverskrifter. Da klienten skal downloade og gemme headerne på disken, kan en stor nok mængde data være i stand til at lamme peers hardware.

For at afbøde denne trussel introducerede Bitcoin Core konceptet checkpoints år siden. Kontrolpunkter bestemmer hvilke blokke skal være til stede i en kæde, for at den er gyldig. Denne løsning repræsenterer dog også et problem, da kontrolpunkter kan blive misbrugt til effektivt at rulle den længste kæde tilbage. En sådan mulighed er ikke ønskværdig i Bitcoin, så en anden løsning måtte udtænkes. Indtast denne nye opdatering.

Med Bitcoin Core 24.0 downloader peers nu blokoverskrifter to gange. I den første kørsel downloades og kasseres headere (ikke gemt på disken), indtil der er fundet en tilstrækkelig mængde arbejde - hvilket tyder på, at den kæde, som peeren har fulgt, er gyldig. I så fald genstarter peeren så processen, men nu gemmer peeren udover downloading også blokoverskrifterne på disken. Ved kun at gemme headers på disken, når peeren er sikker på, at de er en del af en kæde med betydelige beviser på arbejde, undgår peeren at bruge store mængder lagerplads i et eventuelt angreb, såsom ressourceudmattelse. Dette fjerner også behovet for kontrolpunkter og er uden tvivl en mere elegant løsning, da det ikke afhænger af menneskelige input til at bestemme kædens gyldighed.

Tak til Aaron van Wirdum for feedback.

For flere detaljer og andre ændringer, se Bitcoin Core 24.0 udgivelses noter. For at downloade Bitcoin Core 24.0 skal du navigere link.. Detaljer om Bitcoin Core 24.0 er også forklaret i lyd i Bitcoin, Explained-podcasten episode 65.