Blocksize: Some small preparations for a blocksize hardfork #7238

pull jtimon wants to merge 2 commits into bitcoin:master from jtimon:6526-6625-remainings-0.13.99 changing 6 files +24 −17
  1. jtimon commented at 7:05 am on December 21, 2015: contributor
    Replaces #6625 (contains commits from #6526).
  2. consensus: don't define MAX_STANDARD_TX_SIGOPS in terms of block size 0e2977a0f4
  3. consensus: teach ExtractMatches to check for an arbitrary max transaction number
    This is a no-op change. For now, everything passes MAX_BLOCK_SIZE / 60, so the
    result matches what it would've before.
    
    Tests use a number equal to the number of transactions where necessary,
    to ensure that they're never rejected when blocksizesize isn't being tested.
    8e2adc8c1c
  4. maaku commented at 7:22 am on December 21, 2015: contributor
    What’s the reasoning for nMaxTransactions?
  5. jtimon commented at 7:40 am on December 21, 2015: contributor
    More flexibility in the code for when MAX_BLOCK_SIZE is no longer a constant.
  6. maaku commented at 9:46 am on December 21, 2015: contributor
    Perhaps my question wasn’t clear – why limit the number of transactions at all? We should probably do overflow checks (which would mean a real limit of 4 billion transactions), but I’m not sure why this would ever be a purposefully, further constrained parameter.
  7. jtimon commented at 10:10 am on December 21, 2015: contributor
    I guess another option would be to just replace MAX_BLOCK_SIZE / 60 with a static constant in merkleblock.cpp. What you are saying is that changing that constant to a huge value wouldn’t be a hardfork and it’s therefore easier to just decouple merkleblock.cpp from MAX_BLOCK_SIZE, correct?
  8. maaku commented at 7:07 am on December 22, 2015: contributor
    That check is really just a sanity check, and IMHO shouldn’t be there as Merkle trees are used for other purposes. There is no reason to explicitly limit the number of transactions, and a generic merkle tree validator shouldn’t have such a limitation built into it.
  9. jtimon commented at 10:07 am on December 23, 2015: contributor
    Ok, so you suggest to just remove the check then?
  10. jtimon closed this on Jan 7, 2016

  11. DrahtBot locked this on Sep 8, 2021


jtimon maaku


github-metadata-mirror

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-19 00:12 UTC

This site is hosted by @0xB10C
More mirrored repositories can be found on mirror.b10c.me