Jude Nelson

Feat/nakamoto block download API

2

This PR adds three new endpoints: * `/v3/tenures/info`: this returns metadata about the highest-known tenure. It will be used by the block-downloader state machine to identify peers with newer block...

[Chainstate] Sortition::get_canonical_stacks_block_id() does not produce the correct StacksBlockId

3

The method `get_canonical_stacks_block_id()` produces an invalid Stacks block ID, because it uses the _sortition_ consensus hash instead of the _canonical Stacks tip_ consensus hash. Fortunately, this only affects some unit...

[DO NOT MERGE] Feat/pox-4-property-testing

1

This PR tweaks `pox-4` so it logs its stacking events in a way that stateful property test frameworks and Clarinet testing can inspect. DO NOT MERGE.

[Nakamoto] Initial block download network synchronization

1

When the Nakamoto node is booting up, its coordinator will need to be aware of the progress of network synchronization. In particular, it should block the inventory vector state machine...

[Nakamoto] Update block anti-entropy state machine to handle Nakamoto blocks

2

The block anti-entropy state machine needs to be able to identify peers that are missing one or more tenures' block streams, and send them over.

This is an opcode we never implemented because there was never any economic incentive to use it. Let's delete it.

[Nakamoto] Block anti-entropy state machine

1

Specific to the current (and possibly last N) tenures, the node must constantly make sure it has the latest blocks. It does so by executing a separate anti-entropy state machine...

[Nakamoto] LeaderKeyRegisterOp must require a miner public key

2

The `check()` method in `LeaderKeyRegisterOp` currently does not consider the `memo` bytes, which in Nakamoto _must _contain the 20-byte hash160 of the miner's public key.

The bug fixed by #4361 could have been caught if, as part of our release process, we (1) ran the mock-miner for a long-ish duration (e.g. 1 week), (2) stored...

[Signer] throttle up/down stackerdb instances based on which signing set is active, and whether or not DKG is ongoing

2

PR #4323 adds 24 stackerdb contracts -- two for each message type. Most of these message types are concerned with DKG, so we don't need to be particularly aggressive about...