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 look normal but can never be spent. Since these counterfeit keys don’t need real signatures, the outputs are smaller and cheaper to include in blocks, making it a low-cost way to bloat the UTXO set and push storage burdens onto full node operators. That’s why validating public keys at the curve level is essential—it closes this loophole.
Discussion
But many addresses are a hash of the public key, so we cannot validate the public keys when transactions are paying money to them. For these addresses it is impossible to filter based on public key until it is revealed, at time of spending, which requires them to be real and not spam!
Though I haven't thought about this wrt P2TR, and was somewhat surprised to see point validity isn't enforced:
https://github.com/bitcoin/bitcoin/pull/24106
I think id rather the spammers use invalid secp points! A nice broom to have up the sleeve? Can easily patch into a node to sweep out all the invalid ones from the utxoset.
It is super easy to generate these "fake" secp256k1 points which are valid:
02b33fb33fb33fb33fb33fb33fb33fb33fb33fb33fb33fb33fb33fb33fb33fb33f
```rust
use rand::{RngCore, thread_rng};
use secp256kfun::{
Point, hex,
marker::{NonZero, Public},
};
fn main() {
let mut rng = thread_rng();
let hex_str = "b33fb33fb33fb33fb33fb33fb33fb33fb33fb33fb33fb33fb33fb33fb33f";
let hex_bytes = hex::decode(hex_str).expect("invalid hex string");
loop {
let mut random_bytes = [0u8; 64];
rng.fill_bytes(&mut random_bytes);
let my_point_bytes = {
let mut bytes = [0u8; 33];
bytes[0] = 0x02; // start with 02
let hex_len = hex_bytes.len().min(32);
bytes[1..1 + hex_len].copy_from_slice(&hex_bytes[0..hex_len]);
// fill the rest with random bytes
if hex_len < 32 {
bytes[1 + hex_len..33].copy_from_slice(&random_bytes[0..32 - hex_len]);
}
bytes
};
let point = Point::<_, Public, NonZero>::from_bytes(my_point_bytes);
match point {
Some(valid_point) => {
println!("Random valid point: {:?}", valid_point);
}
None => {
eprintln!("Invalid point from bytes: {}", hex::encode(&my_point_bytes));
}
}
}
}
```
A spam‑style transaction begins when a wallet crafts an output script like OP_DATA_33
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.
Yeah not sure i am convinced of the reasons in that issue to **not** filter these, but i am thinking there may be value to the fact that this filter could be created at any time in the future, clear out a large chunk of the UTXO set after they have wasted their sats. Depends if how bad you consider the spam, is it about utxoset bloat or want to filter their existence in blocks
I feel the same way; I'm still trying to grasp this situation. In a surprising turn of events, the entire OP_RETURN debacle has become a blessing. As we can see from this discussion and the node charts, more and more people are becoming educated about spam issues, with the number of knots gaining momentum. 🫡💪🪢
Has been great discussing this - got me thinking deeply and I found a bug in one of our cryptography libraries while exploring valid secp256k1 points! I haven't looked into knots really, semi dismissed it a while ago when i first saw this nuts counting system was supported(?)
By the way, your product looks amazing! I can't wait to try it!
Making the pubkey curve‑valid doesn’t bypass the fix, because once every key has to sit on secp256k1, spammers must brute‑force each payload byte, turning their zero‑cost UTXO bloat into an exponentially expensive grind