571 sats \ 4 replies \ @nerd2ninja 9 Jan \ parent \ on: PR closed: datacarriersize: Match more datacarrying by luke-jr bitdevs
Yeah this thinking is basically what moonsettler calls the "Evil mempool" scenario. We sort of saw the scenario play out with Full RBF (https://mempool.space/rbf) where even though it isn't a default setting, even though you need to run a custom client to peer with other nodes that don't ignore your full rbf txs, we still see a full rbf txs get mined and frequently.
Core's development objectives have always been to never merge anything that doesn't have full consensus (even with mempool policies) because they don't want people routing around them (like full rbf people are doing right now...they should really merge that PR lol) and so that's a huge part of why (more specifics in the PR comments you can read obviously) they locked this thread.
Now to be clear, I'm still very much on the side of prioritizing financial transactions over this noise, but for technical reasons, I prefer to look at increasing costs for undesirable behavior and making cheaper the desired behavior, because that's what's actually going to work.
even though you need to run a custom client to peer with other nodes that don't ignore your full rbf txs
Nitpick: that's actually not necessarily true right now. There's enough people running really well connected full-rbf nodes that a node that accepts incoming connections has a reasonable chance of being connected to a full-rbf node.
But certainly, if you want your full-rbf txs to be guaranteed to propagate, run this: https://github.com/petertodd/bitcoin/tree/full-rbf-v25.1
I'll have a version for v26 soon too.
reply
lol thank you for the update
reply
I don't believe there's a way to do this without crippling other use-cases focused on scaling (like BitVM). The best way to do this imo is to teach those who don't like inscriptions to change their policy to disallow transactions with large scripts from being relayed to their mempool.
reply
Yeah so one thing some people I know are talking about is like, increasing the cost of scripts. So that would be making the vbyte weighting for segwit space to be closer to the weight for the utxo set space, but not exactly the same weight for example.
Ultimately though, the real killer way to do this is to have 100 users share a utxo (L2 scaling solution) and each user pays 1 sat vbyte to exit and that becomes a 100 sat a vbyte tx on-chain that serviced 100 people. That's gonna take years and years to develop all the things we need to get to that point, but that's the ultimate direction.
reply