Hvordan beregnes vanskeligheter?

Bitcoin-vanskeligheten startet på 1 (og kan aldri gå under det). Så sammenlignes tidsstemplene for blokkene for hver 2016-blokk som blir funnet for å finne ut hvor mye tid det tok å finne 2016-blokker, kall det T. Vi vil at 2016-blokker skal ta 2 uker, så hvis T er annerledes, multipliserer vi vanskeligheten ved (2 uker / T) – hvis denne hashraten fortsetter slik den var, vil det nå ta to uker å finne 2016-blokker.

Hvis det for eksempel bare tok 10 dager, betyr at vanskeligheten er for lav og dermed vil øke med 40%.

Vanskeligheten kan øke eller redusere avhengig av om det tok mindre eller mer enn 2 uker å finne 2016-blokker. Vanligvis vil vanskeligheten avta etter at nettverkets hashrate faller.

Hvis korreksjonsfaktoren er større enn 4 (eller mindre enn 1/4), brukes 4 eller 1/4 i stedet for å forhindre endringen for å være for brå.

Det er en feil i implementeringen, på grunn av hvilken beregningen er basert på tiden for å finne de siste 2015-blokkene i stedet for 2016. Å fikse det vil kreve en hard gaffel og er dermed utsatt for nå.

Det er mulig å gi et grovt estimat for neste vanskelighetsendring, basert på tiden for å finne de siste blokkene. Ingen kan på lengre sikt spå fremtidige vanskeligheter pålitelig, men hvem som helst kan spekulere basert på valutakursutviklingen, Moores lov og andre fremskritt innen maskinvare.

Kommentarer

• @StevenRoose: AFAIK det er, men jeg vil overlate det til folk som er mer involvert i kjernekoden å kommentere … Dette er tilstrekkelig for et eget SE-spørsmål.
• Godt svar, men ett lite, men stort poeng er unnlatt: hvordan blir nodene i nettverket enige om hva som er vanskeligheten?
• @deadalnix: Vanskeligheten med en blokk er en deterministisk beregning basert på dataene av de forrige blokkene. Alle noder gjør uavhengig samme beregning og får det samme resultatet.
• @deadalnix: Tidsstemplet er en del av blokken, noe som betyr at den som fant blokken bestemmer hva han skal legge i den Tidsstemplet må ikke være snarere enn medianen for de siste 11 blokkene. Hvis en node mottar en blokk med et tidsstempel mer enn 2 timer i fremtiden, vil den ject det og ikke spre det.
• @tobi: Å ok. Tidligere kommentarer handlet om feilen, og » feil » antydet at det ‘ er feil, så jeg antok at vi ‘ snakker om det. Så ja. Hvis vi antar at rundt 2140 vil hashratet være rundt * 1B hva det er nå, vil planen være fremover med 96 uker, eller nesten to år. Men det er nok en annen effekt – en forsinkelse forårsaket av det faktum at i begynnelsen var vanskeligheten 1 selv om hashratet ikke var ‘ ikke nok til å rettferdiggjøre det.

Menis svar er bra. Jeg vil bare gi noen praktiske detaljmetoder om vanskelighetsberegning, kanskje nyttig for fremtiden synspunkter på dette spørsmålets svar.

La oss ta en titt på Satoshis genesis block header (del av relatert info):

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

Som vi kan se ovenfor, har genese-blokken en «1» vanskelighetsgrad og «1d00ffff» biter. bitcoinbiter betyr «mål» hash-verdien, den nye genererte blokken må oppfylle en betingelse: blokk header «s dobbel SHA-256 hash-verdi må være mindre enn dette «target» -verdi.

Bitverdien «1d00ffff» i genese-blokken betyr «target» -verdien:

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

Deretter, for å finne en ny blokk, må du søke i 32 bits nNodeverdi (og nTimes og hashMerkleRoot også) til blokk hash-verdien har 4 byte null.Forresten, nNonce er et av feltene i blokkoverskriftstruktur:

 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 kryptografisk sikker hash-algoritme) produserer utdata som vil vises som en jevn tilfeldig sekvens , er den praktiske «prøving og feiling» -metoden den eneste måten å finne en ny blokk for å oppfylle betingelsen. Sannsynligheten for å finne en blokk med 4 byte null ledende hash-verdi er 1 / (2 ^ 32), det betyr at gjennomsnittlige «prøving og feiling» -tall er nøyaktig 2 ^ 32 (dvs. 4G).

For menneskelig enkel forståelse av denne «mål» hashverdien, definerer vi begrepet «vanskeligheter», som betyr det gjennomsnittlige «prøving og feiling» -nummeret for å finne en blokk for å oppfylle «mål» -tilstanden. Og vi definerer «vanskelighets» -enheten: 1 «vanskelighetsgrad» = 4G hashes

Så frem til i dag når bitcoin blockchain-høyden 501509, la oss ta en titt på overskriften:

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

Blokken 501509 «s bits = 0x18009645, det er det kompakte formatet på 256 bits heltall, dets 256 bits 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 

Så langt har du alle detaljene om hvordan du skal beregne» vanskeligheten «. I noen tilfeller bruker vi også det enkle formatet 1.7T for å si vanskeligheten, i eksemplet ovenfor ：

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

Kommentarer

• 1d er 29 i desember (ikke 26). SHS er SHA
• takk @BorisIvanov, skrivefeil SHS er løst. Men 1d betyr faktisk 26 byte null hale i stedet for 29, vennligst les eksemplet på detaljene vist ovenfor.
• ah ja. Betydelig

Jeg vil gi mine 2 cent her, ved å forklare forholdet mellom sannsynligheten for å utvinne en blokk gitt det nåværende målet t og den tilsvarende vanskeligheten d som det beregnes i bitcoin-kjerne.

Så kryptografiske hashfunksjoner blir idealisert ved den tilfeldige orakelabstraksjonen [ https://en.wikipedia.org/wiki/Random_oracle] . Vi kan derfor modellere utgangen av doubleSHA256 hash-funksjonen som brukes i PoW som en ensartet variabel i mellomrommet {0,1}^256, dvs. matriser på 256 bits . Dermed er sannsynligheten for at en enkelt hash h er en gyldig hash:

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

På den annen side d beregnes som følger, akkurat som @gary forklarte før bare transformert til desimaler:

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, funksjon GetDifficulty. Egentlig hvis noen kan forklare hvordan koden tilordnes nøyaktig til formelen ovenfor, vil det være nyttig. Ved å kombinere de to formlene vi får:

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

Analysering av dette siste uttrykket er vanskeligheten forholdet mellom sannsynligheten for å oppnå en hash lavere enn 2^{224} (som er det laveste desimaltallet som har en binær representasjon ved bruk av 256 bits som begynner med 32 nullbiter) og sannsynligheten for å oppnå en gyldig hash basert på gjeldende mål t. Dette er en direkte implikasjon av å definere, i genese-blokken, som vanskelighetsgrad 1 den som er knyttet til det heksadesimale målet 0x1d00ffff , uttrykt i det jeg tror kalles 32-biters kompakt form for 256-bits tall.

A fint spørsmål tror jeg er hvorfor denne spesifikke kompakte formen ble valgt for å representere målet.

Kommentarer

• Oppstemt! Den kompakte formen gir 3 mest betydningsfulle byte for målet, i min vanskelighetsgrad er de 3 mest betydningsfulle byte 00ffff.