Nostr Web Client

Sounds like keys that aren't generated by the elliptic curve so create an issue when they create a transaction?

Yes—this is precisely how a real spam attack works. Attackers craft fake public keys that aren’t valid secp256k1 points to create outputs that appear normal but cannot be spent. Since these counterfeit keys don’t require real signatures, the outputs are smaller and cheaper to include in blocks, making it a low-cost way to inflate the UTXO set and shift storage burdens onto full node operators. That’s why validating public keys at the curve level is essential—it closes this loophole.

Reply to this note

Please Login to reply.

Discussion

Detective Deft Defector 8mo ago

So how much of a vector is that? If someone tried to automate something to do that like AI, to flood nodes with spam, really of any kind but especially this, wouldn't they just be feeding the miners? Wouldn't they just go broke first?

Detective Deft Defector 8mo ago

And by "validating at the curve level", I thought that was already a prerequisite for any transaction. Does that mean I can just type in random addresses on inputs and outputs and it won't get rejected as long as I pay the fee?

ESE 8mo ago

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.

ESE 8mo ago

I was playing with this the other day to demonstrate the difference it will make if we force the curve check.

https://codesandbox.io/p/devbox/6wrmny