What's Your Take on Bitcoin Core Update V30, Knots and OP_RETURN

[DYING_S0UL]

First of all, the title says it all, this post is purely for educational purposes and nothing more.

I wanna know you guy's honest opinion on things like Core V30, Knots & OP_RETURN. Obviously I'm not a tech-savvy/tech-nerd/tech-genius/OG like you guys. So there are many technical things or even non technical things, I don't know or not aware of or might misunderstand.

I have been watching many videos regarding this matter, and many of them are heavily criticising this new update. According to many, increasing the OP_RETURN limit from 80 to 100,000 would make things worse. Some are saying, it would make the blockchain a big trashbin for internet's worst data! Imagine someone decided to throw in video, audio, meme or what not. Well what do you all think? And will Knots be able to solve it, or is it even worse than that?

Btw, I'm using Bitcoin Core V29 still.

Correct me, if I'm wrong anywhere, I am only human. Move to appropriate board if needed. 

[stwenhao]

What's Your Take on Bitcoin Core Update V30, Knots and OP_RETURN

1. Update v30 is just a normal update, like many others. Nothing new, nothing special.
2. Knots is just an alternative client. You can use it or not, the choice is yours. Personally, I don't use it for anything serious, but I have some version of it, because sometimes people ask questions about it, so I can run Core and Knots in regtest, and compare them. Also, I have both source codes, to grep them, and compare some differences, when needed.
3. OP_RETURN limit was lifted by miners, and then, Core just acknowledged that fact. Without that change, old clients like v29 would process things a little bit slower, but they wouldn't stop any spam effectively. If miners will lift some next standardness limits, then Core will also follow, because standardness limits are temporary. Only consensus rules are hard-enforced, everything else is just a weak barrier, which may work today, and be lifted tomorrow.

I have been watching many videos regarding this matter, and many of them are heavily criticising this new update.

Because they don't understand the difference between "non-standard" and "invalid". In the very old times, every single transaction was standard, if it was consensus-valid. Then, standardness rules were introduced, to protect users from basic mistakes, and to allow upgrading the network, without confiscating user's coins. Through the history, next limits were lifted, one-by-one, and in the future, all standardness limits will probably be lifted, if hashrate majority will decide to do so.

Of course, making all transactions "standard" may block future soft-forks. But it is not a big deal today, because soft-forks take years, and because a lot of people think, that Bitcoin should no longer be changed. Also, there are other ways than Segwit, to add new rules in a non-confiscatory way, so they can be used instead of future Segwit versions. And also, things like quantum protections, may lead to invalidating every place, where OP_CHECKSIG is used, so it doesn't matter, what spammers use today, if all or most of that will be invalidated in the future.

According to many, increasing the OP_RETURN limit from 80 to 100,000 would make things worse.

1. It would shrink the maximum size of the block from 4 MB to 1 MB. Which is good, because smaller blocks means faster IBD. Also, Luke wanted 300 kB blocks, so a lot of OP_RETURNs will give us an example, what could happen, if the block size would be a bit smaller than today. Maybe Knots should apply witness limit of 1 MB, as it is in Signet, to limit legacy data to 250 kB?
2. It could push us faster to some features like ZK-proofs, if people would want to do IBD, without knowing all transactions in plaintext.
3. Even Knots would accept blocks with non-standard transactions. As long as it is the case, it doesn't matter that much, what you use. Your computer, your choice. If you shoot yourself in your foot in the process, there is nobody to blame, no matter if you use Core or Knots.

Some are saying, it would make the blockchain a big trashbin for internet's worst data! Imagine someone decided to throw in video, audio, meme or what not.

It is going to happen anyway. And future Segwit addresses like bc1sw50qgdz25j can be used to do that anyway, by making continuous, 4 MB witness data pushes.

But it is nothing, compared to quantum signatures and public keys, where some people would want to increase the maximum block size from 4 MB to something bigger, and really turn Bitcoin into a cloud storage.

Well what do you all think?

