Quote from: becoin on July 10, 2011, 07:27:06 AM

The minimum transaction fee effectively is a mining pool 'tax' for all network users. I understand the need to protect against DoS attacks. However, what is the point of protecting against an attack if there is no attack? If you're not flexible, always keeping your shield charged to the maximum, it is just a waste of resources!

Repeat after me: There is no minimum transaction fee.

and then:

Repeat: The overwhelming majority of transactions are zero fee.

The software requires a for relay for transactions which the adaptive technical detection for DOS-attack-like transactions can't distinguish from an attack, and for transactions which are unusually burdensome (many kbytes of data). The adaptive detection doesn't depend on the instantaneous network status: Its can't easily because in a decentralized system there is no singular status, and if nodes disagree about the status the protection isn't effective (if its fail open) or it makes txn get stuck in unspendable limbo at random (if its fail closed).

Instead the adaptivity depends on the character of the transaction itself it's value, the time since its inputs were last spent, the size of the outputs, and the amount of data used to represent it. These are all factors which are directly relevant to a DOS attack because they objectively measure the effort it takes to perform the attack and the impact on the whole network of performing the attack. This is a usable criteria because it's objective and can be acted on uniformly by independent nodes.

Above the cutoff priority txns are handled in a priority oriented manner which gives the soft "only messes things up if there is an attack" behavior that you seem to think we lack. .... You only think we lack it because it actually works. Unfortunately, the soft behavior can only work to a limited extent because in order to handle things in a priority order nodes must have first undertaken the non-trivial costs of storing and forwarding the transaction so at some point the system has to simply say "No, I refuse to use memory for this, I refuse to use bandwidth for this". Otherwise the attacker can exhaust these resources even if non-spammish transactions always beat them into the blocks. If the threshold at which transactions aren't remembered (which makes them _very unlikely_ to go through) is too dynamic then you'll continually end up with transactions which are stuck in limbo polluting your wallet, and potentially polluting the wallet of the receiver if they happened to hear the txn.

These zombie unconfirmed transactions can end up like a spreading cancer, since their (or their change) will eventually get used as inputs as a last resort thus spreading the confirmation delays to additional transactions which would otherwise confirm quickly.

At yes, the setup is far from perfect for example because, unfortunately, a lot of new users make transactions which are technically indistinguishable from a DOS attack... and because the proper fee for DOS-like-txn depends on the current "value" of bitcoin, which changes in unpredictable ways.

On the flip side, the worst case for these newbie transactions is that it causes some users to have to pay a 0.0005 BTC fee per transaction sometimes. This is less than a penny. The gross burden on the disk space of full nodes to store the transaction (around 10 megabytes for a normal sized transaction, assuming 40k full nodes) is currently a similar cost. The fee structure also creates a nice opportunity to educate people about more pro-social usage of bitcoin (e.g. making all payments with zillions of 0.01 txn is unnecessarily burdensome on the network).

Certainly there is a lot of room for improvement, but whining especially whining which exaggerates and misrepresents the situation is not helpful.