(Ordinals) BRC-20 needs to be removed

[LoyceV]

By using the same words, you could also say that about Lightning Network: "on-chain Bitcoins are locked" (behind 2-of-2 multisig), and also "then an equivalent amount of tokens are minted" (but here, it may be even worse, because of conversions between satoshis and millisatoshis, so you can "create millisatoshis out of thin air", because you cannot finalize them on-chain in the current version).

I don't care about millisatoshis, and I'm totally find rounding them when settling on-chain. That's franky's thing to bring up, and it's kinda pointless to even discuss if you pay an on-chain transaction fee that's a million times larger. And that's the problem with LN: I know it's locked, but what's the point if you can't afford the fee for on-chain settlement?

[1714874862]

1714874862

[1714874862]

1714874862

[1714874862]

1714874862

[1714874862]

1714874862

[1714874862]

1714874862

[Wind_FURY]

But from my understanding of how the two-way peg works in sidechains is, on-chain Bitcoins are locked, then an equivalent amount of tokens are minted in the sidechain representing Bitcoin.

By using the same words, you could also say that about Lightning Network: "on-chain Bitcoins are locked" (behind 2-of-2 multisig), and also "then an equivalent amount of tokens are minted" (but here, it may be even worse, because of conversions between satoshis and millisatoshis, so you can "create millisatoshis out of thin air", because you cannot finalize them on-chain in the current version).

So, if you would have 2-of-2 multisig addresses on the sidechain, then what would be the difference? Because obviously, if you would have single-key addresses on the sidechain, then coins could be easily turned into IOU. However, if you would use exactly the same bytes as in LN, then where is the moment, when it is "not Bitcoin"?

OK, the frankandbeans debate.

I'm the stupid one in the forum, and I actually want to learn from the point you're making. Teach me. How are the Bitcoins in those payment channels in Lightning "IOUs"? Where/how are the coins stored/locked and how are the "IOUs" issued?

The argument is rather than have an IOU representing a coin, I would like to have the actual coin.

It only depends on your spending conditions. If you have single-key address, then it can be turned into IOU, but it also has some use cases (for example as a test network). However, if you use the same scripts, as in LN, then where is that IOU?

I don't know. But, I'm confused, kindly explain to me how a Bitcoin-pegged-coin in a sidechain is an actual Bitcoin. What is the process of on-ramping Bitcoin in a sidechain, and what is the process of on-ramping Bitcoin in the Lightning Network.

[vjudeu]

That's franky's thing to bring up, and it's kinda pointless to even discuss if you pay an on-chain transaction fee that's a million times larger.

Yes, but it is not about the amount, but about the ownership: if you want to have millisatoshis on-chain, then in the current version, you can only have a large multisig, behind a single satoshi, so if you have 500 millisatoshis from Alice, and the same from Bob, then all you can do, is to use 2-of-2 multisig on a single satoshi.

How are the Bitcoins in those payment channels in Lightning "IOUs"?

I think they are not. But if people say that coins in sidechains are, then coins in LN should also be called in the same way, if we follow the same logic.

Where/how are the coins stored/locked and how are the "IOUs" issued?

You have IOUs only in centralized sidechains. For example: if you have a sidechain, where you have some large multisig, and you cannot be a miner, if you are not a part of some closed group, then those coins are IOUs. However, if you have decentralized sidechain, then you can use any scripts you want, because every block is covered only by hashrate, and not by some centrally-selected signature, like in signet.

But, I'm confused, kindly explain to me how a Bitcoin-pegged-coin in a sidechain is an actual Bitcoin.

1. If you have to provide a valid signature for a given coin, to transfer it from mainchain into sidechain, then it is based on real coins, and not some "coins created out of thin air".
2. If you have to move a given coin on the mainchain, to bring it back from the sidechain to the mainchain, then it is the same situation as with LN: you can always peg-out, without asking for anyone's permission.

