(Ordinals) BRC-20 needs to be removed

[larry_vw_1955]

Have you looked at Mempool Goggles > Data recently? The spam continues. Maybe it moved from "Ordinals" to "Runes", but that's just a different name for the same scam.

wait a minute though. Runes just uses OP_RETURN. There is no abuse going on there. OP_RETURN is a valid op code and it was approved through a reasonable process. if you have a problem with how people are using OP_RETURN then where were you when OP_RETURN was invented and put into use? not complaining about it, i bet. don't worry about things that use OP_RETURN. they are not storing monkeys on chain.

runes is way different than ordinals. ordinals is an abusive use of something that wasn't even really approved through any reasonable process. we all know that...

[LoyceV]

wait a minute though. Runes just uses OP_RETURN. There is no abuse going on there. OP_RETURN is a valid op code and it was approved through a reasonable process. if you have a problem with how people are using OP_RETURN then where were you when OP_RETURN was invented and put into use?

That's like saying email spammers aren't abusing anything, they're just using the system as it was created. Allow me to rephrase your statement: "If you have a problem with email spam, then where were you when email was invented"?

Blocks are filled for 90% with crap like this, created by an automated system and broadcasted in batches.

[larry_vw_1955]

That's like saying email spammers aren't abusing anything, they're just using the system as it was created. Allow me to rephrase your statement: "If you have a problem with email spam, then where were you when email was invented"?

email and bitcoin. two different things. i don't really need to explain why do i?  

Blocks are filled for 90% with crap like this, created by an automated system and broadcasted in batches.

they are valid transactions and each one includes a transaction fee which is being paid.

Code:

Total received	‎153.85497287 BTC
Total sent	‎153.02784341 BTC
Balance	‎0.82712946 BTC $57,235

to you maybe they are spamming the bitcoin network but to me it looks like they are supporting it. maybe they should be using OP_RETURN instead of creating unspendable outputs but that's their perogative. we can't really tell people what to do. their transactions are none of our business.

[pooya87]

to you maybe they are spamming the bitcoin network but to me it looks like they are supporting it.

That's a weird thing to say!

A spam attack is a spam attack, some of them do more damage like the Ordinals Attack, some do less damage like the spam attack nearly a decade ago with the codename Stress Test; at the end of the day they are all categorized as spam attacks and are all damaging bitcoin.

[larry_vw_1955]

That's a weird thing to say!

to be honest, i'm not really sure what all of these transactions are doing.

but here is an example one:
https://www.blockchain.com/explorer/transactions/btc/bb67d708c4d746ef8b73a01910f0ac5c2d92b68304c2c84cf41319272544b9bb

A spam attack is a spam attack, some of them do more damage like the Ordinals Attack, some do less damage like the spam attack nearly a decade ago with the codename Stress Test; at the end of the day they are all categorized as spam attacks and are all damaging bitcoin.

we have to be careful when we don't even know what the purpose for which a transaction was done and yet we label it as "spam", "unwanted", etc.  i was referring specifically to all the thousands of transactions he linked to belonging to that one address. i don't know if they are ordinals or exactly what they are. so i wouldn't want to pass judgement on them yet.

but if you consider it abuse or spam then you know what to do. get segwit changed so that they can't do that kind of thing anymore. but good luck doing that. i don't think the developers care.

i consider ordinals spam. i don't consider OP_RETURN spam. anything trying to bypass the 80 byte limit of OP_RETURN by trying to use segwit and not only that but getting their data weighted as 1 vs 4, well that's definitely spam.

[pooya87]

i don't consider OP_RETURN spam.

At the end of the day Bitcoin is a payment system not a cloud storage. So whether they use the witness exploit to inject arbitrary data to the chain or OP_RETURN, it can be categorized as abuse and when it is done on a large scale we can call it spam.

However, OP_RETURN is a tolerated and standardized abuse that bitcoiners came up with to prevent abusers from using output scripts to "inject data" into the chain and create unspendable UTXOs.

