d0s3t3ch/wownero
1
0
Fork 0
mirror of https://git.wownero.com/wownero/wownero.git synced 2024-08-15 01:03:23 +00:00
Code Issues Projects Releases Wiki Activity
wownero/src/blockchain_utilities/CMakeLists.txt

334 lines
8.2 KiB
CMake
Raw Normal View History

Update copyright year to 2020 Update copyright year to 2020
2020-05-07 02:36:54 +00:00
# Copyright (c) 2014-2020, The Monero Project
very, VERY primitive blockchain converter hard-coded config folder, hard-coded BlockchainDB subclass. Needs finessing, but should be testable this way. update for rebase (warptangent 2015-01-04) fix conflicts with upstream CMakeLists.txt files src/CMakeLists.txt (edit original commit) src/blockchain_converter/CMakeLists.txt (add)
2014-11-02 00:55:22 +00:00
#
# All rights reserved.
#
# Redistribution and use in source and binary forms, with or without modification, are
# permitted provided that the following conditions are met:
#
# 1. Redistributions of source code must retain the above copyright notice, this list of
# conditions and the following disclaimer.
#
# 2. Redistributions in binary form must reproduce the above copyright notice, this list
# of conditions and the following disclaimer in the documentation and/or other
# materials provided with the distribution.
#
# 3. Neither the name of the copyright holder nor the names of its contributors may be
# used to endorse or promote products derived from this software without specific
# prior written permission.
#
# THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY
# EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
# MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL
# THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
# SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
# PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
# INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT,
# STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF
# THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
Add blockchain_import utility This imports to the blockchain database from an exported blockchain file. It can be used to bootstrap a new database or to add blocks to an existing one. Supports: - both the in-memory and LMDB implementations - optional: batching, verification, testnet See help for usage. Based on work by tomerkon. See https://github.com/tomerkon src/cryptonote_core/bootfileloader.{h,cpp}
2015-02-10 23:13:32 +00:00
set(blockchain_import_sources
blockchain_import.cpp
Update blockchain utilities with portable bootstrap file format Remove repeated coinbase tx in each exported block's data. Add resume from last exported height to blockchain_export, making it the default behavior when the file already exists. Start reorganizing the utilities. Various cleanup. Update output, including referring to both height and block numbers as zero-based instead of one-based. This better matches the block data, rather than just some parts of the existing codebase. Use smaller default batch sizes for importer when verifying, so progress is saved more frequently. Use small default batch size (1000) for importer on Windows, due to current issue with big transaction sizes on LMDB. file format ----------- [4-byte magic | variable-length header | block data] header ------ 4-byte file_info length file_info struct file format major version file format minor version header length (includes file_info struct) [rest of header, padded with 0 bytes up to header length] block data ---------- 4-byte chunk/block_package length block_package struct block txs (coinbase/miner tx included already in block) block_size cumulative_difficulty coins_generated 4-byte chunk/block_package length block_package struct [...]
2015-05-08 20:46:26 +00:00
bootstrap_file.cpp
blockchain_export can now export to a blocks.dat format Also make the number of blocks endian independant, and add support for testnet
2015-10-16 18:45:35 +00:00
blocksdat_file.cpp
Add blockchain_import utility This imports to the blockchain database from an exported blockchain file. It can be used to bootstrap a new database or to add blocks to an existing one. Supports: - both the in-memory and LMDB implementations - optional: batching, verification, testnet See help for usage. Based on work by tomerkon. See https://github.com/tomerkon src/cryptonote_core/bootfileloader.{h,cpp}
2015-02-10 23:13:32 +00:00
)
set(blockchain_import_private_headers
Update blockchain utilities with portable bootstrap file format Remove repeated coinbase tx in each exported block's data. Add resume from last exported height to blockchain_export, making it the default behavior when the file already exists. Start reorganizing the utilities. Various cleanup. Update output, including referring to both height and block numbers as zero-based instead of one-based. This better matches the block data, rather than just some parts of the existing codebase. Use smaller default batch sizes for importer when verifying, so progress is saved more frequently. Use small default batch size (1000) for importer on Windows, due to current issue with big transaction sizes on LMDB. file format ----------- [4-byte magic | variable-length header | block data] header ------ 4-byte file_info length file_info struct file format major version file format minor version header length (includes file_info struct) [rest of header, padded with 0 bytes up to header length] block data ---------- 4-byte chunk/block_package length block_package struct block txs (coinbase/miner tx included already in block) block_size cumulative_difficulty coins_generated 4-byte chunk/block_package length block_package struct [...]
2015-05-08 20:46:26 +00:00
bootstrap_file.h
blockchain_export can now export to a blocks.dat format Also make the number of blocks endian independant, and add support for testnet
2015-10-16 18:45:35 +00:00
blocksdat_file.h
Update blockchain utilities with portable bootstrap file format Remove repeated coinbase tx in each exported block's data. Add resume from last exported height to blockchain_export, making it the default behavior when the file already exists. Start reorganizing the utilities. Various cleanup. Update output, including referring to both height and block numbers as zero-based instead of one-based. This better matches the block data, rather than just some parts of the existing codebase. Use smaller default batch sizes for importer when verifying, so progress is saved more frequently. Use small default batch size (1000) for importer on Windows, due to current issue with big transaction sizes on LMDB. file format ----------- [4-byte magic | variable-length header | block data] header ------ 4-byte file_info length file_info struct file format major version file format minor version header length (includes file_info struct) [rest of header, padded with 0 bytes up to header length] block data ---------- 4-byte chunk/block_package length block_package struct block txs (coinbase/miner tx included already in block) block_size cumulative_difficulty coins_generated 4-byte chunk/block_package length block_package struct [...]
2015-05-08 20:46:26 +00:00
bootstrap_serialization.h
Add blockchain_import utility This imports to the blockchain database from an exported blockchain file. It can be used to bootstrap a new database or to add blocks to an existing one. Supports: - both the in-memory and LMDB implementations - optional: batching, verification, testnet See help for usage. Based on work by tomerkon. See https://github.com/tomerkon src/cryptonote_core/bootfileloader.{h,cpp}
2015-02-10 23:13:32 +00:00
)
Dropped "bit" from bitmonero.
2016-09-26 14:42:29 +00:00
monero_private_headers(blockchain_import
Add blockchain_import utility This imports to the blockchain database from an exported blockchain file. It can be used to bootstrap a new database or to add blocks to an existing one. Supports: - both the in-memory and LMDB implementations - optional: batching, verification, testnet See help for usage. Based on work by tomerkon. See https://github.com/tomerkon src/cryptonote_core/bootfileloader.{h,cpp}
2015-02-10 23:13:32 +00:00
${blockchain_import_private_headers})
Add blockchain_export utility Based on work by tomerkon. See https://github.com/tomerkon/bitmonero src/cryptonote_core/bootfilesaver.{h,cpp} src/bootfilegen/bootfilegen.cpp
2015-02-16 12:20:55 +00:00
set(blockchain_export_sources
blockchain_export.cpp
Update blockchain utilities with portable bootstrap file format Remove repeated coinbase tx in each exported block's data. Add resume from last exported height to blockchain_export, making it the default behavior when the file already exists. Start reorganizing the utilities. Various cleanup. Update output, including referring to both height and block numbers as zero-based instead of one-based. This better matches the block data, rather than just some parts of the existing codebase. Use smaller default batch sizes for importer when verifying, so progress is saved more frequently. Use small default batch size (1000) for importer on Windows, due to current issue with big transaction sizes on LMDB. file format ----------- [4-byte magic | variable-length header | block data] header ------ 4-byte file_info length file_info struct file format major version file format minor version header length (includes file_info struct) [rest of header, padded with 0 bytes up to header length] block data ---------- 4-byte chunk/block_package length block_package struct block txs (coinbase/miner tx included already in block) block_size cumulative_difficulty coins_generated 4-byte chunk/block_package length block_package struct [...]
2015-05-08 20:46:26 +00:00
bootstrap_file.cpp
blockchain_export can now export to a blocks.dat format Also make the number of blocks endian independant, and add support for testnet
2015-10-16 18:45:35 +00:00
blocksdat_file.cpp
Add blockchain_export utility Based on work by tomerkon. See https://github.com/tomerkon/bitmonero src/cryptonote_core/bootfilesaver.{h,cpp} src/bootfilegen/bootfilegen.cpp
2015-02-16 12:20:55 +00:00
)
set(blockchain_export_private_headers
Update blockchain utilities with portable bootstrap file format Remove repeated coinbase tx in each exported block's data. Add resume from last exported height to blockchain_export, making it the default behavior when the file already exists. Start reorganizing the utilities. Various cleanup. Update output, including referring to both height and block numbers as zero-based instead of one-based. This better matches the block data, rather than just some parts of the existing codebase. Use smaller default batch sizes for importer when verifying, so progress is saved more frequently. Use small default batch size (1000) for importer on Windows, due to current issue with big transaction sizes on LMDB. file format ----------- [4-byte magic | variable-length header | block data] header ------ 4-byte file_info length file_info struct file format major version file format minor version header length (includes file_info struct) [rest of header, padded with 0 bytes up to header length] block data ---------- 4-byte chunk/block_package length block_package struct block txs (coinbase/miner tx included already in block) block_size cumulative_difficulty coins_generated 4-byte chunk/block_package length block_package struct [...]
2015-05-08 20:46:26 +00:00
bootstrap_file.h
blockchain_export can now export to a blocks.dat format Also make the number of blocks endian independant, and add support for testnet
2015-10-16 18:45:35 +00:00
blocksdat_file.h
Update blockchain utilities with portable bootstrap file format Remove repeated coinbase tx in each exported block's data. Add resume from last exported height to blockchain_export, making it the default behavior when the file already exists. Start reorganizing the utilities. Various cleanup. Update output, including referring to both height and block numbers as zero-based instead of one-based. This better matches the block data, rather than just some parts of the existing codebase. Use smaller default batch sizes for importer when verifying, so progress is saved more frequently. Use small default batch size (1000) for importer on Windows, due to current issue with big transaction sizes on LMDB. file format ----------- [4-byte magic | variable-length header | block data] header ------ 4-byte file_info length file_info struct file format major version file format minor version header length (includes file_info struct) [rest of header, padded with 0 bytes up to header length] block data ---------- 4-byte chunk/block_package length block_package struct block txs (coinbase/miner tx included already in block) block_size cumulative_difficulty coins_generated 4-byte chunk/block_package length block_package struct [...]
2015-05-08 20:46:26 +00:00
bootstrap_serialization.h
Add blockchain_export utility Based on work by tomerkon. See https://github.com/tomerkon/bitmonero src/cryptonote_core/bootfilesaver.{h,cpp} src/bootfilegen/bootfilegen.cpp
2015-02-16 12:20:55 +00:00
)
Dropped "bit" from bitmonero.
2016-09-26 14:42:29 +00:00
monero_private_headers(blockchain_export
Add blockchain_export utility Based on work by tomerkon. See https://github.com/tomerkon/bitmonero src/cryptonote_core/bootfilesaver.{h,cpp} src/bootfilegen/bootfilegen.cpp
2015-02-16 12:20:55 +00:00
${blockchain_export_private_headers})
blockchain_utilities: new blockchain_blackball tool It scans for known spent outputs and stores their public keys in a database which can then be read by the wallet, which can then avoid using those as fake outs in new transactions. Usage: monero-blockchain-blackball db1 db2... This uses the shared database in ~/.shared-ringdb
2018-02-26 16:39:40 +00:00
set(blockchain_blackball_sources
blockchain_blackball.cpp
)
set(blockchain_blackball_private_headers
bootstrap_file.h
blocksdat_file.h
bootstrap_serialization.h
)
monero_private_headers(blockchain_blackball
${blockchain_blackball_private_headers})
new blockchain_usage tool, reports on output usage
2018-02-27 12:54:28 +00:00
set(blockchain_usage_sources
blockchain_usage.cpp
)
set(blockchain_usage_private_headers)
monero_private_headers(blockchain_usage
${blockchain_usage_private_headers})
blockchain_utilities: new blockchain_blackball tool It scans for known spent outputs and stores their public keys in a database which can then be read by the wallet, which can then avoid using those as fake outs in new transactions. Usage: monero-blockchain-blackball db1 db2... This uses the shared database in ~/.shared-ringdb
2018-02-26 16:39:40 +00:00
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-24 14:49:04 +00:00
set(blockchain_prune_known_spent_data_sources
blockchain_prune_known_spent_data.cpp
)
set(blockchain_prune_known_spent_data_private_headers)
monero_private_headers(blockchain_prune_known_spent_data
${blockchain_prune_known_spent_data_private_headers})
Pruning 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-04-29 22:30:51 +00:00
set(blockchain_prune_sources
blockchain_prune.cpp
)
set(blockchain_prune_private_headers)
monero_private_headers(blockchain_prune
${blockchain_prune_private_headers})
blockchain_ancestry: finds all ancestors of a tx, block, or chain
2018-07-16 15:27:52 +00:00
set(blockchain_ancestry_sources
blockchain_ancestry.cpp
)
set(blockchain_ancestry_private_headers)
monero_private_headers(blockchain_ancestry
${blockchain_ancestry_private_headers})
blockchain_depth: get the average min depth of a set of txes
2018-07-10 18:56:05 +00:00
set(blockchain_depth_sources
blockchain_depth.cpp
)
set(blockchain_depth_private_headers)
monero_private_headers(blockchain_depth
${blockchain_depth_private_headers})
Add stats utility Report statistics from a blockchain DB
2018-10-22 16:31:48 +00:00
set(blockchain_stats_sources
blockchain_stats.cpp
)
set(blockchain_stats_private_headers)
monero_private_headers(blockchain_stats
${blockchain_stats_private_headers})
blockchain_depth: get the average min depth of a set of txes
2018-07-10 18:56:05 +00:00
Dropped "bit" from bitmonero.
2016-09-26 14:42:29 +00:00
monero_add_executable(blockchain_import
Add blockchain_import utility This imports to the blockchain database from an exported blockchain file. It can be used to bootstrap a new database or to add blocks to an existing one. Supports: - both the in-memory and LMDB implementations - optional: batching, verification, testnet See help for usage. Based on work by tomerkon. See https://github.com/tomerkon src/cryptonote_core/bootfileloader.{h,cpp}
2015-02-10 23:13:32 +00:00
${blockchain_import_sources}
blocks: use auto-generated .c files instead of 'LD -r -b binary'
2018-10-09 12:33:39 +00:00
${blockchain_import_private_headers})
Add blockchain_import utility This imports to the blockchain database from an exported blockchain file. It can be used to bootstrap a new database or to add blocks to an existing one. Supports: - both the in-memory and LMDB implementations - optional: batching, verification, testnet See help for usage. Based on work by tomerkon. See https://github.com/tomerkon src/cryptonote_core/bootfileloader.{h,cpp}
2015-02-10 23:13:32 +00:00
target_link_libraries(blockchain_import
cmake: transitive deps and remove deprecated LINK_* Keep the immediate direct deps at the library that depends on them, declare deps as PUBLIC so that targets that link against that library get the library's deps as transitive deps. Break dep cycle between blockchain_db <-> crytonote_core. No code refactoring, just hide cycle from cmake so that it doesn't complain (cycles are allowed only between static libs, not shared libs). This is in preparation for supproting BUILD_SHARED_LIBS cmake built-in option for building internal libs as shared.
2016-09-17 17:59:29 +00:00
PRIVATE
Add blockchain_import utility This imports to the blockchain database from an exported blockchain file. It can be used to bootstrap a new database or to add blocks to an existing one. Supports: - both the in-memory and LMDB implementations - optional: batching, verification, testnet See help for usage. Based on work by tomerkon. See https://github.com/tomerkon src/cryptonote_core/bootfileloader.{h,cpp}
2015-02-10 23:13:32 +00:00
cryptonote_core
cmake: transitive deps and remove deprecated LINK_* Keep the immediate direct deps at the library that depends on them, declare deps as PUBLIC so that targets that link against that library get the library's deps as transitive deps. Break dep cycle between blockchain_db <-> crytonote_core. No code refactoring, just hide cycle from cmake so that it doesn't complain (cycles are allowed only between static libs, not shared libs). This is in preparation for supproting BUILD_SHARED_LIBS cmake built-in option for building internal libs as shared.
2016-09-17 17:59:29 +00:00
blockchain_db
build: auto update version info without manually deleting version.h
2017-09-13 23:28:23 +00:00
version
Change logging to easylogging++ This replaces the epee and data_loggers logging systems with a single one, and also adds filename:line and explicit severity levels. Categories may be defined, and logging severity set by category (or set of categories). epee style 0-4 log level maps to a sensible severity configuration. Log files now also rotate when reaching 100 MB. To select which logs to output, use the MONERO_LOGS environment variable, with a comma separated list of categories (globs are supported), with their requested severity level after a colon. If a log matches more than one such setting, the last one in the configuration string applies. A few examples: This one is (mostly) silent, only outputting fatal errors: MONERO_LOGS=*:FATAL This one is very verbose: MONERO_LOGS=*:TRACE This one is totally silent (logwise): MONERO_LOGS="" This one outputs all errors and warnings, except for the "verify" category, which prints just fatal errors (the verify category is used for logs about incoming transactions and blocks, and it is expected that some/many will fail to verify, hence we don't want the spam): MONERO_LOGS=*:WARNING,verify:FATAL Log levels are, in decreasing order of priority: FATAL, ERROR, WARNING, INFO, DEBUG, TRACE Subcategories may be added using prefixes and globs. This example will output net.p2p logs at the TRACE level, but all other net* logs only at INFO: MONERO_LOGS=*:ERROR,net*:INFO,net.p2p:TRACE Logs which are intended for the user (which Monero was using a lot through epee, but really isn't a nice way to go things) should use the "global" category. There are a few helper macros for using this category, eg: MGINFO("this shows up by default") or MGINFO_RED("this is red"), to try to keep a similar look and feel for now. Existing epee log macros still exist, and map to the new log levels, but since they're used as a "user facing" UI element as much as a logging system, they often don't map well to log severities (ie, a log level 0 log may be an error, or may be something we want the user to see, such as an important info). In those cases, I tried to use the new macros. In other cases, I left the existing macros in. When modifying logs, it is probably best to switch to the new macros with explicit levels. The --log-level options and set_log commands now also accept category settings, in addition to the epee style log levels.
2017-01-01 16:34:23 +00:00
epee
cmake: transitive deps and remove deprecated LINK_* Keep the immediate direct deps at the library that depends on them, declare deps as PUBLIC so that targets that link against that library get the library's deps as transitive deps. Break dep cycle between blockchain_db <-> crytonote_core. No code refactoring, just hide cycle from cmake so that it doesn't complain (cycles are allowed only between static libs, not shared libs). This is in preparation for supproting BUILD_SHARED_LIBS cmake built-in option for building internal libs as shared.
2016-09-17 17:59:29 +00:00
${Boost_FILESYSTEM_LIBRARY}
${Boost_SYSTEM_LIBRARY}
${Boost_THREAD_LIBRARY}
${CMAKE_THREAD_LIBS_INIT}
blocks: use auto-generated .c files instead of 'LD -r -b binary'
2018-10-09 12:33:39 +00:00
${EXTRA_LIBRARIES}
${Blocks})
Add blockchain_import utility This imports to the blockchain database from an exported blockchain file. It can be used to bootstrap a new database or to add blocks to an existing one. Supports: - both the in-memory and LMDB implementations - optional: batching, verification, testnet See help for usage. Based on work by tomerkon. See https://github.com/tomerkon src/cryptonote_core/bootfileloader.{h,cpp}
2015-02-10 23:13:32 +00:00
blockchain_import: Pass ARCH_WIDTH macro if 32-bit or not. This also avoids warnings.
2016-02-18 14:14:31 +00:00
if(ARCH_WIDTH)
blockchain_import: Check bit width for more than just WIN32 Pass the CMake bit width setting to compile flags for blockchain_import and blockchain_converter. For LMDB on 32-bit, hyc has found that batch size of 100 appears to be a good default.
2016-02-17 20:10:26 +00:00
target_compile_definitions(blockchain_import
blockchain_import: Pass ARCH_WIDTH macro if 32-bit or not. This also avoids warnings.
2016-02-18 14:14:31 +00:00
PUBLIC -DARCH_WIDTH=${ARCH_WIDTH})
blockchain_import: Check bit width for more than just WIN32 Pass the CMake bit width setting to compile flags for blockchain_import and blockchain_converter. For LMDB on 32-bit, hyc has found that batch size of 100 appears to be a good default.
2016-02-17 20:10:26 +00:00
endif()
Add blockchain_import utility This imports to the blockchain database from an exported blockchain file. It can be used to bootstrap a new database or to add blocks to an existing one. Supports: - both the in-memory and LMDB implementations - optional: batching, verification, testnet See help for usage. Based on work by tomerkon. See https://github.com/tomerkon src/cryptonote_core/bootfileloader.{h,cpp}
2015-02-10 23:13:32 +00:00
set_property(TARGET blockchain_import
PROPERTY
rename blockchain utils
2016-09-03 11:45:18 +00:00
OUTPUT_NAME "monero-blockchain-import")
blockchain_utilities: Add monero-blockchain-{ex,im}port binaries to default install targets Binaries available to download on https://getmonero.org/downloads/ as embedding monerod, monero-wallet-{cli,rpc} and monero-blockchain-{ex,im}port. This change synchronise download results with a manual build from source
2017-10-15 21:15:18 +00:00
install(TARGETS blockchain_import DESTINATION bin)
Add blockchain_export utility Based on work by tomerkon. See https://github.com/tomerkon/bitmonero src/cryptonote_core/bootfilesaver.{h,cpp} src/bootfilegen/bootfilegen.cpp
2015-02-16 12:20:55 +00:00
Dropped "bit" from bitmonero.
2016-09-26 14:42:29 +00:00
monero_add_executable(blockchain_export
Add blockchain_export utility Based on work by tomerkon. See https://github.com/tomerkon/bitmonero src/cryptonote_core/bootfilesaver.{h,cpp} src/bootfilegen/bootfilegen.cpp
2015-02-16 12:20:55 +00:00
${blockchain_export_sources}
${blockchain_export_private_headers})
target_link_libraries(blockchain_export
cmake: transitive deps and remove deprecated LINK_* Keep the immediate direct deps at the library that depends on them, declare deps as PUBLIC so that targets that link against that library get the library's deps as transitive deps. Break dep cycle between blockchain_db <-> crytonote_core. No code refactoring, just hide cycle from cmake so that it doesn't complain (cycles are allowed only between static libs, not shared libs). This is in preparation for supproting BUILD_SHARED_LIBS cmake built-in option for building internal libs as shared.
2016-09-17 17:59:29 +00:00
PRIVATE
Add blockchain_export utility Based on work by tomerkon. See https://github.com/tomerkon/bitmonero src/cryptonote_core/bootfilesaver.{h,cpp} src/bootfilegen/bootfilegen.cpp
2015-02-16 12:20:55 +00:00
cryptonote_core
cmake: transitive deps and remove deprecated LINK_* Keep the immediate direct deps at the library that depends on them, declare deps as PUBLIC so that targets that link against that library get the library's deps as transitive deps. Break dep cycle between blockchain_db <-> crytonote_core. No code refactoring, just hide cycle from cmake so that it doesn't complain (cycles are allowed only between static libs, not shared libs). This is in preparation for supproting BUILD_SHARED_LIBS cmake built-in option for building internal libs as shared.
2016-09-17 17:59:29 +00:00
blockchain_db
build: auto update version info without manually deleting version.h
2017-09-13 23:28:23 +00:00
version
Change logging to easylogging++ This replaces the epee and data_loggers logging systems with a single one, and also adds filename:line and explicit severity levels. Categories may be defined, and logging severity set by category (or set of categories). epee style 0-4 log level maps to a sensible severity configuration. Log files now also rotate when reaching 100 MB. To select which logs to output, use the MONERO_LOGS environment variable, with a comma separated list of categories (globs are supported), with their requested severity level after a colon. If a log matches more than one such setting, the last one in the configuration string applies. A few examples: This one is (mostly) silent, only outputting fatal errors: MONERO_LOGS=*:FATAL This one is very verbose: MONERO_LOGS=*:TRACE This one is totally silent (logwise): MONERO_LOGS="" This one outputs all errors and warnings, except for the "verify" category, which prints just fatal errors (the verify category is used for logs about incoming transactions and blocks, and it is expected that some/many will fail to verify, hence we don't want the spam): MONERO_LOGS=*:WARNING,verify:FATAL Log levels are, in decreasing order of priority: FATAL, ERROR, WARNING, INFO, DEBUG, TRACE Subcategories may be added using prefixes and globs. This example will output net.p2p logs at the TRACE level, but all other net* logs only at INFO: MONERO_LOGS=*:ERROR,net*:INFO,net.p2p:TRACE Logs which are intended for the user (which Monero was using a lot through epee, but really isn't a nice way to go things) should use the "global" category. There are a few helper macros for using this category, eg: MGINFO("this shows up by default") or MGINFO_RED("this is red"), to try to keep a similar look and feel for now. Existing epee log macros still exist, and map to the new log levels, but since they're used as a "user facing" UI element as much as a logging system, they often don't map well to log severities (ie, a log level 0 log may be an error, or may be something we want the user to see, such as an important info). In those cases, I tried to use the new macros. In other cases, I left the existing macros in. When modifying logs, it is probably best to switch to the new macros with explicit levels. The --log-level options and set_log commands now also accept category settings, in addition to the epee style log levels.
2017-01-01 16:34:23 +00:00
epee
cmake: transitive deps and remove deprecated LINK_* Keep the immediate direct deps at the library that depends on them, declare deps as PUBLIC so that targets that link against that library get the library's deps as transitive deps. Break dep cycle between blockchain_db <-> crytonote_core. No code refactoring, just hide cycle from cmake so that it doesn't complain (cycles are allowed only between static libs, not shared libs). This is in preparation for supproting BUILD_SHARED_LIBS cmake built-in option for building internal libs as shared.
2016-09-17 17:59:29 +00:00
${Boost_FILESYSTEM_LIBRARY}
${Boost_SYSTEM_LIBRARY}
${Boost_THREAD_LIBRARY}
${CMAKE_THREAD_LIBS_INIT}
${EXTRA_LIBRARIES})
Add blockchain_export utility Based on work by tomerkon. See https://github.com/tomerkon/bitmonero src/cryptonote_core/bootfilesaver.{h,cpp} src/bootfilegen/bootfilegen.cpp
2015-02-16 12:20:55 +00:00
set_property(TARGET blockchain_export
PROPERTY
rename blockchain utils
2016-09-03 11:45:18 +00:00
OUTPUT_NAME "monero-blockchain-export")
blockchain_utilities: Add monero-blockchain-{ex,im}port binaries to default install targets Binaries available to download on https://getmonero.org/downloads/ as embedding monerod, monero-wallet-{cli,rpc} and monero-blockchain-{ex,im}port. This change synchronise download results with a manual build from source
2017-10-15 21:15:18 +00:00
install(TARGETS blockchain_export DESTINATION bin)
Revert "remove cn_deserialize" This is useful (to me). This reverts commit f968ccb9d3d34d163dc5638006e6b87c78ddfdb3.
2016-10-30 20:24:21 +00:00
blockchain_utilities: new blockchain_blackball tool It scans for known spent outputs and stores their public keys in a database which can then be read by the wallet, which can then avoid using those as fake outs in new transactions. Usage: monero-blockchain-blackball db1 db2... This uses the shared database in ~/.shared-ringdb
2018-02-26 16:39:40 +00:00
monero_add_executable(blockchain_blackball
${blockchain_blackball_sources}
${blockchain_blackball_private_headers})
target_link_libraries(blockchain_blackball
PRIVATE
wallet
cryptonote_core
blockchain_db
version
epee
${Boost_FILESYSTEM_LIBRARY}
${Boost_SYSTEM_LIBRARY}
${Boost_THREAD_LIBRARY}
${CMAKE_THREAD_LIBS_INIT}
${EXTRA_LIBRARIES})
set_property(TARGET blockchain_blackball
PROPERTY
Rename "blackball" for clarity Apparently some people seem to think it's a censorship list...
2018-10-18 18:05:51 +00:00
OUTPUT_NAME "monero-blockchain-mark-spent-outputs")
blockchain_utilities: new blockchain_blackball tool It scans for known spent outputs and stores their public keys in a database which can then be read by the wallet, which can then avoid using those as fake outs in new transactions. Usage: monero-blockchain-blackball db1 db2... This uses the shared database in ~/.shared-ringdb
2018-02-26 16:39:40 +00:00
install(TARGETS blockchain_blackball DESTINATION bin)
new blockchain_usage tool, reports on output usage
2018-02-27 12:54:28 +00:00
monero_add_executable(blockchain_usage
${blockchain_usage_sources}
${blockchain_usage_private_headers})
target_link_libraries(blockchain_usage
PRIVATE
cryptonote_core
blockchain_db
version
epee
${Boost_FILESYSTEM_LIBRARY}
${Boost_SYSTEM_LIBRARY}
${Boost_THREAD_LIBRARY}
${CMAKE_THREAD_LIBS_INIT}
${EXTRA_LIBRARIES})
set_property(TARGET blockchain_usage
PROPERTY
OUTPUT_NAME "monero-blockchain-usage")
install(TARGETS blockchain_usage DESTINATION bin)
blockchain_ancestry: finds all ancestors of a tx, block, or chain
2018-07-16 15:27:52 +00:00
monero_add_executable(blockchain_ancestry
${blockchain_ancestry_sources}
${blockchain_ancestry_private_headers})
target_link_libraries(blockchain_ancestry
PRIVATE
cryptonote_core
blockchain_db
version
epee
${Boost_FILESYSTEM_LIBRARY}
${Boost_SYSTEM_LIBRARY}
${Boost_THREAD_LIBRARY}
${CMAKE_THREAD_LIBS_INIT}
${EXTRA_LIBRARIES})
set_property(TARGET blockchain_ancestry
PROPERTY
OUTPUT_NAME "monero-blockchain-ancestry")
install(TARGETS blockchain_ancestry DESTINATION bin)
blockchain_depth: get the average min depth of a set of txes
2018-07-10 18:56:05 +00:00
monero_add_executable(blockchain_depth
${blockchain_depth_sources}
${blockchain_depth_private_headers})
target_link_libraries(blockchain_depth
PRIVATE
cryptonote_core
blockchain_db
version
epee
${Boost_FILESYSTEM_LIBRARY}
${Boost_SYSTEM_LIBRARY}
${Boost_THREAD_LIBRARY}
${CMAKE_THREAD_LIBS_INIT}
${EXTRA_LIBRARIES})
set_property(TARGET blockchain_depth
PROPERTY
OUTPUT_NAME "monero-blockchain-depth")
install(TARGETS blockchain_depth DESTINATION bin)
Add stats utility Report statistics from a blockchain DB
2018-10-22 16:31:48 +00:00
monero_add_executable(blockchain_stats
${blockchain_stats_sources}
${blockchain_stats_private_headers})
target_link_libraries(blockchain_stats
PRIVATE
cryptonote_core
blockchain_db
version
epee
${Boost_FILESYSTEM_LIBRARY}
${Boost_SYSTEM_LIBRARY}
${Boost_THREAD_LIBRARY}
${CMAKE_THREAD_LIBS_INIT}
${EXTRA_LIBRARIES})
set_property(TARGET blockchain_stats
PROPERTY
OUTPUT_NAME "monero-blockchain-stats")
install(TARGETS blockchain_stats DESTINATION bin)
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-24 14:49:04 +00:00
monero_add_executable(blockchain_prune_known_spent_data
${blockchain_prune_known_spent_data_sources}
${blockchain_prune_known_spent_data_private_headers})
target_link_libraries(blockchain_prune_known_spent_data
PRIVATE
cryptonote_core
blockchain_db
p2p
version
epee
${Boost_FILESYSTEM_LIBRARY}
${Boost_SYSTEM_LIBRARY}
${Boost_THREAD_LIBRARY}
${CMAKE_THREAD_LIBS_INIT}
${EXTRA_LIBRARIES})
set_property(TARGET blockchain_prune_known_spent_data
PROPERTY
OUTPUT_NAME "monero-blockchain-prune-known-spent-data")
install(TARGETS blockchain_prune_known_spent_data DESTINATION bin)
Pruning 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-04-29 22:30:51 +00:00
monero_add_executable(blockchain_prune
${blockchain_prune_sources}
${blockchain_prune_private_headers})
set_property(TARGET blockchain_prune
PROPERTY
OUTPUT_NAME "monero-blockchain-prune")
install(TARGETS blockchain_prune DESTINATION bin)
target_link_libraries(blockchain_prune
PRIVATE
cryptonote_core
blockchain_db
p2p
version
epee
${Boost_FILESYSTEM_LIBRARY}
${Boost_SYSTEM_LIBRARY}
${Boost_THREAD_LIBRARY}
${CMAKE_THREAD_LIBS_INIT}
${EXTRA_LIBRARIES})
Reference in a new issue Copy permalink