And those two things alone: sign things to peg them in, and move them to peg them out, is sufficient to make a test network for decentralized sidechains. However, if you want to get the main network, then it is all about creating rules for the scripts, used to lock your coins. Which means, that if you have a single-key address, then you can test it alone, but no sane person will accept some coins, if the sender can always take them back, without losing anything. For that reason, the basic building block for decentralized sidechains is N-of-N multisig, where you can have a lot of people behind a single UTXO. And then, all kinds of improvements are focused on making "emergency scripts", to for example not require all N participants to be online, to change the state of the sidechain.

Because if you would have for example non-interactive transaction joining, then a single Taproot UTXO is all you need, to handle a single decentralized sidechain. And then, it is all about combining all signatures from that sidechain, and finalizing it as a simple commitment on-chain, which would have a constant size, regardless of how many people will use a given sidechain.

What is the process of on-ramping Bitcoin in a sidechain, and what is the process of on-ramping Bitcoin in the Lightning Network.

It didn't change that much since the last time, when I wrote about it: https://bitcointalk.org/index.php?topic=5231460.msg61778369#msg61778369

[LoyceV]

Yes, but it is not about the amount, but about the ownership: if you want to have millisatoshis on-chain, then in the current version, you can only have a large multisig, behind a single satoshi, so if you have 500 millisatoshis from Alice, and the same from Bob, then all you can do, is to use 2-of-2 multisig on a single satoshi.

Why do you even care about receiving 0.5 sat from anyone? I don't care about fractions of cents, even though half a cent is worth a lot more than a whole satoshi. The exchanges I use count cents behind the decimal, and if I close my account, I lose them. That's fine.

2. If you have to move a given coin on the mainchain, to bring it back from the sidechain to the mainchain, then it is the same situation as with LN: you can always peg-out, without asking for anyone's permission.

If pegging out costs you $100 in transaction fees, it's only worth it for large amounts. Most people won't want to do it several times per month. That's rent money or food money.

[Wind_FURY]

How are the Bitcoins in those payment channels in Lightning "IOUs"?

I think they are not. But if people say that coins in sidechains are, then coins in LN should also be called in the same way, if we follow the same logic.

Where/how are the coins stored/locked and how are the "IOUs" issued?

You have IOUs only in centralized sidechains. For example: if you have a sidechain, where you have some large multisig, and you cannot be a miner, if you are not a part of some closed group, then those coins are IOUs. However, if you have decentralized sidechain, then you can use any scripts you want, because every block is covered only by hashrate, and not by some centrally-selected signature, like in signet.

OK, I actually have MANY questions for you. But before we go further, you're describing something like Paul Sztorc's Drivechains - BIP-300/ BIP-301?

But, I'm confused, kindly explain to me how a Bitcoin-pegged-coin in a sidechain is an actual Bitcoin.

1. If you have to provide a valid signature for a given coin, to transfer it from mainchain into sidechain, then it is based on real coins, and not some "coins created out of thin air".

2. If you have to move a given coin on the mainchain, to bring it back from the sidechain to the mainchain, then it is the same situation as with LN: you can always peg-out, without asking for anyone's permission.

And those two things alone: sign things to peg them in, and move them to peg them out, is sufficient to make a test network for decentralized sidechains. However, if you want to get the main network, then it is all about creating rules for the scripts, used to lock your coins. Which means, that if you have a single-key address, then you can test it alone, but no sane person will accept some coins, if the sender can always take them back, without losing anything. For that reason, the basic building block for decentralized sidechains is N-of-N multisig, where you can have a lot of people behind a single UTXO. And then, all kinds of improvements are focused on making "emergency scripts", to for example not require all N participants to be online, to change the state of the sidechain.

Because if you would have for example non-interactive transaction joining, then a single Taproot UTXO is all you need, to handle a single decentralized sidechain. And then, it is all about combining all signatures from that sidechain, and finalizing it as a simple commitment on-chain, which would have a constant size, regardless of how many people will use a given sidechain.

Although, who secures the decentralized sidechains, and I assume that they follow different consensus rules? I believe the answer to "If it's Bitcoin?", that's where everything starts to be more complicated

