BIT: The bit of Bitcoin

The smallest unit of value in the network borrows the name of the smallest unit of information. That is not a coincidence. When Satoshi Nakamoto published the Bitcoin whitepaper in 2008 [1], the term bitcoin read as a portmanteau of bit and coin, fusing Claude Shannon's 1948 information-theoretic primitive [2] with the metaphor of coinage. Seventeen years on, that etymology is still right there in the name.

Every Bitcoin block ever produced carries a four-byte field literally named bits, encoding the proof-of-work target the miner had to beat. The field was there in block 0. It was there in block 840,000. It will be there in every block that ever lands.

This paper introduces $BIT, a fungible token whose entire supply derives from that field. The mint quantities, the supply curve, the block-by-block accounting: none of it was chosen. All of it falls out of Bitcoin's existing header data. We did not design $BIT's tokenomics; we read them off of consensus.

The remainder of this paper is structured as follows. §2 traces the etymology of the bit through Shannon, Satoshi, and the block header. §3 specifies the bits field in full, with worked example. §4–§6 formalise the issuance pipeline: DMT projects header fields into integer issuance functions; TAP indexes inscription operations into a deterministic state; $BIT instantiates a particular case. §7 derives the supply curve and its upper bound. §8–§9 examine the fair-mint argument and the threat model. §10–§11 close on the philosophical claim.

On 9 January 1947, in a Bell Labs memo, the statistician John W. Tukey contracted binary digit into a single syllable: bit. Eighteen months later Claude Shannon adopted the word in A Mathematical Theory of Communication [2], and credited Tukey by name (“a word suggested by J. W. Tukey”). With that, the bit became formal: the irreducible atom of information, a single binary distinction, the fundamental unit of message content.

Sixty years later, Satoshi's whitepaper [1] proposed an electronic-cash system whose fundamental unit, bitcoin, fused two metaphors: the bit of digital information, the coin of physical exchange. The smallest unit of money carried, in its name, the smallest unit of information.

bit + coin = bitcoin.The lineage is explicit.

From the very first release of Bitcoin, one bitcoin was 100,000,000 satoshis. Years later, BIP 176 [7] formalised a now-conventional sub-unit: one bit equals 100 satoshis. So even at the level of denomination, the word stays.

But the deepest occurrence of bit is structural, not semantic. Inside the 80-byte header of every Bitcoin block sits a 4-byte field literally named bits. It encodes the difficulty target the block hash must not exceed for the block to be valid [3]. Without bitsthere is no proof-of-work; without proof-of-work there is no chain. The field is the chain's truth condition.

On 3 January 2009 at 18:15:05 UTC, Satoshi mined block zero. Its bits field carried the value 0x1d00ffff: the lowest possible difficulty Bitcoin would ever know. Every block since has carried the same field, in the same four bytes, in the same place. From the first second.

$BIT is named, not after a metaphor, but after that field.

A Bitcoin block header is exactly 80 bytes [3], structured as a fixed-length record of six fields:

The bits field is bytes 72–75 of the header. On the wire it is little-endian; logically it is a 32-bit unsigned integer (often called nBits) that compactly encodes a 256-bit difficulty target.

3.1 Compact target encoding

Let the 32-bit value of the field be split into a 1-byte exponent e and a 3-byte coefficient m:

nBits  =  e · 224  +  m, with  e ∈ [0, 255],  m ∈ [0, 224 − 1]

The implied 256-bit target T is then defined piecewise:

T  =  m · 2^( 8·(e − 3) )      if  e ≥ 3
T  =  m · 2^( −8·(3 − e) )     if  e < 3

For e ≥ 3 this is just T = m · 256^(e − 3), which is the regime every mainnet block has ever lived in. (The e < 3 branch is there for definitional completeness; mainnet exponents lie in [23, 29].) A block hash H is consensus-valid iff H ≤ T. Those four bytes aren't a label on the block; they are the test the block had to pass.

3.2 Worked example: block 840,000

The block at height 840,000— Bitcoin's fourth halving block, mined April 2024 — carries nBits = 0x17034219. Splitting the bytes:

e  =  0x17       =  23
m  =  0x034219   =  213 529

The implied target is therefore

T  =  213 529 · 25623 − 3  =  213 529 · 2160  ≈  3.12 × 1053.

