269 sats \ 6 replies \ @ek 9 Jan \ on: PR closed: datacarriersize: Match more datacarrying by luke-jr bitdevs
I just realized that the controversy around inscriptions feels a bit like the War on Drugs.
It's pushing people we don't like to the edges of society (and beyond) and then we tap ourselves on the shoulder that we "solved" the problem but actually are making the situation around drug usage worse for everyone involved (including society itself) but we deny reality since we like easy "solutions".
I wouldn't recommend doing drugs to anyone but if someone does drugs, I will also not tell them that they are using life wrong. It's their life and their consequences / problems.
Haven't though too much about this similarity so if someone thinks that's stupid, please tell me so lol
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.
reply
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
Interesting. Thinking bout this..
Transaction types: Standard data transaction, ordinals and inscriptions.
Bitcoin Markets. Exchanges and P2P
Drug Classification: Narcotics, pharmaceuticals, base chemicals, naturally occurring psychotropics, complex synthesized compounds.
Distribution: Cartels and P2P
Reception. Is regulating or deregulating welcome among network participants?
Deregulation of controlled substances: Benefit to buyer
Unwelcome for a drug cartel (pricing has to be competitive)
Encourages a higher quality of product
Lower cost to user.
Deregulation of block space
High fees welcomed by miners
Encourages lightning and L2 usage (minimizing L1 transactions)
reply