Nostr Web Client

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 🤷

Reply to this note

Please Login to reply.

Discussion

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.