spec: align bundle_locator wording with the blob_id fetch model - #80
Conversation
§3.6 fetches a BatchBundle by its Blossom blob_id = H(serialize(BatchBundle))
and treats bundle_locator as the on-chain binding value only. A few
descriptions still read as if bundle_locator were the fetch/content address:
- §3.1: a scanner "accepts the inscription only after fetching the bundle
by bundle_locator" directly contradicted §3.6 ("served only by blob_id …
not by the Poseidon bundle_locator") — now fetches by blob_id.
- §3.1 / §1.5 (BatchInscription): "addresses the off-chain bundle by
bundle_locator" -> "binds".
- §1.5 (BatchBundle): "content-addressed" -> "content-addressed by blob_id".
- §1.7.9: "serialize(BatchBundle) is never itself a hash preimage" was
false (it is the blob_id preimage); clarified that it is the per-batch
blob_id fetch key, never the on-chain binding, and never enters
bundle_locator.
Wording only; no normative change.
Review follow-ups to the bundle_locator/blob_id alignment: - §1.7.9: the sentence's closing clause said proof-byte non-determinism 'never enters a content address', which now collided with the added 'content-addressed by blob_id' (blob_id does carry the proof bytes); scoped it to the on-chain bundle_locator binding. - §3.1: blob_id is resolved from a node's inscription index, not from the on-chain inscription itself (which carries only bundle_locator). - §3.6 step 8: serve future verifiers that fetch the BatchBundle by its blob_id (was 'fetching the same bundle_locator'). - §4.9 ping hint: a coin waits at its blob_id, not bundle_locator.
|
Ready for review. Two review passes (conformance/consistency + logic/correctness in parallel each round) until both came back clean. Pass 1 confirmed the five core fixes but found that the §1.7.9 rewrite introduced a same-sentence contradiction — its unchanged closing clause said proof-byte non-determinism 'never enters a content address', which collided with the newly added 'content-addressed by blob_id' (blob_id does carry the proof bytes). Scoped that clause to the on-chain bundle_locator binding, and pulled in three more sites of the same class the pass surfaced: §3.1 blob_id is resolved from a node's inscription index (not the on-chain inscription), §3.6 step 8 and the §4.9 ping hint (a coin waits at its blob_id, not bundle_locator). Pass 2: both lenses clean. Wording only, no normative change. |
1 participant
Why
PR #79 pinned the BatchBundle fetch model: a scanner fetches by the Blossom
blob_id = H(serialize(BatchBundle))and treatsbundle_locator(the Poseidon on-chain value) purely as a binding value (§3.6). A few descriptions that predate that change still read as ifbundle_locatorwere the fetch/content address. One of them was a genuine contradiction, the rest loose wording.What
bundle_locator" directly contradicted §3.6 ("served by Blossom only by its SHA-256 addressblob_id… not by the Poseidon on-chainbundle_locator"). Now fetches byblob_id(resolved from the inscription).bundle_locator" → "binds".blob_id".serialize(BatchBundle)is never itself a hash preimage" was false — it is theblob_idpreimage. Clarified: it is the per-batchblob_idfetch key the publisher fixes once, never an on-chain binding, and it never entersbundle_locator(whose preimage is onlymember_root).Wording only, no normative change. These are the pre-existing items flagged (but held out of scope) during the #79 review.