(Ordinals) BRC-20 needs to be removed

[ABCbits]

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.

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.

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

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

[Wind_FURY]

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.

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.

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.

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

[pooya87]

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.

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.

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.

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.

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

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.

[larry_vw_1955]

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.

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.

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

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.

[LoyceV]

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.

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.

[Wind_FURY]

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.

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.

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

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.

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?

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.

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.

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

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.

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

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.

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.

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?

[graphite]

Are ordinals just an attempt to increase fees to secure the network? Hard to see any other reason for why they were added.

[LoyceV]

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?

In this case: yes! I'm pretty sure it's just one guy creating the massive spam, and selling it to gullible people with FOMO. If I'm right, none of the "buyers" even use Bitcoin. It's like saying someone who pays a spammer to send 10 million emails "uses email".

[ABCbits]

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.

Yes, through OP_RETURN, fake address and other means. If you also interested with the historical usage, check https://www.righto.com/2014/02/ascii-bernanke-wikileaks-photographs.html.

Plus have there been proposals from the Core Developers?

Have you forget these PR?
https://github.com/bitcoin/bitcoin/pull/29769
https://github.com/bitcoin/bitcoin/pull/28408

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?

Whether they're real Bitcoin user or not, it's clear their transaction isn't created with goal of sending Bitcoin to someone else.

[Synchronice]

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?

What is a Bitcoin? Bitcoin is a purely peer-to-peer version of electronic cash that allows online payments to be sent directly from one party to another without going through a financial institution. This is the number one rule of Bitcoin. Now tell me, where do we see P2P version of electronic cash in Bitcoin Ordinals? They abuse Bitcoin and use it to earn money from made up thing, earn money from pixelated dumb ape images on Bitcoin Blockchain network. If Bitcoin Ordinals creators Bitcoin for purely p2p version of electronic cash payments, then they are welcome. What they do right now, is definitely an abuse of Bitcoin, a shitshow to scam people and make money from pixelated dumb ape images.

[pooya87]

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

A LONG time ago when the attack was starting, I said that the Ordinals Attack is something that needs to be "nipped in the bud" because it is effectively creating an incentive to regular newbies to participate in the attack. At that time simple standard rules would have slowed down this cancer

Now however, the scam market has grown and a lot of brainless gamblers are buying into this crap which makes it that much harder to stop.

Add to that the fact that devs didn't bother with thinking about a solution for the attack until way into the attack and the fact that even later nothing serious happened (as seen by the PRs @ABCbits shared that only address part of the problem) then we have ourselves a mess.

At this point I think the only remaining hope is for some third party creating a side-chain to create this garbage there and then pump it so that the gamblers actually bother going there. That way we can "transfer the cancer" out of Bitcoin and let it die there instead of it metastasizing here.
The "pumping" part is important...

[larry_vw_1955]

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.

you can't have it both ways. you either accept and support OP_RETURN and allowing people to store data on the blockchain or you say "No, I don't agree with OP_RETURN at all. Bitcoin was not meant for people to think of as any type of data storage." period the end. the logic that you are going to introduce a special op code to store data so they won't abuse UTXOs is ridiculous in my opinion. but that's what we did and that's where we are. the end results of that...

[ABCbits]

At this point I think the only remaining hope is for some third party creating a side-chain to create this garbage there and then pump it so that the gamblers actually bother going there. That way we can "transfer the cancer" out of Bitcoin and let it die there instead of it metastasizing here.
The "pumping" part is important...

In that case, we should encourage Blockstream to massively promote their Liquid network. After all, the feature is already exist.

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.

you can't have it both ways. you either accept and support OP_RETURN and allowing people to store data on the blockchain or you say "No, I don't agree with OP_RETURN at all. Bitcoin was not meant for people to think of as any type of data storage." period the end.

Why not? People opinion isn't limited to yes or no. That's why Likert scale (strongly disagree to strongly agree or 1 to 5) exist.

the logic that you are going to introduce a special op code to store data so they won't abuse UTXOs is ridiculous in my opinion. but that's what we did and that's where we are. the end results of that...

The other choice is letting total UTXO explode, which leads to higher RAM requirement or faster disk speed to run full node.

[LoyceV]

To me, this was acceptable until it reached thousands of OP_RETURN transactions per block.

