Compare commits

...

4 commits

Author SHA1 Message Date
Sjors Provoost
7fcf228fbb
Merge d016d4f6b6 into c5e44a0435 2025-04-29 11:56:18 +02:00
merge-script
c5e44a0435
Merge bitcoin/bitcoin#32369: test: Use the correct node for doubled keypath test
Some checks are pending
CI / macOS 14 native, arm64, fuzz (push) Waiting to run
CI / Windows native, VS 2022 (push) Waiting to run
CI / Windows native, fuzz, VS 2022 (push) Waiting to run
CI / Linux->Windows cross, no tests (push) Waiting to run
CI / Windows, test cross-built (push) Blocked by required conditions
CI / ASan + LSan + UBSan + integer, no depends, USDT (push) Waiting to run
CI / test each commit (push) Waiting to run
CI / macOS 14 native, arm64, no depends, sqlite only, gui (push) Waiting to run
32d55e28af test: Use the correct node for doubled keypath test (Ava Chow)

Pull request description:

  #29124 had a silent merge conflict with #32350 which resulted in it using the wrong node. Fix the test to use the correct v22 node.

ACKs for top commit:
  maflcko:
    lgtm ACK 32d55e28af
  rkrux:
    ACK 32d55e28af
  BrandonOdiwuor:
    Code Review ACK 32d55e28af

Tree-SHA512: 1e0231985beb382b16e1d608c874750423d0502388db0c8ad450b22d17f9d96f5e16a6b44948ebda5efc750f62b60d0de8dd20131f449427426a36caf374af92
2025-04-29 09:59:42 +01:00
Ava Chow
32d55e28af test: Use the correct node for doubled keypath test 2025-04-28 14:44:17 -07:00
Sjors Provoost
d016d4f6b6
test: clarify timewarp griefing attack
On testnet4 with the timewarp mitigation active, when pool software
ignores the curtime and mintime fields provided by the getblocktemplate
RPC or by createNewBlock() in the Mining interface, they are vulnerable
to a griefing attack.

The test is expanded to illustrate this.
2025-02-12 10:18:41 +01:00
2 changed files with 45 additions and 15 deletions

View file

