Not a fan of Inscriptions? Perhaps you should run Bitcoin Core v 20.2 like I do.

[BitcoinCanSaveUsAll]

Hello everyone,

Before I start this message, I first wanted to wish everyone a happy holiday season and a very prosperous New Year in 2024. Ok now that that's out there, I feel that its important that I post related to the ongoing Inscriptions/Ordinals issue that's bloating L1 and, IMO, attacking the social, technical, and financial game theory layers of Bitcoin.

As I see things it appears as though they, entities funded and/or focused in TRADFI, are currently pitting miners against many members of the community and the generally accepted ethos of the greater good of bitcoin's independence of the traditional fiat system, and are currently complicit in attempting to fold our BTC freedom money into the fiat system.  These inscriptions and ordinals attacks are trying their very best to create things like "rare sats" (which attacks the fungibility of Bitcoin token) while also pushing NFTs onto L1 while simultaneously making every node runner responsible in hosting these potential political attack vectors. 

Also not to mention that with the currently (artificially high due to inscriptions IMO) L1 transaction fees, they're making it impractical for many of the lower earners / net worth folks around the world to attain self custody of their sats and thereby making them reliant on third party custody solutions which very much pumps the breaks hard on the self custody revolution that IMO Bitcoin is all about.  I should also mention that with respect to the higher fees over the last few months that I understand that eventually fees will rise on Layer 1 however it's my view that they will only do so in terms of fiat currency, not in sats or Bitcoin as the price of BTC should rise and eventually the large publicly traded miners selling them for fiat will likely be part of team HODL rather than team fiat.

Since currently however TRADFI seems to have their tentacles deep into the fiat price of bitcoin and are taking this opportunity (while their political money still has value relative to bitcoin) to try their best to get control of it by all means necessary (look at the current Elizabeth Warren attack on self custody initiated by the CEO of the largest US bank , Mr. Dimon).  To me it comes down to the grass roots community here to try to stave off these attacks as soon as possible. 

With all of that said, as a long time node runner in different parts of the world I've been noticing a difference between my node's mempool and what mempool dot space as well as blockstream dot info. After digging into it a bit deeper (with the help of the new goggle tool on mempool dot space), I was able to look at literally dozens of transactions in the mempool labeled inscriptions and then try to pull the same transaction on my nodes running version 20.2 and none of them were visible..that is until they're confirmed by the miners. The point I'm trying to get through however is that if you don't support inscriptions like me, then you might want to consider running an older version of bitcoin core as your node like me as it appears to filter them out of the mempool. Case in point as of now I see about a 1 GB difference between mempool dot space and my node (1.48 GB / 311,000 TXs on their site vs. 564 MB/81,000 TXs on my node).

As always, any and all feedback is greatly appreciated...especially relating to the apparent filtering of the inscription transactions on bitcoin core v 20.2.  Thanks in advance and again happy holidays everyone!

[1714907309]

1714907309

[1714907309]

1714907309

[pooya87]

As always, any and all feedback is greatly appreciated...especially relating to the apparent filtering of the inscription transactions on bitcoin core v 20.2.

There are pros and cons to doing this:
Version 20.2 didn't support witness version 1 yet (it was added in the next release) so it can successfully reject all the Ordinals Attack spam transactions from your mempool regardless of the way they are exploiting the protocol (since they changed it to circumvent other attempts at purging them).

However, this will also [mempool] reject other witness version 1 transactions from regular users that are not malicious.
The other downside is that you no longer fully verify blocks you receive either. Since as I said your node doesn't have the code for the full consensus rules to do so. That means you are relying on the rest of the network to verify that part of the blocks and only add them to the chain if they were valid, instead of fully verifying everything yourself which is what Bitcoin stands for.

[BitcoinCanSaveUsAll]

Thank you for the reply and the additional information. I hope at some point that the Bitcoin core team decides to allow people to activate and deactivate various options on demand in their nodes (such as to be able to turn taproot on or off etc which appears to be what all the inscriptions are using nowadays) . That way we can get all the updates and decide whether or not we want to opt into the various types of transactions or features /behaviors that are present in our own mempools.

[Kruw]

I hope at some point that the Bitcoin core team decides to allow people to activate and deactivate various options on demand in their nodes (such as to be able to turn taproot on or off etc which appears to be what all the inscriptions are using nowadays) . That way we can get all the updates and decide whether or not we want to opt into the various types of transactions or features /behaviors that are present in our own mempools.

