The fee scales with the size of your transaction that has to be recorded in the blockchain, which varies and is not exactly dependent on the value transferred, but is usually not much.
===============
To add to this discussion in general, I think it makes sense to have tiered fees tailored to different use cases and habits rather than a lumped measure. Here’s an example…
First, we have an expensive volume-dependent fee that charges at least 0.05 NBT and otherwise up to 0.5% of the total amount sent. A transaction that pays this fee can be included in any block.
Then we have a cheaper fee, at least 0.03 NBT per kb and otherwise up to 0.3% of total amount. A transaction that pays this fee is only included in 5 blocks every 10 blocks (e.g if block height is 0,1,2,3,4 modulo 10), so the user would expect some extra delay up to 5 blocks.
Then we have a cheapest fee (e.g. 0.01 per kb) for microtransactions that are only included for one in ten blocks. Something like this at least should be an intermediary measure while moving to volume-dependent fees.
Finally we can also do some acrobatics - we can use block-chain recorded “deferred transactions” that also reduces some fees. The transaction would look like a parking transaction, sent to a “parking” address and released to the final destination after a given amount of time. It costs two transactions just to do one, but offers some security to the recipient and allows us to observe and reduce the speed that money is moved around the network, somewhat offsetting the role of parking.
If well designed we would have more fine-grained control over the trade-offs in the effects of transaction fees.
When I vote for 0.02 NBT into the fee vote field in Nu QT client, I interpret that as follows: I want any NBT tx to pay a fee of 0.02 NBT and I do not need to have in mind the quantity of data (ROM) transferred actually encoded.
Still, I would like to know the exact connection betwwen transaction fee and data stored in ROM into the blockchain, if someone could care to clarify, that would be very helpful since I would like to decide with the right understanding.
isn’t the official NU wallet automatically add the fee in every transaction?
thus exchanges should be ok, i think. (bter has 0.1 nbt fee anyway)
edit: the last 3-4 days every nbt transaction is sent from my windows wallet added 0.4-0.6 nbt fee.
i don’t know the reason, amount was small.
poloniex and hitbtc have 0.01, southX is updated to 0.02 !
the back and forth of fee value doesn’t look good.
edit: my feel is that we should leave it as it is 0.02 and not changing it all the time!
There are shareholders voting for 0.05, and it is not clear whether there is consensus on any fee as we don’t have tools look at that like we have for motions and grants. So it could change back any time soon or just jumps to 0.03. No one knows and it could change any time without notice. Without some forewarning e.g. for exchanges this is not a good situation imo.
Providing a quick patch for NuDroid with a 0.02 fee can be done, but might be obsolete in another week or so, I don’t know what the best course of action is other than spending time on working on a sustainable solution which will take time. Until then don’t rely on NuDroid. it’s a shame that we invested a lot of marketing in this, first the issues with the nodes no longer working and being taken offline without notice and now this. Not a good look for people looking to actually use NuBits. Hope there are some lessons learnt in this.
Just fired up my Bitcoin wallet, to be able to pay for some items in Bitcoins…
But I do think that it is also one aspect of the job of the developer who is paid by the shareholders to keep one’s self updated about new features all the time although shareholders should be aware of the complications that some features may cause but seriously who had in mind that the variable tx fee would cause such an issue?
Personally, I assumed that upgrading to the latest version of Nu would get you in the safe zone.
So besides NuDroid, who else has the same issue?
(I suppose the issue is: not being able to broadcast NuBits transactions because of a mismatch between the actual tx fee decided by the network and the tx fee set in the program)
I feel your frustration. I understand the reasons for it well. NuBits is still young and if you are looking at the adoption or the number of installed NuDroids still in its infancy.
Better make now these mistakes than later.
But on the other hand…
Variable transaction fees are an integral part of NuBits.
They need to be handled automatically and properly by wallets.
Full stop.
I will look into the dynamic fee code when I get chance, but I do think the best way to go now in the meantime is to release an update with the 0.02nbt fee. I might be able to do that later today, though I am busy.
When Nu 2.0 was released, I had no warning beforehand. The primary concern at that time was to disable the bloom filtering to ensure the app was compatible. I did at first read about the dynamic fees, but considering the chaos at the time, I forgot about them and the present day problems did not occur to me.
To ensure NuDroid is compatible with future Nu versions, I should always be given advance warning and presented with all of the protocol changes so I have time to go through them and plan an update, with enough time to obtain the funds and develop the changes to the app, before any protocol changes come into force. This also applies to other developers, or project managers of Nu-related software.
I’m sorry if my last post offended you. It was not my intention to put blame on you.
What I wanted to say is: we are all still learning.
Obviously changes like this would better be handled with in a push style from Nu to service providers than expecting a pull style from the service providers.
With exchanges this is already on the agenda. Nu needs to put projects like mobile wallets there as well.
Isn’t variable fee a major break away from Satoshi client? Aren’t we in uncharted water where few major altcoin has tried? I hope @sigmike@JordanLee can comment.
No worries, no offence taken, I was just clarifying things from my perspective.
Indeed the fee has gone back down to 0.01nbt so I wont update the app just yet. I will take a look at dynamic fees and determine the work required. It’s nothing simple, so it’s not something I’ll be able to quickly add to the upcoming release. The only simple fix if the fee goes back up is to change the hardcoded fee (here). No doubt I’ll have to run another grant to implement the dynamic fees.
This brings up another suggestion, which is for cases such as these would it be desirable to have some emergency Nubits available for urgent development tasks? Custodian grants can take a while to pass.
Bitcoin has a variable fee structure, although it works quite differently from our own. Bitcoin is currently working to find an easier way to make the amount of fee required to reliably and quickly process a transaction easily knowable.
So, I think variable fees are just something wallets and exchanges need to learn to automate, which isn’t that difficult. For now, wallets need to be determining the fee based on the paytxfee value returned by the getinfo RPC. This will change in Nu 3.0 when we add value based transaction fees. The design of that is not finalised, but it is safe to say there will be a new RPC that is designed to return the required fee. It is likely to take a size in bytes and a quantity of currency/shares as parameters.