SatsAndSports

Into bitcoin, specifically cashu.

When I'm not working in the fiat mines, I'm into cycling and camping

Public Key

npub1zthq85gksjsjthv8h6rec2qeqs2mu0emrm9xknkhgw7hfl7csrnq6wxm56

Profile Code

nprofile1qqsp9msr6ytgfgf9mkrmapuu9qvsg9d78ua3ajntfmt580t5llvgpespz4mhxue69uhhyetvv9ujumt0wd68ytnsw43qgmeh84

Publishing to

relay.mostr.pub

Author Public Key

npub1zthq85gksjsjthv8h6rec2qeqs2mu0emrm9xknkhgw7hfl7csrnq6wxm56

Show more details

Last Notes

2026-10-05 17:02:36 UTC

de-slopifying protocol specs, not de-slopifying code
https://github.com/SatsAndSports/MONAD/blob/09d21f7e6fccac4b81219c1f67a7ae4c882f8a4d/docs/control-protocol.md

2026-09-20 14:53:36 UTC

- reply

Can you say more?
They don't approve of crypto that depends on inversion?
Or it can't be done in a way what's safe from timing attacks?
Or some other problem that I don't understand? 😂 (Yet)

2026-09-06 07:49:34 UTC

- reply

I want an app where I can swipe left on a reply here and see a few options to block a user
I block a lot when I go into replies. It's tedious to do though; should be much smoother and easier

2026-09-03 16:11:24 UTC

- reply

For those that have their own (local?) hardware for llms, how easy is it for them to sell access - via routstr - to their hardware when they themselves aren't using it?

2026-08-30 09:08:26 UTC

Unfollowed two npubs just now because they turned out to the generic big-blocker bots that we see so much during attacks on Bitcoin
Why do so many attackers (including BIP110ers) always run out of ideas and just randomly attack Lightning and use emotional MoE arguments?
Makes me more convinced that Lightning is the correct approach 🤣, and that we have the right incentives and game theory for Bitcoin
We're making an asset that nobody wants to spend, and which can be transferred with private instant settlement. This is how you play the long game, making it the world's MoE
https://blossom.primal.net/c00ff44d1a34976a76a54b740dff831dc0edd85750c6e861873e9922e3bc0fc1.jpg

2026-08-30 08:30:05 UTC

- reply

I don't want to be rude, but:
Bitcoin is following the game theory that I described. That's a good thing. That's why we had to win the blocksize war
Do you expect your long piece to convince me to ignore Bitcoin's incentives?

2026-08-30 07:32:52 UTC

- reply

"You cannot build a monetary system by treating the money as too sacred to use"
Well actually, this is the plan for bitcoin, and it's the right plan
It's the most ambitious plan
It's the only way for bitcoin to be the world's MoE
We make an asset that nobody wants to spend and which can be transferred easily and quickly with final settlement (Lightning)
If you think that contradicts the "world's MoE" goal, think about the game theory some more

2026-08-27 08:22:34 UTC

- reply

If you can't go --offline, maybe close channels before shutting down?

2026-08-14 15:30:08 UTC

- reply

I guess I was a bit repetitive, and I wrote too much. I'll be shorter:
Did you *want* BIP110 to activate? (Your preference)
Did you think it would get the necessary support? (The preferences of others. Game theory, ...)
I guess your answer is "Yes" to both, but I'm curious which of those two - if any - you would be willing to discuss with me

2026-08-14 07:53:45 UTC

- reply

