Bots that trash Bitcoin blockchain?

[PremiumCodeX]

What is the solution against the bots that automatically and frequently upload unnecessary data into the Bitcoin blockchain?

With pruning enabled, nodes could save space on their HDD.
If allot of nodes enable pruning, will not the blockchain become less secure (because there are less nodes to download historical data from)?

[1714157671]

1714157671

[1714157671]

1714157671

[1714157671]

1714157671

[1714157671]

1714157671

[bob123]

What is the solution against the bots that automatically and frequently upload unnecessary data into the Bitcoin blockchain?

Currently there is no real 'solution' to 'prohibit' such a behaviour.
But pushing data into the blockchain is a very costly undertaking. You can't simply upload pictures or movies for a few bucks..

If allot of nodes enable pruning, will not the blockchain become less secure (because there are less nodes to download historical data from)?

It doesn't make the network less secure. The availability (of the blocks) for others to download from sinks.
The 'security' is more dependent from the total hash rate.

[aleksej996]

Formally this is why there are mining fees and block size limits in the first place.
So those are the only official solutions for it right now.

Of course miners can always agree not to accept certain junk transactions if they wish to do so.

[mattcode]

Formally this is why there are mining fees and block size limits in the first place.
So those are the only official solutions for it right now.

Of course miners can always agree not to accept certain junk transactions if they wish to do so.

How do you define a junk transaction though? Surely if somebody pays the proper fee, their transaction should be as valid as any other.

[just_Alice]

What is the solution against the bots that automatically and frequently upload unnecessary data into the Bitcoin blockchain?

With pruning enabled, nodes could save space on their HDD.
If allot of nodes enable pruning, will not the blockchain become less secure (because there are less nodes to download historical data from)?

Use SPV client, Electrum for instance and you won't have to download blockchain history. Leave the responsibility to do the blockchain validation to servers. 

[equator]

What is the solution against the bots that automatically and frequently upload unnecessary data into the Bitcoin blockchain?

With pruning enabled, nodes could save space on their HDD.
If allot of nodes enable pruning, will not the blockchain become less secure (because there are less nodes to download historical data from)?

Use SPV client, Electrum for instance and you won't have to download blockchain history. Leave the responsibility to do the blockchain validation to servers. 

I agree with your point because which problem OP is telling will be faced if you are using blockchain wallet but if you are using using Electrum or other hardware wallet which dont require to download whole datas but just upload the software and use your wallets.

[aleksej996]

Formally this is why there are mining fees and block size limits in the first place.
So those are the only official solutions for it right now.

Of course miners can always agree not to accept certain junk transactions if they wish to do so.

How do you define a junk transaction though? Surely if somebody pays the proper fee, their transaction should be as valid as any other.

I knew someone was about to ask me this, but I really don't know how to answer this question.
I don't define it. I am just saying that OP's problem can be solved with a soft fork.

It is hard for me to explain why I used the words I did. I just found this to be best way to answer OP's question in a way he will understand my point in an easy way.

It is feels really "meta" that I am talking about this. Discussions on forums always seem to work this way and I am not sure why.

[Loveboard]

If u think Bitcoin is currency, then you should have no problem with bots performing needless unlimited small transactions.

It's the same as asking a bank what they should do about "bots" running up $0.01 transactions at flea markets with their credit cards. And what response would a bank give? They'd say, "it's fine, because they're still paying 3.2% transaction fee XD"

If bitcoin starts turning down "junk transactions," but credit cards widely process these junk transactions, then it shows that bitcoin can't be a true anonymous, decentralized, regulation-free currency. That's why we have to be just as good and better than credit cards.

If there are junk transacitons, it's fine. Because miners are still being paid to process them.

If you have a problem with that, maybe choose a centralized solution 

[PremiumCodeX]

It doesn't make the network less secure. The availability (of the blocks) for others to download from sinks.
The 'security' is more dependent from the total hash rate.

Hash rate is important for sure, but
isn't availability considered security, according to the Confidentiality - Integrity - Availability triad?
Don't we think if any member of the triad sinks, security sinks?

[DannyHamilton]

It doesn't make the network less secure. The availability (of the blocks) for others to download from sinks.
The 'security' is more dependent from the total hash rate.

Hash rate is important for sure, but
isn't availability considered security, according to the Confidentiality - Integrity - Availability triad?
Don't we think if any member of the triad sinks, security sinks?

The historical blocks are only useful for starting up a new full node.  As long as there is at least one reliable location for a user to get the historical blocks from, they can bootstrap a new node.  After that, they and the rest of the network have no need or use for the historical blocks.

It will always be important that there are enough accessible nodes that have the historical blocks so that anyone can add a new node whenever they choose to do so, but the accessibility of those historical blocks does not add anything to the security for the existing full nodes.

[PremiumCodeX]

I think, the question has been well answered so am going to close the topic.

The only "solution" for now are :
1. Limiting block weight size (which is 4000 kWU).
2. Set minimum transaction output (AFAIK, it's about 500 satoshi).
3. Protocol which won't let anyone upload/broadcast unnecessary data besides valid transaction into Bitcoin network.
4. Set minimum accepted fees which is 1 sat/byte, but AFAIK it's possible to set it lower even though some miners or nodes might ignore that transaction.

Thank you for collecting the alternatives!

I knew someone was about to ask me this, but I really don't know how to answer this question.
I don't define it. I am just saying that OP's problem can be solved with a soft fork.

It is hard for me to explain why I used the words I did. I just found this to be best way to answer OP's question in a way he will understand my point in an easy way.

It is feels really "meta" that I am talking about this. Discussions on forums always seem to work this way and I am not sure why.

It is alright. Personally, I would define junk transaction as "Junk transaction is a transaction that was created with the intention to maliciously take place in the blockchain." or "Junk transaction is a transaction that contains more data than what would be necessary to serve a given purpose." These are my personal thoughts after a long day at Uni.

It will always be important that there are enough accessible nodes that have the historical blocks so that anyone can add a new node whenever they choose to do so, but the accessibility of those historical blocks does not add anything to the security for the existing full nodes.

I am not worrying about the accessibility of the historical blocks now, but I had this idea: If there were so many historical blocks that new nodes were very difficult to add and the existing nodes were running out of space, the full nodes could run out of free space by time and their number could decrease and when there would remain only a smaller number of full nodes, it would be easier to hack the majority of them. I think it is more a theoretical question for now than technical, though, and that would take us into another section. So, I am closing this discussion now. Just think about it.