Otherwise we can end up double counting txs towards the weight,
which can over-state the pool weight. E.g. relay tx to node in
stem phase, add its weight to pool weight, then receive tx
from another node, then bump the pool weight again. That double
counts the tx towards the pool weight.
If the weight exceeds the max, the node will "prune" txs from the
pool. Thus, over-counting is probably a cause of, but perhaps
not the only cause of:
https://github.com/seraphis-migration/monero/issues/148
Deferencing the result of `std::max_element()` when `res.connections` has 0 elements leads to UB, and segfaults in practice.
Co-authored-by: iamamyth <user@example.com>
Bug was introduced in c069c04ede, before this txpool additions were not notified on block addition
When receiving blocks with previously unknown conditions, miner data was sent first, but txpool add events for already-added transactions in previous block were sent afterward. Miners would then include already-mined transactions in their new templates due to receiving the mistimed txpool add event.
The fix is to send miner notifications AFTER txpool events are sent, and before normal block notifications are sent (for mining switch speed purposes)
Fixes c069c04ede / #9135
Fixes dfee15eee1 / #7891
A reorg can end up causing an output's position in the chain to
move. Since the wallet doesn't update the RingDB on reorg, it
may refer to the output's stale position in the chain.
This seems a reasonable solution rather than introducing complex
logic to update the stale ring member's value on rerog, since
RingDB can be deprecated with FCMP++.
- Make sure to mark identified spends in the pool as spends. The
wallet might not know these have been spent if it wasn't the wallet
that relayed the tx to the daemon, or the wallet was cleared via
rescan_bc.
- Make sure to add spends to m_unconfirmed_txs if not present.
- Make sure to process the entire pool again if refreshing for
the first time. The wallet fetches pool and blocks at the same
time. The wallet scans blocks first, then pool. If the wallet
identifies received outputs in the chain, then it may have spent
those received outputs in the pool. So we make sure to re-process
the entire pool again after scanning the chain for the first time.
- Multisig wallets that know about spent key images can now detect
spend txs in the pool. Update tests for that.
Signed-off-by: Arthur Chan <arthur.chan@adalogics.com>
Add macro definition for fuzzers
Signed-off-by: Arthur Chan <arthur.chan@adalogics.com>
Fix FuzzedDataProvider header missing problem
Signed-off-by: Arthur Chan <arthur.chan@adalogics.com>
Add README
Signed-off-by: Arthur Chan <arthur.chan@adalogics.com>
Provide static FuzzedDataProvider.h
Signed-off-by: Arthur Chan <arthur.chan@adalogics.com>
Update and enhance fuzzer
Signed-off-by: Arthur Chan <arthur.chan@adalogics.com>
Activate UBSan
Signed-off-by: Arthur Chan <arthur.chan@adalogics.com>
Fix fuzz target retrieval
Signed-off-by: Arthur Chan <arthur.chan@adalogics.com>
Remove bias selector and fix protocol lifespan
Signed-off-by: Arthur Chan <arthur.chan@adalogics.com>
Drop SIGALARM handling and fix bug on selectors
Signed-off-by: Arthur Chan <arthur.chan@adalogics.com>
Fix rpc request changes
Signed-off-by: Arthur Chan <arthur.chan@adalogics.com>
Add a new fuzzer profile that catch all expcetions
Signed-off-by: Arthur Chan <arthur.chan@adalogics.com>
Fix typo
Signed-off-by: Arthur Chan <arthur.chan@adalogics.com>
Add warning
Signed-off-by: Arthur Chan <arthur.chan@adalogics.com>
Fix four issues with wallet_keys_unlocker:
1. It won't decrypt if there are unlockers open simulataneously on multiple `wallet2` instances
2. It won't decrypt if the first unlocker was disabled (i.e. `locked=false`), even with a second non-disabled unlocker
3. If a destructor of an earlier unlocker is triggered before the destructor of a later unlocker, it will re-encrypt too early, while the second unlocker is still in scope
4. Calling the 3-parameter constructor with `locked=true` after an unlocker already exists will "double-encrypt" the spend key after its destructor since the local variable is `locked=false` and the field member is `locked=true`
Also, replace `wallet2::decrypt_account_for_multisig` with `wallet_keys_unlocker`.
