What is your take on Bitcoin Knotz? Bitcoin node and wallet by Luke Dashjr

[headingnorth]

The coming changes to Bitcoin Core would force node runners to host all kinds of garbage including images of child pornography
and other useless or even illegal material. That is no exaggeration. Since it is against the law to host CP on your computer every node runner
would become potential targets of the criminal justice system, through no fault of their own. Which is why I switched to Knots long ago.

This would provide governments with a legal justification to shut down bitcoin completely or at least outlaw it in their respective country.  

This is not true. Neither developers nor other users would be responsible for CP on bitcoin. It is the same with freenet and other p2p networks.

It doesn't matter if individual node runners are prosecuted or not.
CP on bitcoin can be used as a justification to shut bitcoin down or make it illegal.

The laws on this issue vary by state and country, and laws can change at any minute especially
in regards to a relatively new technology like bitcoin.

Regardless of the legality, the negative publicity would be extremely damaging to bitcoin when the public
starts associating bitcoin with child pornography. It is an incredibly stupid and pointless risk to take with zero benefit.
Bitcoin already has plenty of haters, why give them more ammunition? You are handing them a gift.

These retarded changes do nothing to improve bitcoin as a monetary asset. Bitcoin is currency, not a fucking vehicle for
random image hosting. Why are idiots so hellbent on turning bitcoin into Instagram or OnlyFans? It is truly bizarre.

Fortunately, Bitcoin Knots has exploded from less than 1% to 20% of the nodes since the pull request was announced.
And its share will only keep growing. Very few will be upgrading to Core 30 when it is released.

Since there is no consensus, I would be surprised if Core 30 ever reaches more than 10% of all the nodes.
The other 90% will consist of Bitcoin Core 29 and Knots.

[Wind_FURY]

The coming changes to Bitcoin Core would force node runners to host all kinds of garbage including images of child pornography

and other useless or even illegal material. That is no exaggeration. Since it is against the law to host CP on your computer every node runner
would become potential targets of the criminal justice system, through no fault of their own. Which is why I switched to Knots long ago.

This would provide governments with a legal justification to shut down bitcoin completely or at least outlaw it in their respective country.  

This is not true. Neither developers nor other users would be responsible for CP on bitcoin. It is the same with freenet and other p2p networks.

It doesn't matter if individual node runners are prosecuted or not.
CP on bitcoin can be used as a justification to shut bitcoin down or make it illegal.

In your opinion, that may be the situation. At best, that's merely theoretical because it probably is easier to shut down those shitcoin networks which actually encourage dick pics and fart sounds. BUT in practice, none of that happened.

The laws on this issue vary by state and country, and laws can change at any minute especially
in regards to a relatively new technology like bitcoin.

The law also states that intent matters.

Regardless of the legality, the negative publicity would be extremely damaging to bitcoin when the public
starts associating bitcoin with child pornography. It is an incredibly stupid and pointless risk to take with zero benefit.
Bitcoin already has plenty of haters, why give them more ammunition? You are handing them a gift.

Concern trolls LOVE to use THAT as their argument. But Bitcoin continues chugging along, producing block after block despite all of the FUD.

Nation-States are buying in, by the way.

  

These retarded changes do nothing to improve bitcoin as a monetary asset. Bitcoin is currency, not a fucking vehicle for
random image hosting. Why are idiots so hellbent on turning bitcoin into Instagram or OnlyFans? It is truly bizarre.

Fortunately, Bitcoin Knots has exploded from less than 1% to 20% of the nodes since the pull request was announced.
And its share will only keep growing. Very few will be upgrading to Core 30 when it is released.

Since there is no consensus, I would be surprised if Core 30 ever reaches more than 10% of all the nodes.
The other 90% will consist of Bitcoin Core 29 and Knots.

Who cares what YOU personally believe what Bitcoin "should be". If it could be something else that gives a person a sort of utility that he/she needs, then who are you to say that that's "not allowed".

       ¯\_(ツ)_/¯

[gmaxwell]

