Update getTxInfo endpoint API

[samholmes]

• Change addressPrefix to addressHashfix
• Use a couch view for generating hashfix using simple hashfix algorithm
• Change /v1/getTxInfo response type to more closely match Edge core types

CHANGELOG

Does this branch warrant an entry to the CHANGELOG?

• Yes
• No

Dependencies

none

Description

none

---

• To see the specific tasks where the Asana app for GitHub is being used, see below:
  • https://app.asana.com/0/0/1210834854113135

[paullinator]

start and end have the same hash. This doesn't allow for any privacy to ensure we don't exactly know the users addresss.

If this were a standard sha256 hash into hex, we could use the first N chars as the prefix to allow for privacy

[samholmes]

The hashfix is not collision resistant. It is a "hash prefix" because it takes 5 bytes from the address (5 bytes is 5 chars). The collision space is 5 bytes, or 40 bits (2^40). We can lower the collision space to 3-bytes which would have many more collisions.

[samholmes]

OTS comments:

1. Use a large enough space size of (I recall 64^6)
2. Use mango queries to do range queries on the hashfix value

The goal is to be flexible in our design. We want to query different collision space over time rather than be locked to some byte size. To do this we need to do range queries on the hashfix. So the space for the hashfix is a maximum, but the range will determine the actual collision space.

[samholmes]

Sidebar Today:

Because we cannot do multiple range queries on a single view key, we're instead going to store the real hash of transaction's addresses. Then with the full hash of the address we can index it and use a mango query to range query it and the date at the same time.

Next, we want to add a new endpoint that gives use the hash prefix length which MUST be used. If the client doesn't use the same prefix length that the server uses, then it'll reject the query. This is to prevent data miners from getting all our transaction data (DOS protection). This endpoint does some average addresses per minute heuristic and returns the prefix that should be used for the number of minutes within the range that would match the average. This way ever query should be hidden within the average.

Here's what Opus 4.5 generated explaining the limitation:

Good question! Hashfix can be a derived value in a view key — the current implementation already does this. The issue is how CouchDB view queries work with composite keys.

The B-tree Ordering Problem

CouchDB views use B-tree ordering on composite keys. With a key like [hashfix, isoDate]:

[100, "2025-01-01"]
[100, "2025-06-15"]
[100, "2025-12-31"]
[101, "2024-01-01"]  ← hashfix 101 comes AFTER all of hashfix 100
[101, "2025-03-20"]
[102, "2024-06-01"]
...

If you query with:

startKey: [100, "2025-01-01"]
endKey:   [200, "2025-12-31"]

You'd get:

• ✅ hashfix 100, dates from 2025-01-01 onward
• ❌ hashfix 101-199, ALL dates (not just 2025)
• ✅ hashfix 200, dates up to 2025-12-31

The date filter only applies at the boundaries, not across the entire range. This is because B-tree range queries work on the key as a tuple, not as independent fields.

Why Mango is Different

Mango's $and selector applies each constraint independently:

{
  payoutHashfix: { $gte: 100, $lte: 200 },
  isoDate: { $gte: "2025-01-01", $lte: "2025-12-31" }
}

This properly filters: "hashfix in range AND date in range" for every document.

View Workaround?

You could make views work with range hashfix, but it's awkward:

1. Reverse the key to [isoDate, hashfix] — but then you lose efficient hashfix range queries
2. Post-filter in application code — fetch all hashfixes in range, then filter by date
3. Multiple queries — one query per hashfix value (very inefficient for large ranges)

So the derived value itself isn't the problem — it's the composite key ordering that makes independent range queries on multiple fields impractical with views.