I think there is a lot of drama, for a simple change like that. But because bitcointalk is all about entertainment, topics like that are endlessly discussed, and will be, even if they are not so important. For many people, talking about this topic is like going into playground, because there are many more interesting things going on, but well, if people want to talk about cloud storage, then we can do so, and talk about other things in different places.

And will Knots be able to solve it, or is it even worse than that?

Only if they will handle IBD without processing all spammy transactions. Otherwise, all of their filters will only make the situation worse.

Btw, I'm using Bitcoin Core V29 still.

Your computer, your choice. You can use even 0.1.0 version from Satoshi with patches. It doesn't matter, because anyone can even use v30, and declare to accept and process all transactions, but reject them on block template level. It is usually unknown, what is the exact code, that is running on other computers. And it is trivial to run Core, and pretend to run Knots, or vice-versa. Or even to run your own version, and pretend it to be Core, Knots, or anything else.

[ABCbits]

I have been watching many videos regarding this matter, and many of them are heavily criticising this new update. According to many, increasing the OP_RETURN limit from 80 to 100,000 would make things worse. Some are saying, it would make the blockchain a big trashbin for internet's worst data! Imagine someone decided to throw in video, audio, meme or what not. Well what do you all think?

When people say worse, it's true in sense there are more ways to add arbitrary data to Bitcoin blockchain. But determined spammer isn't affected by new OP_RETURN size limit.

And will Knots be able to solve it, or is it even worse than that?

Not really, since those spammer could use crude approach (such as creating fake pubkey) that is much harder to filter without also exclude some monetary/financial TX.

[headingnorth]

I have been watching many videos regarding this matter, and many of them are heavily criticising this new update. According to many, increasing the OP_RETURN limit from 80 to 100,000 would make things worse. Some are saying, it would make the blockchain a big trashbin for internet's worst data! Imagine someone decided to throw in video, audio, meme or what not. Well what do you all think?

When people say worse, it's true in sense there are more ways to add arbitrary data to Bitcoin blockchain. But determined spammer isn't affected by new OP_RETURN size limit.

That would be largely corrected if everyone ran Knots, which closes all the loopholes that Core has created and left
wide-opened to spammers. Watching every shitcoiner and spammer in the world rejoicing over the release of Core 30
should probably tell us something. When even Craig Wright is celebrating, you know something is not right.

Btw, I'm using Bitcoin Core V29 still.

Knots not only leaves the op_return filter intact, but also rejects inscription and ordinal transactions.
So I highly recommend switching to Knots, which is far better than any version of Core which I consider to be malware.

The Core devs have openly stated that sound money is no longer their primary mission for Bitcoin. Every release of Core
has become worse and worse. If you believe in Bitcoin's mission as sound money and don't wish to store great amounts
of arbitrary garbage on your node, then there is no point of running any version of Core because there is no good version of it,
only ones that are slightly less bad.

[Quickseller]

From what I understand, nothing really changed with the update to v30 -- at least in regard to the core/knots debate. The debate caught the attention of some when v30 of bitcoin core and knots were released because someone associated with knots complained.

To my knowledge, knots will only reject transactions from its mempool, but will accept blocks that have these transactions. So knots is not really solving any problem, it is just not relaying some transactions that its dev doesn't like. In practice, this means you will have to valiadate more transactions when validating a block if you are running knots.

Anyone who wants their transaction confirmed will need to pay for block space. So the fee market will handle transactions with op return outputs. However, if the community were to decide that transactions with op return should be banned, the proper way to do this is via a soft fork, not by declining to relay these transactions.

[Cookdata]

Knots not only leaves the op_return filter intact, but also rejects inscription and ordinal transactions.
So I recommend switching to Knots. Knots is much better than any version of Core which I consider to be malware.

The Core devs have openly stated that sound money is no longer their primary mission for Bitcoin. Every release of Core
has become worse and worse. If you believe in Bitcoin's mission as sound money then there is no point of running any
version of Core because there is no good version of it, only ones that are slightly less bad.

