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

What really worries me now is that there are barely any normal real Bitcoin transactions left. Mempool Goggles shows more than 90% of the blocks are filled with "data" (AKA spam). That leaves at most a few dozen "normal" Bitcoin transactions per minute. Bitcoin's transaction rate has always been limited around 7 tps, but currently real transactions barely make it to half a transaction per second. And some of the non-data Bitcoin transactions are like this: 3 dust inputs plus one normal input > 5 dust outputs plus 2 normal outputs. This is not the "adoption" I hoped for.

NATURAL growth is expected and it is fine, the problem is the artificial growth that is happening due to spam. It's one thing to say UTXOs are people's funds locked up, it's another thing to say a considerable percentage of the UTXO set is the outputs of prolonged spam attacks.

the utxo set is only about 4GB apparently. Mozilla Firefox can eat up 1GB of RAM by itself maybe even more! So I mean, at some point people just have to bite the bullet and upgrade their computer. Because a new computer should be having 32GB of RAM at this point. If not you're getting the wrong computer! Also it might be time to upgrade from a hdd to an ssd because i heard they are alot faster. So maybe you could just store the utxo set on the ssd and not in ram.

yes unfortunately, bitcoin like everything else grows with time and will demand more from the people who want to participate in it (run a full node)...


I was just saying that's a possible way to make sure that you don't have non-spendable transactions where the private key to the receiver's public key is not known. aka burn addresses. there's no point for utxos like that to be in the utxo set, is there?

It's also worth to mention higher total UTXO also require either more RAM or slower verification time (since you need to read the data from disk). It's especially slow during IBD process if you don't have enough RAM to store all UTXO on it.


You're expecting receiver signature? I think that require the receiver either,
1. Online and manually sending signature to sender.
2. Use service or run their own server which automatically sign and then send signature to sender.

i don't want script because why would you want to over complicate a system that only had one transaction type?

sender key: receiver key: amount: sender signature

the signature has to be valid and not contain any monkeys.


every transaction needs a sender and a receiver. they can be the same though. but they have to exist.

sender key: receiver key: amount: sender signature: receiver signature

Including the coinbase transaction? Because then, you would have miner-only network, where each user would have to also be a miner, and where all transactions could generate new coins, based on their Proof of Work.

This limit is not so strict. If you make non-standard transaction, you can exceed those 80 bytes. More than that: there are node configuration options, which allows you to change that specific behaviour, so you don't even have to recompile the code to change it in your node.

But you know, that by following this assumption, you would have no Script in your system, and everything would work similar to P2PK, which would be the only address type?

Or rather: the basic system would look like that, and other use cases would require soft-forks, designed in a similar way to Segwit, but instead of being wrapped in a "stack pushes, evaluated into true", would be committed into signatures and public keys instead, like in Taproot.

If they are spendable, then it is not a big deal. Worse, if they are non-spendable, but you cannot prove it. And in general, if you have a full Script support, then you cannot write a program, which will evaluate it, and prove it in finite time, it is called the halting problem: https://en.wikipedia.org/wiki/Halting_problem

Because it is the main thing, which decides about the size, which is required for running pruned node. Then, you have only the last N blocks, but also the full UTXO set. Which also means, that if such set is smaller, then it is easier to manage it, and then more people can afford running a full node with enabled pruning.

Another story is Initial Blockchain Download, where if you want to simplify it, then you can use models like "assume UTXO", which is based on the UTXO set. And the smaller it is, the faster that kind of synchronization can be performed.

Many people switched from full archival nodes into pruned nodes, when the chain became bigger. If the UTXO set will be flooded, then those clients will switch into some even weaker model. And that is something you don't want, because after more and more simplifications, you can reach a moment, when nobody can access the full history anymore. And if there will be more and more spam, then we will enter those times sooner, than we should.

Of course, many optimizations are possible. But first, you will see some crashing nodes, and frustrated users, and then some fixes, and changes in the codebase. Writing software is hard, and there are many things, which are open, and not covered by any consensus rules (for example: the total size of the UTXO set is currently unlimited). However, in our universe, everything is finite, just by the resources of those, who run their nodes. And if you abuse those resources, then you may end up in a situation, where there would be no volunteers, willing to provide their services for free, and you will end up with a network, which consists of only weak clients, unable to access the full history anymore.

But the problem is, that we have many software problems. And sometimes, there are more issues than people, willing to fix them. And then, guess what you have: the status quo. The "nothing will be changed" assumption, the crashing clients, and nobody, willing to clean up that mess. Just like with Ordinals: there were not enough people, willing to fix the problem, and it became worse over time, and we reached "status quo" in that matter.

So, to sum up: you don't want to get "status quo", when it comes to the UTXO flood. Because then, you may enter the time, when you need coding skills to use the network properly, just like it is the case with some altcoins, when their creators lack needed skills and competence to maintain it.

Even if it would be cheaper, and the coin flow would match exactly, what you broadcasted to the network? And even if it would be possible to prove, that your transaction was present in the chain, and see the exact location?

Not really. If you follow the whole idea of OP_RETURN, before it became, what it is now, then you will understand, that it is directly related to the "return" keyword in C++. And that keyword alone, when used in the real C++ code, has a lot of use cases. If you have a function with many "return something;", then it is perfectly valid, and this is what Satoshi wanted to achieve. The main problem was "OP_TRUE OP_RETURN", but there are other ways to fix it, than making a given output invalid.

Also note, that there is a reason, why Taproot has OP_SUCCESS opcodes, but not "OP_TRUE OP_RETURN" instead, even if the true meaning of "return" keyword is just that. Not to mention, what can happen, if you combine OP_CODESEPARATOR with properly implemented OP_RETURN, and also in Taproot, you cannot have "OP_IF OP_SUCCESS OP_ENDIF", which could be sometimes useful, but instead, it is always spendable, because of scanning for OP_SUCCESS occurrences, and making the script immediately valid, even if that opcode can be reached only inside some condition.

On the other hand: do you want to always store everyone else's transactions? Because if not, then we are going back to the free rider problem: https://en.wikipedia.org/wiki/Free-rider_problem

Or, in other words: a forced soft-fork: https://petertodd.org/2016/forced-soft-forks#radical-changes

Why? Each miner can simply decide to include only a coinbase transaction, and nothing else. In that case, other users cannot get their transactions confirmed, if the attacker has 51%, no matter, how big is that block, or what it contains, if it is fully controlled by the attacker, just like in signet.

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. 

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.


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.


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.  



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.

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!

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.

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

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

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


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 other choice is letting total UTXO explode, which leads to higher RAM requirement or faster disk speed to run full node.

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

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

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.

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.


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


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

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