For instance this guy:
https://blockexplorer.nu/blocks/523659/1
You probably called that a 20 nbt Tx, but what if it was a 0.03 nbt tx and the 20 nbt was the account balance?
@tomjoad I would love to see a volume dependent tx fee passed, no matter what function we decide on. As long as there’s a votable proportionality constant, I think we could do just about anything and it would work out. The change problem is a powerful issue, but not undefeatable.
You are right. I just tried to find some information on which tx fees could be based on. But it seems like the tx fee is in the same category as the park rate interest: no reliable data to base a decision on 
we can find an absolute minimum average Tx size and standard deviation by assuming the biggest output is the change. Maximum is found by assuming no change. In any case, if there’s a TxOut address that’s also a Txin, assume that’s the change address.
Very clever!
Looking at tx like this:
https://blockexplorer.nu/blocks/522951/1
I wonder why someone would require two inputs above 87.89 NBT each if 87.89 NBT were to be sent and 2,000 NBT were the change.
But this is not saying the proposed method is not good for finding the absolute minimum average tx size. It’s good for exactly that!
It’s rather the insight that the minimum average tx size found by this procedure might be off by far.
And still it would be much better than having no data for discussing tx fees!
Very good point, you should try to generalize that and use that too if you’re trying to write a program. I think we can assume that Txn’s are being sent from normal clients a majority of the time.
Unfortunately I can write nothing except for tiny ugly bash scripts. In my next life I’m going to be a coder. In this life I’m left behind admiring people who can write code 
Back to topic:
we can never be sure what’s the change and what’s the deposit to a foreign address.
You pointed out a way to find the minimum average tx size.
And you assumed the maximum were found by assuming no change.
That only works if there’s no change, which in most cases isn’t true. It’s unlikely that an UTXO has exactly the right size to pay the tx fee and send an amount of NBT without a change.
But you can invert the “minumum” approach to find the maximum average tx size by assuming that the biggest output is the sent NBT.
Somewhere in between the minimum and maximum tx size is the reality.
But occasionally someone truly is sending their full account balance. I know I do that a lot. I think I can update my fee code relatively easily to give some practical numbers. If I recall the biggest issue with it is that it doesn’t know how to identify a coinbase Tx before we started marking them with a nonce hash. But for the last half year or so I should be able to recover some real numbers.
If that account has more than one address, you’ll find more than one UTXO in that transaction, which makes me realize that the maximum average tx size can’t be gathered from the biggest output, but needs to be the total amount of the tx - just what I had in my list some posts above and which I mistakenly assumed to show real tx volumes (which in fact is false).
So what do you want to know? You probably want to know Tx volume / Tx size, but I haven’t figured out how to find Tx size rigorously using rpc. I can do average Tx volume.
I think I will change to 0.02 in my next feed update.
This is between 500,000 and 524,000. It’s a minimum and does not include the modification MoD mentioned.
It shows an average around 100 NBT/Tx. There seems to be a cluster of Txns around 0.03 volume. The program is slow, so it would take a long time to do the whole block chain.
Not a fan of this as most people don’t want to have their stakes or profiles identified. The way to address this is to provide more choice in datafeeds. I understand that there are developments underway which makes it all easier.
The same reason as some others have already expressed.
Unclear what the actual $ gain is by e.g. doubling the fee.
Given the number and kind of transactions I think it is too early to raise the cost of transactions. I feel we rather need to stimulate. However I’m not sure about the effectiveness of e.g. halving the rate though.We need to stimulate through other means, like NuDroid, marketing, documentation, web wallets, improving ease of use etc.
Although a step in the right direction, I think the current rate setting needs to be more granular. e.g. relatively high transaction fees for micro transactions (<$10), medium for up to $500 or so and highest for large transactions. I understand from the other threads that this is not easy to achieve due to the change addresses.
~$0.5/day.
As a super rough approximation, we’d lose something like 1% of our Txns by doubling the fee.
Your third point is volume dependence, which most shareholders seem to support, but will require some real funding for dev work. I think your second point is the most interesting. I would be of the opinion that other marketing efforts can change the volume of the network as much as 10% easily (that would mean an extra 5 Txns/day). Therefore, I estimate that doubling the fee would have a negligible effect on marketing when compared with actual marketing efforts. However, $0.5/day is also somewhat negligible (only about 0.15% of our expenditures) so meh.
Nothing to win at the moment, only to lose when word get out that Nu raises their fees in the network. It is not good for marketing and would therefore do more damage than good imo.
These two comments convince me that raising the tx fee above 0.01 NBT/kB is no good option at the moment.
Changing it would have the benefit of showing the world that Nu actually can change the tx fee, though.
Although I was arguing for raising the fee earlier, I’d rather vote for lowering it to 0.005 NBT/kB now.
This should still be enough to protect the network from spam transactions, doesn’t cost more than 0.25 NBT per day (~90 NBT per year; based on @Nagalim’s analysis) and shows that Nu can adjust the tx fees.
This could be better marketing than raising the fees (both the lowering and the fact that Nu can adjust fees). If it doesn’t pay out marketing wise it still didn’t cost much and can be changed back to 0.01 NBT/kB easily.
More than happy to cooperate in a test and see how the network responds. Lowering it to 0.009 or so would do the trick. But after that I would vote for 0.01 again.
By the way, what is the width of consecutive blocks that is checked and needs to contain a certain tx fee vote at a 50% rate at least in order for a fee to get implemented?
Is it the same as motions, custodial grant votes and interest rates?
Don’t forget that we would be increasing our block chain size by decreasing the fee (theoretically). Cutting the fee in half would be extreme, in my opinion. I’d gladly vote 0.009 though.
Yeah, why not. 0.009 would still be a change and not as drastic as 0.005 
Voting for 0.02 NBT - easier to lower them afterwards marketing wiser and perhaps tx is a business arena that we want to explore.
