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

400MB per year is not the growth rate of Bitcoin's blockchain. A conservative estimate with approx. 1.5MB per block gives you a growth of roughly 2016 blocks per two weeks times 26 (for a year) times 1.5MB which equals 78,624MB per year, thus somewhere in the ballpark of 80GB growth per year at minimum.

I wonder where you got this 400MB figure from...

And those 240TB harddrives are still vaporware. Try an Initial Blockchain Download and node sync on a mechanical harddrive, it's a real fun^{not so much for the drive}. You can keep the irony if you detect it.



I'm not sure if I get it right, so excuse if I confuse consensus rules with something else. My standpoint is: it's a flaw in consensus rules to allow arbitrary sized witness data for an input in a transaction. There's likely no real need for this. It's an oversight which is now exploited. Can it be fixed easily without having weird or problematic side-effects. I don't know, that's a bit over my technical Bitcoin expertise.

I don't care who exploits it for whatever reason. The inscription shitheads and shit-token on Bitcoin blockchain morons exploit it and abuse the blockchain for storage of bullshit data. They don'c care about Bitcoin, period!

Sure, I'm exaggerating that it's bullshit of whatever flavor in my personal opinion. I don't expect anybody to agree on this with me. I'm free to have my own opinion and defend it.



Did you rather meant a blocksize war? I believe, yes, because I can't make up anything related to hash power with this topic.



We can debate the magnitude of "more expensive" fees, but that's not what I dislike in particular. More adoption and more transactions would also fill up the mempool and make it more expensive for you and me. That's the fee market and I have no valid point to complain about it if more adoption and "normal" transaction volume were the reason for  mempool clogs.

OP_RETURN data costs 4WU per byte. I wouldn't be happy if people start to use it excessivly but at least they'd have to pay a fair fee for it. And it's limited in size for a reason. Someone who wants to pay for it could use as many OP_RETURN outputs in his transaction(s) as this someone feels (s)he needs to. Would I like it? Certainly no. But I'm pretty much sure, it wouldn't be exploited in the extend we see with the inscription shit.

This superfluous data burdens every archival node and because of arbitrary size within the limits of max. blocksize any exploiter can cram in data that could become a problem with law. OP_RETURN is somewhat similar but you have the 80 bytes limit, even if used in multiples, you have a segmentation of problematic data like pictures or movies that collide with law.
I hope that such a forced segmentation wouldn't allow to say there's a whole problematic picture, intact in it's entirety in the blockchain. (Yes, I'm aware that such things were attempted in the past or maybe also in the presence. Stupid data abusers...)

Another issue is the bloating of the UTXO set by idiots who like to send dust or more to the genesis block's coinbase or rather the derived P2PKH address of the P2PK coinbase public key or other "Patoshi" blocks. But that's another, entirely different topic, though it shows to some extend that many people simply don't care to look at the whole picture and consequences for all of us.

Sorry for the rant but such sort of asocial ego-centric narrow-bubbled beings piss me off from time to time.

And then he also continues:

So, if other use cases would use some separate chains for that data, it could be fine. They could build some honest, valuable protocol out of that. But the problem is, that they just decided not to, and abuse the Bitcoin network instead.

And yet another sentence, from the same post:

Which means, that if you put all of those additional features on separate chains, then Bitcoin can still stay "easy for lots of users and small devices", and just take a role of "a notarization chain", providing Proof of Work to timestamp all other chains. But if you put "everything on Bitcoin" instead, then guess what: the current limits will take down existing payments. Because it is always a choice: confirm this payment, or this Ordinal. Which means, that if you allow using and abusing Bitcoin for everything else than the payment system, then it may stop being useful for payments, and lose its utility.

But from the viewpoint of the Ordinals/soon Runes users, if they have paid the fees and they're transactions are following the consensus rules, are they truly "exploiting" the system? It's not their fault it's there. They're merely using it because the system allows them to. Plus if it wasn't Casey Rodarmor, it would be another developer that would use this "hack/bug" and make something from it.


I believe that they should be careful. It might start a hash war again.


I don't like it too, it's making on-transactions a little more expensive to use for plebs like us. But what can we do? Literally ANYONE can use Bitcoin the way it allows us to if we pay the fees and follow the consensus rules.

