Monzero core node, command-line wallet, consensus code, and release tooling. https://code.monzero.org/monzero-core.git/atom?h=v0.16.0.1 2020-06-13T15:42:09Z 2020-06-13T15:42:09Z moneromooo-monero moneromooo-monero@users.noreply.github.com 2020-06-13T14:20:20Z urn:sha1:a67c634f89d3bfc492ef270a729f71ba6fb8a21e 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. 2020-04-04T17:52:46Z luigi1111 luigi1111w@gmail.com 2020-04-04T17:52:46Z urn:sha1:44547006bfcac4f807d28016d597b7e5d3693dfd fcb06f7 cryptonote_core: skip block notify on blockchain switching rollback (xiphon) 2020-02-29T03:36:16Z Alexander Blair snipa@jagtech.io 2020-02-29T03:36:16Z urn:sha1:4da37daf67976e48d6fc75f2a5a6f5858d227815 5985c5af rpc: add bad-blocks to flush_cache RPC (moneromooo-monero) 2020-02-19T16:19:29Z xiphon xiphon@protonmail.com 2020-02-19T15:17:43Z urn:sha1:fcb06f7a820f6a1efc6982a2f4b08571c4c28cf9 2019-12-12T19:47:04Z luigi1111 luigi1111w@gmail.com 2019-12-12T19:47:04Z urn:sha1:e5cc6d39a953917b18b047015d7642d019ca1e41 886ed25 blockchain: fix comment wrongly refering to SHA-3 rather than Keccak (moneromooo-monero) 2019-12-02T18:53:30Z moneromooo-monero moneromooo-monero@users.noreply.github.com 2019-12-02T18:51:28Z urn:sha1:5985c5afe8051ef9933212e62293ece3634a5024 Flushes m_invalid_blocks in Blockchain. 2019-11-02T20:36:03Z Lee Clagett code@leeclagett.com 2019-11-02T20:36:03Z urn:sha1:5d7ae2d2791c0244a221872a7ac62627abb81896 2019-10-29T11:37:08Z moneromooo-monero moneromooo-monero@users.noreply.github.com 2019-09-30T19:04:29Z urn:sha1:886ed250555a32c05757e9b86563890156d4f045 2019-10-08T20:55:03Z luigi1111 luigi1111w@gmail.com 2019-10-08T20:55:03Z urn:sha1:bf525793c724f62d4716aaca59345ba2e13a2c3c 8330e77 monerod can now sync from pruned blocks (moneromooo-monero) 2019-09-27T00:10:37Z moneromooo-monero moneromooo-monero@users.noreply.github.com 2019-09-16T12:18:34Z urn:sha1:8330e772f1ed680a54833d25c4d17d09a99ab8d6 If the peer (whether pruned or not itself) supports sending pruned blocks to syncing nodes, the pruned version will be sent along with the hash of the pruned data and the block weight. The original tx hashes can be reconstructed from the pruned txes and theur prunable data hash. Those hashes and the block weights are hashes and checked against the set of precompiled hashes, ensuring the data we received is the original data. It is currently not possible to use this system when not using the set of precompiled hashes, since block weights can not otherwise be checked for validity. This is off by default for now, and is enabled by --sync-pruned-blocks