Topic: (Ordinals) BRC-20 needs to be removed - page 16. (Read 7771 times)

OK, there's something to learn here. I have questions. Please be patient with me.

In the context that there's the Ordinals Chain merge mined with the Bitcoin blockchain, doesn't the miner earn rewards from both chains, and therefore has the choice of which coin to sell to pay for electricity bills/other expenses?

Does merged mining add extra work for miners to process more data and therefore is like a block size increase?


If there was no incentive to mine the Ordinal Chain, then why try to find blocks there at all? Plus it would be better for the miners if Ordinals inscriptions stay in the Bitcoin blockchain/keep fees high.

Whether you like or not coming up with fancy names for an attack like calling it Decentralized Finance, Ordinals, etc. doesn't make them real or valuable for that matter. None of it is part of the protocol, they are abusing the bitcoin blockchain as cloud storage only and the real deal happens on a centralized platform where a scam such as BRC-20 interprets the arbitrary data in the blockchain for you.

If anybody thinks something like that which is clearly centralized is worth something they don't even belong in the Bitcoin world!

The only guarantee is to upgrade the infrastructure to handle the load . If these companies are selling a service and each click could be a potential client it would be idiotic to stand and look their website going down .


I'm glad that you took an example with the only company that your argument could stand but it is flawed . The problem is that in facebook you are the product they sell . It's easy , when you're not paying for a product you are the product .
How many clients of facebook ( advertisers ) have you heard getting banned for using their service ?  
Try another argument with netflix or banks , or whatever network that users who pay for using a service getting excluded or targeted for using it . Dude , grow up .

You fail to understand what electronic cash means , that's why you insist it's an attack . In fact you have to understand what cash is : https://www.investopedia.com/terms/c/cash.asp .
Cash can be anything that can be turned into physical cash .  So , there has to be a market for it , and preferably it should be widely accepted . Guess what , ordinals , brc-20's and in the future defi's are accepted as a form of cash , so the payment system works as it should . Either you like it or not .

I'm saying all these things because i see people complaining about things bitcoin has face in the past ( periods of insane fees ) . And for that you blame ordinals etc . There are no spammers as long as they pay fees , especially higher than your "normal transactions" . Try to think and blame those that are really responsible for that , and that's a part of core . No one else .

This is also true. But if we give it more tools, it gets worse.

But other scenarios can be constructed, how Ordinals can be used to try to harm Bitcoin. Now, that would be pure and mere speculation, which is not worth feeding into.
I just think that the first layer of the blockchain shouldn't be dealing with this type of content. I'm not against Ordinals, I just think they're operating in the wrong place.

As someone who knows a lot of people who are into Ordinals & constructed marketplaces for them, knows where the funding is coming from, and understands how crypto influencooring works, this is the correct take.


What you're describing is a miner centralization problem and it has been an existential threat since the birth of the first mining pool.

But I gave an example, large pools artificially increase block fees.

If the 3 or 4 largest pools on the market align, they can create Ordinals transactions with high fees, knowing that they will get the money from these fees back in the blocks they mine.

Another way is for large pools to create Ordinal transactions, at the same time as reducing their hash, following a difficulty adjustment on the network. The network becomes clogged, generating a greater number of pending transactions in the mempool, which will generate fee increases.

Of course, I'm not saying that this is what's happening. Because it will be difficult to prove, even if it is happening. But these are scenarios, which happen, could be considered an attack on the network, as they were trying to take advantage of a protocol for their own purposes, damaging this entire protocol.

I think the two cases are slightly different. In the example you posted, the comparator receives direct benefit from attacking that website, and the cost of the attack compared to the potential reward makes a lot of sense. Imagine you have 10k clients that you may lose today if they managed to access that company's website. Spending 100% of what those 10k clients make you in a year might still make economic sense to you, especially considering that the number of companies offering the same service in your country is probably not more than a few, whereas in BTC the case is different.

If you would call Ordinals an attack, then you need to have a reasonable explanation of what the attackers are willing to achieve from it. Is it BSV folks trying to raise fees so that people would move to their chain? But then—there are a few thousand other blockchains out there. What if they move to ETH or something else? So, this has to be a coordinated attack by a few dozen altcoins, which also doesn't make a lot of sense.