Since the inscriptions are still getting confirmed in blocks, rejecting them from your mempool is only delaying the inevitable.  I don't know what problem you think you are solving exactly.

[franky1]

I hope at some point that the Bitcoin core team decides to allow people to activate and deactivate various options on demand in their nodes (such as to be able to turn taproot on or off etc which appears to be what all the inscriptions are using nowadays) . That way we can get all the updates and decide whether or not we want to opt into the various types of transactions or features /behaviors that are present in our own mempools.

Since the inscriptions are still getting confirmed in blocks, rejecting them from your mempool is only delaying the inevitable.  I don't know what problem you think you are solving exactly.

user node assisted rejection pre-confirm wont help much
these junk spammers use fibre(known nodes closely peered to mining pool manager nodes), accelerator(again peers partnered with mining pool nodes) and other portals directing traffic to pools

if people actually looked at the topology of network nodes to see which are most influential they will soon see general user nodes are at the borders, not center of the network

whats actually needed is either:
to make certain opcodes be punished at a higher fee rate than other peoples normal transactions using a fee formulae
where pools dont include junk unless the junk spammers pay a premium and blocks evading the formula get rejected thus makes pools comply to the formulae
or
opcodes with no content condition re-disabled again whereby the are only treated as 'isvalid' validation bypass if the block version is above version of current known ruleset. whereby block version only changes when network readiness shows is majority ready to understand new formats, so only a small underclass  of minority nodes are using the bypass, but all new nodes have format/content conditions set

[OgNasty]

Are you a fan of censoring the blockchain?  Use pro-censorship node software!

There I fixed it for you.  This seems like a pretty slippery slope though.  How long before more transactions you don't like are added to the exclusion list?  When your coins are excluded from being transacted on the blockchain or your address is blacklisted, will you then think this is a bad idea?  I'm just wondering if you think letting this cat out of the bag won't result in it biting you at some point.  Personally, I think that letting certain transactions take advantage of the blockchain while censoring others that use the same method to accomplish a different goal is against what Bitcoin stands for.

[franky1]

Are you a fan of censoring the blockchain?  Use pro-censorship node software!

There I fixed it for you.  This seems like a pretty slippery slope though.  How long before more transactions you don't like are added to the exclusion list?  When your coins are excluded from being transacted on the blockchain or your address is blacklisted, will you then think this is a bad idea?  I'm just wondering if you think letting this cat out of the bag won't result in it biting you at some point.  Personally, I think that letting certain transactions take advantage of the blockchain while censoring others that use the same method to accomplish a different goal is against what Bitcoin stands for.

what if i told you bitcoin WAS designed to reject transactions that dont meet a format standard...
what if i told you bitcoin always did and has rejected certain transactions for a large variety of reasons

what if i told you the reason bitcoin was not full of nonsense before this issue, is because bitcoins job is actually to verify and only include certain data that meets certain thresholds of rules compliance

what if i told you numbskulls relaxed the rules to make their future lives easier, exploitable to not need consensus every time they brainfart an idea.., to soften consensus and want junk.. and they hate anyone trying to fix the "softening" to make their live harder again
what if i told you these numbskulls hate people using bitcoin because they cant make money from them as ROI for sponsored projects

what if i told you, you have been trapped into a narrative that promotes the destabilisation of bitcoin utility for the promotion of other network adoption

[pooya87]

Are you a fan of censoring the blockchain?  Use pro-censorship node software!

In that case you should stop using bitcoin or running bitcoin core altogether because from early days we have been "censoring" hundreds of different types of perfectly valid but abusive transactions through standard rules

And to think a user who has been around from at least 2011 doesn't already know that!!

[BlackHatCoiner]

The fact that people want to completely ignore taproot for the sake of shutting down Ordinals clearly signs there's something wrong in the Bitcoin community.

to make certain opcodes be punished at a higher fee rate than other peoples normal transactions using a fee formulae

Hey franky, could you please explain to me how to punish someone without softforking (or hardforking)? Not that I agree with it, but I simply want to know how to impose such a policy to a miner. The way I see it is: the network is peer-to-peer, the Ordinal user can send their transaction to the miner, completely bypassing everyone supporting this "fee punishment policy".

[franky1]