[WillyAp]

At the end of the day Bitcoin is a payment system not a cloud storage. So whether they use the witness exploit to inject arbitrary data to the chain or OP_RETURN, it can be categorized as abuse and when it is done on a large scale we can call it spam.

Beg your pardon, when was the last time you used BTC and paid something with it?
BTC is slow and expensive.

It is time to moderate the Whitepaper. Bitcoin is not a payment vehicle any more.

[LoyceV]

when was the last time you used BTC and paid something with it?

Last week. Your point being?

[larry_vw_1955]

However, OP_RETURN is a tolerated and standardized abuse that bitcoiners came up with to prevent abusers from using output scripts to "inject data" into the chain and create unspendable UTXOs.

so would you consider segwit to be another "tolerated and standardized abuse"? how does 2 things that take up the same storage space on disk and yet one of them has an artificial thing that weighs it less? sounds like abuse to me. ripe for abuse.

[gmaxwell]

so would you consider segwit to be another "tolerated and standardized abuse"? how does 2 things that take up the same storage space on disk and yet one of them has an artificial thing that weighs it less? sounds like abuse to me. ripe for abuse.

They don't take up the "same space".  In order to validate blocks utxo data needs to be quickly accessible as the access speed bottlenecks validation speed, witness data doesn't need to be stored *at all*, since once you've validated it once you can forget it, so the long term cost of witness data is orders of magnitude lower.

Unfortunately the weight calculation can't disregard witness size completely because if its too disregarded it will make nodes bandwidth constrained, because witness and non-witness data are equivalent for the purpose relay at the tip.  Most nodes are far from bandwidth constrained and other known improvements at the time segwit was designed were expected to get nodes 2-4x bandwidth reduction (in terms of their ongoing p2p traffic).

In any case, the perspective you're adopting is a confused one-- I think a confused one specifically engineered by malicious parties attempting to engage in consensus cracking.

There is exactly one metric that matters when it comes to the ability to spam and the cost of spam: the capacity of the network relative to the demand.  Segwit did increase people's ability to add spam, but it did so purely by virtue of adding capacity.  Any other way of adding capacity would have the same effect.  Perhaps the particular spam *encoding* chosen might be different depending on how the capacity limit was constructed, but that's immaterial to anything you care about.   (and fortunately, the weighing scheme has caused the spammers here to encode their bullshit as witness data, which radically lowers the carrying cost of it for the network). 

[ABCbits]

A spam attack is a spam attack, some of them do more damage like the Ordinals Attack, some do less damage like the spam attack nearly a decade ago with the codename Stress Test; at the end of the day they are all categorized as spam attacks and are all damaging bitcoin.

we have to be careful when we don't even know what the purpose for which a transaction was done and yet we label it as "spam", "unwanted", etc.  i was referring specifically to all the thousands of transactions he linked to belonging to that one address. i don't know if they are ordinals or exactly what they are. so i wouldn't want to pass judgement on them yet.

but if you consider it abuse or spam then you know what to do. get segwit changed so that they can't do that kind of thing anymore. but good luck doing that. i don't think the developers care.

At very least, we know transaction which use Ordinal, Rune or similar protocol doesn't have purpose to send Bitcoin to someone else. That alone is enough to make some people classify those TX as spam.

At the end of the day Bitcoin is a payment system not a cloud storage. So whether they use the witness exploit to inject arbitrary data to the chain or OP_RETURN, it can be categorized as abuse and when it is done on a large scale we can call it spam.

Beg your pardon, when was the last time you used BTC and paid something with it?
BTC is slow and expensive.

And what's your point? Some transaction doesn't need very fast confirmation and today's fee (about $1 based on https://mempool.space/) isn't that expensive if you don't make micro-transaction.

[LoyceV]

today's fee (about $1 based on https://mempool.space/) isn't that expensive if you don't make micro-transaction.