You may call it "abuse" or "against Bitcoin best practice"; that would make more sense. I don't even think calling it "spam" makes a lot of sense. Spamming on bitcoin is rather expensive and useful. I wouldn't even call it "cloud storage" because there exists cheaper, faster, and more efficient cloud storage to store those funny pictures.

The way I see it is that someone or a group of people managed to exploit an opportunity to make money by creating value out of thin air. And now, greedy people want to make money by investing in these stupid projects. These people spend millions of dollars hoping to make more millions of dollars in profit—not to hurt bitcoin or make things worse for other people. They just want to sell their bags to the next person at a higher valuation. This is how I view the current situation.

It is you who is comparing apples and oranges. In your both examples you used legitimate use cases of the service (buying stuff, users of Facebook, etc.) but when it comes to Bitcoin you are counting the attackers as legitimate use case!

Every system is made for a purpose and when you use it for something else or break the rules of that system, your actions would be counted as abuse. For example if you use your Facebook account to post some random stuff every 10 seconds, your account will be banned and nuked in matter of minutes.
It's the same in Bitcoin, when you try to exploit the protocol and turn Bitcoin into cloud storage, that's an abuse and it should be banned. The only difference between Bitcoin and a centralized service is that Bitcoin is decentralized so such decision makings are extremely slow.

As I've said a million times this is not about fees nor about what is being stored in chain. This is all about the fact that Bitcoin is being used as cloud storage whereas it is supposed to be a payment system. And it is ONLY possible through an EXPLOIT.

That's just outright wrong.
Ignoring the fact that block size hasn't been 1MB for years, for some reason you said all these stuff in previous pages to get here (I wonder what reason ) to say that "people using bitcoin as their cloud storage is OK and we should increase the block size so they can have access to a bigger "cloud space" for their arbitrary data!"

1. It is not that surprising, if you remember, how people argued about activation method for each soft-fork. It is still unclear, what exactly should be used, and with each soft-fork, there are the same problems. So, some people tried to code it in a way, where it would no longer be needed.

2. There were some posts on mailing list, which presented, how to achieve some features, by using long and complex scripts. By making it standard, it is now possible to test it in a standard way. But of course, it would be better, if that kind of testing would happen on any kind of testnet, and then would be standardized on mainnet.

3. Taproot was advertized as "self-upgradable". And some rules were relaxed, to switch features on and off at will. And it would be fine, as long as there would be less people smart enough, to misuse that. Which means, it was also some kind of test: "can we relax the rules, and use it to activate features in the future?". And Ordinals gave developers the answer: no, you cannot, it will be abused. So now, the decision is to put some limits back, and for example relay only standard transactions, even in test networks. And if Ordinals will keep abusing the chain, then next steps would be needed. Some of them are in progress, for example simplifications in Initial Blockchain Download, and I hope they would be enough, to discourage people, to store their data on-chain, if it will turn out, that more nodes will be bootstrapped in a new way, or will simply stop storing that data, and will focus instead on proofs, that they are just signed correctly, without knowing the content.

It really cannot be considered an attack, directly. But, this does not mean that it cannot be used as a tool for less-intentioned people to achieve their goals, which are less favorable for the network.

I'll give you an example, which happened yesterday. On prime-time TV, there was a report on the success of some companies in my country. When trying to access 2 or 3 websites of these companies, the websites were not prepared for so many visits and did not work correctly. I believe that the attention the report received led people to research the subject. But what guarantee is there that competing companies were not taking advantage of the moment to harm? Of course I'm just speculating, and I know that's not what happened. But, it could happen.

What I mean by this is that despite what is happening, it is not exactly an attack. It can be used to achieve certain purposes that are purely personal and not for the good of the network.

It has already been mentioned in other topics that if two or three large mining pools align themselves, they can achieve "ordinal" transactions with the sole purpose of increasing fees. Because in the end, they will always win, as the fees they are paying are for themselves.

