You’re attacking the straw man, when the real culprit are the NEW venture capital funded business models that will use op return to complete their objectives. It’s not an OR as they’ve said, it’s an AND.

Core is corrupt. No other explanation.

I don't think the OP_RETURN limit changes were made with the expectation of attracting use cases that currently use UTXOs and the witness discount.

I think they were made in anticipation that there would be layer 2 solutions that need more immediate ways to anchor their state to the chain, like Citrea zkp's; using inscriptions would require two transactions across two different block heights (I thinl).

Even if they will not do that, should they have that option with V30?

Another avenue is not necessary.

Is pulling the data with op return not easier then in the UTXO set?

If so, that can be an incentive.

For a financial network, 80 bytes of non-Bitcoin data is WAY more than generous. I'm all for making this a block protocol rule, along with the necessary date encoding fixes.

Multiple developer posts/gists and community threads say Citrea historically used a construction of “1 OP_RETURN + 2 unspendable Taproot outputs” (because of the 80-byte limit) and that the project intended to move to one or more larger OP_RETURN outputs once Core’s policy changed.

Now who's a major stakeholder in Citrea? Jameson Lopp

No conflicts of interest detected.

I don't assume that's the reason for the change in the first place...

Next level Game theory. 🧡

Interesting to read different views over the last couple of days from Nick Szabo, Adam Back and many others. Problem in this game is you don’t know who the fuck is DeNiro and who is Pacino.

#bitcoin

cc nostr:nprofile1qqsvfr3f7p95stxqrjslnmuvsmhcxxxqt8swjdfjx5tz7zq0yms5cygprpmhxue69uhhyetvv9ujuumwdae8gtnnda3kjctvqyf8wumn8ghj7am0wsh82arcduhx7mn95r6vuk nostr:nprofile1qqsx5dvc2g3cmjgz4mgelwlk5p2ln2ljrsw23y2ar38z0agd7tefpkgpzemhxue69uhk7unpdenk2urfd3kx2u3wdaexwqg4waehxw309ajkgetw9ehx7um5wghxcctwvs3m9lhx nostr:nprofile1qqsr9cvzwc652r4m83d86ykplrnm9dg5gwdvzzn8ameanlvut35wy3gpzemhxue69uhhyetvv9ujumn0wd68ytnzv9hxgqgdwaehxw309ahx7uewd3hkc3e66qe nostr:nprofile1qqsp4lsvwn3aw7zwh2f6tcl6249xa6cpj2x3yuu6azaysvncdqywxmgpvemhxue69uhkv6tvw3jhytnwdaehgu3wwa5kuef0dec82c33wf6xcutrvyu8ydnpw4ukzae4dc6ksvmvx56ryvnyd568xunex4j85en9v56rvwfkveck2wrnxeckwatyddenwer2w3n8x0mzwfhkzerrv9ehg0t5wf6k2qg4waehxw309ajkgetw9ehx7um5wghxcctwvsvcthy3 nostr:nprofile1qqs8spcgqfgzxkcnerak0t40xs8jfsecgkeywrnam3lvp4qvqp5zv3gpzamhxue69uhhyetvv9ujumn0wd68ytnzv9hxgtcpremhxue69uhkummnw3ez6ur4vgh8wetvd3hhyer9wghxuet59ur4gt0q nostr:nprofile1qqsyefyyj99wys6yv4v5qyw5frq88pym0v2hpvt3w8xfvatjm0krh9spzfmhxue69uhk7enxvd5xz6tw9ec82cspzamhxue69uhhyetvv9ujucm4wfex2mn59en8j6gh890wm nostr:nprofile1qqsg86qcm7lve6jkkr64z4mt8lfe57jsu8vpty6r2qpk37sgtnxevjcpr4mhxue69uhkummnw3ez6ur4vgh8wetvd3hhyer9wghxuet5qyvhwumn8ghj7urewfsk66ty9enxjct5dfskvtnrdaksxv0tx3 nostr:nprofile1qqsw4v882mfjhq9u63j08kzyhqzqxqc8tgf740p4nxnk9jdv02u37ncpz4mhxue69uhhyetvv9uju6mpd4czuumfw3jszynhwden5te0wp6hyurvv4cxzeewv4esugqq4q

nostr:nevent1qqsz6jj839yk5lh86ccxqnjemlu3tj9wlvfvh4j2jqdu4hd9j2rq2fcpzemhxue69uhhyetvv9ujuurjd9kkzmpwdejhg8vcnsu

I think OP_RETURN policies that are more accommodating will have 2 dominant outcomes:

#1) those who can think of a use case for large amounts of arbitrary data - but discouraged from doing so by having to go through the trouble of figuring out how to abuse the UTXO set - will suddenly have a convenient mechanism for implementing their use case; and,

#2) those same people - due to the ease of achieving results vis a vis #1 - will be inspired to come up with more such use cases.

Any information on the long term financing of Core devs from e.g. OpenSats? If that were to be “enough”, would this long term financing not make them akin to a corporate employee, where they need to stay busy to justify themselves? Instead of ad-hoc financing to solve specific issues

Just stumbled across this recently. I can relate because I am a corporate employee, so I know that incentive system particularly well.

This argument is equally viable with good intentions from their side, I’m not saying they are trying to break Bitcoin nor anything like that

So you agree there is no point in filters for op return because no one uses it anyways. Thanks for coming to my ted talk.

But without a solution to the UTXO bloat, OP_RETURN proponents have the higher ground here. Even though I totally agree with you - spammers aren't going to play nice.

But with that said I'll not upgrade, because that is not a solution.

If the only solution is based on the op_return than we have solved nothing.

I think op_returns will get very little usage. There might be some “hey look this is new!” spike, but unless you really need something in an output for technical reasons, I think most data publication will continue to use the witness

Looks like Jimmy is done pulling his punches. Good.

nostr:nevent1qqsz6jj839yk5lh86ccxqnjemlu3tj9wlvfvh4j2jqdu4hd9j2rq2fcpzemhxue69uhhyetvv9ujuurjd9kkzmpwdejhg8vcnsu

Correct!

nostr:nevent1qqsz6jj839yk5lh86ccxqnjemlu3tj9wlvfvh4j2jqdu4hd9j2rq2fcpzemhxue69uhhyetvv9ujuurjd9kkzmpwdejhgq3q0vlhsqm4qar0g42p8g3plqyktmktd8hnprew45w638xzezgja95qxpqqqqqqzqmwluz

#Knots fixes this. It filters inscriptions spam and limits OP_RETURN. Running #Knots

Who are you seeing doing any of those things? As far as I can tell you're arguing about strawman.

Absolutely. I would also add the simple premise that node operators should be able to have increased configurability of their nodes. I hear a lot of personal attacks and fear mongering, but I have not heard much about the importance of nodes to control what they relay. I think thats the core issue (no pun intended)