If the purpose was to allow more functionality, and it did, isn't this a personal opinion ?

Demand is not a bug or spam.

It's one thing to opt in to Knots, it's another for core to continue to decide changes like this.

This and Future changes that exclude large segments of use that otherwise follow the rules of supply, ect are vulnerable to politics.

Political money is fiat money.

Today, you consider this spam. Tomorrow what ese will be considered spam. To the death of bitcoin.

One mans free speech is anothers hate speech. Who are you or core , to decide ?

Reply to this note

Please Login to reply.

Discussion

I’m still undecided - but what if we look at it like a bug. We actually do fix the bugs in bitcoin and nobody says it’s censorship. What we have here is just a disagreement in what is and isn’t a bug, right?

yes. It comes down to what one person or faction feel is a bug and what others do not. These opinions hampered by the limits to that one individual or groups values and life experience, attempting to speak for millions of others.

The real bug is in how we arrive at the definition of what a bug is, in the first place.

On a private project, a team lead decides.

On a public project, it becomes political.

There is a third option, market choice.

People who subscribe to Luke's worldview and vision for Bitcoin can download and run Knots.

Another way to let the market decide is to reduce the scope and importance of core, and move features to a layer 2, where consumers choose.

Some bugs and upgrades are not political of course. Things such as a flaw in SHA that requires emergency fork. Other bugs are maintenance or efficiency types, as languages and procedures backing the project improve. These can keep being pushed to core, but the surface area can be further reduced, along with ossification.

The history of projects shows that when political and technical become confused, the project will eventually alienate so many people, despite the best of intentions and logic, it dies.

If you tell your node not to allow extra data beyond 40 bytes, and it then allows 40k, how is that ever not a bug?

In that case yes. Your node should do what you want it to.

Unless i'm missing something however, what you are trying to get core to adopt is not an optional toggle, but a hard size limit, where legacy or non-complient nodes cannot participate or are shunned going forward ? Thus the blocking of "spam" network wide.

The wording leads me to believe that's your intention. Or would it still be optional to inscribe if you want ?

It's one thing to run Knots/Ocean and gather/market support for it. It's another to frame it as a bug and push it to core as a new defacto standard.

By the way, unlike the blocksize debate, this change affects proven profits by motivated network participants. Since adoption and use appear to be increasing unabated despite the "spam", are you fully cognizant of the down stream impact such a change would have ? The second order effects and blowback ?

The idea in Bitcoin is that anyone is free to write and release their own reference client, implementing the consensus rules, as they see fit. It is up to the users to decide whether or not to use that client.

That's all that's happening here....

Free market operating perfectly. Make your choices. No drama.