|
Title: Bits field vs actual difficulty? Post by: FlatPepsi on July 16, 2018, 03:55:34 PM 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. Title: Re: Bits field vs actual difficulty? Post by: odolvlobo on July 17, 2018, 08:18:35 AM 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. Title: Re: Bits field vs actual difficulty? Post by: Evil-Knievel on July 17, 2018, 01:23:51 PM 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? Title: Re: Bits field vs actual difficulty? Post by: Kallisteiros on July 17, 2018, 02:56:06 PM 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?
Title: Re: Bits field vs actual difficulty? Post by: SoManyQuestions9 on July 19, 2018, 12:35:01 PM 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. Title: Re: Bits field vs actual difficulty? Post by: Kallisteiros on July 21, 2018, 12:25:08 PM 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? |