Add a `prepared_bind` that lets you get a prepared statement and bind
parameters to it in one shot.
Add comments to the prepared_* methods.
Fix test suite bug in sqlite testing wrapper added in the earlier
prepared statement commit: it was selecting values from the current
(new, empty) database rather than the passed-in one.
After the batching HF we now have a "reward" field in the block header
which is confusingly different to "miner_reward". This renames
miner_reward to coinbase_payouts to clarify that this amount is the
amount actually paid out in the coinbase vs the reward accumulated into
the batching DB.
Also fixes a minor bug where the reward would only show the reward of
the first vout instead of summing all the vouts.
It is not uncommon to have nodes get decommissioned after a hardfork,
either due to lack of updating or issues with the release. This
implements a 7 day grace period where nodes that do get decommissioned
will not progress into a deregistration (and being hit with the 30 day
funds locked penalty).
Using SQLite::Statement directly requires sqlite to re-prepare the
statement every time it is executed; going via our `prepared_st` wrapper
caches (per thread) and reuses previously prepared statements for better
performance.
(It also, in some cases, simplifies the code a bit).
Adds two slightly different versions of prepare_registration: one that
works with the existing 4-person registrations (used up to the hard
fork), and one that produces HF19 amount-based registrations.
This also overhauls the questions to be a bit nicer to input;
specifically:
- allow "max" and "min" as stake amount options, and make "max" the
default.
- eliminate the "do you want to contribute the whole stake?" question
entirely. We instantly figure that out if you choose "max" (or enter
the 15000 manually).
- eliminate the "how many contributors?" question. Instead we just keep
taking additional contributors until you stop entering them.
- move the fee to later, after you've provided contributor info (if not
a full stake).
There is, unfortunately, a *huge* amount of duplication here: I copy and
pasted the entire HF18 registration code and just eliminated the
portions parts of it. This is temporary: as soon as we are into HF19 we
can eliminate the HF18 version entirely.
This adds a new tx registration interpretation for HF19+ by repurposing
the fields of the registration:
- `expiration` becomes `hf_or_expiration`; for "new" registrations it
contains the hardfork number (e.g. 19 for HF19), but the data layout
on chain doesn't change: essentially we determine whether it's a new
registration based on whether the field is <= 255 (interpret as HF) or
not (interpret as expiration).
Changes in "new" registrations:
- stake amounts are atomic OXEN rather than portions. This lets us skip
a whole bunch of fiddling around with amounts that was necessary to
deal with integer truncation when converting between amounts and
portions.
- the fee in the registration data is now a value out of 10000 instead
of a portion (i.e. value out of 2^64-4). This limits fee precision to
a percentage with two decimal places instead of ~17 decimal places.
Internally we still convert this to a portion when processing the
registration for service_node_states, but this makes the registration
itself much simpler and easier to work with (as a human).
- HF19+ registrations no longer have an expiry timestamp (though they do
depend on the hardfork, so they "expire" whenever the next hard fork).
The expiry timestamp was really only there to avoid a registration
amount decreasing too much from the dropping staking requirement.
- Both types are registration are still permitted for HF19, but because
registrations with more than 4 contributors expose bugs in the portion
transfer code (that results in registrations become invalid),
old-style registrations are still limited to 4 contributors.
- HF19 will allow both old and new registrations, so that registrations
generated before the HF will still work, and so that we don't break
testnet which has various "old" registrations on it.
There is a (correct) warning in the calculation that divides by this
value that this code is doing integer division, but then storing in a
float. This fixes the warning, and the intention.
This test uses 3.5 billion iterations, and takes multiple minutes --
effectively just as long as all other test suite tests combined.
This is dumb.
Reduce the "optimized" version to increment by 83 instead of 1, the same
as the "reference" version, but add a V2_INT_SQRT_FULL_TEST=1
environment variable you can set if you really want to test your CPU
cooler.
This PR defines contributors to a service node as a small contributor if
they contribute <25% of the nodes locked contributions. If a contributor
is small then they are prevented from unlocking their stake for 30 days
after the node is registered. This was in response to operators getting
frustrated with small contributors immediately unlocking after a node
was registered.
If you imagine the following node contribution structure:
Operator: 25%
Contributor 1: 65%
Contributor 2: 10%
Total: 100%
Node is registered on day 0. On Day 1 both the operator and Contributor
1 will be able to unlock their stake and the node begins its 15 day
unlock period.
Contributor 2 however will be prevented from unlocking until day 30.
At this point they will be able to unlock and begin the nodes 15 day
unlock period.
This allows a user to query the daemon and ask for the accrued balance
of oxen rewards that have been batched but not yet paid out.
The endpoint takes in an array of addresses (Strings) and returns an
array of atomic oxen amounts (integers) that reflect the current
database balances for those requested addresses.
For example an address has accrued 2x batch payments of 16.5 oxen but
has not yet been paid out will show 33000000000 being the atomic amount
in the database.
- Replace all cryptonote_config macros with constexpr variables. Some
become integer types, some become chrono types.
- generally this involved removing a "CRYPTONOTE_" prefix since the
values are now in the `cryptonote` namespace
- some constants are grouped into sub-namespaces (e.g.
cryptonote::p2p)
- deprecated constants (i.e. for old HFs) are in the `cryptonote::old`
namespace.
- all the magic hash key domain separating strings are now in
cryptonote::hashkey::WHATEVER.
- Move some economy-related constants to oxen_economy.h instead
- Replaced the BLOCKS_EXPECTED_IN_DAYS constexpr functions with more
straightforward `BLOCKS_PER_DAY` value (i.e. old
`BLOCKS_EXPECTED_IN_DAYS(10)` is now `BLOCKS_PER_DAY * 10`.
- Replaced `network_version` unscoped enum with a scoped enum
`cryptonote::hf`, replacing all the raw uint8_t values where it was
currently accepted with the new `hf` type.
- Made `network_type` a scoped enum so that it now has to be qualified
(network_type::TESTNET) and can't be arbitrarily/unintentionally
converted to/from an int.
- HARDFORK_WHATEVER macros have become cryptonote::feature::WHATEVER
constexpr hf values.
- Add `revision` to rpc hard_fork_info response
- Don't build trezor code at all (previously we were pointlessly
building an empty dummy lib).
A fixed 3750 amount won't work on testnet (and also was set to 3750
atomic units instead of 3750 coins).
This refactor the math a bit so that the amount falls out of the portion
constant when making a registration.
Jason Rhinelander
Sean Darcy
Thomas Winget
majestrate