you can't have it both ways. you either accept and support OP_RETURN and allowing people to store data on the blockchain or you say "No, I don't agree with OP_RETURN at all. Bitcoin was not meant for people to think of as any type of data storage." period the end.

Why not? People opinion isn't limited to yes or no. That's why Likert scale (strongly disagree to strongly agree or 1 to 5) exist.

I'm with ABCbits on this. My percention changed once it was abused too much. There's a limit to what's acceptable. I used to be okay with online ads, until it overtook my entire screen and added sound. So I installed an adblocker and have blocked millions of ads since then.

[BlackHatCoiner]

the logic that you are going to introduce a special op code to store data so they won't abuse UTXOs is ridiculous in my opinion.

It is basic rationale. Action reaction. If you don't let them use Ordinals in their inefficient way, they'll probably find an even less efficient way to do it. Storing in the UTXO set is probably their last resort, but it can be done, either in a standard way (sending 546 sat dust), or in a non-standard way (sending 1 sat dust after agreeing with mining pools). You can't stop people from using Bitcoin as a cloud storage, you can only discourage them to an extent through transaction fees.

[vjudeu]

or in a non-standard way (sending 1 sat dust after agreeing with mining pools)

If you accept non-standard ways, then it is possible to use zero satoshis as a dust.

[DooMAD]

you can't have it both ways. you either accept and support OP_RETURN and allowing people to store data on the blockchain or you say "No, I don't agree with OP_RETURN at all. Bitcoin was not meant for people to think of as any type of data storage." period the end.

As long as we're clear that you also can't have it both ways.  

You either support a blockchain where users will initiate a witch hunt to stamp out any transactions they don't approve of (and either trust or hope that they never disapprove of the transactions you make).  As a consequence, you'll then be leaving the door wide open for governments and regulators to apply pressure to stamp out the transactions they don't approve of (and again hope that doesn't include your transactions).

-OR-, you can support Bitcoin as it stands, where no one is in a position to dictate what other users can or can't do with their transactions.

Know that if you pick the former and take action to enact it, you'll be splitting the current Bitcoin userbase.  I, for one, absolutely won't follow such a grotesque and 'nimby'-ist blockchain.  It's an absolute prerequisite for me that censorship is not a factor.  I simply won't accept it.  I hope that others here feel the same because they understand what a travesty the alternative would be.  Although, it honestly wouldn't surprise me if such users were dwindling in number, as forum users generally nowadays seem to be more ignorant and less appreciative of what we have and why it works this way.  But there should be enough of us who see sense to continue on our current path.

It's a matter of principles and I get the distinct impression ours don't align.  It looks like you have some obstacles to overcome in order to get what you want, because I'm certainly not giving up what I already have.  Censorship-resistant freedom.

[pooya87]

You either support a blockchain where users will initiate a witch hunt to stamp out any transactions they don't approve of (and either trust or hope that they never disapprove of the transactions you make).  As a consequence, you'll then be leaving the door wide open for governments and regulators to apply pressure to stamp out the transactions they don't approve of (and again hope that doesn't include your transactions).

You are comparing apples and oranges.

There is a clear distinction between transactions that abuse the protocol and treat bitcoin as a cloud storage, something that nobody approves of including the creator of Bitcoin, Satoshi Nakamoto.
With government trying to censor transactions that are transferring bitcoin from one person to another, which is what bitcoin is supposed to do as a payment network.

Not wanting the abuse and exploits doesn't mean you open the way for the second category!

[larry_vw_1955]

the logic that you are going to introduce a special op code to store data so they won't abuse UTXOs is ridiculous in my opinion.

It is basic rationale. Action reaction. If you don't let them use Ordinals in their inefficient way, they'll probably find an even less efficient way to do it. Storing in the UTXO set is probably their last resort, but it can be done, either in a standard way (sending 546 sat dust), or in a non-standard way (sending 1 sat dust after agreeing with mining pools). You can't stop people from using Bitcoin as a cloud storage, you can only discourage them to an extent through transaction fees.

i want them to make standard transactions so that they cannot be differentiated from any other ordinary transaction that is an actual transaction. so it needs to be in the utxo set. if they're not willing to put it into the utxo set then i'm not really a fan of them storing any type of data, except grudgingly with OP_RETURN since it puts a strict limit of 80 bytes on it.

As long as we're clear that you also can't have it both ways.  

