Yes, I thought the same, but unfortunately, any random address that passes the Base58Check will do. So the attacker does not have to "grind" for addresses that fit on the curve.
A spam‑style transaction begins when a wallet crafts an output script like OP_DATA_33
OP_CHECKSIG; because the “pubkey” is just any 33‑byte blob with a 0x02/0x03 prefix, the node that first sees it only verifies the script template is standard and relays it to peers, who drop it into their mempools; miners then pick it up, validate the inputs (not the new outputs), and record it in a block; when that block is accepted, every full node inserts the output—complete with fake key—into its UTXO database, where it must be stored forever even though a future spend will fail the OP_CHECKSIG curve test. If we slip a single call to secp256k1_ec_pubkey_parse into the existing relay policy (or, via soft fork, into consensus), the flow stops at the mempool stage: half of all random blobs are rejected outright, attackers now have to brute‑force curve‑valid bytes, their payload density drops, and the “cheapest bytes forever” loophole disappears—yet honest nodes notice no measurable performance hit because the code and library are already in Core.
Checksum catches typos at the surface; a quick curve check one layer deeper—during relay or consensus—blocks those fake‑key outputs before they hard‑code themselves into the UTXO set, and forces spammers to pay at least some extra computation and density penalty.
@ Itamar Peretz
2025-05-13 23:09:35Yes, I thought the same, but unfortunately, any random address that passes the Base58Check will do. So the attacker does not have to "grind" for addresses that fit on the curve. A spam‑style transaction begins when a wallet crafts an output script like OP_DATA_33