Topic: Valid, but non-transmittable. Internal Node Logic can stop spam transactions. (Read 1256 times)

So... people can override the node default to send these dust transactions,
Is it possible to have a client that still doesn't have to accept them?

They don't. Stock nodes will not relay these dust transactions.  Unfortunately, a lot of people have overridden the defaults, and the abuse we're currently seeing is the result.

If you're unhappy about it, go see what pools are mining them, and prod their hashing customers to ask their pools why they're mining abusive spam.

Actually, whether or not we can even discuss that first probably depends on this process.  

Localizing and penalizing nodes that broadcast spam might also sound like a good idea at first, but it's easy to circumvent by creating new nodes, or hijacking tools to take advantage of someone else's resources to broadcast a transaction.  I.e. https://blockchain.info/pushtx

I'm of the belief that some types of spam can be definitively and mathematically identified, so the first issue to focus on for the moment is:  What criteria would definitively identify a transaction as spam?  

Keep in mind that the potential for false positive blocks is not permissible, and any changes that caused them would likely be rejected (and should be) by the devs and community

thanks for good explanation. I think Bitcoin spammers best cared by another mechanism who will shutdown nodes which seem to spamming at least temporarly. smtg like X node did total H amount transaction under Y amount time and the percentage per transactions was below 1000 satoshi and he sees and alert box, spamming harming our eco so you gotto wait Z amount time...
just thinking on it little bit....

It's curious that even with a dust limit of 5430 satoshi's, the network is still getting spammed to no end.  https://blockchain.info/address/1SochiWwFFySPjQoi2biVftXn8NRPCSQC

Nodes that receive these transactions will happily send out "inv" messages and relay them to other nodes, who respond with "getdata," also confirm the transactions as valid, and broadcast the transactions to everyone else.  What if nodes had further logic to understand when these types of transactions are being created?  Since they are essentially never going to confirm and are zero cost, it doesn't make sense for every node to be forced to broadcast them to begin with.  

The solution won't necessarily be straightforward.  A simple check such as [(sum of inputs)/(number of inputs) >5430 = true then send] might sound promising, but in practice it doesn't cut it because a spammer could just include one or several much larger outputs back to themselves as part of the overall transaction.  Additionally, talking about any kind of limitation on the types of transactions that can be sent out strays into dangerous territory: no one wants to cripple the network.  

But is it possible to nip this type of spam in the bud or are we stuck with it for all eternity? I'm imagining a future where dozens of unconfirmed transactions arrive into my account by the minute.