Tracking: all the consensus parameters

[yaahc]

Right now as part of equihash verification we've hard coded:

• n=200 and k=9 in one of the functions used to verify equihash

These types of constants should be centralized as much as possible to ease maintenance and make it easier to look up the consensus parameters that zebra uses. This type should probably be defined and instantiated in zebra-consensus.

---

Here are some other things we'll want in our consensus parameters:

• hash difficulty settings

  • the per-network minimum difficulty, when there are no new blocks for a while (feature: Add the MinimumDifficulty consensus parameter #771)
  • the per-network maximum difficulty (params.powLimit)

• coinbase amount and halving intervals (Tracking Issue: Validate coinbase transactions, including the dev fund #801)

  • dev fund amounts, addresses, and height range (per network)

• activation heights for consensus rule changes (Add the consensus branch ID and activation heights to the consensus parameters #716)

• consensus branch IDs for network upgrades (Add the consensus branch ID and activation heights to the consensus parameters #716)

• the hash of the genesis block (Check genesis hash in checkpoint lists #663)

• the hash of the parent of the genesis block (Check genesis hash in checkpoint lists #663)

• excluding the genesis transaction from UTXOs (parameter Add Genesis NU, Update Canopy NU Testnet Height #765, design rfc: Parallel Verification #763)

• TODO: Zcash spec

• TODO: zcashd

• TODO: Bitcoin

It might be helpful to look at zcashd's chain and consensus parameters:

• https://github.com/zcash/zcash/blob/master/src/chainparams.cpp
• https://github.com/zcash/zcash/blob/master/src/consensus/params.h
• https://github.com/zcash/zcash/blob/master/src/consensus/params.cpp

We might also need some parts of the network upgrade info:

• https://github.com/zcash/zcash/blob/master/src/consensus/upgrades.cpp#L7

To do some network integration tests (#466), we might need a "regression test" mode like zcashd. So we might end up with 3 sets of parameters.

---

Yeah, I think that we should think about how we want to represent consensus parameters, maybe in an object in zebra-consensus or something?

Originally posted by @hdevalence in #550

[teor2345]

(Moved to description, so we can track items on the checklist.)

[teor2345]

I think we want to interface to the consensus parameters using functions that takea a block height, and a network (mainnet, testnet, and maybe regtest).

[dconnolly]

@conradoplg @teor2345 I think this is redundant now, should we close it?

[teor2345]

Yep, we have all the parameters we need for now.