Quote from: vjudeu on November 17, 2023, 11:59:53 PM

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).

I can't get into the techinical details as i'm not educated in this . But , you can understand that at that time HDD's and broadband speed were not the same as today . Also the network was at it's infancy . Things changed since then .
I'll quote satoshi :

Quote from: satoshi on June 17, 2010, 06:46:08 PM

The nature of Bitcoin is such that once version 0.1 was released, the core design was set in stone for the rest of its lifetime. Because of that, I wanted to design it to support every possible transaction type I could think of. The problem was, each thing required special support code and data fields whether it was used or not, and only covered one special case at a time. It would have been an explosion of special cases. The solution was script, which generalizes the problem so transacting parties can describe their transaction as a predicate that the node network evaluates. The nodes only need to understand the transaction to the extent of evaluating whether the sender's conditions are met.

The script is actually a predicate. It's just an equation that evaluates to true or false. Predicate is a long and unfamiliar word so I called it script.

The receiver of a payment does a template match on the script. Currently, receivers only accept two templates: direct payment and bitcoin address. Future versions can add templates for more transaction types and nodes running that version or higher will be able to receive them. All versions of nodes in the network can verify and process any new transactions into blocks, even though they may not know how to read them.

The design supports a tremendous variety of possible transaction types that I designed years ago. Escrow transactions, bonded contracts, third party arbitration, multi-party signature, etc. If Bitcoin catches on in a big way, these are things we'll want to explore in the future, but they all had to be designed at the beginning to make sure they would be possible later.

I don't believe a second, compatible implementation of Bitcoin will ever be a good idea. So much of the design depends on all nodes getting exactly identical results in lockstep that a second implementation would be a menace to the network. The MIT license is compatible with all other licenses and commercial uses, so there is no need to rewrite it from a licensing standpoint.

"Bitcoin isn't currently practical for very small micropayments. Not for things like pay per search or per page view without an aggregating mechanism, not things needing to pay less than 0.01. The dust spam limit is a first try at intentionally trying to prevent overly small micropayments like that.
Bitcoin is practical for smaller transactions than are practical with existing payment methods. Small enough to include what you might call the top of the micropayment range. But it doesn't claim to be practical for arbitrarily small micropayments. "

"Quote from: theymos on October 03, 2010, 08:28:39 PM
Applying this patch will make you incompatible with other Bitcoin clients.

+1 theymos. Don't use this patch, it'll make you incompatible with the network, to your own detriment.

We can phase in a change later if we get closer to needing it."

And for the backwards compatibility part that most believe should not change , the moment satoshi proposed

"It can be phased in, like: if (blocknumber > 115000) maxblocksize = largerlimit It can start being in versions way ahead, so by the time it reaches that block number and goes into effect, the older versions that don’t have it are already obsolete. "

the road for hard forks open . If satoshi was against it , he wouldn't post such a thing , but would propose something in a backwards compatible way .

Quote

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.

The answer is in the quotes above . Script is necessary for bitcoin to work as a network that apps and new type of transactions can be build upon . They're not necessary for bitcoin to work just as a medium of exchange .

Quote

Edit: Also, Satoshi explicitly said something about uploading videos:

Quote from: satoshi on June 18, 2010, 04:17:14 PM

Quote from: gavinandresen on June 17, 2010, 07:58:14 PM

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.

Nope , don't make words look like what you want them to be . He says "that's one of the reasons for transaction fees" . If you want to use the network that way you have to pay the price .
Also states " There are other things we can do if necessary" . What he meant by that ? Who knows .
He doesn't explicitly states that using OP_pushdata4 is forbidden like you make it look like .
And to put it another way , if he didn't want it he wouldn't have added it to OP's .