pull down to refresh
400 sats \ 5 replies \ @SimpleStacker 5 Sep \ on: Bitcoin is about money, spam has no place in the timechain bitcoin
So, I think what he's saying is that miners should be the ones to filter spam, not the protocol developers. He said that miners could be nudged to do that through education/persuasion, or through user behavior, which I didn't fully understand.
His idea is that users who make transactions start adding an extra output that goes to a 1 of N multisig that is addressed to spam-filtering miners. We bribe pools to filter spam in order for them to collect extra fees from such transactions instead of spam-transactions.
reply
I think the part I didn't understand is: I didn't know that you can address transactions to specific miners or types of miners
reply
reply
Rather than subsidize "white" miners in this convoluted way, why not have users donate to ALL miners by stuffing data into op returns at a fee rate high enough and with a mempool backlog large enough to deter non op return data utxo bloat (aka spam).
if spammers bid more aggressively, greater good minded users can use cpfp or other mechanisms to increase their own bid.
I doubt many users would want to use wallets that forced to donate to an anti spam fund like this.
But they might equally not want to donate to the anti spam fund the other way. And at least this way doesn't introduce a state attack vector.
reply
Adam back wants to shift utxo bloat control (aka anti spam aka censorship) to users / wallets, who would subsidize miners who block spam.
Blocking spam sounds like a good thing.
But can we really tell what is spam? Won't the jpegs just keep getting sneakier and sneakier. and it becomes a spy vs spy red queens race and opens a censorship attack vector to boot?
I agree utxo bloat is a problem but idk if this is a solution.
If wallet subsidies push data into prunable op_returns, maybe that's a good thing.
But
a) will users pay the extra fee, even if it's tiny?
b) will wallet maintainers be able to resist state address and mpubkey whitelists when this is inevitably attempted?
maybe accepting centralization risk of utxo bloat is better than centralization risk of opening wallet filters as a state attack vector.
reply