mining: Optimise for typical mining use with blockmaxsize #8386

1. 
   luke-jr commented at 5:01 pm on July 21, 2016: member
2. mining: Optimise for typical mining use with blockmaxsize 3092829809
3. jonasschnelli added the label Mining on Jul 21, 2016
4. 
   morcos commented at 6:38 pm on July 21, 2016: member

   Can you quantify the benefit of doing this? I don’t think we should be keeping around extra fields without being sure its really worth it. Will any significant number of miners use this instead of blockmaxweight? In any case this is redundant with blockmaxweight until segwit is activated, so we should defer discussion of adding it until then.
5. 
   luke-jr commented at 7:06 pm on July 21, 2016: member

   All miners should be using blockmaxsize, not blockmaxweight, right now and until some future change makes blocks larger than 1 MB sane. It’s not redundant on testnet, and if it were redundant, we should remove the weight stuff, not size…
6. 
   morcos commented at 1:53 pm on July 25, 2016: member

   @luke-jr I don’t think we’re concerned about block size on test net.

   By quantifying the benefit what I meant was miners can already use blockmaxsize if they want to (although I would recommend they not), all this pull does is cache the necessary calculations. Can you quantify the benefit of doing that instead of the status quo?

7. 
   luke-jr commented at 2:43 pm on July 25, 2016: member

   Miners should not be recommended to disable blockmaxsize, since size is currently the critical constraining resource on the network. It’s true that switching to blockmaxweight in 0.13.0 won’t have any practical difference on mainnet, but when segwit gets activated, it will, and it is TBD whether producing blocks larger than 1 MB will be responsible at that time.
8. 
   f139975 commented at 5:12 pm on July 27, 2016: none

   @luke-jr: please provide a description, when opening a pull request.

   To quote CONTRIBUTING.md#contributor-workflow:

   The body of the pull request should contain enough description about what the patch does together with any justification/reasoning.

9. 
   luke-jr commented at 4:04 am on August 27, 2016: member

   #8559 says 576MiB per day = ~17GB per Month is too high; if this is correct, it will be important for miners to set a maxblocksize of at most 2 MB.
10. 
    luke-jr commented at 4:19 am on October 3, 2016: member

    This should probably be tagged for 0.13.1…
11. 
    morcos commented at 12:49 pm on October 3, 2016: member

    I recently looked into this because I was worried about the default (passing no options) still using size accounting and this being potentially slow after segwit activates. I tried to estimate how slow this might be by setting a blockmaxsize=950000 and blockmaxweight=4000000 which should cause the mining algorithm to have to trace each package adding up size all the way through the mempool. I found that this was only slightly slower than just setting blockmaxweight. 12ms average vs 10.5ms.

    I believe we should not do any extra work to support size accounting at this point, but that it is fine to leave it in the code and not a significant performance concern until we can all agree that there is no reason to keep the extra complication around.

12. luke-jr closed this on Oct 3, 2016

    ---

13. 
    sipa commented at 1:21 pm on October 3, 2016: member

    @morcos Thanks for benchmarking this - always better to have actual numbers.
14. MarcoFalke locked this on Sep 8, 2021

Contributors
luke-jr morcos f139975 sipa

Labels
Mining