| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| |\ \
| | |
| | |
| | | |
402dd207 db_lmdb: guard against non NUL terminated keys (moneromooo-monero)
|
| | |/ |
|
| | | |
|
| |/ |
|
| |
|
|
| |
as opposed to an absent record
|
| |\
| |
| |
| | |
8330e77 monerod can now sync from pruned blocks (moneromooo-monero)
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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
|
| |\ \
| |/
|/|
| | |
f9b3f6e Removed Berkeley DB and db switching logic (JesusRami)
|
| | | |
|
| |/ |
|
| |
|
|
|
| |
We've added a lot of new indices recently, and 20 isn't enough for them plus
new DBs opened during format migrations.
|
| |\
| |
| |
| | |
06b8f29 blockchain: keep alternative blocks in LMDB (moneromooo-monero)
|
| | |
| |
| |
| |
| | |
Alternative blocks are cleared on startup unless --keep-alt-blocks
is passed on the command line
|
| |\ \
| | |
| | |
| | |
| | | |
25a7cfd add a few checks where it seems appropriate (moneromooo-monero)
1a66a86 remove unused code (moneromooo-monero)
|
| | |/ |
|
| | |
| |
| |
| | |
to avoid errors when the txn is too large
|
| | |
| |
| |
| |
| | |
NULL is valid when size is 0, but memcpy uses nonnull attributes,
so let's not poke the bear
|
| | | |
|
| |/ |
|
| |
|
|
| |
and delete obsolete BlockchainBDB::get_tx_output_indices along the way
|
| |
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
| |
Use the actual block weight limit, assuming that weight is always
greater or equal to size
|
| |
|
|
|
|
| |
Based on Boolberry work by:
jahrsg <jahr@jahr.me>
cr.zoidberg <crypto.zoidberg@gmail.com>
|
| |\
| |
| |
| | |
4b21d38d blockchain: speed up getting N blocks weights/long term weights (moneromooo-monero)
|
| | | |
|
| |/ |
|
| |\
| |
| |
| | |
f024a10b db_lmdb: make mdb_block_info format conversion more future proof (moneromooo-monero)
|
| | |
| |
| |
| |
| | |
If mdb_block_info changes again, the v2 to v3 conversion would
convert to an incorrect format.
|
| | | |
|
| | | |
|
| |/
|
|
| |
by avoiding repeated (de)serialization
|
| |\
| |
| |
| | |
d78addcb db_lmdb: don't unnecessarily cast to double on the way to uint64_t (moneromooo-monero)
|
| | | |
|
| |\ \
| | |
| | |
| | | |
85088d9f db_lmdb: fix missing mdb_dbi_close in migration (moneromooo-monero)
|
| | | |
| | |
| | |
| | | |
Fixed by hyc
|
| |/ /
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
| |/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
| |
Since the commitment has to be calculated for non rct outputs,
it slows down a lot unnecessarily if we don't need it
|
| |\
| |
| |
| | |
008647d7 blockchain_db: speedup tx output gathering (moneromooo-monero)
|
| | |
| |
| |
| | |
We know all the data we'll want for getblocks.bin is contiguous
|
| | |
| |
| |
| |
| |
| | |
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.
|
| |\ \
| |/
|/|
| |
| |
| |
| |
| |
| | |
6644b9b blockchain_db: remove a couple unused functions (moneromooo-monero)
ce594f5 blockchain_db: allocate known size vector only once (moneromooo-monero)
8332698 db_lmdb: inline check_open, it's trivial and called everywhere (moneromooo-monero)
5511563 db_lmdb: avoid pointless division (moneromooo-monero)
d1efe3d cryptonote: set tx hash on newly parsed txes when known (moneromooo-monero)
9cc68a2 tx_pool: add a few std::move where it can make a difference (moneromooo-monero)
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| |\ \
| |/
|/|
| |
| | |
a48f2dab blockchain_prune_known_spent_data: blackball file is now optional (moneromooo-monero)
17b45725 Outputs where all amounts are known spent can now be pruned (moneromooo-monero)
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
| |\ \
| | |
| | |
| | | |
fc99f177 lmdb: fix gcc 7.3.0 'implicit-fallthrough' warning (xiphon)
|
| | | | |
|