For the block to be valid, the SHA-256d of its header had to fall at or below this target. Reading the 4-byte nBits word itself as a uint32 yields 386,089,497. On 19 April 2024 some miner found a hash that cleared the target; that same integer, 386,089,497, is now the $BIT quantity credited to a successful mint at block 840,000.

3.3 Relation to difficulty

Bitcoin Core defines difficulty D as the ratio of the maximum target to the current target [3]:

D(h)  =  Tmax / T(h)

Tmaxis the protocol-defined maximum target, the so-called “difficulty 1” target, encoded as 0x1d00ffff (integer value 486,604,799). It is also the genesis-era encoding. Bitcoin's difficulty has trended upward across most of its retarget epochs [6], punctuated by occasional sharp downward adjustments after big hashrate shocks. The largest of those is the −27.94% retarget at block 689,472 in July 2021, after the China mining ban. As difficulty rises, target falls, and the integer value of nBits falls with it. So the per-block $BIT mint runs roughly anti-correlated with difficulty, modulo short-horizon retarget noise.

Two retarget thresholds bracket the regime of practical interest:

• Maximum bits: nBitsmax = 0x1d00ffff (integer 486,604,799) — the minimum-difficulty target, also the genesis-era encoding.
• Block 840,000: nBits = 0x17034219 (integer 386,089,497) — for reference scale.

Updates to nBits happen every 2,016 blocks via the difficulty-retarget rule. Each retarget produces a step change. The resulting per-block emission curve is non-uniform, non-monotonic in the small, but bounded above by nBitsmax for all h.

Ordinals gave us a way to number individual satoshis. Digital Matter Theory [4] goes a step further: it lets us name structures that Bitcoin has already written. The thesis of DMT is that several fields inside a Bitcoin block are not arbitrary at all. They are deterministic, public, immutable, and globally replicated. DMT treats those fields as digital primary matter, substance from which assets can be tokenized without an issuer creating any new state.

4.1 Formalisation

Let the Bitcoin chain at tip height n be the sequence of confirmed blocks

B  =  (b0, b1, …, bn).

For each DMT element index k, let πk denote the projection that extracts element k from a block:

πk :  B  →  { 0, 1 }*, πk(bh) = encoded element value at height h.

Define the issuance function for element-k tokens as the integer interpretation of that projection:

μk : ℕ → ℕ, μk(h) = uint( πk(bh) ).

A DMT element-k token is a tuple ⟨tick, k, hdeploy⟩ such that for every minted block h ≥ h_deploy, the supply increment is μ_k(h). Because πk is a pure function of consensus state, μ_k is verifiable by anyone running a Bitcoin full node. No oracles, no bridges, no off-chain data.

4.2 The element registry

DMT formalises a registry of numbered fields with canonical encodings [4]. The block-header subset of the registry, with its standard JSON-RPC field names, is:

4.3 Patterns and the identity case

A DMT deploy is more than a choice of element. The full inscription identifier follows the form <name>.<pattern>.<k>.element, where pattern is a function f : ℕ → ℕ applied to the integer-decoded element value at each block [4]. Per-block emission is therefore μk,f(h) = f( πk(bh) ). Different choices of (k, f) produce distinct DMT tokens.

$BIT picks the simplest configuration on this scheme: ticker is the field, pattern is the identity, mint is open. tick = "bit", k = 11, f = id; the per-block emission for any unminted block h is just μ11,id(h) = nBits(h), claimable by anyone. No transformation, no gating. $BIT is, in this sense, the literal DMT-11 token.

Tokens on Ordinals require an inscription-based protocol. $BIT uses TAP [5]— Trac Systems' OrdFi protocol on Ordinals — which encodes token operations as JSON inscriptions on satoshis. TAP supports DMT operations natively.

5.1 The TAP envelope

Every TAP-relevant inscription i carries a JSON envelope:

i  =  { "p": "tap", "op": ⟨op⟩, ...op-specific fields... }

For DMT, three operations are relevant:

• dmt-deploy — registers a ticker T against an element k with parameters.
• dmt-mint — claims supply increment μ_k(h) for a target height h, against a specific deploy.
• transfer — moves balances between Ordinals UTXOs subject to the standard TAP transfer semantics.

5.2 State and transitions

Let σ_t denote the global TAP indexer state after processing the first t TAP-relevant inscriptions in confirmed-Bitcoin order. The state-transition function δ is

σt+1  =  δ(σt, it+1).