But it's too high to go mainstream. I think we, as a family, make up to 200 financial transactions per month. If we'd have to pay $1 for each of those, that would take a significant chunk out of our monthly budget. Obviously this won't be fixed by removing Ordinals (and others), but this is how I compare costs when thinking about a scaling solution.

[ABCbits]

today's fee (about $1 based on https://mempool.space/) isn't that expensive if you don't make micro-transaction.

But it's too high to go mainstream. I think we, as a family, make up to 200 financial transactions per month. If we'd have to pay $1 for each of those, that would take a significant chunk out of our monthly budget. Obviously this won't be fixed by removing Ordinals (and others), but this is how I compare costs when thinking about a scaling solution.

I agree, although if you make up to 200 TX per month (especially to few same seller), it's one of cases when LN could be useful. It's also worth to mention with current Bitcoin price and minimum relay fee rate (imposed by full nodes), you'll need to pay at least $0.1 even with 1 sat/vB fee rate.

[Synchronice]

wait a minute though. Runes just uses OP_RETURN. There is no abuse going on there. OP_RETURN is a valid op code and it was approved through a reasonable process. if you have a problem with how people are using OP_RETURN then where were you when OP_RETURN was invented and put into use?

That's like saying email spammers aren't abusing anything, they're just using the system as it was created. Allow me to rephrase your statement: "If you have a problem with email spam, then where were you when email was invented"?

Blocks are filled for 90% with crap like this, created by an automated system and broadcasted in batches.

The number of TXs load endlessly and all of them seem to be ordinals. This address has done 11,624 transactions (still creating new ones as I am writing), who the hell spent 165 Bitcoins into this?
By the way, do you know what does this mean? (Click on image for high resolution). What does BAVO mean? BAVO MINT 1,000? And why are they so much on this image? It's from the address that you posted.


Do you guys notice the trend of Solana memecoins? Now I think that ordinals, runes, meme coins, etc, they purpose is to launder money and that's why millions of dollars are paid in pixelated dumb ape images and so on. Someone paid 8.2 million in The Rotating Mud in real life

[larry_vw_1955]

They don't take up the "same space".  In order to validate blocks utxo data needs to be quickly accessible as the access speed bottlenecks validation speed, witness data doesn't need to be stored *at all*, since once you've validated it once you can forget it, so the long term cost of witness data is orders of magnitude lower.

i'm not sure what you mean by "utxo data" but utxos don't have signatures attached to them. they have to be signed to be spent. a utxo is just a transaction id with a particular output index number. nothing more than that. in practice though i think the output index number is looked up and replaced with the value and scriptpubkey. but still. we aren't needing to store any signatures in the utxo set.

for non-segwit transactions the signature is stored in the scriptsig field of transaction inputs. but they are not needed. so once you have validated a particular transaction you could just throw it away. and just store any of its outputs you needed to in the utxo set.

In any case, the perspective you're adopting is a confused one-- I think a confused one specifically engineered by malicious parties attempting to engage in consensus cracking.

i understand that segwit solved transaction malleability and that it segregated the signature from the transaction itself. those things should have been done in the very beginning but anyway. i'm not arguing against the merits of segwit but you are/were (?) a bitcoin developer. surely you can't really agree with allowing a segwit signature to hog up the entire block taking up the full 4MB can you? what do you think the developers were thinking when they allowed that loophole?

There is exactly one metric that matters when it comes to the ability to spam and the cost of spam: the capacity of the network relative to the demand.  Segwit did increase people's ability to add spam, but it did so purely by virtue of adding capacity.  Any other way of adding capacity would have the same effect.

