Boog900

> Do you want a cuprate-zmq-types crate with 5 top-level message types Yeah that would be a good place to start, and yes identical output. Although some of the fields...

> what is the protocol for accepting large code like this (especially hash functions)? It really would take time to verify this whole implementation, probably as long as implementing it...

Just to keep you updated, my plan is to first merge #274 then with that I'll test a sync on all 3 networks up to RandomX activation if that is...

yes, mainly for UX. I am also considering only exposing the necessary API for Cuprate on the the types although I don't really think the benefits are there.

I'll start by saying how much I appreciate `monero-serai`, it really is a great crate. Initially Cuprate also used `monero-rs`, very soon in development we decide to move over to...

## Blockchain | Request | | |------------------------|-------------------------------------------------------------------------------------------------------------------------------| | PopBlocks(u64) | This will be a request for the blockchain manager. | | Prune | This should be left as a TODO...

Just to add some more details on how these limits were chosen, the string limit was chosen to allow us to roughly reach the 100mb packet size limit with average...

> Second question, what about 3rd-party tools changing the database between monerod runs? By introducing this code, you assume that nothing ever touches the txpool table except monerod. If tools...

This code is only ran at startup but yes when adding a block and the HF changes the tx-pool is re-validated: https://github.com/monero-project/monero/blob/8d6aff95908e029d6b131638fbbf845e8cff04fc/src/cryptonote_core/blockchain.cpp#L4356-L4368 Which would freeze up the node for a...

The crate should be completed separated, `cuprate-consensus` shouldn't depend on the context crate