The fact that people want to completely ignore taproot for the sake of shutting down Ordinals clearly signs there's something wrong in the Bitcoin community.

to make certain opcodes be punished at a higher fee rate than other peoples normal transactions using a fee formulae

Hey franky, could you please explain to me how to punish someone without softforking (or hardforking)? Not that I agree with it, but I simply want to know how to impose such a policy to a miner. The way I see it is: the network is peer-to-peer, the Ordinal user can send their transaction to the miner, completely bypassing everyone supporting this "fee punishment policy".

i thought you left!!.. dang it. i was hoping to see the average IQ of the forum would rise in your absence
(dont came back just to play dumb now.. try to actually make an effort this time, now that you returned. start a new chapter of your life, be different than you were before. make an effort this time.. please dont just sound like an echo of a certain person, try better)

as for how to implement it.. its easy..
the same way everyone sees legacy pays more then segwit.. by CODING IT!!!

firstly. you dont apply it to miners.. ASICS do not select transactions, nor are asics using nodes..  
you apply it to node, knowing POOLS use an node as a backbone of transaction selection

also it can be enforced by mandating POOLS comply by blackmailing them that their blocks will get rejected if they dont comply.. you know exactly how that happened before. so its not a precedent that goes against your morals

there are many ways to code it.. consensus enforced or just policy followed
a. consensus enforced:
have a fee formulae that transactions using certain opcodes pay a certain threshold. and if transactions are not in the threshold then the block can be rejected, thus making pools ensure they put certain complying transactions into a block, thus enforcing transactors wanting to use certain opcodes pay the premium to get included

b. just policy followed
heck it doesnt need to be enforced by being a consensus rule. simply knowing majority use core as the backbone of the network where pools API call their transaction selections from a core node. just having it as "policy" seems to have shown compliance..much like how legacy transactions are seen to be paying more then segwit without any consensus enforcement

but like i said code is great. anything can be coded, so its not impossible. it just needs core dev politics to want to add it

as for the fee formulae
the options are limitless
EG
if opcode used, the formulae could be:
(144/utxo age)*100
meaning
a 1 confirm spam respend using certain opcode starts 14400 higher then a normal transaction

meanwhile regular bitcoiners using regular opcodes pay the regular rate

..
thats the beauty of code. devs can code any rules and policy they like.

[BlackHatCoiner]

i thought you left!!.. dang it. i was hoping to see the average IQ of the forum would rise in your absence

Love you too.

the same way everyone sees legacy pays more then segwit.. by CODING IT!!!

Before writing, take a minute to read the entire post. I said without softforking or hardforking. Legacy pays more than Segwit, because of softfork.

heck it doesnt need to be enforced by being a consensus rule. simply knowing majority use core as the backbone of the network where pools API call their transaction selections from a core node.

That is not going to work just as with non-standardness. The Ordinal user will not use a client which charges them more, and the miner will absolutely not ignore a non-policy-compliant transaction unless they don't want profit.

[franky1]

i thought you left!!.. dang it. i was hoping to see the average IQ of the forum would rise in your absence

Love you too.

the same way everyone sees legacy pays more then segwit.. by CODING IT!!!

Before writing, take a minute to read the entire post. I said without softforking or hardforking. Legacy pays more than Segwit, because of softfork.

heck it doesnt need to be enforced by being a consensus rule. simply knowing majority use core as the backbone of the network where pools API call their transaction selections from a core node.

That is not going to work just as with non-standardness. The Ordinal user will not use a client which charges them more, and the miner will absolutely not ignore a non-policy-compliant transaction unless they don't want profit.

POOLS (i cant beleive i have to correct you about differences between miners and pools still)
POOLS would accept fee policy that earns them more income. and causing junk to be a premium can be a income gainer for them

changing code doesnt need to result in FORKING
however soft or hard changes need to happen to change things..

ordinals users dont need to upgrade node. but if pool nodes ar challenging the fee law, thus demanding ordinal tx pay x rate. ordinals would soon see their broadcasts not enter blocks as quick, thus they end up RBF until confirmed, learning the hard way they were initially paying too little

.. and no dont reply 'but i blackhat was asking how to upgrade without upgrading'
again not all upgrades result in a fork
some upgrades can be soft or hard without causing a fork of differing blocks

