Nostr Web Client

arent nodes running filters to impede this propagation as a way to marginally discourage behavior of relaying transactions not accepted by the wider network? thats the entire point, it works. why wouldnt expanding those filters to include utxo-bloat spam work also?

when a peer is relaying a bunch of spam to my node, my node basically treats that peer like a block relay. not my business that he sends those txs to me multiple times and not his business i refuse to forward along transactions. in the event where multiple chaintips appear, I'd prefer to relay that the block with more of the transactions ive already validated in memory over the one where theres transactions my node hasnt validated

sedited 8mo ago

> arent nodes running filters to impede this propagation as a way to marginally discourage behavior of relaying transactions not accepted by the wider network? thats the entire point, it works. why wouldnt expanding those filters to include utxo-bloat spam work also?

I don't understand why you are saying this works. Clearly transactions are finding their way to miners over the regular p2p network. For what it's worth I also don't understand why this change is sold as company x needs this to post the data as op_returns. They should just do it now, because enough nodes and miners have these liberal policies already. Bitcoin Core should still adopt the relaxed policy to make relay smooth, and make it easier to use, because it reduces harm in terms of node storage requirements, but keep the option, so node runners like yourself can encourage building templates with non-data carrying transactions.

Reply to this note

Please Login to reply.

Discussion

Nyoro~n 8mo ago

apologies, my nostr-edit appears not not have made it to you: "arent nodes running filters to impede this propagation as a way to marginally discourage behavior relaying *blocks with* transactions not accepted by the wider network"

i think you mistake the occasional stunt by miners to throw random junk they choose to include in blocks as a failure of mempool policy. it'd be as absurd as to pointing to an empty block and blame it on mempool policy too

sedited 8mo ago

Thanks for reposting :)

My nostr client is really messing the rendering of this thread up right now. Maybe it's good to stop a discussion at some depth ^^.

My impression is the recent large OP_RETURNs are not a miner stunt. A stunt for sure given their content, but my impression is they get through by relay.

Nyoro~n 8mo ago

🤔, so which is it? you can have whatever impression you want but this works in a certain way.

are these larger OP_Return transactions successfully relayed through the network because a sufficient amount of nodes actively configured their node to do so (because Core or Knots wont do it out of the box save for Libre Relay and some very old versions) or are these transactions resorting to services like slipstream because the wider network wont relay them?

because if you're saying these transactions get through by a small subset of configured nodes relaying to one another, consider to extending that conclusion to nodes choosing to configure in another direction too 😅 and if you're saying these transactions had to be sent to the miner directly because the wider p2p network wont relay them, well...seems like you understand that filters work and that it costs something to get around them 🤷

sedited 8mo ago

Mmh, I think it is clear that if ~all nodes use the same policy a transaction has a tough time of getting through. Surely there is also a cost for getting around them too. But I think we've reached the point here where that cost is low, and the cost incurred by not adapting is bigger.

I also think it should be left configurable at least . Miners should get the choice of not having to include these transactions, meaning Bitcoin Core should allow excluding them from template generation. Similarly nodes relaying transactions to these miners should be able to exclude them to able to relay lower fee transactions that might get evicted otherwise if the mempool is full already.