| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |\
| |
| |
| |
| |
| | |
d67a8d8 build: prepare v0.18.5.1 (selsta)
ACKs: SNeedlewoods, plowsof
|
| | | |
|
| | | |
|
| |\ \
| |/
|/|
| | |
2de5e82 Fix: check hwdev.generate_output_ephemeral_keys result (SChernykh)
|
| | |
| |
| |
| | |
If it fails, out_eph_public_key and view_tag remain uninitialized.
|
| |\ \
| | |
| | |
| | | |
878c781 zmq: apply restricted-mode privacy filtering to get_transaction_pool (greatjourney589)
|
| | |/
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Add an include_sensitive parameter to tx_memory_pool::get_pool_for_rpc
(and its core passthrough), mirroring the include_sensitive_data
parameter on the HTTP analog get_transactions_and_spent_keys_info.
When false, receive_time and last_relayed_time are zeroed using the
same masking already applied on the HTTP path.
The ZMQ handler in daemon_handler.cpp passes !m_restricted, so
--restricted-zmq-rpc callers now receive the same privacy-filtered view
as restricted HTTP callers instead of the unfiltered timing metadata
they previously got. Stem-phase txs continue to be excluded regardless
(relay_category::broadcasted filter unchanged).
Refs #10529.
|
| |\ \
| | |
| | |
| | | |
3d856f4 Blockchain: fix wrong block_weight in handle_get_objects (SChernykh)
|
| | |/
| |
| |
| |
| |
| | |
- When there are missing IDs, blocks.size() != arg.blocks.size(), so arg.blocks can't be indexed by `i` - the indices will be wrong, the wrong weight will be returned to some peer and this peer will ban our node.
Use `bl.second` instead of `arg.blocks[i]`. Also it saves one DB query per returned block.
|
| |/
|
|
| |
- txid was a reference to an item which was later deleted in remove_tx_from_transient_lists(), and txid was used after that
|
| |\
| |
| |
| | |
1f1e74b build: prepare v0.18.5.0 (selsta)
|
| | | |
|
| | | |
|
| |\ \
| | |
| | |
| | | |
44412d3 cryptonote_core: add change address sanity check (jeffro256)
|
| | | |
| | |
| | |
| | |
| | |
| | | |
Prevents silly mistakes where wrong change address is passed
Release versions uses boost::optional instead of std::optional
|
| | | | |
|
| |\ \ \
| | | |
| | | |
| | | | |
73f1eaa Fix ZMQ-PUB reporting of mempool txes that were initially in stem phase (Lee Clagett)
|
| | | |/
| |/| |
|
| | |/
|/| |
|
| |/ |
|
| |\
| |
| |
| | |
f9d089a cryptonote_core: try-catch in prepare same as cleanup (j-berman)
|
| | | |
|
| |/
|
|
|
|
|
| |
Changes complexity from M*N to (2*N+M)*log2(M). The FCMP++ stressnet recently hit mempool sizes of ~55k txs.
If the requesting node's mempool is populated, this results in an average of (55000*55000)/2
(about 1.5 billion) comparisons for the responding node. Under this commit, this would be reduced to
(55000+55000)*log2(55000) comparisons (about 2.6 million), a 99.83% reduction.
|
| | |
|
| |\
| |
| |
| | |
ec34c5b build: prepare v0.18.4.5 (selsta)
|
| | | |
|
| |/
|
|
|
|
|
|
|
|
|
|
|
| |
Without this commit:
1) read height from DB
2) add block to chain in separate thread
3) read chain for block id's and request them from peer
4) ERR in handle_response_chain_entry, peer's first block is the
one that was added to the chain, which has block idx=height from
step 1.
This commit reads the chain for height and highest block id's
in one go while holding the m_blockchain_lock to avoid the race.
|
| |\
| |
| |
| | |
4e4e343 Daemon: relay empty fluffy block on found block (j-berman)
|
| | | |
|
| |/
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| | |
|
| |\
| |
| |
| | |
09f5cbb build: prepare v0.18.4.3 (selsta)
|
| | | |
|
| | | |
|
| |\ \
| |/
|/|
| | |
39c7a22 Send ZMQ miner notifications after txpool additions (WeebDataHoarder)
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Bug was introduced in c069c04ede338929c50297558fee15192aa0f67c, 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 c069c04ede338929c50297558fee15192aa0f67c / #9135
Fixes dfee15eee18a97be5a8fb9822527f98ebd1b33e9 / #7891
|
| |/ |
|
| | |
|
| | |
|
| | |
|
| |\
| |
| |
| | |
97e1a49dd checkpoints: update to a recent block height (selsta)
|
| | | |
|
| |\ \
| | |
| | |
| | | |
c7f01e57f Blockchain: remove skip for pruned txs in `check_tx_inputs()` (jeffro256)
|
| | |/
| |
| |
| |
| |
| |
| |
| |
| | |
I can't see how this would trigger in the current codebase, so it's not a *current* safety issue,
but I can very well see it becoming on in the future if downstream code doesn't handle the passing
of pruned transactions correctly. I think the safe/good choice would be to remove this skip now
that all transactions that pass into the mempool are supposed to be unpruned. And for all in-block
txs, `check_tx_inputs()` isn't called for checkpointed blocks, and we sync pruned blocks only if
syncing checkpointed blocks.
|
| |/ |
|
| |\
| |
| |
| | |
008ba966d blockchain sync: reduce disk writes from 2 to 1 per tx (jeffro256)
|
| | | |
|
| | | |
|
| |/ |
|
