actually, now that I think about it, it may be even *better* than that. Since utreexo nodes can reconstruct the proofs from blocks themselves, they probably *don't* need the proofs to be submitted alongside the blocks. Just give them the blocks themselves and they can create the proofs on their own

> requires a bunch of network calls

Do you have more details on this? It looks like you are saying utreexo nodes make *more* network queries than normal nodes. What additional calls to the network do they make?

> more proofs to verify a block

Utreexo nodes receive slightly more data alongside blocks (i.e. they receive additional merkle inclusion proofs), but (1) not much more (2) the extra data is ephemeral: after validating the proof, they may discard it, as, upon storing the block, they can reconstruct the proofs upon request from other nodes that may ask them for it in the future. To me, that seems worth exploring! Maybe it's *more* efficient

done*

Efficiency

To turn your question around, what's the point of a 12GB utxo set when 12KB gets the job down?

I've been playing around with Floresta a lot lately, reporting bugs and testing what it can do

I often see it discussed as a solution for storage-limited nodes: you can prune blocks *and* prune the utxo set

I'm starting to think it can do more.

Specifically, I want to experiment with running it *with* a full blockchain, while *not* storing the utxo set. Spam has grown the utxo set to 12GB+. What if utreexo/floresta fixes this? What if you can have a full archival node, but your "utxo set" only uses a few kilobytes?

https://github.com/vinteumorg/Floresta/

Matthew Krabber is at it again!

https://video.nostr.build/36705837796aef6233e1b5031d6d0a69327275da4abdaa17013e2f6a099294c4.mp4

0.06% seems clearly different from "nothing"

It seems strange to stop doing a profitable thing because of unfounded fear. Do you find their behavior strange?

Have fun staying Core

I have heard that argument too. But look at the data: two pools -- Mara and CKpool -- cited a higher orphan risk in their explanations for why they stopped ignoring the subsat tx filters.

Mara's post on this: https://x.com/PortlandHODL/status/1958520763083825640

CkPool's post on this: https://x.com/ckpooldev/status/1957235824451559746

Despite whatever peering strategies they are using, they both decided to construct blocks with fewer filtered transactions in them. I would be very surprised if that wasn't because lots of filtered transactions equates to slower block relay.

Wete they complaining about greater *risk* of orphan blocks rather than an increased *rate* of orphan blocks?

Librerelay and bitcoin knobs are third and fourth options

I think there are a lot of sybils aka knots bots that got spun up over the last few days, and many of them turned off yesterday for some reason -- maybe out of vps credits

Common enough that Mara Pool and CKPool both stop mining subsat transactions because doing so increased their orphan rate too high.

Mara Pool's post on this: https://x.com/PortlandHODL/status/1958520763083825640

CKPool's post on this: https://x.com/ckpooldev/status/1957235824451559746

> Have you intentionally left out the UTXO bloat part?

I am only aware of one protocol that stores meaningful amounts of data in outputs (Stamps), and they have openly said that they do so in order that the data cannot be pruned. "Inviting" those people specifically to use op_returns -- i.e. the very people who have said they don't want it -- seems like a poor reason to relax the filters. Instead, it seems like it will just invite more op_return spam by people who previously wouldn't have done it at all.

> what about miners taking the junk txs directly from the issuers?

Miners who include privately-submitted transactions in their blocks have a higher orphan rate, because the rest of the network propagates that block more slowly than blocks containing only publicly-known transactions, as nodes have to download/validate the privately-submitted transactions, which were not already in their mempools. The extra time they spend doing so gives that miner's competitors more time to mine/propagate a competing block at the same blockheight. This is part of why private mempools typically charge a higher rate: the extra cost compensates for the risk of losing money through an orphaned block.

Widespread mempool filters thus modify the economic incentives that apply to miners: they can certainly receive filtered transactions via a private mempool service, but their incentive is to make it cost more (which is what we antispam people want), and they may even refuse to do it altogether if it causes too many orphaned blocks. E.g. we saw Mara Pool and CKPool both stop mining subsat transactions because doing so increased their orphan rate too high.

Mara Pool's post on this: https://x.com/PortlandHODL/status/1958520763083825640

CKPool's post on this: https://x.com/ckpooldev/status/1957235824451559746

This is part of why I celebrate more widespread filters. It means spammers are more likely to use private mempools, which raises their costs, and results in more orphans for spam-friendly miners. Both of those are good things that I want to see more of.

I don't know if they have each other as peers. I do know that at least two pools have complained that ignoring the subsat tx filters caused them to lose money via an increased orphan rate. CKPool complained about this here: https://x.com/ckpooldev/status/1957235824451559746 and Mara Pool complained about it here: https://x.com/PortlandHODL/status/1958520763083825640

So if they *are* peering with one another it is apparently insufficient. The miners who *ignore* that peering (maybe Ocean?) and just broadcast blocks to the rest of the network benefitted by getting their blocks propagated faster, and winning more races. I want to see that play out again, but this time with inscriptions, and to that end I am excited to see the Knots count rise.

Re: bypassing the delay, whatever mechanism users opt for in order to bypass the filters, that very mechanism can simply be added to the filters.

Regarding pruning, relaxing the op_return filter does invite some increased usage of this prunable field, and that usage is problematic for many users: it invites more spam into their mempools.

I kept the receipts. CKPool post on the topic: https://x.com/ckpooldev/status/1957235824451559746

Mara Pool post on the topic: https://x.com/PortlandHODL/status/1958520763083825640

Tell that to Mara Pool and CKPool. They noticed that their blocks were getting orphaned more often when they ignored the subsat tx filters, and reimplemented them. The higher the percentage of Knots runners, the higher the likelihood this plays out again, but for inscriptions and op_returns

The filters work perfectly at their main job: keeping filtered content out of your mempool

When widely adopted they also delay the propagation of spam-filled blocks, which provides a nice monetary incentive for miners to ignore spam: ignoring spam = fewer blocks orphaned = higher income

The filters work perfectly at their main job: keeping spam out of your mempool

When widely adopted they also delay the propagation of spam-filled blocks, which provides a nice monetary incentive for miners to ignore spam: ignoring spam = fewer blocks orphaned = higher income