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.
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
It’s a good point, our response time to a type 1 spam attack (DDoS) is for sure lacking even with our pretty excellent voter participation. There are a disproportionate number of Txns below 0.1 NBT which a higher fee would surely kill. However, to some degree we should consider if that is a bad thing. Even without a DDoS attempt, type 2 spam (blockchain bloat) is still a considerable issue, especially in our early stages. Whether the data is loaded onto the blockchain in the period of an hour or the period of a month, we will suffer if we do not increase our fee eventually. How much are we willing to sell our blockchain space for? Are we really willing to double our blockchain for $10,000?
The people that are sending small transactions are most likely just trying things out, testing. If we force them to spend $0.05 instead of $0.01 to test, will it make that much of a difference? We are scared of losing customers, but do we even want customers that either a) are fretting over cents for a great service or b) are trying to do some form of micro transaction that will bloat the blockchain? I believe group a) is small and group b) we want to discourage (or make them pay their fair share).
The revenue from a 5x increase would likely be somewhere near $2.5/day, which is <1% of our expenditures. Still, @JordanLee is right that the spam protection of the fee is a very real concern and we need to prepare ourselves for both long range and short range attacks by keeping a consistently high bar for spam.
3 Likes
I neglected to point out that with the NuShare fee set at 1 per KB, we could see a full 24 hour attack performed for less than $3000. Because the NuShare fee is less than the NuBit fee, only raising the NuBit fee doesn’t provide any protection from a denial of service attack. The lowest fee is what matters.
I see the security benefit in a high fee and the economy benefit in a low fee. In order to compete with creditcards (2-3% fee) the tx amount would be above 2 NBT if the fee is 0.05
Just to clarify things. What is the definition of a tx fee? The amount of NBTs taken away per KB of data contained within a block?The amount of NSRs taken away per KB of data contained within a block?
It charges based on the number of inputs and outputs to the Tx. It has nothing to do with the actual amount of NBT being transferred. My rule of thumb is 5 outputs per KB and 20 inputs per KB, plus a little overhead. A Tx with just one input and one output still pays the minimum fee.