pull down to refresh
342 sats \ 13 replies \ @Murch 4 May \ parent \ on: Quick questions about OP_RETURN? Quick answers here. bitcoin
Since transactions with larger OP_RETURN outputs or multiple OP_RETURN outputs are consensus valid, they will appear in blocks as long as they find their way to mining pools and mining pools choose to include them. Any nodes that don’t allow such transactions in their mempool will download them twice: once when the transaction is first offered to them by a peer, where they download it, evaluate it, and drop it due to their mempool policy, and then a second time when they receive the block announcement that includes the transaction.
Whenever nodes are missing transactions from a compact block announcement, they have to request the missing transactions which increases the latency until they can relay the block. The relay is delayed more when large transactions are missing. Nodes that run a mempool policy that is stricter than what regularly appears in blocks therefore use more bandwidth and relay blocks more slowly.
Slower block propagation benefits larger mining pools by increasing the number of stale blocks and delaying other miners in switching to the new chaintip. Bigger miners disproportionally win over competing blocks and the block author doesn’t suffer from the propagation delay when a block is found.
Whenever nodes are missing transactions from a compact block announcement, they have to request the missing transactions which increases the latency until they can relay the block. The relay is delayed more when large transactions are missing. Nodes that run a mempool policy that is stricter than what regularly appears in blocks therefore use more bandwidth and relay blocks more slowly.
For what it's worth, to people who are far more influential...
There is a growing 'army' of folks who want to run more restrictive mempool policies to 'kill the spam'. Anti-ordinals, anti-memecoins, anti-BRCs etc... This is preached nonstop over and over, just do 'x' and you can stop the spam. "It's your memepool do X" etc etc.
What some of these "educators" don't explain however... is what you just said. About increasing latency, delay, bandwidth, speed at which blocks are relayed, miner centralization etc.
People are free to run whatever they want... but some of the "influencers" in the space only tell half the story or don't explain some of the downsides. It's like 'do this it's good' but without explaining why 'that' may not be a great idea. Thank you guys
reply
good point
reply
Right! However, this is not a static situation as this is fully solveable with a relatively small amount of code: if people are truly serious about filtering, they could simply add a "purgatory" inside the mempool (or outside it, that doesn't matter) where all the crap lives that one does not want to relay or mine, but is still valid for (a) new txn inputs (where the new txns automatically end up in purgatory too unless the offending parent gets mined) and (b) compactblock reconstruction.
reply
wait, what are you talking about specifically? Is this a mempool policy? or something else?
my understanding is that a 'complete' solution does exist, the 'purifier' solution but of course it is a hard-fork.
reply
I mean: if Knots devs want to not lose performance on block validation due to the filters, this is solvable by not purging policy-offending txs completely, but - in the simplest form - flagging them as "non-standard" and checking for that flag, before relaying or creating a block template.
This would eliminate the downside of having to re-request all the txs again when you get a compact block or a package with a child tx in there and largely remove the filter-specific part of any block withholding issue too.
reply
many of the knots-people (not the developers but the people following them) seem to think that by 'filtering the spam' they can keep it off their node completely. they want no spam they want to be 'spam-free' so they run knots to keep the spam 'to a minimum'.
like "filtering their email inbox" is how it is explained
they don't understand they actually download the spam regardless.
and then when the alternative/nuance is explained they say "oh you're just malicious"! "you hate bitcoin!"
"you're corrupt!!!" which is not helpful obviously.
reply
True, and I think that that's a generic issue across nearly every facet of society that I am aware of.
However: one would think that someone running an actual pool using that software would understand the benefits of not having to mine empty block templates for a minute. The impact - no matter how small - is in the block template inclusion policy. If one were to claim that the greatest good is financial transactions even at a loss of income, then mining an empty block isn't cool.
edit re: the emotional appeal. That's where we're at as humanity... I have a little experimental locally running AI that I can ask to rewrite an email without emotional pitfalls. It actually makes sense to simply feed every bitcoindev list mail to it.
Project for the coming weekend lol.
reply
reply
Is there a corrolary to what you describe here?
Slower block propagation benefits larger mining pools by increasing the number of stale blocks and delaying other miners in switching to the new chaintip. Bigger miners disproportionally win over competing blocks and the block author doesn’t suffer from the propagation delay when a block is found.
For instance, if network is dominated (90%) by strict policy around spam. Do small miners/pool only including standard tx be able to propagate their block faster than the big pool mining non-standard OP_RETURN? In that sense, do we have a reduction in stale blocks for these small pools? On the other side, the big pools mining non-standard tx would also receive those standard blocks as fast as the other.
Can we say that the big pool could face the issue of getting orphaned blocks in the situation where a pool mines a block with only standard transaction propagating faster than their slower non-standard block?
reply
The outcome depends on how much of the hashrate is accepting the offending transactions. If both the majority of the network and the majority of the hashrate is rejecting some transactions, yes, the miners that include those transactions will have a greater delay for their blocks to reach other miners. This delay causes a higher stale rate, so the lenient miners would be more likely to lose blocks to competitors that can propagate blocks quickly.
However, if the majority of the network rejects some type of transactions, but a majority of the hashrate accepts those transactions I would expect the effect to present differently: miners are generally well-connected, and the miners with loser mempool policies would likely all be connected via the subgraph with the loser mempool policies. A miner publishing a block with offending transactions would see it propagated quickly to the majority of the hashrate. Meanwhile the minority of miners not accepting the offending transaction would be the only ones affected by the delay: they would be more likely to still find a competing block when the majority of the hashrate had already switched over to extend the chaintip with the offending transactions. I would argue that in this case, the delay actually helps the majority miners with the loser policy because it causes the stricter minority to waste hashrate, similar to a selfish mining attack.
So in short, yes accepting unpopular transactions hurts your block propagation if both the network and other miners don’t accept them. However, you may also be collecting more transaction fees that may offset the loss to some extent, as the propagation delay we are talking about would cause an effective revenue loss of around 1%.
reply