Even if you are a techy guy you seem to fail to understand that you are comparing different things . If i'm a legit user of a website i won't try to send 1 million requests per second . That's a DDos attack , and it's purpose is to take down a website and have a gain by either ransoms or financial gain for a competitor .
If 1 million customers per second were trying to use that website to buy stuff that can't be consider an attack , that website would be more than happy to upgrade it's infrastructure and maximize it's profits . Imagine if facebook or netflix or banks were calling an attack the use of their networks by millions of users . Wouldn't you laugh at them ?
That's the problem here , currently there are thousands of customers that want to use btc's chain because they see an opportunity . Btc has ruled that the ones that pay higher fees are eligible to enter their transactions faster in a block that it's capacity should be limited to be as valuable as it gets . If the fee model is flawed by default ( at least from my point of view ) then that's not making those willing to pay the price attackers . It's like the example of 1 million customers per second i gave above , the logical would be to upgrade the infrastructure . But , guys like you , now understand how wrong were they sticking to 1 MB limit and scarce block space and just try to blame others . Your magical solution of L2 doesn't work , and you're looking for enemies . What would happen if tomorrow morning 100 million users decided to use btc for their everyday needs transacting in a way proper of how you think network should work ? Would you call them attackers too ? In your sense everyone that's not using LN is an attacker , that's the problem .


As i explained above you are the one that doesn't understand that this not an attack , it's a result of your premise that there should be a fee market and a limited scarce blocksize . You want a network that works on your needs , where full nodes decide how network will work . Well , from what i see , your full node that i guess is rejecting any "non-standard transaction" doesn't play any part on how blocks are building . Maybe it's time to understand how PoW consensus really works ?

That sounds like a paradox, like having your cake and eating it too. To activate something means changing the consensus rules and that requires a fork and that fork could apply the previous needed changes too

The reason was quite simple: developers were just tired of constant soft-forks, and they wanted to activate something "for the future", to avoid doing yet another soft-fork in the future. Is it a good reason? In my opinion not, because it is better to lift those limits with a new soft-fork, and not here and now, leaving the protocol wide open for making standard transactions in that way.

And, as you can recently noticed, in the latest version of Bitcoin Core 26.0, rules for regtest, testnet, and signet, were tightened to allow only standard transactions by default, and allow non-standard ones, only if the node operator explicitly change that.

Of course not. There is a reason, why transactions could be non-standard, but still valid. And this is the way, how the protocol can be expanded, and historically, it was done in that way.

This is debatable, and for that reason, there is no consensus for blocking the Ordinals entirely, by some kind of soft-fork. Because now, this is the only way, that would block them sufficiently. All those relay rules could suffice, when there was no software, that allowed Ordinals by default. But now, if you block them in some future version, then some people will simply not upgrade their clients. And now, you have the opposite: there is a minority, that tries to use downgraded clients, and unofficial ones, to block as much Ordinals, as they can. So, whatever will be done, some group will be disappointed.

And because the history is set in stone, then I think at this point, Ordinals should not be blocked. Instead, regular users should get some tools, to join their payments, to compete with Ordinals. Because it is easier to compress a lot of regular payments, than a lot of Ordinals (which could be compressed, if they would be turned into commitments, but this is not the goal of those users, as they explicitly want to always reveal everything on-chain, which means, they will sooner or later hit some barriers of data compression).

Yeah, I remember reading that topic around June time when gmaxwell posted.  It sounded very much as though devs had their reasons for doing this and I was prepared to give them the benefit of the doubt.  But the prevailing view now appears to be that those reasons weren't sufficient.  

If you're all quite certain that:

a) plugging this loophole isn't going to jeopardise future scaling efforts

and

