Monzero core node, command-line wallet, consensus code, and release tooling. https://code.monzero.org/monzero-core.git/atom?h=v0.15.0.1 2019-10-25T16:56:55Z 2019-10-25T16:56:55Z moneromooo-monero moneromooo-monero@users.noreply.github.com 2019-10-25T16:56:55Z urn:sha1:174a6ac9c581a8ec73f57170650cd0becf400ef7 Coverity 205394 2019-10-22T15:18:28Z luigi1111 luigi1111w@gmail.com 2019-10-22T15:18:28Z urn:sha1:426d2ac8ee9b3be3a06b057b750826496d1c0950 88c9d90 protocol: initialize block_weight in block_complete_entry ctor (moneromooo-monero) fe443bb cryptonote: don't leave block_weight uninitialized (moneromooo-monero) 1ba9baf tx_pool: do not divide by 0 (moneromooo-monero) 2019-10-22T15:06:10Z luigi1111 luigi1111w@gmail.com 2019-10-22T15:06:10Z urn:sha1:6f202844b5550b28674b27998cd2edc23c9735fe 01f660f blockchain: fill in cumulative block weight for alt blocks (moneromooo-monero) 2019-10-16T18:51:34Z luigi1111 luigi1111w@gmail.com 2019-10-16T18:51:34Z urn:sha1:461a25e1b5d41fe65c46f27426fd883efd664574 ec14abd tx_pool: make spent return-by-reference as intended (stoffu) 2019-10-11T14:09:31Z moneromooo-monero moneromooo-monero@users.noreply.github.com 2019-10-11T10:46:24Z urn:sha1:1ba9bafd3331f6534242e682bafbd6d863be42ed In case of a 0 tx weight, we use a placeholder value to insert in the fee-per-byte set. This is used for pruning and mining, and those txes are pruned, so will not be too large, nor added to the block template if mining, so this is safe. CID 204465 2019-10-10T20:26:40Z moneromooo-monero moneromooo-monero@users.noreply.github.com 2019-09-17T17:03:28Z urn:sha1:01f660f60fc95449130f0b6ffdb3931a6173c838 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-10-06T03:28:30Z stoffu stoffu@protonmail.ch 2019-10-06T03:28:30Z urn:sha1:ec14abdbe880f5986fd2096fc3991f1fd2d217bd 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 2019-08-28T14:46:31Z Tom Smeding tom.smeding@gmail.com 2019-08-28T14:46:31Z urn:sha1:6bbc646e6f517185344821345459e0dc89ca2c1d The 98th percentile position in the agebytes map was incorrectly calculated: it assumed the transactions in the mempool all have unique timestamps at second-granularity. This commit fixes this by correctly finding the right cumulative number of transactions in the map suffix. This bug could lead to an out-of-bounds write in the rare case that all transactions in the mempool were received (and added to the mempool) at a rate of at least 50 transactions per second. (More specifically, the number of *unique* receive_time values, which have second- granularity, must be at most 2% of the number of transactions in the mempool for this crash to trigger.) If this condition is satisfied, 'it' points to *before* the agebytes map, 'delta' gets a nonsense value, and the value of 'i' in the first stats.histo-filling loop will be out of bounds of stats.histo.