Bitcoin Forum
April 05, 2026, 09:49:32 PM *
News: Latest Bitcoin Core release: 30.2 [Torrent]
 
   Home   Help Search Login Register More  
Pages: [1]
  Print  
Author Topic: Possible solutions for preventing bloat in the bitcoin blockchain  (Read 157 times)
pokeybear (OP)
Newbie
*
Offline Offline

Activity: 8
Merit: 1


View Profile
May 06, 2025, 11:26:52 PM
Last edit: May 07, 2025, 11:57:48 PM by pokeybear
 #1

I am new to Bitcoin development but curious, interested, and happy to learn new things. I would like to discuss ideas for preventing and reducing blockchain bloat. Like many of you, I desire that Bitcoin remain as decentralized as possible. That means we probably want to make it easier to run full nodes that don’t require much more than 800 GB of storage space over the course of many years.

Other people mentioned that one issue in the Bitcoin network is that some miners will process non-monetary or harmful transactions directly for monetary rewards, especially if they are receiving millions of dollars to do so.  People have unsuccessfully tried to convince miners to stop doing that.  It seems the next best option to prevent abuse is a software change.

Do you think it’s possible to modify the Bitcoin Core and other software to make certain transactions go through a specific consensus of node operators before miners are allowed to process them? It seems like many people running nodes might be more reliable because there’s less chance of them getting monetarily incentivized to corrupt the blockchain.

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?

I have an idea, and I don’t know if it is possible:  If a transaction meets specific criteria before it gets sent from one node to the rest of the network, could it update a temporary approval count variable?  Then, all the other nodes could see the approval value of the transaction and update the approval number if they agree the transaction is good.  If the transaction’s approval number is high enough, and if there is a way to know that more than 70% of active nodes have approved it, then the transaction could proceed to be processed by a miner.

What do you think?
achow101
Moderator
Legendary
*
expert
Offline Offline

Activity: 3920
Merit: 7676


Just writing some code


View Profile WWW
May 07, 2025, 02:03:41 AM
Merited by LoyceV (12), gmaxwell (5), d5000 (5), ABCbits (5), nc50lc (1)
 #2

I have an idea, and I don’t know if it is possible:  If a transaction meets specific criteria before it gets sent from one node to the rest of the network, could it update a temporary approval count variable?  Then, all the other nodes could see the approval value of the transaction and update the approval number if they agree the transaction is good.  If the transaction’s approval number is high enough, and if there is a way to know that more than 70% of active nodes have approved it, then the transaction could proceed to be processed by a minor.

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

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.

stwenhao
Hero Member
*****
Offline Offline

Activity: 657
Merit: 1695


View Profile
May 07, 2025, 03:15:33 AM
 #3

Quote
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.
Even in that case, it is quite likely, that people would still be able to make public keys, where they don't know the private key, but can produce a valid signature. A good example is this public key: https://mempool.space/testnet/address/032baf163f5e27261ab3228e61fb86dc98054abd514751fce93d7444e8fbc6a293

As you can easily check, the size of the signature is only 9 bytes, and it is crafted in a way, where knowing the private key would mean, that you would also know the private key to 020000000000000000000000000000000000000000000000000000000000000001, which would probably mean, that ECDSA is broken (or you found some hidden secret behind secp256k1 generator).

Because making a single signature can be sometimes faked. And even if validation would be bulletproof, then still, signing things, and throwing away private keys, would still be possible.

Proof of Work puzzle in mainnet, testnet4 and signet.
ABCbits
Legendary
*
Offline Offline

Activity: 3570
Merit: 9904



View Profile
May 07, 2025, 09:38:32 AM
Last edit: May 10, 2025, 09:50:43 AM by ABCbits
 #4

I am new to Bitcoin development but curious, interested, and happy to learn new things. I would like to discuss ideas for preventing and reducing blockchain bloat. Like many of you, I desire that Bitcoin remain as decentralized as possible. That means we probably want to make it easier to run full nodes that don’t require much more than 800 GB of storage space over the course of many years.

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

Do you think it’s possible to modify the Bitcoin Core and other software to make certain transactions go through a specific consensus of node operators before minors are allowed to process them? It seems like many people running nodes might be more reliable because there’s less chance of them getting monetarily incentivized to corrupt the blockchain.

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.

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 theoretical address format which make fake public key/address become more expensive.

███████████████████████████
███████▄████████████▄██████
████████▄████████▄████████
███▀█████▀▄███▄▀█████▀███
█████▀█▀▄██▀▀▀██▄▀█▀█████
███████▄███████████▄███████
███████████████████████████
███████▀███████████▀███████
████▄██▄▀██▄▄▄██▀▄██▄████
████▄████▄▀███▀▄████▄████
██▄███▀▀█▀██████▀█▀███▄███
██▀█▀████████████████▀█▀███
███████████████████████████
.
.Duelbits PREDICT..
█████████████████████████
█████████████████████████
███████████▀▀░░░░▀▀██████
██████████░░▄████▄░░████
█████████░░████████░░████
█████████░░████████░░████
█████████▄▀██████▀▄████
████████▀▀░░░▀▀▀▀░░▄█████
██████▀░░░░██▄▄▄▄████████
████▀░░░░▄███████████████
█████▄▄█████████████████
█████████████████████████
█████████████████████████
.
.WHERE EVERYTHING IS A MARKET..
█████
██
██







██
██
██████
Will Bitcoin hit $200,000
before January 1st 2027?

    No @1.15         Yes @6.00    
