There has been problems with the dynamic fees introduced with Nu 2.0. NuDroid continues to use the 0.01nbt fee even if the required fee is higher. I have determined how dynamic fees can be introduced in NuDroid, though it is not a quick and easy fix.
The details of the grant proposal are shown below.
Regards,
Matthew
Address: tbc Amount: 4,000 NBT
This proposal is to add dynamic fee calculation to the NuDroid Android application, as according to the 2.0 Nu protocol. The application will read and store the fee votes from blocks and calculate the fee using the same mechanism as the Nu desktop client. The application will automatically and seamlessly update the blockchain storage structure when it is opened for the first time after the update. After the user updates the app, they will have to wait about 35 hours (2,059 blocks) before the fee calculation is correct, or they can reset the blockchain.
This update shall be released no later than 4 weeks after the grant is passed, however efforts will be made to release earlier than this if possible. If the update is not released by this time, the entire grant amount shall be burned.
The update will be released under version 4.4 on Google Play.
This is outside the scope of core client, NuBot and ALP development.
It isn’t clear it is supported by shareholders.
Even if it were within the scope of the core client, generally features of this level of expense require shareholder approval. Exceptions are only made when it is clear shareholders support it, such as the memory and start up speed optimisations.
I am questioning whether the implementation proposed is optimal. It takes a great deal more development and expense when compared to just using the getinfo RPC and using the paytxfee value returned. @MatthewLM is there a reason it should not be implemented using that simple method?
It is also possible we could include a new getfee RPC in version 2.1 that takes the transaction size in bytes and the value in currency/shares as parameters. The advantage to waiting and implementing the variable fee using the getfee RPC not yet available is that it will have to be used for version 3.0 later because the paytxfee won’t give a result that takes value based fees into account. So, there are 3 choices for implementation:
What Matthew proposes above.
Waiting until 2.1 is released to use the new getfee RPC.
Implement variable fees now using the paytxfee value and then change the implementation after 2.1 is released but before 3.0 is released to use the getfee RPC.
Thanks Jordan. Whilst it would be nice to have the app calculate the fees itself, according to feedback it appears that using the trusted servers to provide the fee would be the best way to go. For every transaction, the app could send a request with the transaction size/amount, and the servers can then use the getfee RPC method to provide the fee to the app. This could be implemented under a new URL, for instance /q/getvalidhashes/getfee by adding /getfee to the end of the URL. A benefit of this solution is that the app itself would be agnostic to the fee calculation logic if it ever changes; it would simply rely on the servers.
In this case it would be best to wait for version 2.1. Do you know when or when-abouts it will be released and the details of the getfee method? I could arrange the changes to NuDroid in advance.
I have created this issue to create a getfee RPC in Nu 2.1. The speed with which 2.1 is released depends on how quickly @sigmike completes the coding and how quickly it progresses through testing and beta release. Perhaps Mike can provide more info. I can say that the 2.1 release is about 80% code complete.
OK, I’m writing up a new proposal now. How will Nu 3.0 determine how much is being sent? Does it assume the value of the largest output as being the amount sent? Or is it the total output value?
I’m not sure how the devs are thinking about it, but my thoughts would that it would be total output value for any output address that is not also an input address (or where the ouput for that address is bigger than the input). Then, have a minimum for the fee equal to the fee that currently exists (transaction size dependent). That way, a standard Txn in avatar mode doesn’t have to worry about the change address and a Txn not in avatar mode can play some interesting games to minimize the change output (which will indeed get charged along with the standard output).
Hmm, well the final behaviour does need to be known so I can calculate and send the correct value. Also I did hear talk about changing the minimum output. Will there be any changes to this?
Edit: Another thing. will the fee calculation be per 1000 bytes, or will it change for every byte? I need to know if the fee should be recalculated if the size increases but does not surpass another 1000 bytes.
I don’t know how the shareholders want this new volume dependent fee to work. The motion doesn’t give any detail about that.
There’s no reliable way to determine the change output and it’s a feature to protect privacy. I don’t think using the smallest output is wise, it would often be wrong and it can very easily be gamed to reduce the minimum fee.
One way to do it is as Nagalim described: take all the outputs that are not also an input address. That way people who don’t care about privacy can use avatar mode and pay the fee only on the amount sent. And people cautious about their privacy would pay the fee on the whole amount.
Another way would be to always take the whole amount. In this case we would not favor settings lacking privacy protection, but the cost would depend on the amount in your outputs.
We may at the same time introduce an option to automatically split NuBit outputs like we do with NuShares. But you don’t control that when you receive NuBits.
Thanks for the reply. I suppose the only thing I can do for now then is to wait for a decision to be made in regards to the getfee parameters. This would be OK assuming that the fee remains at 0.01nbt until that time comes and I am able to produce a solution. Otherwise I could look to produce a solution that is only guaranteed to work with version 2.1.
Sure. What I can do is use the getfee command and assume that it is OK to send the total output amount as the app wont use an avatar mode anyway. It still wont be guaranteed to work with 3.0, but indeed it should at least work with 2.1. And then it wouldn’t necessarily be too hard to update it again to support 3.0 if needed.
I’ll finish putting together an alternative proposal later today.