If by chance knot flip core by numbers, it will not change much, maybe will reduced how often we are going to have OP_RETURN, the inscriptions and ordinal transactions because knot is a policy rule and not a consensus enforcement. We still have numbers of node that are running old version nodes, there will be more nodes running this same version 30 you guys don't like and as long as there are mining nodes that accepts OP_RETURN, you will get this OP_RETURN included in the block once a in a while when they found a block. Knot policy implementation is not going to solve the agitation.

Sometimes I think we forgot what node is about, I mean what happen to my node is my rule? You set up your rule and decided to filter things you don't like but then you want others to follow your rule and do the same? Na! You keep your rule. I don't have version 30 but I'm not running knot, there are many ways one can contribute to the network and not get involved with this knot core shenanigans just to prove points.

[headingnorth]

Knots not only leaves the op_return filter intact, but also rejects inscription and ordinal transactions.
So I recommend switching to Knots. Knots is much better than any version of Core which I consider to be malware.

The Core devs have openly stated that sound money is no longer their primary mission for Bitcoin. Every release of Core
has become worse and worse. If you believe in Bitcoin's mission as sound money then there is no point of running any
version of Core because there is no good version of it, only ones that are slightly less bad.

If by chance knot flip core by numbers, it will not change much, maybe will reduced how often we are going to have OP_RETURN, the inscriptions and ordinal transactions because knot is a policy rule and not a consensus enforcement. We still have numbers of node that are running old version nodes, there will be more nodes running this same version 30 you guys don't like and as long as there are mining nodes that accepts OP_RETURN, you will get this OP_RETURN included in the block once a in a while when they found a block. Knot policy implementation is not going to solve the agitation.

Sure the Knots nodes will have to store the garbage data if it gets mined, but it won't have to relay it to other nodes.
That is the point. The more Knots nodes running on the network makes it harder for spam to go through.

Giving up without a fight or doing nothing is not the solution.

[stwenhao]

However, if the community were to decide that transactions with op return should be banned, the proper way to do this is via a soft fork, not by declining to relay these transactions.

Why use a soft-fork for something, that can be solved without any forks? Knots could simply reject all spammy transactions, and perform IBD in other ways, without downloading them. There is no need to fork the chain, but if they want to go for a soft-fork or a hard-fork, then it is their problem, if they will get a new altcoin out of it.

Sure the Knots nodes will have to store the garbage data if it gets mined

They don't have to. Pruned nodes don't do that, and they are not constantly forking the network, by having less transactions, than everyone else. And when it comes to IBD, it can be done in a different way than today, it is only a matter of implementing it.

Giving up without a fight or doing nothing is not the solution.

Which is why I still wonder, why people talk about filters, instead of talking about things like ZK-proofs, or other improvements to IBD.

[Satofan44]

Sure the Knots nodes will have to store the garbage data if it gets mined, but it won't have to relay it to other nodes.
That is the point. The more Knots nodes running on the network makes it harder for spam to go through.

Sounds good. Attacker response: Now you have forced my hand and I will store CSAM and state secrets in unprunable UTXOs.

Congratulations, you have achieved absolutely nothing and you are now the proud owner of several types of illegal data that are stored permanently on your system. How does that make you feel? Very accomplished?
OP, this is the correct answer. Ignore the naysayers. Running Knots does not do anything other than show that the person is stupid and ungrateful. Without Core we would not even be here. Further, that someone would change from a battle tested client with peer review to one run by a religious nut job over some magic developer numbers says everything you need to know about their knowledge or intellect.

Everything that is aligned with consensus rules is valid. If some filterboy does not want it, they can propose changes to the consensus rules. Otherwise they need to shut up with their censoring bullshit.

[Quickseller]

However, if the community were to decide that transactions with op return should be banned, the proper way to do this is via a soft fork, not by declining to relay these transactions.

Why use a soft-fork for something, that can be solved without any forks? Knots could simply reject all spammy transactions, and perform IBD in other ways, without downloading them. There is no need to fork the chain, but if they want to go for a soft-fork or a hard-fork, then it is their problem, if they will get a new altcoin out of it.

I am not sure what 'IBD' means in your post, but I will respond to what I understand about your response.

