OCEAN successfully delays spam transactions \ stacker news ~mempool

pull down to refresh

OCEAN successfully delays spam transactions

1220 sats \ 18 comments \ @Filiprogrammer 27 Apr mempool

24 hours ago the OCEAN pool mined this block: 0000000000000000000055167ff46b33e39e25510a096360a185d7e757595b0e The expected inscription "spam" was omitted from the block.

Hence these transactions are still waiting in the mempool 24 hours later 🤣 96c5a7ac2de62b1f910bdb68fc044f45f942c3c7f5830bd09746614f994c1bf7 7107e878078b0e9da48fd16863799a780f763b74f707d486ba6576402b3287f9 cb516ba8e87d2518844bf9f2ddeb47f5c49117460ed43d93c829cdc732d64afc ...

I just find this kind of amusing.

view all related items

110 sats \ 0 replies \ @nullcount 27 Apr

For now, the cost of excluding a high-paying txn is relatively small, and the virtue signal is comparatively strong. Maybe when fees account for 90% of miner revenue the desire to discriminate will be reduced.

Subsidies tend to distort all kinds of markets. How can blockspace be properly valued if empty blocks still pay 80% as well as full blocks?

Today, Ocean delays the inclusion of "spam" which might be tolerable to the market, after all, how quickly do you really need your JPEG stored on everyone's node?

The market for blockspace also permits a miner to censor non-spam and prioritize these "spam" transactions instead. If the market wants spam txns confirmed quickly, then all it takes is one pool (or an alliance of pools) with similar hashrate as Ocean to effectively negate all their efforts to delay spam.

10 sats \ 0 replies \ @seashell 12 Jun

Spam crying about confirmation while blocks sit half empty is pure comedy. That's not censorship, that's just miners with standards. Ocean filtering ordinals is based. Your 1 sat/vB monkey pic isn't entitled to block space. Fee market working as intended. Don't like their template, run your own pool. Bitcoin's permissionless for everyone, not just jpeg collectors. Real censorship would be protocol changes. This is just miners choosing not to subsidize chain spam. There's a difference.

67 sats \ 3 replies \ @denlillaapan 27 Apr

...and the miners thereafter didn't mine the spam...?

22 sats \ 2 replies \ @Filiprogrammer OP 27 Apr

No, because the overall fee to get into the next block was driven up by other transactions immediately after. Ironically, it was almost included—now it’s still stuck waiting in the mempool.

0 sats \ 1 reply \ @denlillaapan 27 Apr

So not censoring/filtering by just good ole fashioned fee pressure...?

0 sats \ 0 replies \ @Filiprogrammer OP 27 Apr

Yeah, but the transactions would have been included in the OCEAN block, if they weren't dropped due to the block template policy that the miner used.

It's technically not OCEAN who filtered these transactions since we are talking about a DATUM block. This means that the miner uses their own block template. In the case of this block, that miner was "Elektron Energy".

31 sats \ 3 replies \ @OT 27 Apr

Is that because fees went up after Ocean found that block?

70 sats \ 1 reply \ @Filiprogrammer OP 27 Apr

Yes indeed, that's what happened. And these transactions pay the lowest fee of 1 sat/vByte

10 sats \ 0 replies \ @OT 27 Apr

It's their own fault then

0 sats \ 0 replies \ @LibertasBR 27 Apr

This is an important context.

11 sats \ 5 replies \ @BlokchainB 27 Apr

So we are cool with censorship now?

231 sats \ 0 replies \ @optimism 27 Apr

If you're not, then make your own template with DATUM, or join another pool. The censorship resistance isn't established by pools or individual template composers being forced towards being inclusive, it's by the fact that mining isn't gatekept, that blocks are permissive and that there is a massive economical disincentive to reject a valid block.

Also, not mining a tx in mempool isn't censorship per se, it's policy. And although for a longer time, from a LN perspective uniformity in block templates was expected, it isn't sustainable and I feel like we've largely moved away from that delusion since full RBF.

True censorship would more look like this:

I post transaction A at height N
FreedomPool mines transaction A into block N+1.
CensorPool censors transaction A by invalidating block N+1 locally and instead mining block N+1b that doesn't contain transaction A, upon N
CensorPool also mines block N+2 upon block N+1b so everyone will pick that up as the longest chain
FreedomPool mines transaction A into block N+3, upon block N+2
CensorPool again censors transaction A by invalidating block N+3 and instead mining block N+3b, again without transaction A, upon N+2, and another block

... and so on.

131 sats \ 0 replies \ @anon 27 Apr

It takes a fundamental misunderstanding of how Bitcoin works to pretend this is censorship. They can increase their fee and any miner is free to mine them at any fee. Just like any miner is free to not mine them. It's not censorship at all. Is it censorship when miners put their own transactions or side channel accelerated transactions with low fees in blocks before mine? No. Is there some kind of rule about what miners have to put in a given block? No.

If you want to talk censorship let's talk the fact American mining companies are OFAC compliant and actively refuse to include transactions in blocks. Is that despicable and should we boycott those companies? Yes. Is it censorship? Not unless those miners are reorging the chain with a majority of miners every time an OFAC restricted transaction is included by a non-American miner.

This absurd conversation about censorship fundamentally fails to comprehend how Bitcoin works, where it gets its censorship resistant properties from, and what the execution of those properties looks like in action. It looks exactly like this. Learn about Bitcoin instead of being a sensationalist tool.

0 sats \ 0 replies \ @ken 28 Apr

You can't force a miner to include a transaction

0 sats \ 0 replies \ @BITC0IN 27 Apr

only if you're cool with forced speech

0 sats \ 0 replies \ @Filiprogrammer OP 27 Apr

Well, I personally was never a fan of inscriptions.

0 sats \ 1 reply \ @02c42fc294 3 May

So the transactions were not mined when there was spare capacity, the block was not fully utilized and the transactions linger in memory because other miners deemed them too low fee? Nothing here singles out ocean as a positive: they wasted block capacity, the lingering transaction will likely eventually still confirm, and in the meantime they float in the mempool and waste cycles of other miners trying to build a block template.

Ocean behaves just like any normal miner, foregoing transactions it doesn't seem valuable. It's only their cost function is changed, which in a distributed system may cause unexpected effects (heterogenous policies as an attack vector is quite common).

10 sats \ 0 replies \ @02c42fc294 3 May

Oh, and guess why the fees went up after the block mined by ocean: because it was not full, we wasted available capacity, kept the mempool full, and disoriented fee estimators...