This PR is connected with the timewarp fix part of the BIP: By further
restricting nTime fields on difficulty adjustment blocks, we propose fixing
the long-standing âtimewarpâ inflation vulnerability in Bitcoinâs difficulty
adjustment without risking existing mining hardware becoming unusable. This
limits the worst-case difficulty adjustment target in case of attack from the
current exponential growth, to once every roughly 600 seconds.
The expected time period of 2016 blocks (one retargetting period) isnât
exactly two weeks. See this thread from Pieter
Wuille on why exactly
that is.
The PR doesnât enforce that consensus change. Rather, it changes the mining
behaviour of a Bitcoin Core node to be compliant with the proposed changes.
There are two changes:
One to getblocktemplate (the RPC that a miner calls in order to get a
template block to work on). This PR changes the returned mintime
field returned by getblocktemplate, such that if the next block is a
difficulty adjustment block, it is constrained by the prev-600 rule.
One to UpdateTime(), which is called when creating a new block (either
for mining on the node for regtest, or for getblocktemplate).
At the time of writing, this PR is âChasing Concept ACKâ. That means that
we want contributors to review the concept before reviewing the implementation.
Questions
What could a miner do by abusing the timestamp field in a difficulty adjustment
block prior to the Great Consensus Cleanup change?
After the Great Consensus Cleanup change, what can a miner do by abusing the
block timestamp?
Why not just enforce that difficulty adjustment blocks to have a timestamp after
the previous block, rather than after prev-600?
Which function would need to be changed to enforce this timestamp restriction
as a consensus rule?
The curtime return value of getblocktemplate is now constrained by the
prev-600 rule. Why?
<jnewbery> I'd encourage everyone to spend at least a few minutes preparing before the meeting by reading the notes. It'll really increase the benefit you get from the meeting if you come with questions prepared.
<jnewbery> pinheadmz: What could a miner do by abusing the timestamp field in a difficulty adjustment block prior to the Great Consensus Cleanup change?
<jnewbery> that makes it appear to the retarget algorithm that it took a long time for the prior retarget period, so difficulty stays low or is adjusted down
<pinheadmz> can we clarify which blocks by # ? Like, block 2015 (the ACTUAL last block for retarget algo) is the one thats post-dated 2 hours into the future?
<lightlike> jnewbery: "way in the future": is it possible, i read somewhere that you cannot go more than 2 hours into the future with the current rules?
<jnewbery> lightlike: correct, so you couldn't use this attack at the tip, but you could redo a blockchain from genesis that does this because you have 10 years to play with
<jnewbery> (in fact there are stome checkpoints, so you could only do it from block 295,000 if you wanted your blockchain to be accepted by Bitcoin Core)
<jnewbery> so the retarget algorithm compares the timestamp of block 2016 with block 1 and thinks "hmmm, it took 2 weeks to mine these blocks, keep difficulty at 1"
<jnewbery> so in summary: it allows someone to create arbitrarily long blockchains without the difficulty increasing. The Median Time Passed of the blockchain creeps forward slowly, but one block out of every 2016 is sent forward in time to artificially keep the difficulty down
<fl> ariard: using the node's local clock, it increases the attack surface from inaccurate time attestations in blocks to requiring the persistent manipulation of timeserver/nodes' local time
<lightlike> jnewbery: why would other nodes accept the longer blockchain? I thought the one with the most cumulated work is accepted, not with the largest block count.
<fl> jnewbery wouldn't a timewarped fork chain require an eclipse attack to prevent nodes from learning about a non attacking chain? or is the desire just to make controlled supply more metered?
<jnewbery> lightlike: correct, so the full attack would be: I control 51% of the mining power, so I can create a chain with more work than anyone else. I do that, but also use timeward to make that most-work chain really long
<jnewbery> I created a 500,000 long mainnet blockchain by starting at genesis with an S7 a few years ago. At the time I believe it was the longest mainnet Bitcoin blockchain (but not most work, obviously)
<nehan> jnewbery: i still don't understand why, in your example, other nodes would accept block 2016 (its timestamp is far in the future) but i am happy to take it offline
<ariard> fl: yes on increasing the attack surface to require the persistent manipulation of timeserver but I wonder if eclipse attacks can destroy this assumption and instead relying on public data wouldn't be better...
<jnewbery> ariard fl: assuming your peer is on the most work tip, and your spoofed chain is below block 295,000, it wouldn't accept the headers because of the checkpoint
<pinheadmz> Is there any way timewarp can benefit one single attacker? Seems like it lowers difficulty for EVERYONE, doesn't give one party a specific advantage
<jnewbery> if you want to use timewarp to ratchet down the difficulty, you still need to get to the next difficulty retarget block after 295000, and then you can only lower it by 75%
<fl> jnewbery the resource consumption on a spoof timewarp chain is negligible but in your case where 51% miner stretches out the chain, they could start stuffing more and more data into blocks increasing node operation costs more
<jnewbery> nehan: because the aim of this PR is to make miners not mine a difficulty retarget block more than 600 seconds before the prior block. When the miner callers GBT we want the block template returned to them to have a timestamp that is constrained by that rule
<jnewbery> Anyone brave enough to try to answer "Which function would need to be changed to enforce this timestamp restriction as a consensus rule?" :)
<hugohn> q: what happens if there is a large hashrate drop between the second-to-last block and the last block in a period (so the gap between those 2 blocks is truly more than 2 minutes)? Won't this change make it so that we won't account for this hash rate drop in retargeting? then that means the next period's difficulty will be a lot longer than it has to be?
<jnewbery> I'm out of office and won't make the next couple of review clubs. I'm going to try to find someone else to host, so keep an eye out on the website for details.
<jnewbery> jonatack: I believe Matt has some updates to make to his consensus cleanup proposal. I'm going to hold off on concept reviewing until after that