Skip to content

Conversation

@cculianu
Copy link
Owner

@cculianu cculianu commented Oct 23, 2025

- new method: mempool.get_info
- changed method: blockchain.estimatefee

Also added sections discussing the mempool transaction ordering
specification.
- Updated copyright year
- Updated protocol version to 1.6.0 in document
- Clarified mempool ordering description
- Refer to mempool ordering properly from the "status" section.
Comment on lines +389 to +390
all transactions with unconfirmed parents, and within each grouping, they are sorted by their transaction hash (as a
string).

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

note the txid is in network byte-order here, not the human-readable form

Copy link
Owner Author

@cculianu cculianu Oct 24, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the review here.

In Fulcrum, internally, I keep the hashes as bytes but in human-readable byte order always (to avoid having to reverse them when presenting them to RPCs or in human-readable form) -- Electron Cash on BCH also assumes this now. This kind of throws a wrench into the works for me to have to change this... why are you keeping them in memory in non-human readable form anyway? It's just wasted cycles to do that since internally you don't really care about exact hash value you just care about communicating to the client (in human readable hex form) and to the daemon (again, in the same ordering).

Hmm... :/


Note that the only reason the hash is "reversed" when stringified in bitcoind anyway is due to a historical quirk of sorts -- the hashes (sometimes) were uint256 values treated as a little-endian integer (as is the case with a block hash). They ended up getting "reversed" so they print nicely because humans read numbers in big endian order.

But most hashes are never internally treated as integers anymore so.. the whole reversing-them-to-print is kind of nonsensical in the first place... but since that stupidity is enforced in the RPC interface and when printing hashes.. better to keep them in memory in the "ready to print" and "ready to send to RPC" form when communicating with bitcoind, clients, etc, if you ask me.

@cculianu cculianu changed the title Draft: Documentation changes for Protocol 1.6 Documentation changes for Protocol 1.6 Nov 5, 2025
@cculianu cculianu merged commit 3670260 into master Nov 5, 2025
@cculianu cculianu deleted the protocol_1_6 branch November 5, 2025 06:54
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants