Will it really? I thought that's the entire point...that it shouldn't propagate spam to peers, until the spam gets mined, of course.
Discussion
> until the spam gets mined of course
Aha! This is the critical point. I don't think we can prevent miners from seeing the spam, but maybe we can discourage mining of those transactions.
People who are against large OP_RETURNs should focus on how to punish the miners that include those transactions. One option is to delay propagation ot those blocks. Delay, not reject, as we don't want to split chains
What do you think? And apologies if you've seen this idea already!
I think that idea was already discussed and debunked as being harmful for small miners by putting them at risk for having their blocks replaced: https://gist.github.com/instagibbs/c436110890ab25aa9997b13c2270d5ce?permalink_comment_id=5568544#gistcomment-5568544
Doesn't matter to me, I just think the Knots extra config options are useful. They don't break consensus so idk why Core fans care so much about people running Knots or btcd. Maybe I'm too midwit to understand
Thanks for the link. To make sure I understand:
Large pools can kinda give themselves a "head start" when they find a block, as they can immediately start on the subsequent block before the current block has propagated to the other miners
Small pools don't get this advantage, as they are less likely to get mine two blocks in a row.
Small pools are more dependent on fast propagation (for them to see new blocks, *and* for their new blocks to be seen by other miners) than large pools.
All good so far?
Maybe we should increase the block rate from every 10 minutes to every 60 minutes, in order to decrease the impact of propagation delays
yes
nostr:note18hkztahjp3nfle7le06u7wmw9uryyd2quy4m536jtpne7du58kqs9z8gdz