• 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
      CPU-miner.
    
    * 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
    2aa462f8
TxValidation.cpp 24.3 KB