You either support a blockchain where users will initiate a witch hunt to stamp out any transactions they don't approve of (and either trust or hope that they never disapprove of the transactions you make).  As a consequence, you'll then be leaving the door wide open for governments and regulators to apply pressure to stamp out the transactions they don't approve of (and again hope that doesn't include your transactions).

i want a blockchain where every single transaction is treated the same exact way and no one knows what its purpose is. and no one cares. therefore, they should all be in the UTXO set. and then I won't have any problem. i'm not sure why people complain so much about the size of the UTXO set. the blockchain is way bigger than the UTXO set so if they can store that then they can surely store the UTXO set too. if they don't have enough RAM then maybe bitcoin can be rewritten to take advantage of not needing to store the entire UTXO set in RAM all at once. but that's not a reason to complain about the UTXO set size, if there's a technological problem or algorithmic issue about how the UTXO set is stored, processed and used by software then it's a software problem.

-OR-, you can support Bitcoin as it stands, where no one is in a position to dictate what other users can or can't do with their transactions.

i wouldn't want a transaction of mine to not be in the UTXO set. so I never really thought very much of OP-RETURN but I grudgingly accepted it. but it really doesn't have a purpose other than to try and persuade people to not use the UTXO set for some of their transactions. I don't like someone telling me what type of transaction to do. Because I want my transaction always being stored by everyone. So it needs to be in the UTXO set. And in my opinion all transactions need to be in the UTXO set. There shouldn't be any special transaction type that says "i'm just for storing data so you don't need to keep me in the UTXO set and if you want to prune me, go right ahead." I'm not going to let someone do that to my transaction.  

Know that if you pick the former and take action to enact it, you'll be splitting the current Bitcoin userbase.  I, for one, absolutely won't follow such a grotesque and 'nimby'-ist blockchain.  It's an absolute prerequisite for me that censorship is not a factor.  I simply won't accept it.  I hope that others here feel the same because they understand what a travesty the alternative would be.  Although, it honestly wouldn't surprise me if such users were dwindling in number, as forum users generally nowadays seem to be more ignorant and less appreciative of what we have and why it works this way.  But there should be enough of us who see sense to continue on our current path.

It's a matter of principles and I get the distinct impression ours don't align.  It looks like you have some obstacles to overcome in order to get what you want, because I'm certainly not giving up what I already have.  Censorship-resistant freedom.

if some people wanted to use OP_RETURN out of respect for the UTXO set then that was always their perogative. Use it as much as you want! But don't ask me to do it. I can do whatever I want and I don't want someone telling me to use OP_RETURN so that my transactions are not kept by all miners. I'm not going to volunteer to have my transaction data pruned by people who only care about making a buck...but I don't think you and me are on opposite sides of the fence when it comes to this issue. It's just that maybe we don't understand how the other one feels about the background of ordinals and how they came to be and under what circumstances that came to be allowed. I still don't understand if they meant for people to be able to hog up an entire block with a single transaction OR NOT. If that's what they meant then they should have said so. Because obviously some people haven't gotten that memo.

Imagine some rich guy like Bill Gates decided to f*** with the blockchain. He could just fill up all the blocks with a single transaction for days, weeks, months maybe even years. A single transaction per block. that would be a Denial of Service attack. But if his transaction sizes were limited in size such that they could only take up 80 bytes each, it would be alot harder for him to do. Either way it would cost him though but imagine the uproar if the former occurred.

[DooMAD]

You either support a blockchain where users will initiate a witch hunt to stamp out any transactions they don't approve of (and either trust or hope that they never disapprove of the transactions you make).  As a consequence, you'll then be leaving the door wide open for governments and regulators to apply pressure to stamp out the transactions they don't approve of (and again hope that doesn't include your transactions).

You are comparing apples and oranges.

There is a clear distinction between transactions that abuse the protocol and treat bitcoin as a cloud storage, something that nobody approves of including the creator of Bitcoin, Satoshi Nakamoto.
With government trying to censor transactions that are transferring bitcoin from one person to another, which is what bitcoin is supposed to do as a payment network.

Not wanting the abuse and exploits doesn't mean you open the way for the second category!

I sincerely hope the distinction between apples and oranges brings you comfort when all fruit is banned.   

If you can appeal to a group of developers and successfully convince them to stop "apples", then I guarantee you governments will start looking for ways to convince developers to stop most of your goddamn five-a-day. 

Don't set stupid precedents.