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.
1 Like
I think I will change to 0.02 in my next feed update.
2 Likes
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.
3 Likes
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.
1 Like
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.
1 Like
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.
1 Like
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.
1 Like
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?
2 Likes
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.
2 Likes
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.
Any good idea about the NuShares fee to set?
I wanted to mess with the nsr fee until I realized we earn about 10x more from the nsr fee than we do from the nbt fee because of the 10 kNSR chunking system. If anything, I think we should lower it, but I’m actually of the opinion that it’s in a pretty good sweet spot as is.
By the way, since it is likely that the minimal amount of NSRs required to vote will be reduced to 1 (according to ), the standard NSR tx fee should be divided by 10,000 as well.
While adjustable transaction fees serve a number of purposes, my primary reason for promoting its implementation was as a protection against denial of service attacks and attempts to bloat our blockchain. Here is the question that is most important when selecting the optimal transaction fee:
If someone performed a denial of service attack against the network, would you be pleased with the revenue gained from transaction fees or would you feel the attacker took more value than they paid?
At 0.01 per KB, you can buy a block for $10. This means an attacker could dominate the network and delay many or most transactions for an entire day for around $14,400. A 24 hour attack would add up to 1.44 GB to the blockchain (which is currently around 700 MB). Would you be happy to have transactions disrupted for a day and have 1.44 GB of additional space used on your hard drive for $14,400 of revenue? If your answer is no, that means fees are too low.
At 0.05 per KB the cost of a 24 hour denial of service attack is $72,000. I would be quite pleased to see such an attack performed. If it happened repeatedly, we could use a small portion of the revenues to develop a method to trim the blockchain. Most of it could go to share buybacks and we would see the NSR price soar.
Our network is very open and provides access to untrusted parties by design. The simple truth is that we can’t prevent a denial of service attack, but we can decide how much it costs. We ought to charge enough for transactions that we would be pleased to see a denial of service attack. What is the minimum fee that would make you pleased to see a denial of service attack? At 0.01 per KB, I would be disappointed to see an attack. At 0.03 per KB, I’m not sure. At 0.05 per KB, I say bring it on!
6 Likes