Bitcoin Q&A: Difficulty Targeting and the "Death Spiral" - YouTube

Channel: aantonop

[0]
Gabriel asks, "Is it a rule of Bitcoin, or an average number based on computation power,
[6]
that blocks are formed every ten minutes or so?"
[11]
Both. It is a rule of Bitcoin that the [difficulty target], based on [the] computation [power of the network],
[18]
forms blocks every ten minutes.
[20]
The rule in Bitcoin is [about] the difficulty of doing the calculation, which is adjusted every two weeks.
[27]
The average number of blocks in a period of time [will] equal a block about every ten minutes.
[36]
The way this works is, over a period of two weeks, there should be 2016 blocks [mined].
[42]
Therefore, we can count [blocks from] the previous two weeks, and if the answer is exactly 2016,
[50]
that means the difficulty of [solving the proof-of-work] algorithm and the amount of [hash power that miners]...
[56]
are committing to Bitcoin mining, is perfect.
[61]
Blocks are coming out every ten minutes, [so there is] nothing to adjust.
[64]
Let's say that instead of 2016 blocks, we had 2,217 blocks, or effectively 10% more blocks.
[76]
The network [would adjust] the difficulty [to be] 10% [more difficult],
[82]
the same ratio as the [percentage] of extra blocks we had versus the number of blocks we should have.
[91]
If that difference is 10%, then the difficulty target will be adjusted by 10%.
[96]
As a result, we will be closer to ten-minute blocks in the future.
[101]
If instead of 2016 blocks, we had 1,814 blocks [and were] two hundred blocks or 10% short,
[112]
we would adjust by about 10% in the difficulty target.
[115]
That calculation happens every two weeks, at exactly the same block,
[122]
and affects the difficulty of the next block across the entire network [of nodes].
[126]
Every computer in the network [counts] the number of blocks it saw over the last two weeks,
[134]
measures [the amount of time between them], adjusts the difficulty by the same amount,
[138]
and arrives at the same answer, as the entire network switches [the difficulty target].
[144]
For the exact same amount, every two weeks.
[155]
Jimmy has a great question.
[157]
"Is it possible that the blockchain will not proceed or propagate because we come to a point where...
[163]
the difficulty required cannot be satisfied anymore, in all the iterations of the nonce and extraNonce?"
[172]
Yes. In fact, that has already happened. We have the extraNonce because we [once reached] a point...
[180]
where the difficulty could not be satisfied in the nonce.
[184]
So extraNonce had to be [appended as a field of the coinbase transaction].
[187]
There are a number of other things in the block header that can be changed to produce more variation.
[194]
The most important one, interestingly enough, is the order and types of the transactions [a miner] includes.
[202]
Let's say you have 2,000 transactions in your block.
[209]
These transactions were received and put into the candidate block in a specific order.
[217]
Because of the order of the transactions in the block, they [will] produce a specific Merkle tree.
[226]
Each pair of transactions -- first and second, third and fourth, then fifth and sixth -- are hashed together.
[238]
Then those hashes are hashed together, etc. until you get to the Merkle root of the tree.
[245]
It is a binary tree. If you change [even] two transactions at the bottom of the tree, or reverse the order,
[253]
the calculation all the way up changes and you [will] get a different Merkle root.
[260]
Effectively, that is like changing a nonce. You have changed the block header.
[264]
All you did was flip two transactions around and re-calculate the Merkle root.
[270]
With 2,000 transactions in the block, there are a lot of [possible] combinations [in which to] order those.
[275]
to produce all kinds of variety in the Merkle root.
[280]
Re-ordering transactions is one of the ways miners can vary the block header...
[287]
when they run out of nonce and extraNonce.
[290]
That [could] already [be] happening [with covert] ASICBoost, which is a particular shortcut [involving]...
[300]
[finding a collision in the last 4 bytes of the Merkle root;]
[303]
[overt "version-rolling" ASICBoost only changes the version field in the block header].
[305]
The point [that matters is] you can still satisfy the difficulty by varying other parts of the block header.
[315]
It is very likely that, over the next few years, we [will] see a change in the format of the block header.
[321]
One of the things that [will] change in the format of the block header is more space for a bigger nonce,
[331]
There is no reason why that can't be done again, to increase the [potential] amount of difficulty.
[344]
The amount of nonce required can be satisfied. That is not a problem [for Bitcoin].
[350]
M.J. asks about the Bitcoin "death spiral."
[356]
"Some believe that a combination of economic [and political] factors, such as a crashing bitcoin price...
[361]
[or] governments outlawing mining, could cause a sudden and sustained reduction in hash power."
[370]
"What threat would this pose to Bitcoin? Could it cause a 'death spiral,' as some fear (or hope)?"
[377]
The "death spiral" phenomenon is this:
[379]
[The difficulty] is not calculated based on time, but [on the number of blocks], every 2016 blocks [mined].
[385]
Let's assume that [hash power] drops dramatically, with only 50% of miners [still] participating.
[394]
Blocks [would be issued] every twenty minutes instead of every ten minutes.
[399]
Because [block issuance] is twenty minutes instead of ten minutes, it [will take longer than] two weeks...
[404]
to recalculate the difficulty and adjust [the average block time] back to ten minutes.
[407]
It will [be] four weeks [before the next re-targeting]; it will take four weeks for 2016 blocks to be produced.
[415]
A sudden and sustained reduction in hashing power will cause an increase of the time [between each] block.
[423]
which will increase the interval [of time] until the next difficulty re-targeting.
[431]
Of course, some people assume if that happens, then a lot of miners will [leave];
[436]
[that they will say], "I'm not making enough profit anymore because things are moving a lot slower."
[443]
"I will turn off my mining [equipment]," which then causes [hash rate] to drop even further.
[447]
[That makes block issuance even] slower, which causes [more miners to drop out], etc.
[453]
[There is this] death spiral and [difficulty] never adjusts.
[456]
First of all, that is unlikely to happen.
[460]
We have seen that in other blockchains which suffered sudden reductions in [hash power].
[466]
Miners have a much more long-term perspective.
[470]
They have an existing investment in equipment and usually purchase electricity on long-term plans.
[476]
They don't pay for it by the week.
[478]
Therefore, if they have to wait three months to become profitable again,
[483]
and they already have the equipment in place, then they are not turning it off.
[487]
They take a bet that they will return to profitability.
[491]
In fact, if they wait until the re-targeting and difficulty becomes easier, miners who wait make more profit.
[503]
In the new [network distribution], they have a greater percentage of the [hash] power than they did before.
[508]
Let's say the [number of miners] dropped by 50%.
[511]
The miners who stick around and wait for the difficulty re-targeting, are now twice as profitable [afterwards].
[518]
That is a pretty good incentive to stick around.
[521]
The other reason this is unlikely to happen: it assumes, [with such a threat], the rest of the network [will] sit...
[530]
idly by and no changes are made to the protocol.
[533]
Arguably, if you had such a drastic reduction in [hash] power, [such] that the time until the re-targeting...
[541]
was pushed [too] far, one of the [possible solutions] is to change the [difficulty adjustment] algorithm.
[550]
This happened in Bitcoin Cash, where the difficulty [target] was being [adjusted] far too often.
[559]
A hard fork was made to change the difficulty [adjustment] algorithm.
[564]
Changing the algorithm, to make the difficulty be re-targeted sooner, is something that could be done,
[572]
as long as there is a big enough reason and everybody agrees that it must be done.
[577]
You [must] achieve consensus [on the new algorithm] in order to avoid a [network] fork.
[583]
Otherwise, those who disagree, [or aren't coordinating], will end up on a different [chain].
[590]
Arguably, yes, this could [cause a network] fork, but it is more likely that you would have overwhelming support,
[599]
if it becomes a big enough problem.
[602]
I think the term "death spiral" in itself produces this fantastic, dark image.
[610]
It is a very strong, emotionally triggering term [for those who care about Bitcoin].
[614]
People are thinking, "Oh, this is a terrible thing that could happen!"
[619]
But the chances of it happening are low; the chances of nobody doing anything to fix it, are near zero.
[630]
I don't think we have anything to fear from this situation of difficulty re-targeting.
[638]
"Do you think there will ever come a time when the Bitcoin / crypto economy is so large...
[642]
that controlling a proportion of the mining capacity will be considered a central bank responsibility?"
[648]
"Or a national security issue?"
[650]
"For example, where the United States, European Union, China, and Russia would be running state-controlled...
[655]
mining operations and competing against each other."
[659]
"Or do you think mining will remain in the hands of private enterprises, for the foreseeable future?"
[666]
"Or perhaps states will seize privately-owned mining facilities and forcibly take them into public ownership."
[676]
Well, here's the thing...
[680]
There is something to be said about the possibility of state entities taking over private mining facilities...
[688]
and turning them into state-owned enterprises.
[690]
You would think that, because this is a free market,
[695]
where energy use [for] mining can be done [almost] anywhere [that has] usable [energy sources],
[706]
perhaps electricity that is difficult to distribute or delivered in excess of the local demand...
[714]
but can be utilized [by miners]...
[717]
You would think that the distribution of mining would follow free-market principles.
[726]
If [a state] took it over and turned [a private mining operation] into a state-owned enterprise,
[730]
it is extremely likely that a state-owned enterprise would be less efficient than its private counterpart.
[739]
Effectively, the state [would be] sinking a lot of money into building a failed national infrastructure.
[747]
That [might be] okay if the production of electricity wasn't highly monopolistic and state-controlled.
[758]
This isn't a level playing field entirely. There might be some advantages for state entities...
[766]
to nationalize mining, in conjunction with a nationalized energy infrastructure.
[775]
in order to gain some strategic advantage [in the Bitcoin network].
[778]
The strategic advantage in this particular case wouldn't be taking over, changing the rules,
[786]
or trying to interfere with Bitcoin.
[789]
As I mentioned in a previous answer, that would fail so spectacularly and in such a costly fashion.
[795]
However, consider it this way:
[797]
what if [some] national interest would be to maintain the neutrality of the protocol,
[803]
to not allow anyone else to take it over, to [use hash power to] resist attempts to centralize mining?
[815]
That's an interesting possibility; I don't think it is entirely out of the question.
[820]
You might see actors eventually doing large, state-level mining.
[826]
I don't think they [will] be competitive, but they could use control over the energy [sector] to do that.
[834]
I don't know if that is a good thing or a bad thing [for] the cryptocurrency economy.
[839]
I don't think it [would be] a bad thing [if] they have to follow the rules like everybody else.
[844]
If they tried to break the rules, they would face a network-wide change in the proof-of-work algorithm.
[854]
There is always that, the nuclear option.