Fortunately even without any preferential peering it only takes a few percent of nodes to form a complete graph.  Not that I believe for a minute your forward-looking claims about people running knots (I just don't believe that many people are that foolish).

Long ago Gilmore wrote "The Net interprets censorship as damage and routes around it."  This statement was more aspirational than technically true,  but in Bitcoin we not only met that criteria but exceed it.  Bitcoin takes advantage of the nature of information being easy to spread but hard to stifle.

Idiots are free to run censorware, -- free to ignore the patiently argued points about their censorship being pointless and counterproductive.   Bitcoin will continue to interpert censorship whatever the motivation as damage and route around it.  And as the desperately failing censors up their malicious attacks via things like the "garbageman" connection flood attacks, defensive countermeasures will be deployed as required.

It's a bit sad though to have to waste resources dealing with this stuff when there are other areas that could benefit from improvement, e.g. resistance to illegal content attacks which the filtering does absolutely nothing for but which things like utxotree, pruning improvements, encryption improvements, or using FEC to split archive data across multiple nodes as I proposed years ago absolutely do help address.

[nutildah]

It doesn't matter if individual node runners are prosecuted or not.
CP on bitcoin can be used as a justification to shut bitcoin down or make it illegal.

This has been an argument for at least 10-12 years, and nothing ever became of it.

So you are out to destroy the block chain?
Absolutely the last thing that bitcoin needs is 7 billion ass clowns loading up the blockchain with pictures of their dog.

Oh… but wait…… What if some sick fuck uploads  kiddie porn onto the blockchain and then the  sickos start using it as a distribution network for kiddie porn as a guaranteed way to ensure distribution with  ZERO TRACEABILITY ,…. now……. every copy of the block chain held independently would be:

1. An excuse for WHY kiddie porn was on your computer. ( sorry officer , I was only using bitcoin)
2. An excuse for law enforcement to totally destroy the Crypto currency due to its association with the most vile of human beings.

There's no reason to assume something would become of it now, especially since you can't "shut bitcoin down." Its not possible. And with the massive institutional adoption + ETFs, bitcoin won't be made illegal any time soon, at least not in the countries with the most users/holders.

Furthermore, NO cryptocurrency has ever been shut down due to legal pressure, except for one, and that was Coinye, in 2014. But even then, after a cease-and-desist order by Kanye West, it never completely died.

Why are idiots so hellbent on turning bitcoin into Instagram or OnlyFans? It is truly bizarre.

LOL, live streaming on Bitcoin, I don't think you'll ever have to worry about that.

Fortunately, Bitcoin Knots has exploded from less than 1% to 20% of the nodes since the pull request was announced.

Except Knots doesn't actually do anything to stop this (as has been pointed out already).

Fortunately even without any preferential peering it only takes a few percent of nodes to form a complete graph.  Not that I believe for a minute your forward-looking claims about people running knots (I just don't believe that many people are that foolish).

According to coin.dance, 18.5% of all Bitcoin nodes are Knots nodes. I'm not sure if you believe them either though.

[ABCbits]

You're far too late to worry about it. More than 1 decade ago someone already push Wikileaks cablegate data on Bitcoin blockchain[1].

[1] https://www.reddit.com/r/Bitcoin/comments/1bw9xg/data_in_the_blockchain_wikileaks/

The difference is that you are much more likely to get prosecuted or at least deplatformed for hosting something illegal like malware or csam than  a leaked cable.

It is not just law enforcement involved here - it's also platforms' terms of service.

There is no legal precedent for this yet, but what happens if some litigious person in the mold of Craig Wright tries to sue users he/she doesn't like with this pretense?

It's just an example that i remember right away, there are all kinds of data stored on Bitcoin even since a decade ago[1]. Should i mention that research from few years ago discover some kind of content including hundreds link to child porn[2]? Should i also mention shortly after Ordinal launch, someone use it to add porn/explicit image[3]?

If you run non-pruned Bitcoin full node, your device already store such data.

[1] https://www.righto.com/2014/02/ascii-bernanke-wikileaks-photographs.html#ref14
[2] https://fc18.ifca.ai/preproceedings/6.pdf, section 4.3 Investigating Blockchain Files.
[3] https://crypto.news/bitcoin-ordinals-encounters-explicit-images-days-after-launch/

[headingnorth]

Idiots are free to run censorware, -- free to ignore the patiently argued points about their censorship being pointless and counterproductive.   Bitcoin will continue to interpert censorship whatever the motivation as damage and route around it.  And as the desperately failing censors up their malicious attacks via things like the "garbageman" connection flood attacks, defensive countermeasures will be deployed as required.

Patiently argued by who? Bozo the clown? LMAO.

In the bitcoin context, censorship resistance is referring to being able to execute monetary transactions without permission.
Anyone can use bitcoin to send and receive value (sats or bitcoins) without permission. It does not mean you are free to
upload pictures of monkeys, clowns, porn, bestiality, etc. onto the network as the bozos and buffoons of the world so desire.

It is called bit-COIN for a reason. The BIT part refers to it being digital while COIN refers to it being money.
Would you like me to draw you a picture with Crayola crayons? Bitcoin is DIGITAL MONEY, PERIOD.
It is not fucking spamcoin, monkeycoin, bozocoin, clowncoin, porncoin, pepecoin, fartcoin, shitcoin, etc.

[NotATether]

These retarded changes do nothing to improve bitcoin as a monetary asset. Bitcoin is currency, not a fucking vehicle for
random image hosting. Why are idiots so hellbent on turning bitcoin into Instagram or OnlyFans? It is truly bizarre.

If we zoom out, we can see that beyond the illegal images argument, there is another argument that can be made against smart contract functionality (turing-complete, so not HLTCs for example) on Bitcoin in general.

Ethereum and forks like Avalanche, BSC, Polygon already do a really good job at implementing smart contracts, and 99% of the smart contract codes and programmers are using one of those chains. So why the need to implement - partially at that - an inferior alternative?



I don't mean to sound like an ETH shill by the way. This line of thinking is common sense. These moves like datacarriers, OP_CAT and so on really only benefit Ordinals, Runes and similar. They don't benefit ordinary developers like us.

[gmaxwell]

First principle: It is not of you business how I use my money with other consenting parties.  You might not think it's useful. Good for you.   It's not your decision.

Second principle:  Smart contracting comes from BITCOIN. Those other systems are clones of Bitcoin, that chose to hype up some parts the copied or expanded on.  Their investors-- which may well include you-- routinely act to undermine Bitcoin.  Including perhaps, through subversive manipulation campaigns on social media to hobble bitcoin's functionality.

Third:  Those other systems are generally technically incompetent massively premined frauds.  They are objectively not good, their implementations have lost hundreds of millions of dollars through totally avoidable errors, including some that Bitcoin has solved since day one (like addresses having checksums).


 

These moves like datacarriers, OP_CAT and so on really only benefit Ordinals, Runes and similar.

How does the op_return stuff have anything to do with ordinals or benefit it in any way?  Why are you talking against OP_CAT in a thread promoting knots when luke has publicly committed to activating op_cat?

Back in the thread,

There was a proposal to implement a check that pubkeys must be "real" (i.e. be on an elliptic curve), which means additional ressources needed for tx validation, but it could be worth it if it really was a solution to the problem.

There are several fairly straightforward ways to transform arbitrary data to and from an indistinguishable valid pubkey.  One is in the bitcoin codebase already for the P2P encryption.  So what, permanently increase the validation cost of every txn by 1/4 or something to make the opponent copy and paste a bit of existing code?  So not only would that fail, it would also make things worse since at least now a node could expand its definition of unspendable outputs to include the ~half of these that aren't valid points and exclude them from their UTXO set.  But if blocked and then they move to adjusting the encoding so they're always valid points (or just changes to make them 256 bit "script hashes") this option goes away.   Keep in mind that none of the 'spammers' are particularly fee sensitive or they'd absolutely not use Bitcoin at all.

[Wind_FURY]

Idiots are free to run censorware, -- free to ignore the patiently argued points about their censorship being pointless and counterproductive.   Bitcoin will continue to interpert censorship whatever the motivation as damage and route around it.  And as the desperately failing censors up their malicious attacks via things like the "garbageman" connection flood attacks, defensive countermeasures will be deployed as required.

Patiently argued by who? Bozo the clown? LMAO.

In the bitcoin context, censorship resistance is referring to being able to execute monetary transactions without permission.
 
Anyone can use bitcoin to send and receive value (sats or bitcoins) without permission. It does not mean you are free to
upload pictures of monkeys, clowns, porn, bestiality, etc. onto the network as the bozos and buffoons of the world so desire.

It is called bit-COIN for a reason. The BIT part refers to it being digital while COIN refers to it being money.
Would you like me to draw you a picture with Crayola crayons? Bitcoin is DIGITAL MONEY, PERIOD.
It is not fucking spamcoin, monkeycoin, bozocoin, clowncoin, porncoin, pepecoin, fartcoin, shitcoin, etc.

OK, but you fail to understand the underlying, and what makes Bitcoin censorship-resistant. WHICH, if you do, it makes everything more complicated. It won't be merely about decentralized, censorship-resistant "money" anymore.

People may or may not agree in removing OP_RETURN limits, but Bitcoin is a network that could be used for arbitrary data too. Didn't Luke Dash Jr. embed a bible passage once? Luke would probably approve of that use case if the community shared their favorite bible verses through the blockchain.

- "That's not spam, saying it's spam is a Sin".

[NotATether]

These moves like datacarriers, OP_CAT and so on really only benefit Ordinals, Runes and similar.

How does the op_return stuff have anything to do with ordinals or benefit it in any way?  Why are you talking against OP_CAT in a thread promoting knots when luke has publicly committed to activating op_cat?

It was just an example, albeit a poor one at that, demonstrating the addition of non-monetary features into the protocol.

P.S. Why would I want to undermine Bitcoin? It is my largest position by a huge margin

OK, but you fail to understand the underlying, and what makes Bitcoin censorship-resistant. WHICH, if you do, it makes everything more complicated. It won't be merely about decentralized, censorship-resistant "money" anymore.

People may or may not agree in removing OP_RETURN limits, but Bitcoin is a network that could be used for arbitrary data too. Didn't Luke Dash Jr. embed a bible passage once? Luke would probably approve of that use case if the community shared their favorite bible verses through the blockchain.

- "That's not spam, saying it's spam is a Sin".

I don't think anyone here wants to prevent people from embedding data into the blockchain at all, they just don't want the chain to be overwhelmed with data transactions in a way that rises fee rates significantly.

Likewise I think the vast majority of people would not have a problem with someone trying to embed 128 bytes into a transaction, such as a bible verse. The problem, to which I think those who dissent to allowing large datacarriers can reach a consensus, is when chains are abused to store harmful data such as the malware example I gave earlier, which is happening on other coins BTW:

[1]: https://www.coindesk.com/markets/2025/09/04/crypto-hackers-are-now-using-ethereum-smart-contracts-to-mask-malware-payloads

Granted, these are using smart contracts in order to obfuscate the payload, something which is not directly possible when you only have a stack with no extra instructions. But it does highlight the ways which bad actors are using crypto - when they are not using it to scam people or steal funds, that is.

[gmaxwell]

demonstrating the addition of non-monetary features into the protocol.

It is NOT a non-monetary feature.  But see this is why you shouldn't go around concerning yourself with telling other people how they can and can't use their money, because you're just going to make mistakes in your determination. Anyone will.  The safe position is to be hands off as much as possible.  If you don't get this you've forgotten or never knew what bitcoin was about.

P.S. Why would I want to undermine Bitcoin? It is my largest position by a huge margin

People act against their own interests all the time, also a common theme for shitcoiners is essentially that while their bitcoin is currently worth more, they own a much larger percentage of the supply from some shitcoin, so fucking up bitcoin to pump their shitcoin is something they imagine will still be a net win.  But thanks for admitting that you have a conflict of interests, even if you personally think it isn't a big deal.

I don't think anyone here wants to prevent people from embedding data into the blockchain at all, they just don't want the chain to be overwhelmed with data transactions in a way that rises fee rates significantly.

That's nice but it's not really a logically consistent position.  If someone is willing to pay a lot of money in fees they can drive fees up-- end of story.  Nothing being discussed here has anything to do with their ability or willingness to do so.  I'm also not even sure if you use bitcoin at all, because there haven't been elevated feerates since last October, and not really much then.  The nice thing about activity that drive up fees is that they're self regulating-- they inherently burn up the actors funds.

This I think also explains the bizarre activity from Ocean Mining-- they were created at the height of one of those traffic booms and made anti-spam a central plank of their brand identity. The issue solved itself, as expected, and they lost relevance and inertia and appear to be failing.  Now they are unethically manufacturing a controversy in a desperate attempt to stay relevant.  It's an unsurprising move in the sense that their founder is a no-coiner and so he fails if ocean fails even if bitcoin flourishes.

is when chains are abused to store harmful data such as the malware example I gave earlier, which is happening on other coins BTW:

That isn't about "storing" harmful data, -- it's just that the entire ethereum ecosystem is incompetently and insecurely designed such that it's impossible to programmatically tell what anything is doing, and so attackers can snow users who are trying to figure things out.

[d5000]

Public key validation would work if those were being used to store the spam, but what happens if it's address hashes a la base58 or bech32? Verification becomes impossible as the key is not even known.

Yes, that's true. The main effect is that spam would become more expensive because the "grinding process" to figure out the addresses would not allow a similar efficiency to storage in the "public keys" (e.g. in P2MS like some of these protocols do).

I don't remember "how much" more expensive data storage would become due to such a measure (should be buried deep in the bitcoin-dev discussion about the OP_RETURN change). IMO it was significant but a malicious spammer would still be able to afford it. But in the bitcoin-dev discussion it was argued that also regular Bitcoin transactions would become more expensive as you would have to store more data in the script, like a signature. See also @gmaxwell's answer here:

There are several fairly straightforward ways to transform arbitrary data to and from an indistinguishable valid pubkey.  One is in the bitcoin codebase already for the P2P encryption.  So what, permanently increase the validation cost of every txn by 1/4 or something to make the opponent copy and paste a bit of existing code?

A slight doubt I had about your post, @gmaxwell:

So not only would that fail, it would also make things worse since at least now a node could expand its definition of unspendable outputs to include the ~half of these that aren't valid points and exclude them from their UTXO set. But if blocked and then they move to adjusting the encoding so they're always valid points (or just changes to make them 256 bit "script hashes") this option goes away.

I interpret that "currently" there would be some methods for nodes to exclude these "fake public keys" from their UTXO set already, but if the validation was changed, that would not longer be possible. So does this mean that there could be indeed some "spam-pruning" methods to be set up for the case the fake public key method become too widespread? I guess the primary question would be the cost of this method for nodes vs. the cost of storing the data.

Of course spammers, if they really want to be sure that their data remains on the blockchain, could already now develop a completely "safe" protocol, for example encoding the data directly into pubkey hashes or addresses. Not even a method based on UTXO expiration (with recovery option, see my thread here) would really help in this case, although it would increase the costs to store that content "forever" if the UTXO expiration also allows nodes to prune the UTXOs from blockchain data.

The other method we have is to enforce transaction (not block!) pruning as an optional command-line option, by using a bloom filter to completely ignore Bitcoin eater addresses, invalid keys, OP_RETURN.

I guess that is what @gmaxwell wrote above. As long as full nodes need to archive everything, however, that would indeed only be useful for "passive" nodes, i.e. not those actively distributing the blockchain.

[gmaxwell]

I interpret that "currently" there would be some methods for nodes to exclude these "fake public keys" from their UTXO set already, but if the validation was changed, that would not longer be possible.

Kind of-- half of fake pubkeys are indistinguishable from ordinary pubkeys to begin with.  But the other half aren't and so outputs that are actually unspendable due to a detectably fake pubkey could be excluded.  If there were some relay rule running this check then none would be detectable anymore.

When an output is unspendable no one can tell if you've pruned it or not, so you're free to use whatever complicated schemes you want to tidy your own utxo set so long as they have no false positives for unspendability.

Of course spammers, if they really want to be sure that their data remains on the blockchain,

Well that isn't what they actually want. They want to hype their worthless token over some other worthless token, once they've pocketed the victims money they sail off into the sunset and the long term is irrelevant.  So it's just a marketing point.

could already now develop a completely "safe" protocol,

Nah, because anyone paying attention would know that the existence of utxotree shows that no such safe method can exist, even using spendable outputs.  Bitcoin isn't a data storage system so surprise surprise you cannot use it to safely store data long term.

The other method we have is to enforce transaction (not block!) pruning as an optional command-line option, by using a bloom filter to completely ignore Bitcoin eater addresses, invalid keys, OP_RETURN.

Bloom filters have false positives, you can't do that because someone will come along and spend one of those false positives and then you reject the valid block and go off onto a fork.  (Also the victim of the false positive would be pretty cross their coins were destroyed if that fork were ultimately popular!).  OP_RETURNS are all safely excluded from the UTXO set today because they can never be spent.  There are other outputs that are undependable which could be detected but it hasn't historically been worth it.

[stwenhao]

So does this mean that there could be indeed some "spam-pruning" methods to be set up for the case the fake public key method become too widespread?

Yes. If people would start sending coins to 020000000000000000000000000000000000000000000000000000000000000000, then we could safely treat it in the same way as "OP_RETURN", because that kind of funds are provably unspendable. Because OP_RETURN is not the only unspendable Script, there are many others, for example "OP_FALSE".

could already now develop a completely "safe" protocol, for example encoding the data directly into pubkey hashes or addresses

Yes. The best method I know of, is "OP_CHECKSIG OP_NOT OP_VERIFY", where you waste resources on validating a signature, but you can put any data you want, and they have to be checked, because maybe, somewhere, someone, posted something valid, and it should be discarded then. Which means, that each signature checking can consume two stack elements, 520-byte each, and they have to be invalid.

Another way to waste resources, is to use "<data> OP_SWAP OP_CHECKSIGVERIFY <data2> OP_SWAP OP_CHECKSIGVERIFY ...". Then, contrary to the previous example, you save one byte, by replacing "OP_CHECKSIG OP_VERIFY" with a single "OP_CHECKSIGVERIFY", and nobody can replace your 64-byte data pushes, wrapped in DER signatures, with another data.

And there are many other ways. By just using "OP_2DROP OP_2DROP ... OP_2DROP", it is possible to quickly exhaust 10 kB Script size limit, and then, you can push similar amount of data through P2WSH, that you can in P2TR. It is a cat and a mouse game, and there are a lot of ways to push data to the chain. Of course, spammers can use the most demanding ones, and then, if next standardness limits will be lifted, we may see huge multisigs, accepted by miners in out-of-band ways. Then, it becomes dangerous, when the time to verify a block is counted in minutes, and especially, if it takes longer, than producing a new block.

Also, look at this list: https://en.bitcoin.it/wiki/Common_Vulnerabilities_and_Exposures

Many things were never fixed, because there was no hurry to do so. But some things can be exploited even today, and they were known for decades. Because it is all about Open Source, where people work on things they want, and as long, as they are not directly attacked, they can focus on what they like, instead of doing essential things.

And also, it has another side: making more sophisticated attacks require some skills. And many attackers are not smart enough, to use them, so we are safe, as long as they are focused on just pushing data in unexecuted branches, instead of doing way worse things.

Bitcoin isn't a data storage system so surprise surprise you cannot use it to safely store data long term.

As long as UTXO pruning is not implemented, every full node stores the whole UTXO set. And if you explore past URLs, then quite often, some block explorers, and websites are gone. But by knowing the block hash, or transaction hash, you can still retrieve it. Which means, that as long as network rules are "store every UTXO, even in pruned mode", then it is used as a cloud storage, and I guess it will remain that way, as long as there won't be "more pruned" versions.

[gmaxwell]

As long as UTXO pruning is not implemented, every full node stores the whole UTXO set.

uh the name of the patch that introduced the UTXO set was named ultraprune.  The utxo set has been pruned almost as long as the concept of the utxo set existed.  No bitcoin core nodes keep all unspent outputs.  Today op_returns and outputs over 10000 bytes are eliminated.  Anyone could eliminate any additional unspendable outputs without it even being detectable by third parties. Adding additional undependable types doesn't present any compatibility hurdles and more could be added at any time. Presumably you means something about "pruning" spendable outputs, but that's really confusing because you can't do that (in either the sense that the definition of pruning is removing info not needed for future spends or in the sense that removing anything spendable will break consensus and/or confiscate coins).

Already people running utxotree can run without any utxo set at all today though it's not a normal thing are doing in production yet, but this isn't pruning rather it's just not needing to keep a utxo set at all.

But by knowing the block hash, or transaction hash, you can still retrieve it.

Also confusing. Nodes provide no external (e.g. p2p) interface to fetch utxos in any form, quite intentionally.  The utxo set can't act as cloud storage in that sense-- the fact that something is in some other nodes utxo set doesn't provide you any way to access it.  Sure you can access your own copy if you have one, but if you're keeping your own copy you could also just as well keep pruned data, op returns, or whatever else, the utxo set isn't special.

You have to keep in mind that the people promoting NFT and ordinals and other related things are almost entirely fraudsters and they will tell essentially arbitrary lies about Bitcoin in order to promote their fraud and enrich themselves, so bending the truth is no barrier at all.  So just because they tell you that data they stuffed into the utxo set is immutable cloud storage doesn't make it true.  Many of these issues were considered and addressed long before most bitcoin users had ever used bitcoin.

Aside, it's also quite easy to encrypt your utxo set so even you can't access it... also without breaking compatibility just no one has thought it worth deploying yet.  Use txid:vout as a crypto key to encrypt the txout,  store the encrypted blob with H(per_node_salt||txid||vout) as the key in the database.  You could even make the utxo set a fair amount smaller this way by truncating the lookup key to 128 bits.  (and for a faster implementation, use the truncated second half as the crypto key).  If you don't reduce the sizes it's a few line patch to implement, I spent a couple minutes looking and can't find a copy now as I stopped using it after it got broken by some refactoring change.

[headingnorth]

First principle: It is not of you business how I use my money with other consenting parties.  You might not think it's useful. Good for you.   It's not your decision.

You can flood the internet with spam all you want I could care less, but when you attempt to pass such garbage
through my node hardware without my permission then that is my business. You don't have the right to tell me
what I can and cannot host on my own computer. It is amazing to me when spammers think they can flood the internet
with mountains of their garbage and expect no one to complain or do anything about it?

Do you enjoy receiving spam emails in your inbox every day? Do you have nothing better to do then look at
countless spam emails all day long? Or do you not take measures to block such spam from getting to your inbox in the first place?

Do you regard email spam filters as a form of censorship that should be removed from all email?

Spammers would no doubt remove all spam filters from every email software if they could. Which makes perfect sense
for someone to do when they have a financial interest in spamming and/or scamming people.

Maybe you enjoy looking at spam email all day long, as well as enjoy receiving physical junk mail delivered to your house
from the post office, but I would venture to say 99% of people do not like it and will do anything they can to avoid receiving it.
Hence, the massive negative reaction to Core 30's attempt to kill all spam filters.

Email spam filters do a pretty good job, but they can't block 100% of spam, but they do get pretty close.
But it is utterly stupid to say because spam filters can "only" block 95 to 99% of spam then they have failed,
therefore we should NOT have any spam filters at all. That is essentially what the Core idiot devs are doing.

OK, but you fail to understand the underlying, and what makes Bitcoin censorship-resistant. WHICH, if you do, it makes everything more complicated. It won't be merely about decentralized, censorship-resistant "money" anymore.

People may or may not agree in removing OP_RETURN limits, but Bitcoin is a network that could be used for arbitrary data too. Didn't Luke Dash Jr. embed a bible passage once? Luke would probably approve of that use case if the community shared their favorite bible verses through the blockchain.

- "That's not spam, saying it's spam is a Sin".

Do you understand there is massive difference between a bible verse that consists of a short line of text, and an entire photo image or a video?

[stwenhao]

You don't have the right to tell me what I can and cannot host on my own computer.

Of course. You don't have to store the whole blockchain, if you don't want to. And you don't have to use Bitcoin Core in its default configuration. If you want to remove a particular data from your node, then you are free to do so. You can always say to another node, that "I don't have this block" or "I don't have this transaction". You always could, it is your choice.

But then, it is a question about supporting the network. As long as other nodes need everything, to synchronize the chain, then if you remove anything, you won't support them in being fully synced. And then, they will have to download the data you removed from elsewhere. And as long as Initial Blockchain Download requires explicitly downloading all transactions and blocks in plaintext, then it would be the case.

when spammers think they can flood the internet with mountains of their garbage and expect no one to complain or do anything about it?

Spammers always wanted to flood the network. And it became easier, when people started to lift standardness rules. And lifting the rules came from a simple fact, that making yet another soft-fork is difficult, so developers wanted to deploy new things, without having to pass through that painful process. And since spammers started using standard transactions to spam, then it became harder and harder to stop.

I expect in the future, the chain will be endlessly spammed, because all standardness limits will be lifted, and the mainchain will contain everything, so that blocks will never be empty again. Then, developers will be responsible for nothing, because every consensus-valid transaction will be also standard, and then, in this chaos, new things will be built on top of that, forming subnetworks, which would have stricter rules, and only handle a subset of the mainnet traffic (because handling all of that will be too expensive).

Do you enjoy receiving spam emails in your inbox every day?

No. But in P2P networks, it is inevitable to process transactions, done by other people. You need some of them, to not be fully exposed. Running a mail server does not require processing all e-mails in the world. But in case of blockchains, it is exactly like that.

Do you have nothing better to do then look at countless spam emails all day long?

You don't have to "look at" other people's transactions. The only case where you have to, is if they consume too much resources, and it is visible on your charts. Then, you can strip them, but then, other nodes will have to connect with someone else, to still remain in the same network. And as long as you have to download that data, no matter how complex they are, then you have to trust other nodes, if you don't want to process them (as long as ZK-proofs are not implemented).

Or do you not take measures to block such spam from getting to your inbox in the first place?

You can do so, but if you will be alone, then the act of doing so, will expose your node. Which means, that currenty, if you want to remain hidden in the crowd of other nodes, all you can do is pruning. And if you want to prune more things, then they should be standardized first, because if you manually prune for example the UTXO set, then it will expose your node, if no other nodes will have similar settings.

Do you regard email spam filters as a form of censorship that should be removed from all email?

No. But I guess all limits will be lifted in the future, to free developers of all kinds of accusations. If every consensus-valid transaction will become standard, then no developer will be accused of any kind of censorship anymore. And then, some people will beg them, to introduce any filters, or will join developers, who will provide tools to filter any spam, and consume less resources.

Do you understand there is massive difference between a bible verse that consists of a short line of text, and an entire photo image or a video?

As long as we don't have commitments, putting any message anywhere, requires consuming more on-chain bytes. It would be great, if people could commit to messages, without putting the data on-chain, but only tweaking public keys, but we are not yet there. And as long, as commitments are not standardized, then putting data in plaintext is the only way to share it in easy-to-understand way.

So, it can be done better, but people don't have tools for that yet.

[uint512_t]

"Idiots are free to run censorware"

also

"These knobs are useless"

Boomer is demented.

[NotATether]

So does this mean that there could be indeed some "spam-pruning" methods to be set up for the case the fake public key method become too widespread?

Yes. If people would start sending coins to 020000000000000000000000000000000000000000000000000000000000000000, then we could safely treat it in the same way as "OP_RETURN", because that kind of funds are provably unspendable. Because OP_RETURN is not the only unspendable Script, there are many others, for example "OP_FALSE".

Key validity conditions should not be checked within the script interpreter but by the transaction verifying process itself.

If I have an uncompressed public key and the calculation of the Y point from the X leads to a different value of Y written, then its associated UTXO should be pruned just like OP_RETURN.

It works even for addresses hashes that are spent from  - but then that gives us an oxymoron, as all addresses with sending transactions have valid points. So it's not very useful.

As @gmaxwell wrote, probabilistic pruning based on alphanumerical patterns in the pubkey or address could lead to a frozen funds situation for coincidental legit addresses. However, an even lighter version of the Bitcoin software can cache all UTXOs, exclude such addresses from the cache, and then query a full node when a cache-miss occurs.

Because it is backed by full nodes, a fork will never occur.

[stwenhao]

probabilistic pruning based on alphanumerical patterns in the pubkey or address could lead to a frozen funds situation for coincidental legit addresses

For that reason, only strictly invalid public keys should be discarded. Which means:

Code:

000000000000000000000000000000000000000000000000000000000000000000 - discarded
...
01ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff - discarded
020000000000000000000000000000000000000000000000000000000000000000 - discarded
020000000000000000000000000000000000000000000000000000000000000001 - saved
020000000000000000000000000000000000000000000000000000000000000002 - saved
020000000000000000000000000000000000000000000000000000000000000003 - saved
020000000000000000000000000000000000000000000000000000000000000004 - saved
020000000000000000000000000000000000000000000000000000000000000005 - discarded
020000000000000000000000000000000000000000000000000000000000000006 - saved
...
03fffffffffffffffffffffffffffffffffffffffffffffffffffffffefffffc25 - saved
03fffffffffffffffffffffffffffffffffffffffffffffffffffffffefffffc26 - discarded
03fffffffffffffffffffffffffffffffffffffffffffffffffffffffefffffc27 - discarded
03fffffffffffffffffffffffffffffffffffffffffffffffffffffffefffffc28 - discarded
03fffffffffffffffffffffffffffffffffffffffffffffffffffffffefffffc29 - discarded
03fffffffffffffffffffffffffffffffffffffffffffffffffffffffefffffc2a - discarded
03fffffffffffffffffffffffffffffffffffffffffffffffffffffffefffffc2b - saved
03fffffffffffffffffffffffffffffffffffffffffffffffffffffffefffffc2c - saved
03fffffffffffffffffffffffffffffffffffffffffffffffffffffffefffffc2d - discarded
03fffffffffffffffffffffffffffffffffffffffffffffffffffffffefffffc2e - discarded
03fffffffffffffffffffffffffffffffffffffffffffffffffffffffefffffc2f - discarded
03fffffffffffffffffffffffffffffffffffffffffffffffffffffffefffffc30 - discarded
...
ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff - discarded

For each exposed public key, it is possible to check, if that key is valid or not. All standard address types require valid keys. The only way, how it could become a problem, is if you have a raw Script with things like "OP_CHECKSIG OP_NOT". But if you strip only UTXOs, where you are 100% sure, that they are provably unspendable, then it should be safe.