Anyone running knots will need to download all transactions that are valid and are included in a block. So if a transaction that knots thinks are spam gets in a block, it will be downloaded once its confirmed instead of when the transaction is transmitted as a 0/unconfimred tx.

[headingnorth]

Sure the Knots nodes will have to store the garbage data if it gets mined, but it won't have to relay it to other nodes.
That is the point. The more Knots nodes running on the network makes it harder for spam to go through.

Sounds good. Attacker response: Now you have forced my hand and I will store CSAM and state secrets in unprunable UTXOs.

Congratulations, you have achieved absolutely nothing and you are now the proud owner of several types of illegal data that are stored permanently on your system. How does that make you feel? Very accomplished?
OP, this is the correct answer. Ignore the naysayers. Running Knots does not do anything other than show that the person is stupid and ungrateful. Without Core we would not even be here. Further, that someone would change from a battle tested client with peer review to one run by a religious nut job over some magic developer numbers says everything you need to know about their knowledge or intellect.

Everything that is aligned with consensus rules is valid. If some filterboy does not want it, they can propose changes to the consensus rules. Otherwise they need to shut up with their censoring bullshit.

Everything you said is 100% BS that you just pulled out of your ass.

There is no point in proposing anything to Core-tards like you who think spam filters are somehow a form of censorship.
There is no point in proposing changes to consensus rules to those who will not listen to reason. It has been done more than once to no avail.

Are email spam filters a form of censorship as well? On what planet are you fucktards living on? Jesus Christ.

[stwenhao]

I am not sure what 'IBD' means in your post

Initial Blockchain Download.

Anyone running knots will need to download all transactions that are valid and are included in a block.

In the current version yes, it is true for Core and Knots. But it can be done differently. And I wonder, why people, that want to filter transactions, don't think about that kind of implementations at all, but focus on filtering instead.

For example: when you have Monero, then transactions are processed, and validated, without knowing, who is the recipient, who is the sender, and which amounts are used. But still, all miners can check, if the transaction is valid, and build new blocks on top of that.

Which means, that technically, it is possible to validate a transaction, without knowing its content. Which also means, that it is possible to change the algorithm used during Initial Blockchain Download, to not process spammy transactions in plaintext, but to process only some kind of proof, that it is valid. And then, if it can be done for spammy transactions, it can be expanded to all historical transactions as well, because if it could work for transaction A, then why it shouldn't work for transaction B? And then, only users, who have their inputs or outputs involved, could store these transactions, and everyone else could only focus on processing some proofs, that the transaction is valid, and that new blocks can be safely built on top of it.

But no, instead of simplifying Initial Blockchain Download, people want to talk about filters instead. Why? I don't know.

[She shining]

Core 30 didn't change much datacarriersize can still be placed at previous update limit I.e 83 bytes. I see no reason not to update it.

Some are saying, it would make the blockchain a big trashbin for internet's worst data! Imagine someone decided to throw in video, audio, meme or what not

OP_RETURN isnt the only way to placed such on the blockchain and what can be placed into a transaction is still limited to 100kb.

[Mia Chloe]

~snip

This particular debate on multiple discussions about Bitcoin core and knots has been raised multiple times and the truth is it'sore like a thing of preference because there are actually two sides to this debate like I've always said. Knots is kinda giving you so privileges that some people view as Extra freedom but in detail is not really significant and could be partially used as flaw against the network.

This forum will always support bitcoin core over Knots  and part of the reasons is because Satoshi's initially software and work was bitcoin core not knots. Theymos openly said this recently.

[ABCbits]

I have been watching many videos regarding this matter, and many of them are heavily criticising this new update. According to many, increasing the OP_RETURN limit from 80 to 100,000 would make things worse. Some are saying, it would make the blockchain a big trashbin for internet's worst data! Imagine someone decided to throw in video, audio, meme or what not. Well what do you all think?

When people say worse, it's true in sense there are more ways to add arbitrary data to Bitcoin blockchain. But determined spammer isn't affected by new OP_RETURN size limit.