@ -36,6 +36,7 @@ from test_framework.p2p import P2PDataStore
from test_framework.test_framework import BitcoinTestFramework
from test_framework.util import (
assert_equal,
assert_greater_than,
assert_greater_than_or_equal,
assert_raises_rpc_error,
get_fee,
@ -194,26 +195,45 @@ class MiningTest(BitcoinTestFramework):
self.log.info("Mine until the last block of the retarget period")
blockchain_info = self.nodes[0].getblockchaininfo()
n = DIFFICULTY_ADJUSTMENT_INTERVAL - blockchain_info['blocks'] % DIFFICULTY_ADJUSTMENT_INTERVAL - 2
t = blockchain_info['time']
wall_time = blockchain_info['time']
for _ in range(n):
t += 600
self.nodes[0].setmocktime(t)
wall_time += 600
node.setmocktime(wall_time)
self.generate(self.wallet, 1, sync_fun=self.no_op)
self.log.info("Create block two hours in the future")
self.nodes[0].setmocktime(t + MAX_FUTURE_BLOCK_TIME)
self.log.info("Create block MAX_TIMEWARP < t <= MAX_FUTURE_BLOCK_TIME in the future")
# A timestamp that's more than MAX_TIMEWARP seconds in the future can
# happen by accident, due to a combination of pool software that doesn't
# use "curtime" AND has a faulty clock.
#
# But it could also be intentional, at the end of a retarget period, in
# order to make the next block miner violate the time-timewarp-attack rule.
# For this attack to succeed the victim miner needs to ignore both our
# "curtime" and "mintime" values AND use wall clock time. This is true even
# if the victim miner implements the MTP rule.
#
# The attack is illustrated below.
#
# The attacker produces a block with a timestamp in the future:
future = wall_time + 1000
# This is an arbitrary time, far enough in the future that it triggers the
# timewarp rule, but not so far in the future that it won't get relayed.
assert_greater_than(future, wall_time + MAX_TIMEWARP)
assert_greater_than_or_equal(wall_time + MAX_FUTURE_BLOCK_TIME, future)
node.setmocktime(future)
self.generate(self.wallet, 1, sync_fun=self.no_op)
assert_equal(node.getblock(node.getbestblockhash())['time'], t + MAX_FUTURE_BLOCK_TIME)
assert_equal(node.getblock(node.getbestblockhash())['time'], future)
self.log.info("First block template of retarget period can't use wall clock time")
self.nodes[0].setmocktime(t)
# The template will have an adjusted timestamp, which we then modify
node.setmocktime(wall_time)
# The template will have an adjusted timestamp.
tmpl = node.getblocktemplate(NORMAL_GBT_REQUEST_PARAMS)
assert_greater_than_or_equal(tmpl['curtime'], t + MAX_FUTURE_BLOCK_TIME - MAX_TIMEWARP)
assert_equal(tmpl['curtime'], future - MAX_TIMEWARP)
# mintime and curtime should match
assert_equal(tmpl['mintime'], tmpl['curtime'])
# Check that the adjusted timestamp results in a valid block
block = CBlock()
block.nVersion = tmpl["version"]
block.hashPrevBlock = int(tmpl["previousblockhash"], 16)
@ -224,19 +244,29 @@ class MiningTest(BitcoinTestFramework):
block.solve()
assert_template(node, block, None)
# Use wall clock instead of the adjusted timestamp. This could happen
# by accident if pool software ignores mintime and curtime.
bad_block = copy.deepcopy(block)
bad_block.nTime = t
bad_block.nTime = wall_time
bad_block.solve()
assert_raises_rpc_error(-25, 'time-timewarp-attack', lambda: node.submitheader(hexdata=CBlockHeader(bad_block).serialize().hex()))
# It can also happen if the pool implements its own logic to adjust its
# timestamp to MTP + 1, but doesn't take the new timewarp rule into
# account (and ignores mintime).
mtp = node.getblock(node.getbestblockhash())["mediantime"]
bad_block.nTime = mtp + 1
bad_block.solve()
assert_raises_rpc_error(-25, 'time-timewarp-attack', lambda: node.submitheader(hexdata=CBlockHeader(bad_block).serialize().hex()))
self.log.info("Test timewarp protection boundary")
bad_block.nTime = t + MAX_FUTURE_BLOCK_TIME - MAX_TIMEWARP - 1
bad_block.nTime = future - MAX_TIMEWARP - 1
bad_block.solve()
assert_raises_rpc_error(-25, 'time-timewarp-attack', lambda: node.submitheader(hexdata=CBlockHeader(bad_block).serialize().hex()))
bad_block.nTime = t + MAX_FUTURE_BLOCK_TIME - MAX_TIMEWARP
bad_block.solve()
node.submitheader(hexdata=CBlockHeader(bad_block).serialize().hex())
block.nTime = future - MAX_TIMEWARP
block.solve()
node.submitheader(hexdata=CBlockHeader(block).serialize().hex())
def test_pruning(self):
self.log.info("Test that submitblock stores previously pruned block")

View file

@ -87,7 +87,7 @@ class BackwardsCompatibilityTest(BitcoinTestFramework):
# 0.21.x and 22.x would both produce bad derivation paths when topping up an inactive hd chain
# Make sure that this is being automatically cleaned up by migration
node_master = self.nodes[1]
node_v22 = self.nodes[self.num_nodes - 5]
node_v22 = self.nodes[self.num_nodes - 3]
wallet_name = "bad_deriv_path"
node_v22.createwallet(wallet_name=wallet_name, descriptors=False)
bad_deriv_wallet = node_v22.get_wallet_rpc(wallet_name)