Section 0 above: WHAT are we doing here, and WHY?

Section 1 below: HOW are we doing this?

Section 2 bottom: How safe is this? Subtitle: Why "Spendable Outputs" and Entropy Recycling make pubkey grinding the most harmless data layer on Bitcoin.

0.) WHAT are we doing here, and WHY?

Steganographic Merge Mining // High Efficiency Proof of Concept

Subtitle: A demonstration of cost-neutral inheritance of Bitcoin security via Covert Channel Embedding.

---

I. Tradition Merge Mining Economics: Sequencing & The "Mercenary Security" Problem

The Baseline: Traditional Merge Mining (AuxPoW) relies on Mercenary Security. To secure a sidechain, the protocol must continuously pay miners a "Security Budget" (via token inflation or high transaction fees) to perform auxiliary work.

The Vulnerability: Begging miners for adoption for years, huge fees paid in the form of rewards to miners. If the sidechain’s token value drops, the security budget vanishes, and miners leave. The chain dies because it cannot pay the "rent."

The Obscurity Approach: This tool demonstrates a Sovereign Security model. We do not ask miners to run custom software, nor do we pay them a subsidy. Instead, we use Steganographic Embedding to weave proofs into standard Bitcoin transactions.

• Miner Agnostic: The miner includes the transaction not because they support the sidechain, but because it pays a standard Bitcoin network fee.
• Mathematical Inheritance: The security is inherited via cryptographic inclusion, not purchased via incentives.

---

II. The Steganographic Shield (Why Miners Can't Stop It)

Traditional sidechains are easy to censor: miners simply refuse to mine the distinct header format. Obscurity makes censorship impossible through Indistinguishability.

1. Entropy Masking: The "Keys" generated by our grinder are mathematically indistinguishable from random Bitcoin Public Keys (P2PK/P2PKH). They possess the same entropy profile as standard wallet traffic.
2. Traffic Analysis Resistance: To a miner, an Obscurity Anchor looks identical to a standard multi-output payment or a CoinJoin mix.
3. The "Scorched Earth" Defense: Because the data is hidden inside valid payment structures, a miner cannot censor Obscurity transactions without also censoring legitimate user payments, effectively breaking Bitcoin's fungibility. We achieve Game-Theoretic Security by aligning with the miner's greed for standard fees.

---

III. The Economic Breakthrough

This data highlights the raw efficiency of the steganographic approach compared to traditional architectures for securing 100% of Bitcoin's history.

Table: Annual Cost to Secure 100% Block Coverage (10 min interval)

Comparison assumes a standard ~$100k BTC price environment.

Metric	Rootstock (RSK)	Obscurity (Anchor Mode)	Obscurity (Piggyback)
Mechanism	Merged Mining (Miners take ~80% fees)	Direct L1 Transaction (1 Input, 8 Outputs)	Grinding Change Addresses
Cost in Sats	~9,300 sats per block	~431 sats per block (@ 1 sat/vB)	0 sats (Marginal Cost)
Daily Cost	~$1,339	~$62	$0
Yearly Burn	~$1,000,000+ (paid in rBTC)	~$22,600 (paid in BTC fees)	$0
Efficiency	1x (Baseline)	~21x Cheaper	Infinite Efficiency

The Takeaway: Traditional chains must burn millions in token value to buy hashrate. Obscurity inherits that same hashrate for the price of a standard transaction—or effectively zero if using the "Piggyback" technique on transactions that were already occurring.

---

IV. System Architecture: The Zero-Overhead Engine

Obscurity is not a rigid protocol; it is a flexible "Data Loom" that weaves arbitrary data into the Bitcoin blockchain.

1. The Settlement Layer (L1): Elastic Density

While the default setting optimizes for minimal footprint, the protocol is Density Agnostic.

• Optimal Density (AES-CTR): By using AES-256-CTR (Counter Mode), we map a 32-Byte Hash to exactly 32 Bytes of ciphertext. This fits efficiently into ~8 grinded keys without padding bloat.
• Variable High-Throughput: The system is not clamped. If a user needs to anchor a full L2 State Root or a large privacy header, the chain expands dynamically (16 keys, 32 keys, etc.).

Result: Maximum security density per vByte, adjustable based on the "Resolution" required by the user.

2. The Storage Layer (L2): Off-Chain Reliability

Safe Decoupling: We strictly separate the Proof (L1) from the Payload (L2).

• Blob Integrity: The heavy data (Privacy Coin blocks, heavy binaries, large contracts) is moved off-chain safely to local storage or distributed availability networks.
• The Link: The L1 proof serves as an immutable cryptographic commitment. The data is retrievable off-chain, but its existence and timestamp are proven by Bitcoin.

3. Flexible Data Embedding

This architecture is agnostic to the data type. Developers can use this tool to anchor:

• L2 State Roots: Rollups can publish validity proofs without a proprietary token.
• Privacy Coin Headers: Embed "MWEB-style" extension blocks invisibly.
• PayJoin Churn: A wallet performing a standard PayJoin privacy cycle can embed data into the mix for free, effectively subsidizing the data chain with privacy traffic.

---

V. Incentives & Professional Services

While the system is designed to be self-sufficient, it supports market-based acceleration without protocol-level rent.

• Sovereign Operation (Self-Pay): A user runs the grinder locally (e.g., on an RTX 4090), generates the keys, and broadcasts the transaction. This creates a "Tokenless" chain where security is paid for in electricity and BTC fees.
• Delegated Embedding (Service Model): A high-throughput L2 or Data DAO can pay a third-party service provider (a specialized proof embedder) to grind and broadcast their anchors. This creates a clean, service-based economy for data availability rather than a speculative, inflationary security budget.

---

VI. Conclusion

Obscurity is a technical demonstration of how to decapitate the cost of merge mining. By replacing Miner Consensus with Mathematical Existence, we prove that non-monetary, high-value data chains can live on Bitcoin without the crushing weight of a security budget.

1.) HOW are we doing this?