δ is deterministic: given σ₀= ⊥ (empty state) and the canonical inscription order induced by Bitcoin's confirmed-block sequence, every honest indexer arrives at the same σ_t. We refer to this as TAP's indexer-determinism property.

5.3 Mint validity

A dmt-mint inscription targeting height h against deploy d is valid iff all of:

1. d resolves to a registered, immutable dmt-deploy for some element k;
2. the height h has not yet been claimed for tick(d);
3. the chain has confirmed h by the time the indexer evaluates V(i) (so nBits(h) is readable);
4. the inscription payload conforms to the TAP schema for dmt-mint.

The first inscription satisfying (1)–(4) for a given pair (d, h)wins; later inscriptions for the same pair are no-ops under δ. This is TAP's first-valid-inscription rule, enforced by every honest indexer without coordination. Whatever chain ordering Bitcoin settles on, that is also the ordering that resolves $BIT mints.

None of this stack was built for $BIT. Ordinals is the substrate, TAP is the protocol on top of it, DMT is the semantic on top of that. $BIT only instantiates them.

The canonical $BIT deploy lives at the following inscription on Bitcoin mainnet:

deploy id:  9424802e38fc889969417cd90df4c4147209d2a83ed83798c0c4aa4391ad36e5i0
ticker:    "bit"         (case-insensitive on TAP)
element:   dmt.11.element  (the bits field)
protocol:  TAP on Ordinals
premine:   0
reserved:  0

6.1 Mint-validity predicate

Specialise §5.3 to the canonical $BIT deploy. Let ID* denote the canonical deploy inscription ID (above). A $BIT mint inscription i is valid iff

V(i)  =  ( i.p   = "tap" )       ∧
         ( i.op  = "dmt-mint" )  ∧
         ( i.dep = ID* )         ∧
         ( i.tick ≡ "bit" )      ∧
         ( i.blk ∈ ℕ, 0 ≤ i.blk ≤ tip ) ∧
         ¬ claimed( i.blk )

where claimed(h) is true iff a strictly prior inscription i' in canonical TAP order satisfied V(i') with i'.blk = h. The credited amount for a valid mint is

amount(i)  =  μ11(i.blk)  =  nBits( i.blk )  ∈ [ 0, 4 294 967 295 ].

6.2 Reference mint payload

{
  "p":    "tap",
  "op":   "dmt-mint",
  "dep":  "9424802e38fc889969417cd90df4c4147209d2a83ed83798c0c4aa4391ad36e5i0",
  "tick": "bit",
  "blk":  "840000"
}

Verifying any $BIT balance reduces to two checks: (i) that the canonical deploy inscription matches ID*, and (ii) that every claimed mint resolves on a TAP-aware indexer to a unique valid block claim under the predicate above. There are no oracles in the picture, no off-chain data, and no trust beyond Bitcoin itself plus the open TAP and DMT specs.

Five fields, no signature. $BIT doesn't add data to Bitcoin; it asks Bitcoin to surface what it has been writing for seventeen years.

Let nBits(h) denote the integer value of the bits field at height h. Let M(tip) ⊆ { 0, 1, …, tip } denote the set of heights for which a valid dmt-mint has been recorded. The realised total $BIT supply at chain tip is

Srealised(tip)  =  Σh ∈ M(tip) nBits(h).

This is bounded above by the supply that would obtain if every block were minted — the so-called theoretical supply:

Stheory(tip)  =  Σh=0tip nBits(h)  ≥  Srealised(tip).

And in turn:

Stheory(tip)  ≤  (tip + 1) · nBitsmax =  (tip + 1) · 486 604 799.

This is a hard, computable upper bound. It treats every block as if it had the genesis-era nBits, which it does not — so the true bound is far tighter. Empirically, the integer nBits(h) has fallen across difficulty epochs, producing a steeply front-loaded emission curve.

The early blocks hold the most $BIT. They were mined when Bitcoin was one laptop and a few cypherpunks on a mailing list, when nBitssat at its maximum and would not move for the first sixteen retarget epochs. To hold those bits is to hold a slice of Bitcoin's first hour.

7.1 Asymptotic behaviour

Under the model in [6], Bitcoin's aggregate hashrate R(t) grows roughly geometrically over long horizons. The retarget rule equalises expected block time, so on average T(h) ∝ 1 / R(th). Since nBits compactly encodes T, large‐h values of nBits shrink in step with R. This implies that

∂ μ11(h) / ∂h  ≈  − μ11(h) · γ,

