Monzero core node, command-line wallet, consensus code, and release tooling. https://code.monzero.org/monzero-core.git/atom?h=v0.14.1.2 2019-04-14T08:35:38Z 2019-04-14T08:35:38Z moneromooo-monero moneromooo-monero@users.noreply.github.com 2019-04-05T09:28:30Z urn:sha1:5e673c03fec66024027b94229fa2e317d7767a20 The db txn in add_block ending caused the entire overarching batch txn to stop. Also add a new guard class so a db txn can be stopped in the face of exceptions. Also use a read only db txn in init when the db itself is read only, and do not save the max tx size in that case. 2019-03-05T21:05:34Z binaryFate binaryfate@users.noreply.github.com 2019-03-05T21:05:34Z urn:sha1:1f2930ce0bec07e28958c059444151ad4968e1e6 2019-03-05T11:57:55Z moneromooo-monero moneromooo-monero@users.noreply.github.com 2018-11-11T14:51:03Z urn:sha1:b044d03a51e1dc64bebe2461813e0cfc50f71b0d 2019-03-04T09:33:58Z moneromooo-monero moneromooo-monero@users.noreply.github.com 2019-01-21T17:18:50Z urn:sha1:b8787f430262520a9e81267802b869b1a7cde245 This curbs runaway growth while still allowing substantial spikes in block weight Original specification from ArticMine: here is the scaling proposal Define: LongTermBlockWeight Before fork: LongTermBlockWeight = BlockWeight At or after fork: LongTermBlockWeight = min(BlockWeight, 1.4*LongTermEffectiveMedianBlockWeight) Note: To avoid possible consensus issues over rounding the LongTermBlockWeight for a given block should be calculated to the nearest byte, and stored as a integer in the block itself. The stored LongTermBlockWeight is then used for future calculations of the LongTermEffectiveMedianBlockWeight and not recalculated each time. Define: LongTermEffectiveMedianBlockWeight LongTermEffectiveMedianBlockWeight = max(300000, MedianOverPrevious100000Blocks(LongTermBlockWeight)) Change Definition of EffectiveMedianBlockWeight From (current definition) EffectiveMedianBlockWeight = max(300000, MedianOverPrevious100Blocks(BlockWeight)) To (proposed definition) EffectiveMedianBlockWeight = min(max(300000, MedianOverPrevious100Blocks(BlockWeight)), 50*LongTermEffectiveMedianBlockWeight) Notes: 1) There are no other changes to the existing penalty formula, median calculation, fees etc. 2) There is the requirement to store the LongTermBlockWeight of a block unencrypted in the block itself. This is to avoid possible consensus issues over rounding and also to prevent the calculations from becoming unwieldy as we move away from the fork. 3) When the EffectiveMedianBlockWeight cap is reached it is still possible to mine blocks up to 2x the EffectiveMedianBlockWeight by paying the corresponding penalty. Note: the long term block weight is stored in the database, but not in the actual block itself, since it requires recalculating anyway for verification. 2019-01-22T20:30:51Z moneromooo-monero moneromooo-monero@users.noreply.github.com 2018-04-29T22:30:51Z urn:sha1:b750fb27b0f20e9443827732b69a504a76036430 The blockchain prunes seven eighths of prunable tx data. This saves about two thirds of the blockchain size, while keeping the node useful as a sync source for an eighth of the blockchain. No other data is currently pruned. There are three ways to prune a blockchain: - run monerod with --prune-blockchain - run "prune_blockchain" in the monerod console - run the monero-blockchain-prune utility The first two will prune in place. Due to how LMDB works, this will not reduce the blockchain size on disk. Instead, it will mark parts of the file as free, so that future data will use that free space, causing the file to not grow until free space grows scarce. The third way will create a second database, a pruned copy of the original one. Since this is a new file, this one will be smaller than the original one. Once the database is pruned, it will stay pruned as it syncs. That is, there is no need to use --prune-blockchain again, etc. 2018-12-05T21:13:18Z moneromooo-monero moneromooo-monero@users.noreply.github.com 2018-12-05T19:21:43Z urn:sha1:ce594f5af78e4722122735d67a019325f1c495cb 2018-09-11T13:38:07Z moneromooo-monero moneromooo-monero@users.noreply.github.com 2018-07-18T21:24:53Z urn:sha1:5ffb2ff9b7c301eda5811a939c705f26627c4735 2018-08-12T16:13:46Z moneromooo-monero moneromooo-monero@users.noreply.github.com 2018-08-01T10:09:35Z urn:sha1:b278b83860da5eaaa122c219ad8c63f641e41cd3 Blocks have a very wide range, whereas actual size is the relevant quantity to consider when syncing 2018-07-13T10:37:04Z moneromooo-monero moneromooo-monero@users.noreply.github.com 2018-05-22T13:46:30Z urn:sha1:45e419bd5c756337635feccec388efedf04f44ac This gets rid of the temporary precalc cache. Also make the RPC able to send data back in binary or JSON, since there can be a lot of data This bumps the LMDB database format to v3, with migration. 2018-05-23T21:48:12Z moneromooo-monero moneromooo-monero@users.noreply.github.com 2017-10-01T10:24:33Z urn:sha1:b9389e582eb4e1806ce25a14fa492259c3d40dfc This bumps DB version to 2, migration code will run for v1 DBs