handshake-org / handshake-org/hsd
Fee estimator doesn't account for covenant submarkets
- Dominant language
- JavaScript
- Stars
- 2.1k
- Forks
- 306
- PR merge metrics
- No merged PRs in 30d
Description
The `hsd` [fee estimator](https://github.com/handshake-org/hsd/blob/4b04d9a2f9094b9c4c8e17346e7f24517f0a0336/lib/mempool/fees.js) is bcoin code that has not been updated for hsd, so it doesn't consider fee submarkets at all.
By submarkets, I mean that there are four limits for how many transactions can go in a block, each of which could fill up separately:
- the main market for block space
- a submarket for [600 "updates"](https://github.com/handshake-org/hsd/blob/af86d4899791601d10212115c80a2f2136fdb004/lib/protocol/consensus.js#L200) which are `OPEN`, `UPDATE`, `TRANSFER` and `REVOKE` covenants
- a submarket for [600 "renewals"](https://github.com/handshake-org/hsd/blob/af86d4899791601d10212115c80a2f2136fdb004/lib/protocol/consensus.js#L208), which are `FINALIZE`, `REGISTER`, and `RENEW` covenants
- a sub-submarket for [300 opens](https://github.com/handshake-org/hsd/blob/af86d4899791601d10212115c80a2f2136fdb004/lib/protocol/consensus.js#L192), which are just `OPEN`s. Note that these 300 opens are a subset of the 600 updates
Note that the other side of the market, the miners who make blocks with the hsd template code, behave rationally. They [pick the highest-paying transactions](https://github.com/handshake-org/hsd/blob/7c172277476ea2a41501413f4f43a4a0a040b100/lib/mining/miner.js#L362) for each block that respect the covenant limits.
I'm planning to write a new `estimateFee()` method that takes covenant type as an argument and estimates fees to account for submarkets. Does that sound like a useful thing to add to fee estimation?
Contributor guide
Assessment
This issue has not been assessed yet.