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

It is harmful. A large multisig, done with OP_CHECKMULTISIG is harmful, because it has at least O(n^2) complexity (it can be bigger, if you have a lot of multisig transactions, connected with each other). To notice that, you can check, how many transaction hashes are computed, how many times is FindAndDelete() called, and how complex it is, to verify 15-of-15 P2SH multisig, or 20-of-20 bare multisig. If you misuse it, then it is possible to create a block, which will take at least a few minutes to verify. And guess what: we have 10 minutes per block! Guess, what will happen, if blocks will be spammed with multisig, and it would take 3 or 5 minutes to verify a single block!

Because if you ever wondered, why sigops limit is there in the first place, then the answer is simple: it prevents that particular attack, related to OP_CHECKMULTISIG.

Edit: https://en.bitcoin.it/wiki/Common_Vulnerabilities_and_Exposures#CVE-2013-2292

It is not the only solution. For example: if non-interactive transaction joining would be available on the protocol level, then the same number of transactions per second, could be written on-chain, with smaller amount of bytes. Which means, that if you can batch things, then you can have quite small block size, but confirming a lot of transactions. And the same is true, when it comes to data compression: if you compress for example historical address reuse, then it makes Initial Blockchain Download faster.

Because it is written in a download-and-verify trustless style. If you just select your bitcoin directory, and do copy-paste on your hard drive, it could take minutes, maybe hours, depending on your hardware. However, if you want to get that data from another peer, over the Internet, and make it trustless, and also assume, that some node may be malicious, and serve some invalid data, then guess what: you have to verify it! And that verification is the main bottleneck.

And of course, you can skip verification, if you really want. Many altcoin users shared their bitcoin directory, with already created and verified database. But guess what: in this way, you don't verify, you just trust. And the whole problem of verification time is not related to existing users and nodes, which already know, that the history is correct. It is more related to new nodes, which has to verify everything for the first time, and to some pruned nodes, which may need to re-download and re-verify the chain, if their pruned node will crash for whatever reason (or if there would be any chain reorganization, which is deeper than their pruning point).

Because then, you may waste a lot of resources, if you encounter some malicious node. For example: some ASIC user may want to test "the longest chain rule". It is easy to produce one million blocks with minimal difficulty. Then, if you don't verify anything, you will download a lot of gigabytes, only to notice, that since block 123,456, something is wrong, and there is some heavier chain, which is shorter, but contains a bigger chainwork. And it is not only about that, there are many attacks, where something could go wrong, and where you may end up downloading a lot of data from some peer, to conclude in the end, that the whole chain is invalid since block number N. Another example: sigops limit per block. Even some mining pools sometimes get it wrong: https://bitcointalksearch.org/topic/error-connectblock-too-many-sigops-invalidchainfound-invalid-block-5447129

yes but older hardware and older cpus are becoming deprecated by the linux kernel developers.

Linux Kernel May Drop i486 Support as Torvalds Backs Pentium Plan
https://www.tomshardware.com/news/linux-removes-486-cpu-support

Linux Kernel Nixes IDE Support In the Latest 5.14 Release Candidate
https://www.tomshardware.com/news/linux-kernel-nixes-ide-support-in-the-latest-514-release-candidate



The solution to your problem is to get a more poweful CPU and alot more RAM. To be quite honest, that's the only solution to your problem. And maybe a faster SSD. Is your SSD NVME or is it SATA? Maybe you need to get an NVME one.

I'm still baffled how, and i know this might sound a bit off topic, but how downloading the entire blockchain is apparently some type of CPU/RAM/SSD-HDD intensive process. That makes no sense to me. I can download things and it's not CPU or RAM intensive at all. Maybe bitcoin has a problem where it is trying to do too many things at once. Why not break it into steps:

1) download all the raw data
2) once download is complete, then process the data

to me that seems more reasonable than trying to do both things at once.


You seem to have suggested previously that ordinals is "good" because it stops people from using something like bitcoin stamps instead. i disagree that something can be judged as good or preferred just because it stops or offers an alternative to something which is a built in feature of bitcoin (multisig) being used in way that you think might be harmful. we don't even know that people would adopt that alternative if "ordinals" didn't even exist.

So what if the Ordinals' data can be pruned? Full nodes must keep track of everything, otherwise new nodes can't sync up.

Your opinion on whether it's worth to pay for an Ordinal is irrelevant in a decentralized network, no offense. The market decides if it's worth it or not.

This can't happen. If all nodes prune that data, there can never be any new nodes. The "actual users" side is definitely losing more than it is gaining.

In which Universe have I argued the opposite?

That makes sense, although i disagree what counts as "important" transaction.