That's a completely different topic.
Regardless of what Bitcoin's block capacity is, whether it is 1 byte or 1 terabyte, Bitcoin should continue staying as a payment system and not a cloud storage.

well, all i can say about that is bitcoin is going to be LEFT BEHIND if it clings to some type of small block sizes when consumer hard drives end up being 250 TB in size.

Hard drives aren't dead yet as Seagate demos new multi-layer 3D magnetic tech with potential for 240TB capacities
https://www.pcgamer.com/hardware/graphics-cards/hard-drives-arent-dead-yet-as-seagate-demos-new-multi-layer-3d-magnetic-tech-with-potential-for-240tb-capacities/

How would bitcoin continue to justify itself with only 400mb per year when people have 240TB hard drives? I just don't think it could. Adapt or die.

My examples were about "exploits" and fixing them more than being about data storage. But I agree that in Bitcoin we are slightly "flexible" when it comes to data storage (but not that much). For example we already have OP_RETURN that is used for data storage and is the standard way but it is a limited way that is acceptable.

Keep in mind that bottom is that Bitcoin is not a cloud storage, it is a payment system.

Guess what: on the mailing list, there was a topic about exactly this issue, and it was continued on Delving Bitcoin: https://delvingbitcoin.org/t/bug-spammers-get-bitcoin-blockspace-at-discounted-price-lets-fix-it/327

But I think it won't be fixed, because of that line of thinking:
And in general, I agree with that statement, but I also agree, that in the current model, not all bytes are counted properly. For example: there is an incentive to send coins into P2WPKH, but spend by key from P2TR. However, if you count the total on-chain footprint of P2WPKH, and compare it with P2TR with key-path spending, then P2WPKH is cheaper to send to, but it takes more on-chain bytes (and the cost is just moved to the recipient, so it is cheaper for the sender).

Also, if we would optimize things, and represent them on-chain differently, for example by saving raw public keys, and just using a single byte to indicate, that "this should use old DER encoding", and "this pubkey is wrapped in P2SH", then the whole chain could probably be much smaller, than it currently is. However, as compression is a no-fork, it can be always applied, so the only problem is standardizing the data, so then you can rely on other nodes, getting exactly the same results, and compressing data with the same algorithms. So, it is all about making "ZIP format for blockchain data": it is easier to send ZIP file, if you can unzip them in the same way on both computers. The same is true for historical blockchain data (and of course, some custom algorithm would be more effective, than just zipping it, because it could take into account, that you have to compress for example secp256k1 points, so it could efficiently use for example x-only-pubkeys, without having to build a weird auto-generated "dictionary" for that).

Well, if you want to simplify the current model, then standardisation is the first step in the right direction. And then, if you have for example some widely-deployed model, where you have a huge table of all public keys, which appeared on-chain, then you can generalize it, switch to a different model (utreexo), or view the scripting language from a different perspective: https://delvingbitcoin.org/t/btc-lisp-as-an-alternative-to-script/682

So, I guess that it could be restricted, if the network will be abused too much, but people are currently focused on things, which needs to be done, no matter if you want to restrict it, or not. Because simply "the status quo" is the default, so if you work on a change, that does not require touching consensus, then it can be easily merged. But if you work on some serious soft-fork instead, then you may end up with some working code, that simply won't be merged. And of course, writing some code, which is not consensus-critical is still needed, and is often required as a dependency to your soft-fork (you need to have standardized data compression, to compress and decompress the chain reliably, and to "undo your pruning" if needed).

There's the clear inequity under current rules that one byte of data in an OP_RETURN output is worth 4WU and one byte in witness data as exploited by inscriptions is only 1WU. If you want data on the blockchain to be treated equally, current rules simply don't do it and I consider this a fault/bug and/or ongoing exploit.

I'm not so much following discussions of Core devs, but frankly, my perception is a disturbing unwillingness to tackle this weight unit inequity.

I don't need to like what's "inscribed" to the blockchain, it's not my business to judge or censor. Bitcoin is not made to judge or censor.

But from the viewpoint of the network, if a transaction paid for the fees and followed the consensus rules then those transactions are technically valid, and they will be included in the blocks. You can have an opinion on what to call it. It's an "exploit" according to your opinion? OK, but for dick pic/fart sound collectors, their usage of the blockchain is merely something you don't approve of.