It seems to me we are losing exchanges because of the NSR issue.
A few weeks I did manage to withdraw the first portion of my NSRs from cryptopia with no issue.
Then I tried to withdraw the second portion but I could not.
I have been communicating with their support since then.
It seems that their nubits wallet is working for deposit and withdrawal so it is not an issue with the blockchain download.
I suspected this was related to the NSR fee.
However I noticed they were not using the right fee amount for NBT either.
See below, the latest msg sent to them.
Dear customer support. I did contact you 1 week ago and 2 weeks ago, both times about the same subject, NSR withdrawal. I apologize for the additional message but would you have an update on the NSR withdrawal issue? As I said last time, the client is stable for both units, NBT and NSR. However you need to be careful about the tx fee for both units. You can get the current tx by typing in “getinfo”, under debug info. You will get the following: - tx fee for nbt: 0.05 - tx fee for nsr: 10 The latest version is v5.0.1-beta. Just now, I did a withdrawal for NBT from my cryptopia account and I got it with no problem. However I noticed that you are using 0.01 as tx fee and not 0.05. You should not have any issue with NSR either if you use the right amount of tx fee which is 10NSR. Please let me know if you need some help. Thank you very much in advance. Sincerely, PS: By the way, I really like your exchange over Polo. Polo is not transparent. You are. Cryptog
Is the right amount of fee automatically selected from communicating with the client when sending NBT or NSR?
It appears it is not.
But it seems that we have also the opposite issue.
The operator is using the right amount of fee but that fee does not match what the client is using.
I had some NSRs on alcurex too.
I did one try with 100k NSRs with no issue.
Then I tried to withdraw 1m NSR or so and it took then 10h to send me the assets.
Below is the email I exchanged with their customer support.
Hello.
Seems NSR developers are lift network fee from 10 to over 1500 NSR.
For this reason withdraws was blocked by security engine.
Do you accept new network fee or want cancel withdraw?
As you can see the client is requesting a fee of 1500 whereas the tx fee decided by vote is 10NSR.
To me there seems to me a huge bug in the client, that ends up preventing the client to send NSR and potentially NBT as well because of a contradiction on the fee requested.
Any thoughts?
I think this is a crucial issue to solve if we want Nu to the get the NSR liquidity needed for the peg…
Indeed and there’s also the inputs that may be split. You can disable the split on the outputs, but not on the inputs (since it’s already been done). Exchanges should disable output share splitting, but they will still have users sending them shares in 10k chunks, so that may mean significant fees to transfer those funds.
But whatever the size of the transaction and the voted fee, the fee calculation is always the same. I think exchanges like to pay constant fee. It’s a waste but it’s possible, they just need to calibrate that constant correctly. And if possible it should still depend on the voted fee. I can help with that if they want.
I see. But how can the exchange operator get to know about the required fee?
Can it be automatized?
I mean can someone easily make sure that the client will include the right amount of fee automatically?
It seems Alcurex was surprised to see that the client requested 1510 NSRs. He seems that he assumed that the fee was always 10NSRs.
In a words, can someone easily compute the required fee and include it in the tx ?
They have 3 possibilities depending on their use case:
they don’t because they let the client handle that
or if they build the raw transaction with createrawtransaction then they have to
first create a transaction without the fee,
calculate the required fee from the size of the generated transaction and the paytxfee field of getinfo (the exact formula is in the source, it’s (1 + floor(size_in_bytes / 1000)) * paytxfee),
and run createrawtransaction again with the fee included (and possibly do this process again in the rare situation where the new fee increased the size and it made the required fee change)
or if they build the raw transaction themselves then they do the same as above but with their own generator.
There’re currently no way of seeing the raw transaction before it is sent by the client. We could add an RPC to do that. You can however inspect already sent transactions with getrawtransaction, so you can verify the fee calculation on any past transaction. But I am not aware of any report about the client miscalculating the fee.
The problem with exchanges is they usually want to build the transaction themselves so they also have to calculate the fee themselves and sometimes they fail to do that correctly.
That’s probably because in other coins most simple transactions are below 1000 bytes, so they wrongly assumed the fee is constant. But in most coins with a minimum fee it depends on the size, and if they make the same assumption on other coins they probably also generate invalid transactions from time to time when they have to take multiple inputs because they have a lot of small outputs to spend. In NSR it’s almost always bigger though, because of the split (especially if they don’t disable it on the output, but if they build the transaction themselves the split is not done anyway).
We do have a documentation for exchanges that mention another important change they usually want to make (disabling avatar mode, but it’s really only useful if they let the client generate the transactions) : https://docs.nubits.com/integrating-nubits-or-nushares-with-an-exchange/
It doesn’t mention the share split though.
It’s not very easy because you have to know the transaction size (which may be seen as a chicken and egg problem). But as you can see above it’s not very difficult either (that’s how the client does it btw). You have to be able to query paytxfee frequently though, because it was decided our fee would be able to change over time.
Note that paytxfee is actually not the actual current fee, but is the maximum fee that will be effective in the next 10 blocks, so that you’re almost certain the transaction can be included in a block if you send it now.
