Discussion about the transaction fees

[Nagalim]

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.

[masterOfDisaster]

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.

[Nagalim]

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.

[masterOfDisaster]

But occasionally someone truly is sending their full account balance.

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).

[Nagalim]

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.

[cryptog]

Any reason for voting for 0.01? Why not 0.02?

Although, it would be nice to see even 0.02 NBT voted for just to send a signal that we are able to change our Tx fees.

I think I will change to 0.02 in my next feed update.

[Nagalim]

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.

[Cybnate]

ctually, there is a way to track this. If each data feed provider inputted a unique motion hash into their voting (such as 0B5AB73448AFDF1080598ED9A083DF4EE94925F2 for “This is Cybnate’s data feed.”) we could track in real time the level of support each data feed provider has.

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.

Any reason for voting for 0.01? Why not 0.02?

The same reason as some others have already expressed.

1. Unclear what the actual $ gain is by e.g. doubling the fee.

2. 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.

3. 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.

[Nagalim]

Unclear what the actual $ gain is by e.g. doubling the fee.

~$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.

[Cybnate]

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.

[masterOfDisaster]

Unclear what the actual $ gain is by e.g. doubling the fee.

~$0.5/day.

Nothing to win at the moment, only to lose when word get out that Nu raises their fees in the network.

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.

[Cybnate]

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.

[cryptog]

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?

[Nagalim]

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.

[masterOfDisaster]

Yeah, why not. 0.009 would still be a change and not as drastic as 0.005

[crypto_coiner]

Voting for 0.02 NBT - easier to lower them afterwards marketing wiser and perhaps tx is a business arena that we want to explore.

[crypto_coiner]

Any good idea about the NuShares fee to set?

[Nagalim]

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.

[cryptog]

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.

[JordanLee]

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!