(Ordinals) BRC-20 needs to be removed

[vjudeu]

except grudgingly with OP_RETURN since it puts a strict limit of 80 bytes on it

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.

i want a blockchain where every single transaction is treated the same exact way and no one knows what its purpose is

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.

therefore, they should all be in the UTXO set.

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

i'm not sure why people complain so much about the size of the UTXO set

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.

the blockchain is way bigger than the UTXO set so if they can store that then they can surely store the UTXO set too

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.

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

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

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.

i wouldn't want a transaction of mine to not be in the UTXO set

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?

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

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.

Because I want my transaction always being stored by everyone.

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

A single transaction per block. that would be a Denial of Service attack.

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

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.

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.

[garlonicon]

i want a blockchain where every single transaction is treated the same exact way and no one knows what its purpose is

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.

[larry_vw_1955]

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?

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.

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

it will definitely halt all you have to do is iterate through all possible private keys to see if the particular public key matches to one of them.

but there's a simpler way than doing that. just don't accept transactions where the receiver key has not been verified. you could do that by adding a 5th field like so:

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

i don't think it is asking too much for the receiving party to be required to participate in a transaction of which they are the beneficiary. i'm not sure it's really necessary to do this but you could. and that would enforce more structure onto transactions. and it wouldn't hurt anybody. but it would slightly increase each transaction size. but that's all.

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

if the system is well designed, it shouldn't be a burden to anyone to store everyone's transactions. but you can't be having people storing pictures of their girlfriend and things like that.

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.

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

[ABCbits]

i'm not sure why people complain so much about the size of the UTXO set

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.

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.

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.

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

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.

[larry_vw_1955]

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.

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

You're expecting receiver signature?

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?

[pooya87]

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

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.

[LoyceV]

the problem is the artificial growth that is happening due to spam.

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.

[larry_vw_1955]

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.

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.

What really worries me now is that there are barely any normal real Bitcoin transactions left. Mempool Goggles (https://mempool.space/) 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 (https://mempool.space/tx/708c4f6a91cd461c81966c956121f3c9dae135b6bd68be74b681a8608c964b4d): 3 dust inputs plus one normal input > 5 dust outputs plus 2 normal outputs. This is not the "adoption" I hoped for.

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

[DooMAD]

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)

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. 

[BlackHatCoiner]

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

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?

[LoyceV]

First someone proposes "fixing" spam and before long they're talking about "fixing" immutability itself.

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.

[ABCbits]

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.

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

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.

You're expecting receiver signature?

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?

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

[larry_vw_1955]

Why do you think they won't be willing to put it into the UTXO set?

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.

What's the reasoning here? Aren't they evidently willing to throw millions in the bucket for their crap?

they're not getting what they're paying for though in my opinion. all the people running nodes and things are just laughing saying "i'll just prune your data". do you think that's really fair?  

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?

whats so difficult for you to understand that a multi-signature bitcoin transaction is none of your business unless you are a party to it. why do you need to worry what people are using multi-sig for? bitcoin stamps uses multi-sig.

so is that where we are at. bitcoin has features that some people should be allowed to use but not others. i get it. thanks for letting me know.  

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

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!

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. 

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.

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?

hmmm I've never heard anybody say that before.

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

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

[LoyceV]

so what's the big deal then about the UTXO set getting too bloated?

This:

During the last hours, sync speed was limited by my SSD speed (and the lack of RAM).

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.

[ABCbits]

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

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 makes sense, although i disagree what counts as "important" transaction.

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.

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.

about the utxo set being 11GB now. it very well could be. i had just googled what its size is and say 4GB.

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.

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!

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.

[BlackHatCoiner]

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.

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

they're not getting what they're paying for though in my opinion.

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.

all the people running nodes and things are just laughing saying "i'll just prune your data". do you think that's really fair? 

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.

whats so difficult for you to understand that a multi-signature bitcoin transaction is none of your business unless you are a party to it.

In which Universe have I argued the opposite?

[larry_vw_1955]

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.

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

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.

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.

In which Universe have I argued the opposite?

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.

[vjudeu]

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.

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.

but how downloading the entire blockchain is apparently some type of CPU/RAM/SSD-HDD intensive process

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

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.

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://bitcointalk.org/index.php?topic=5447129.0

[garlonicon]

a built in feature of bitcoin (multisig) being used in way that you think might be harmful

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

[LoyceV]

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

You're grasping at straws. Try to find a new Windows version that runs on 35 year old hardware.

so what's the big deal then about the UTXO set getting too bloated?

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.

(restored quote to include context)
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.

You're missing the point. You asked why a large UTXO set is a problem, and your solution is to buy more RAM? So in the same post in which you argued Linux is removing support for systems with 4 MB RAM, you argue 8 GB isn't enough. I'd argue adding more RAM doesn't scale well: what if there are 100 times more UTXOs? Add 2 TB RAM to run Bitcoin Core?

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.

Downloading isn't resource intensive, verifying all data is what gets you.

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.

It won't be faster, and it won't reduce system load. Besides, if you downloaded one wrong bit in a block, you'll have to start over.