Quote from: achow101 on May 07, 2025, 02:03:41 AM

No good, easy to sybil attack. If someone wants it badly enough, they can spin up enough nodes to be 70% of the network.

I'm thankful you shared that. Such a solution would need to be paired with extra code for resistance to sybil attack, which might not be worth adding to get such a feature.

Quote from: achow101 on May 07, 2025, 02:03:41 AM

Mining is already a consensus mechanism, what you want is to change the consensus rules that everyone follows. There were a few ideas mentioned on the mailing list on this topic, but ultimately what it comes down to is trading the flexibility of script for rigidity in ensuring that all UTXOs can be spent. Essentially, the mechanism for doing this would be to require that every output also carry a proof that the output is spendable, i.e. a signature. However, this severely limits what script can do, to the point that script wouldn't really exist. I think there would be a lot of additional logistical nightmares as well (e.g. senders and receivers now need to coordinate in order for the sender to make a transaction).

Furthermore, this wouldn't even stop data storage in Bitcoin. Sure it would make it harder, but steganography is an entire field dedicated to hiding data in things that are not meant to store such data. It would still be fairly easy to shove data in bits and pieces into pubkeys and hashes, it just takes a little bit of work to grind a couple bytes of a hash or pubkey to be the data that you want to embed. And since this is extra inefficient, the instances of this data would result in massive/lots of transactions.

Lastly, just because a UTXO is spendable by someone doesn't necessarily mean that it will be spent. So even with such a scheme, we could have tons of UTXOs that encode some data inefficiently, and someone is able to spend them, but ... maybe they just don't, and they still have polluted the UTXO set.

It is good that mining already has a consensus mechanism, making sybil attacks cost more. It sounds like the solutions mentioned so far would not be worth adding due to creating more problems than they solve. Thank you for sharing.

Quote from: ABCbits on May 07, 2025, 09:38:32 AM

FWIW, cost to run Bitcoin full node is much lower than cost to run node for current top 100 altcoin by market cap.

Bitcoin rocks! I was distracted by altcoins when first finding out about bitcoin, and had to learn over time that bitcoin is still the best for many things.

Quote from: ABCbits on May 07, 2025, 09:38:32 AM

While it's theoretically possible to propose extreme fork which do these,
1. Treat script OP_FALSE OP_IF ... OP_FALSE as invalid.
2. Add size limit to script size.
3. Treat OP_RETURN with data bigger than X bytes as invalid.
4. Treat new UTXO that contain less than X satoshi as invalid.

Such fork is very unlikely to be accepted. And if it does, some spammer will continue to add arbitrary data using fake address at higher cost.

In my opinion, that's a great feature of bitcoin. It prevents a lot of bad code changes from getting introduced.

Quote from: ABCbits on May 07, 2025, 09:38:32 AM

Quote from: pokeybear on May 06, 2025, 11:26:52 PM

Is it possible to detect transactions that contain large UTXOs, large numbers of public keys (some may be fake, and we don’t know which ones are fake), or other attributes that may identify a transaction as harmful?

AFAIK no. Although i recall there were few discussions here that talks about theoretician address format which make fake public key/address become more expensive.

I'll have to look for some of those discussions. It sounds interesting.

Quote from: gmaxwell on May 07, 2025, 10:11:02 PM

... Aside, the term is miner not minor-- the confusion is understanble, both are known to play with blocks.

Excellent catch! I went back and edited just the spelling of miner in my original post.

I'll read through and ponder the rest of your post as soon as I can. There are great points in there! I am grateful to you and the others for discussing these ideas with me.

[moderator's note: consecutive posts merged]