Commit Graph

15 Commits

Author SHA1 Message Date
TomZ 2aa462f8bb Replace SigOps with SigChecks
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
2020-04-13 15:57:42 +02:00
TomZ 9195ad96e1 Add May Protocol Upgrade activation code 2020-04-10 17:28:02 +02:00
TomZ ba76c35a7d Move merkle to flowee_utils libs
Merkle-block and merkle-tree classes and methods are pretty much stand-
alone and can be moved with no efforts.

Also move the relevent unit test to qtestlib.
2020-04-01 22:53:07 +02:00
TomZ 7593d06473 Use blockheight to enable historical features
We used various ways to enable new features over the last 10 years.
We can remove that legacy code and just set the blockheight.

This cleans up the code quite a bit.
2019-10-14 19:24:19 +02:00
TomZ 3fc088a76d Add 2019-11 HF activation mechanism. 2019-10-08 14:24:22 +02:00
TomZ f868a8274e Make all protocol upgrades equal.
The "UAHF" one used to be "more equal", mostly just because it happened
to be the first.
This makes them all equally equal.

Specifically this removes the special casing and the enum for the 201708
HF (aka BCH fork-point).
We select the right branch now purely based on the historical check-
points.
2019-06-02 13:57:47 +02:00
TomZ 5996205a07 add checkpoint and set PU blockheight 2019-05-15 20:44:47 +02:00
TomZ 2577b6f7ef Merge branch 'may19PU' 2019-04-22 12:51:07 +02:00
TomZ d8b9d79f2f Use block-height for DAA PU (201711) 2019-04-21 17:41:47 +02:00
TomZ f23aa69a86 Detect the 2019-09 protocol upgrade 2019-04-17 16:02:54 +02:00
TomZ 3e3f8843f3 Remove the optional replay protection feature
Its sundown has passed, so the code is now effectively dead.
2018-11-29 23:13:48 +01:00
TomZ 2ef243a43a Add more basic support for the novHF
this adds sigop counting for the new opcodes and
flags enabling based on block-height.
2018-11-08 17:37:22 +01:00
TomZ b8a6c54a51 Make block-height hard fork detection easy 2018-11-03 19:31:22 +01:00
DesWurstes c9e9e19698 Add Sha256D64 to Merkle root calculation 2018-08-12 10:27:40 +03:00
TomZ 14bf96aa3c Start libs/server 2018-02-13 13:27:58 +01:00