Add a comment explaining the use of MAX_BLOCK_BASE_SIZE. #10608
pull gmaxwell wants to merge 1 commits into bitcoin:master from gmaxwell:size_comment changing 1 files +7 −1-
gmaxwell commented at 0:47 am on June 16, 2017: contributor
-
Add a comment explaining the use of MAX_BLOCK_BASE_SIZE. 18873373bd
-
fanquake added the label Docs and Output on Jun 16, 2017
-
instagibbs commented at 1:22 am on June 16, 2017: memberso
network rule
here actually means “network consensus rule”? I misunderstood when I read this before. -
in src/consensus/consensus.h:19 in 18873373bd
11@@ -12,7 +12,13 @@ 12 static const unsigned int MAX_BLOCK_SERIALIZED_SIZE = 4000000; 13 /** The maximum allowed weight for a block, see BIP 141 (network rule) */ 14 static const unsigned int MAX_BLOCK_WEIGHT = 4000000; 15-/** The maximum allowed size for a block excluding witness data, in bytes (network rule) */ 16+/** 17+ * The maximum allowed size for a block excluding witness data, in bytes (network rule). 18+ * This parameter is largely superfluous because it is directly implied by the above block 19+ * weight limit, even when BIP 141 is not active. It continues to exist for use in 20+ * various early tests that run before the witness data has been checked.
practicalswift commented at 4:17 am on June 16, 2017:Minor nit: Accidental double spaces after*
on the two lines above.
gmaxwell commented at 5:30 am on June 16, 2017:intentional indentation
practicalswift commented at 7:39 am on June 16, 2017:Just out of curiosity, why the indentation? :-)
benma commented at 1:32 pm on June 16, 2017:“tests” is overloaded and could be confused for unit/integration tests. “early checks” might be better.
Why are those checks not removed if they don’t change the rules? Would be good to mention the reason for it also here.
practicalswift commented at 8:09 pm on June 16, 2017:After re-reading the diff I think I get it: the indentation is to clarify that the current line is part of the sentence of the line above.
gmaxwell commented at 11:36 pm on June 16, 2017:There are many early checks in validation which limit the resources used handling invalid things or avoid incorrect invalidation in the presence of malleability. Most of them explain themselves.
E.g. in this case you cannot check the weight limit until after you’ve verified the witness commitment, which takes a bunch of hashing– otherwise you might invalidate a block you received with an tampered witness (take a valid block add another 2mb of junk to one of the witnesses) instead of just dropping it and the party that gave it to you. But you can check the base size before doing that.
practicalswift commented at 4:22 am on June 16, 2017: contributorACK 18873373bde38a026f154c5878fedac6c2a04446 modulo clarification of “network rule” vs “network consensus rule” as suggested by @instagibbsgmaxwell commented at 5:31 am on June 16, 2017: contributor@instagibbs if you decrease it below a million you will break consensus. If you remove it entirely you will not, or set it to eleven million you will not. It’s a consensus rule but a redundant one which is subsumed by weight.
Do you see a way to make that more clear?
laanwj merged this on Jun 24, 2017laanwj closed this on Jun 24, 2017
laanwj referenced this in commit eee398fa12 on Jun 24, 2017theStack referenced this in commit a00f02e2f2 on Jul 1, 2021theStack referenced this in commit e26ad3b39c on Jul 1, 2021theStack referenced this in commit 607076d01b on Jul 3, 2021MarcoFalke referenced this in commit b620b2d58a on Aug 2, 2021DrahtBot locked this on Sep 8, 2021
gmaxwell instagibbs practicalswift benma laanwjLabels
Docs
This is a metadata mirror of the GitHub repository bitcoin/bitcoin. This site is not affiliated with GitHub. Content is generated from a GitHub metadata backup.
generated: 2024-12-24 12:12 UTC
More mirrored repositories can be found on mirror.b10c.me