1. 13 Apr, 2020 2 commits
    • 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
    • Tom Zander's avatar
      Inline CScriptCheck · 0386f38c
      Tom Zander authored
      It was only called twice, and in very close proximity. The class didn't
      add anything.
      This improves readability and with the new state its easier to write
  2. 12 Apr, 2020 2 commits
    • Tom Zander's avatar
      Start sigCheck implementation; actually count them. · 916cb9b5
      Tom Zander authored
      Update Script::State to add a sigCheckCount counter.
    • Tom Zander's avatar
      Refactor ScriptEval/ScriptVerify calls · e101591f
      Tom Zander authored
      Feeling cute, may update this API later.
      namespace Script {
      struct State {
          State() = default;
          State(uint32_t flags) : flags(flags) {}
          uint32_t flags = SCRIPT_VERIFY_NONE; // validation flags
          ScriptError error = SCRIPT_ERR_OK;
          const char* errorString() const;
      bool eval(std::vector<std::vector<unsigned char> > &stack, const CScript
          &script, const BaseSignatureChecker checker, Script::State &state);
      bool verify(const CScript& scriptSig, const CScript& scriptPubKey, const
          BaseSignatureChecker& checker, Script::State &state);
      bool checkTransactionSignatureEncoding(const std::vector<unsigned char>
          &vchSig, State &state);
      More of the same.
  3. 11 Apr, 2020 2 commits
  4. 10 Apr, 2020 6 commits
  5. 08 Apr, 2020 3 commits
  6. 07 Apr, 2020 2 commits
  7. 01 Apr, 2020 8 commits
  8. 29 Mar, 2020 5 commits
  9. 24 Mar, 2020 1 commit
  10. 19 Mar, 2020 7 commits
  11. 06 Mar, 2020 1 commit
  12. 05 Mar, 2020 1 commit