• Tom Zander's avatar
    Replace SigOps with SigChecks · 2aa462f8
    Tom Zander authored
    This is part of the protocol upgrade for 2020-05-15, and in general it
    seems to go the direction of "we did this before, lets do this again".
    The spec is clear enough, but there is still a lack of questioning and
    testing. The problem this attempts to fix has been neutered for years[1].
    The spec states:
    > The essential idea of SigChecks is to perform counting solely in the
    > spending transaction, and count actual executed signature check
    > operations.
    This, however nobel and logical, ignores that the
    check-for-being-too-costly just pulled in a UTXO lookup and the loading
    of the output script from the historical chain.
    The goal that we protect against CPU over-use may be reached, but the
    price is a total system slowdown. You can have multiple CPUs, but the
    bus to permanent storage has one, max 2 parallel pipes.
    To ensure theHub stays the number one scalable node, I didn't blindly
    follow the spec, while making sure that the Hub is correctly going to
    follow/reject consensus violations of newly mined blocks.
    As a result the implementation in Flowee the Hub:
    * does not check sigcheck-counts on historical blocks (more than 1000
      blocks in the past).
      This may increase the risk of chain-splits ever so slightly, but the cost
      of disk-IO would be too high.
    * No longer stores the value in the mempool, nor uses it for the
    * Ties the sigcheck-limits to the user-set block-size-accept-limit.
      This is contrary to the spec which mistakenly thinks that BCH has a
      max block-size in the consensus rules. The effect is the same, though.
    * The per-intput standardness suggestion is not implemented because
      standardness checks don't currently fetch the previous outputs and
      that would be too expensive to add.
    * Standardness rules for the whole transaction are moved to the
      mempool-acceptance logic instead. The cost would be too great
      otherwise, similar to the previous point.
      Again, the effect is the same as likely intented.
    1) since the intro of the CachingTransactionSignatureChecker
script.cpp 18.3 KB