Yes exactly, not only the mempool but bandwidth used by every node to relay the transactions.
I'll go back and fix the typo but the idea is that if you broadcast a transaction it should have a significant chance of actually being mined.
I'm not sure I would agree that one or another is "primary" protocol-induced. They are all important to the protocol (the process of mining, for example, is certainly part of the protocol), but they are different and interrelated. They're all per-kb in the current implementation.
gotcha gotcha. I think I'm picking up what you're putting down.
Basically, you're saying that if some kind of algorithmic floating number were to be implemented, we would have to find a way to harmonize it across those 4 different elements. Well, really, elements 1,2, and 3. What miners decide ( #4) has to be >= 1,2,3 .
And changing the fees would require recompiling the source code.
I would imagine it would work something like this:
When a block is mined, a new piece of data (activity) is stored in the header. This piece of data (calculated by the miner) is something like
activity = (sum of number of transactions in n recent blocks) X (total amount in transactions in n recent blocks) / (n recent blocks)
We'll have to figure out exactly what the function X is.
When new block is made, every miner can validate that activity value was properly calculated.
(1) When determining whether to propagate a transaction, the daemon can use the most recent activity value in its calculation of minimum fee.
(2) When determining whether to include a transaction, the mining code can use the value in its calculation
(3) When making a transaction, simplewallet can use the activity value to make its calculation of minimum fee.
Sure, we've added more data to each block, but I think Monero is fond of the notion of increased protocol utility vs. concerns over blockchain size. And yes, Monero is sentient and can be fond of things.