| Commit message (Collapse) | Author | Age | Files | Lines |
| |\
| |
| |
| | |
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)
|
| | | |
|
| | | |
|
| |/ |
|
| |\
| |
| |
| | |
4d2aad837 Revert "blockchain: detect and log bad difficulty calculations" (selsta)
|
| | |
| |
| |
| | |
This reverts commit 5741b4d74de542f6f75dddad8125f4c4a5ad9143.
|
| |\ \
| |/
|/|
| | |
41c4bc4 Blockchain: get height of RingCT fork programmatically (jeffro256)
|
| | |
| |
| |
| |
| |
| | |
Get height of the RingCT fork to start the output distributuon programmatically, instead of using a hardcoded index.
If using a hardcoded index, when the hardfork tables are modified, this can cause segmentation faults or horrific privacy issues: https://codeberg.org/wownero/wownero/issues/488#issuecomment-2514880.
|
| |\ \
| |/
|/|
| | |
f0a574c Blockchain: fix temp fails causing alt blocks to be permanently invalid (jeffro256)
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
[RELEASE]
1. Use std::is_standard_layout and std::is_trivially_copyable instead of std::is_pod for KV byte-wise serialization, which fixes compile issue for Boost UUIDs
2. Removed reimplementation of std::hash for boost::uuids::uuid
3. Removed << operator overload for crypto::secret_key
4. Removed instances in code where private view key was dumped to the log in plaintext
Release version of #9450, containing C++14 modified assertions
|
| |/ |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Related to https://github.com/monero-project/research-lab/issues/78
Added a relay rule that enforces the `unlock_time` field is equal to 0 for non-coinbase transactions.
UIs changed:
* Removed `locked_transfer` and `locked_sweep_all` commands from `monero-wallet-cli`
APIs changed:
* Removed `unlock_time` parameters from `wallet2` transfer methods
* Wallet RPC transfer endpoints send error codes when requested unlock time is not 0
* Removed `unlock_time` parameters from `construct_tx*` cryptonote core functions
@tobtoht: undo rebase changes tx.dsts -> tx_dsts
|
| | |
|
| |
|
|
|
| |
- Fixed undefined behavior after a call to `remove_tx_from_transient_lists` (it used an invalid iterator)
- Fixed `txCompare` (it wasn't strictly weak ordered)
|
| |\
| |
| |
| | |
36ee12b get_block_template_backlog: better sorting logic (SChernykh)
|
| | |
| |
| |
| | |
std::sort is unstable, so it can return random sets of transactions when mempool has many transactions with the same fee/byte. It can result in p2pool mining empty blocks sometimes because it doesn't pick up "new" transactions immediately.
|
| |/
|
|
|
| |
Nodes who see different txs in a double spend attack will drop each other, splitting the network.
Issue found by @boog900.
|
| |\
| |
| |
| | |
f2360a7 build: prepare v0.18.3.2 (selsta)
|
| | | |
|
| |/ |
|
| |\
| |
| |
| |
| | |
69de381 add a test for the long term weight cache (Boog900)
810f6a6 Fix: long term block weight cache The long term block weight cache was doing a wrong calculation when adding a new block to the cache. (Boog900)
|
| | |
| |
| |
| |
| | |
The long term block weight cache was doing a wrong calculation when
adding a new block to the cache.
|
| |/ |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
[release-v0.18]
- `/getblocks.bin` respects the `RESTRICTED_TX_COUNT` (=100) when
returning pool txs via a restricted RPC daemon.
- A restricted RPC daemon includes a max of `RESTRICTED_TX_COUNT` txs
in the `added_pool_txs` field, and returns any remaining pool hashes
in the `remaining_added_pool_txids` field. The client then requests
the remaining txs via `/gettransactions` in chunks.
- `/gettransactions` no longer does expensive no-ops for ALL pool txs
if the client requests a subset of pool txs. Instead it searches for
the txs the client explicitly requests.
- Reset `m_pool_info_query_time` when a user:
(1) rescans the chain (so the wallet re-requests the whole pool)
(2) changes the daemon their wallets points to (a new daemon would
have a different view of the pool)
- `/getblocks.bin` respects the `req.prune` field when returning
pool txs.
- Pool extension fields in response to `/getblocks.bin` are optional
with default 0'd values.
|
| |
|
|
| |
[release-v0.18]
|
| |
|
|
| |
reported by sech1
|
| |\
| |
| |
| | |
4f1262b build: prepare v0.18.2.2 (selsta)
|
| | | |
|
| |/
|
|
|
|
| |
Also: txs with tx_extra which is too large will not get published to ZMQ
Co-authored-by: SChernykh <sergey.v.chernykh@gmail.com>
|
| |\
| |
| |
| | |
cdeb286 build: prepare v0.18.2.1 (selsta)
|