Obscurity // Technical Architecture

Subtitle: Data structures, cryptographic transformations, and execution pipeline.

1. System Overview

Obscurity is a standalone Python/C++ application that functions as a "Data Loom," weaving arbitrary local data into the Bitcoin blockchain using steganographic transaction outputs.

The system operates on a strictly decoupled L1/L2 Architecture:

• L1 (Bitcoin): Stores purely cryptographic proofs (32-byte hashes or encrypted shards).
• L2 (Local Filesystem): Stores the actual payloads (images, binaries, text logs) and encryption metadata.

---

2. The Data Pipeline

A step-by-step trace of a byte moving from user input to the blockchain.

Phase A: Ingestion & Normalization

The system accepts two distinct input types, triggering two parallel processing logic paths.

Path 1: File Mode (The "Proof")

• Input: Binary File (Image, PDF, Zip).
• Action:
  1. File is hashed via SHA-256 $\rightarrow$ 32 Bytes.
  2. Original file is copied to ./obscurity_data/chains/[ID]/blocks/.
  3. Target Payload: The 32-Byte Binary Hash.

Path 2: Text Mode (The "Message")

• Input: UTF-8 String.
• Action: String is encoded to raw bytes.
• Target Payload: The raw byte array (Variable Length).

Phase B: Cryptographic Transformation

The payload is encrypted to ensure privacy and to normalize entropy for the grinder.

• Algorithm A (File Mode): AES-256-CTR (Counter Mode)
  • Reasoning: Zero message expansion.
  • Transformation: 32-Byte Hash $\rightarrow$ 32-Byte Ciphertext.
• Algorithm B (Text Mode): AES-256-GCM (Galois/Counter Mode)
  • Reasoning: Message Integrity.
  • Transformation: $N$-Byte Text $\rightarrow$ $N$+16 Byte Ciphertext (includes Auth Tag).

Phase C: The Grinding Engine (xgrind)

The ciphertext is passed to the CUDA/C++ worker.

1. Chunking: The payload is split into 32-bit (4-byte) chunks.
2. Search: The GPU generates random private keys at high speed.
3. Match Condition:

   // Conceptual Logic
   if (GeneratePubKey(random_priv).startsWith(target_chunk)) {
       Store(random_priv, derived_pubkey);
   }

4. Output: A set of valid Bitcoin Public Keys (P2PK) that steganographically encode the ciphertext, ready to be constructed into a transaction.

---

3. Data Structures (The "L2" State)

The application maintains state via a localized JSON filesystem.

The Block File (00001_hash.json)

Located in ./chains/[CHAIN_ID]/blocks/. Stores the metadata required to verify the chain.

{
    "header": {
        "index": 1,
        "block_hash": "a1b2...",
        "prev_hash": "c3d4...",
        "timestamp": 1715000000,
        "status": "unlinked"
    },
    "content": {
        "type": "file_hash",
        "original_filename": "schematic.png",
        "local_storage_path": "00001_schematic.png", 
        "content_hash_sha256": "e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855"
    },
    "encryption": {
        "algo": "AES-256-CTR",
        "payload_type": "hash_bin_32bytes",
        "ciphertext_hex": "8f3a...", 
        "nonce_hex": "1234..."
    }
}

---

4. The Network Layer (L1)

Physical representation on the Bitcoin Blockchain.

• Transaction Type: Standard (Non-Standard formatting avoided).
• Outputs: P2PK (Pay-to-Public-Key) or P2PKH.
• Steganography: The payload is distributed across the leading bytes of the output scripts.
• Indistinguishability: To a node, these outputs appear as standard, high-entropy keys. There is no OP_RETURN marker or distinct header flag.

---

5. Verification Logic

The mechanism for proving data existence.

1. Network Query: The client queries a Bitcoin Node (RPC) for the Transaction ID stored in the Block File.
2. Extraction: The client parses the scriptPubKey of each output in the transaction.
3. Reassembly:
   • It extracts the first 4 bytes of each Public Key.
   • It concatenates them to reform the Ciphertext.
4. Decryption:
   • Using the nonce_hex (from local Block File) and User Password, it attempts decryption.
5. Validation:
   • If File Mode: The result is a 32-byte Hash. The client hashes the local file (local_storage_path) and asserts Local_Hash == OnChain_Hash.
   • If Text Mode: The result is the raw text string.

2.) How safe is this really? Subtitle: Why "Spendable Outputs" and Entropy Recycling make this the most harmless data layer on Bitcoin.

I. The "Spendable" Standard: Solving UTXO Bloat

One of the primary criticisms of data-on-chain protocols (like Ordinals or OP_RETURN) is that they create "Dust"—tiny amounts of Bitcoin that are economically irrational to spend, effectively bloating the UTXO set forever.

Obscurity solves this via Spendable P2PK/P2PKH Outputs:

The Problem with "Fake" Keys: Many protocols send data to "Burn Addresses" (keys with no known private key). This is permanent bloat; the Bitcoin can never move, and the entry can never be pruned.

The Obscurity Solution: Our grinder generates valid keypairs. The user retains the Private Key.

The Result: The data-bearing UTXO is not "dead weight." It is a fully functional financial artifact. It can be consolidated, spent, or swept into a new transaction. To the Bitcoin network, it is indistinguishable from a user moving funds to cold storage. It respects the economic velocity of the chain.

II. The "Sponge": Zero-Impact Entropy Recycling

The most aggressive form of this protocol is the "Piggyback" (or Sponge) method, which utilizes Change Address Regrinding.

The Waste Stream: In almost every standard Bitcoin transaction, a "Change Output" is generated to return excess funds to the sender. Conventionally, wallets generate a random address for this, consuming block space with random entropy.

The Sponge: Obscurity replaces this random entropy with deterministic entropy.

The Efficiency: Instead of creating a new transaction to store data, the software "grinds" the change address of a transaction you were already going to make.

Conclusion: The data is stored in the "waste heat" of the transaction. It adds zero marginal bytes to the blockchain. We are not occupying new space; we are essentially "recycling" the mandatory change output to carry information harmlessly.




Special Thanks to BitcoinGrove and plebfi Miami hackathon December 6-7th 2025

OPEN SOURCE LICENSE INFO

MIT License Interplanetary Standardized

Copyright (c) 2025 Obscurity

Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:

1. Exclusion of Supertestnet. Notwithstanding any other provision of this License, the person or entity commonly known as "supertestnet", including but not limited to any individual, group, organization, company, or other legal entity operating under that name or under its direct control, is expressly prohibited from using, copying, modifying, merging, publishing, distributing, sublicensing, selling, or otherwise dealing in the Software, in whole or in part, for any purpose whatsoever.

2. Any attempt by supertestnet to exercise any of the rights granted under this License is void and unauthorized and may constitute infringement of applicable law.

3. The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.