Plus is it possible for a sidechain to fork away from Bitcoin, and never return?

[vjudeu]

But before we go further, you're describing something like Paul Sztorc's Drivechains - BIP-300/ BIP-301?

Yes, something like that.

who secures the decentralized sidechains

The same miners, which secure Bitcoin. It is based on Merged Mining.

and I assume that they follow different consensus rules?

All new rules are expressed as a combination of existing ones, which means, that all mainchain rules are followed.

I believe the answer to "If it's Bitcoin?", that's where everything starts to be more complicated

The basic rules are simple: you sign your coins to peg them in, and move them to peg them out. And of course, it is Bitcoin, because every signature is compatible with Bitcoin. And if you have something new, then it is expressed as a combination of existing rules. If you think that it is not Bitcoin, then it applies to LN as well (because the main difference is that you don't have to open a channel, if you already have some shared output, and you can reuse existing LN transactions on such sidechain).

Plus is it possible for a sidechain to fork away from Bitcoin, and never return?

It depends, which forks you have in mind. When it comes to hard forks, then you can apply that on each and every coin, including Bitcoin, and you have some altcoins, which did exactly that (but it is not possible to stop anyone from trying to do, what for example BCH did). But if you think about soft-forks or no-forks, then things could co-exist, without losing a peg. Because it is all about following the chain of signatures: if you have a signature, that is valid on Bitcoin, and on the sidechain at the same time, then you cannot really tell, that "it forked away", because you can see exactly the same chain of signatures in both networks.

Even more interesting things are possible: if some altcoin or sidechain preserved enough rules, then you can recreate the same chain of signatures in both networks, if you reach identical coinbase transactions. Because their uniqueness is based only on a block number, and not for example on block hashes, so things can be duplicated. Some example: https://bitcointalk.org/index.php?topic=5479988.msg63437260#msg63437260

Which means, that "and never return?" is never the case, because there are no technical issues with recreating a peg in those chains, which lost it in the past. But the community just don't want to get that feature, which is why nobody implemented it. There is even a page about blockchain fusion, if you are interested: https://www.truthcoin.info/blog/blockchain-fusion/

[sherlockphone]

And at this point, how to fix the problem? those of us who maintain nodes could have the option to accept or not these ordinals? or is it up to the miners?

[larry_vw_1955]

And at this point, how to fix the problem?

the only way you can fix it is to fix the code. so the exploit is not allowed anymore. but the devs haven't shown any inclination to doing that and they will never do it. so we're stuck with it unless we do some type of fork.

those of us who maintain nodes could have the option to accept or not these ordinals?

apparently you can run something called a pruned node:

https://thebitcoinmanual.com/behind-btc/nodes/pruned-node/

you don't even have to download the entire blockchain first if you download a snapshot from a "trusted" source.   we all trust everyone we download from so why not right?  

or is it up to the miners?

the miners could reject any type of transaction they want to but why would they? it will just cost them money.

[d5000]

And at this point, how to fix the problem?

the only way you can fix it is to fix the code. so the exploit is not allowed anymore. but the devs haven't shown any inclination to doing that and they will never do it. so we're stuck with it unless we do some type of fork.

Please don't repeat that again, we have discussed that extensively in this and another threads. It is simply wrong that it can be "fixed" (at least not easily, BTC would have to adopt the Monero or Grin protocol to "fix" it).

I have written an example in this post in another thread that you could encode a token like BRC-20 or Runes in a transaction with two simple P2(W)PKH outputs. How would you "fix" that "exploit"? It would be actually much worse than Runes and even Ordinals because it clutters the UTXO set.

I don't like Runes but they are at least a bit better than the BRC-20 bullshit.

those of us who maintain nodes could have the option to accept or not these ordinals? or is it up to the miners?

As a node operator you can choose to ignore transactions with a "datacarriersize" of more than an arbitrary number of bytes you can define yourself. On Bitcoin Core, this only affects data transactions using OP_RETURN, like Runes, while Luke Dashjr's "Bitcoin Knots" can detect Ordinals too. But of course if a miner accepts an Ordinals transaction and includes it into a block, then you have to add the block containing it to the blockchain.

You could change the code to fork away, i.e. some nodes -- and miners -- could unite to create a hard fork without any Taproot- or OP_RETURN-based "data transactions", but that would incentive the behaviour I have described in my answer to larry_vw_1955. And very likely it would be a minority hardfork.

[larry_vw_1955]

Please don't repeat that again, we have discussed that extensively in this and another threads. It is simply wrong that it can be "fixed" (at least not easily, BTC would have to adopt the Monero or Grin protocol to "fix" it).

you can always fix something especially if you're the one that caused it...

I have written an example in this post in another thread that you could encode a token like BRC-20 or Runes in a transaction with two simple P2(W)PKH outputs. How would you "fix" that "exploit"? It would be actually much worse than Runes and even Ordinals because it clutters the UTXO set.

ok then why aren't people doing that then? go ahead and answer. is it because it is too expensive or inconvenient or they just don't know about it.

I don't like Runes but they are at least a bit better than the BRC-20 bullshit.

see if i was the one that designed bitcoin i would have made it impossible for all these type of things to happen. my bitcoin would be a bit lean and mean. and if people wanted to pollute the utxo set then they would pay a hefty price for doing so. because there would be no data storage component.

[DooMAD]

Please don't repeat that again, we have discussed that extensively in this and another threads. It is simply wrong that it can be "fixed" (at least not easily, BTC would have to adopt the Monero or Grin protocol to "fix" it).

you can always fix something especially if you're the one that caused it...

"Cause" is a funny thing.  The inventors of the internet itself "caused" Ordinals just as much as Bitcoin devs did. People can use things in ways that were never anticipated.  You're using the Internet to spread misinformation and foolishness right now, for example.

Are car manufacturers responsible for "fixing" cars so that people can't use them to commit vehicular manslaughter?  Surely the manufacturers "caused" that, right?  

If you made something and then someone used it in a way that you never conceived it could be used, is it your responsibility to change the thing you made?  And then are you also obligated to "fix" every other possible way in which they could use it for some other purpose?  Are people not free to use the thing you made in the way they want to use it?  Is it your place to determine that?

It is not the developers' responsibility to police the globe.  First and foremost, it's not remotely practical to envision every way in which someone could abuse the protocol to embed crap or spam the network.  Second, if there were a way to lock the protocol down to prevent people from using it in unforseen ways, it would be far more difficult to maintain and develop the code.  And lastly, Devs have no interest in being the "thought police" and dictating to others what they can or can't do.

Please stop buying into the abject idiocy some people are talking about Ordinals.  You can't "fix" human propensity for greed and selfishness.  It would be a fool's errand to try.

see if i was the one that designed bitcoin i would have made it impossible for all these type of things to happen.

Ah, yes, the inevitable "I could do a better job" comment.  Go on, then.  Show us all how it's done.  Except you never will.

[ABCbits]

And at this point, how to fix the problem?

the only way you can fix it is to fix the code. so the exploit is not allowed anymore. but the devs haven't shown any inclination to doing that and they will never do it. so we're stuck with it unless we do some type of fork.

As i said previously, fork isn't really needed. You could just make Ordinal TX become non-standard. And few attempt to do that always rejected, see
https://github.com/bitcoin/bitcoin/pull/28408
https://github.com/bitcoin/bitcoin/pull/29769

those of us who maintain nodes could have the option to accept or not these ordinals?

apparently you can run something called a pruned node:

https://thebitcoinmanual.com/behind-btc/nodes/pruned-node/

you don't even have to download the entire blockchain first if you download a snapshot from a "trusted" source.   we all trust everyone we download from so why not right?

Even with pruned node, you can't avoid accepting valid block which may contain Ordinal TX.

[d5000]

ok then why aren't people doing that then? go ahead and answer. is it because it is too expensive or inconvenient or they just don't know about it.

The truth is that this has been done several times since 2013 or 2014, but never a "fad" developed around these early protocols. In fact, it was an intelligent move of the developers to make OP_RETURN standard in 2014, because as I wrote the earlier protocols clutter the UTXO set, while OP_RETURN outputs are not stored there (they can be safely pruned by nodes - @franky1 incoming saying "these are not full nodes" 3... 2... 1... ).

Stampchain tried to introduce a similar protocol called SRC-20 recently, embedding the tokens into "normal-looking" multisig transactions. Fortunately (for the UTXO set) they failed to get any adoption, probably due to Runes being already discussed at that time they launched.

Fads sometimes have strange behaviour. BRC-20 survived a lot despite much better and cheaper alternatives existed since before they were developed, and the reason was probably that it was conceived inside the NFT community which was too lazy to investigate better protocols. But in this case actually it's a blessing that a fad around Stampchain tokens or similar mechanisms never existed.

see if i was the one that designed bitcoin i would have made it impossible for all these type of things to happen. my bitcoin would be a bit lean and mean. and if people wanted to pollute the utxo set then they would pay a hefty price for doing so. because there would be no data storage component.

OK, so how is your plan?

The challenge is that you can actually not allow anything which can be used for arbitrary data. For example, probably publicly visible fields for values with a large number of digits could be enough. Public key hashes too, like I demonstrated in the post I linked above.

You could have forked Grin or Monero, but these protocols were developed years (Monero: 2014, Grin: 2018) after Bitcoin was. So you would have had to travel in time. And even these do allow some inscription mechanisms but you would have to link several transactions so they would be effectively more expensive than "payment" transactions. For example, for Monero Mordinals exists, and for grin at least a proof of concept was shown on Github.

[larry_vw_1955]

Ah, yes, the inevitable "I could do a better job" comment.  Go on, then.  Show us all how it's done.  Except you never will.

You had quite a long post there and i can't respond to every single question but i think you understand the issues involved.

Satoshi did a better job. If they would have just left it that way. But instead they had to introduce things like OP_RETURN, segwit and taproot. What do you think the end result of all that is going to be? that's right. a huge mess.

I don't hold satoshi responsible for all this mess though. If people want to store data on the blockchain, they should have to pay through the nose but then they would never do it in the first place most likely. Just like it never caught on before all these upgrades took place. "upgrades".

Satoshi showed us how it's done.

OK, so how is your plan?

Surprisingly, the plan would be similar to the original bitcoin. Only a few transaction types. No OP RETURN no nothing like that.

The challenge is that you can actually not allow anything which can be used for arbitrary data. For example, probably publicly visible fields for values with a large number of digits could be enough. Public key hashes too, like I demonstrated in the post I linked above.

Only have one transaction type. Pay to public key hash. That really is all I would have. The simpler the better and less exploitable it is. No upgrades for higher level functionality, nothing like that. Only bug fixes if necessary. But no new "features". Doing one thing and doing it well is all that really is necessary. Bitcoin has kind of lost that with all these ugrades and things. And we see the end result.

Thank you for the question.

[pooya87]

Please don't repeat that again, we have discussed that extensively in this and another threads. It is simply wrong that it can be "fixed" (at least not easily, BTC would have to adopt the Monero or Grin protocol to "fix" it).

Let's first define the exploit and the problem then see if it can be fixed or not.

The exploit is that the Bitcoin protocol previously had strict rules about stack item sizes and script sizes. These rules were loosened for witnesses and that means the attackers can now inject an arbitrary size data in their witness without the tx becoming invalid.
This can and should be fixed.

What you are explaining is another attack vector that had existed from day one and was also exploited in early days leading to introduction of OP_RETURN rules and said "exploits" were moved into said output types.
As I've said before, in a decentralized blockchain we can not prevent abuse. What we can do is to make it harder and more expensive. For example we could never make a spam attack impossible (like the so called "stress test" pre-2017) but with fee market we can make it harder and more expensive.

[ABCbits]

Ah, yes, the inevitable "I could do a better job" comment.  Go on, then.  Show us all how it's done.  Except you never will.

You had quite a long post there and i can't respond to every single question but i think you understand the issues involved.

Satoshi did a better job. If they would have just left it that way. But instead they had to introduce things like OP_RETURN, segwit and taproot. What do you think the end result of all that is going to be? that's right. a huge mess.

I don't hold satoshi responsible for all this mess though. If people want to store data on the blockchain, they should have to pay through the nose but then they would never do it in the first place most likely. Just like it never caught on before all these upgrades took place. "upgrades".

Satoshi showed us how it's done.

You talk as if OP_RETURN, segwit and taproot bring no advantage. Should we remind you to few of these facts?
1. OP_RETURN created mainly to reduce P2PKH abuse by encoding 20-byte of arbitrary data as public key hash. It means less UTXO which will never be used.
2. SegWit practically solve transaction malleability and quadratic sighash problem.
3. Taproot let you only reveal part of the script. It means slightly better privacy and less TX size.

OK, so how is your plan?

Surprisingly, the plan would be similar to the original bitcoin. Only a few transaction types. No OP RETURN no nothing like that.

The challenge is that you can actually not allow anything which can be used for arbitrary data. For example, probably publicly visible fields for values with a large number of digits could be enough. Public key hashes too, like I demonstrated in the post I linked above.

Only have one transaction type. Pay to public key hash. That really is all I would have. The simpler the better and less exploitable it is. No upgrades for higher level functionality, nothing like that. Only bug fixes if necessary. But no new "features". Doing one thing and doing it well is all that really is necessary. Bitcoin has kind of lost that with all these ugrades and things. And we see the end result.

Thank you for the question.

Only P2PKH? I guess we should say goodbye to multi-signature address, address with "inheritance" feature, LN, sidechain and other innovations.

[vjudeu]

Only have one transaction type. Pay to public key hash.

1. Why not pay to compressed public key, without any hashing?
2. Why not restrict it to only valid public key coordinates, to have all existing UTXOs always "mathematically spendable"?

In case of hashes, it is possible, that some particular value could be simply unreachable, and then you won't know, if a given UTXO will ever be spent or not.

Only P2PKH? I guess we should say goodbye to multi-signature address, address with "inheritance" feature, LN, sidechain and other innovations.

As I said in some other topic, if I would want to create a new altcoin from scratch, then it would be based only on public keys and signatures. Because it is possible to add a Script later, just like TapScript is connected with the Taproot public key. Which means, that a new chain could contain only public keys, and operations on them (for example: a signature is a relation between two public keys, formed by addition and multiplication by some known numbers; in general: R=Q*first+second, both for classical ECDSA, and for Schnorr signatures, just different formulas are hidden behind "first" and "second").

Which means, that if you have some P2TR address, and you spend only by key, then multi-signature can work fine on top of that. In case of sidechains, they could be based on top of any scripts, including N-of-N multisig. And if by "inheritance" you mean applying some kind of locktime, then it is outside of the Script, just as the last field of the transaction. Also, in case of Segwit, if you create things from scratch, then you don't have to include signatures in transaction hashes (but unfortunately, Satoshi put that model even in the whitepaper, but for new coins, built from scratch, they could have separated signatures from the very beginning, for each and every transaction; and also that new altcoin could make hashing a transaction much easier, than it is done today by "FindAndReplace" or by Segwit/Taproot partial hashing of some chunks, and combining it).

[larry_vw_1955]

Only have one transaction type. Pay to public key hash.

1. Why not pay to compressed public key, without any hashing?
2. Why not restrict it to only valid public key coordinates, to have all existing UTXOs always "mathematically spendable"?

In case of hashes, it is possible, that some particular value could be simply unreachable, and then you won't know, if a given UTXO will ever be spent or not.

of course you are right. that would all be EVEN SIMPLER. and the simpler the better. as long as we agree not to worry about theoretical quantum computing attacks on published public keys. they're not a thing right now. but if was designing a brand new crypto system i think i might need to make it quantum resistant somehow.

You talk as if OP_RETURN, segwit and taproot bring no advantage. Should we remind you to few of these facts?

leave "memos" (aka OP_RETURN) to yellow sticky notes on your refrigerator. i wouldn't have it my crypto system.
Yes SegWit did solve the transaction malleability issue and improved signature verification time but i don't have an issue with those bug fixes. i don't think an entirely new address type was needed though. we need to keep things SIMPLE.
I don't find Taproot to be a compelling argument. or necessity.
but thanks for your insights.

1. OP_RETURN created mainly to reduce P2PKH abuse by encoding 20-byte of arbitrary data as public key hash. It means less UTXO which will never be used.
2. SegWit practically solve transaction malleability and quadratic sighash problem.
3. Taproot let you only reveal part of the script. It means slightly better privacy and less TX size.

if as vjudeu pointed out we used just P2PK instead of P2PKH, you can ensure that every utxo is spendable and not just some burn address. so i might agree to his idea...

As I've said before, in a decentralized blockchain we can not prevent abuse. What we can do is to make it harder and more expensive. For example we could never make a spam attack impossible (like the so called "stress test" pre-2017) but with fee market we can make it harder and more expensive.

this is certainly the bottom line. and a reasonable one at that. i WOULD give you a merit poooya but i think i'm out of them at the moment.  

i was thinking about a way to get rid of unspendable spam in the utxo set what you could do is have different tiers of utxo sets. the longer they go without being spent, they keep moving down to lower and lower tiers until finally it is going to cost alot to spend them. since nodes could decide which tiers they wanted to store. not all nodes would store all tiers. and the ones that did are going to certainly want compensation if they are a miner. a fee market tier structure on the utxo set...

[d5000]

Only have one transaction type. Pay to public key hash.

Did you read the post I linked to show how P2(W)PKH can be "exploited" too? Seems not. P2PK would also be affected by this. Again: A fad based on P2PKH tokens would be much more disastrous for BTC than one based on OP_RETURN tokens.

2. Why not restrict it to only valid public key coordinates, to have all existing UTXOs always "mathematically spendable"?

This is interesting and I have thought also about a related idea, but can it be proven that a private key exists for a given public key?

My related idea was a kind of "invitation-only" coin: that you have to derive a key always from another key and announce this derivation with a mathematic proof that it is spendable before you can transact value to them (i.e. create a challenge based on that PK). This would allow that only "spendable" keys could be created. But first, I'm unsure about the math, and second, that would not be really an "open", "free" cryptocurrency.

Perhaps also a proof that a public key is spendable is possible without deriving the key from an existing one?

However I believe even that can be used for data storage, but it would already make it more difficult (not necessarily more expensive though).

The exploit is that the Bitcoin protocol previously had strict rules about stack item sizes and script sizes. These rules were loosened for witnesses and that means the attackers can now inject an arbitrary size data in their witness without the tx becoming invalid.

I'd have no problem if this particular problem is "fixed". However, the bigger inscriptions were only a problem for a short time in early 2023. Since then the focus has shifted to BRC-20, which is also the topic of this thread by the way, and BRC-20s were "compliant" to script size rules established before. In other words, for tokens like BRC-20, the "lifting" of the size limit in Taproot is irrelevant. This was also extensively discussed here.  

Now we have Runes, which are also compliant, but have cluttered a couple of blocks. I said already that I don't like their economic model. But I'm relatively "happy" that they exist and have driven BRC-20 out of the market, because they should take 30-40% less space if we consider how inefficient BRC-20 was. I think we'll soon see "blue" (<10 sat/vbyte) fee rates again.

[vjudeu]

as long as we agree not to worry about theoretical quantum computing attacks on published public keys

We don't have to worry about that, even in a chain with only public keys, and nothing else. Because in case of some quantum attack, all of those inputs would behave just like OP_TRUE. Which means, that if you require a valid signature in spend-by-key path, and add a new requirement to accept only spend-by-new-signature-path, then it would be possible to upgrade the system in a backward-compatible way.

For example: imagine that someone could easily break all public keys. If the new system would require a valid signature in the old style, and a new stack push, where SHA-256(newData) would be equal to the x-value of that public key, then guess what: breaking ECDSA alone would not give the attacker any advantage here, because it would be needed to also break for example SHA-256 (but you can apply any not-yet-broken hash function there instead, if SHA-256 will be too weak at that time).

P2PK would also be affected by this.

There are two things: one is simplifying address types, and another one is preventing spam. For the former, something like P2PK looks fine (but it would be closer into spend-by-key in P2TR in practice, with some modifications, like prefixing keys with 02 and 03). For the latter, you would need transaction joining on the protocol level. Because if you cannot join public keys and signatures, then you cannot prevent spam. But if you can do so, then nobody can abuse the system with a lot of random public keys, because then all of them are added, and committed to a single public key, so it no longer matters if you create one UTXO or thousands of them (the on-chain size remains the same, only public keys are tweaked, to commit to your data). And in that kind of system, the only space for abuse is left in the block headers, but you would need some blockstorm, like in testnet3, to get there.

Again: A fad based on P2PKH tokens would be much more disastrous for BTC than one based on OP_RETURN tokens.

Yes. But there are two separate topics here: one is to make BTC better, and fix the system, which is already deployed. Another is to make something from scratch. And the latter is much easier than the former. But because some questions were about making simple things from scratch, then I think it is definitely possible to create a new system, that is resistant to those spam attacks.

When it comes to fixing existing system, then it is about simplifying Initial Blockchain Download, and compressing existing data. In that case, people would still need to pay the same fees as today, but it would be possible to not store and process some data, if they are not used in consensus rules.

but can it be proven that a private key exists for a given public key?

Yes. If you have any public key, and you know (x,y) coordinates, then if the equation y^2=x^3+7 is valid, when you apply modulo p-value, then it is 100% guaranteed, that there is some private key, which allows moving those funds. If you have some smaller elliptic curve, then you can brute force all of those keys. If you have slightly bigger one, then you can get a distance between any two public keys, in a reasonable time. For serious, huge elliptic curves, you cannot brute force it, but you can prove, how many points are there, because it is needed to create a valid curve in the first place, and calculate n-value, based on p-value. And if you can compute it, then you can also prove, that there are exactly N valid keys.

you have to derive a key always from another key and announce this derivation with a mathematic proof that it is spendable before you can transact value to them

It is always possible to create "trap public keys" in such system. Even more than that: in Bitcoin, you can move some coins from public keys, where nobody knows the private key, but the signature is valid, because of SIGHASH_SINGLE bug. Some example: https://mempool.space/testnet/tx/3952b35bde53eb3f4871824f0b6b8c5ad25ca84ce83f04eb1c1d69b83ad6e448

Related topic: https://bitcointalk.org/index.php?topic=5373858.0
You have this address: https://mempool.space/testnet/address/032baf163f5e27261ab3228e61fb86dc98054abd514751fce93d7444e8fbc6a293

Nobody knows the private key, but as you can see, it was spent in testnet3. And similar tricks can be used, to prove, that something is spendable during initialization, but never move that coin later in another way. However, if your public key will be committed, instead of being revealed, then creating thousands of UTXOs will have the same on-chain size, as creating a single UTXO. The only needed thing is transaction joining in non-interactive way, enforced on a protocol level (and if you create something from scratch, then it can be introduced, without worrying about backward-compatibility).

Perhaps also a proof that a public key is spendable is possible without deriving the key from an existing one?

Even if something is spendable, then the creator could simply generate private keys, move coins into public keys, and throw away those private keys. Which means, that the problem of abusing space is related more to data compression and transaction joining, than to preventing the ability to make some unspendable UTXO. But of course, having all UTXOs mathematically spendable is a nice property to have, if you want to design something new.