clang-format resulted in some screwy reformatting, particularly with
post-commended fields, and also exposed various missing header includes
when re-sorting headers.
This commit contains various small fixes and improvements to deal with
the formatting issues.
This adds a new table to the batching schema to copy the accrued
balances every so often. This means that we can jump back to a
previous point without popping blocks.
The archiving is triggered in sql every 100 blocks and added to the
archive table, then pruned from the archive table at a later time to
ensure the size is kept small. Rebuilding 100 blocks is pretty
reasonable and should be less than 10s.
For longer distance pop_blocks and blockchain detached every 10k blocks
is kept in the archiving table. This takes longer to rebuild but is
better than rebuilding from scratch.
The blockchain detached function is also added to our regular blockchain
detached hooks so that it gets called every time the blockchain
detaches. Which appears to have caused some issues previously when some
of the modules would detach but batching would be stuck in an advanced
state.
The checking if the service node contributers are small miscalculated
atomic oxen. This brings in the correct figure for HF20 and in the
interim brings measures into the wallet and blink to prevent small
contributors from being to unlock in HF19.
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).
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.
- 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.
This requires the operator to still contribute 25% of the service node
but another 9 nodes will be allowed to stake to the node makeing 10
contributors total rather than our previous 4.
This updates the coinbase transactions to reward service nodes
periodically rather than every block. If you recieve a service node
reward this reward will be delayed x blocks, if you receive another
reward to the same wallet before those blocks have been completed it
will be added to your total and all will be paid out after those x
blocks has passed.
For example if our batching interval is 2 blocks:
Block 1 - Address A receives reward of 10 oxen - added to batch
Block 2 - Address A receives reward of 10 oxen - added to batch
Block 3 - Address A is paid out 20 oxen.
Batching accumulates a small reward for all nodes every block
The batching of service node rewards allows us to drip feed rewards
to service nodes. Rather than accruing each service node 16.5 oxen every
time they are pulse block leader we now reward every node the 16.5 /
num_service_nodes every block and pay each wallet the full amount that
has been accrued after a period of time (Likely 3.5 days).
To spread each payment evenly we now pay the rewards based on the
address of the recipient. This modulus of their address determines which
block the address should be paid and by setting the interval to our
service_node_batching interval we can guarantee they will be paid out
regularly and evenly distribute the payments for all wallets over this
This makes reachability testing activate at HF19. We probably want to
come back and update this before HF19, but for now we just check but
don't enforce lokinet reachability.
It works just like storage server testing.
Renames the report_peer_storage_server_status to report_peer_status, and
repurposes the code to handle both SS and lokinet.
This *doesn't* need a HF by design because the reason bit field was
deliberately designed so that we can add reason fields (older clients
will just ignore unknown bits).
This moves all the responsibility of ping testing (deciding when it's
unreachable, etc.) into oxend, allowing for better reporting on SS ping
results and eliminating some edge cases that can lead to oxend and
storage server getting "stuck" thinking each is in a different state.
This makes uptime proof times network-dependent, and tweaks them a bit.
Also converts the times to type-safe std::chrono types rather than
macros.
Mainnet/testnet/devnet:
- Send the first proof 30s after startup rather than waiting 2 minutes.
- Check for whether we need to send a proof every 30s rather than every
5mins.
Mainnet:
Other times unchanged.
Testnet/devnet:
- Send proofs every 10min instead of 1h, and consider nodes to be down
after 21m instead of 2h5m.
Fakechain:
- Send 5s after startup, check every 5s, and send every 1min.
- Expiry after 2min5s
Also remove the cmake debug option for short proofs since the fakechain
changes above basically incorporate what it did.
- A complete fix would involve setting the DIFFICULTY_WINDOW to
1 unified constant for both pre/post HF16 code. My attempts to get this
to work have not succeeded and so I'm putting this aside to allocate
more time on getting Pulse ready for testnet.
For completeness sake, I'll be copying verbatim the changes requested below.
Of the changes requested only adjusting the DIFFICULTY_WINDOW to 59 was
done (with the appropriate offset changes to the other constants that
interact with it).
The changes requested by jagerman
(from https://github.com/loki-project/loki-core/pull/1235)
Two points about this analysis:
1. Most of the comments here belong in the commit message rather than
code comments.
2. Well before I joined LOKI I worked with zawy for a good bit of time
on LWMA implementations, and so I found this description very confusing
because adding 1 is the correct thing to do for an LWMA. You need 61
observations to do a LWMA 60 because you need solve times where are
timestamp differences of adjacent blocks.
However what you describe above is also correct. So then I investigated
the disparity, and figured it out:
We don't do a proper LWMA(60) because of this: N = (DIFFICULTY_WINDOW - 1)
That is just wrong: it means we are doing a LWMA(59). But even that
isn't quite right because the resize(N+1) done in next_difficulty_v2
also throws away the top value. So what we end up calculating is
a LWMA(59) with a lag of one (that is, we throw away the most recent
usable observation).
The fix in this commit is making the math line up, but in not quite the
right away because there is still a bunch of stuff that is off by one.
Instead what we need is:
DIFFICULTY_WINDOW_V2 should be changed to 59, since that's what it is
(and has always) actually done.
DIFFICULTY_BLOCKS_COUNT_V2 should remain as DIFFICULTY_WINDOW_V2 + 1 because that's the proper number of
required blocks needed for a LWMA(DIFFICULTY_WINDOW_V2).
- the -1 should be removed from next_difficulty_v2 (so that it remains at 59, with the
above change).
- if we're on HF15 or earlier then we still need
DIFFICULTY_BLOCKS_COUNT_V2 blocks, but because of this bug they need
to be the values from blocks (H-61) through (H-2) rather than (H-60)
through (H-1).
- The // TODO: put asserts here, so that the difficulty algorithm is never
called with an oversized window (removed in this commit) should be
actually done as it should work fine with these fixes.
- Pulse blocks will forcibly get the difficulty set to
1'000'000 * TARGET_BLOCK_TIME throughout time
- When PoW is required again, the past window of blocks will use these
difficulties, i.e. setup the chain for mining at 1'000'000 difficulty
which is easily mineable to continue the network and continue to pull
difficulties from the new-er mined blocks until the network is ready
for Pulse again.
- Difficulty is still necessary for falling back to mining when Pulse
fails. Switching between the two systems seamlessly can be done by
continuing to set the difficulty for Pulse blocks.
- Keep none for blocks
- Remove HF_VERSION_PULSE and prefer network_version_16 for big features
- Keep HF_VERSION_... for smaller feature flags
- Add operator< for pulse_sort_key
- Avoid erase() in validators gen loop for pulse
Replace stagenet parameters with new devnet parameters:
- Wallet prefix is now dV[123] for regular wallets, dV[ABC] for
integrated addresses, and dV[abc] for subaddresses. Wallet length is
the same as testnet (i.e. 2 longer than mainnet).
- devnet has a single v7 genesis block (because change this is too
intrusive) and then immediately jumps to v15 at height 2.
- Moved default ports from 3805x to 3885x (to avoid conflicting with
potential existing stagenet daemons)
- DEVNET staking requirement is 1/10 of the mainnet requirement
beginning at height 600000. i.e. devnet staking requirement at height
1234 == 1/10 of mainnet requirement at height 601234. (This makes
lets devnet test out the decreasing stake, which testnet's fixed
requirement has never allowed).
Jason Rhinelander
Sean Darcy
Thomas Winget
Sean Darcy
Doyle
moneromooo-monero
Sarang Noether