Hvordan beregnes vanskeligheder?

Bitcoin-vanskeligheden startede ved 1 (og kan aldrig gå under det). For hver 2016-blok, der findes, sammenlignes tidsstemplerne for blokkene for at finde ud af, hvor meget tid det tog at finde 2016-blokke, kald det T. Vi vil have, at 2016-blokke tager 2 uger, så hvis T er anderledes, multiplicerer vi vanskeligheden ved (2 uger / T) – hvis denne hashrate fortsætter som den var, vil det nu tage 2 uger at finde 2016-blokke.

For eksempel, hvis det kun tog 10 dage, betyder vanskeligheder er for lave og vil således blive øget med 40%.

Vanskeligheden kan stige eller falde afhængigt af om det tog mindre eller mere end 2 uger at finde 2016-blokke. Generelt vil sværhedsgraden falde, når netværkshashratet er faldet.

Hvis korrektionsfaktoren er større end 4 (eller mindre end 1/4), bruges 4 eller 1/4 i stedet for at forhindre ændringen for at være for brat.

Der er en fejl i implementeringen, som beregningen er baseret på tidspunktet for at finde de sidste 2015-blokke i stedet for 2016. At rette det ville kræve en hård gaffel og er således udsat for nu.

Det er muligt at give et groft skøn for den næste vanskelighedsændring baseret på tiden til at finde de seneste blokke. Ingen kan forudsige langsigtede forudsigelser for den fremtidige vanskelighed pålideligt, men enhver kan frit spekulere baseret på valutakursudviklingen, Moores lovgivning og andre fremskridt inden for hardware.

Kommentarer

• @StevenRoose: Det er AFAIK, men jeg overlader det til folk, der er mere involveret i kernekoden, at kommentere … Dette er passende for et separat SE-spørgsmål.
• Godt svar, men et lille, men stort punkt undgås: hvordan er knudepunkterne i netværket enige om, hvad der er vanskeligheden?
• @deadalnix: Vanskeligheden ved en blok er en deterministisk beregning baseret på dataene af de foregående blokke. Alle knudepunkter foretager uafhængigt samme beregning og får det samme resultat.
• @deadalnix: Tidsstemplet er en del af blokken, hvilket betyder, at den, der fandt blokken, beslutter hvad han skal sætte i den Tidsstemplet må ikke være hurtigere end medianen for de sidste 11 blokke. Hvis en node modtager en blok med et tidsstempel mere end 2 timer i fremtiden, vil den også ject det og ikke sprede det.
• @tobi: Åh ok. Tidligere kommentarer handlede om fejlen, og ” fejl ” antydede, at det ‘ er det bug, så jeg antog, at vi ‘ taler om det. Så ja. Hvis vi antager, at omkring 2140 vil hashratet være omkring * 1B, hvad det er nu, vil tidsplanen være fremad med 96 uger eller næsten to år. Men der er endnu en effekt – en forsinkelse forårsaget af det faktum, at vanskeligheden i starten var 1, selvom hashratet ikke var ‘ ikke nok til at retfærdiggøre det.

Menis svar er godt. Jeg vil bare give nogle praktiske detaljeringsmetoder om vanskelighedsberegning, måske nyttige i fremtiden synspunkter på dette spørgsmåls svar.

Lad os se på Satoshis genesis block header (del af relateret info):

$ bitcoin-cli getblockhash 0 000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f $ bitcoin-cli getblockheader 000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f { ... "height": 0, ... "bits": "1d00ffff", "difficulty": 1, ... } 

Som vi kan se ovenfor, har genesisblokken en “1” vanskelighed og “1d00ffff” bits. bitcoin bits betyder “mål” hash-værdien, den nye genererede blok skal opfylde en betingelse: blokhovedets dobbelte SHA-256 hash-værdi skal være mindre end dette “mål” -værdi.

Bitværdien “1d00ffff” i genesisblok betyder “mål” -værdien:

[0x00000000,0xffff,{0x00..0x00}] {0x00..0x00} at above has 26 bytes 0x00. 

