Well, now that thats all over, lets talk about something fun!!!
I've been trying to wrap my head around how to convert the fee calculation to something dynamic that wouldn't require human intervention.
As far as I understand, the primary reason the fees exist is to prevent blockchain spamming (and mining incentive). So Monero has some minimum fee thats based on the size of the transaction. I'm sure you've noticed how this works if you've tried to clean up some dust using Moneromoo's recent simplewallet enhancements (2.3 XMR to cleanup 5xmr of dust wuuuuut)
Currently, the fee is 0.01 xmr kb as writ here:
https://forum.getmonero.org/1/news-and-announcements/91/monday-monero-missives-17-november-2nd-2014Now this is all fine and dandy except when Monero shoots to the moon (1 xmr = $1000), because an increase in price doesn't mean the size of the transactions will decrease. A transaction to send 0.045 XMR will use the same space (well, probably more depending on mixin availability) as a transaction to send 45 XMR (more or less).
Obviously, the easiest solution is to modify the code by hand (the devs intervene), and there will be plenty of incentive to do so - the cost of transacting will decrease the utility of Monero - the coin has become worth a lot, but it is really expensive to use, so people just hold it. But when humans intervene, you end up with all the nonsense associated with humans. Miners might not want to switch because they're raking in profits. The monero-as-asset crowd will rally for not changing the protocol because transaction friction could actually
increase the value of an asset ( perhaps ).
All-in-all, the modifying-the-fee-using-human-intervention is the antithesis of cryptocurrency. Again, the goal of cryptocurrency is to remove as much of human element as possible.
So, how could we do that?
I don't think its possible to somehow link the protocol to some type of oracle - i.e., the protocol somehow gets data input from some external source. For example, you could imagine the protocol gets a feed from some XMR fiat exchange. I don't think this is possible primarily because it depends on factors exterior to the protocol.
I think we would have to stick with data that exists within the protocol blockchain. Specifically, I think these are the data we can use:
t = Transaction frequency = number of transactions per block
a = transaction amount = the amount of XMR actually transacted in a given transaction
Using these data, I think something could be written that would achieve goal of increasing the XMR cost of a transaction when fiat value is low, and decreasing the XMR cost of a transaction when fiat value is high.
Essentially, when the transaction frequency is low and the transaction amount is high, one could infer that the fiat value of XMR is low.
Conversely, when the transaction frequency is high and the transaction amount is low, one could infer that the fiat value of XMR is high.
Obviously, some sort of rolling window would be used to aggregate an average of these data.
I've been trying to wrap my head around how to convert the fee calculation to something dynamic that wouldn't require human intervention.
This is a useful and interesting effort but keep in mind there are at least four different tx fees:
1. The fee required for relaying by nodes.
2. The default fee set in the code for miners to include a transaction.
3. The default fee set in the code for those sending a transaction.
4. The actual fee at which miners include transactions in practice.
The first is a network function that prevents spamming the p2p network as a DoS attack. It should not really be much less than #4 because that allows spamming the p2p without any real cost (the spammer wouldn't actually pay the fee because the tx wouldn't get mined). It can't be changed (either higher or lower) by individual nodes because if they violate the rule expected by other nodes they will get disconnected.
The second is a default in the code and miners can change it if they want (currently this would require recompiling the source code, but other options may be added later), though setting it lower than #1 would not result in any more transactions being mined since they won't be sent over the p2p UNLESS the miner gets these transactions via another channel, or creates them.
The third is a default in the code and users could change it if they want (currently this would require recompiling the source code, but other options may be added later). If this is set lower than #1, the transaction will be rejected by nodes.
The fourth is entirely a market phenomenon that is a balance between supply, demand, and the fee policies set by users and miners.
EDIT: fixed typo "much much" -> "much less"
I've been trying to wrap my head around how to convert the fee calculation to something dynamic that wouldn't require human intervention.
This is a useful and interesting effort but keep in mind there are at least four different tx fees:
1. The fee required for relaying by nodes.
2. The default fee set in the code for miners to include a transaction.
3. The default fee set in the code for those sending a transaction.
4. The actual fee at which miners include transactions in practice.
The first is a network function that prevents spamming the p2p network as a DoS attack.
It should not really be much much than #4 because that allows spamming the p2p without any real cost (the spammer wouldn't actually pay the fee because the tx wouldn't get mined). It can't be changed (either higher or lower) by individual nodes because if they violate the rule expected by other nodes they will get disconnected.
The second is a default in the code and miners can change it if they want (currently this would require recompiling the source code, but other options may be added later), though setting it lower than #1 would not result in any more transactions being mined since they won't be sent over the p2p UNLESS the miner gets these transactions via another channel, or creates them.
The third is a default in the code and users could change it if they want (currently this would require recompiling the source code, but other options may be added later). If this is set lower than #1, the transaction will be rejected by nodes.
The fourth is entirely a market phenomenon that is a balance between supply, demand, and the fee policies set by users and miners.
So the fee that I'm talking about would be #1 - the fee required for relay by nodes. I'm not sure I'm parsing what you write in the above bold - so the spammer could spam just by bloating the mempool? I think the confusing part is the mis-type of "much much", which could be "much less" or "much more", and this is a key piece of data.
I'm assuming its much less.
blue text = but couldn't each individual node recalculate the minimum value based on data on the blockchain? So then all nodes will be in agreement, because they're all making the same calculation off the same blockchain.
If I'm reading you right, the primary protocol-induced fee is #1. Is this fee what I understand as the per-kb fee?
So the fee that I'm talking about would be #1 - the fee required for relay by nodes. I'm not sure I'm parsing what you write in the above bold - so the spammer could spam just by bloating the mempool? I think the confusing part is the mis-type of "much much", which could be "much less" or "much more", and this is a key piece of data.
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.
If I'm reading you right, the primary protocol-induced fee is #1. Is this fee what I understand as the per-kb fee?
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.
So the fee that I'm talking about would be #1 - the fee required for relay by nodes. I'm not sure I'm parsing what you write in the above bold - so the spammer could spam just by bloating the mempool? I think the confusing part is the mis-type of "much much", which could be "much less" or "much more", and this is a key piece of data.
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.
If I'm reading you right, the primary protocol-induced fee is #1. Is this fee what I understand as the per-kb fee?
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.
So the fee that I'm talking about would be #1 - the fee required for relay by nodes. I'm not sure I'm parsing what you write in the above bold - so the spammer could spam just by bloating the mempool? I think the confusing part is the mis-type of "much much", which could be "much less" or "much more", and this is a key piece of data.
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.
If I'm reading you right, the primary protocol-induced fee is #1. Is this fee what I understand as the per-kb fee?
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.
Hrm, you would also have to make the floating minimum a range, not a fixed value.
Ff the precisely calculated minimum is 0.01211 xmr kb, and by the time your transaction is made and sent to the network, the new precisely calculated minimum is 0.01213 xmr kb, that won't work.
instead, you would have some range around the precise minimum. This range itself would have to be dynamic, but that could be easy... just use the rate of the delta for the minimum. I.e., if over n blocks the minimum moved 0.0004 xmr, then thats the range. (or something like this)
