Long-form Content: ~ (Why Inscriptions are an exploit) by jb55 (npub1xts…kk5s) \ stacker news ~bitcoin

pull down to refresh

Long-form Content: ~ (Why Inscriptions are an exploit) by jb55 (npub1xts…kk5s)njump.me/naddr1qqxnzdesxyurwd3jxuengv3nqgsr9cvzwc652r4m83d86ykplrnm9dg5gwdvzzn8ameanlvut35wy3grqsqqqa280afpv2

2845 sats \ 6 comments \ @Roll 7 Dec 2023 bitcoin freebie

view all related items

100 sats \ 0 replies \ @Zepasta 7 Dec 2023

Remember, bitcoin is not for storing data, so anytime bitcoin-devs accidentally make it cheap and easy to relay data then this should be viewed as an exploit.

Don't care. Its not for investment and trading either and people are doing it, should their txs be viewed as an expoit assell?

Most inscriptions are junk and spam GBs, sure, but that doesn't mean there aren't some good use-cases. It doesn't really matter anyways if its all shitcoinery, everyone allowed this, its too late to go back.

None of this affects me in anyway. In fact, if shitcoiners and nft retards are leaving ETH to come to Bitcoin driving up the value, adoption and paying gigantic fees to miners in the process. Seems a win win to me.

bitcoin devs should be working on solutions. Ideological devs like luke who actually care about the health and decentralization

Just suck his dick already. The guy is a mongloid who lost his own coins and begged for more donations. He is a mini-Dictator, and his Ocean-piss pool filtering transactions is just madness that should'nt exist in Bitcoin.

10 sats \ 0 replies \ @0xIlmari 7 Dec 2023

There's so many takes I disagree with.

Storing arbitrary data in the blockchain is still a bad idea; it is less costly and far more efficient to store non-currency data elsewhere.

"Costly" and "efficient" are subjective - the person who stores the data can decide whether they need the entire monkey JPEG on the blockchain or just its hash. It's their choice of paying for security. Either way, they need to consume a single unprunable utxo for this operation.

Besides, the blockchain is such a perfect immutable and incorruptible database, it should be of no surprise that people would want to inscribe onto it things they want to be immortalized, like say, ownership deeds to real estate. And per my understanding, if you want this data to be "movable", it cannot be stored in an OP_RETURN, which is why Ordinals "solve" this "problem".

Inscriptions are also taking advantage of features in segwit v1 (witness discount) and v2/taproot (no arbitrary script size limit). Each of these features have interesting and well-justified reasons why they were introduced.

Like I said in another thread, SegWit is Bitcoin's greatest unspoken hipocrisy. After "winning" the block size wars unchanged, Bitcoin then increases it anyway with SegWit "discount" but purists still sit on their high horses complaining that blocks space is being used "not according to design".

Remember, bitcoin is not for storing data [...]

But can be used as such. Financial transactions are data, after all. For example, SegWit transactions appear as trivial "anyone-can-spend" to a non-SegWit-aware node because the meat of the verification is buried in a structure it does not understand - to it, it's "just some arbitrary data".

[...] so anytime bitcoin-devs accidentally make it cheap and easy to relay data then this should be viewed as an exploit.

No, it should be viewed as devs being too short-sighted in making changes.

Perhaps there's a lesson to be learned from Cardano and their academic peer-review process for every change.

Data should not get a discount, people should pay full price if they want to store data.

This one I can agree with. And the consequence is that SegWit should also be reverted.

And to close out, if utxo set size is already a problem, then Bitcoin is a failure. "8 billion utxos for 8 billion people" should be the minimum to aim for, and still run fine on a Raspberry Pi. Bitcoin devs should focus on solving this problem, not some imaginary "spam" or "exploit" attack.

10 sats \ 0 replies \ @Lumor 7 Dec 2023

I'm coming around to Will & Luke's stances somewhat too. OP_RETURN set a precedent of having a configurable max size and being explicitly prunable. Inscriptions appear to be largely prunable while Stamps are not. It's a mixed bag. High fee environments force L2 solutions to evolve.