Derefter til find en ny blok, du skal søge i den 32 bit nNonce værdi (og nTimes og hashMerkleRoot også), indtil blok hash værdien har 4 bytes nul førende.Forresten er nNonce et af felterne i blokhovedstruktur:

 struct header_structure{ // BYTES NAME uint32_t nVersion; // 4 version uint8_t hashPrevBlock[32]; // 32 previous block header hash uint8_t hashMerkleRoot[32]; // 32 merkle root hash uint32_t nTime; // 4 time uint32_t nBits; // 4 target uint32_t nNonce; // 4 nonce }; 

Fordi SHA-256-algoritme (såvel som enhver kryptografisk sikker hash-algoritme) producerer output, der vises som en ensartet tilfældig sekvens , er den praktiske “forsøg og fejl” -metode den eneste måde at finde en ny blok til at opfylde betingelsen. Sandsynligheden for at finde en blok med de 4 bytes nul-førende hash-værdi er 1 / (2 ^ 32), det betyder, at de gennemsnitlige “prøve-og-fejl” -tal er nøjagtigt 2 ^ 32 (dvs. 4G).

For menneskelig let forståelse af denne “mål” hash-værdi definerer vi udtrykket “vanskelighed”, hvilket betyder det gennemsnitlige “forsøg og fejl” tal for at finde en blok, der opfylder “mål” -tilstanden. Og vi definerer “sværhedsgrad” -enheden: 1 “sværhedsgrad” = 4G hashes

Så indtil i dag når bitcoin-blockchain-højden 501509, lad os se på dens overskrift:

$ bitcoin-cli getblockheader 0000000000000000006c5532f4fd9ee03e07f94df165c556b89c495e97680147 { ... "height": 501509, ... "bits": "18009645", "difficulty": 1873105475221.611, ... } 

Blokken 501509 “s bits = 0x18009645, det er det kompakte format på 256 bit heltal, dets 256 bit format er:

[0x00000000,0x00000000,0x009645,{0x00..0x00}] {0x00..0x00} at above has 21 bytes 0x00. that is 0x009645 * (256 ^ 21） The genesis block"s target is ( 0x00ffff * 256 ^ 26 ）which is the difficulty unit "1.0". So, the difficulty = (0x00ffff * 256 ^ 26）/ (0x009645 * 256 ^ 21) = 65535/38469 * (256^5) = 1.703579505575918 * 2^40 = 1873105475221.611 

Indtil videre har du alle detaljer om, hvordan du beregner” vanskeligheden “. I nogle tilfælde bruger vi også det enkle format 1.7T for at sige vanskeligheden, i ovenstående eksempel ：

 (1.703579505575918 * 2^40) = 1.703579505575918T 1T = 2^40 = 1024^4 

Kommentarer

• 1d er 29 i dec (ikke 26). SHS er SHA
• tak @BorisIvanov, skrivefejl SHS er rettet. Men 1d betyder faktisk 26 bytes nul hale i stedet for 29, læs venligst eksemplets detaljer vist ovenfor.
• ah ja. Betydelig

Jeg vil gerne give mine 2 cent her ved at forklare forholdet mellem sandsynligheden for at udvinde en blok givet det aktuelle mål t og den tilsvarende vanskelighed d som det beregnes i bitcoin-kerne.

Så kryptografiske hashfunktioner idealiseres ved den tilfældige oracle-abstraktion [ https://en.wikipedia.org/wiki/Random_oracle] . Vi kan derfor modellere output af doubleSHA256 hash-funktionen, der bruges i PoW som en ensartet variabel i rummet {0,1}^256, dvs. arrays på 256 bit . Således er sandsynligheden for, at en enkelt hash h er en gyldig hash:

p = P(h < t) = t /( 2^{256} - 1 ) 

På den anden side d beregnes som følger, ligesom @gary forklarede før kun omdannet til decimaler:

d = ( (2^{16} - 1) * 2^{8*26} ) / t = ( (2^{16} -1) * 2^{208} ) / t 

Implementeringen er i [ https://github.com/bitcoin/bitcoin/blob/master/src/rpc/blockchain.cpp] , linje 60, funktion GetDifficulty. Faktisk hvis nogen kan forklare, hvordan nøjagtigt koden kortlægges til formlen ovenfor, ville det være nyttigt. Kombination af de to formler, vi får:

d = ( (2^{16} -1) * 2^{208} ) / ( p * (2^{256} - 1) ) ~ 2^{-32} / p 

Analyse af dette sidste udtryk er vanskeligheden forholdet mellem sandsynligheden for at opnå en hash lavere end 2^{224} (hvilket er det laveste decimaltal, der har en binær repræsentation ved hjælp af 256 bits, der starter med 32 nulbit) og sandsynligheden for at opnå en gyldig hash baseret på det aktuelle mål t. Dette er en direkte implikation af at definere, i genesisblokken, som vanskelighed 1 den, der er knyttet til det hexadecimale mål 0x1d00ffff , udtrykt i hvad jeg tror kaldes 32-bit kompakt form til 256-bit tal.

A godt spørgsmål tror jeg er, hvorfor denne specifikke kompakte form blev valgt til at repræsentere målet.

Kommentarer

• Opstemt! Den kompakte form giver 3 mest betydningsfulde byte til målet, i min sværhedsgrad er de 3 mest betydningsfulde byte 00ffff.