keeping non-segwit block size limit at 1MB but telling people "oh, you can do segwit transactions and the block can go up to 4MB and not only that but you get a 75% discount on the fee and guess what, you can store arbitrary data too in the witness signature and it can be as large as you want it to be" that's about as open an invitation to spammers as you could make. kind of unreasonable!

  Perhaps the particular spam *encoding* chosen might be different depending on how the capacity limit was constructed, but that's immaterial to anything you care about.   (and fortunately, the weighing scheme has caused the spammers here to encode their bullshit as witness data, which radically lowers the carrying cost of it for the network). 

you're acting like they will always find a loophole. well it wasn't very hard to find with taproot was it? it was more like an open invitation to spam the blockchain with huge data.

[pooya87]

Beg your pardon, when was the last time you used BTC and paid something with it?
BTC is slow and expensive.

It is time to moderate the Whitepaper. Bitcoin is not a payment vehicle any more.

Bitcoin not being a perfect payment system doesn't mean it is not a payment system used by many people to pay for something. Whether or not I, as an individual, used it for payment doesn't change that fact either.

However, OP_RETURN is a tolerated and standardized abuse that bitcoiners came up with to prevent abusers from using output scripts to "inject data" into the chain and create unspendable UTXOs.

so would you consider segwit to be another "tolerated and standardized abuse"? how does 2 things that take up the same storage space on disk and yet one of them has an artificial thing that weighs it less? sounds like abuse to me. ripe for abuse.

I think you missed the argument entirely.
The point is Bitcoin has a purpose and a utility. That is to be used as a payment system. If you use it for something else (storing arbitrary data), I call that abuse.

