Commit graph

8 commits

Author SHA1 Message Date
moneromooo-monero
b8787f4302
ArticMine's new block weight algorithm
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-03-04 09:33:58 +00:00
moneromooo-monero
a6216d1ac2
blockchain_db: allow getting output keys without commitment
Since the commitment has to be calculated for non rct outputs,
it slows down a lot unnecessarily if we don't need it
2019-01-16 20:13:08 +00:00
Riccardo Spagni
9d57ee9ff6
Merge pull request #4984
008647d7 blockchain_db: speedup tx output gathering (moneromooo-monero)
2019-01-16 19:06:07 +02:00
moneroexamples
ec68cf822f Make get_output_key method const
get_output_key method is commonly used when working with txs and their key images. Because the method is not const, passing blockchain object though const& or pointers to const is not possible in this context. This is especially problematic in external projects (e.g., projects in moneroexamples) that use monero C++ api to operate on the blockchain and txs.

Thus, having get_output_key method will simplify moving blockchain object around through const references and pointers to const objects.
2019-01-07 05:53:14 +08:00
moneromooo-monero
008647d7eb
blockchain_db: speedup tx output gathering
We know all the data we'll want for getblocks.bin is contiguous
2018-12-18 11:55:21 +00:00
moneromooo-monero
17b45725af
Outputs where all amounts are known spent can now be pruned
Only for pre rct for obvious reasons.

Note: DO NOT use a known spent list which includes outputs
which are not known spent. If the list includes any output
that's just strongly thought to be spent, but not provably
so, you risk finding yourself unable to sync past the point
where that output is spent.

I estimate only 200 MB saved on current mainnet though,
unless the new blackballing rule unearths a good amount of
large-amount-set extra spent outs.
2018-11-27 15:45:42 +00:00
moneromooo-monero
fc98f7a0a1
rpc: speedup get_outs.bin 2018-11-26 18:56:23 +00:00
moneromooo-monero
31d80027b5
tests: add unit tests for get_output_distribution 2018-11-16 19:21:45 +00:00