It's probably true since malware needs to replace both real address and signature. Although dedicated scammer wouldn't have hard time adapt to change.


It very well could be? It's a fact (at least if you use Bitcoin Core). I'd recommend you to check https://statoshi.info/d/000000009/unspent-transaction-output-set?orgId=1&refresh=5s&from=now-5y&to=now which shows some stats about UTXO.


Not very good comparison though. You still can use Linux on old or low end machine, assuming you choose light DE (such as XFCE) or distro specially created for such machine.

This:
With just 8 GB RAM, Bitcoin Core is pounding my SSD at maximum capacity for hours during IBD. Even though it's just a one-time thing, it's only getting worse.

because they don't care about data permanence. these people are uninformed, and don't understand the difference between something like bitcoin stamps which stores data directly into the utxo set which can never be pruned vs ordinals data which can be pruned.


yes, but at the same time, it prioritizes "important" transactions. i don't really consider a transaction important if one of the parties is not even willing to do anything. that could cut down on spam transactions like address poisoning. i'm assuming you've heard about that scam. and other types of dust spam which no one wants.

about the utxo set being 11GB now. it very well could be. i had just googled what its size is and say 4GB. but the situation reminds me of how Linux used to be for low end machines that had limited resources like a slow cpu, small hdd, low amount of ram. if you want to really run linux now, you need a much more modern machine. the same thing is happening with bitcoin as far as being able to run a node. linux is not for geeks with no money who cobbled together some old hardware. those days are long gone. off my soapbox about that now!


what i think about "redistributing wealth" has nothing to do with what i was saying about solving the UTXO set bloat issue. or my remarks about what i thought was causing it. sorry you think i'm trying to redistribute your bitcoin to other people because i'm not.

hmmm I've never heard anybody say that before.

so what's the big deal then about the UTXO set getting too bloated? you're running a full node and you don't have any problem with the UTXO set so maybe there isn't one. and people are being irrational in thinking that that if monkeys didn't live in ordinals but swung over to bitcoin stamps it would destroy bitcoin...

4GB? I think you saw very old stats. On my device, it's about 11.5GB for mainnet and about 9GB for testnet. And while i agree people ideally should upgrade their computer periodically, i think only Bitcoin enthusiast would upgrade their computer with primary goal to run Bitcoin full node smoothly. And as reminder, renting VPS with big RAM isn't exactly cheap.


I get your point, although it makes sending Bitcoin become less convenient.

I don't really mind UTXOs, as long as they don't need to be in memory. Who cares about a few GB more storage on disk, as long as it doesn't need to be in RAM or read from disk all the time? I just checked my chainstate:
1 .ldb file has date May 6.
1 .ldb file has date May 7.
5924 .ldb files have date May 8.
21 .ldb files have date May 9.
There are no newer files.

I closed Bitcoin Core. Now:
1 .ldb file has date May 6.
1 .ldb file has date May 7.
5923 .ldb files have date May 8.
20 .ldb files have date May 9.
0 .ldb files have date May 10.
11 .ldb files have date May 11.
I use dbcache=1024

I guess it's less inefficient than I thought. If "inactive" UTXOs are just left untouched by Bitcoin Core, fine by me.

Why do you think they won't be willing to put it into the UTXO set? What's the reasoning here? Aren't they evidently willing to throw millions in the bucket for their crap?

The situation is really simple, yet we've made it unnecessarily complicated. Users can inject arbitrary data whether you like it or not. They can do it either by inflating the UTXO set, or by merely touching it. At the moment, these users don't harm the set by creating an output for every 256-bit chunk their Ordinals weigh, which could be their last resort, again. If you invalidate this "less harmful solution", or make it non-standard, you're pushing them to do the most harmful for the rest of us solution.

What's so difficult to understand?

See, this is how it starts.  First someone proposes "fixing" spam and before long they're talking about "fixing" immutability itself.

I don't get all the subterfuge.  Why aren't people honest about their intentions?  Just get straight to the point and admit that you want a centrally planned economy where you can redistribute wealth as you see fit. 

Not only are "spam" UTXOs a problematic issue with bitcoin but you also have these too:

1) UTXOs that cannot be spent because they are "burn addresses"
2) UTXOs that are no longer spendable because the owner lost their private key (the guy whos hard drive is in a landfill)
3) UTXOs that are very old and it is not clear if they will ever be spent or not (satoshi's bitcoin)

It's inefficient to have to store all of these type of things. FOREVER. For who? No one is ever going to use them. At least as far as #1 and #2 are concerned.


whatever is going on there is definitely not what satoshi intended in his whitepaper, in my opinion!