[Passed] Dynamic Fees in NuDroid

[MatthewLM]

Hello. This is the final proposal for implementing dynamic fees into NuDroid. I’ve taken into account that Nu 2.1 has not been released yet meaning that the application will be prepared for the 2.1 “getfee” command but shall still work with Nu 2.0.

Matthew

---

Proposal RIPEMD160 hash: 7a62f4e88e251d963240bf762175fb79c4100fb3

=##=##=##=##=##=## Custodian Hash starts with this line ##=##=##=##=##=##=

Custodial Address: BSn4pCHyK7T9iFafSiYnPuGjGoyW65J5js
Amount Requested: 1600 NBT

This proposal will allow the correct fee to be used in NuDroid for the 2.0 protocol. It may work with the future 3.0 protocol, but this is not guaranteed. It involves the following tasks and changes:

• A new python wsgi script will be created to provide NuBits fees. The script will take “application/x-www-form-urlencoded” POST data with the arguments “bytes” and “amount”. The “bytes” argument shall be the size of the transaction in bytes, and the “amount” argument shall be formatted with 4 decimal places. The script will attempt to use the “getfee” RPC command from Nu 2.1, however if the RPC command is unavailable the script will revert to using the “paytxfee” field from the “getinfo” response. The script will work with Nu 2.0 but will also be compatible with Nu 2.1 when it is released.
• The new script shall be deployed on the “Default - Explorer” server, and potentially on “Default - Anton” with the collaboration of @willy Nu, will be upgraded to 2.1 if 2.1 is available during this time.
• The application will assume that the “amount” parameter should be the total value of all outputs in a transaction. It is assumed that this will likely achieve the correct fee with the future 3.0 protocol, although it is not guaranteed.
• The fee calculation will be altered to first estimate coin selection with an assumed 0.01nbt fee. Then the app will make a server request for the fee and coin selection will be reapplied with the returned fee if it is different. If there is a change in the transaction size as a multiple of 1000 bytes, another request will be made to the server to obtain the new fee. The process will be repeated until the fee is satisfied.
• When requesting fees, the app should try all of the trusted servers with “/getfee” appended to the URL and use the fee of the first server that responds.
• The app should give the error “Cannot obtain fee from servers” if there is an error obtaining the fees.
• This update shall be released no later than 2 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.

=##=##=##=##=##=## Custodian Hash ends with this line ##=##=##=##=##=##=

Verify. Use everything between and including the <custodianhash></custodianhash> tags.

[Cybnate]

Great, supporting this. Thanks for responding to feedback and returning with a solution which better suits the Shareholders.
Can you please hash the grant?

[desrever]

I support this.

Instruction for hashing @ https://docs.nubits.com/nubits-discourse-bot/

[MatthewLM]

Thank you. I tried hashing it, though it did not work. I will try again after a short while.

[MatthewLM]

OK, I managed to get it working this time, please see the hash in the original post.

[willy]

7a62f4e88e251d963240bf762175fb79c4100fb3

RIPEMD 160 hash:
7a62f4e88e251d963240bf762175fb79c4100fb3

verified

[zoro]

i don’t see shareholders to support this. i would expect some reasons why.
not even a single comment against it!

[Nagalim]

I’m not voting for it because I don’t think it’s worth the cost. It is more expensive than the alp-nubot crossover and vastly less useful, just for comparison.

[desrever]

It is more expensive than the alp-nubot crossover and vastly less useful, just for comparison.

mmm actually it’s not : remember I will be using 1700 NBT extra. So overall this cost almost a half of nubot-alp.

I support @MatthewLM motion

[Cybnate]

I’m not voting for it because I don’t think it’s worth the cost. It is more expensive than the alp-nubot crossover and vastly less useful, just for comparison.

Saying it is not worth it is interesting. So either you don’t want to support dynamic fees going forward as this is the trigger for the additional costs or you want to make NuDroid obsolete as it won’t work as soon as the fees are changing. Interested in hearing your position.

In the mean I like to say that I still support this as long as no one can create a similar or better solution for less costs. The time for this is limited though as Shareholders clearly indicated earlier that they want to change the fees.
The NuDroid code is opensource, so competition is open, although I hope we can work on the same source without creating forks, but that is a side note.

[cryptog]

So either you don’t want to support dynamic fees going forward

Perhaps instead of paying for finding an ad-hod solution for variable fees only, it could be wiser and more economical to pay for adapting NuDroid to Nu 3.0 which includes dynamic fees?

[MatthewLM]

Hi. With this grant I will attempt to provide future compatibility with Nu 3.0. However, since many details on 3.0 are up in the air at the moment, I cannot guarantee it.

[zoro]

i don’t think this will pass!
i guess there are more like Nagalim that disagree about the cost.

[Nagalim]

So either you don’t want to support dynamic fees going forward as this is the trigger for the additional costs or you want to make NuDroid obsolete as it won’t work as soon as the fees are changing. Interested in hearing your position.

If a billion nbt grant was asked for, would these still be my only two options? Is the network held ransome for any number of nbt by the desire to keep NuDroid from going obsolete?

[MatthewLM]

Someone else could offer to implement dynamic fees in NuDroid for a lower cost. Either way, shareholders should be aware that until the dynamic fees are introduced, any increase in the transaction fee will break NuDroid.

[Cybnate]

No, it is not about holding ransom. There are options and they have implications. That’s what I spelled out. Doing nothing is also an option and that will effectively break NuDroid and make it unusable unless we don’t change transaction fees.

As Matthew said as long as there is awareness amongst shareholders this is happening I’m fine with that although I don’t support it at all. Good to save further costs in hosting, certificates and security as well, as it would be a waste to continue the server side support when the client becomes useless anyway. Then I will keep it off-line for a while until someone comes up with a supported solution for the issue I suppose. Saves me a lot of work in maintanance too. Will raise a proposal to do so as soon as the transaction costs change rendering NuDroid worthless.

At this stage I’m not seeing developments of anyone else doing this work, please let us know if someone is working on it or likes to work on it or you are aware of this is happening so we can consider another option.

[Nagalim]

There are always other options to find consensus. Perhaps we should put out a bounty?

[zoro]

what would be a “logical” cost for this implementation?

[Nagalim]

Could we use a poll with several options, like 0, 400, 600, 800, 1000, 1200, 1600? Vote for the highest you’d be willing to pay.

[cryptog]

@assistant custodian vote BSn4pCHyK7T9iFafSiYnPuGjGoyW65J5js