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.
9cc0d42 connection_context: remove state_ prefix from state names (moneromooo-monero)
d9d002c daemon: print peer state in sync_info (moneromooo-monero)
This patch allows to filter out sensitive information for queries that rely on the pool state, when running in restricted mode.
This filtering is only applied to data sent back to RPC queries. Results of inline commands typed locally in the daemon are not affected.
In practice, when running with `--restricted-rpc`:
* get_transaction_pool will list relayed transactions with the fields "last relayed time" and "received time" set to zero.
* get_transaction_pool will not list transaction that have do_not_relay set to true, and will not list key images that are used only for such transactions
* get_transaction_pool_hashes.bin will not list such transaction
* get_transaction_pool_stats will not count such transactions in any of the aggregated values that are computed
The implementation does not make filtering the default, so developers should be mindful of this if they add new RPC functionality.
Fixes#2590.
Transactions in the txpool are marked when another transaction
is seen double spending one or more of its inputs.
This is then exposed wherever appropriate.
Note that being marked with this "double spend seen" flag does
NOT mean this transaction IS a double spend and will never be
mined: it just means that the network has seen at least another
transaction spending at least one of the same inputs, so care
should be taken to wait for a few confirmations before acting
upon that transaction (ie, mostly of use for merchants wanting
to accept unconfirmed transactions).
792ba4f0 Log categories can now be added to and removed from (moneromooo-monero)
48f92eb6 easylogging++: add categories getter (moneromooo-monero)
f35afe62 epee: factor log level/categories setting (moneromooo-monero)
df0cffed cryptonote_protocol: warn if we see a higher top version we expect (moneromooo-monero)
317ab21a cryptonote_protocol: less strict check on top version on connect (moneromooo-monero)
cc81a371 cryptonote_protocol: update target height when syncing too (moneromooo-monero)
e2ad372b cryptonote_protocol: simplify and remove unnecessary casts (moneromooo-monero)
727e67ca cryptonote_protocol: print peer top height along with its version (moneromooo-monero)
b5345ef4 crypto: use malloc instead of alloca (moneromooo-monero)
80794b31 thread_group: set thread size to THREAD_STACK_SIZE (moneromooo-monero)
5524bc31 print peer id in 0 padded hex for consistency (moneromooo-monero)
8f8cc09b contrib: add sync_info to rlwrap command set (moneromooo-monero)
70b8c6d7 cryptonote_protocol: misc fixes to the new sync algorithm (moneromooo-monero)
A block queue is now placed between block download and
block processing. Blocks are now requested only from one
peer (unless starved).
Includes a new sync_info coommand.
eb20f720 daemon: print average fee per byte in print_pool_stats (moneromooo-monero)
37be70bb daemon: add fee/byte when print pool transaction info (moneromooo-monero)
893f5a30 tx_pool: add blob size and fee/byte when logging a new tx (moneromooo-monero)
Added an extra path to check for linux power supply status.
Added ignore battery option. If set to true, then when we can't figure out
the power status, we'll assume the system is plugged in.
source, and CPU has been idle for some time, then begin mining to some
threshold (don't destroy the users' CPU).
This patch only supports windows and linux (I've only tested on Win64 and
Ubuntu).
The variables currently default to pretty conservative values (i.e. 20%
CPU mining threshold).
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.