That would be largely corrected if everyone ran Knots, which closes all the loopholes that Core has created and left
wide-opened to spammers. Watching every shitcoiner and spammer in the world rejoicing over the release of Core 30
should probably tell us something. When even Craig Wright is celebrating, you know something is not right.

We better hope those spammer won't resort to use service offered by miner/mining pool that include non-standard TX or create spam that not filtered by Knots (such as fake pubkey).

Anyone running knots will need to download all transactions that are valid and are included in a block.

In the current version yes, it is true for Core and Knots. But it can be done differently. And I wonder, why people, that want to filter transactions, don't think about that kind of implementations at all, but focus on filtering instead.

For example: when you have Monero, then transactions are processed, and validated, without knowing, who is the recipient, who is the sender, and which amounts are used. But still, all miners can check, if the transaction is valid, and build new blocks on top of that.

Which means, that technically, it is possible to validate a transaction, without knowing its content. Which also means, that it is possible to change the algorithm used during Initial Blockchain Download, to not process spammy transactions in plaintext, but to process only some kind of proof, that it is valid. And then, if it can be done for spammy transactions, it can be expanded to all historical transactions as well, because if it could work for transaction A, then why it shouldn't work for transaction B? And then, only users, who have their inputs or outputs involved, could store these transactions, and everyone else could only focus on processing some proofs, that the transaction is valid, and that new blocks can be safely built on top of it.

But no, instead of simplifying Initial Blockchain Download, people want to talk about filters instead. Why? I don't know.

While i understand the idea, i don't how it simplify the IBD. From what i can understand, it require additional programming about managing the proof. For those who perform IBD, more computational resource needed to verify the proof itself. CMIIW.

[stwenhao]

While i understand the idea, i don't how it simplify the IBD.

It allows users to synchronize the chain from a pruned node, by just validating a proof. Which means, that only archival nodes have to store old transaction data in plaintext. And also, they don't need it anymore for consensus reasons: if some user does not care about storing past transactions, then it is the same situation, as if the same user does not care about making a backup of a private key.

Of course, existing nodes can still do things in the old way, but as there will be less and less full, archival nodes, then they will just end up waiting more time, to get past transactions. And if getting data from old transactions will no longer be reliable (which is inevitable, because of the always-growing, and never-shrinking chain), then users will lose any incentive to use Bitcoin to push data in any form. Also, if some UTXO will be trapped on random 160-bit hash, then it will be up to the coin sender and receiver, to keep that data. Other nodes can simply validate the proof, include the transaction, and build next blocks on top of the chain, without worrying about storing exact data behind it. Because during spending, it will be required to provide it by the coin spender. Which could never happen, if that data is a random hash, that is unreachable, or harder to reach, than re-mining the whole chain.

From what i can understand, it require additional programming about managing the proof.

Of course. But if nodes don't want to process transactions in plaintext, then they would have an option, to use such proofs instead, and don't worry about being sued.

For those who perform IBD, more computational resource needed to verify the proof itself.

It depends. If there are non-consensus data pushes, and something is wrapped in "OP_FALSE OP_IF ... OP_ENDIF" envelope, then the only thing you need, is to store some hash of that data, without storing them in plaintext. And for every OP_CHECKSIG call, you only need a proof, that the signature is valid, and that it signed a given transaction. You don't need all in-between data, because they don't affect the signature checking algorithm at all, you just have one 256-bit number instead of another one, and that's it. You have just a hashed message to be signed, and the only proof you need, is that between OP_IF and OP_ENDIF, there are only stack pushes, and nothing more.

Also, proofs are reusable: as long as verifying a proof is fast, generating it can be slower, because it can be done once, and then, all verifiers will accept it, and can store it, without bothering to store the data in plaintext, which were used to generate it.

I expect generating proofs for most data-related use-cases will be quite fast. Because OP_RETURNs or Ordinals envelope can be verified faster, than a bunch of regular signatures, when things are stored inside private keys, or fake public keys or hashes inside multisigs. But even if it would take a while, then generating a proof can be slower, if it will speed up the verification time of that proof.

