Implements view tags as proposed by @UkoeHB in MRL issue
https://github.com/monero-project/research-lab/issues/73
At tx construction, the sender adds a 1-byte view tag to each
output. The view tag is derived from the sender-receiver
shared secret. When scanning for outputs, the receiver can
check the view tag for a match, in order to reduce scanning
time. When the view tag does not match, the wallet avoids the
more expensive EC operations when deriving the output public
key using the shared secret.
This comment suggests this check is unnecessary, when it is completely necessary as miner TXs can have multiple outputs *which is a statement directly, and incorrectly, contradicted by this comment*. While I don't ever see someone removing this code and getting their edits merged into Monero, someone inexperienced who thinks they're cleaning old code may break their own work, and then there's really just zero benefit to keeping this around.
avoids mining txes after a fork that are invalid by this fork's
rules, but were valid by the previous fork rules at the time
they were verified and added to the txpool.
Adds the following:
- "get_miner_data" to RPC API
- "json-miner-data" to ZeroMQ subscriber contexts
Both provide the necessary data to create a custom block template. They are used by p2pool.
Data provided:
- major fork version
- current height
- previous block id
- RandomX seed hash
- network difficulty
- median block weight
- coins mined by the network so far
- mineable mempool transactions
There are quite a few variables in the code that are no longer
(or perhaps never were) in use. These were discovered by enabling
compiler warnings for unused variables and cleaning them up.
In most cases where the unused variables were the result
of a function call the call was left but the variable
assignment removed, unless it was obvious that it was
a simple getter with no side effects.
Miners with MLSAG txes which they'd already verified included
a couple in that block, but the consensus rules had changed
in the meantime, so that block is technically invalid and any
node which did not already have those two txes in their txpool
could not sync. Grandfather them in, since it has no effect in
practice.
d20ff4f64 functional_tests: add a large (many randomx epochs) p2p reorg test (moneromooo-monero)
6a0b3b1f8 functional_tests: add randomx tests (moneromooo-monero)
9d42649d5 core: fix mining from a block that's not the current top (moneromooo-monero)
The cache is discarded when a block is popped, but then gets
rebuilt when the difficulty for next block is requested.
While this is all properly locked, it does not take into account
the delay caused by a database transaction being only committed
(and thus its effects made visible to other threads) later on,
which means another thread could request difficulty between
the pop and the commit, which would end up using stale database
view to build the cache, but that cache would not be invalidated
again when the transaction gets committed, which would cause the
cache to not match the new database data.
To fix this, we now keep track of when the cache is invalidated
so we can invalidate it again upon database transaction commit
to ensure it gets calculated again with fresh data next time it
is nedeed.
luigi1111