did you know core devs do and have messed with minrelay.. dust limit and bumpfee increment defaults and serialisation cost multiples without causing network turmoil

notice how adding taproot did not cause a network block fork

not all changes result in forks..

..
please dont enter 2024 with the witchcraft pitchfork mindset of your forum wife..
his game is core do things soft to prevent forks. anyone not core should be treated as witches and be threatened out of town with pitchforks "fear the fork".. pretend any idea not instigated by core gods will cause forks

[BlackHatCoiner]

ordinals users dont need to upgrade node. but if pool nodes ar challenging the fee law, thus demanding ordinal tx pay x rate. ordinals would soon see their broadcasts not enter blocks as quick, thus they end up RBF until confirmed, learning the hard way they were initially paying too little

And I'm telling you: this won't work. Let me give you an example. Let's say that if a transaction contains tapscript, it needs to pay double of what a non-tapscript transaction of the same size does.

Ordinal users start broadcasting transactions ignoring this arbitrary rule. The pool's option are:
- either to ignore the transactions.
- include them with this "unfair" fee.

Another way to put it is: if you double tapscript transactions' fee, the tapscript users will simply choose half the fee they were choosing previously.

[Casdinyard]

Are you a fan of censoring the blockchain?  Use pro-censorship node software!

There I fixed it for you.  This seems like a pretty slippery slope though.  How long before more transactions you don't like are added to the exclusion list?  When your coins are excluded from being transacted on the blockchain or your address is blacklisted, will you then think this is a bad idea?  I'm just wondering if you think letting this cat out of the bag won't result in it biting you at some point.  Personally, I think that letting certain transactions take advantage of the blockchain while censoring others that use the same method to accomplish a different goal is against what Bitcoin stands for.

honestly not a stretch. Eventually if people are this eager to use pro-censorship software we're going to have people literally blocking other addresses from sending or receiving them money, which in itself has its perks as we can blacklist addresses from suspected hackers and scammers, but at the same time especially with how fast cancelation in the internet works before figuring shit out it might end up just as you said, people just blacklisting other people from sending money. It also poses security and identity risks cause in some way you gotta know the person from a certain level to know for sure that they are the ones you want to blacklist.

I think the solution towards ordinals do not lie upon the users or the people in the blockchain. The developers should do something about it besides banning it cause honestly in the future another project will just come out to entice the people again with the concept of "______ but in bitcoin" just as what ordinals did. If that happens are they just going to ban every project like so?

[franky1]

ordinals users dont need to upgrade node. but if pool nodes ar challenging the fee law, thus demanding ordinal tx pay x rate. ordinals would soon see their broadcasts not enter blocks as quick, thus they end up RBF until confirmed, learning the hard way they were initially paying too little

And I'm telling you: this won't work. Let me give you an example. Let's say that if a transaction contains tapscript, it needs to pay double of what a non-tapscript transaction of the same size does.

Ordinal users start broadcasting transactions ignoring this arbitrary rule. The pool's option are:
- either to ignore the transactions.
- include them with this "unfair" fee.

Another way to put it is: if you double tapscript transactions' fee, the tapscript users will simply choose half the fee they were choosing previously.

if you look at the cludgy math of cores method to count legacy size for fee estimation (witness scale factor x 4)..
legacy users dont then just choose to pay 4x less in fee's to match segwit fee. because doing so means their transaction ends up taking 4x longer to get confirmed

legacy user actually do end up paying more then segwit users just to be on par with confirmation priority.. and that is not even a outright policy nor consensus rule nor causes forks.. its just the over reliance of pools using core as a transaction selector so the fee estimate preferences are built in
to pools method of transaction selection.. by default a legacy paying 4x baserate is the same priority as segwit paying base rate

so the same method can be employed by treated unconditioned opcodes as a multiple of base rate

[BlackHatCoiner]

so the same method can be employed by treated unconditioned opcodes as a multiple of base rate

It doesn't surprise me that I'll have to repeat myself:

- Segwit was a softfork. Not a policy. The math Core applies to the client for legacy transactions might or might not be local policy, but that's because a softfork has preceded.
- For this measure to be effective, the ordinal byte must take more space than a regular transaction byte, as a legacy takes 4 times the space a segwit does. This could happen by re-writing a new block size policy which treats every non-tapscript transaction as the respective to segwit, but again, that's softfork.

I want a non-fork way that cannot be bypassed.