█████
██
██







██
██
██████

  CHECK MORE > 
gmaxwell
Moderator
Legendary
*
expert
Offline Offline

Activity: 4704
Merit: 10519



View Profile WWW
May 07, 2025, 10:11:02 PM
Last edit: May 07, 2025, 10:34:18 PM by gmaxwell
Merited by d5000 (5), nc50lc (2)
 #5

Do you think it’s possible to modify the Bitcoin Core and other software to make certain transactions go through a specific consensus of node operators before minors are allowed to process them?
If that worked bitcoin never would have had mining in the first place.  Mining exists because it doesn't work, for the reasons highlited by Ava.  Aside, the term is miner not minor-- the confusion is understanble, both are known to play with blocks.

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.
In addition to the excellent points as to why these sorts of schemes don't work anyone proposing these schemes should explain why, if their scheme actually worked, wouldn't just be a way for some rogue government actor to impose a blockaid on donating to their political opponents or what not.

The whole reason preventing 'spam' in Bitcoin is hard is because Bitcoin was designed to be censorship resistant and to depend itself on censorship resistance to work, to take advantage of the nature of information being easy to spread and hard to stifle.  You don't need to settle the perennial debate on if filtering data stuffing nft shitcoin nonsense constitutes censorship itself to recognize that from a technical perspective the same *means* are used, and have similar effectiveness.

If anything ordinary transactions are more vulnerable than bullshit:  Bullshit doesn't care much about how it's encoded.  Ground into TXIDs? Stuffed into 'fake addresses', twiddling bits of signatures?  There is no end to the flexibility of bullshit encoding because the network doesn't do anything with the bullshit data.  The honest user can't so easily freely change what they're doing to avoid some filter targeting them, and they may be much less well funded than a spammer.  It's easy for a spammer to e.g. get a relationship with a miner because while although what they're doing may be unpopular and repugnant to many, it isn't *illegal* anywhere, it's not going to get some powerful state actor mad at you, the worst it does is outrage a largely impotent social media mob. And even the angry mob can be avoided because miners can produce blocks anonymously too (and should be more often).

Now I don't fear for Bitcoin's censorship resistance, these filtering methods ultimately don't work all that well.  But their advocates argue that not working well doesn't necessarily mean doing nothing at all-- maybe pushing hard and constantly issuing updates that stamp out each use as it's discovered could at least reduce the total volume of spam.  Yes, it probably could.   But at what cost?   You've just appointed or empowered a self appointed dictator[1] over what transactions are good or not, who will now waste lots of energy squishing stuff and you'll inevitable disagree with some of their decisions.  Even if there is some kind of *vote* someone is deciding how it works or setting its default behaviors.  You'll have sent a clear message to powerful actors that there exists tools to suppress transactions they don't like (or just haven't approved of) if only they apply enough pressure to node operators, developers, and/or miners.  And sure while the censorship may not be complete, they may not care just like people constantly demanding 'spam' filtering are fine with it being incomplete at best.

I've grown wary of calling this traffic spam because it result in the wrong way of thinking about it.  Spam is messages directed to you that you don't want, filtering it is largely effective because all the filtering need to do is keep it from showing up in front of you-- it's still 'effective' when your (ISPs) computer had to process the spam, it's still effective if someone *else* got the spam. It just has to keep you from seeing it.   But this traffic in bitcoin involves a consenting sender, one or more consenting receivers, and a consenting miner who happily got paid for their facilitation.  To block it effectively, it has to be blocked by pretty much everyone.  Because-- short of using a block explorer or something-- you would never even see the 'spam' at all, the criteria for success is stuff like your computer not spending time processing it (or at least not storing it in the chain)... and that is an infinitely higher bar than applies for email spam.

So I think you could fairly say that if you define spam the same way we do for email Bitcoin is already has almost perfect spam filtering,  that the only spam that remains is varrious kinds of 'dusting'.   People seldom complain about dusting though for that there are lot of additional things that could be done, because like email spam you wouldn't have to block it everywhere for everyone for it to have an impact, and because there is an involuntary receiver that doesn't want it.

I think people too easily fall into the trap of thinking some obnoxious shitcoin stuff is "the enemy" and forgetting what Bitcoin is for in the first place. Shitcoin nft stuff isn't the enemy, the enemy is systems of money that are capriciously controlled by third parties, inflated out from under us, surveilled, seized, and wielded as a weapon against the political opponents of whomever has power over it. The embedded data stuff an annoyance, an impediment, occasionally a bit of a threat.. no doubt but it's not the enemy.  If it were it would have an easy solution: set the block size to zero and head home. No more spam!   When you run a node you take on varrious costs in doing so,  such as processing the 99.999999% of transactions that have nothing to do with you.  It's a cost of Bitcoin's existence and a well justified one.  Junk traffic is just part of that.  It's critical that nothing is able to flood you off the chain, junk traffic or not, aided by miners or not, but that's part of why the Bitcoin consensus rules have limits on the amount of resources the system can take up.


[1] And inevitably the person who wants this job most is the person who on no accounts should be allowed to have it... that is even clear already in Bitcoin where the most outspoken anti-spam person is basically infamous for their fringe judgemental views.
pokeybear (OP)
Newbie
*
Offline Offline

Activity: 8
Merit: 1


View Profile
May 07, 2025, 11:34:27 PM
Last edit: May 09, 2025, 05:01:17 PM by mprep
 #6

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.

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.




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.


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.



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.



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


 Grin 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]
Pages: [1]
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!