The number of contributions to a service node is dependant on the number
of locked contributions instead of contributors. The difference being
that a single contributor may make several locked contributions to a
service node which will reduce the number of available slots. To clarify
a single contributor may contribute twice to a service node, using 2
slots rather than one.
The heartbeat was overloading the rpc wallet with calls every 5 seconds
which resulted in an ever growing queue of messages. Have slowed the
hearbeat down significantly for hardware wallets.
Have also added code to ensure that the hwdev.txt file gets created upon
wallet creation, the GUI wallet needs this to know if a wallet is a
hardware wallet and this isn't generated by default unless we pass a
name to the initial RPC create wallet call.
The ONS purchase screen validated that the user needs 8 oxen to purchase
an ONS name. 7 oxen for the name and another single oxen to cover fees.
Given the current fee rates this buffer is too high and 0.1
oxen should be sufficient to cover a single ONS purchase.
Fixes the logic around showing reserved contribution nodes:
- if we are a contributor and have a reserved spot, list it first.
- if the node has no open spots, don't list it at all.
Also tweaks the display so that we *do* show unfilled reserved stakes
for us, *even if* the node is unlocking. (But continue not showing
unstaking open nodes).
Reserved contributions for the current wallet were not properly being
added into the available contribution room available to a wallet; this
fixes it to include any unfilled reserved spots when showing available
stakes.
18082 will conflict with a running monerod on the system (18082 is
monero's default ZMQ RPC port).
This moves the default to 22026, which is clustered with oxend's other
ports (22022 P2P, 22023 RPC, 22025 OMQ).
(The '24 hole there was once used for the Monero ZMQ RPC interface in
oxend, but we no longer have that--but if we *do* need another port for
something 22024 will likely be it, so 22026 should be safe from future
oxend requirements).