Bitcoin Forum
July 09, 2024, 01:51:53 PM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: [1]
  Print  
Author Topic: Bits field vs actual difficulty?  (Read 205 times)
FlatPepsi (OP)
Newbie
*
Offline Offline

Activity: 8
Merit: 1


View Profile
July 16, 2018, 03:55:34 PM
 #1

In BTC, each block has a Bits field with a rounded representation of the actual difficulty, which was calculated from the last 2-week adjustment.

Why do blocks have this Bits field in it?
Everything else about blocks feels like they are calculated whenever possible, keeping things compact with no redundant data.

Doesn't having a less precise version of the true difficulty cause problems?  What happens when a new block is generated, which is valid according to Bits, but is not good enough to meet the true difficulty?

I am confuse.
odolvlobo
Legendary
*
Offline Offline

Activity: 4368
Merit: 3287



View Profile
July 17, 2018, 08:18:35 AM
Last edit: July 17, 2018, 08:40:45 AM by odolvlobo
 #2

The actual value that must be achieved is the "target" as represented in the "compact" form. When the next target value is computed, the result of the computation is converted to the compact form to get the actual value that is used. The difficulty is derived from the target.

I don't know why the target is stored in the block header, since it must be computed for validation anyway and it doesn't vary.

Join an anti-signature campaign: Click ignore on the members of signature campaigns.
PGP Fingerprint: 6B6BC26599EC24EF7E29A405EAF050539D0B2925 Signing address: 13GAVJo8YaAuenj6keiEykwxWUZ7jMoSLt
Evil-Knievel
Legendary
*
Offline Offline

Activity: 1260
Merit: 1168



View Profile
July 17, 2018, 01:23:51 PM
 #3

In BTC, each block has a Bits field with a rounded representation of the actual difficulty, which was calculated from the last 2-week adjustment.

Why do blocks have this Bits field in it?
Everything else about blocks feels like they are calculated whenever possible, keeping things compact with no redundant data.

Doesn't having a less precise version of the true difficulty cause problems?  What happens when a new block is generated, which is valid according to Bits, but is not good enough to meet the true difficulty?

I am confuse.


The nBits represents the true difficulty.

The reason why it is stored in every block is, that you only need the previousBlock of your current block to verify whether the block meets the target and the target claimed is actually valid. This makes the POW check really inexpensive. Otherwise, without the nBits, you would have to do some fancy "retrospective replay of 2016 blocks into the past" to calculate the current difficulty on demand. How else would you know the difficulty if you didn't go through all last 2016 blocks and calculated how long it took them to mine?

Kallisteiros
Copper Member
Member
**
Offline Offline

Activity: 85
Merit: 122


View Profile
July 17, 2018, 02:56:06 PM
 #4

Also curious, specifically about where it would prove useful. Even SPV wallets download all block headers and are perfectly able to calculate the difficulty on their own, given the starting difficulty. Seems more like a redundant field left for historical compatibility purposes?
SoManyQuestions9
Newbie
*
Offline Offline

Activity: 1
Merit: 0


View Profile
July 19, 2018, 12:35:01 PM
 #5

Only reason I can think of is that you don't have to compute it when starting up a new node.
 Problem is, if you rely on this field him alone you'll be wrong 1 time out of 2016 - a lazy miner will be using an out of date difficulty, and risk getting an invalid block.

Thinking deeper, shouldn't every miner have the full block chain anyway?  How can a miner correctly validate incoming new blocks without knowing the actual computed difficulty?

Satosi spent so much time & work keeping the blocks efficient, this seems out of place.
 
Kallisteiros
Copper Member
Member
**
Offline Offline

Activity: 85
Merit: 122


View Profile
July 21, 2018, 12:25:08 PM
Merited by odolvlobo (1), ABCbits (1)
 #6

Quote
Thinking deeper, shouldn't every miner have the full block chain anyway?
They must, if only for the validation of incoming transactions. And not only miners. Everyone downloads at least all block headers, even light SPV wallets.

Quote
Satosi spent so much time & work keeping the blocks efficient, this seems out of place.
Well, no data structures and algorithms are perfect, neither are people who design them. For example, you mentioned the difficulty adjustment period of 2016 blocks before, but it's actually 2015, because of off-by-one mistake in the code, which has been left untouched to not ruin consensus, but causing the difficulty to always adjust 0.05% higher than it objectively is.

But I still feel like there might be a use case here. Maybe it's for independent validation of any block, of the hashing power spent generating it? Since you can't deduce difficulty just from the number of leading zeroes in block hash (a miner can accidentally discover a hash with many more zeroes, but it doesn't mean that that's the difficulty he was aiming for, nor does it mean that it should now have a role in difficulty calculations). Where would it be useful though?
Pages: [1]
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!