HashXHistoryPrefixRow issue with endianness of TxNums written to DB
Nobody has claimed this yet.
- Dominant language
- Python
- Stars
- 15
- Forks
- 16
- PR merge metrics
- No merged PRs in 30d
Description
Python scribe when run on my machine (MacOS ARM64) produces little-endian txnums for hashXhistory prefix. (I just looked up M1 mac behavior, and it's little-endian by default) But there could be some more exotic platform that writes txnums big-endian fashion.
The endianness should be corrected to big-endian like other numbers in the database OR it should be locked to be little-endian specifically.
For now, I am correcting (herald.go) HashXHistoryValue implementation to read TxNums in little-endian form.
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Compare the Python scribe's HashXHistoryPrefixRow serialization with the HashXHistoryValue implementation in herald.go, focusing on how TxNums are encoded and read. Determine the intended byte order for database values and verify that the chosen representation is consistent across platforms and implementations.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- go, macos, python
- Domain
- databases
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100