Thanks for writing this, nostr:nprofile1qqs9pk20ctv9srrg9vr354p03v0rrgsqkpggh2u45va77zz4mu5p6ccpzemhxue69uhk2er9dchxummnw3ezumrpdejz7qgkwaehxw309a5xjum59ehx7um5wghxcctwvshszrnhwden5te0dehhxtnvdakz7qrxnfk . Can you help with a couple more questions?
How do we get rid of inscriptions? Is there anything we could do, regardless of how difficult it would be, that could do it?
Can we get rid of the segwit discount? I understand segwit solved an exploit that was involved in the MtGox hack, but is the discount really necessary?
Shitcoins will automatically be priced out once Bitcoin adoption achieves critical adoption globally.
Pleb transactions will also be priced out, and this why layer2/3 are extremely importants for the long term success of Bitcoin. Otherwise it will just become a digital gold that no pleb can use.
Inscriptions aren't shitcoins. I agree that 2nd layers are extremely important, but I do not agree that plebs will ever be priced out without them. If that were a believable scenario, then the focus should be more on handling "utxo bloat" - meaning making the bloat okay, instead of avoiding it. The reason is because 1 sat/vbyte is not the minimum tx fee.
But I don't think these issues have anything yo do with my questions, and I don't want to be sidetracked.
Inscriptions in their current form can be filtered by matching against non-executed conditional script branch opcodes, that is OP_FALSE OP_IF. This is what Knots does in CScript::DatacarrierBytes https://github.com/bitcoinknots/bitcoin/blob/271fd206893a164b2d1c2d1c44c3696d23dd10e9/src/script/script.cpp#L329C36-L381
Core proponents state that this is not good enough since, were this logic to be applied everywhere, inscription spammers would find another way to push their data.
What other ways might they use?
Probably endless when it comes to embedding data within script opcodes, I can imagine inscription spammers could easily update their protocol such that instead of embedding data within the OP_FALSE OP_IF .. OP_ENDIF envelope, they would do so within something a bit more convoluted, but still not executed as a logical branch, maybe take advantage of OP_ADD / OP_LESSTHAN etc etc
I think the only way to really remove the spam threat is probably by allowing only well known transaction types, which means a set of transactions even more restricted than what are currently deemed standard. I am not sure this approach would be definitive anyways, but it would be incredibly controversial probably and it would come with its own set of risks, if feasible at all. I am personally in no position to currently propose alternative approaches, even in theory, as I am far from being a Bitcoin expert, so these are just some thoughts off the top of my head.
It still helps. Thanks for giving your thoughts.