Hi. I hope you don't mind me replying, but I think you're misunderstanding what happened with BIP110
(I enjoy following you, as I feel that you are different from many bitcoiners here on Nostr, and it's useful to follow different perspectives)
The big miners didn't really *reject* BIP110, they simply ignored it. They just kept mining Bitcoin blocks as usual. Dathon Ohm lied when he said the big miners did a "secret hard fork".
Some users configured their nodes to reject Bitcoin blocks, and therefore it's no surprise that they ended up on a different chaintip; sorry if this is uncomfortable to read, but it's true
BIP110 was harmful to Bitcoin's monetary purpose. It would have made it more difficult to run a node, by forcing data into the UTXO set; and that's the worst outcome for node decentralisation
The Knots and filtering movement is harmful to mining decentralisation, as it makes it difficult for small miners to see what's going to be mined. The "Tolerant Minority" fought back, to defend decentralisation, by helping small miners to see all the fee-paying transactions; they did this by relaxing their mempools to relay more transactions
So, it's good that BIP110 was ignored by Bitcoin. And the BIP110 leaders told many lies about "game theory", as well as generally being egotistical maniacs

2026-08-11 07:28:11 UTC

- reply

"attack"
The Bitcoin network did literally *nothing*. It didn't even notice BIP110
No URSF, no invalidateblock.
Miners didn't make any change to their templates, or their signalling code
Bitcoin didn't defeat BIP110, it ignored it

2026-07-16 12:29:07 UTC

- reply

Philosophy is cool and all, but if the hashrate falls to very low values in the future, we're going to have to be pragmatic about the security budget
I love the idea of Ark as a 'Channel Factory', allowing billions to have fully sovereign Lightning nodes. However, if Ark is *too* efficient in this case, then a typical block might have only one transaction!
(By the way, that's partly why I'm currently against CTV; I want Ark, but I don't want it to be *too* scalable; I want many medium-sized Arks, not one mega-Ark)
On balance, I think it'll all be fine and there won't be a problem with the security budget. But there could be a problem, and that problem could eventually be fatal. So I like to think about it
The article discusses Runes, but I think it dismisses them too quickly. The Lightning network could be extended to fully support Runes (no soft fork required), and it's possible (but admittedly, very unlikely) that one of the Runes becomes very valuable. As many Runes 'currencies' have tail emissions, it's possible that they could provide the right incentives to miners
Anyway, there's always 'demurrage', a soft fork to apply a tax on old UTXOs, which would motivate people to move their coins more often and create. The rule could be that, when spending a UTXO older than X years, at least Y% of the outputs must be anyone-can-spend outputs that are locked to a few years in the future. Such outputs are equivalent to the block subsidy in practice

2026-07-13 15:38:11 UTC

- reply

That's too vague
The wording should be explicit about calculations, e.g. the hash rate in a 2016-block difficulty-adjustment window

2026-07-13 13:47:05 UTC

- reply

Liar

2026-07-11 14:22:34 UTC

- reply

The plebs love community so much because they don't know how to form their own opinion, they need a leader to tell them

2026-07-06 14:18:39 UTC

- reply

I love K2.7. I've used it very heavily for a few weeks. They only reason I don't use it exclusively is that I have my GPT subscription and hence no marginal cost of using GPT
Kimi seems better than other models at noticing opportunities for reusing code
When I've done work in Kimi, I like asking GPT to review. And vice versa
TLDR: I love Kimi
I haven't used Opus 4.8 so much, due to the cost. The last Opus that I used heavily was 4.6, because I was able to use it within OpenCode

2026-06-29 07:42:06 UTC

- reply

I think both parties need to have a cashu wallet set up (with compatible mints?)
Then, when you press the zap button in Amethyst, you can choose to send by cashu or lightning
Worked for me to nutzap Vitor
https://blossom.primal.net/7157af01a4823718df26f39fdf61354c49c61b4eca566d6a8798e25830b42712.jpg
https://blossom.primal.net/804582ca10d57393bf8fdba5e8ee355addcb2a5b69c4520c74db6264ec058f83.jpg

2026-06-26 22:09:19 UTC

- reply

I just sent my first nutzap. Great to see it working

2026-06-26 20:33:37 UTC

- reply

.. PS: I should add that this kind of thing might work if you have some expert humans in the loop somewhere, for example to fix or rewrite the spec. But this person is proposing just giving exclusive responsibility to the AI for everything, to maintain existing crappy and complex systems

2026-06-26 20:19:04 UTC

- reply

Yes indeed, I agree. I love it and am looking forward to it gradually being adopted

2026-06-26 20:17:10 UTC

- reply

I'm drafting a system I'm calling MONAD. It's kinda like Tor, where you select relays and route your traffic through them using 'onion routing'.
Anybody can run a relay, and the users pay the relay operators for their service. The payments are bitcoin micropayments using cashu, using our @npub17fz…9yxv 'spilman channel' system for very efficient payments.
This repo is quite out of date; I hope to push my latest code in a couple of weeks when it's ready
https://github.com/SatsAndSports/MONAD

2026-06-26 15:41:50 UTC

A 'Senior Principle Engineer' in my fiat job thinks that the role of AI is to infer the spec from our existing codebases (they are unmaintainable, underspecified, untested, human slop), so that every time a new 'vastly superior' model appears we should ask it to rewrite the code from scratch using this inferred spec as the guide
#NGMI
"... extract a spec (product, engineering) from an existing codebase, force an isolated AI agent to rebuild it from scratch, and measure the divergence. The goal is to discover the minimal codebase practices we must adopt today so that when vastly superior models release tomorrow, we can confidently hit “re-generate” on entirely AI-generated codebases and guarantee the output is strictly better."

2026-06-26 08:09:26 UTC

- reply

On Twitter, I'm unfollowing/muting people who interact too much with BIP110, no matter which side of the argument they're in
While I agree with you, I might have to temporarily unfollow you too, for giving it too much oxygen 🙂

2026-06-24 17:54:27 UTC

- reply

True.
But I'm still going to block that account myself, removing it from my feed, because it's retarded

2026-06-23 08:20:20 UTC

- reply

... and when I ask it to check for updates beyond 12, it says "your software is up to date"

2026-06-23 08:18:12 UTC

- reply

I'm on EMUI 12.0 on my Huawei phone.
(I'm not sure if that answers your question though)

2026-06-22 09:36:27 UTC

- reply

The NIPs repo should be forked and given a new name (PINs - Proposals to Improve Nostr) and new maintainers.
They should follow the same process as used in the BIPs repo; in particular copying the role of the "BIP Editors"

2026-06-22 09:11:56 UTC

Trying to ban myself from working on freedom tech today, as I've been neglecting my fiat-mining obligations
I've been obsessed by my open source stuff, because it's much more fun and important, but I need to do other boring stuff to pay the bills

2026-06-21 20:08:37 UTC

- reply

I think others will do one, better than me, before me 🙂
And I have plenty of other stuff to do

2026-06-21 12:19:42 UTC

- reply

The channel factory idea doesn't require any particular extension to Ark. It's something that could - in theory - be done today
I think most of the code changes would be needed in Lightning, not in Arm
My guess is that we'll need to see more confidence that "basic Ark" works well, and that we have robust libraries and implementations and then the channel factory idea will catch on

2026-06-21 09:15:57 UTC

I think I finally fully understand Ark, and will try to explain it here:
(The swapping from the old round to the new round was what I didn't fully understand until I asked AI a few questions this morning)
Lightning already shows how two users can share one UTXO; both parties have a pre-signed transaction that they can broadcast at any time to spend the onchain 2-of-2 UTXO. That transaction spends that one UTXO and creates two new UTXOs which give each party their balance.
In Ark, it's basically the same, but with any number of users. The onchain UTXO is an n-of-n multisig instead of just 2-of-2. All parties have the necessary transactions which they can broadcast at any time. So every user has 'unilateral exit', they can broadcast these transactions at any time and get a single onchain UTXO with their balance belonging just the them.
These are the VTXOs (Virtual UTXOs). You can exercise your unilateral exit at any time by broadcasting your VTXOs.
(Pedantic detail that you don't really need to know: if there are 5 users, it's not a single transactions that spends the 5-of-5 *directly* to five different UTXOS, one for each of the five users. There is a tree of transactions, and each user has a copy of the *chain* of transactions that are necessary to get their balance out to a single UTXO under their control)
It's possible to receive payments at any time from another Ark user. But it requires a bit of trust (because the Ark Service Provider [ASP] and the sender could collude to take payment money that they sent to you) and therefore I won't discuss it in detail. Ark doesn't use the cool Lightning tech for instant settlement with commitment transactions. Therefore, I'll ignore this slightly-trusted part of Ark, and I will focus on the fully trustless parts, i.e. where Ark users have unilateral exit
If you already have 1000 sats locked up safely in one 'round' onchain, and you receive another 500 sats and you want those to be locked up safely, then you will need to take part in another round. This is where things get really interesting, and this is the bit I only just fully understood today ...
The ASP creates a new 'round', i.e. a new multsig output onchain that includes all the users who wish to take part. In this round, you will be assigned 1500 sats. i.e. you now have unilateral exit allowing you to take 1500 sats
But you still have the VTXOs from the first round, and so it seems like you could implement both exits and thereby claim 1000+1500 = 2500 sats, stealing 1000 sats from the Ark Service Provider
The solution is a 'forfeit' transaction. The ASP won't include the 1000 sats in the new round unless you first sign a 'forfeit' transaction and give that signature to the ASP. This gives control of your original 1000 sats to the ASP; if you broadcast the original VTXOs, then the ASP can use the forfeit to claim those 1000 sats for itself. There is a timelock in the VTXOs, in order to give the ASP sufficient time to broadcast the forfeit transaction
The forfeit therefore protects the ASP, because it stops the user from 'double exiting'. There can then be multiple on chain 'rounds', and you have a balance in all of them, but you are practically able to access only one of them [the latest one]. 'Your' money in the older round UTXOs isn't really yours any more.
But we must also protect the user! You, the user, don't want to forfeit your balance in the 'old' onchain UTXOs before the new 'round' is confirmed on chain. The solution here is 'connector outputs'; the forfeit transaction depends on outputs created in the new round and therefore the forfeit is ineffective until the new round is confirmed.
So now both the user and the ASP are protected. The user has a balance on-chain in the 'old' round, with full unilateral exit via their VTXOs, and they can trustlessly and atomically 'move' that into a 'new' onchain round. It's not instant, because the new rounds need to be confirmed on chain, but it is unilateral exit
So Ark is great at scalability, but it has a few downsides for the various parties:
It's not private
If you insist on full sovereignty, i.e. you don't trust the ASP, then Ark is slow like on-chain. If you want instant trustless final settlement, then Lightning is still the only option
From the ASP's point of view, they have to lock up a lot of liquidity. If a given user has a balance of 21,000 sats and there are five rounds with that balance, then the ASP actually has to lock up 105,000 sats on chain. Each round therefore has an expiry time built in, where all the funds go back to the ASP after that expiry time; this motivates all users to take part in a new round - or exit or otherwise spend their funds - before the expiry.
This sounds like I'm being quite critical of Ark. It sounds like I'm saying that it's as slow and as non-private as on-chain, and the only advantage is scale because many users can share a single UTXO.
However, this is where Lightning comes in again. Lightning shows how you can take a slow and transparent system, and then build private instant settlement on top of it
In the vision of 'Ark as a channel factory for Lightning' that René Pickhardt and others have been talking about for a couple of years, everyone can have a full Lightning node. They haven't channels with other people, doing (blind) routing over the Lightning network. They'll be paying for preimages in the usual way. They'll be sending 'commit transactions' over and back in the usual way. Fully Lightning in every way, no compromises. In this vision, everyone gets private instant settlment because they directly use Lightning
The subtlety in this approach is that, instead of Lightning channels being backed by conventional already-confirmed on-chain funding transactions, the funding transaction that backs the Lightning channel is instead an Ark VTXO. You and I can set up a Lightning channel without broadcasting that funding transaction; we are both satisfied that either of us can - at any time - broadcast the Ark VTXOs to get the funding transaction on chain. This allows us to do all the Lightning stuff *as if* the funding transaction is already on chain.
In this context, you would have to 'exit' twice in order to get your funds. The first 'exit' is the Ark exit, where you broadcast the VTXOs in order to create the 2-of-2 funding transaction for the Lightning channel, and then the second exit is where you broadcast your latest Lightning commitment transaction in order to split the the 2-of-2 into the final on chain balance for you and for your channel partner
In the 'channel factory', Lightning is still the Layer 2. All payments fully go through Lightning, giving us private instant settlement. Ark is like 'Layer 1.1', offering a wrapper over Layer 1 that is still slow and somewhat transparent, but which allows us to scale up the number of users that can fit on chain

2026-06-19 12:00:15 UTC

The British sense of fun around elections is great. This is a genuine photo from last night of the UK's likely next prime minister with other candidates for the seat that he has just won. In every election, fun candidates run against the high profile politicians
https://blossom.primal.net/0f8990ffc844791f1b2a2c079b59d57c115659575c3868357b387e9af1f265f9.jpg

2026-06-18 19:53:15 UTC

I ran twice today. 7.5km each time
It's nice to suddenly be addicted to jogging again

2026-06-17 13:58:54 UTC

- reply

I learned about cryptography in uni in the late 1900's
Back in my day, RSA and MD5 were good enough for public key crypto and hashing respectively

2026-06-17 12:44:05 UTC

Great story
#nevent1q…ss3c

2026-06-16 22:00:12 UTC

I'll go to Bitdevs tomorrow. I missed it the last few months, sometimes from laziness and sometimes because I was out of town
Looking forward to it!

2026-06-16 17:54:45 UTC

- reply

Adam Smith was pretty smart, but he got a lot of the history wrong.
He was wrong to say that barter was typical. He didn't have access to the modern anthropological research.
He was writing in the late 1800's and was therefore, understandably, speculating on what seemed reasonable to him as he didn't have any good data to go on.
Of course, my point doesn't really address your point; you make a good point I guess. I'm just taking this opportunity to go a little off topic and ask everybody (not you, specifically) to be more nuanced in their research. Saifedean Ammous also makes embarrassing historical errors in his The Bitcoin Standard, and he doesn't have the same ignorance excuse that Smith had 😀

2026-03-21 13:33:32 UTC

- reply

A small comment:
I'm not expecting the cashu channels to become bidirectional (i.e. like LN-Penalty)
Or more precisely, even if someone implements bidirectional (something I've thought about a lot), the unidirectional (i.e. Spilman) variant is still a lot simpler and more efficient.
The unidirectional version doesn't require a round trip per payment

2026-02-25 20:48:06 UTC

- reply

I couldn't get it working when trying Numo with a friend
Is cashu.me supposed to be able to tap-to-pay?
(I guess I just need to configure something related to NFC on one or both phones?)
My friend's Android has cashu.me, installed via Chrome as a PWA.
I installed Numo on my phone; a Huawei P30 Pro (quite old, but it has NFC). I entered 16 satoshis on the green screen, and then pressed 'Charge'. The black and white screen with the QR code and 'Scan or tap to pay' came up
With cashu.me open my friend's phone, we put it on top of my phone. Eventually, I got asked to choose between one of two options (If I remember correctly, something like 'Cashu Payment Service' and 'Phoenix ...'). I selected the Cashu Payment Service and then I got this screenshot
I couldn't get any further, either by touching this on my screen, or by moving our phones around.
https://image.nostr.build/6cebb2cb9bfdc2a5f56346aa129508129b9f4f68f7f1733253494ffa5e8c31c4.jpg
The NFC settings on my phone, the one running Numo:
https://image.nostr.build/898ad255c945ffbf95a0de4eb4882ad9dcf86a6bf0c0c0eb3c0112195a2dc6ae.jpg

2026-01-19 17:11:24 UTC

Next step in the Cashu Spilman channel system is to redesign the backend to make it easier to plug in any storage system that you like, e.g. sqlite, nostr, in-memory.
I want to wrap up the functionality into easy-to-use high level functions, such as 'validate_payment', in order to make it very easy for service providers to start accepting payments via these Cashu channels. Some of those functions will need efficient ways to reach out to state management systems, but I don't want to hardcode one particular system into this library.
The core code will stay in Rust for now, as that can be easily exposed (e.g. via WASM) to other languages. And I'll probably write these "bridges" for TypeScript [for continued use within the Cashutube blossom-server] and Python.
So here's an LLM description of what I'll likely work on this evening, although I expect I'll want to convince the LLM to change some of the details of this plan before executing:
== LLM description: ==
https://image.nostr.build/934bca319bd48de08f60c3d955ccbe2eaa7e89307b0f26a39721219e456939b8.png
#nevent1q…54qy

2025-10-12 08:01:27 UTC

I've started lurking on X in recent weeks, to see what the main Bitcoiners are saying, after a few years of totally ignoring X. Such low quality in the replies
I'm using this a lot:
https://image.nostr.build/903668267b510fbde5414e89b8c8f09f41faa89b9b1445dda249023e05688266.png

2025-08-20 09:03:12 UTC

- reply

In this message, I'm not going to try to continue the debate (directly). I just want to say a few high level things that might help. I'm still curious and I want to be able to have an open conversation with anyone, including you, in the future
I'm quite open minded about all of this still, and I haven't ruled anything out. Maybe I'll be Knots's biggest fan in a few weeks. On the other hand, I'm not even sure yet what my ultimate goals are (what is spam? do we want to suppress it? what's the most effective way to suppress it? how does this interact with other important issues such as miner centralisation?)
I had ignored Bitcoin for a few years, and I only got heavily into Bitcoin news again about six weeks ago. So I have had a lot of catching up to do. I've been on vacation for those six weeks, so I had a lot of time to catch up on many articles and podcasts
I finished watching the rest of that Bitcoin Mechanic video. None of the arguments he presented were new to me. Every point he made, even the smallest ones, were points I had heard in recent weeks. I'm not saying they are bad points, I'm just saying that I've already done my homework. I might be wrong in the big picture, but I have been doing my homework on these topics 😃
I look forward to continuing to learn more, from you and others, about the actual goals and incentives and game theory

2025-08-19 21:12:02 UTC

- reply

anyway, Bitcoin Mechanic completely agrees with me 😃 and therefore I don't need to watch any more of that video.
From 9m08s to 9m42s he says exactly my point: that the only way to discourage large OP_RETURNs is to punish miners who mine them, and that the only way to punish them is to delay propagation of those blocks.
My suggestion to the small-op_return folks is to put that idea on steroids: refuse to propagate any block with large op_returns, and "hide" that block within the node. That block is only "released" when a small-op_return block is mined on top of it later.
This is the obvious way to maximize the propagation-punishment while staying within consensus. That punishment is the main weapon available, and therefore it should be utilised to the maximum by those who feel strongly.
(As I mentioned elsewhere, I'm not sure I'm strongly against large op_returns; I'm just trying to help think through the options)

2025-08-19 20:54:31 UTC

- reply

Bitcoin Mechanic is talking in bad faith. At 7:40 he says:
"it's obvious that (people skeptical of the current Knots approach) ... betray an agenda to make Bitcoin more conducive to spammers"
He can't expect to be taken seriously when sharing videos like that, where every opponent "obviously" has a "pro-spam agenda"
(I haven't finished his video yet, but I'm finishing it now)
Some people who advocate for large OP_RETURN limits might be naïve. They might be brainwashed. They might be idiots. But if he says they ALL of them have an evil agenda, then he's not credible
I want a calm, non-paranoid, discussion based on expert understanding of the goals and the trade offs and the game theory

2025-08-19 20:32:38 UTC

- reply

I'm watching the Bitcoin Mechanic video now. I think I'll have a few comments to share when I'm finished watching it. It's a bit frustrating because I feel both sides (ignoring those individuals who are acting in bad faith) are closer to each other than they realise
I don't watch the Bitcoin University channel any more. I've watched many of his videos on multiple topics. He rambles emotionally and doesn't appear to really understand the technical details and the game theory

2025-08-19 19:21:09 UTC

- reply

The more I think about this, the more convinced I am by my idea to delay propagation 😃. #Knots #Spam
Trying to censor these transactions in the mempool will just delay them a little and will transfer money to the permissive miners. Basically, not much good and a bit harmful.
If the goal really is to minimize large op_returns, I want to see a credible proposal that will *incentivize* miners to keep those transactions out of the block. We can't *realistically* stop the permissive miners from seeing these transactions, so instead we can encourage them to keep then out of the block (via delaying propagation of their block)
If my proposal isn't good, then I'd like to see a better one. But I don't think the current Knots approach is a serious approach
(And also, I'm not even sure that op_return limits, even if everybody enforced them, are really the right approach. I'm more concerned about the size of the UTXO set

2025-08-19 16:46:32 UTC

- reply

Do you have a point?

2025-08-19 14:41:44 UTC

- reply

By that logic, Knots is pointless.
(For simplicity, I'm just talking about op_return here. I accept that Knots has other features too, but I'll ignore them for now)
The consensus rules aren't going to change, and miners will include large op_returns.
In fact, the only people that gain from (attempted) censorship is the big miners, as they get more fees via their 'dark mempool' approaches . That's why I suspect that some of the support for Knots is coming from spammy miners.
Anyway, good point about Foundry's advantages now
[As I said, I have no objection to large op_returns, I just find this topic very interesting to think about in terms of the game theory]

2025-08-19 13:47:40 UTC

- reply

What percentage of (important) nodes do you think is sufficient for Knots to win?
51% clearly isn't enough, as a small number of 'permissive' nodes is sufficient to route the spam around the Knots nodes

2025-08-19 13:44:17 UTC

- reply

If the Knots community is serious about discouraging large op_retums ('lops'), their nodes should implement what I call a "treacle-fork". It's not a hard-fork, but it puts maximum pressure on miners who include these 'lops' to encourage them to stop mining lops.
When a Knots node sees a mined block that includes any lops, the node should NOT (immediately) forward the block to other nodes. It should pretend that it didn't see the block.
I know you might think this will cause a hard fork and split the chain. However, to avoid a hard fork, I would allow that whenever a 'lop-free' block is found, Knots will accept and forward that block *and it will also (retrospectively) accept+propagate all the ancestor blocks*, even if those ancestor blocks contain lops.
With this system, Knots still follows the existing consensus rules, but miners will see a propagation delay if they mine lops. Miners who include only small op_returns will see their blocks propagate more quickly and therefore will be rewarding by winning the race more often.
Miners who include lops will see their confirmations stuck temporarily, as if they are stuck in treacle.
As a contingency to avoid falling too far behind, if there are three consecutive blocks containing lops, perhaps Knots could just give up
I should close by saying that I'm not personally strongly against large op_returns, I just find it interesting to think about the best way for nodes to apply pressure against transactions they don't like. It's a fun mental exercise!