Design discussion: daily active-address count and address-count profit/loss

[maketobot]

I'd like architectural guidance before implementation. This is a design discussion only; no code or PR exists yet.

Daily active addresses

Proposed contract:

• Address identity is (OutputType, TypeIndex).
• For each completed UTC day1 under BRK's monotonic timestamp mapping, count the exact union of decoded addresses that either are attached to a prevout referenced by a non-coinbase input or receive a positive-value output.
• Zero-value receiving outputs, undecoded scripts, and the current partial day stay outside the result.
• A standalone derived-history module/database would scan BRK's existing typed input/output indexes, keep one day's union transiently, and write the daily count plus recovery metadata.

Would this belong in brk_computer? After safe lengths and monotonic timestamps settle following a reorg, would truncating from the day containing the fork predecessor and rescanning from that day's first canonical height fit BRK's recovery model? How should its version and database be scoped so changes do not invalidate unrelated computed state?

Address-count profit/loss

For comparability with BRK v0.3.2's existing coin-weighted supply_in_profit_share, the address-count series must use the same per-block integer-cent acquisition-price tape and the same price_close_cents/day1 daily valuation series.

Proposed exact contract:

• Count decoded addresses with positive remaining balance.
• Keep FundedAddrData.realized_cap_raw as exact CentsSats; zero-cent early acquisitions remain valid zero cost.
• With checked or widened integer arithmetic, classify an address as profit when close_cents × balance_sats >= remaining_cost, and as loss otherwise.
• Publish profit, loss, and eligible address counts with eligible = profit + loss. An optional at-cost diagnostic is the equality subset of profit, not a third partition.
• Use rollback-safe derived state or indexes and emit the same day1 date coverage as the existing coin series, including its current partial UTC day.

Where should the daily address-count/index state live relative to FundedAddrData and distribution state? What replay, versioning, checkpoint, and reorg-recovery shape would you prefer? Would an upstream implementation of this exact contract be acceptable in principle?

P2PK wire identity

In released v0.3.2, P2PK33 and P2PK65 both serialize as p2pk, although TypeIndex is only unique within one output type. Bounded samples can measure observed collisions but cannot establish an all-history bound from the collapsed wire. PR #38 appears to give the native wire values distinct names. Is #38 the intended prerequisite, and would it make the existing typed input/output series exact for an external reader without another API design change?

Would either or both metric designs be acceptable upstream in principle? Which placement and recovery boundaries should be settled before any implementation work?

[nym21]

The first two would be interesting to have (or at least see) but they both require pretty deep changes with notable (to say the least) impacts on code, speed and storage
A plugin architecture is planned and those datasets are great candidates for it

As for the latter, yes a fix is under way, p2pk33 and p2pk65 are legit different adresses, it was an oversight on my part to convert both to p2pk in more places than necessary. We'll still have to keep p2pk in one place for mempool.space compat