apologies, my nostr-edit appears not not have made it to you: "arent nodes running filters to impede this propagation as a way to marginally discourage behavior relaying *blocks with* transactions not accepted by the wider network"

i think you mistake the occasional stunt by miners to throw random junk they choose to include in blocks as a failure of mempool policy. it'd be as absurd as to pointing to an empty block and blame it on mempool policy too

Magically worked again for two days after rotating graphics cards,, just to crash at a very inopportune moment.

We are also arguing on stackernews. thanks for the discussion and consistency.

I say it's a political issue at this point. bitcoin-core must stop appearing to support the forthcoming "built on bitcoin" shitcoins.

see NVK's comments to Livera

The PR should be rewritten after public discussion at the big conference coming up.

arent nodes running filters to impede this propagation as a way to marginally discourage behavior of relaying transactions not accepted by the wider network? thats the entire point, it works. why wouldnt expanding those filters to include utxo-bloat spam work also?

when a peer is relaying a bunch of spam to my node, my node basically treats that peer like a block relay. not my business that he sends those txs to me multiple times and not his business i refuse to forward along transactions. in the event where multiple chaintips appear, I'd prefer to relay that the block with more of the transactions ive already validated in memory over the one where theres transactions my node hasnt validated

what do you mean by 'degraded manner' for the network as a whole?

other than a lower availability of these spam transactions in any given set of nodes' mempool, it makes little no difference for a node that is enforcing existing policy which is the network at large. it would only be degraded for the participants that want higher availability of arbitrary data prior to the spam transaction getting mined which is even a smaller set of people than the people who actibely upgrade software and/or apply patches.

the argument i see being made is that fee estimation could be messed up, but the thing is that fees are up to the node. their ability to calculate fees on their own criterion of what to bid against is none of anyone's business and certainly doesnt degrade the rest of the network. the node knows whats best, assumptions on what a miner "might" include in blocks dont need to (and shouldn't) be forced upon them.

Oh, I was under the impression Ocean uses Knots exclusively. But I guess it could be relevant for people who would like to relay transactions to Ocean, or a Datum template provider.

"They also use a different client already, so why should Bitcoin Core maintain something that they don't even directly use?" -?

ive been running Core with pull request 28408 (match more datacarrying) for well over a year. before the discussion for the PR was closed, at taiwan bitdevs we applied this patch together as a way to show our attendees how datacarrier works (or more like why it was broken). some users even continue to use that version of Core in their nodes, even applying the patch up through v28/29.

the users understand how arbitrary data still show up on blocks and still go through the process om their own. the patch itself works just fine, i dont see why datacarrier should be removed if it is working properly.

i followed the recent mailing list discussion and i dont have any strong opinions on the implementations that choose to bypass existing restrictions. doesnt matter that much to me, but the PR you submitted removes a functionality node operators use and im a bit lost as to why.

i dont buy that removing restrictions will reduce utxo bloat, intuitively it makes me think the situation would be made worse

i dont have a random fancy whitepaper to kick off discussion like the ML, i can only ask whats wrong with fixing it ?

on a positive note, at least theres acknowledgement that datacarrier is dysfunctional. best of luck with your endeavors to remove it, id even prefer that result compared to doing absolutely nothing.

What does that even mean?

Sure, I am not against OP_RETURN having no technical limit. What I am against is making the field unpruneable. If I want a limit on MY mempool's acceptance I don't want to have to fork the software. That's ridiculous. Also, keep the default where it is and let the spammers increase their OP_RETURN data carrier limit. That is more than fair. Spammers set their data carrier limits and do their worst. Others who disagree can run their filters and see who is more prevalent on the network.

Thank you to everyone on nostr who has been patiently explaining the technical reasoning behind considering increasing or removing Bitcoin Core's default OP_RETURN size limit.

Right, but #1 is quite rare, and #2 to a use case that people wouldn't use witness data for anyways, even if there is a point to be made about the use of OP_RETURN by far being preferrable to the use of witness data, it seems a red herring to suggest that relaxing OP_RETURN standardness policy will reduce harm by increasing the number of people who use OP_RETURN over inscriptions, when there is actually strong disincentives for doing that, and the only hope is for the altruism of users.

Supposed to be a spec update any day now maybe?

But why would people even use OP_RETURN when they can pay 1/4th the fees to get a witness discount? Doesn’t it seem like OP_RETURN is just hoping for goodwill (at 4x the fee cost) from people making unspendable outputs

So these stamp things my meetup buddies get all excited about will stop working at some point (unless counterparty is maintained), bougey castle built on sand?

Stamps use CounterParty under the hood, which simply switches to bare multisig once the payload goes over 80 bytes. With the proposed Bitcoin Core change to policy, or just considering relay reality, CounterParty could stop doing that. But afaik nobody is maintaining it, and the inefficiency is a feature for some of its users (stamps).

There's no point arguing over what you consider a moral argument then.