for some non-negative drift γ that tracks the long-run growth rate of hashrate. The per-block $BIT mint therefore decays quasi-exponentially with retarget index, modulated by short-horizon fluctuations within each 2,016-block epoch.

$BIT's supply is, quite literally, an integral over Bitcoin's economic history.

$BIT is a fair-mint asset, by construction:

• The dmt-deploy inscription carries no balance. Deploying produces zero $BIT.
• There was no presale and there is no team allocation. Not one satoshi-equivalent of $BIT was emitted at deploy.
• Every $BIT in circulation was claimed by an inscriber paying Bitcoin transaction fees against a publicly-readable, deterministic block.
• First-valid-inscription wins. The rule is enforced by indexers, not by trusted parties.
• The deploy parameters are immutable on Bitcoin L1, so they cannot be changed after the fact by anyone, including us.

More formally: any participant p looking to acquire $BIT at cost c_p(h) (Bitcoin transaction fees, plus an ordinary inscription budget for height h) competes with the rest of the network on equal terms. The protocol does not privilege any address, key, or identity; the auction for each block is symmetric. Where the miner pays joules to mint the block, the inscriber pays fees to claim its bits.

We enumerate three failure modes and the corresponding mitigations. None of them affect the supply formula μ₁₁; they affect who holds what, not what $BIT is.

1. Lookalike deploys.TAP tickers are case-insensitive and unique-on-first-deploy. A non-canonical “bit” deploy can exist as an inscription, and a naive participant could mint against it. Mitigation: the canonical deploy ID* is fixed and published; always verify the deploy ID before any mint or transfer.
2. Indexer divergence at the tip. During short Bitcoin reorganisations (1–2 blocks), TAP indexers may transiently disagree on σ_t at the chain tip. Mitigation: rely on n-block-confirmed state (n ≥ 6 by convention); this is standard for Bitcoin-anchored systems.
3. Ordering ambiguity. Two inscriptions targeting the same (d, h) may be broadcast in different mempools. Mitigation:δ resolves by Bitcoin's canonical confirmed-block order; once the chain settles, exactly one inscription is accepted.

9.1 Independent verification procedure

Any party with a Bitcoin full node and a TAP indexer can compute the canonical $BIT state independently:

1. For every h ∈ [0, tip], read nBits(h) via the standard RPC getblockheader; parse the returned hex string as a 32-bit unsigned integer.
2. Read all TAP-relevant inscriptions in the same range, in canonical confirmed order.
3. Apply δ from §5.2, gated by V from §6.1, to derive σ.
4. The resulting σ.balances is the canonical $BIT distribution.

The procedure is reproducible, fully open, and depends on no third party. Note that none of it is special-purpose: every step is something a Bitcoin verifier already does, just read from a slightly different angle.

The claim is stronger than mere viability: $BIT is inevitable.

Once we accept that the bitsfield is a deterministic, public, immutable structure inside every Bitcoin block; that DMT is a coherent framework for tokenizing structures of this kind; and that TAP provides a working substrate for DMT issuance on Bitcoin L1, then sooner or later someone was going to deploy the most natural token of the field. By “most natural” we mean a deploy whose pattern preserves the field value verbatim, and whose ticker simply is the field. TAP tickers are unique-on-first-deploy, and there is exactly one ticker "bit". So there is, and can only be, one $BIT.

The etymological identity is not incidental either. The Bitcoin protocol contains a field called bits; the Bitcoin protocol's name derives from bit. The word came from Tukey in 1947; Shannon ratified it for information theory the next year; Satoshi spent it in 2008 to name his electronic-cash system. Bitcoin's bits field is the structural manifestation of that lineage, sitting inside every block. A permissionless DMT-11 token whose pattern is the identity and whose name is the field itself closes the loop: the bit of Bitcoin, finally tokenized.

What was always present is, finally, also legible.

$BIT introduces no new state. It needs no new infrastructure and no one's promise to function. Its supply curve was written, block by block, by every miner who ever found one of them. Its name has been kicking around for almost eighty years, from Tukey to Shannon to Satoshi. And its issuance rule is a one-line equation, read straight off of Bitcoin's chain.

The smallest unit of money was always, also, the smallest unit of information. The bits Bitcoin has spent seventeen years writing into every header are not a side product of mining; they are the actual substance the chain has been signing, four bytes at a time, for every block since genesis. $BIT just reads them out.

The bit was always there. $BIT names it.