New BIP: Deterministic Satoshi Indexing

[thewrlck]

This BIP proposes a deterministic scheme for assigning serial numbers to satoshis and tracking their movement across transactions.

The goal is to provide a consistent and reproducible method that independent implementations can use to identify and track individual sats. The proposal does not require any changes to Bitcoin consensus rules, transaction formats or network behavior.

Implementations of this scheme have been in use on mainnet, signet, and testnet, including wallets with sat-level control and indexers that track sat locations. These systems construct standard Bitcoin transactions and operate entirely within existing protocol rules.

Without a shared specification, different implementations may assign sats inconsistently, leading to interoperability issues between wallets, indexers, and other software. This document attempts to standardize the indexing method so that independent implementations can arrive at identical results.

This is my first BIP submission, so feedback on structure, scope, and content would be appreciated.

This document standardizes an indexing method already used in production, with the goal of ensuring consistent behavior across implementations.

An earlier draft of a similar proposal was discussed previously: #1408

This version has been revised and reframed as an informational interoperability specification based on deployment experience.

[murchandamus]

This document appears to be a paraphrase of the previously submitted Ordinals proposal (#1408). I’m closing this PR, because it duplicates work and wastes the community’s time.

[thewrlck]

This document appears to be a paraphrase of the previously submitted Ordinals proposal (#1408). I’m closing this PR, because it duplicates work and wastes the community’s time.

Thank you for the clarification.

I understand that #1408 was previously rejected, and I want to emphasize that this proposal is not intended to reintroduce it under a different form.

The key difference is that 1408 was a "Standards Track" proposal describing ordinals as a system, including motivation, applications, and broader implications.

This document is instead an Informational BIP that documents a deterministic indexing scheme that is already implemented and deployed across multiple independent systems.

It does not propose adoption, does not introduce new concepts, and does not attempt to standardize ordinals as a protocol. Instead, it provides a minimal, implementation-neutral specification so that independent implementations can converge on identical results.

In that sense, this proposal is closer to documenting existing practice for interoperability, rather than proposing something new.

My goal is to reduce fragmentation between implementations, not to reopen previously rejected design discussions.

[murchandamus]

Instead, it provides a minimal, implementation-neutral specification so that independent implementations can converge on identical results.

What you are describing is a Specification BIP, not an Informational BIP. I don’t see a relevant difference to #1408 in purpose or content. You’re merely putting up an entirely new text for editing to specify the same scheme, which was invented and described by another person.
We just finished processing the prior submission, so I struggle to come up with a more charitable interpretation than you deliberately wasting your and our time.

[thewrlck]

What you are describing is a Specification BIP, not an Informational BIP. I don’t see a relevant difference to #1408 in purpose or content. You’re merely putting up an entirely new text for editing to specify the same scheme, which was invented and described by another person.
We just finished processing the prior submission, so I struggle to come up with a more charitable interpretation than you deliberately wasting your and our time.

Thank you for the candid feedback.

I want to clarify one key point, because I think the disagreement here is less about duplication, and more about whether this kind of document is appropriate for the BIP repository.

I fully acknowledge that the scheme described here was originally introduced by @casey , and this document is based on that work. I am not proposing a new system or alternative design.

The intent is to provide a deterministic and reproducible specification of behavior that is already implemented in practice, so that independent implementations can arrive at identical results.

I agree that this may be better categorized as a Specification / Standards Track BIP rather than Informational, and I am open to reclassifying it accordingly.

That said, my understanding is that BIPs can also serve to document and standardize existing practices where interoperability between independent implementations is required, even if the original design originated from a single source.

If the concern is that this does not yet meet the bar of sufficiently independent or widespread adoption, that would be useful to clarify, as it would give a concrete path forward.

If instead the concern is that this class of scheme should not be standardized or documented within the BIP process at all, then that seems to be a broader editorial decision rather than an issue of duplication or format.

Clarifying which of these concerns applies would help me understand how to proceed constructively.

[kanzure]

There are already existing documents online that specify Casey's project. It doesn't need to be in this BIPs repository to achieve your goal. This is cause for celebration!

[murchandamus]

You’re right. There are two levels to this situation. One is that we literally just processed an equivalent proposal. That’s where I am talking about this submission duplicating work. The other is the general question whether the Ordinals proposal is on-topic for this repository.

I consider it a personal failure that #1408 was left in limbo for such a long period of time. While the submission was made before I was a BIP Editor and we inherited the PR with scores of mostly useless comments on it already, I had been unable to facilitate progress on it for over a year. When we started out as BIP Editors, it was unclear whether Ordinals should be on-topic or off-topic for this repository. Thus, I set as one of the goals for the new BIP Process to more clearly specify the scope of the BIPs repository and make that question decidable. In the process of writing BIP 3, I drafted several scope definitions that were all shot down almost immediately for one or another reason. Alas, BIP 3 still only vaguely defines the scope of the repository, leaving the gray area as a judgment call to the BIP Editors.

I see the arguments regarding Ordinals as follows:

• Ordinals is deployed by several software projects on the Bitcoin network and broadly used, therefore a specification should be in-scope here
• Ordinals is a meta protocol that offers no palpable benefits to the use of the Bitcoin currency
• The interpretation of sats as uniquely identifiable essentially makes it a colored-coin scheme
• Beyond its own token characteristics Ordinals directly facilitates creation of other NFT and token schemes on Bitcoin which are obviously off-topic for this repository

While the Ordinals proposal explained itself well-enough and clearly is technically feasible, Ordinals does clearly not fall into the core topic of this repository, which focuses on improvements to the Bitcoin currency. Before and after BIP 3 was deployed, I attempted to make progress on Ordinals several times. While I still don’t have strong feelings either way whether it should be on- or off-topic, I felt that it was my job to facilitate a decision. Neither closing it, nor publishing it found strong support among my BIP Editor colleagues across those attempts.

Recently, there was a renewed demand for a decision on the proposal. I suggested that we time-box the decision. It became apparent that BIP Editors were more strongly opposed to accepting the proposal than to rejecting it. A BIP Editor made a decision. I would have probably communicated differently about that decision had I made it, but I can live better with this outcome than with the proposal remaining in limbo indefinitely.

Either way, it looks like the decision is that Ordinals is not eligible for publication here. We might have this conversation again at a later time, or when there are different BIP Editors, but I am not interested in further relitigating the decision mere days after it was made.

[thewrlck]

Thank you for taking the time to explain the broader context.

I would like to highlight what I see as a key distinction, as I believe it may not have been fully addressed.

The original Ordinals proposal by @casey introduced a system, including its motivations, applications, and broader implications. As such, it can reasonably be evaluated as a proposal for a meta-protocol and judged on whether that belongs within the scope of the BIP repository.

This bip takes a different approach. It does not propose a new system, advocate for adoption, or attempt to standardize Ordinals as a protocol. Instead, it documents a deterministic indexing method that is already implemented and in active use across multiple independent systems, with the sole goal of ensuring that those implementations can arrive at identical results.

In that sense, this document is closer to a reproducibility and interoperability specification than to a protocol proposal.

Given that independent implementations already exist and rely on consistent behavior, the absence of a shared specification introduces a real risk of fragmentation. From this perspective, the question is not whether Ordinals should be endorsed, but whether deterministic behavior that already exists in practice should be documented to avoid divergence between implementations.

I also understand that the bip process involves editorial discretion, especially in areas where the scope is not strictly defined. However, it seems worth noting that this introduces a layer of subjective judgment in what is ultimately a decentralized ecosystem.

Clarifying whether the rejection is based on scope, or a broader decision not to document this class of behavior would help establish a clearer path for contributors working on similar interoperability concerns in the future.

[kanzure]

What "absence of a shared specification" do you refer to?

[murchandamus]

I just read both documents again. As mentioned twice before, I fail to see a relevant distinction between your document and the original. As has been communicated, we do not consider Ordinals or similar meta-protocols to be BIPable at this time. Obviously, it follows from this decision that interoperability concerns of the off-topic protocol don’t make it on-topic.

I consider all points raised in this conversation addressed. If you have no new arguments and post here again, please refer to this and previous replies to service yourself should further replies not substantiate.