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-11T11:07:58Z 2019-04-11T11:07:58Z moneromooo-monero moneromooo-monero@users.noreply.github.com 2019-03-23T16:20:08Z urn:sha1:064ab123401814b755c776d8e53f132f6a151657 Related to emission, reorgs, getting tx data back, output distribution and histogram 2019-03-05T21:05:34Z binaryFate binaryfate@users.noreply.github.com 2019-03-05T21:05:34Z urn:sha1:1f2930ce0bec07e28958c059444151ad4968e1e6 2019-03-05T11:58:13Z moneromooo-monero moneromooo-monero@users.noreply.github.com 2018-11-23T11:15:04Z urn:sha1:238401d4e950dad6a243fb895027dd26d2992ee6 2019-03-05T11:57:57Z moneromooo-monero moneromooo-monero@users.noreply.github.com 2018-11-12T23:22:20Z urn:sha1:f75d51abda4c83ef58236bdc217f5a4c967084d2 2019-03-04T11:48:39Z moneromooo-monero moneromooo-monero@users.noreply.github.com 2019-02-06T17:09:28Z urn:sha1:d4fb9641e0a84ac6d6acb7d7f322ca22b8412a89 This runs a command whenever the block rate deviates too much from the expectation 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-18T11:55:21Z moneromooo-monero moneromooo-monero@users.noreply.github.com 2018-12-16T13:28:49Z urn:sha1:008647d7eb8f0bd72f7a9f8a49fe611fc4d5e0fe We know all the data we'll want for getblocks.bin is contiguous 2018-12-12T09:53:10Z Riccardo Spagni ric@spagni.net 2018-12-12T09:53:10Z urn:sha1:dde1e697236030cdb433d340c3606e0787cd45d9 3dba7f25 protocol: option to pad transaction relay to the next kB (moneromooo-monero) 2018-12-04T15:33:19Z Riccardo Spagni ric@spagni.net 2018-12-04T15:33:18Z urn:sha1:81418cb281c44481fc4137257df8e39623d94885 aee7a4e3 wallet_rpc_server: do not use RPC data if the call failed (moneromooo-monero) 1a0733e5 windows_service: fix memory leak (moneromooo-monero) 0dac3c64 unit_tests: do not rethrow a copy of an exception (moneromooo-monero) 5d9915ab cryptonote: fix get_unit for non default settings (moneromooo-monero) d4f50cb1 remove some unused code (moneromooo-monero) 61163971 a few minor (but easy) performance tweaks (moneromooo-monero) 30023074 tests: slow_memmem now returns size_t (moneromooo-monero)