Hur beräknas svårigheten?

Bitcoin-svårigheten började vid 1 (och kan aldrig gå under det). För varje 2016-block som hittas jämförs blockens tidsstämplar för att ta reda på hur mycket tid det tog att hitta 2016-block, kall det T. Vi vill att 2016-blocken tar två veckor, så om T är annorlunda multiplicerar vi svårigheten med (2 veckor / T) – på detta sätt, om hashrate fortsätter som det var, tar det nu två veckor att hitta 2016-block.

Till exempel, om det bara tog 10 dagar betyder att svårigheten är för låg och därmed kommer att öka med 40%.

Svårigheten kan öka eller minska beroende på om det tog mindre eller mer än två veckor att hitta 2016-block. I allmänhet kommer svårigheten att minska efter att nätverkets hashrat sjunker.

Om korrigeringsfaktorn är större än 4 (eller mindre än 1/4) används 4 eller 1/4 istället för att förhindra förändringen att vara för abrupt.

Det finns ett fel i implementeringen, på grund av vilken beräkningen baseras på tiden för att hitta de senaste 2015-blocken snarare än 2016. Att fixa det skulle kräva en hård gaffel och är därmed uppskjutas för närvarande.

Det är möjligt att ge en grov uppskattning för nästa svårighetsändring, baserat på tiden för att hitta de senaste blocken. Ingen kan göra långsiktiga förutsägelser för framtida svårigheter på ett tillförlitligt sätt, men vem som helst är fri att spekulera utifrån valutakursutvecklingen, Moores lag och andra hårdvaruprojekt.

Kommentarer

• @StevenRoose: AFAIK är det, men jag lämnar det till personer som är mer involverade i kärnkoden att kommentera … Detta är tillräckligt för en separat SE-fråga.
• Bra svar, men en liten men huvudstad eluderas: hur överensstämmer noderna i nätverket om vad som är svårigheten?
• @deadalnix: Svårigheten med ett block är en deterministisk beräkning baserad på data av de tidigare blocken. Alla noder gör oberoende samma beräkning och får samma resultat.
• @deadalnix: Tidsstämpeln är en del av blocket, vilket innebär att den som hittade blocket bestämmer vad han ska sätta i det Tidsstämpeln får inte vara tidigare än medianen för de senaste 11 blocken. Om en nod tar emot ett block med en tidsstämpel mer än 2 timmar i framtiden kommer det att ject det och inte sprida det.
• @tobi: Åh okej. Tidigare kommentarer handlade om felet och ” fel ” antydde att det ’ är bug, så jag antog att vi ’ pratar om det. Så ja. Om vi antar att omkring 2140 kommer hashratet att vara runt * 1B vad det är nu, kommer schemat att vara framåt med 96 veckor, eller nästan två år. Men det finns ännu en effekt – en fördröjning orsakad av det faktum att i början var svårigheten 1 även om hashratet inte var ’ för att motivera det.

Menis svar är bra. Jag vill bara ge några praktiska detaljeringsmetoder om svårighetsberäkning, kanske till hjälp för framtiden syn på den här frågan ”. Svar.

Låt oss ta en titt på Satoshis genusblockhuvud (del av relaterad info):

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

Som vi kan se ovan har genesblocket ”1” svårighet och ”1d00ffff” bitar. bitcoinbitar betyder hashvärdet ”target”, det nya genererade blocket måste uppfylla ett villkor: blockhuvudets dubbla SHA-256 hashvärde måste vara mindre än detta ”mål” -värde.

Bitvärdet ”1d00ffff” i Genesis-blocket betyder ”mål” -värdet:

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

För att sedan hitta ett nytt block, du måste söka det 32 bitarna nNonvärde (och nTimes och hashMerkleRoot också) tills block-hash-värdet har 4 byte noll.Förresten är nNonce ett av fälten i blockhuvudstrukturen:

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

Eftersom SHA-256-algoritm (liksom alla kryptografiskt säkra hashalgoritmer) producerar utdata som kommer att visas som en enhetlig slumpmässig sekvens , är den praktiska metoden ”försök och fel” det enda sättet att hitta ett nytt block för att uppfylla villkoret. Sannolikheten att hitta ett block med de fyra bytes nollledande hashvärdet är 1 / (2 ^ 32), det betyder att de genomsnittliga ”försök och fel” -talen är exakt 2 ^ 32 (dvs. 4G).

För mänsklig enkel förståelse av detta ”mål” hashvärde definierar vi termen ”svårighet”, vilket betyder det genomsnittliga ”försök och fel” -talet för att hitta ett block för att uppfylla ”mål” -villkoret. Och vi definierar ”svårighets” -enheten: 1 ”svårighet” = 4G-hash

Sedan, fram till idag, når bitcoin blockchain-höjden 501509, låt oss ta en titt på dess rubrik:

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

Blocket 501509 ”s bitar = 0x18009645, det är det kompakta formatet på 256 bitars heltal, dess 256 bitars format är:

[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 

Hittills har du alla detaljer om hur man beräknar” svårigheten ”. I vissa fall använder vi också det enkla formatet 1.7T för att säga svårigheten, i ovanstående exempel ：

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

Kommentarer

• 1d är 29 i dec (inte 26). SHS är SHA
• tack @BorisIvanov, skrivfel SHS har fixats. Men 1d betyder faktiskt 26 byte noll svans istället för 29, läs exemplets detalj som visas ovan.
• ah ja. Betydande

Jag skulle vilja ge mina 2 cent här, genom att explicera förhållandet mellan sannolikheten för att bryta ett block med tanke på det aktuella målet t och motsvarande svårighet d som det beräknas i bitcoin-kärna.

Så kryptografiska hashfunktioner idealiseras av den slumpmässiga oracle-abstraktionen [ https://en.wikipedia.org/wiki/Random_oracle] . Vi kan därför modellera utdata från doubleSHA256 hashfunktion som används i PoW som en enhetlig variabel i utrymmet {0,1}^256, dvs matriser på 256 bitar . Sannolikheten för att en enskild hash h är en giltig hash är således:

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

Å andra sidan d beräknas enligt följande, precis som @gary förklarade innan den bara omvandlades till decimaler:

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

Implementeringen sker i [ https://github.com/bitcoin/bitcoin/blob/master/src/rpc/blockchain.cpp] , rad 60, funktion GetDifficulty. Egentligen om någon kan förklara hur exakt koden mappas till formeln ovan, skulle det vara till hjälp. Genom att kombinera dessa två formler får vi:

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

Analys av det här sista uttrycket är svårigheten förhållandet mellan sannolikheten för att få en hash lägre än 2^{224} (vilket är det lägsta decimaltalet som har en binär representation med 256 bitar som börjar med 32 nollbitar) och sannolikheten för att få en giltig hash baserat på det aktuella målet t. Detta är en direkt implikation av att definiera, i genesblocket, som svårighet 1 den som är associerad med det hexadecimala målet 0x1d00ffff , uttryckt i vad jag tror kallas 32-bitars kompakt form för 256-bitars nummer.

A trevlig fråga tror jag är varför denna specifika kompakta form valdes för att representera målet.

Kommentarer

• Uppröstade! Den kompakta formen ger 3 mest betydande byte för målet, i minsta svårighet är de 3 viktigaste byten 00ffff.