Monero fee improvement attempt

[SamsungGalaxyPlayer]

The existing code creates a Monero fee in the UI of 1.9E-09 XMR. This is substantially less than a normal Monero network fee.

The fee response from get_fee_estimate is the "Amount of fees estimated per byte in atomic-units".

https://docs.getmonero.org/rpc-library/monerod-rpc/?h=get_fee_estimate#get_fee_estimate

I thus change feeRatePerKb to feeAtomicRatePerByte, and I use feeRatePerByte to convert the fee in atomic units to non-atomic. Then I multiply this value by 1500 bytes, which is currently a reasonable approximate weight of a 1-in/2-out Monero transaction.

Apologies if I missed anything in this PR!

[NicolasDorier]

hey @SamsungGalaxyPlayer thank you for this PR. We are releasing the 2.1 very soon, I want then to hand off this repo to the monero community which can merge that.

Just to make sure I don't introduce a bug as we are going to release, I don't merge it myself.

Excited to see you guys going freely on the monero integration! :)

[deverickapollo]

@SamsungGalaxyPlayer - Can you resolve the merge conflict here? I'll pull this in with our next release.

[napoly]

Hey @SamsungGalaxyPlayer .. thank you for this PR! We finally have all the infrastructure up and ready to bring this in safely.. can you pls rebase ?

git fetch origin
git rebase -i origin/master
# fix any conflicts, squash.. then:
git push -f

As for the code you are casting long/double.. losing precision but I believe this will be pointed out for you by CodeRabbit once rebased. I also don't like hard-coded values --> 1500.. but this is an estimation.. could be calculated to some degree but doesn't seem to be worth it..

We do have an integration tests that hit this part of code.. fyi.. but as this is a calculation it should be covered by unit test/s i think (again AI can help a lot.. one should mock away the rpc response..)

Pls let us know if you get stuck!

[nahuhh]

I also don't like hard-coded values --> 1500.. but this is an estimation.. could be calculated to some degree but doesn't seem to be worth it..

you cant know the input select before generating the tx.

afaik, the only way to know an accurate fee is to submit the proposed tx using do_not_relay, which will return the correct/exact fee. (it will also submit the tx to the node w/ a do_not_relay flag attached to it. I believe this tx can still be mined, but wont be relayed)

there is also a get_fee_priority method that will tell you which fee lvl / multiplier that "automatic" tier is using.

[nahuhh]

Also, i might not suggest a rebase. This has been fudged up with multiple merge commits.

probably easier to just git reset --hard HEAD~2 to drop the merge commits, then rebase.

or to cherry-pick the first 2 commits onto a clean branch off