Hoe wordt de moeilijkheidsgraad berekend?

De Bitcoin-moeilijkheidsgraad begon bij 1 (en kan daar nooit onder gaan). Vervolgens worden voor elke 2016 blokken die worden gevonden, de tijdstempels van de blokken vergeleken om erachter te komen hoeveel tijd het kostte om 2016 blokken te vinden, noem het T. We willen dat 2016 blokken 2 weken duren, dus als T anders is, vermenigvuldigen we de moeilijkheidsgraad met (2 weken / T) – op deze manier, als de hashrate doorgaat zoals hij was, duurt het nu 2 weken om 2016-blokken te vinden.

Als het bijvoorbeeld maar 10 dagen duurde, betekent dat de moeilijkheidsgraad te laag is en dus met 40% wordt verhoogd.

De moeilijkheidsgraad kan toenemen of afnemen, afhankelijk van of het minder of meer dan 2 weken duurde om blokken van 2016 te vinden. Over het algemeen neemt de moeilijkheidsgraad af nadat de netwerkhashate is gedaald.

Als de correctiefactor groter is dan 4 (of kleiner dan 1/4), wordt in plaats daarvan 4 of 1/4 gebruikt om de verandering te voorkomen te abrupt te zijn.

Er zit een fout in de implementatie, waardoor de berekening is gebaseerd op de tijd om de laatste blokken van 2015 te vinden in plaats van op 2016. Om het probleem op te lossen zou een hard fork nodig zijn. voorlopig uitgesteld.

Het is mogelijk om een ruwe schatting te geven voor de volgende moeilijkheidsgraad, gebaseerd op de tijd om de recente blokken te vinden. Niemand kan op betrouwbare wijze voorspellingen doen voor de toekomstige moeilijkheid, maar het staat iedereen vrij om te speculeren op basis van wisselkoersontwikkelingen, de wet van Moore en andere hardware-ontwikkelingen.

Opmerkingen

• @StevenRoose: AFAIK is het, maar ik laat het over aan mensen die meer betrokken zijn bij de kerncode om commentaar te geven … Dit is voldoende voor een aparte SE-vraag.
• Goed antwoord, maar een klein, maar hoofdpunt is ontgaan: hoe komen de knooppunten in het netwerk overeen wat de moeilijkheid is?
• @deadalnix: De moeilijkheid van een blok is een deterministische berekening op basis van de gegevens van de vorige blokken. Alle knooppunten voeren onafhankelijk dezelfde berekening uit en krijgen hetzelfde resultaat.
• @deadalnix: De tijdstempel is een onderdeel van het blok, wat betekent dat degene die het blok heeft gevonden, beslist wat erin moet worden gestopt . Het tijdstempel mag niet eerder zijn dan de mediaan van de afgelopen 11 blokken. Als een knooppunt een blok ontvangt met een tijdstempel dat meer dan twee uur in de toekomst ject het en verspreid het niet.
• @tobi: Oh ok. Eerdere opmerkingen gingen over de bug, en ” fouten ” lieten doorschemeren dat het ‘ de bug, dus ik nam aan dat we het daar ‘ over hadden. Dus ja. Als we aannemen dat de hashrate rond 2140 ongeveer * 1 miljard zal zijn wat het nu is, zal het schema 96 weken vooruitlopen, of bijna twee jaar. Maar er is nog een ander effect – een vertraging veroorzaakt door het feit dat de moeilijkheid in het begin 1 was, hoewel de hashrate niet ‘ t genoeg was om het te rechtvaardigen.

Het antwoord van Meni is goed. Ik wil alleen een praktische gedetailleerde methode geven over moeilijkheidsberekening, misschien nuttig voor de toekomst weergaven van het antwoord van deze vraag.

Laten we eens kijken naar Satoshis genesis block header (deel van gerelateerde info):

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

Zoals we hierboven kunnen zien, heeft het genesisblok een “1” moeilijkheidsgraad en “1d00ffff” bits. De bitcoin-bits betekent de “doel” -hashwaarde, het nieuw gegenereerde blok moet aan een voorwaarde voldoen: de dubbele SHA-256-hashwaarde van de blokheader moet kleiner zijn dan deze “target” waarde.