However, even if we assume, that making these proofs properly is hard, then still: pushing the discussion in that direction would be better, than talking about filters. Because then, all transactions can be simplified. And I think it is better, if more users will run "pruned nodes with ZK-proofs" than "SPV nodes". Maybe it would be still far from ideal, but it would be a step in the right direction.

Edit: Also, proofs can be chained. Which means, that instead of checking, if a single transaction is correct, you can verify, if a given set of proofs is valid. Which means, that if you have a proof, that Alice -> Bob transaction is valid, and you also have a proof, that Bob -> Charlie transaction is valid, then you can replace it with a proof, that Alice -> Charlie coin transfer is valid, no matter how many middle-points are in-between, as long as things like ECDSA or SHA-256 are secure.

Of course, faking a proof is possible in theory. As well as making 1,000,000 block reorg is mathematically possible. But it is quite unlikely, so if faking a proof will be harder, than overwriting the whole chain, then it should be sufficient to be used in practice.

[d5000]

My take is that the Core 30 change is reasonable. It doesn't really open a new door for spam, because spamming data will not become cheaper nor really more convenient. @stwenhao's excellent post has already explained almost everything I would say about the topic.

Knots, which closes all the loopholes that Core has created

No, they can't block formats which use fake public keys. And there is even a more "unstoppable" way: using weak cryptography and storing data in private keys which then can be easily calculated by everybody wanting to see the image, video or whatever.

This is the essence of the problem. If the spammer wants to spam and knows the option he has on the table, he can't be stopped. He could spam as many data as he wanted since 2009. Core 30 only adds a slightly more expensive spam option which is more convenient for node runners, but protocol devs who care about Bitcoin could use them instead of the fake public keys or the Ordinals method which are more expensive for node operators.

Only for those who don't know still how many fake public key NFTs are on the Bitcoin blockchain: at least 1,2 million in one single protocol and there may be more.

Of course, making all transactions "standard" may block future soft-forks.

Just asking: What do you mean with that? IMO soft forks tighten protocol rules, so if a particular type of transaction was made "standard" (like one with 100,000 OP_RETURN bytes) and later a soft-fork (a la BIP 444) restricts it to 83 again, then the "standardness" would be "overruled" by the protocol. Or am I getting something wrong?

[stwenhao]

What do you mean with that?

I mean, that today, if you try to spend coins from addresses like bc1sw50qgdz25j, then it can be done in the same way, as spending from bc1pfeessrawgf. And if you try to prepare a new soft-fork now, which would use "bc1s" addresses, then it can be safely deployed, without wondering, if anyone uses it now (it is non-standard, so it should be unused).

However, if every single transaction, which is consensus-valid, will be suddenly accepted as "standard", then making a new soft-fork will have a higher confiscation surface, than today. Each and every soft-fork can potentially confiscate your funds, because you can use a feature, that a given soft-fork explicitly blocks as "invalid". As long as new soft-forks use "non-standard" things, they are safer, because there is a lower risk, that some user, somewhere, used it for something else, and have presigned, timelocked transactions (which would be invalid, if some soft-fork would activate).

More about it: https://b10c.me/blog/007-spending-p2tr-pre-activation/

IMO soft forks tighten protocol rules, so if a particular type of transaction was made "standard" (like one with 100,000 OP_RETURN bytes) and later a soft-fork (a la BIP 444) restricts it to 83 again, then the "standardness" would be "overruled" by the protocol.

Exactly. And then, imagine that you signed a transaction, which uses 100 bytes in OP_RETURN. What then? Your signature and your transaction is valid now, but can be invalidated in the future. And then, if there is another transaction, which can be used after some timelock, then it can expire. Which means, that some people can lose funds, because of such change.

Because currently, you can have 2-of-2 multisig, that is spent in this way:

Code:

+----------------------------------------------------------+
| Alice and Bob 1.00 BTC -> Alice                 0.99 BTC |
|                           OP_RETURN <100 bytes> 0.00 BTC |
+----------------------------------------------------------+
| locktime: 2026-07-08                                     |
+----------------------------------------------------------+

And you can have another transaction:

Code:

