For example if it is a hard fork to increase block size in the future when the need arises, then my answer is a big fat YES. We definitely need to increase the on-chain capacity at some point but the important part is the "at some point" part.
Only time will tell, but I guess it will be much easier to convince people to include 1 GB commitment, as an addition to 4 MB witness, than to create a hard-fork, and include this 1 GB directly. It will simply not happen. If there would be some chances to get it, then Segwit would also be a hard-fork.
Which means, people could increase witness by adding "a second witness" called "commitments" or whatever. But I don't think it will be a regular hard-fork, because the longer that change needs to wait, the more ossified and "set in stone" everything is. And in the future, it will be even harder to convince BTC users to do any hard-fork, unless strictly needed (for example in 2038, because this bug can shutdown old nodes). If you create some unnecessary hard-fork on BTC, then users will call it an altcoin, and create a competing soft-fork or no-fork, and then your hard-fork will be "outside Bitcoin", just because of backward compatibility. The only chance to get a successful hard-fork, is when the old software crashes, and if there is no way to fix them without upgrading.
When it is used as "cloud storage" it is considered abuse and the transactions are spam. Meaning right now that the congestion is caused by abusing the protocol to perform an attack on bitcoin, this is not natural and the exploit should be fixed instead of increasing the capacity to let bigger spam in.
True. Even if someone supports big blocks, then other changes are more important. And if they won't be deployed first, then the final result will contain just Ordinals flood, UTXO flood, and a lot of other, not-yet-invented forms of spamming the chain.
P.S. I don't think increasing block capacity has ever been a "taboo" as some like to exaggerate it. HOW it is increased has been the source of a lot of disagreement.
Also true. We have soft-forks, because they are backward compatible. We could have a hard-fork, but then, there is a huge risk, that some people will call it "an altcoin", and release a competing soft-fork or no-fork. Which means, if you have all development power in your hands, and you release some hard-fork, then you risk losing it. Also, Ordinals can show you that too: Core developers didn't include Ordinals to their Bitcoin Core client, but they are still present on-chain. Which means, now people know, how to add new things, without asking Core. Which means, more people will start deploying their half-baked inventions, without asking for permission, or voting for a new soft-fork, so be ready for a huge spam of no-fork projects.
If the sole purpose of bitcoin was just to transfer money what's the role of OP_pushdata ? And especially OP_pushdata4 ?
The role of OP_PUSHDATA is to push data (duh!). And why we have OP_PUSHDATA4? Well, because Satoshi released 32-bit version, and four bytes can be used to express some 32-bit number. Guess what: if the first version would be 64-bit, we could have OP_PUSHDATA8 as well.
But, I can ask you another question: if Satoshi wanted to fully use OP_PUSHDATA4, then why he limited MAX_SIZE of the P2P message into 32 MiB (0x02000000), and later limited block size into 1 MB (1000000)? Why November 2008 version was limited to only 32 MiB P2P message size? Yes, that November 2008 version, which contained quite huge Script support, what you can discover by exploring the Script of the coinbase transaction, used in that version (also note that it contained 100.00 BTC, expressed with 2-digit precision only as "10k satoshis", instead of 8-digit precision we have today, and that OP_CODESEPARATOR was mandatory at that time).
Seems that the creator had a different view than yours .
The whole Script is not necessary for Bitcoin to function. In the whitepaper, you have only P2PK, and nothing else. And it is still called Bitcoin, and people still check many coins if they implement everything from whitepaper, if they want to call something "the true Bitcoin" or not. Which means, your OP_PUSHDATA4 is not even mentioned there. We could start from P2PK-only system as well, and add commitments later, or even attach Schnorr signatures or TapScript later, directly into those public keys. Then, in such system, spending-by-pubkey would be always mandatory, but some keys (for example the private key equal to one) could require a commitment to some Script.
And how do you measure that? Even if we were to follow that route, and have a block size limit that corresponds to the "legitimate usage", how do we begin?
For that reason, I think we should not try to measure that, but instead implement some way to compress pubkey-based transactions, while leaving non-standard use cases uncompressed. In this way, users could make cheap transactions, which could be combined into more expensive ones, while Ordinals users, and other spammers, would still need to pay the full price. In general, I think the price you pay for your transaction, should be relative to the level of compression you can achieve. Public keys can be compressed by Schnorr signatures. Arbitrary data pushes will usually stay uncompressed. The Hutter Prize record at the moment of writing allowed compressing 1 GB of Wikipedia into around 114 MB. But pubkey-based transactions could be compressed much further than that, you will hit a wall during compression, only if you push regular data, you won't have such problems with signatures, that could be just combined, because you can cover 1000-of-1000 multisig with a single signature.
Edit: Also, Satoshi explicitly said something about uploading videos:
I admire the flexibility of the scripts-in-a-transaction scheme, but my evil little mind immediately starts to think of ways I might abuse it. I could encode all sorts of interesting information in the TxOut script, and if non-hacked clients validated-and-then-ignored those transactions it would be a useful covert broadcast communication channel.
That's a cool feature until it gets popular and somebody decides it would be fun to flood the payment network with millions of transactions to transfer the latest Lady Gaga video to all their friends...
That's one of the reasons for transaction fees. There are other things we can do if necessary.
See? The answer was not "just use OP_PUSHDATA4, and upload it". The answer was "fees are needed to discourage that". And even more: "if fees will not be sufficient, then we can do something else to limit it further". That's what he said, as you can see above, and click on the link to the quote to confirm it.
Seems that the creator had a different view than yours .
