zkvm: remove maxtime?

[oleganza]

We should probably remove the maxtime (expiration time) field from TxHeader. The reason for it in the first place was due to symmetry with mintime and ability to reliably kick out low-fee transactions from the mempool, so they don't bounce in the network indefinitely.

Unfortunately, the problem with maxtime is that it makes mempool logic more complicated and opens some DoS vectors. The more you want to avoid DoS, the less useful maxtime is, as nodes would require it to be farther in the future.

Bitcoin uses a simple principle "every tx accepted in mempool can be mined" (aside of intentional double spending attempts). This means, that tx that incurred the cost of relay to the network cannot just disappear w/o paying a fee. This principle greatly simplifies the mempool logic. Bouncing issue can be mitigated in two ways: from the UX perspective, CPFP (child-pays-for-parent) can be used; and to prevent DoS-y bouncing, kicked out TxIDs can be remembered in a bloom filter to avoid their reappearance and re-relay without appropriately increased fee (via CPFP).

[oleganza]

Here's a problem with the relative timelocks: in Bitcoin, the utxo is stored with the timestamp of a block, where it was created. Then, a relative-time-locked input is checked against that timestamp. This, unfortunately, adds considerable amount of complexity:

1. a utreexo proof must include the timestamp;
2. the contracts need extra maxtime-like commitment to be checked against the actual timestamp, if we want to make this available in the contract.

Ideally, we'd encode all state management into the contract logic, so the blockchain state machine has as little features as possible. Mintime/maxtime bounds allow us to do just that. But then we need to work around DoS issues with expiring tx. E.g. requiring that feerate pays enough for the tx to be included in the block well before the maxtime.