BTCtoOblivion on Nostr: As most of the bitcoiners know that scammers have been spamming the bitcoin for more ...
As most of the bitcoiners know that scammers have been spamming the bitcoin for more than year now.
I have seen some good arguments in support of filtering the spam to disincentive the behavior.
Time for the post on strawman and steelman arguments on spam.
Strawman: - What is your definition for scam? While I agree 99% of the trading is done because of speculation and will cause many to lose money. The scams are only projects lying to their customers to run out with their money, which there are many, but much less than speculate traders.
Steelman: - Just because you want to have sex doesn't mean you're justified in raping people who don't consent.
Strawman: - But aren’t they within the consensus rules and therefor it’s not rape? They found an exploit! Ok. Filter. Won’t they find another exploit? Wouldn’t it be better to focus on the monetary use cases? And people will choose to use it as SOV?
Steelman: - What if I find a way to steal anybody’s bitcoin within the consensus rules. Will you fix the bug? I will let him steal my Bitcoin as long as it is in consensus rules.
Strawman: - Ya I probably would want that fixed. But 1) how would someone steal bitcoin and still be within consensus? And 2) how are cat jpegs on blockchain the same as stealing someone’s bitcoin? That’s a clear issue needing addressed.
Steelman: - 1) people thought that the supply limit was 21m until someone found out how to violate it within the code's consensus engine. There's no know way to steal today, but the question is about how you would react if such a hypothetical vulnerability was discovered in the future - the exact mechanics of the exploit don't matter for the hypothetical. 2) cat jpegs on chain and steal someone's Bitcoin are the same issue because there isn't consensus for either one of them.
Strawman: - Is the 'exploit' that the code was written just fine, operates just as expected, and is being used in a different but anticipated way, but at an unanticipated rate? Or is there more?
Steelman: - Bitcoin script was not intended for unlimited arbitrary data storage, therefore it is not operating as expected.
Strawman: - Seems like Casey expected OP_FALSE, _IF, _PUSH, _ENDIF to operate that way. Do you mean he just guessed? Storage is still bound by block size(not unlimited) and the 'scammers ran out of fiat for their attack', ie fees operated exactly as we all expected them to do.
Steelman: - You're describing every single exploit/hack/crack in computer software history. The people who designed OpenSSL intended it to be a library for HTTPS security. The people who designed the Heartbleed hack expected to break OpenSSL so, you think Heartbleed wasn't an exploit and OpenSSL was just fine? This is clown-world logic.
Steelman: - In information security terminology, a "bug" is a problem found in the software. Some bugs are also "vulnerabilities", meaning that you can leverage them to cause unintended or unexpected behavior by the software. Leveraging them is the "exploit" of the vulnerability.
Strawman: - I can convince myself it's an exploit (semantically) but I still struggle to see the bug. Everything is operating as expected, but some users are using those operations (in an obvious way) to do something others for whatever reason didn't expect.
Steelman: - The bug is the datacarriersize is not properly counting data carried inside op_false op_if
Strawman: - ty! (although begs the q what is meant by 'properly') Was there a reason it was ignored? Was this deliberate decision? A non-concern? My (crude) understanding was some initially used this for commenting, as it doesn't execute anything.
Steelman: - When datacarriersize was first introduced in 0.9 it was done so simultaneously with op_return. Prior to 0.9 people had started to use ridiculously inefficient methods to embed small amounts of arbitrary data in transactions, so a consensus emerged to create a strictly limited, but TOLERATED way to add arbitrary data to transactions - that's what op_return was. To limit the amount of arbitrary data per transaction, datacarriersize was added. For the next 10 years, all was happy. Then in early 2023 someone discovered a way to add arbitrary data to a transaction outside of op_return, and bypass the datacarriercheck matching heuristic. This bug was critical for inscriptions to work because it meant that they could bypass the existing spam filters to add any amount of arbitrary data up to the block weight limit. In mid-2023, the bitcoin core managers closed the issue about the bug, claiming that discussing the github topic was "too controversial" In August 2023, a Bitcoin core maintainer changed the documentation/comments in the source code which defined arbitrary data. Since then the core team has been unwilling to acknowledge that this is a bug.
Strawman: - Also remember that a property of OP_RETURN is that it creates a provably unspendable utxo, which can be safely pruned if you don't want to store the arbitrary data on your node.
Steelman: - This isn't an argument against spam, though. Pruning just adds to the work of a full node, it doesn't eliminate it. And Inscriptions are all equally prunable.
Steelman: - OP_RETURN is a top symbol of altcoining mindset, such mindset classic 'solution' is a BAND-AID to pretend the problem does not exist and life goes on. As hash-anchoring to TXs is possible, the question needs to be: how to make it VERY cumbersome. NOT apply a band-aid on top.
As you can see clearly from some of these arguments that legitimate bug is being exploited by some bad actors in the #bitcoin community.
I would strongly suggest running @BitcoinKnots
to disincentivize this behaviour and if you are miner then send your hash to @ocean_mining
.
If this bug doesn't get fixed then I wouldn't be surprised if we have to reconsider the blocksize limit since spam (sorry scam) has been bloating bitcoin blockchain and UTXO set like never before.
It will drive up the cost to run your own node hence we may need to think about reducing the blocksize limit as you can see most of the mempool is filled with garbage (to scam the people)
Maybe 300kb-400kb limit would be optimal blocksize limit. It will at least keep the cost of running your own node low for a very long time.
If you want to see bitcoin getting succeed, you don't want to see NGU in only #bitcoin price but NGU in node runners as well and current spamming condition will severely affect the NGU in node runners (in the long run for sure).
cc GrassFedBitcoin (npub1wnl…n3wr) Luke Dashjr (npub1lh2…a9nk) Asher (npub16s0…8ky6) giacomozucco (npub1au2…t53j)
I have seen some good arguments in support of filtering the spam to disincentive the behavior.
Time for the post on strawman and steelman arguments on spam.
Strawman: - What is your definition for scam? While I agree 99% of the trading is done because of speculation and will cause many to lose money. The scams are only projects lying to their customers to run out with their money, which there are many, but much less than speculate traders.
Steelman: - Just because you want to have sex doesn't mean you're justified in raping people who don't consent.
Strawman: - But aren’t they within the consensus rules and therefor it’s not rape? They found an exploit! Ok. Filter. Won’t they find another exploit? Wouldn’t it be better to focus on the monetary use cases? And people will choose to use it as SOV?
Steelman: - What if I find a way to steal anybody’s bitcoin within the consensus rules. Will you fix the bug? I will let him steal my Bitcoin as long as it is in consensus rules.
Strawman: - Ya I probably would want that fixed. But 1) how would someone steal bitcoin and still be within consensus? And 2) how are cat jpegs on blockchain the same as stealing someone’s bitcoin? That’s a clear issue needing addressed.
Steelman: - 1) people thought that the supply limit was 21m until someone found out how to violate it within the code's consensus engine. There's no know way to steal today, but the question is about how you would react if such a hypothetical vulnerability was discovered in the future - the exact mechanics of the exploit don't matter for the hypothetical. 2) cat jpegs on chain and steal someone's Bitcoin are the same issue because there isn't consensus for either one of them.
Strawman: - Is the 'exploit' that the code was written just fine, operates just as expected, and is being used in a different but anticipated way, but at an unanticipated rate? Or is there more?
Steelman: - Bitcoin script was not intended for unlimited arbitrary data storage, therefore it is not operating as expected.
Strawman: - Seems like Casey expected OP_FALSE, _IF, _PUSH, _ENDIF to operate that way. Do you mean he just guessed? Storage is still bound by block size(not unlimited) and the 'scammers ran out of fiat for their attack', ie fees operated exactly as we all expected them to do.
Steelman: - You're describing every single exploit/hack/crack in computer software history. The people who designed OpenSSL intended it to be a library for HTTPS security. The people who designed the Heartbleed hack expected to break OpenSSL so, you think Heartbleed wasn't an exploit and OpenSSL was just fine? This is clown-world logic.
Steelman: - In information security terminology, a "bug" is a problem found in the software. Some bugs are also "vulnerabilities", meaning that you can leverage them to cause unintended or unexpected behavior by the software. Leveraging them is the "exploit" of the vulnerability.
Strawman: - I can convince myself it's an exploit (semantically) but I still struggle to see the bug. Everything is operating as expected, but some users are using those operations (in an obvious way) to do something others for whatever reason didn't expect.
Steelman: - The bug is the datacarriersize is not properly counting data carried inside op_false op_if
Strawman: - ty! (although begs the q what is meant by 'properly') Was there a reason it was ignored? Was this deliberate decision? A non-concern? My (crude) understanding was some initially used this for commenting, as it doesn't execute anything.
Steelman: - When datacarriersize was first introduced in 0.9 it was done so simultaneously with op_return. Prior to 0.9 people had started to use ridiculously inefficient methods to embed small amounts of arbitrary data in transactions, so a consensus emerged to create a strictly limited, but TOLERATED way to add arbitrary data to transactions - that's what op_return was. To limit the amount of arbitrary data per transaction, datacarriersize was added. For the next 10 years, all was happy. Then in early 2023 someone discovered a way to add arbitrary data to a transaction outside of op_return, and bypass the datacarriercheck matching heuristic. This bug was critical for inscriptions to work because it meant that they could bypass the existing spam filters to add any amount of arbitrary data up to the block weight limit. In mid-2023, the bitcoin core managers closed the issue about the bug, claiming that discussing the github topic was "too controversial" In August 2023, a Bitcoin core maintainer changed the documentation/comments in the source code which defined arbitrary data. Since then the core team has been unwilling to acknowledge that this is a bug.
Strawman: - Also remember that a property of OP_RETURN is that it creates a provably unspendable utxo, which can be safely pruned if you don't want to store the arbitrary data on your node.
Steelman: - This isn't an argument against spam, though. Pruning just adds to the work of a full node, it doesn't eliminate it. And Inscriptions are all equally prunable.
Steelman: - OP_RETURN is a top symbol of altcoining mindset, such mindset classic 'solution' is a BAND-AID to pretend the problem does not exist and life goes on. As hash-anchoring to TXs is possible, the question needs to be: how to make it VERY cumbersome. NOT apply a band-aid on top.
As you can see clearly from some of these arguments that legitimate bug is being exploited by some bad actors in the #bitcoin community.
I would strongly suggest running @BitcoinKnots
to disincentivize this behaviour and if you are miner then send your hash to @ocean_mining
.
If this bug doesn't get fixed then I wouldn't be surprised if we have to reconsider the blocksize limit since spam (sorry scam) has been bloating bitcoin blockchain and UTXO set like never before.
It will drive up the cost to run your own node hence we may need to think about reducing the blocksize limit as you can see most of the mempool is filled with garbage (to scam the people)
Maybe 300kb-400kb limit would be optimal blocksize limit. It will at least keep the cost of running your own node low for a very long time.
If you want to see bitcoin getting succeed, you don't want to see NGU in only #bitcoin price but NGU in node runners as well and current spamming condition will severely affect the NGU in node runners (in the long run for sure).
cc GrassFedBitcoin (npub1wnl…n3wr) Luke Dashjr (npub1lh2…a9nk) Asher (npub16s0…8ky6) giacomozucco (npub1au2…t53j)