The current anti-spam debate around Bitcoin — ordinals, inscriptions, large witness blobs — is almost entirely framed around block space waste and UTXO set pollution. Fair concerns. But the conversation is missing something more uncomfortable.
Taproot allows embedding arbitrary byte payloads inside tap leaves, revealed on spend, processed by the script interpreter. Ordinals do exactly this: stuff up to ~4MB of raw bytes into a witness via an OP_FALSE OP_IF ... OP_ENDIF envelope. Nodes that validate these transactions run that witness data through Bitcoin Core's C++ script parser.
That parser processes untrusted, attacker-controlled bytes. Bitcoin Script's VM design is sound — no syscalls, no heap writes, no indirect dispatch. But the VM is implemented in C++, which has no memory safety by default. A carefully crafted tapscript leaf could, in principle, trigger a heap overflow or integer corruption in CScript::GetOp() or the opcode dispatch path — and at that point, the script sandbox is irrelevant. You're in the C++ runtime. Shellcode could be sitting in the same witness blob, ready to execute in the context of bitcoind.
This is not a theoretical curiosity. It is a textbook attack class: parser confusion → memory corruption → arbitrary code execution, with the payload and the trigger colocated in a single transaction. Every validating node that processes the transaction is a target.
Bitcoin Core mitigates this through fuzzing, bounded script sizes, and increasingly safe C++ patterns. Those mitigations are real. But they are implementation-level defenses against an architectural exposure that grows with every new opcode, every expanded witness limit, every reserved annex byte that gets activated.
The passive anti-spam movement is worried about bytes. It should at least acknowledge it is also implicitly negotiating the parser attack surface of every node on the network.
That seems worth saying out loud.