Topic: (Ordinals) BRC-20 needs to be removed (Read 6235 times)

OK, then what do the "we" propose do to effectively get rid of the "Ordinals Attack"?

Plus have there been proposals from the Core Developers?


But currently, does that basic assumption actually hold true for everyone?


A person who uses Bitcoin in a way that you don't approve of, but paid the fees for block space, and followed the consensus rules is not a real Bitcoin user?

To me, this was acceptable until it reached thousands of OP_RETURN transactions per block. See Mempool Goggles. The larger spam transactions are now replaced by many more small transactions. It's still spam and takes up block space that could have been used by real Bitcoin users.

yeah they probably could but using OP_RETURN. limited to 80 bytes. so people can't go crazy. or it will cost them more than its worth to them. a self regulating mechanism.



thats a good point. but if we make the basic assumption that bitcoin was meant to do financial transactions and not to store peoples' private data then we is everybody.

That's true but they are still exploiting the protocol in the same manner regardless of what size they occupy (the same OP_FALSE OP_IF exploit) to inject an arbitrary size data into the chain.

There is an accepted method of storing arbitrary data in transactions through OP_RETURN that is limited to 80 bytes and is also easily pruned from the UTXO set since they are provably unspendable. Other methods are not acceptable and are damaging like creating an unspendable output that can not be purged from the UTXO set so it remains there forever.

The same "we" that has been deciding what can or can not be done up to the Ordinals Attack!
For example the same "we" that didn't allow you to inject an arbitrary data as that dummy item that is popped from the stack in the OP_CHECKMULTISIG(VERIFY) op codes.

I'm genuinely asking to learn. - But couldn't developers already store arbitrary data within the blocks if they wanted to before Segwit? I remember there was a marriage certificate "in the blockchain"  and other arbitrary data.


It might be a very dangerous path because, who is "we", and does "we" speak for the whole community?

But on long term, witness version on Bech32m address format makes it's easier to deploy new feature or technology. Legacy address doesn't offer such thing, where you're forced to "wrap stuff" inside P2SH address which is less simple than using Bech32m. I also forget to mention Taproot upgrade also bring aggregated signature feature which also reduce TX size.


I also wonder whether it could be exploited as new form of DoS attack to SPV client and full node.

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

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.

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.

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.

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://bitcointalksearch.org/topic/the-smallest-valid-signature-5373858
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).

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.

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.

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.

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.


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

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.

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

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.


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

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.

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.

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


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.

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.

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.

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


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

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



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 can always fix something especially if you're the one that caused it...


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.

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.

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.

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.

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?  

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

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?