bitcoins use case has change
this is because things called OPCODES change the use case of a transaction. whereby it changes how much data can be contained in a transaction. how much of that data is even validated/accounted/counted. and other things.
when new opcode subsets are released changing the bitcoin rules via softening the rules.. it changes how bitcoin is used.
starting with allowing 4mb of unvalidated, miscounted junk to be appended to a tx that has no functional utility of signing proof of the sats intended to be moved, but sit at the end of tx for nonsense unrelated purpose to bitcoin functionality, which most bitcoin nodes dont even check the content of such added data ..
bitcoin code(rules) were strong years ago, where every byte had purpose and was counted and checked to meet the rules..
devs used to care about every bit and byte. and want efficiency...
now devs want congestion and miscounting of bytes and inclusion of bytes that have no purpose
the whole softening of the rules in the last 7 years has not helped bitcoin. but has just helped dev politics do as they please even at the annoyances of bitcoiners..
Yes, you are correct that Bitcoin's use case has evolved over time due to changes in opcode rules. Opcodes enable the execution of specific operations within a Bitcoin transaction. When new opcode subsets are released, it can modify the rules of Bitcoin by allowing for different data sizes and validation processes.
The introduction of new opcodes can increase the data capacity of a transaction, allowing for the inclusion of additional information that may not be directly related to the intended purpose of the transaction. While some Bitcoin nodes may not validate or analyze the content of such added data, it still becomes a part of the transaction.
actually no.. let me clarifyopcodes used to only be activated when they were needed for new features by actually including conditions, limitations and expectation to give nodes something to validate and reject if they didnt meet those conditions..
however activated opcodes with no conditions is the problem.. as there is no size limit or validation formatting requirement of unconditioned opcodes.. and there lays the exploit/problem
there was a subset of opcodes made during segwit activation season where a few dozen extra opcodes were made active but without conditions set
and then when taproot activation occured, now there are hundreds of opcodes that are active without conditions
these opcodes should not have been active by default(hindesights a b!tch). but instead should have periodically activated when new features were needed/(after proposed, reviewed,scrutinised), where conditions would have been set and the network of nodes would then upgrade to be network ready to validate such conditions and then the feature can be activated knowing the network is ready to validate a new features
but the softening of consensus (which WAS a concept of network readiness majority before activation), has caused the controversy.
now there are many opcodes that nodes dont have conditions to validate, so just pass and let into the blockchain. unchecked.
and people are exploiting that consensus softening of not needing node readiness for new features
whats needed now is to clean up the cludgy code.. and refine the code to actually want to know whats being added to the blockchain by requiring new features to be proposed where a myriad of node brands collectively use consensus to be network ready of new features before feature activation(before trojan gets passed the gatekeepers) whereby the new features have conditions of validity to be checked. where every byte is explained by its purpose and every byte is counted and has reason for being.
its called network security
its called data efficiency
where we get back to offering feature of actual utility and leanness of real functionality and validity checking
