What to know

  • Fabian Jahr opened the naming discussion onSeptember22.
  • Changing a tag changes cryptographic outputs and implementation test vectors.
  • The thread seeks a convention; it does not announce an activated Bitcoin rule.

The question raised on the mailing list

Fabian Jahr opened a Bitcoin development discussion on 22 September 2026 about a convention for tagged-hash tags in Bitcoin Improvement Proposals. His post contrasts tags containing a BIP number with descriptive names and asks whether a consistent practice should be documented. The immediate concern is specification stability: a draft can have implementations before receiving its final number. Renaming the cryptographic tag afterward changes the outputs used by those implementations. This is a standards-design discussion, not a newly disclosed break of Bitcoin signatures.

Why a name can be part of a protocol

For application readers, the surprising point is that some names are data consumed by cryptographic calculations. They are not merely labels in documentation that can be edited without consequence. Our interpretation is that a team should treat such names as part of its compatibility boundary. A documentation change, a test-vector change and an implementation change may need to move together even when the prose appears to describe the same mathematical construction before and after the edit.

Two reasonable goals can conflict

A numbered name can make its origin easier to recognize and help avoid accidental reuse. A stable descriptive name can keep existing prototypes aligned while a draft moves through review. Those goals are not automatically compatible at every stage of a specification’s life. The useful question is when an author commits to an identifier and how the project communicates later changes. Publishing a rule without a migration story would leave implementers to discover mismatches through failing tests or incompatible messages.

A practical checklist for protocol authors

Before releasing a cryptographic format, maintainers could record which strings are protocol inputs, where their exact bytes are defined and which test vectors protect them. If a draft changes those bytes, release notes should call out compatibility consequences directly. Independent implementations should regenerate vectors and compare results before claiming interoperability. These are editorial recommendations for specification work. They are not a claim that the mailing-list participants have adopted a particular checklist or agreed on a final community rule.

What readers should watch next

The evidence to follow is whether the discussion produces written guidance and whether new drafts apply it consistently. A mailing-list thread can expose a coordination problem without settling it. Developers should continue to use the exact specification for their target protocol rather than inventing a local naming convention from a news summary. For everyone else, the episode shows why Bitcoin engineering progress often involves careful treatment of small compatibility details. Those details matter because independently written software must arrive at the same answer without relying on an editor’s interpretation.

Sources and reading

Editorial note: AI-assisted original BijliCoin synthesis. Original BijliCoin synthesis of the linked public primary source. Analysis and suggested checks are editorial interpretation; reported claims are attributed. Illustration is conceptual, not a photograph of the event.

Sources & context

  1. Fabian Jahr: tagged hash conventions discussion ↗

See our editorial policy or report a correction.