De “1d00ffff” bits waarde in Genesis block betekent de “target” waarde:

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

Vervolgens, om zoek een nieuw blok, je moet die 32 bits nNonce-waarde zoeken (en nTimes en de hashMerkleRoot ook) totdat de blok-hashwaarde 4 bytes nul heeft.Overigens is de nNonce een van de velden in de blokheaderstructuur:

 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 }; 

Omdat het SHA-256-algoritme (evenals elk cryptografisch beveiligd hash-algoritme) produceert output die zal verschijnen als een uniform willekeurige reeks , de praktische “trial and error” -methode is de enige manier om een nieuw blok te vinden dat aan de voorwaarde voldoet. De kans om een blok te vinden met de 4 bytes nul leidende hash-waarde is 1 / (2 ^ 32), dat betekent dat de gemiddelde “trial and error” -nummers precies 2 ^ 32 (dwz 4G) zijn.

Om de mens gemakkelijk te begrijpen over deze “doel” -hashwaarde, definiëren we de term “moeilijkheid”, wat de gemiddelde “vallen en opstaan” -nummers betekent om een blok te vinden dat voldoet aan de “doel” -voorwaarde. En we definiëren de “moeilijkheidsgraad” -eenheid: 1 “moeilijkheidsgraad” = 4G-hashes

Tot op de dag van vandaag bereikt de bitcoin blockchain-hoogte 501509, laten we eens kijken naar de kop:

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

Het blok 501509 “s bits = 0x18009645, het is het compacte formaat van 256 bits integer, het 256 bits formaat is:

[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 

Tot dusver heb je alle details over hoe je de” moeilijkheidsgraad “kunt berekenen. In sommige gevallen gebruiken we ook de eenvoudige indeling 1.7T om de moeilijkheid te zeggen, in het bovenstaande voorbeeld:

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

Reacties

• 1d is 29 december (niet 26). SHS is SHA
• bedankt @BorisIvanov, de typefout SHS is opgelost. Maar 1d betekent inderdaad 26 bytes zero tail in plaats van 29, lees alstublieft de voorbeelddetails hierboven.
• ah ja. Significand

Ik zou mijn 2 willen geven cent hier, door de relatie uit te leggen tussen de kans om een blok te minen gezien het huidige doel t en de overeenkomstige moeilijkheid d zoals het wordt berekend in bitcoin core.

Dus cryptografische hash-functies worden geïdealiseerd door de willekeurige oracle-abstractie [ https://en.wikipedia.org/wiki/Random_oracle] . We kunnen daarom de uitvoer van de doubleSHA256 hash-functie die in PoW wordt gebruikt, modelleren als een uniforme variabele in de ruimte {0,1}^256, dwz arrays van 256 bits . De kans dat een enkele hash h een geldige hash is, is dus:

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

Aan de andere kant d wordt als volgt berekend, net zoals @gary eerder uitgelegd, alleen omgezet in decimalen:

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

De implementatie is in [ https://github.com/bitcoin/bitcoin/blob/master/src/rpc/blockchain.cpp] , regel 60, functie GetDifficulty. Als iemand kan uitleggen hoe de code precies overeenkomt met de bovenstaande formule, zou dat eigenlijk handig zijn. Door deze twee formules te combineren, krijgen we:

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

Bij het analyseren van deze laatste uitdrukking is de moeilijkheid de verhouding tussen de kans op het verkrijgen van een hash lager dan 2^{224} (dit is het laagste decimale getal dat een binaire weergave heeft met 256 bits beginnend met 32 nul bits) en de kans dat een geldige hash wordt verkregen op basis van het huidige doel t. Dit is een directe implicatie van het definiëren, in het genesisblok, als moeilijkheidsgraad 1 degene die is gekoppeld aan het hexadecimale doel 0x1d00ffff , uitgedrukt in wat ik denk dat de 32-bits compacte vorm voor 256-bits getallen wordt genoemd.

A leuke vraag is volgens mij de reden waarom deze specifieke compacte vorm werd gekozen om het doel weer te geven.

Opmerkingen

• Upvoted! De compacte vorm biedt 3 meest significante bytes voor het doel, in de min moeilijkheidsgraad zijn de 3 meest significante bytes 00ffff.