| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
|
|
|
|
Deleted 3 out of 4 calls to method connection_basic::sleep_before_packet
that were erroneous / superfluous, which enabled the elimination of a
"fudge" factor of 2.1 in connection_basic::set_rate_up_limit;
also ended the multiplying of limit values and numbers of bytes
transferred by 1024 before handing them over to the global throttle
objects
|
|
It's getting hit too easily
|
|
It's sent as JSON, so raw binary is not appropriate
|
|
|
|
|
|
wallet2 is a library, and should not prompt for stdin. Instead,
pass a function so simplewallet can prompt on stdin, and a GUI
might display a window, etc.
|
|
Those have no reason to be in a generic module
|
|
It's nasty, and actually breaks on Solaris, where if.h fails to
build due to:
struct map *if_memmap;
|
|
|
|
|
|
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).
|
|
This branch fixes a file permission issue introduced by https://github.com/monero-project/monero/commit/69c37200aa87f100f731e755bdca7a0dc6ae820a
|
|
|
|
Enable with perf:DEBUG
|
|
|
|
|
|
It's pretty slow and I/O intensive
|
|
|
|
|
|
- internal nullptr checks
- prevent modifications to network_address (shallow copy issues)
- automagically works with any type containing interface functions
- removed fnv1a hashing
- ipv4_network_address now flattened with no base class
|
|
|
|
|
|
It was always returning true, and could not be foreseen to
usefully return errors in the future. This silences CID 162652
as well as saves some checking code in a few places.
|
|
rather than in the same directory as the prebuilt versions
|
|
Also, set_log without parameters now prints the log categories
|
|
|
|
|
|
|
|
|
|
|
|
|
|
- Add some RPC commands (and touch up a couple others)
- some bounds checking
- some better pointer management
- const correctness and error handling
-- Thanks @vtnerd for type help with serialization and CMake changes
|
|
Structured {de-,}serialization methods for (many new) types
which are used for requests or responses in the RPC.
New types include RPC requests and responses, and structs which compose
types within those.
# Conflicts:
# src/cryptonote_core/blockchain.cpp
|
|
|
|
|
|
The byte for TX_EXTRA_TAG_PUBKEY is already included in
res.reserved_offset by the call to slow_memmem.
|
|
|
|
|
|
|
|
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.
|
|
|
|
Since I had to add an ID to the derived classes anyway,
this can be used instead. This removes an apparently
pointless warning from CLANG too.
|
|
|
|
|
|
Since we're just counting txs, there's no reason to deserialize all the blobs.
|
|
All code which was using ip and port now uses a new IPv4 object,
subclass of a new network_address class. This will allow easy
addition of I2P addresses later (and also IPv6, etc).
Both old style and new style peer lists are now sent in the P2P
protocol, which is inefficient but allows peers using both
codebases to talk to each other. This will be removed in the
future. No other subclasses than IPv4 exist yet.
|
|
Integration could go further (ie, return_tx_to_pool calls should
not be needed anymore, possibly other things).
poolstate.bin is now obsolete.
|
|
Only works from V5 fork onward - returns 0 before that block.
|
|
|
|
Includes a new RPC to get tx pool hashes fast.
|
|
This ensures a manual or RPC update tries the right build tag,
rather than source, which is currently not setup
|
|
|
|
|
|
subcommands "check", "download", and "update".
update is not yet implemented.
|
|
|
|
|
|
|
|
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.
|
|
|
|
This speeds up operations such as serving blocks to syncing peers
|
|
|
|
was resetting bg mining enabled instead of started. Upped the miner threshold. Also moved setting of enabled on start above miner thread creation since starting with true, then stopping, then starting with false resulted in race condition.
|
|
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).
|
|
|
|
|
|
of cores times 4 or 257.
|
|
These warnings were emitted by clang++, and they are real bugs.
src/rpc/core_rpc_server.cpp:208:58: warning: adding 'uint64_t'
(aka 'unsigned long') to a string does not append to the string
[-Wstring-plus-int]
res.status = "Error retrieving block at height " + height;
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~
The obvious intent is achieved by using std::to_string().
|
|
|
|
|
|
It was always set to false, even for orphan blocks
|
|
This prevents easy fingerprinting when you change IPs, and
will be a must when kovri gets used.
|
|
|
|
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.
|
|
|
|
Also print its value when printing pool
|
|
About the tip of the main chain, and the last N blocks
|
|
|
|
|
|
and print it in print_bc
|
|
|
|
|
|
|
|
|
|
Daemon RPC version is now composed of a major and minor number,
so that incompatible changes bump the major version, while
compatible changes can still bump the minor version without
causing clients to unnecessarily complain.
|
|
Those aren't yet in the blockchain, so will not be found
(and aren't yet known, since it depends on where exactly the
tx will be mined in the next block or blocks)
|
|
|
|
|
|
Someone apparently needs that to make a wallet but never asked.
If you read that and that's not what you wanted, the bugtracker
is at https://github.com/monero-project/monero/issues
|
|
I forgot to bump it previously when changing RPC, most notably
for the addition of the unlocked field in the histogram RPC.
This causes new wallets to not realize when they're talking to
an older daemon, and get confused trying to get outputs to use
as fake outs. This otherwise gratuitous bump ensures than old
daemons will be detected by wallets using this code.
|
|
|
|
|
|
25% of the outputs are selected from the last 5 days (if possible),
in order to avoid the common case of sending recently received
outputs again. 25% and 5 days are subject to review later, since
it's just a wallet level change.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
and the other 'response'.
Fixed to the standard spelling 'response'. This may fix some functionality - some calls had mixed spellings.
|
|
|
|
|
|
This is intended to catch traffic coming from a web browser,
so we avoid issues with a web page sending a transfer RPC to
the wallet. Requiring a particular user agent can act as a
simple password scheme, while we wait for 0MQ and proper
authentication to be merged.
|
|
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.
|
|
|
|
This plugs a privacy leak, where the wallet tells the daemon
which transactions contain outputs for the wallet by asking
for additional information for that particular transaction.
As a nice bonus, this actually makes refresh slightly faster.
|
|
|
|
It is not yet constrained to a fork, so don't use on the real network
or you'll be orphaned or rejected.
|
|
to get random ringct outputs to mix with
|
|
|
|
|
|
This plugs a privacy leak from the wallet to the daemon,
as the daemon could previously see what input is included
as a transaction input, which the daemon hadn't previously
supplied. Now, the wallet requests a particular set of
outputs, including the real one.
This can result in transactions that can't be accepted if
the wallet happens to select too many outputs with non standard
unlock times. The daemon could know this and select another
output, but the wallet is blind to it. It's currently very
unlikely since I don't think anything uses non default
unlock times. The wallet requests more outputs than necessary
so it can use spares if any of the returns outputs are still
locked. If there are not enough spares to reach the desired
mixin, the transaction will fail.
|
|
This constrains the number of instances of any amount
to the unlocked ones (as defined by the default unlock time
setting: outputs with non default unlock time are not
considered, so may be counted as unlocked even if they are
not actually unlocked).
|
|
|
|
If the version is different, simplewallet will refuse to use that
daemon, unless --allow-mismatched-daemon-version is used.
|
|
|
|
|
|
|
|
|
|
restricted mode.
|
|
When m_refresh_from_block_height has been set, only hashes will be
retrieved up to that height, instead of full blocks. The same will
be done for "refresh <height>" when the specified height is beyond
the current local blockchain.
|
|
|
|
Just to make it easier
|
|
|
|
This allows appropriate action to be taken, like displaying
the reason to the user.
Do just that in simplewallet, which should help a lot in
determining why users fail to send.
Also make it so a tx which is accepted but not relayed is
seen as a success rather than a failure.
|
|
This is a list of existing output amounts along with the number
of outputs of that amount in the blockchain.
The daemon command takes:
- no parameters: all outputs with at least 3 instances
- one parameter: all outputs with at least that many instances
- two parameters: all outputs within that many instances
The default starts at 3 to avoid massive spamming of all dust
outputs in the blockchain, and is the current minimum mixin
requirement.
An optional vector of amounts may be passed, to request
histogram only for those outputs.
|
|
|
|
The blocked ip list will still hold them till next time
a connection attempt is made with that IP, so the effective
length of the ban may be negative.
|
|
It can flush a particular tx, or the whole pool (the RPC command
can flush a list of transactions too)
|
|
|
|
Some of it uses hardcoded height, which will need some thinking
for next (voted upon) fork.
|
|
which fixes the status command via RPC too.
Turns out there are two versions of the GET_INFO call.
I'd never noticed before.
|
|
|
|
|
|
And make it change behavior slightly when close/after first hard fork
|
|
and add top block hash in get_info RPC
|
|
This fixes coretests, which does not register daemon specific arguments,
but uses core, which uses those arguments. Also gets rid of an unwanted
dependency on daemon code from core.
|
|
It does not expose the RPC for commands like start_mining, etc
(ie, commands a public node operator might want to be restricted)
|
|
This fixes the hash rate being wrong on testnet after the switch
to 2 minute blocks
|
|
|
|
The last relayed time of a transaction is maintained, and
transactions will be relayed again if they are still in the
pool after a certain amount of time, which increases with
the transaction's age. All such transactions are resent,
whether or not they originated on the local node.
|
|
They check whether they're running on testnet by accessing the
m_rpc_server object, which does not exist when in RPC mode.
Also, fix hard_fork_info being called with the wrong API.
|
|
I had never tested it, obviously
|
|
|
|
|
|
|
|
vector<bool> causes issues in serialization with Boost 1.56
|
|
|
|
|
|
|
|
It's helpful when you don't know something failed (especially as
everything ends up returning true, so caller thinks all's fine)
|
|
|
|
This is for the "print_pool" command and "get_transaction_pool" RPC
method.
Add mempool's spent key images to the results.
|
|
old unbound #warning does not block compilation
unit tests build fine. Even though the RPC/P2P network type is required again
|
|
|
|
Daemon interactive mode is now working again.
RPC mapped calls in daemon and wallet have both had connection_context
removed as an argument as that argument was not being used anywhere.
|
|
This was changed because sometimes the daemon does not complete its exit
routine with this method, but as it does correctly wind most things down
even if it gets stuck I've changed it back.
|
|
The RPC calls the daemon executable uses to talk to the running daemon
instance have mostly been added back in. Rate limiting has not been
added in upstream, but is on its way in a separate effort, so those
calls are still NOPed out.
|
|
many RPC functions added by the daemonize changes
(and related changes on the upstream dev branch that were not merged)
were commented out (apart from return). Other than that, this *should*
work...at any rate, it builds, and that's something.
|
|
|
|
|
|
Older versions of CMake support LINK_{PUBLIC,PRIVATE} while newer
versions prefer PUBLIC and PRIVATE instead, but still support the LINK_
prefix.
|
|
|
|
|
|
This cleans up the CMake code and shows patterns more easily (to be
refactored in the next commit).
|
|
|
|
It would read data outside the allocated space in a couple cases.
|
|
|
|
|
|
|
|
|
|
|
|
height param is used optionally in refresh command
TODO: This should also be the default behaviour
when generating a new wallet.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