OP_RETURN is method of storing arbitrary data in this payment system. That makes it an abuse. But it is standardized, accepted and tolerated. Most importantly because it is part of the protocol, it does far less damage (eg. the outputs are provably unspendable and aren't included in UTXO set) compared to the exploit used in Ordinals attack.

SegWit is NOT a way to store "arbitrary data" in transactions. It is a way to fix malleability and also help the capacity increase of this payment system.
Finding an exploit in SegWit to create Ordinals Attack is a different matter that doesn't categorize SegWit itself as an "abuse".

[ABCbits]

By the way, do you know what does this mean? (Click on image for high resolution). What does BAVO mean? BAVO MINT 1,000? And why are they so much on this image? It's from the address that you posted.

1. BAVO refer to name of the token created using BRC-20 protocol.
2. MINT 1000 means someone mint/create 1000 BAVO token.
3. Someone probably mint/create bunch of BAVO at once.

They don't take up the "same space".  In order to validate blocks utxo data needs to be quickly accessible as the access speed bottlenecks validation speed, witness data doesn't need to be stored *at all*, since once you've validated it once you can forget it, so the long term cost of witness data is orders of magnitude lower.

i'm not sure what you mean by "utxo data" but utxos don't have signatures attached to them. they have to be signed to be spent. a utxo is just a transaction id with a particular output index number. nothing more than that. in practice though i think the output index number is looked up and replaced with the value and scriptpubkey. but still. we aren't needing to store any signatures in the utxo set.

for non-segwit transactions the signature is stored in the scriptsig field of transaction inputs. but they are not needed. so once you have validated a particular transaction you could just throw it away. and just store any of its outputs you needed to in the utxo set.

I think you missed the point. I think his point is that adding arbitrary data to "fake" address/public key leads to longer time to verify transaction, while using witness doesn't have such impact.

[vjudeu]

i'm not sure what you mean by "utxo data" but utxos don't have signatures attached to them

I think it is about "scriptPubKey". Which in case of Taproot is just "OP_TRUE <pubkey>". However, in case of OP_RETURN, it is "OP_RETURN <data>", which means, that Taproot output has constant size (when it comes to "scriptPubKey"), but OP_RETURN can have an arbitrary size, see transaction: https://mempool.space/tx/d29c9c0e8e4d2a9790922af73f0b8d51f0bd4bb19940d9cf910ead8fbe85bc9b

a utxo is just a transaction id with a particular output index number. nothing more than that

There is also "scriptPubKey", mentioned above, which has to be stored. In case of OP_RETURN, it is ignored. In case of Taproot, it has constant size. However, if you take for example bare multisig, then it can be quite huge. And the same with bare Script.

but still. we aren't needing to store any signatures in the utxo set

If you have bare Script, then you can even use "<signature> OP_SWAP OP_CHECKSIG" as your "scriptPubKey", in that case you have to reveal the proper public key to spend it, but only "OP_SWAP OP_CHECKSIG" part is signed. And then, guess what, your signature will be part of the UTXO set. And it is just another way to abuse UTXOs, as well as "<data> OP_DROP OP_TRUE" or "<data> <data> OP_2DROP OP_TRUE", but just with more complex validation for no reason.

surely you can't really agree with allowing a segwit signature to hog up the entire block taking up the full 4MB can you? what do you think the developers were thinking when they allowed that loophole?

1. The famous transaction https://mempool.space/tx/0301e0480b374b32851a9462db29dc19fe830a7f7d7a88b81612b9d42099c0ae just had a single signature, everything else was related just to data pushes, and could be replaced with a single OP_NOP.
2. There are technical reasons to allow bigger signatures than today, if ECDSA would ever be broken. In general, if you think about alternatives to what we have today in OP_CHECKSIG, then they usually take more space. Which also means, that if we would have something else, then we would need batching, to handle N people in a single signature.

Some topic about alternatives to ECDSA: https://bitcointalk.org/index.php?topic=5470213.msg62990674#msg62990674

you can store arbitrary data too in the witness signature and it can be as large as you want it to be

1. It was hard before Taproot, even if you use Segwit.
2. Since Ordinals, some people can get even non-standard transactions mined, in that case, they could just use Segwit v2, and push any data they want. Or even use a bare Script, and then it is even worse.

[larry_vw_1955]

Bitcoin not being a perfect payment system doesn't mean it is not a payment system used by many people to pay for something. Whether or not I, as an individual, used it for payment doesn't change that fact either.

if it was meant to be a payment system then it should always be designed with that goal in mind. at the forefront to make sure that any new feature would not allow it to be used for something else.

SegWit is NOT a way to store "arbitrary data" in transactions. It is a way to fix malleability and also help the capacity increase of this payment system.

but people have been using it to store "arbitrary data".

Finding an exploit in SegWit to create Ordinals Attack is a different matter that doesn't categorize SegWit itself as an "abuse".

it does if the "abuse" goes on for a long enough period of time.  

but OP_RETURN can have an arbitrary size, see transaction: https://mempool.space/tx/d29c9c0e8e4d2a9790922af73f0b8d51f0bd4bb19940d9cf910ead8fbe85bc9b

that's a very old transaction. i thought OP_RETURN was limited to 80 bytes.

If you have bare Script, then you can even use "<signature> OP_SWAP OP_CHECKSIG" as your "scriptPubKey", in that case you have to reveal the proper public key to spend it, but only "OP_SWAP OP_CHECKSIG" part is signed. And then, guess what, your signature will be part of the UTXO set. And it is just another way to abuse UTXOs, as well as "<data> OP_DROP OP_TRUE" or "<data> <data> OP_2DROP OP_TRUE", but just with more complex validation for no reason.

hmm. you just described some ways people could abuse bitcoin. of course, a signature can only be 74 bytes apparently so i don't know why they would do that since OP_RETURN is 80 bytes.

with that said though you are absolutely right that bitcoin's scripting language allows people to do things that they have no business doing. one of the problems of bitcoin: things that are not explicitly disallowed seem to be allowed whereas it should be the REVERSE. but you can't just say "here is a scripting language anything that evaluates to true is good". bad design. poor result.

[pooya87]

i thought OP_RETURN was limited to 80 bytes.

That's a standard rule not a consensus rule. Technically your output script with or without OP_RETURN can be so big so that it fills the entire block. In other words there is no limit on its size other than block size.