- Learn
- The-market
- Specifications
SNIP-04: Raw Printing & AuxPoW
Status
Draft
Abstract
This specification defines the standard formatting for packaging Merged Mining (AuxPoW) block headers into standalone, verifiable payloads.
By embedding proof-of-work Merkle branch data into Nostr objects (Kind 35510), SNIP-04 provides validators with direct cryptographic access to the raw execution logic required to authenticate a printed Sharenote.
Solo miners and independent proxies use Kind 35510 to publish raw printing events — without a pool accounting pipeline (SNIP-03). This is the primary path for miners operating independently.
Cryptographic Header Payloads
When a note is printed, the broadcasting agent provides the unparsed header encoded in hex via the dd tag. Validators hash this hex to confirm it results in d (HeaderHash) and satisfies the leading-zero bounds dictated by z (Sharenote denomination).
Tag Structure:
| Tag | Format | Required | Description |
|---|---|---|---|
d | ["d", "<HeaderHash>"] | Yes | Block header hash. Unique identifier for the sharenote. |
a | ["a", "<address>", "<worker>", "<agent>"] | Yes | Miner attribution: chain address, worker name, and user-agent string. |
z | ["z", "<label>"] | Yes | Sharenote denomination label, always lowercase (e.g., "34z10"). |
w | ["w", "<BlockHash>", "<ChainID_hex>", "<Height>", "<Solved>", "<Label>"] | Yes | Auxiliary block entries (see below). One or more required. |
dd | ["dd", "<HeaderHex>"] | Yes | Full block header encoded as hex. Always the last tag. |
Example:
[
["d", "0000000000000000abcd1234..."],
["a", "fc1qxyz...", "antminer-s19", "bmminer/2.0.0"],
["z", "34z10"],
["w", "000000ab...", "15", "843000", "true", "40z00"],
["w", "000001cc...", "2a", "110000", "false", "34z10"],
["dd", "0100000081cd02ab..."]
]
(The a tag must include the routing address so the worker can optionally be compensated.)
Validation rule: Compute the double-SHA256 of dd, confirm it equals d, then check that the leading zeros satisfy z.
Merged Mining (AuxPoW) Subsidiaries
A single hash execution can solve multiple independent blockchains if their targets are met concurrently. To map these subsidiary proofs, the event includes an array of w tags.
The primary chain w tag MUST appear first, followed by auxiliary chain entries.
[
["w", "<BlockHash>", "<ChainID>", "<Height>", "<Solved>", "<Label>"],
["w", "000000ab...", "15", "843000", "true", "40z00"],
["w", "000001cc...", "2a", "110000", "false", "34z10"]
]
Tag Definitions:
| Field | Description |
|---|---|
[1] BlockHash | The auxiliary target hash. |
[2] ChainID | Hex-encoded integer network ID (e.g., "15" for decimal 21). |
[3] Height | Chain block height as a decimal integer. |
[4] Solved | Boolean string ("true" or "false") indicating whether this hash reached the network subsidy target (true), or only passed the lower Sharenote boundary (false). |
[5] Label | The Sharenote difficulty label for this branch (lowercase). |
Rationale
Embedding raw Merkle branch data directly in the Nostr event enables any third party to independently verify the proof-of-work without contacting the original miner or pool. The Kind 35510 payload is self-contained and cryptographically complete.
Vibe Coding Integration
Builders do not need to manually construct or validate raw Kind 35510 block headers. By invoking npx skills add soprinter/skills, your AI assistant natively understands the AuxPoW merkle specifications outlined in this document.