b) doing so doesn't set a precedent for future attack vectors where governments or regulators can successfully pressure devs into imposing stricter limits in order to deny transactions *they* don't like (because that could swiftly kill the entire project if we're not careful),

then perhaps I could be convinced to get on board with what people are suggesting.  I still urge extreme caution, though.  Do not leave the door wide open to governments and regulators to enact pressure on devs purely because people seem unable to look beyond the tx fees.  To say that the implications are potentially significant if people are wrong about this feels like an understatement.  

Very interesting remark...

https://en.wikipedia.org/wiki/Colour_revolution

"The aim of the colour revolutions was to establish Western-style liberal democracy in those countries"

Because of some limits, which were lifted in the source code: https://bitcointalksearch.org/topic/whats-the-reason-for-not-being-strict-about-taproot-witness-program-size-5340900

It was possible, but it was more expensive than today, if you compare the space needed for that.

An alternative was to keep that limit, and raise it, when there will be a need to do so. Which means, it could be valid, but non-standard. Ordinals gave us so much trouble, because they are standard transactions (and for that reason, some people downgraded their nodes to reject all Taproot transactions, which halted some transitions into Taproot, which I planned before, because now those address types are rejected by some nodes).

Why do you think that raising the limit, and making it standard, when it will be needed, would be worse? It doesn't have to be there from the start. The same with OP_SUCCESS: now, if you want to make a contract, where some part of the TapScript is hidden, you have to require an additional proof, that it contains no OP_SUCCESS opcodes. Why OP_SUCCESS is not "non-standard"?

You don't need a crystal ball:

1. Block size limit: set to 1 MB. People reached that.
2. Witness limit: 4 MB. People reached that.
3. Transaction size limit: 100 kB (for witness: 400 kB). People reached that.
4. Sigops limit: 20,000 (for witness: 80,000). People reached that.

If you put "no limits" somewhere, then you can expect, that it will be abused, and then you can expect, that other limits will be the only reason, why your system will not explode.

You can leave some space for future rules. But why do you want to make it standard? Imagine, how better it would be, if Ordinals would be possible, but non-standard.

And if you think that lifting some rules is good, then why Segwit v2, v3, and so on, are non-standard, and were not lifted as well?

Forward compatibility is a good thing and it has always been part and parcel of Bitcoin protocol. But there is a difference between leaving the protocol open for future improvements (like what we have in witness version 2+ or OP codes like OP_SUCCESS, etc.) and leaving the protocol wide open to abuse (like the removal of consensus critical script size restriction from Taproot and not even making it a standard rule, etc.).

The exploit used in the Ordinals Attack is proof of that distinction.

Another point that cannot be forgotten is this aspect mentioned here:



It's one thing for criminals to use bitcoin as financial resources for their crimes. Another is to turn bitcoin itself into a crime tool.

Is this what we want for the Bitcoin blockchain?

The two points are linked.  Scaling generally requires extensible code.  If you make it too rigid, there's nowhere to grow.  If you want a dinky little bonsai tree, then sure, strict and disciplined is the way to go.  But we need something bigger than a bonsai tree, here.

If you propose painting ourselves into a corner, development-wise, but the devs have other ideas on that matter, guess what the outcome is going to be.

It's all building blocks.  Incremental steps to better things.  Try not to let this incident cloud the big picture.

There is a clear distinction here that I'm surprised you still don't want to see.

When a transaction is complying with consensus rules, standard rules and is behaving the way it is expected it is different from a transaction that is complying with consensus rules but not standard rules or the expected behavior.

In this case using the OP_RETURN output that is the expected way of inserting a teeny tiny arbitrary data into the bitcoin blockchain is a normal behavior.
On the other hand, using the oversight in witness verification to inject arbitrary size arbitrary data into the bitcoin blockchain is not normal or expected behavior hence it is an attack.

Edit: another major difference I forgot to mention is the fact that OP_RETURN outputs that are expected behavior can be pruned from UTXO database while the Ordinals spam which is an exploit keeps growing the UTXO database with dust outputs.

Possible? Not exactly. You see there is a difference between a valid transaction and a possible transaction (something that is easily relayed and mined).
It has always been "valid" to for example create an output that has a ~1 MB script containing arbitrary data but it was never possible to propagate that or get a miner to confirm it easily.

And they are all extremely limited and controlled to prevent abuse and attacks such as Ordinals.

Wrong. It has been like that since long before that

Feel free to prove me wrong.

Create a legacy transaction that injects a large arbitrary data inside one script by using the same script as the Ordinals Attack and get majority of full nodes to accept that tx in their mempool and all miners to include it in their candid block without you contacting them behind curtains and paying an extra fee through another channel to get it "manually" included.
Now do the same using witness version 1 and see for yourself whether it has always been possible or not!

Now you're changing the topic of discussing entirely.

You seem to have talked to franky so much so that you see everything about SegWit as a whole. The problem is not the soft-fork(s), nor is it SegWit itself. We aren't even discussing SegWit version 0 and 1 here.
The problem is the oversight that left some rules "loose" and enabled this attack vector which Ordinals is exploiting to perform their attack.
The solution was simple too, all it took was including the same exact rules that existed in Bitcoin into the witness verification rules to continue preventing this type of abusive attacks.