Bitcoin Core October Upgrade

[_act_]

Some people on this forum would have known about Bitcoin Core development and transaction relay policy which some people think would be about OP-RETURN and Ordinals, although Core developers did not directly mentioned any like that.

The users of Bitcoin Knot which is alternative means to run a full node is drastically increasing. It started from when MPR #32406 was introduced which will be part of the upgrade. It is about the OP_RETURN data limit increase from 80 bytes to 4 Megabyte. Definitely some people that like just only text and not image and other large files to be included on the blockchain will not like it.

Another thing is the Ordinals, BRC20 tokens and maybe other coming ones spamming the mempool to be blocked. Which means such transactions might be rejected even as they obey the consensus rule and valid. This probably make some people leave Bitcoin Core and started using Bitcoin Knot. Bitcoin Core node runners increased from 394 nodes to over 2000 nodes, although Core users are around 87% while Knot users are still around 13%, but there are speculations that Knot users might continue to increase and take over Core users. This may be very wrong but just a speculation.





I understood everything I read about this but except on thing. If there is upgrade to Bitcoin Core, is it possible for the Bitcoin Core developers to make some changes mandatory for the non-Core users? Like people using Bitcoin Knot to follow their upcoming October Upgrade? I am asking this question because I think Bitcoin Core developers against Ordinals while some node runners may like it as long as their transaction is not against the consensus rules.

If I make any mistake, you can correct me. I only have little knowledge about the politics and principles surrounding bitcoin.

[achow101]

If there is upgrade to Bitcoin Core, is it possible for the Bitcoin Core developers to make some changes mandatory for the non-Core users?

No.

Policy changes have no effect on the policy rules that other nodes may choose to follow. Consensus changes would be the only changes the could "require" other node software to follow suit, but even then, it's still up to the node operators to decide which consensus rules they want to follow by choosing which software they wish to run.

[BitGoba]

No, Bitcoin Core developers cannot force changes on the entire network, especially not on people using other implementations. Bitcoin is decentralized  rules are only valid if users, and nodes choose to adopt them.

When Bitcoin Core releases an upgrade, it’s completely optional. If you run a full node, you decide whether to update or not. And even if a new feature is added, it has no effect unless the wider network agrees to use it.

This is what makes Bitcoin unique  no single group can change the rules on their own. Consensus is what matters, not code alone.

[NotATether]

No, Bitcoin Core developers cannot force changes on the entire network, especially not on people using other implementations.

That's why it's good that alternative clients are finally catching on, if only Bitcoin Knots for now.

Now we're getting Ethereum's operational decentralization which they had for years.

[takuma sato]

