Why Counterparty’s Fake-Pubkey Grinding Reveals the Real Boundary Between Bitcoin Consensus and…
Bitcoin is not a state machine. It is a verifiable sequence of events. "Event Machine Letters - Protocol Thoughts on Bitcoin's Architecture" begins here. Enter fullscreen modeExit fullscreen. . .
Bitcoin is not a state machine. It is a verifiable sequence of events. "Event Machine Letters - Protocol Thoughts on Bitcoin's Architecture" begins here. Enter fullscreen modeExit fullscreen modeIntroductionWhile writing Chapter 5 of my bookHow People Tried to Push Non-Transaction Data into Bitcoin, I fell into a technical rabbit hole: How did Counterparty manage to store structured payloads inside bare multisig outputs?The answer turned out to be more interesting than expected — not because of multisig itself, but because Counterparty’s “fake-pubkey grinding” exposes a deep and often misunderstood distinction in Bitcoin:Consensus guarantees possibility. Policy guarantees sanity. Most debates around Bitcoin protocol behavior (including recent ones) come from mixing these two layers together. Counterparty provides a perfect historical case study for why this distinction matters. 1. Counterparty’s Hack: Multisig as a Data ContainerCounterparty (2014) was the first protocol to systematically embed arbitrary data in Bitcoin by encoding payloads inside fake public keys placed in a 1-of-3 bare multisig output:OP_1OP_3OP_CHECKMULTISIGEnter fullscreen modeExit fullscreen modeThe fake pubkeys contained 64 bytes of payloadThe real pubkey ensured the output was theoretically spendableOP_RETURN carried only the instruction headerMultisig carried the full structured payloadThis design allowed Counterparty to break through the ~80-byte OP_RETURN limit and support more complex protocol messages. But it also forced Counterparty to confront Bitcoin’s deepest rules. 2. Why Fake Pubkeys Must Be Valid EC PointsAt first glance, one might think:“If Counterparty never plans to spend these outputs, who cares if the pubkeys are valid?”Bitcoin cares — a lot. Before a transaction can enter the mempool, Bitcoin Core performs a full consensus-level script validity check. This check ensures:The script is syntactically validNo opcode triggers immediate failureEvery pubkey is a valid secp256k1 pointCHECKMULTISIG would not immediately errorBitcoin does not allow an output that is provably unspendable due to script error. That would violate consensus rules, not policy. Thus:Even if no one will ever spend the output, fake pubkeys still must be on the secp256k1 curve. This is why Counterparty clients had to grind fake pubkeys:Grinding =Search for an x-coordinate that:Encodes the payload (high bits), andProduces a valid curve point (low bits adjusted until valid)Only such points can be accepted into the mempool and relayed across the network. Without a valid EC point, the transaction never broadcasts — it fails before policy even enters the picture. 3. Consensus vs. Policy: What Counterparty Accidentally Taught UsCounterparty’s architecture forces us to confront the difference between two layers often confused in Bitcoin debates. Consensus Layer: Strict Logic, Wide PermissionConsensus rules guarantee:Every output is theoretically spendableScript execution will not immediately errorPublic keys are validCHECKMULTISIG would not produce ScriptErrorScript semantics are self-consistentConsensus does not care:whether an output will ever be spentwhether the pubkey is used as a data containerwhether the protocol “abuses” Bitcoinwhether it’s storing JPEGs or metadatawhether users are burning dust foreverBitcoin consensus is maximalist in a very precise way:If your pubkey is valid and your script is internally consistent, consensus says “Yes. ”It is rule-bound but not value-judging — almost Confucian in spirit. Policy Layer: Pragmatic, Local, ProtectivePolicy rules — Bitcoin Core’s mempool rules — are not consensus. They exist only to prevent node DoS and spam. Policy restricts:bare multisig relaymultisig N rangesdust thresholdsOP_RETURN sizesnonstandard script formsThese rules:vary between node implementationsdo not affect the blockchaindo not define Bitcoin’s consensusonly determine whether the transaction is relayed and mined easilyThis is why Counterparty eventually became marginalized:Consensus allowed itPolicy discouraged itBare multisig became a disfavored pattern, even though it remains fully valid at the consensus layer. 4. The Real Insight: Bitcoin Allows Abuse at Consensus, Discourages It at PolicyCounterparty sits precisely at the intersection of the two:Consensus:“That fake pubkey is a valid secp256k1 point? Then this multisig output is fine. ”Policy:“Don’t fill the UTXO set with garbage. We may choose not to relay this. ”Users:“These outputs are dust. We’re never spending them anyway. ”Thus, Counterparty becomes:Consensus permissiveness ×Policy defensiveness ×User economic behaviorIt’s far more than a curiosity of early NFT history. It’s a case study in how Bitcoin’s layered design produces emergent behavior. 5. Why This Distinction Matters TodayA surprising number of recent Bitcoin debates — OP_RETURN policy changes, Ordinals arguments, BitVM anchoring, and even knothole discussions — stem from the same misunderstanding:People mix up consensus rules (what is allowed) with policy rules (what is relayed or encouraged). Counterparty’s fake-pubkey grinding is the earliest and clearest reminder of this separation. Understanding it is essential for understanding Bitcoin’s evolution — and the fights that continue around it. ConclusionCounterparty wasn’t just a creative hack for storing data in Bitcoin. It was the first protocol to unintentionally illuminate the boundary betweencanandshould, between consensus and policy. And many misunderstandings in today’s discussions remain unsolved simply because this boundary is still not widely understood. If we want to reason clearly about Bitcoin’s future, this distinction is the place to start. ByAaron RecompileonNovember 24, 2025. Canonical linkExported fromMediumon July 3, 2026.