+----------------------------------------------------------+
| Alice and Bob 1.00 BTC -> Bob                   0.99 BTC |
+----------------------------------------------------------+
| locktime: 2026-09-10                                     |
+----------------------------------------------------------+

And then, this BIP is activated on 2026-02-01, and deactivated on 2027-02-01. Then, suddenly, instead of confirming transaction, which transfers coins from multisig to Alice, only Bob can get funds out of the channel, just because of this OP_RETURN in Alice's transaction.

Which means, that in this case, Alice have a reason, to oppose the soft-fork, because it is confiscatory from her perspective. And each and every soft-fork has some confiscatory surface. However, when standard things are invalidated, then it is a bigger deal, than if only some non-standard ones are, which almost nobody uses (if something is non-standard, then it is a soft-warning: "be careful, you may lose your funds"; standard transactions don't have such warnings, because they are valid, and can be easily created by a lot of widely available tools).

[Quickseller]

I am not sure what 'IBD' means in your post

Initial Blockchain Download.

Ahh gotcha.

Anyone running knots will need to download all transactions that are valid and are included in a block.

In the current version yes, it is true for Core and Knots. But it can be done differently. And I wonder, why people, that want to filter transactions, don't think about that kind of implementations at all, but focus on filtering instead.

For example: when you have Monero, then transactions are processed, and validated, without knowing, who is the recipient, who is the sender, and which amounts are used. But still, all miners can check, if the transaction is valid, and build new blocks on top of that.

This is not how Bitcoin works. The Bitcoin protocol requires that for a transaction to be confirmed, it must be included in a block. I am unable to think of a scenario in which what you describe could be implemented into Bitcoin without a hard fork.

So, going back to your point about "IBD" -- regardless of if you are using Bitcoin Core or Knots, you are going to eventually download all transactions confirmed in blocks. Once your node is synced, you will download the transactions you describe as "spam" shortly after they are broadcast if you are running Core, and you will download these transactions once they're confirmed if you're running knots. The transactions that knots will not relay are valid, and are likely to be confirmed fairly quickly. TBH, it is really just silly not to relay these transactions.

[stwenhao]

regardless of if you are using Bitcoin Core or Knots, you are going to eventually download all transactions confirmed in blocks

Bitcoin nodes don't need to store or provide access to historical blocks to operate.  They only do today (to the extent they do, many don't) to aid new nodes coming up securely, but in the future that will be accomplished via other means because transferring terabytes of blockchain to process and throw away whenever someone starts a new node won't be sufficiently viable.

See? I am not the only one, thinking in that way. And it should be quite obvious, if you note, that the chain is constantly growing, never shrinking, and it takes longer and longer, to verify it, so in the future, people will give up, and stop running full nodes at all, or start making more optimizations.

TBH, it is really just silly not to relay these transactions.

Then, why Satoshi tested the system with settings, where for example once per four messages, things were randomly dropped?

Before the original release I did a test dropping 1 out of 4 random messages under heavy load until I could run it overnight without any nodes getting stuck.

Also note, that sending unconfirmed transactions, or some recent transactions, is crucial, because it is needed to form next blocks. But when it comes to the historical transactions and blocks, then it is not that important. Otherwise, pruning wouldn't be possible at all.

And it would nicely complete the step 7 from the whitepaper: "Reclaiming Disk Space".

Once the latest transaction in a coin is buried under enough blocks, the spent transactions before it can be discarded to save disk space.

And also:

A block header with no transactions would be about 80 bytes. If we suppose blocks are generated every 10 minutes, 80 bytes * 6 * 24 * 365 = 4.2MB per year. With computer systems typically selling with 2GB of RAM as of 2008, and Moore's Law predicting current growth of 1.2GB per year, storage should not be a problem even if the block headers must be kept in memory.

Why the size of the block headers is counted, and nothing else? Isn't there an assumption, that only block headers will be kept for historical data? Also, things could be then more private, because the community only needs a proof, that all transactions and blocks are correct. However, if getting historical data would be slower, or more difficult than today, then it would protect the privacy of old users, at least to some extent.