I am also unable to broadcast TX from NuDroid … The only thing I’ve found is that if you reset the blockchain at least the pending outgoing TX will go away and you’ll see your balance back.
I just sent a test-transaction … 0.25 NBT 0.01 NBT fee, it’s obviously not getting broadcasted.
urgent, urgent @MatthewLM
If someone has a direct contact with @erasmospunk they might want to give him a heads up about Coinomi. I haven’t seen him on the forum for a while.
Oh, didn’t know that; I just backed up the wallet and cleared all data. There might be some risks either way though, and the only way I know to eliminate them it is to re-send all NBT you still see to a new destination (possibly original addresses)
The thing is Nu didn’t need an upgrade to change the transaction fees, so some peers might still be broadcasting your old transaction, unless Nu is built so that you never broadcast transcations with invalid fees - even if that’s the case, some rogue custom-built nud might still be broadcasting it, who knows. A transaction basically links past outputs to a new output, and as long as all those past outputs still exist, a minter can accept the transaction and spend those NBT for you. So I guess we should resend our balance somewhere else as soon as possible.
Does anyone know of a convenient way to import the NuDroid wallet to the standard client? Is it enough just to copy and paste the decrypted private keys somewhere in walletB.dat?
1 Like
Broadcast might be possible yes, but what use is there if no minter is going to include it in the blockchain (our current one that hard forked with the 2.0 update, which included dynamic fees)?
The valid fee could still change back to 0.01 NBT again for your transaction, though.
Yes, if the transactions are indefinitely stored in the rawmempool of those minters or the transaction is (automatically?) re-broadcasted from the sender when the fee is 0.01 again.
I’m not sure though how Nu handles this at the moment on code-level.
This experiment with increasing the fee unexpectedly is not great imo. We should have some indicator in the blockchain or elsewhere so we would know that this was about to happen soon. Now we have two broken Apps and god knows what else may break. Not a good look.
I recommend bringing the fee back to 0.01 till these issues are fixed as we don’t know when they can be fixed as both Coinomi and NuDroid developers are only made aware of it today. Hope the Shareholders are satisfied with the experiment to break these Apps and can revert to the status quo until these issues are sorted.
Thanks for your consideration
2 Likes
Blaming shareholders for doing what they are explicitly allowed to do (increasing/decreasing fees) doesn’t seem very expedient to me.
Well, I guess the only thing that shareholders are to blame for here is, that there was no real campaign announcing that TX fees could change any time and that developers building on Nu (Apps, Wallets, Exchanges, […]) should change their fixed 0.01 fee implementations asap.
That was missed, I think.
1 Like
It is hard for me to believe that the majority of the Shareholders didn’t think about the consequences for the Apps and exchanges. I can recall an earlier discussion about the changing fees for exchanges although I can’t find the link. So doing this without announcement is really not great. Those who sincerely didn’t know are excluded from my response of course.
Nu is still experimental so I’m ok to ‘test’ functionality, but let’s make sure we inform our stakeholders and take responsibility now and revert back this change until this has been fixed and communicated appropriately. This does hurt. 
That depends on where you see the responsibilities of the parties involved. One (not me) might argue, that it’s not the shareholder’s job to think about every possible effect on third party applications, while using a feature which has been announced a while ago.
1 Like
i had the feeling that the fee was something used automatically by nu network and didn’t need any
manual handling by apps,exchanges or third party designers!
1 Like
The apps mentioned use their own methods to create transactions, which are not necessarily idenditcal with the routines used inside the official Nu/Nud builds.
If those methods are outdated (in this case: include a fee that’s too low), their transactions will be rejected by the official client.
1 Like
I could release an update with the correct fee (0.02nbt right?), but then if it goes back down to 0.01nbt, it will be too high. I can look into dynamic fees but that will no doubt involve significant development work. The question is, will this be resolved by returning the fee to 0.01nbt, or should I update it?
Dynamic is the way to go here, I suppose.
Can nubitsj/nudroid discover the price itself or does it need an external feed?
I can offer integrating a tx-feed on anton… which of course can be changed inside the wallet by the user if wanted.
1 Like
It would make most sense to calculate fees from examining the fee votes in the blockchain which can be done via nubitsj. This would have to wait for a future update though. For now I can change the hardcoded fee, though it makes no sense to do so if the plan is to return to a 0.01nbt fee.
Maybe that 1 cent has to work for the interim period… Question is: What happens if the TX fee keeps rising further?
If the fee is continuously changing every block (e.g. a moving average) then the valid fee has to be within a tolerance range (e.g. 0.00214586 +/- 0.00000100 ) or the fee paid at GUI inputing time or broadcasting time might be outdated by the time the tx is processed by a node. I don’t remember there is a tolerance parameter defined.
You can’t just use the getinfo RPC command? That’s what I did in my nuauction code.
2 Likes
I could provide the information via a server, but it would be better to have the app calculate the fee itself. It would have to follow the same algorithm as the main client.