The main point of Bitcoin is that it is decentralized. You can run your own implementation, code it yourself, compile it, and run it. Understandably so, a lot of people are against the spam of questionable content in the blockchain (namely, anything non-monetary, in other words, anything that isn't transactions) and that is why Bitcoin Knots is picking up traction. Hopefully. Bitcoin Knots becomes the #1 implementation, or before that happens, Bitcoin Core sets it as it was before the update.

[Ambatman]

The main point of Bitcoin is that it is decentralized. You can run your own implementation, code it yourself, compile it, and run it. Understandably so, a lot of people are against the spam of questionable content in the blockchain (namely, anything non-monetary, in other words, anything that isn't transactions) and that is why Bitcoin Knots is picking up traction. Hopefully. Bitcoin Knots becomes the #1 implementation, or before that happens, Bitcoin Core sets it as it was before the update.

Unfortunately compared to Core it's More centralized and I read somewhere that they censor certain transactions.
Knot adoption has increased to approximately 14% from 2% couple of weeks ago.

Client diversity is a Plus for Bitcoin.

[Mia Chloe]

Unfortunately compared to Core it's More centralized and I read somewhere that they censor certain transactions.
Knot adoption has increased to approximately 14% from 2% couple of weeks ago.
Client diversity is a Plus for Bitcoin.

If I remember vividly I think there was a post on the development and technical discussion board a couple of weeks back where someone also brought up a discussion about knot being better than bitcoin core what I think bitcoin calls still take the leaderboard in terms of adoption since it is basically more popular it was on recent I even got to no more about Knot.

Actually bitcoin Core developers cannot force non Core users like those running Bitcoin Knot to adopt specific policy changes that are not part of the consensus rules. Although they can actually propose and implement changes within Bitcoin Core other node software like Knot is kinda free to implement its own relay policies as long as they still adhere to the fundamental consensus rules of the Bitcoin network. It's all about preference if you ask me.

[Wind_FURY]

No, Bitcoin Core developers cannot force changes on the entire network, especially not on people using other implementations. Bitcoin is decentralized  rules are only valid if users, and nodes choose to adopt them.

When Bitcoin Core releases an upgrade, it’s completely optional. If you run a full node, you decide whether to update or not. And even if a new feature is added, it has no effect unless the wider network agrees to use it.

This is what makes Bitcoin unique  no single group can change the rules on their own. Consensus is what matters, not code alone.

Plus if an individual does decide to upgrade his/her node, isn't the part of the block where the data resides by way of OP_RETURN prunable? That's probably better than embedding data where it can be a long-term problem for the network, no?

I believe that Bitcoin-Stamps use OP_RETURN. The dick pics and fart sounds on the blockchain lovers will start minting using MikeInSpace's "protocol".

[stwenhao]

isn't the part of the block where the data resides by way of OP_RETURN prunable?

If you don't care about Initial Blockchain Download, then it is. But if you do, then in the current implementation, new nodes require downloading all data from 2009, up to today. As long as it is the case, there will be a problem with spamming the chain. It is technically possible to implement things in a way, where the exact data from OP_RETURN won't be needed to bring back new nodes to the network, but today, it is not yet implemented.

That's probably better than embedding data where it can be a long-term problem for the network, no?

Yes, storing things in OP_RETURN is better, than storing them elsewhere. But still: committing to data, without pushing them on-chain, is even better. And as long as you have to download and process each and every OP_RETURN, to synchronize the chain, it is a problem, no matter how and where things are stored.

In general: being forced to process everything from 2009, up to today, is a problem, which will be more and more urgent, as more time will pass, no matter if blocks will be filled with regular transactions, or with just data pushes. And moving the responsibility to keep that data, from the network, to the user, is technically possible. Then, things could be pruned by all nodes, and users would need to provide more data, when spending their coins, instead of relying on nodes to keep the full history forever.

And of course, some people may want to not accept future upgrades, and still store and process everything. Of course they can. But as it will be more and more costly, the incentive to upgrade will grow, and eventually, people will do that, to not store terabytes of historical data in the future.

[Wind_FURY]

isn't the part of the block where the data resides by way of OP_RETURN prunable?

If you don't care about Initial Blockchain Download, then it is. But if you do, then in the current implementation, new nodes require downloading all data from 2009, up to today. As long as it is the case, there will be a problem with spamming the chain. It is technically possible to implement things in a way, where the exact data from OP_RETURN won't be needed to bring back new nodes to the network, but today, it is not yet implemented.

That's probably better than embedding data where it can be a long-term problem for the network, no?

Yes, storing things in OP_RETURN is better, than storing them elsewhere. But still: committing to data, without pushing them on-chain, is even better. And as long as you have to download and process each and every OP_RETURN, to synchronize the chain, it is a problem, no matter how and where things are stored.

In general: being forced to process everything from 2009, up to today, is a problem, which will be more and more urgent, as more time will pass, no matter if blocks will be filled with regular transactions, or with just data pushes. And moving the responsibility to keep that data, from the network, to the user, is technically possible. Then, things could be pruned by all nodes, and users would need to provide more data, when spending their coins, instead of relying on nodes to keep the full history forever.

And of course, some people may want to not accept future upgrades, and still store and process everything. Of course they can. But as it will be more and more costly, the incentive to upgrade will grow, and eventually, people will do that, to not store terabytes of historical data in the future.

OK, but the point is, isn't it better for the network if dick pics and fart sound lovers to have their data embedded by way of OP_RETURN than to have them embedded in the UTXO-set, or other storage schemes, which will be more problematic long-term?

[buwaytress]

Some time last year I asked if there was any noticeable or distinct effort from "the core" for client diversity. Something Ethereum developers have occassionally brought up and advocated for (not an Ethereum fanboy, but from an objective perspective the client has always seemed like a logical vector of attack for me) but not something I observed from Bitcoin's side of things.

I wonder if this is such an effort?

If I remember vividly I think there was a post on the development and technical discussion board a couple of weeks back where someone also brought up a discussion about knot being better than bitcoin core ~

Not about being better, there is always a matter of client suiting needs methinks.

[ABCbits]

Plus if an individual does decide to upgrade his/her node, isn't the part of the block where the data resides by way of OP_RETURN prunable? That's probably better than embedding data where it can be a long-term problem for the network, no?

AFAIK there's still no full node software that allow prune only OP_RETURN output. Besides, it doesn't change the fact you still need to download and verify whole block first.

I believe that Bitcoin-Stamps use OP_RETURN. The dick pics and fart sounds on the blockchain lovers will start minting using MikeInSpace's "protocol".

Bitcoin Stamps (also called SRC-20) actually use P2MS. Here's the proof, https://github.com/stampchain-io/stamps_sdk/blob/main/docs/src20specs.md.

[stwenhao]

but the point is, isn't it better for the network

It is better, but far from sufficient in the long-term. And there are ways to timestamp any given data, without abusing Initial Blockchain Download. If users will abuse the chain too much, then just encouraging people to switch to OP_RETURN won't be sufficient, and then, there are more things, which can be done, for example by making more lightweight nodes, which would require less resources, and which would accept some proofs, instead of storing everything.

In general, I expect there will be some abuse, and some people will make a lot of unspendable outputs, no matter how often they will be encouraged to use OP_RETURN instead. And then, if it will be needed to make further changes, to stop the abuse, then they will be taken, when node runners will start running out of resources, and if there will be a need to encourage more people to run nodes. Because here and now, many people don't want to process over 600 GB, just to get the ability to share the chain, and introduce new nodes to the network. Which means, that if the chain will grow too much, then further actions will be needed, to keep the network decentralized enough, and to scale it properly.

Besides, it doesn't change the fact you still need to download and verify whole block first.

You need that only in the current implementation. But it can be changed in the future, and it will change, if more people will want to do something with the problem of spamming the chain. Because here and now, the system is wide open to non-standard transactions, which will push a lot of data, and which will send coins from zero satoshis to zero satoshis, and every full node will be forced to process that Bitcoin-unrelated traffic. There is no UTXO set size limit, and there is no total chain size limit. And people don't have unlimited resources, so such things can be restricted in the future, to allow running full nodes by enough separated entities, and limit that kind of centralization pressure.

[Wind_FURY]

Plus if an individual does decide to upgrade his/her node, isn't the part of the block where the data resides by way of OP_RETURN prunable? That's probably better than embedding data where it can be a long-term problem for the network, no?

AFAIK there's still no full node software that allow prune only OP_RETURN output. Besides, it doesn't change the fact you still need to download and verify whole block first.

I understand that. But the point is, what's the lesser evil? Data that's embedded by way of OP_RETURN, or data embedded in the UTXO-set?

  ¯\_(ツ)_/¯

I believe that Bitcoin-Stamps use OP_RETURN. The dick pics and fart sounds on the blockchain lovers will start minting using MikeInSpace's "protocol".

Bitcoin Stamps (also called SRC-20) actually use P2MS. Here's the proof, https://github.com/stampchain-io/stamps_sdk/blob/main/docs/src20specs.md.

Thanks for reminding me. I remember posting about this during the Ordinals craze, and that it couldn't be pruned at all?

[stwenhao]

what's the lesser evil? Data that's embedded by way of OP_RETURN, or data embedded in the UTXO-set?

OP_RETURN is better, but it is still far from being the best way to handle it.

and that it couldn't be pruned at all?

If new nodes will remove that data from their storages, and will keep only a proof, that a given coin is there, then users will have to provide not only signatures, but also public keys, when they will want to spend their coins. And if data converted into public keys leads to unknown or unspendable private keys, then such things would never be touched. And if less and less nodes will provide such data, then there will be less incentive to push them on-chain in the first place, when accessing historical transaction data will be harder than today, and if the effort of doing that will be shifted from nodes to users.

So, in general, it is the question, if some people want to make enough developers angry, to move dust expiry from theoretical discussion land into practice: https://delvingbitcoin.org/t/dust-expiry-clean-the-utxo-set-from-spam/1707

[ABCbits]

--snip--
AFAIK there's still no full node software that allow prune only OP_RETURN output. Besides, it doesn't change the fact you still need to download and verify whole block first.

I understand that. But the point is, what's the lesser evil? Data that's embedded by way of OP_RETURN, or data embedded in the UTXO-set?

I agree with @stwenhao, OP_RETURN is less harmful than other option to add arbitrary data on Bitcoin blockchain.

--snip--
Bitcoin Stamps (also called SRC-20) actually use P2MS. Here's the proof, https://github.com/stampchain-io/stamps_sdk/blob/main/docs/src20specs.md.

Thanks for reminding me. I remember posting about this during the Ordinals craze, and that it couldn't be pruned at all?

P2MS is old form of address with N-of-M signature requirement to spend it. So Bitcoin node which prune all P2MS UTXO from it's UTXO list unable to verify TX that spend one or more P2MS UTXO and likely to treat it as invalid TX.

So, in general, it is the question, if some people want to make enough developers angry, to move dust expiry from theoretical discussion land into practice: https://delvingbitcoin.org/t/dust-expiry-clean-the-utxo-set-from-spam/1707

Some people really have wild idea. If it become reality, it may turn into mouse and cat game where token/NFT protocol will enforce or recommend to create UTXO with higher satoshi value.

[Wind_FURY]

what's the lesser evil? Data that's embedded by way of OP_RETURN, or data embedded in the UTXO-set?

OP_RETURN is better, but it is still far from being the best way to handle it.

OK, that answers that question. It's probably why the debate should focus on how to make dick pics and fart sound lovers embed their NFTs in the part of the block where it would be less of a problem long-term.

I understand that it's isn't the best solution, but if we consider the fact that nothing will stop the dick picks and fart sound lovers, what would be a better solution than that?

and that it couldn't be pruned at all?

If new nodes will remove that data from their storages, and will keep only a proof, that a given coin is there, then users will have to provide not only signatures, but also public keys, when they will want to spend their coins. And if data converted into public keys leads to unknown or unspendable private keys, then such things would never be touched. And if less and less nodes will provide such data, then there will be less incentive to push them on-chain in the first place, when accessing historical transaction data will be harder than today, and if the effort of doing that will be shifted from nodes to users.

So, in general, it is the question, if some people want to make enough developers angry, to move dust expiry from theoretical discussion land into practice: https://delvingbitcoin.org/t/dust-expiry-clean-the-utxo-set-from-spam/1707

  👍

[stwenhao]

but if we consider the fact that nothing will stop the dick picks and fart sound lovers, what would be a better solution than that?

I already answered both questions: first, it is not true, that "nothing will stop" it. And second, I already shared a link, describing what could happen, if people will abuse the chain too much: https://delvingbitcoin.org/t/dust-expiry-clean-the-utxo-set-from-spam/1707

See? Here and now, every node have to process the whole UTXO set. But, things can be changed in future versions, and node operators can decide, that they don't want to store everything. Today, we have full archival nodes, and pruned nodes. Currently, you can bring around 600 GB of historical data into something like 10 GB of the UTXO set.

However, if there will be more and more spam, then the UTXO set can grow much faster than today. It can take 20 GB, 30 GB, and so on, and so forth, until reaching the point, where the size of historical data will be comparable with the size of the UTXO set, and then, pruning won't do anything good anymore, and will only block you from bringing new nodes to the network.

And then, node operators can decide to implement proposals like linked above, which would allow them to process the subset of the UTXO set, and stay compatible with the rest of the network. Which means, that if there will be too much spam, then it is possible, that it will make enough developers angry, to implement solutions, which will keep spammers away from money-based transactions.

For example: imagine that today, you can visit some block explorer, and it will show you some on-chain posted image. But if there will be too much spam, then imagine that future version could require users to store their own images locally instead, because new nodes could refuse to store non-consensus-related data at all, or even store any historical data at all, and require all users, who will want to move their coins, to provide more data during spending.

And then, if exploring the full history won't be that easy, as it is today, and if everyone will be forced to keep those things locally, or else such coins will be unspendable, then it will stop a lot of people from spamming, and only the most persistent ones will keep doing that. If people will find out, that Bitcoin is not a cloud storage, and you simply cannot be a leecher in this P2P network anymore, then old NFTs will simply behave like old torrents with no seeders.

So, the question is: do you want to push Bitcoin in that direction? Because if someone is pro-NFT, then that person should be aware, what could be a consequence of using Bitcoin for every blockchain-related thing, instead of focusing on payments. Simply, non-monetary use cases can be punished in the future, and then, the whole monetary activity can be moved into some subnetwork, while leaving mainchain people with a spammed chain, which is not used to move any coins anymore.

[Wind_FURY]

but if we consider the fact that nothing will stop the dick picks and fart sound lovers, what would be a better solution than that?

it is not true, that "nothing will stop" it.

Debatable unless we could change human behavior. People will still mint, trade, send, receive their dick pics and fart sounds on-chain on the Bitcoin blockchain simply because "they can".

Developers like Casy Rodarmor found a "clever" storage scheme to embed data when "it was not supposed to do that", no? Now we have Ordinals, BRC-20, and Runes.

[stwenhao]

People will still mint, trade, send, receive their dick pics and fart sounds on-chain on the Bitcoin blockchain simply because "they can".

Of course. But then, people willing to use Bitcoin as a P2P money will simply move to other subnetworks, while leaving on-chain spam, where it currently is. And then, you will have a choice: use the current client, and process all of that money-unrelated spam, or upgrade your client, and focus on monetary transactions.

So, it is only a matter of making enough people angry enough, to develop that kind of solutions. Satoshi was angry, because of fiat currencies, and that pushed him to make Bitcoin in the first place. If fiat currencies would be better, then Bitcoin wouldn't exist, because then, there would be no need to make it (which you can also read directly in the Genesis Block, how "second bailout" was literally the input to create Bitcoin).

And if NFT enthusiasts will abuse the chain more than they should, then some developers can be pushed to their limits, and make a money-only-based network, on top of Bitcoin, which would be designed, to explicitly exclude other use cases. Technically, it can be done, it is only a matter of pushing people enough, to start discussions, similar to what I linked, and bring changes like that into reality.

Also, as long as spammers are strong, such changes would be just optional. I don't want to force everyone to follow my rules, but note, that ideas like dropping UTXOs can come from developers as well. And in that case, they can make it mandatory, by turning them into soft-forks. And then, I don't know, what will be the end result, but I guess the optional path will be taken anyway, and just P2P money enthusiasts will move to their own subnetwork, where they will focus on money, and everyone else will use the official version, which would allow a lot of spam, and would have heavy requirements to run a node, if you compare it with other alternative, more spam-resistant clients.

For now, my plan is to still stick with Bitcoin Core, but as you can see, by pushing more spam on-chain, many people can be convinced to use a different implementation, or to run their own tools on top of Bitcoin Core (which is for example how Paul Sztorc wanted to introduce sidechains, by making his "Core Untouched Soft Fork" client). If there will be more spam, then such things will just happen more often, and some people will start using different implementations, to make Bitcoin usable with lower resource requirements, and fight with centralization pressure, made by spammers.