MAX_BLOCK_BASE_SIZE
#22378
MAX_BLOCK_BASE_SIZE from the core implementation about four years ago (see also #10608 in why it was considered confusing and superfluous).
Since there is also no point in still keeping it in the functional test framework, the PR switches to weight-based accounting on the relevant test code parts and use MAX_BLOCK_WEIGHT instead for the block limit checks. To prepare that, the first two commits introduce get_weight() helpers for the classes CTransaction and CBlock, respectively.
501@@ -502,7 +502,7 @@ def run_test(self):
502 # Make sure we didn't accidentally make too big a block. Note that the
503 # size of the block has non-determinism due to the ECDSA signature in
504 # the first transaction.
505- while (len(b39.serialize()) >= MAX_BLOCK_BASE_SIZE):
506+ while (b39.get_weight() >= MAX_BLOCK_WEIGHT):
()
339+ script_length = (MAX_BLOCK_WEIGHT - b24.get_weight() - 276) // 4
340 script_output = CScript([b'\x00' * (script_length + 1)])
341 tx.vout = [CTxOut(0, script_output)]
342 b24 = self.update_block(24, [tx])
343- assert_equal(len(b24.serialize()), MAX_BLOCK_BASE_SIZE + 1)
344+ assert_equal(b24.get_weight(), MAX_BLOCK_WEIGHT + 1 * 4)
bytes in the scriptSig count for 4 weight units.
Not sure, but it might be possible to pad the scriptWitness to get exactly +1 weight unit
MAX_BLOCK_WEIGHT + 4 is the smallest over-weight block you can reach if you only change non-witness data (as in this test scenario, the scriptPubKey), as every byte added increases the block weight by 4 WU
(What you probably meant was (MAX_BLOCK_BASE_SIZE + 1) * 4 but that constant doesn’t exist anymore in this PR :))
@MarcoFalke: yes I guess it’s possible to reach exactly MAX_BLOCK_WEIGHT+1 by tweaking the witness. Didn’t want to change too much of the surrounding logic though, can be done in a follow-up I guess. E.g. adding test coverage for the rejection state bad-blk-weight is on my TODO list, it could be appropriate to include it in such a PR.
The constant `MAX_BLOCK_BASE_SIZE` has been removed from the
core implementation years ago due to being confusing and
superfluous, as it is implied by the block weight limit (see
PRs #10618 and #10608). Since there is also no point in
still keeping it in the functional test framework, we switch
to weight-based accounting on the relevant test code parts
and use `MAX_BLOCK_WEIGHT` instead for the block limit
checks.
The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.
Reviewers, this pull request conflicts with the following ones:
If you consider this pull request important, please also help to review the conflicting pull requests. Ideally, start with the one that should be merged first.
Concept Ack!
Since the core codebase does not use MAX_BLOCK_BASE_SIZE anymore, it makes sense to update our test implementations too accordingly.
Replacing them with MAX_BLOCK_WEIGHT just like we did in the codebase is the appropriate approach to make our tests more relevant to the core
Reviewed the codebase too! Merging this PR will remove the existence of MAX_BLOCK_BASE_SIZE entirely from the codebase.
review ACK 607076d01bf23c69ac21950c17b01fb4e1130774 🚴
Signature:
0-----BEGIN PGP SIGNED MESSAGE-----
1Hash: SHA512
2
3review ACK 607076d01bf23c69ac21950c17b01fb4e1130774 🚴
4-----BEGIN PGP SIGNATURE-----
5
6iQGzBAEBCgAdFiEE+rVPoUahrI9sLGYTzit1aX5ppUgFAlwqrYAACgkQzit1aX5p
7pUhangv/fJc3Jt7y5CNtkgkk5wpM7WvrVo7kr5id3uDLFwc4XvV/+tu46Lj8wKnM
8VaKCogYIZUfDY0ybaQTPWUQsc7mRsCQHCZrzdqULXKlgilkbptrtw2Hnib5Yji/V
9z8i55R4h27Vz9/+TnTQnoIVnN2yJb74ZDOhIplt+9EK8jsQlIpVSwvTd6jzybqfB
10feKe5yfWdVXBa2Wt+7vI8jLB657ImRRpNjo0vmzsYV8dBKO69M6bLOFCyZyJI4vR
11d/yV6Oz5mqBH3IE+k1yc+A9C1HDs7RTOk8Br9rAFF6l3GIRW5FZpojAHo6C52XGT
12/uVcpiHj+KOkgQCsKDOsyULt+d64KVbXpyTm/ZBrtMsPiyWz3pf5sAaIFPKlJbbY
13rCPJOz4BisFWea7r4SJnGRNzIn6AW5WAPTMkGhmBzbrp11sbGC43pavGyWlVXAkv
14d2Lzhx6uzWSZMPdcyrF2tSMTt27iMpGt6yiTSVe5akPurgtlPtEP5K7rU3AadT+Y
159XhNZRKq
16=6Hi6
17-----END PGP SIGNATURE-----
Timestamp of file with hash ed68a39acc95435083178c51bd7a5f00064c323a9eb72384644b3c4b2d16a9a6 -