2019-03-05 21:05:34 +00:00
|
|
|
// Copyright (c) 2014-2019, The Monero Project
|
2014-07-23 13:03:52 +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.
|
|
|
|
|
//
|
|
|
|
|
// Parts of this file are originally copyright (c) 2012-2013 The Cryptonote developers
|
2014-03-03 22:07:58 +00:00
|
|
|
|
2014-09-27 12:50:15 +00:00
|
|
|
/*!
|
|
|
|
|
* \file simplewallet.h
|
|
|
|
|
*
|
|
|
|
|
* \brief Header file that declares simple_wallet class.
|
|
|
|
|
*/
|
2014-03-03 22:07:58 +00:00
|
|
|
#pragma once
|
|
|
|
|
|
|
|
|
|
#include <memory>
|
|
|
|
|
|
2016-11-09 03:55:41 +00:00
|
|
|
#include <boost/optional/optional.hpp>
|
2014-03-03 22:07:58 +00:00
|
|
|
#include <boost/program_options/variables_map.hpp>
|
|
|
|
|
|
2017-01-26 15:07:23 +00:00
|
|
|
#include "cryptonote_basic/account.h"
|
|
|
|
|
#include "cryptonote_basic/cryptonote_basic_impl.h"
|
2014-03-03 22:07:58 +00:00
|
|
|
#include "wallet/wallet2.h"
|
|
|
|
|
#include "console_handler.h"
|
2019-05-06 08:44:50 +00:00
|
|
|
#include "math_helper.h"
|
2018-07-06 23:03:15 +00:00
|
|
|
#include "wipeable_string.h"
|
2018-01-26 12:58:49 +00:00
|
|
|
#include "common/i18n.h"
|
2017-02-05 22:48:03 +00:00
|
|
|
#include "common/password.h"
|
2014-06-04 22:59:47 +00:00
|
|
|
#include "crypto/crypto.h" // for definition of crypto::secret_key
|
2014-03-03 22:07:58 +00:00
|
|
|
|
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
|
|
|
#undef MONERO_DEFAULT_LOG_CATEGORY
|
|
|
|
|
#define MONERO_DEFAULT_LOG_CATEGORY "wallet.simplewallet"
|
2018-01-04 14:33:20 +00:00
|
|
|
// Hardcode Monero's donation address (see #1447)
|
|
|
|
|
constexpr const char MONERO_DONATION_ADDR[] = "44AFFq5kSiGBoZ4NMDwYtN18obc8AemS33DBLWs3H7otXft3XjrpDtQGv7SqSsaBYBb98uNbr2VBBEt7f2wfn3RVGQBEP3A";
|
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
|
|
|
|
2014-09-27 12:50:15 +00:00
|
|
|
/*!
|
|
|
|
|
* \namespace cryptonote
|
|
|
|
|
* \brief Holds cryptonote related classes and helpers.
|
|
|
|
|
*/
|
2014-03-03 22:07:58 +00:00
|
|
|
namespace cryptonote
|
|
|
|
|
{
|
2014-09-27 12:50:15 +00:00
|
|
|
/*!
|
|
|
|
|
* \brief Manages wallet operations. This is the most abstracted wallet class.
|
|
|
|
|
*/
|
2014-04-02 16:00:17 +00:00
|
|
|
class simple_wallet : public tools::i_wallet2_callback
|
2014-03-03 22:07:58 +00:00
|
|
|
{
|
2015-07-14 19:28:25 +00:00
|
|
|
public:
|
|
|
|
|
static const char *tr(const char *str) { return i18n_translate(str, "cryptonote::simple_wallet"); }
|
|
|
|
|
|
2014-03-03 22:07:58 +00:00
|
|
|
public:
|
|
|
|
|
typedef std::vector<std::string> command_type;
|
|
|
|
|
|
|
|
|
|
simple_wallet();
|
|
|
|
|
bool init(const boost::program_options::variables_map& vm);
|
|
|
|
|
bool deinit();
|
|
|
|
|
bool run();
|
2014-03-20 11:46:11 +00:00
|
|
|
void stop();
|
2015-11-29 13:02:01 +00:00
|
|
|
void interrupt();
|
2014-03-03 22:07:58 +00:00
|
|
|
|
|
|
|
|
//wallet *create_wallet();
|
|
|
|
|
bool process_command(const std::vector<std::string> &args);
|
|
|
|
|
std::string get_commands_str();
|
2017-11-22 12:53:18 +00:00
|
|
|
std::string get_command_usage(const std::vector<std::string> &args);
|
2014-03-03 22:07:58 +00:00
|
|
|
private:
|
2018-10-26 14:25:20 +00:00
|
|
|
|
2018-11-12 03:31:46 +00:00
|
|
|
enum ResetType { ResetNone, ResetSoft, ResetHard, ResetSoftKeepKI };
|
2018-10-26 14:25:20 +00:00
|
|
|
|
2015-11-22 19:03:10 +00:00
|
|
|
bool handle_command_line(const boost::program_options::variables_map& vm);
|
2014-03-03 22:07:58 +00:00
|
|
|
|
|
|
|
|
bool run_console_handler();
|
|
|
|
|
|
2016-08-07 12:06:40 +00:00
|
|
|
void wallet_idle_thread();
|
2015-11-28 12:38:58 +00:00
|
|
|
|
2016-12-17 23:07:15 +00:00
|
|
|
//! \return Prompts user for password and verifies against local file. Logs on error and returns `none`
|
|
|
|
|
boost::optional<tools::password_container> get_and_verify_password() const;
|
|
|
|
|
|
2018-07-30 11:39:05 +00:00
|
|
|
boost::optional<epee::wipeable_string> new_wallet(const boost::program_options::variables_map& vm, const crypto::secret_key& recovery_key,
|
2016-11-09 03:55:41 +00:00
|
|
|
bool recover, bool two_random, const std::string &old_language);
|
2018-07-30 11:39:05 +00:00
|
|
|
boost::optional<epee::wipeable_string> new_wallet(const boost::program_options::variables_map& vm, const cryptonote::account_public_address& address,
|
2016-11-09 03:55:41 +00:00
|
|
|
const boost::optional<crypto::secret_key>& spendkey, const crypto::secret_key& viewkey);
|
2018-07-30 11:39:05 +00:00
|
|
|
boost::optional<epee::wipeable_string> new_wallet(const boost::program_options::variables_map& vm,
|
2018-07-06 23:03:15 +00:00
|
|
|
const epee::wipeable_string &multisig_keys, const std::string &old_language);
|
2018-08-23 22:50:31 +00:00
|
|
|
boost::optional<epee::wipeable_string> new_wallet(const boost::program_options::variables_map& vm);
|
2019-03-30 19:21:30 +00:00
|
|
|
boost::optional<epee::wipeable_string> open_wallet(const boost::program_options::variables_map& vm);
|
2014-03-03 22:07:58 +00:00
|
|
|
bool close_wallet();
|
|
|
|
|
|
2014-08-05 06:53:30 +00:00
|
|
|
bool viewkey(const std::vector<std::string> &args = std::vector<std::string>());
|
2015-05-20 00:08:37 +00:00
|
|
|
bool spendkey(const std::vector<std::string> &args = std::vector<std::string>());
|
2014-08-01 13:40:18 +00:00
|
|
|
bool seed(const std::vector<std::string> &args = std::vector<std::string>());
|
2017-08-06 15:51:40 +00:00
|
|
|
bool encrypted_seed(const std::vector<std::string> &args = std::vector<std::string>());
|
2019-07-08 13:51:50 +00:00
|
|
|
bool restore_height(const std::vector<std::string> &args = std::vector<std::string>());
|
2014-12-06 14:58:33 +00:00
|
|
|
|
|
|
|
|
/*!
|
|
|
|
|
* \brief Sets seed language.
|
|
|
|
|
*
|
|
|
|
|
* interactive
|
|
|
|
|
* - prompts for password so wallet can be rewritten
|
|
|
|
|
* - calls get_mnemonic_language() which prompts for language
|
|
|
|
|
*
|
|
|
|
|
* \return success status
|
|
|
|
|
*/
|
|
|
|
|
bool seed_set_language(const std::vector<std::string> &args = std::vector<std::string>());
|
2015-07-18 21:03:35 +00:00
|
|
|
bool set_always_confirm_transfers(const std::vector<std::string> &args = std::vector<std::string>());
|
2016-12-23 12:04:54 +00:00
|
|
|
bool set_print_ring_members(const std::vector<std::string> &args = std::vector<std::string>());
|
2015-11-22 12:26:27 +00:00
|
|
|
bool set_store_tx_info(const std::vector<std::string> &args = std::vector<std::string>());
|
2017-07-31 06:50:41 +00:00
|
|
|
bool set_default_ring_size(const std::vector<std::string> &args = std::vector<std::string>());
|
2015-11-28 12:38:58 +00:00
|
|
|
bool set_auto_refresh(const std::vector<std::string> &args = std::vector<std::string>());
|
2015-12-05 21:44:25 +00:00
|
|
|
bool set_refresh_type(const std::vector<std::string> &args = std::vector<std::string>());
|
2016-10-01 16:03:53 +00:00
|
|
|
bool set_confirm_missing_payment_id(const std::vector<std::string> &args = std::vector<std::string>());
|
2017-01-27 12:26:52 +00:00
|
|
|
bool set_ask_password(const std::vector<std::string> &args = std::vector<std::string>());
|
2017-03-01 22:27:27 +00:00
|
|
|
bool set_unit(const std::vector<std::string> &args = std::vector<std::string>());
|
wallet: try to save large outputs when using an unneeded second input
When a single input is enough to satisfy a transfer, the code would
previously try to add a second input, to match the "canonical" makeup
of a transaction with two inputs and two outputs. This would cause
wallets to slowly merge outputs till all the monero ends up in a
single output, which causes trouble when making two transactions
one after the other, since change is locked for 10 blocks, and an
increasing portion of the remaining balance would end up locked on
each transaction.
There are two new settings (min-output-count and min-output-value)
which can control when to stop adding such unneeded second outputs.
The idea is that small "dust" outputs will still get added, but
larger ones will not.
Enable with, eg:
set min-output-count 10
set min-output-value 30
to avoid using an unneeded second output of 30 monero or more, if
there would be less than 10 such outputs left.
This does not invalidate any other reason why such outputs would
be used (ie, when they're really needed to satisfy a transfer, or
when randomly picked in the normal course of selection). This may
be improved in the future.
2017-03-24 20:58:02 +00:00
|
|
|
bool set_min_output_count(const std::vector<std::string> &args = std::vector<std::string>());
|
|
|
|
|
bool set_min_output_value(const std::vector<std::string> &args = std::vector<std::string>());
|
2017-03-24 21:56:58 +00:00
|
|
|
bool set_merge_destinations(const std::vector<std::string> &args = std::vector<std::string>());
|
2017-08-26 15:23:54 +00:00
|
|
|
bool set_confirm_backlog(const std::vector<std::string> &args = std::vector<std::string>());
|
2017-09-18 11:46:33 +00:00
|
|
|
bool set_confirm_backlog_threshold(const std::vector<std::string> &args = std::vector<std::string>());
|
2018-01-14 23:36:13 +00:00
|
|
|
bool set_confirm_export_overwrite(const std::vector<std::string> &args = std::vector<std::string>());
|
2017-10-08 09:14:44 +00:00
|
|
|
bool set_refresh_from_block_height(const std::vector<std::string> &args = std::vector<std::string>());
|
2018-01-15 03:05:16 +00:00
|
|
|
bool set_auto_low_priority(const std::vector<std::string> &args = std::vector<std::string>());
|
2018-02-19 10:23:23 +00:00
|
|
|
bool set_segregate_pre_fork_outputs(const std::vector<std::string> &args = std::vector<std::string>());
|
|
|
|
|
bool set_key_reuse_mitigation2(const std::vector<std::string> &args = std::vector<std::string>());
|
2018-03-16 04:11:45 +00:00
|
|
|
bool set_subaddress_lookahead(const std::vector<std::string> &args = std::vector<std::string>());
|
2018-03-13 19:38:52 +00:00
|
|
|
bool set_segregation_height(const std::vector<std::string> &args = std::vector<std::string>());
|
2018-06-28 02:31:50 +00:00
|
|
|
bool set_ignore_fractional_outputs(const std::vector<std::string> &args = std::vector<std::string>());
|
2019-10-02 04:04:24 +00:00
|
|
|
bool set_ignore_outputs_above(const std::vector<std::string> &args = std::vector<std::string>());
|
|
|
|
|
bool set_ignore_outputs_below(const std::vector<std::string> &args = std::vector<std::string>());
|
2018-12-03 15:32:14 +00:00
|
|
|
bool set_track_uses(const std::vector<std::string> &args = std::vector<std::string>());
|
2019-05-06 08:44:50 +00:00
|
|
|
bool set_inactivity_lock_timeout(const std::vector<std::string> &args = std::vector<std::string>());
|
2019-03-30 19:21:30 +00:00
|
|
|
bool set_setup_background_mining(const std::vector<std::string> &args = std::vector<std::string>());
|
2018-08-23 21:50:53 +00:00
|
|
|
bool set_device_name(const std::vector<std::string> &args = std::vector<std::string>());
|
2019-04-10 09:20:12 +00:00
|
|
|
bool set_export_format(const std::vector<std::string> &args = std::vector<std::string>());
|
daemon, wallet: new pay for RPC use system
Daemons intended for public use can be set up to require payment
in the form of hashes in exchange for RPC service. This enables
public daemons to receive payment for their work over a large
number of calls. This system behaves similarly to a pool, so
payment takes the form of valid blocks every so often, yielding
a large one off payment, rather than constant micropayments.
This system can also be used by third parties as a "paywall"
layer, where users of a service can pay for use by mining Monero
to the service provider's address. An example of this for web
site access is Primo, a Monero mining based website "paywall":
https://github.com/selene-kovri/primo
This has some advantages:
- incentive to run a node providing RPC services, thereby promoting the availability of third party nodes for those who can't run their own
- incentive to run your own node instead of using a third party's, thereby promoting decentralization
- decentralized: payment is done between a client and server, with no third party needed
- private: since the system is "pay as you go", you don't need to identify yourself to claim a long lived balance
- no payment occurs on the blockchain, so there is no extra transactional load
- one may mine with a beefy server, and use those credits from a phone, by reusing the client ID (at the cost of some privacy)
- no barrier to entry: anyone may run a RPC node, and your expected revenue depends on how much work you do
- Sybil resistant: if you run 1000 idle RPC nodes, you don't magically get more revenue
- no large credit balance maintained on servers, so they have no incentive to exit scam
- you can use any/many node(s), since there's little cost in switching servers
- market based prices: competition between servers to lower costs
- incentive for a distributed third party node system: if some public nodes are overused/slow, traffic can move to others
- increases network security
- helps counteract mining pools' share of the network hash rate
- zero incentive for a payer to "double spend" since a reorg does not give any money back to the miner
And some disadvantages:
- low power clients will have difficulty mining (but one can optionally mine in advance and/or with a faster machine)
- payment is "random", so a server might go a long time without a block before getting one
- a public node's overall expected payment may be small
Public nodes are expected to compete to find a suitable level for
cost of service.
The daemon can be set up this way to require payment for RPC services:
monerod --rpc-payment-address 4xxxxxx \
--rpc-payment-credits 250 --rpc-payment-difficulty 1000
These values are an example only.
The --rpc-payment-difficulty switch selects how hard each "share" should
be, similar to a mining pool. The higher the difficulty, the fewer
shares a client will find.
The --rpc-payment-credits switch selects how many credits are awarded
for each share a client finds.
Considering both options, clients will be awarded credits/difficulty
credits for every hash they calculate. For example, in the command line
above, 0.25 credits per hash. A client mining at 100 H/s will therefore
get an average of 25 credits per second.
For reference, in the current implementation, a credit is enough to
sync 20 blocks, so a 100 H/s client that's just starting to use Monero
and uses this daemon will be able to sync 500 blocks per second.
The wallet can be set to automatically mine if connected to a daemon
which requires payment for RPC usage. It will try to keep a balance
of 50000 credits, stopping mining when it's at this level, and starting
again as credits are spent. With the example above, a new client will
mine this much credits in about half an hour, and this target is enough
to sync 500000 blocks (currently about a third of the monero blockchain).
There are three new settings in the wallet:
- credits-target: this is the amount of credits a wallet will try to
reach before stopping mining. The default of 0 means 50000 credits.
- auto-mine-for-rpc-payment-threshold: this controls the minimum
credit rate which the wallet considers worth mining for. If the
daemon credits less than this ratio, the wallet will consider mining
to be not worth it. In the example above, the rate is 0.25
- persistent-rpc-client-id: if set, this allows the wallet to reuse
a client id across runs. This means a public node can tell a wallet
that's connecting is the same as one that connected previously, but
allows a wallet to keep their credit balance from one run to the
other. Since the wallet only mines to keep a small credit balance,
this is not normally worth doing. However, someone may want to mine
on a fast server, and use that credit balance on a low power device
such as a phone. If left unset, a new client ID is generated at
each wallet start, for privacy reasons.
To mine and use a credit balance on two different devices, you can
use the --rpc-client-secret-key switch. A wallet's client secret key
can be found using the new rpc_payments command in the wallet.
Note: anyone knowing your RPC client secret key is able to use your
credit balance.
The wallet has a few new commands too:
- start_mining_for_rpc: start mining to acquire more credits,
regardless of the auto mining settings
- stop_mining_for_rpc: stop mining to acquire more credits
- rpc_payments: display information about current credits with
the currently selected daemon
The node has an extra command:
- rpc_payments: display information about clients and their
balances
The node will forget about any balance for clients which have
been inactive for 6 months. Balances carry over on node restart.
2018-02-11 15:15:56 +00:00
|
|
|
bool set_persistent_rpc_client_id(const std::vector<std::string> &args = std::vector<std::string>());
|
|
|
|
|
bool set_auto_mine_for_rpc_payment_threshold(const std::vector<std::string> &args = std::vector<std::string>());
|
|
|
|
|
bool set_credits_target(const std::vector<std::string> &args = std::vector<std::string>());
|
2014-03-20 11:46:11 +00:00
|
|
|
bool help(const std::vector<std::string> &args = std::vector<std::string>());
|
2014-03-03 22:07:58 +00:00
|
|
|
bool start_mining(const std::vector<std::string> &args);
|
|
|
|
|
bool stop_mining(const std::vector<std::string> &args);
|
2017-09-22 18:20:09 +00:00
|
|
|
bool set_daemon(const std::vector<std::string> &args);
|
|
|
|
|
bool save_bc(const std::vector<std::string> &args);
|
2014-03-03 22:07:58 +00:00
|
|
|
bool refresh(const std::vector<std::string> &args);
|
2017-02-19 02:42:10 +00:00
|
|
|
bool show_balance_unlocked(bool detailed = false);
|
2014-03-20 11:46:11 +00:00
|
|
|
bool show_balance(const std::vector<std::string> &args = std::vector<std::string>());
|
2014-03-03 22:07:58 +00:00
|
|
|
bool show_incoming_transfers(const std::vector<std::string> &args);
|
2014-05-03 16:19:43 +00:00
|
|
|
bool show_payments(const std::vector<std::string> &args);
|
2014-03-03 22:07:58 +00:00
|
|
|
bool show_blockchain_height(const std::vector<std::string> &args);
|
2018-10-28 13:46:58 +00:00
|
|
|
bool transfer_main(int transfer_type, const std::vector<std::string> &args, bool called_by_mms);
|
2014-03-03 22:07:58 +00:00
|
|
|
bool transfer(const std::vector<std::string> &args);
|
2016-09-28 13:20:37 +00:00
|
|
|
bool locked_transfer(const std::vector<std::string> &args);
|
2018-04-13 01:13:24 +00:00
|
|
|
bool locked_sweep_all(const std::vector<std::string> &args);
|
|
|
|
|
bool sweep_main(uint64_t below, bool locked, const std::vector<std::string> &args);
|
2016-04-19 20:20:27 +00:00
|
|
|
bool sweep_all(const std::vector<std::string> &args);
|
2017-04-16 16:46:01 +00:00
|
|
|
bool sweep_below(const std::vector<std::string> &args);
|
2017-10-11 01:32:06 +00:00
|
|
|
bool sweep_single(const std::vector<std::string> &args);
|
2016-03-26 21:15:47 +00:00
|
|
|
bool sweep_unmixable(const std::vector<std::string> &args);
|
2016-12-14 11:44:09 +00:00
|
|
|
bool donate(const std::vector<std::string> &args);
|
2016-09-26 22:11:10 +00:00
|
|
|
bool sign_transfer(const std::vector<std::string> &args);
|
|
|
|
|
bool submit_transfer(const std::vector<std::string> &args);
|
2014-06-16 00:36:44 +00:00
|
|
|
std::vector<std::vector<cryptonote::tx_destination_entry>> split_amounts(
|
|
|
|
|
std::vector<cryptonote::tx_destination_entry> dsts, size_t num_splits
|
2014-06-15 21:20:16 +00:00
|
|
|
);
|
2017-02-19 02:42:10 +00:00
|
|
|
bool account(const std::vector<std::string> &args = std::vector<std::string>());
|
|
|
|
|
void print_accounts();
|
2017-12-15 03:08:36 +00:00
|
|
|
void print_accounts(const std::string& tag);
|
2014-04-02 16:00:17 +00:00
|
|
|
bool print_address(const std::vector<std::string> &args = std::vector<std::string>());
|
2015-06-11 08:44:13 +00:00
|
|
|
bool print_integrated_address(const std::vector<std::string> &args = std::vector<std::string>());
|
2016-12-21 03:05:29 +00:00
|
|
|
bool address_book(const std::vector<std::string> &args = std::vector<std::string>());
|
2014-03-03 22:07:58 +00:00
|
|
|
bool save(const std::vector<std::string> &args);
|
2015-05-31 14:34:55 +00:00
|
|
|
bool save_watch_only(const std::vector<std::string> &args);
|
2014-12-06 14:58:33 +00:00
|
|
|
bool set_variable(const std::vector<std::string> &args);
|
2015-08-11 14:14:44 +00:00
|
|
|
bool rescan_spent(const std::vector<std::string> &args);
|
2014-03-03 22:07:58 +00:00
|
|
|
bool set_log(const std::vector<std::string> &args);
|
2015-08-19 19:59:44 +00:00
|
|
|
bool get_tx_key(const std::vector<std::string> &args);
|
2018-07-29 12:29:56 +00:00
|
|
|
bool set_tx_key(const std::vector<std::string> &args);
|
2015-10-11 23:13:05 +00:00
|
|
|
bool check_tx_key(const std::vector<std::string> &args);
|
2017-03-29 23:22:16 +00:00
|
|
|
bool get_tx_proof(const std::vector<std::string> &args);
|
|
|
|
|
bool check_tx_proof(const std::vector<std::string> &args);
|
2017-08-28 15:34:17 +00:00
|
|
|
bool get_spend_proof(const std::vector<std::string> &args);
|
|
|
|
|
bool check_spend_proof(const std::vector<std::string> &args);
|
2017-12-28 13:50:10 +00:00
|
|
|
bool get_reserve_proof(const std::vector<std::string> &args);
|
|
|
|
|
bool check_reserve_proof(const std::vector<std::string> &args);
|
2015-11-15 21:59:40 +00:00
|
|
|
bool show_transfers(const std::vector<std::string> &args);
|
2018-11-08 05:12:11 +00:00
|
|
|
bool export_transfers(const std::vector<std::string> &args);
|
2016-12-24 05:31:19 +00:00
|
|
|
bool unspent_outputs(const std::vector<std::string> &args);
|
2015-12-30 12:58:15 +00:00
|
|
|
bool rescan_blockchain(const std::vector<std::string> &args);
|
2018-10-26 14:25:20 +00:00
|
|
|
bool refresh_main(uint64_t start_height, ResetType reset, bool is_init = false);
|
2016-04-20 17:19:42 +00:00
|
|
|
bool set_tx_note(const std::vector<std::string> &args);
|
|
|
|
|
bool get_tx_note(const std::vector<std::string> &args);
|
2017-10-08 07:15:06 +00:00
|
|
|
bool set_description(const std::vector<std::string> &args);
|
|
|
|
|
bool get_description(const std::vector<std::string> &args);
|
2016-06-20 18:11:10 +00:00
|
|
|
bool status(const std::vector<std::string> &args);
|
2017-08-31 08:11:20 +00:00
|
|
|
bool wallet_info(const std::vector<std::string> &args);
|
2016-09-16 10:50:52 +00:00
|
|
|
bool set_default_priority(const std::vector<std::string> &args);
|
2016-04-23 20:46:48 +00:00
|
|
|
bool sign(const std::vector<std::string> &args);
|
|
|
|
|
bool verify(const std::vector<std::string> &args);
|
2016-07-15 11:11:55 +00:00
|
|
|
bool export_key_images(const std::vector<std::string> &args);
|
|
|
|
|
bool import_key_images(const std::vector<std::string> &args);
|
2018-08-23 21:50:53 +00:00
|
|
|
bool hw_key_images_sync(const std::vector<std::string> &args);
|
2018-08-23 22:50:31 +00:00
|
|
|
bool hw_reconnect(const std::vector<std::string> &args);
|
2016-10-30 19:37:09 +00:00
|
|
|
bool export_outputs(const std::vector<std::string> &args);
|
|
|
|
|
bool import_outputs(const std::vector<std::string> &args);
|
2017-01-08 13:57:24 +00:00
|
|
|
bool show_transfer(const std::vector<std::string> &args);
|
2017-01-27 07:12:18 +00:00
|
|
|
bool change_password(const std::vector<std::string>& args);
|
2017-06-10 09:08:55 +00:00
|
|
|
bool payment_id(const std::vector<std::string> &args);
|
2017-08-27 20:04:56 +00:00
|
|
|
bool print_fee_info(const std::vector<std::string> &args);
|
2017-05-28 11:18:51 +00:00
|
|
|
bool prepare_multisig(const std::vector<std::string>& args);
|
2018-10-28 13:46:58 +00:00
|
|
|
bool prepare_multisig_main(const std::vector<std::string>& args, bool called_by_mms);
|
2017-05-28 11:18:51 +00:00
|
|
|
bool make_multisig(const std::vector<std::string>& args);
|
2018-10-28 13:46:58 +00:00
|
|
|
bool make_multisig_main(const std::vector<std::string>& args, bool called_by_mms);
|
2017-08-13 14:29:31 +00:00
|
|
|
bool finalize_multisig(const std::vector<std::string> &args);
|
2018-07-12 09:55:52 +00:00
|
|
|
bool exchange_multisig_keys(const std::vector<std::string> &args);
|
2018-10-28 13:46:58 +00:00
|
|
|
bool exchange_multisig_keys_main(const std::vector<std::string> &args, bool called_by_mms);
|
Add N/N multisig tx generation and signing
Scheme by luigi1111:
Multisig for RingCT on Monero
2 of 2
User A (coordinator):
Spendkey b,B
Viewkey a,A (shared)
User B:
Spendkey c,C
Viewkey a,A (shared)
Public Address: C+B, A
Both have their own watch only wallet via C+B, a
A will coordinate spending process (though B could easily as well, coordinator is more needed for more participants)
A and B watch for incoming outputs
B creates "half" key images for discovered output D:
I2_D = (Hs(aR)+c) * Hp(D)
B also creates 1.5 random keypairs (one scalar and 2 pubkeys; one on base G and one on base Hp(D)) for each output, storing the scalar(k) (linked to D),
and sending the pubkeys with I2_D.
A also creates "half" key images:
I1_D = (Hs(aR)+b) * Hp(D)
Then I_D = I1_D + I2_D
Having I_D allows A to check spent status of course, but more importantly allows A to actually build a transaction prefix (and thus transaction).
A builds the transaction until most of the way through MLSAG_Gen, adding the 2 pubkeys (per input) provided with I2_D
to his own generated ones where they are needed (secret row L, R).
At this point, A has a mostly completed transaction (but with an invalid/incomplete signature). A sends over the tx and includes r,
which allows B (with the recipient's address) to verify the destination and amount (by reconstructing the stealth address and decoding ecdhInfo).
B then finishes the signature by computing ss[secret_index][0] = ss[secret_index][0] + k - cc[secret_index]*c (secret indices need to be passed as well).
B can then broadcast the tx, or send it back to A for broadcasting. Once B has completed the signing (and verified the tx to be valid), he can add the full I_D
to his cache, allowing him to verify spent status as well.
NOTE:
A and B *must* present key A and B to each other with a valid signature proving they know a and b respectively.
Otherwise, trickery like the following becomes possible:
A creates viewkey a,A, spendkey b,B, and sends a,A,B to B.
B creates a fake key C = zG - B. B sends C back to A.
The combined spendkey C+B then equals zG, allowing B to spend funds at any time!
The signature fixes this, because B does not know a c corresponding to C (and thus can't produce a signature).
2 of 3
User A (coordinator)
Shared viewkey a,A
"spendkey" j,J
User B
"spendkey" k,K
User C
"spendkey" m,M
A collects K and M from B and C
B collects J and M from A and C
C collects J and K from A and B
A computes N = nG, n = Hs(jK)
A computes O = oG, o = Hs(jM)
B anc C compute P = pG, p = Hs(kM) || Hs(mK)
B and C can also compute N and O respectively if they wish to be able to coordinate
Address: N+O+P, A
The rest follows as above. The coordinator possesses 2 of 3 needed keys; he can get the other
needed part of the signature/key images from either of the other two.
Alternatively, if secure communication exists between parties:
A gives j to B
B gives k to C
C gives m to A
Address: J+K+M, A
3 of 3
Identical to 2 of 2, except the coordinator must collect the key images from both of the others.
The transaction must also be passed an additional hop: A -> B -> C (or A -> C -> B), who can then broadcast it
or send it back to A.
N-1 of N
Generally the same as 2 of 3, except participants need to be arranged in a ring to pass their keys around
(using either the secure or insecure method).
For example (ignoring viewkey so letters line up):
[4 of 5]
User: spendkey
A: a
B: b
C: c
D: d
E: e
a -> B, b -> C, c -> D, d -> E, e -> A
Order of signing does not matter, it just must reach n-1 users. A "remaining keys" list must be passed around with
the transaction so the signers know if they should use 1 or both keys.
Collecting key image parts becomes a little messy, but basically every wallet sends over both of their parts with a tag for each.
Thia way the coordinating wallet can keep track of which images have been added and which wallet they come from. Reasoning:
1. The key images must be added only once (coordinator will get key images for key a from both A and B, he must add only one to get the proper key actual key image)
2. The coordinator must keep track of which helper pubkeys came from which wallet (discussed in 2 of 2 section). The coordinator
must choose only one set to use, then include his choice in the "remaining keys" list so the other wallets know which of their keys to use.
You can generalize it further to N-2 of N or even M of N, but I'm not sure there's legitimate demand to justify the complexity. It might
also be straightforward enough to support with minimal changes from N-1 format.
You basically just give each user additional keys for each additional "-1" you desire. N-2 would be 3 keys per user, N-3 4 keys, etc.
The process is somewhat cumbersome:
To create a N/N multisig wallet:
- each participant creates a normal wallet
- each participant runs "prepare_multisig", and sends the resulting string to every other participant
- each participant runs "make_multisig N A B C D...", with N being the threshold and A B C D... being the strings received from other participants (the threshold must currently equal N)
As txes are received, participants' wallets will need to synchronize so that those new outputs may be spent:
- each participant runs "export_multisig FILENAME", and sends the FILENAME file to every other participant
- each participant runs "import_multisig A B C D...", with A B C D... being the filenames received from other participants
Then, a transaction may be initiated:
- one of the participants runs "transfer ADDRESS AMOUNT"
- this partly signed transaction will be written to the "multisig_monero_tx" file
- the initiator sends this file to another participant
- that other participant runs "sign_multisig multisig_monero_tx"
- the resulting transaction is written to the "multisig_monero_tx" file again
- if the threshold was not reached, the file must be sent to another participant, until enough have signed
- the last participant to sign runs "submit_multisig multisig_monero_tx" to relay the transaction to the Monero network
2017-06-03 21:34:26 +00:00
|
|
|
bool export_multisig(const std::vector<std::string>& args);
|
2018-10-28 13:46:58 +00:00
|
|
|
bool export_multisig_main(const std::vector<std::string>& args, bool called_by_mms);
|
Add N/N multisig tx generation and signing
Scheme by luigi1111:
Multisig for RingCT on Monero
2 of 2
User A (coordinator):
Spendkey b,B
Viewkey a,A (shared)
User B:
Spendkey c,C
Viewkey a,A (shared)
Public Address: C+B, A
Both have their own watch only wallet via C+B, a
A will coordinate spending process (though B could easily as well, coordinator is more needed for more participants)
A and B watch for incoming outputs
B creates "half" key images for discovered output D:
I2_D = (Hs(aR)+c) * Hp(D)
B also creates 1.5 random keypairs (one scalar and 2 pubkeys; one on base G and one on base Hp(D)) for each output, storing the scalar(k) (linked to D),
and sending the pubkeys with I2_D.
A also creates "half" key images:
I1_D = (Hs(aR)+b) * Hp(D)
Then I_D = I1_D + I2_D
Having I_D allows A to check spent status of course, but more importantly allows A to actually build a transaction prefix (and thus transaction).
A builds the transaction until most of the way through MLSAG_Gen, adding the 2 pubkeys (per input) provided with I2_D
to his own generated ones where they are needed (secret row L, R).
At this point, A has a mostly completed transaction (but with an invalid/incomplete signature). A sends over the tx and includes r,
which allows B (with the recipient's address) to verify the destination and amount (by reconstructing the stealth address and decoding ecdhInfo).
B then finishes the signature by computing ss[secret_index][0] = ss[secret_index][0] + k - cc[secret_index]*c (secret indices need to be passed as well).
B can then broadcast the tx, or send it back to A for broadcasting. Once B has completed the signing (and verified the tx to be valid), he can add the full I_D
to his cache, allowing him to verify spent status as well.
NOTE:
A and B *must* present key A and B to each other with a valid signature proving they know a and b respectively.
Otherwise, trickery like the following becomes possible:
A creates viewkey a,A, spendkey b,B, and sends a,A,B to B.
B creates a fake key C = zG - B. B sends C back to A.
The combined spendkey C+B then equals zG, allowing B to spend funds at any time!
The signature fixes this, because B does not know a c corresponding to C (and thus can't produce a signature).
2 of 3
User A (coordinator)
Shared viewkey a,A
"spendkey" j,J
User B
"spendkey" k,K
User C
"spendkey" m,M
A collects K and M from B and C
B collects J and M from A and C
C collects J and K from A and B
A computes N = nG, n = Hs(jK)
A computes O = oG, o = Hs(jM)
B anc C compute P = pG, p = Hs(kM) || Hs(mK)
B and C can also compute N and O respectively if they wish to be able to coordinate
Address: N+O+P, A
The rest follows as above. The coordinator possesses 2 of 3 needed keys; he can get the other
needed part of the signature/key images from either of the other two.
Alternatively, if secure communication exists between parties:
A gives j to B
B gives k to C
C gives m to A
Address: J+K+M, A
3 of 3
Identical to 2 of 2, except the coordinator must collect the key images from both of the others.
The transaction must also be passed an additional hop: A -> B -> C (or A -> C -> B), who can then broadcast it
or send it back to A.
N-1 of N
Generally the same as 2 of 3, except participants need to be arranged in a ring to pass their keys around
(using either the secure or insecure method).
For example (ignoring viewkey so letters line up):
[4 of 5]
User: spendkey
A: a
B: b
C: c
D: d
E: e
a -> B, b -> C, c -> D, d -> E, e -> A
Order of signing does not matter, it just must reach n-1 users. A "remaining keys" list must be passed around with
the transaction so the signers know if they should use 1 or both keys.
Collecting key image parts becomes a little messy, but basically every wallet sends over both of their parts with a tag for each.
Thia way the coordinating wallet can keep track of which images have been added and which wallet they come from. Reasoning:
1. The key images must be added only once (coordinator will get key images for key a from both A and B, he must add only one to get the proper key actual key image)
2. The coordinator must keep track of which helper pubkeys came from which wallet (discussed in 2 of 2 section). The coordinator
must choose only one set to use, then include his choice in the "remaining keys" list so the other wallets know which of their keys to use.
You can generalize it further to N-2 of N or even M of N, but I'm not sure there's legitimate demand to justify the complexity. It might
also be straightforward enough to support with minimal changes from N-1 format.
You basically just give each user additional keys for each additional "-1" you desire. N-2 would be 3 keys per user, N-3 4 keys, etc.
The process is somewhat cumbersome:
To create a N/N multisig wallet:
- each participant creates a normal wallet
- each participant runs "prepare_multisig", and sends the resulting string to every other participant
- each participant runs "make_multisig N A B C D...", with N being the threshold and A B C D... being the strings received from other participants (the threshold must currently equal N)
As txes are received, participants' wallets will need to synchronize so that those new outputs may be spent:
- each participant runs "export_multisig FILENAME", and sends the FILENAME file to every other participant
- each participant runs "import_multisig A B C D...", with A B C D... being the filenames received from other participants
Then, a transaction may be initiated:
- one of the participants runs "transfer ADDRESS AMOUNT"
- this partly signed transaction will be written to the "multisig_monero_tx" file
- the initiator sends this file to another participant
- that other participant runs "sign_multisig multisig_monero_tx"
- the resulting transaction is written to the "multisig_monero_tx" file again
- if the threshold was not reached, the file must be sent to another participant, until enough have signed
- the last participant to sign runs "submit_multisig multisig_monero_tx" to relay the transaction to the Monero network
2017-06-03 21:34:26 +00:00
|
|
|
bool import_multisig(const std::vector<std::string>& args);
|
2018-10-28 13:46:58 +00:00
|
|
|
bool import_multisig_main(const std::vector<std::string>& args, bool called_by_mms);
|
Add N/N multisig tx generation and signing
Scheme by luigi1111:
Multisig for RingCT on Monero
2 of 2
User A (coordinator):
Spendkey b,B
Viewkey a,A (shared)
User B:
Spendkey c,C
Viewkey a,A (shared)
Public Address: C+B, A
Both have their own watch only wallet via C+B, a
A will coordinate spending process (though B could easily as well, coordinator is more needed for more participants)
A and B watch for incoming outputs
B creates "half" key images for discovered output D:
I2_D = (Hs(aR)+c) * Hp(D)
B also creates 1.5 random keypairs (one scalar and 2 pubkeys; one on base G and one on base Hp(D)) for each output, storing the scalar(k) (linked to D),
and sending the pubkeys with I2_D.
A also creates "half" key images:
I1_D = (Hs(aR)+b) * Hp(D)
Then I_D = I1_D + I2_D
Having I_D allows A to check spent status of course, but more importantly allows A to actually build a transaction prefix (and thus transaction).
A builds the transaction until most of the way through MLSAG_Gen, adding the 2 pubkeys (per input) provided with I2_D
to his own generated ones where they are needed (secret row L, R).
At this point, A has a mostly completed transaction (but with an invalid/incomplete signature). A sends over the tx and includes r,
which allows B (with the recipient's address) to verify the destination and amount (by reconstructing the stealth address and decoding ecdhInfo).
B then finishes the signature by computing ss[secret_index][0] = ss[secret_index][0] + k - cc[secret_index]*c (secret indices need to be passed as well).
B can then broadcast the tx, or send it back to A for broadcasting. Once B has completed the signing (and verified the tx to be valid), he can add the full I_D
to his cache, allowing him to verify spent status as well.
NOTE:
A and B *must* present key A and B to each other with a valid signature proving they know a and b respectively.
Otherwise, trickery like the following becomes possible:
A creates viewkey a,A, spendkey b,B, and sends a,A,B to B.
B creates a fake key C = zG - B. B sends C back to A.
The combined spendkey C+B then equals zG, allowing B to spend funds at any time!
The signature fixes this, because B does not know a c corresponding to C (and thus can't produce a signature).
2 of 3
User A (coordinator)
Shared viewkey a,A
"spendkey" j,J
User B
"spendkey" k,K
User C
"spendkey" m,M
A collects K and M from B and C
B collects J and M from A and C
C collects J and K from A and B
A computes N = nG, n = Hs(jK)
A computes O = oG, o = Hs(jM)
B anc C compute P = pG, p = Hs(kM) || Hs(mK)
B and C can also compute N and O respectively if they wish to be able to coordinate
Address: N+O+P, A
The rest follows as above. The coordinator possesses 2 of 3 needed keys; he can get the other
needed part of the signature/key images from either of the other two.
Alternatively, if secure communication exists between parties:
A gives j to B
B gives k to C
C gives m to A
Address: J+K+M, A
3 of 3
Identical to 2 of 2, except the coordinator must collect the key images from both of the others.
The transaction must also be passed an additional hop: A -> B -> C (or A -> C -> B), who can then broadcast it
or send it back to A.
N-1 of N
Generally the same as 2 of 3, except participants need to be arranged in a ring to pass their keys around
(using either the secure or insecure method).
For example (ignoring viewkey so letters line up):
[4 of 5]
User: spendkey
A: a
B: b
C: c
D: d
E: e
a -> B, b -> C, c -> D, d -> E, e -> A
Order of signing does not matter, it just must reach n-1 users. A "remaining keys" list must be passed around with
the transaction so the signers know if they should use 1 or both keys.
Collecting key image parts becomes a little messy, but basically every wallet sends over both of their parts with a tag for each.
Thia way the coordinating wallet can keep track of which images have been added and which wallet they come from. Reasoning:
1. The key images must be added only once (coordinator will get key images for key a from both A and B, he must add only one to get the proper key actual key image)
2. The coordinator must keep track of which helper pubkeys came from which wallet (discussed in 2 of 2 section). The coordinator
must choose only one set to use, then include his choice in the "remaining keys" list so the other wallets know which of their keys to use.
You can generalize it further to N-2 of N or even M of N, but I'm not sure there's legitimate demand to justify the complexity. It might
also be straightforward enough to support with minimal changes from N-1 format.
You basically just give each user additional keys for each additional "-1" you desire. N-2 would be 3 keys per user, N-3 4 keys, etc.
The process is somewhat cumbersome:
To create a N/N multisig wallet:
- each participant creates a normal wallet
- each participant runs "prepare_multisig", and sends the resulting string to every other participant
- each participant runs "make_multisig N A B C D...", with N being the threshold and A B C D... being the strings received from other participants (the threshold must currently equal N)
As txes are received, participants' wallets will need to synchronize so that those new outputs may be spent:
- each participant runs "export_multisig FILENAME", and sends the FILENAME file to every other participant
- each participant runs "import_multisig A B C D...", with A B C D... being the filenames received from other participants
Then, a transaction may be initiated:
- one of the participants runs "transfer ADDRESS AMOUNT"
- this partly signed transaction will be written to the "multisig_monero_tx" file
- the initiator sends this file to another participant
- that other participant runs "sign_multisig multisig_monero_tx"
- the resulting transaction is written to the "multisig_monero_tx" file again
- if the threshold was not reached, the file must be sent to another participant, until enough have signed
- the last participant to sign runs "submit_multisig multisig_monero_tx" to relay the transaction to the Monero network
2017-06-03 21:34:26 +00:00
|
|
|
bool accept_loaded_tx(const tools::wallet2::multisig_tx_set &txs);
|
|
|
|
|
bool sign_multisig(const std::vector<std::string>& args);
|
2018-10-28 13:46:58 +00:00
|
|
|
bool sign_multisig_main(const std::vector<std::string>& args, bool called_by_mms);
|
Add N/N multisig tx generation and signing
Scheme by luigi1111:
Multisig for RingCT on Monero
2 of 2
User A (coordinator):
Spendkey b,B
Viewkey a,A (shared)
User B:
Spendkey c,C
Viewkey a,A (shared)
Public Address: C+B, A
Both have their own watch only wallet via C+B, a
A will coordinate spending process (though B could easily as well, coordinator is more needed for more participants)
A and B watch for incoming outputs
B creates "half" key images for discovered output D:
I2_D = (Hs(aR)+c) * Hp(D)
B also creates 1.5 random keypairs (one scalar and 2 pubkeys; one on base G and one on base Hp(D)) for each output, storing the scalar(k) (linked to D),
and sending the pubkeys with I2_D.
A also creates "half" key images:
I1_D = (Hs(aR)+b) * Hp(D)
Then I_D = I1_D + I2_D
Having I_D allows A to check spent status of course, but more importantly allows A to actually build a transaction prefix (and thus transaction).
A builds the transaction until most of the way through MLSAG_Gen, adding the 2 pubkeys (per input) provided with I2_D
to his own generated ones where they are needed (secret row L, R).
At this point, A has a mostly completed transaction (but with an invalid/incomplete signature). A sends over the tx and includes r,
which allows B (with the recipient's address) to verify the destination and amount (by reconstructing the stealth address and decoding ecdhInfo).
B then finishes the signature by computing ss[secret_index][0] = ss[secret_index][0] + k - cc[secret_index]*c (secret indices need to be passed as well).
B can then broadcast the tx, or send it back to A for broadcasting. Once B has completed the signing (and verified the tx to be valid), he can add the full I_D
to his cache, allowing him to verify spent status as well.
NOTE:
A and B *must* present key A and B to each other with a valid signature proving they know a and b respectively.
Otherwise, trickery like the following becomes possible:
A creates viewkey a,A, spendkey b,B, and sends a,A,B to B.
B creates a fake key C = zG - B. B sends C back to A.
The combined spendkey C+B then equals zG, allowing B to spend funds at any time!
The signature fixes this, because B does not know a c corresponding to C (and thus can't produce a signature).
2 of 3
User A (coordinator)
Shared viewkey a,A
"spendkey" j,J
User B
"spendkey" k,K
User C
"spendkey" m,M
A collects K and M from B and C
B collects J and M from A and C
C collects J and K from A and B
A computes N = nG, n = Hs(jK)
A computes O = oG, o = Hs(jM)
B anc C compute P = pG, p = Hs(kM) || Hs(mK)
B and C can also compute N and O respectively if they wish to be able to coordinate
Address: N+O+P, A
The rest follows as above. The coordinator possesses 2 of 3 needed keys; he can get the other
needed part of the signature/key images from either of the other two.
Alternatively, if secure communication exists between parties:
A gives j to B
B gives k to C
C gives m to A
Address: J+K+M, A
3 of 3
Identical to 2 of 2, except the coordinator must collect the key images from both of the others.
The transaction must also be passed an additional hop: A -> B -> C (or A -> C -> B), who can then broadcast it
or send it back to A.
N-1 of N
Generally the same as 2 of 3, except participants need to be arranged in a ring to pass their keys around
(using either the secure or insecure method).
For example (ignoring viewkey so letters line up):
[4 of 5]
User: spendkey
A: a
B: b
C: c
D: d
E: e
a -> B, b -> C, c -> D, d -> E, e -> A
Order of signing does not matter, it just must reach n-1 users. A "remaining keys" list must be passed around with
the transaction so the signers know if they should use 1 or both keys.
Collecting key image parts becomes a little messy, but basically every wallet sends over both of their parts with a tag for each.
Thia way the coordinating wallet can keep track of which images have been added and which wallet they come from. Reasoning:
1. The key images must be added only once (coordinator will get key images for key a from both A and B, he must add only one to get the proper key actual key image)
2. The coordinator must keep track of which helper pubkeys came from which wallet (discussed in 2 of 2 section). The coordinator
must choose only one set to use, then include his choice in the "remaining keys" list so the other wallets know which of their keys to use.
You can generalize it further to N-2 of N or even M of N, but I'm not sure there's legitimate demand to justify the complexity. It might
also be straightforward enough to support with minimal changes from N-1 format.
You basically just give each user additional keys for each additional "-1" you desire. N-2 would be 3 keys per user, N-3 4 keys, etc.
The process is somewhat cumbersome:
To create a N/N multisig wallet:
- each participant creates a normal wallet
- each participant runs "prepare_multisig", and sends the resulting string to every other participant
- each participant runs "make_multisig N A B C D...", with N being the threshold and A B C D... being the strings received from other participants (the threshold must currently equal N)
As txes are received, participants' wallets will need to synchronize so that those new outputs may be spent:
- each participant runs "export_multisig FILENAME", and sends the FILENAME file to every other participant
- each participant runs "import_multisig A B C D...", with A B C D... being the filenames received from other participants
Then, a transaction may be initiated:
- one of the participants runs "transfer ADDRESS AMOUNT"
- this partly signed transaction will be written to the "multisig_monero_tx" file
- the initiator sends this file to another participant
- that other participant runs "sign_multisig multisig_monero_tx"
- the resulting transaction is written to the "multisig_monero_tx" file again
- if the threshold was not reached, the file must be sent to another participant, until enough have signed
- the last participant to sign runs "submit_multisig multisig_monero_tx" to relay the transaction to the Monero network
2017-06-03 21:34:26 +00:00
|
|
|
bool submit_multisig(const std::vector<std::string>& args);
|
2018-10-28 13:46:58 +00:00
|
|
|
bool submit_multisig_main(const std::vector<std::string>& args, bool called_by_mms);
|
2017-10-07 20:20:28 +00:00
|
|
|
bool export_raw_multisig(const std::vector<std::string>& args);
|
2018-10-28 13:46:58 +00:00
|
|
|
bool mms(const std::vector<std::string>& args);
|
2018-02-18 10:47:25 +00:00
|
|
|
bool print_ring(const std::vector<std::string>& args);
|
2018-02-28 18:26:06 +00:00
|
|
|
bool set_ring(const std::vector<std::string>& args);
|
2019-04-02 14:03:25 +00:00
|
|
|
bool unset_ring(const std::vector<std::string>& args);
|
2018-02-18 10:47:25 +00:00
|
|
|
bool save_known_rings(const std::vector<std::string>& args);
|
2018-02-25 19:20:07 +00:00
|
|
|
bool blackball(const std::vector<std::string>& args);
|
|
|
|
|
bool unblackball(const std::vector<std::string>& args);
|
|
|
|
|
bool blackballed(const std::vector<std::string>& args);
|
2019-03-13 21:51:41 +00:00
|
|
|
bool freeze(const std::vector<std::string>& args);
|
|
|
|
|
bool thaw(const std::vector<std::string>& args);
|
|
|
|
|
bool frozen(const std::vector<std::string>& args);
|
2019-05-06 08:44:50 +00:00
|
|
|
bool lock(const std::vector<std::string>& args);
|
daemon, wallet: new pay for RPC use system
Daemons intended for public use can be set up to require payment
in the form of hashes in exchange for RPC service. This enables
public daemons to receive payment for their work over a large
number of calls. This system behaves similarly to a pool, so
payment takes the form of valid blocks every so often, yielding
a large one off payment, rather than constant micropayments.
This system can also be used by third parties as a "paywall"
layer, where users of a service can pay for use by mining Monero
to the service provider's address. An example of this for web
site access is Primo, a Monero mining based website "paywall":
https://github.com/selene-kovri/primo
This has some advantages:
- incentive to run a node providing RPC services, thereby promoting the availability of third party nodes for those who can't run their own
- incentive to run your own node instead of using a third party's, thereby promoting decentralization
- decentralized: payment is done between a client and server, with no third party needed
- private: since the system is "pay as you go", you don't need to identify yourself to claim a long lived balance
- no payment occurs on the blockchain, so there is no extra transactional load
- one may mine with a beefy server, and use those credits from a phone, by reusing the client ID (at the cost of some privacy)
- no barrier to entry: anyone may run a RPC node, and your expected revenue depends on how much work you do
- Sybil resistant: if you run 1000 idle RPC nodes, you don't magically get more revenue
- no large credit balance maintained on servers, so they have no incentive to exit scam
- you can use any/many node(s), since there's little cost in switching servers
- market based prices: competition between servers to lower costs
- incentive for a distributed third party node system: if some public nodes are overused/slow, traffic can move to others
- increases network security
- helps counteract mining pools' share of the network hash rate
- zero incentive for a payer to "double spend" since a reorg does not give any money back to the miner
And some disadvantages:
- low power clients will have difficulty mining (but one can optionally mine in advance and/or with a faster machine)
- payment is "random", so a server might go a long time without a block before getting one
- a public node's overall expected payment may be small
Public nodes are expected to compete to find a suitable level for
cost of service.
The daemon can be set up this way to require payment for RPC services:
monerod --rpc-payment-address 4xxxxxx \
--rpc-payment-credits 250 --rpc-payment-difficulty 1000
These values are an example only.
The --rpc-payment-difficulty switch selects how hard each "share" should
be, similar to a mining pool. The higher the difficulty, the fewer
shares a client will find.
The --rpc-payment-credits switch selects how many credits are awarded
for each share a client finds.
Considering both options, clients will be awarded credits/difficulty
credits for every hash they calculate. For example, in the command line
above, 0.25 credits per hash. A client mining at 100 H/s will therefore
get an average of 25 credits per second.
For reference, in the current implementation, a credit is enough to
sync 20 blocks, so a 100 H/s client that's just starting to use Monero
and uses this daemon will be able to sync 500 blocks per second.
The wallet can be set to automatically mine if connected to a daemon
which requires payment for RPC usage. It will try to keep a balance
of 50000 credits, stopping mining when it's at this level, and starting
again as credits are spent. With the example above, a new client will
mine this much credits in about half an hour, and this target is enough
to sync 500000 blocks (currently about a third of the monero blockchain).
There are three new settings in the wallet:
- credits-target: this is the amount of credits a wallet will try to
reach before stopping mining. The default of 0 means 50000 credits.
- auto-mine-for-rpc-payment-threshold: this controls the minimum
credit rate which the wallet considers worth mining for. If the
daemon credits less than this ratio, the wallet will consider mining
to be not worth it. In the example above, the rate is 0.25
- persistent-rpc-client-id: if set, this allows the wallet to reuse
a client id across runs. This means a public node can tell a wallet
that's connecting is the same as one that connected previously, but
allows a wallet to keep their credit balance from one run to the
other. Since the wallet only mines to keep a small credit balance,
this is not normally worth doing. However, someone may want to mine
on a fast server, and use that credit balance on a low power device
such as a phone. If left unset, a new client ID is generated at
each wallet start, for privacy reasons.
To mine and use a credit balance on two different devices, you can
use the --rpc-client-secret-key switch. A wallet's client secret key
can be found using the new rpc_payments command in the wallet.
Note: anyone knowing your RPC client secret key is able to use your
credit balance.
The wallet has a few new commands too:
- start_mining_for_rpc: start mining to acquire more credits,
regardless of the auto mining settings
- stop_mining_for_rpc: stop mining to acquire more credits
- rpc_payments: display information about current credits with
the currently selected daemon
The node has an extra command:
- rpc_payments: display information about clients and their
balances
The node will forget about any balance for clients which have
been inactive for 6 months. Balances carry over on node restart.
2018-02-11 15:15:56 +00:00
|
|
|
bool rpc_payment_info(const std::vector<std::string> &args);
|
|
|
|
|
bool start_mining_for_rpc(const std::vector<std::string> &args);
|
|
|
|
|
bool stop_mining_for_rpc(const std::vector<std::string> &args);
|
2019-03-29 22:03:52 +00:00
|
|
|
bool net_stats(const std::vector<std::string>& args);
|
2019-06-25 16:50:08 +00:00
|
|
|
bool public_nodes(const std::vector<std::string>& args);
|
2019-04-01 23:11:56 +00:00
|
|
|
bool welcome(const std::vector<std::string>& args);
|
2018-04-13 17:45:10 +00:00
|
|
|
bool version(const std::vector<std::string>& args);
|
2019-05-06 08:44:50 +00:00
|
|
|
bool on_unknown_command(const std::vector<std::string>& args);
|
2014-03-03 22:07:58 +00:00
|
|
|
|
2019-03-13 21:51:41 +00:00
|
|
|
bool cold_sign_tx(const std::vector<tools::wallet2::pending_tx>& ptx_vector, tools::wallet2::signed_tx_set &exported_txs, std::vector<cryptonote::address_parse_info> &dsts_info, std::function<bool(const tools::wallet2::signed_tx_set &)> accept_func);
|
2014-03-20 11:46:11 +00:00
|
|
|
uint64_t get_daemon_blockchain_height(std::string& err);
|
2016-12-23 12:04:54 +00:00
|
|
|
bool try_connect_to_daemon(bool silent = false, uint32_t* version = nullptr);
|
2014-05-03 16:19:43 +00:00
|
|
|
bool ask_wallet_create_if_needed();
|
2016-11-15 21:22:04 +00:00
|
|
|
bool accept_loaded_tx(const std::function<size_t()> get_num_txes, const std::function<const tools::wallet2::tx_construction_data&(size_t)> &get_tx, const std::string &extra_message = std::string());
|
2016-09-26 22:11:10 +00:00
|
|
|
bool accept_loaded_tx(const tools::wallet2::unsigned_tx_set &txs);
|
2016-10-30 10:49:22 +00:00
|
|
|
bool accept_loaded_tx(const tools::wallet2::signed_tx_set &txs);
|
2016-12-23 12:04:54 +00:00
|
|
|
bool print_ring_members(const std::vector<tools::wallet2::pending_tx>& ptx_vector, std::ostream& ostr);
|
2017-08-02 13:44:42 +00:00
|
|
|
std::string get_prompt() const;
|
2017-08-06 15:51:40 +00:00
|
|
|
bool print_seed(bool encrypted);
|
2018-11-12 03:13:54 +00:00
|
|
|
void key_images_sync_intern();
|
|
|
|
|
void on_refresh_finished(uint64_t start_height, uint64_t fetched_blocks, bool is_init, bool received_money);
|
2018-12-03 15:32:14 +00:00
|
|
|
std::pair<std::string, std::string> show_outputs_line(const std::vector<uint64_t> &heights, uint64_t blockchain_height, uint64_t highlight_height = std::numeric_limits<uint64_t>::max()) const;
|
2019-03-13 21:51:41 +00:00
|
|
|
bool freeze_thaw(const std::vector<std::string>& args, bool freeze);
|
2019-04-18 12:45:19 +00:00
|
|
|
bool prompt_if_old(const std::vector<tools::wallet2::pending_tx> &ptx_vector);
|
2019-05-06 08:44:50 +00:00
|
|
|
bool on_command(bool (simple_wallet::*cmd)(const std::vector<std::string>&), const std::vector<std::string> &args);
|
|
|
|
|
bool on_empty_command();
|
|
|
|
|
bool on_cancelled_command();
|
|
|
|
|
void check_for_inactivity_lock(bool user);
|
2015-11-29 13:02:01 +00:00
|
|
|
|
2018-11-08 05:12:11 +00:00
|
|
|
struct transfer_view
|
|
|
|
|
{
|
2018-12-23 15:14:16 +00:00
|
|
|
std::string type;
|
2018-11-08 05:12:11 +00:00
|
|
|
boost::variant<uint64_t, std::string> block;
|
|
|
|
|
uint64_t timestamp;
|
|
|
|
|
std::string direction;
|
|
|
|
|
bool confirmed;
|
|
|
|
|
uint64_t amount;
|
|
|
|
|
crypto::hash hash;
|
|
|
|
|
std::string payment_id;
|
|
|
|
|
uint64_t fee;
|
|
|
|
|
std::vector<std::pair<std::string, uint64_t>> outputs;
|
|
|
|
|
std::set<uint32_t> index;
|
|
|
|
|
std::string note;
|
|
|
|
|
std::string unlocked;
|
|
|
|
|
};
|
|
|
|
|
bool get_transfers(std::vector<std::string>& args_, std::vector<transfer_view>& transfers);
|
|
|
|
|
|
2014-10-19 09:09:45 +00:00
|
|
|
/*!
|
|
|
|
|
* \brief Prints the seed with a nice message
|
|
|
|
|
* \param seed seed to print
|
|
|
|
|
*/
|
2018-07-06 23:03:15 +00:00
|
|
|
void print_seed(const epee::wipeable_string &seed);
|
2014-09-27 12:50:15 +00:00
|
|
|
|
|
|
|
|
/*!
|
|
|
|
|
* \brief Gets the word seed language from the user.
|
|
|
|
|
*
|
|
|
|
|
* User is asked to choose from a list of supported languages.
|
|
|
|
|
*
|
|
|
|
|
* \return The chosen language.
|
|
|
|
|
*/
|
2014-09-25 12:34:30 +00:00
|
|
|
std::string get_mnemonic_language();
|
2014-03-03 22:07:58 +00:00
|
|
|
|
2017-10-06 01:14:09 +00:00
|
|
|
/*!
|
|
|
|
|
* \brief When --do-not-relay option is specified, save the raw tx hex blob to a file instead of calling m_wallet->commit_tx(ptx).
|
|
|
|
|
* \param ptx_vector Pending tx(es) created by transfer/sweep_all
|
|
|
|
|
*/
|
|
|
|
|
void commit_or_save(std::vector<tools::wallet2::pending_tx>& ptx_vector, bool do_not_relay);
|
|
|
|
|
|
2019-03-30 19:21:30 +00:00
|
|
|
/*!
|
|
|
|
|
* \brief checks whether background mining is enabled, and asks to configure it if not
|
|
|
|
|
*/
|
|
|
|
|
void check_background_mining(const epee::wipeable_string &password);
|
|
|
|
|
void start_background_mining();
|
|
|
|
|
void stop_background_mining();
|
|
|
|
|
|
2019-05-06 08:44:50 +00:00
|
|
|
// idle thread workers
|
|
|
|
|
bool check_inactivity();
|
|
|
|
|
bool check_refresh();
|
|
|
|
|
bool check_mms();
|
daemon, wallet: new pay for RPC use system
Daemons intended for public use can be set up to require payment
in the form of hashes in exchange for RPC service. This enables
public daemons to receive payment for their work over a large
number of calls. This system behaves similarly to a pool, so
payment takes the form of valid blocks every so often, yielding
a large one off payment, rather than constant micropayments.
This system can also be used by third parties as a "paywall"
layer, where users of a service can pay for use by mining Monero
to the service provider's address. An example of this for web
site access is Primo, a Monero mining based website "paywall":
https://github.com/selene-kovri/primo
This has some advantages:
- incentive to run a node providing RPC services, thereby promoting the availability of third party nodes for those who can't run their own
- incentive to run your own node instead of using a third party's, thereby promoting decentralization
- decentralized: payment is done between a client and server, with no third party needed
- private: since the system is "pay as you go", you don't need to identify yourself to claim a long lived balance
- no payment occurs on the blockchain, so there is no extra transactional load
- one may mine with a beefy server, and use those credits from a phone, by reusing the client ID (at the cost of some privacy)
- no barrier to entry: anyone may run a RPC node, and your expected revenue depends on how much work you do
- Sybil resistant: if you run 1000 idle RPC nodes, you don't magically get more revenue
- no large credit balance maintained on servers, so they have no incentive to exit scam
- you can use any/many node(s), since there's little cost in switching servers
- market based prices: competition between servers to lower costs
- incentive for a distributed third party node system: if some public nodes are overused/slow, traffic can move to others
- increases network security
- helps counteract mining pools' share of the network hash rate
- zero incentive for a payer to "double spend" since a reorg does not give any money back to the miner
And some disadvantages:
- low power clients will have difficulty mining (but one can optionally mine in advance and/or with a faster machine)
- payment is "random", so a server might go a long time without a block before getting one
- a public node's overall expected payment may be small
Public nodes are expected to compete to find a suitable level for
cost of service.
The daemon can be set up this way to require payment for RPC services:
monerod --rpc-payment-address 4xxxxxx \
--rpc-payment-credits 250 --rpc-payment-difficulty 1000
These values are an example only.
The --rpc-payment-difficulty switch selects how hard each "share" should
be, similar to a mining pool. The higher the difficulty, the fewer
shares a client will find.
The --rpc-payment-credits switch selects how many credits are awarded
for each share a client finds.
Considering both options, clients will be awarded credits/difficulty
credits for every hash they calculate. For example, in the command line
above, 0.25 credits per hash. A client mining at 100 H/s will therefore
get an average of 25 credits per second.
For reference, in the current implementation, a credit is enough to
sync 20 blocks, so a 100 H/s client that's just starting to use Monero
and uses this daemon will be able to sync 500 blocks per second.
The wallet can be set to automatically mine if connected to a daemon
which requires payment for RPC usage. It will try to keep a balance
of 50000 credits, stopping mining when it's at this level, and starting
again as credits are spent. With the example above, a new client will
mine this much credits in about half an hour, and this target is enough
to sync 500000 blocks (currently about a third of the monero blockchain).
There are three new settings in the wallet:
- credits-target: this is the amount of credits a wallet will try to
reach before stopping mining. The default of 0 means 50000 credits.
- auto-mine-for-rpc-payment-threshold: this controls the minimum
credit rate which the wallet considers worth mining for. If the
daemon credits less than this ratio, the wallet will consider mining
to be not worth it. In the example above, the rate is 0.25
- persistent-rpc-client-id: if set, this allows the wallet to reuse
a client id across runs. This means a public node can tell a wallet
that's connecting is the same as one that connected previously, but
allows a wallet to keep their credit balance from one run to the
other. Since the wallet only mines to keep a small credit balance,
this is not normally worth doing. However, someone may want to mine
on a fast server, and use that credit balance on a low power device
such as a phone. If left unset, a new client ID is generated at
each wallet start, for privacy reasons.
To mine and use a credit balance on two different devices, you can
use the --rpc-client-secret-key switch. A wallet's client secret key
can be found using the new rpc_payments command in the wallet.
Note: anyone knowing your RPC client secret key is able to use your
credit balance.
The wallet has a few new commands too:
- start_mining_for_rpc: start mining to acquire more credits,
regardless of the auto mining settings
- stop_mining_for_rpc: stop mining to acquire more credits
- rpc_payments: display information about current credits with
the currently selected daemon
The node has an extra command:
- rpc_payments: display information about clients and their
balances
The node will forget about any balance for clients which have
been inactive for 6 months. Balances carry over on node restart.
2018-02-11 15:15:56 +00:00
|
|
|
bool check_rpc_payment();
|
|
|
|
|
|
|
|
|
|
void handle_transfer_exception(const std::exception_ptr &e, bool trusted_daemon);
|
2019-05-06 08:44:50 +00:00
|
|
|
|
2019-06-25 16:50:08 +00:00
|
|
|
bool check_daemon_rpc_prices(const std::string &daemon_url, uint32_t &actual_cph, uint32_t &claimed_cph);
|
|
|
|
|
|
2014-04-02 16:00:17 +00:00
|
|
|
//----------------- i_wallet2_callback ---------------------
|
|
|
|
|
virtual void on_new_block(uint64_t height, const cryptonote::block& block);
|
2019-05-16 21:34:59 +00:00
|
|
|
virtual void on_money_received(uint64_t height, const crypto::hash &txid, const cryptonote::transaction& tx, uint64_t amount, const cryptonote::subaddress_index& subaddr_index, uint64_t unlock_time);
|
2017-02-19 02:42:10 +00:00
|
|
|
virtual void on_unconfirmed_money_received(uint64_t height, const crypto::hash &txid, const cryptonote::transaction& tx, uint64_t amount, const cryptonote::subaddress_index& subaddr_index);
|
|
|
|
|
virtual void on_money_spent(uint64_t height, const crypto::hash &txid, const cryptonote::transaction& in_tx, uint64_t amount, const cryptonote::transaction& spend_tx, const cryptonote::subaddress_index& subaddr_index);
|
2017-02-27 20:26:17 +00:00
|
|
|
virtual void on_skip_transaction(uint64_t height, const crypto::hash &txid, const cryptonote::transaction& tx);
|
2018-07-08 20:12:33 +00:00
|
|
|
virtual boost::optional<epee::wipeable_string> on_get_password(const char *reason);
|
2019-02-23 14:28:18 +00:00
|
|
|
virtual void on_device_button_request(uint64_t code);
|
|
|
|
|
virtual boost::optional<epee::wipeable_string> on_device_pin_request();
|
|
|
|
|
virtual boost::optional<epee::wipeable_string> on_device_passphrase_request(bool on_device);
|
2014-04-02 16:00:17 +00:00
|
|
|
//----------------------------------------------------------
|
|
|
|
|
|
|
|
|
|
friend class refresh_progress_reporter_t;
|
|
|
|
|
|
|
|
|
|
class refresh_progress_reporter_t
|
|
|
|
|
{
|
|
|
|
|
public:
|
|
|
|
|
refresh_progress_reporter_t(cryptonote::simple_wallet& simple_wallet)
|
|
|
|
|
: m_simple_wallet(simple_wallet)
|
|
|
|
|
, m_blockchain_height(0)
|
|
|
|
|
, m_blockchain_height_update_time()
|
|
|
|
|
, m_print_time()
|
|
|
|
|
{
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void update(uint64_t height, bool force = false)
|
|
|
|
|
{
|
|
|
|
|
auto current_time = std::chrono::system_clock::now();
|
2016-01-29 15:09:17 +00:00
|
|
|
const auto node_update_threshold = std::chrono::seconds(DIFFICULTY_TARGET_V1 / 2); // use min of V1/V2
|
|
|
|
|
if (node_update_threshold < current_time - m_blockchain_height_update_time || m_blockchain_height <= height)
|
2014-04-02 16:00:17 +00:00
|
|
|
{
|
|
|
|
|
update_blockchain_height();
|
|
|
|
|
m_blockchain_height = (std::max)(m_blockchain_height, height);
|
|
|
|
|
}
|
|
|
|
|
|
2015-11-21 11:52:35 +00:00
|
|
|
if (std::chrono::milliseconds(20) < current_time - m_print_time || force)
|
2014-04-02 16:00:17 +00:00
|
|
|
{
|
2015-11-21 11:52:35 +00:00
|
|
|
std::cout << QT_TRANSLATE_NOOP("cryptonote::simple_wallet", "Height ") << height << " / " << m_blockchain_height << '\r' << std::flush;
|
2014-04-02 16:00:17 +00:00
|
|
|
m_print_time = current_time;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
private:
|
|
|
|
|
void update_blockchain_height()
|
|
|
|
|
{
|
|
|
|
|
std::string err;
|
|
|
|
|
uint64_t blockchain_height = m_simple_wallet.get_daemon_blockchain_height(err);
|
|
|
|
|
if (err.empty())
|
|
|
|
|
{
|
|
|
|
|
m_blockchain_height = blockchain_height;
|
|
|
|
|
m_blockchain_height_update_time = std::chrono::system_clock::now();
|
|
|
|
|
}
|
|
|
|
|
else
|
|
|
|
|
{
|
|
|
|
|
LOG_ERROR("Failed to get current blockchain height: " << err);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
private:
|
|
|
|
|
cryptonote::simple_wallet& m_simple_wallet;
|
|
|
|
|
uint64_t m_blockchain_height;
|
|
|
|
|
std::chrono::system_clock::time_point m_blockchain_height_update_time;
|
|
|
|
|
std::chrono::system_clock::time_point m_print_time;
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
private:
|
2014-03-03 22:07:58 +00:00
|
|
|
std::string m_wallet_file;
|
|
|
|
|
std::string m_generate_new;
|
2018-02-20 16:01:27 +00:00
|
|
|
std::string m_generate_from_device;
|
2015-06-20 11:31:53 +00:00
|
|
|
std::string m_generate_from_view_key;
|
2017-10-09 23:31:46 +00:00
|
|
|
std::string m_generate_from_spend_key;
|
2016-02-22 22:10:55 +00:00
|
|
|
std::string m_generate_from_keys;
|
2017-07-28 23:41:24 +00:00
|
|
|
std::string m_generate_from_multisig_keys;
|
wallet: add a --generate-from-json flag
It takes a filename containing JSON data to generate a wallet.
The following fields are valid:
version: integer, should be 1
filename: string, path/filename for the newly created wallet
scan_from_height: 64 bit unsigned integer, optional
password: string, optional
viewkey: string, hex representation
spendkey: string, hex representation
seed: string, optional, list of words separated by spaces
Either seed or private keys should be given. If using private
keys, the spend key may be omitted (the wallet will not be
able to spend, but will see incoming transactions).
If scan_from_height is given, blocks below this height will not
be checked for transactions as an optimization.
2016-03-25 00:48:11 +00:00
|
|
|
std::string m_generate_from_json;
|
2017-08-14 03:00:25 +00:00
|
|
|
std::string m_mnemonic_language;
|
2014-03-03 22:07:58 +00:00
|
|
|
std::string m_import_path;
|
2018-03-16 04:11:45 +00:00
|
|
|
std::string m_subaddress_lookahead;
|
2018-12-14 16:37:38 +00:00
|
|
|
std::string m_restore_date; // optional - converted to m_restore_height
|
2014-03-03 22:07:58 +00:00
|
|
|
|
2018-07-06 23:03:15 +00:00
|
|
|
epee::wipeable_string m_electrum_seed; // electrum-style seed parameter
|
2014-06-04 22:59:47 +00:00
|
|
|
|
|
|
|
|
crypto::secret_key m_recovery_key; // recovery key (used as random for wallet gen)
|
2014-06-08 22:59:02 +00:00
|
|
|
bool m_restore_deterministic_wallet; // recover flag
|
2017-11-09 10:59:41 +00:00
|
|
|
bool m_restore_multisig_wallet; // recover flag
|
2014-06-09 00:04:32 +00:00
|
|
|
bool m_non_deterministic; // old 2-random generation
|
2016-07-10 15:49:40 +00:00
|
|
|
bool m_allow_mismatched_daemon_version;
|
2016-08-09 23:54:20 +00:00
|
|
|
bool m_restoring; // are we restoring, by whatever method?
|
2016-04-15 18:10:20 +00:00
|
|
|
uint64_t m_restore_height; // optional
|
2017-10-06 01:14:09 +00:00
|
|
|
bool m_do_not_relay;
|
2018-03-17 22:46:41 +00:00
|
|
|
bool m_use_english_language_names;
|
2014-06-04 22:59:47 +00:00
|
|
|
|
2014-03-03 22:07:58 +00:00
|
|
|
epee::console_handlers_binder m_cmd_binder;
|
|
|
|
|
|
2014-03-20 11:46:11 +00:00
|
|
|
std::unique_ptr<tools::wallet2> m_wallet;
|
2014-04-02 16:00:17 +00:00
|
|
|
refresh_progress_reporter_t m_refresh_progress_reporter;
|
2015-11-28 12:38:58 +00:00
|
|
|
|
2016-08-07 12:06:40 +00:00
|
|
|
std::atomic<bool> m_idle_run;
|
|
|
|
|
boost::thread m_idle_thread;
|
|
|
|
|
boost::mutex m_idle_mutex;
|
|
|
|
|
boost::condition_variable m_idle_cond;
|
|
|
|
|
|
|
|
|
|
std::atomic<bool> m_auto_refresh_enabled;
|
2015-11-28 12:38:58 +00:00
|
|
|
bool m_auto_refresh_refreshing;
|
2015-11-29 13:02:01 +00:00
|
|
|
std::atomic<bool> m_in_manual_refresh;
|
2017-02-19 02:42:10 +00:00
|
|
|
uint32_t m_current_subaddress_account;
|
2018-12-27 00:43:15 +00:00
|
|
|
|
2019-05-06 08:44:50 +00:00
|
|
|
std::atomic<time_t> m_last_activity_time;
|
|
|
|
|
std::atomic<bool> m_locked;
|
|
|
|
|
std::atomic<bool> m_in_command;
|
|
|
|
|
|
|
|
|
|
epee::math_helper::once_a_time_seconds<1> m_inactivity_checker;
|
|
|
|
|
epee::math_helper::once_a_time_seconds<90> m_refresh_checker;
|
|
|
|
|
epee::math_helper::once_a_time_seconds<90> m_mms_checker;
|
daemon, wallet: new pay for RPC use system
Daemons intended for public use can be set up to require payment
in the form of hashes in exchange for RPC service. This enables
public daemons to receive payment for their work over a large
number of calls. This system behaves similarly to a pool, so
payment takes the form of valid blocks every so often, yielding
a large one off payment, rather than constant micropayments.
This system can also be used by third parties as a "paywall"
layer, where users of a service can pay for use by mining Monero
to the service provider's address. An example of this for web
site access is Primo, a Monero mining based website "paywall":
https://github.com/selene-kovri/primo
This has some advantages:
- incentive to run a node providing RPC services, thereby promoting the availability of third party nodes for those who can't run their own
- incentive to run your own node instead of using a third party's, thereby promoting decentralization
- decentralized: payment is done between a client and server, with no third party needed
- private: since the system is "pay as you go", you don't need to identify yourself to claim a long lived balance
- no payment occurs on the blockchain, so there is no extra transactional load
- one may mine with a beefy server, and use those credits from a phone, by reusing the client ID (at the cost of some privacy)
- no barrier to entry: anyone may run a RPC node, and your expected revenue depends on how much work you do
- Sybil resistant: if you run 1000 idle RPC nodes, you don't magically get more revenue
- no large credit balance maintained on servers, so they have no incentive to exit scam
- you can use any/many node(s), since there's little cost in switching servers
- market based prices: competition between servers to lower costs
- incentive for a distributed third party node system: if some public nodes are overused/slow, traffic can move to others
- increases network security
- helps counteract mining pools' share of the network hash rate
- zero incentive for a payer to "double spend" since a reorg does not give any money back to the miner
And some disadvantages:
- low power clients will have difficulty mining (but one can optionally mine in advance and/or with a faster machine)
- payment is "random", so a server might go a long time without a block before getting one
- a public node's overall expected payment may be small
Public nodes are expected to compete to find a suitable level for
cost of service.
The daemon can be set up this way to require payment for RPC services:
monerod --rpc-payment-address 4xxxxxx \
--rpc-payment-credits 250 --rpc-payment-difficulty 1000
These values are an example only.
The --rpc-payment-difficulty switch selects how hard each "share" should
be, similar to a mining pool. The higher the difficulty, the fewer
shares a client will find.
The --rpc-payment-credits switch selects how many credits are awarded
for each share a client finds.
Considering both options, clients will be awarded credits/difficulty
credits for every hash they calculate. For example, in the command line
above, 0.25 credits per hash. A client mining at 100 H/s will therefore
get an average of 25 credits per second.
For reference, in the current implementation, a credit is enough to
sync 20 blocks, so a 100 H/s client that's just starting to use Monero
and uses this daemon will be able to sync 500 blocks per second.
The wallet can be set to automatically mine if connected to a daemon
which requires payment for RPC usage. It will try to keep a balance
of 50000 credits, stopping mining when it's at this level, and starting
again as credits are spent. With the example above, a new client will
mine this much credits in about half an hour, and this target is enough
to sync 500000 blocks (currently about a third of the monero blockchain).
There are three new settings in the wallet:
- credits-target: this is the amount of credits a wallet will try to
reach before stopping mining. The default of 0 means 50000 credits.
- auto-mine-for-rpc-payment-threshold: this controls the minimum
credit rate which the wallet considers worth mining for. If the
daemon credits less than this ratio, the wallet will consider mining
to be not worth it. In the example above, the rate is 0.25
- persistent-rpc-client-id: if set, this allows the wallet to reuse
a client id across runs. This means a public node can tell a wallet
that's connecting is the same as one that connected previously, but
allows a wallet to keep their credit balance from one run to the
other. Since the wallet only mines to keep a small credit balance,
this is not normally worth doing. However, someone may want to mine
on a fast server, and use that credit balance on a low power device
such as a phone. If left unset, a new client ID is generated at
each wallet start, for privacy reasons.
To mine and use a credit balance on two different devices, you can
use the --rpc-client-secret-key switch. A wallet's client secret key
can be found using the new rpc_payments command in the wallet.
Note: anyone knowing your RPC client secret key is able to use your
credit balance.
The wallet has a few new commands too:
- start_mining_for_rpc: start mining to acquire more credits,
regardless of the auto mining settings
- stop_mining_for_rpc: stop mining to acquire more credits
- rpc_payments: display information about current credits with
the currently selected daemon
The node has an extra command:
- rpc_payments: display information about clients and their
balances
The node will forget about any balance for clients which have
been inactive for 6 months. Balances carry over on node restart.
2018-02-11 15:15:56 +00:00
|
|
|
epee::math_helper::once_a_time_seconds<90> m_rpc_payment_checker;
|
2018-10-28 13:46:58 +00:00
|
|
|
|
daemon, wallet: new pay for RPC use system
Daemons intended for public use can be set up to require payment
in the form of hashes in exchange for RPC service. This enables
public daemons to receive payment for their work over a large
number of calls. This system behaves similarly to a pool, so
payment takes the form of valid blocks every so often, yielding
a large one off payment, rather than constant micropayments.
This system can also be used by third parties as a "paywall"
layer, where users of a service can pay for use by mining Monero
to the service provider's address. An example of this for web
site access is Primo, a Monero mining based website "paywall":
https://github.com/selene-kovri/primo
This has some advantages:
- incentive to run a node providing RPC services, thereby promoting the availability of third party nodes for those who can't run their own
- incentive to run your own node instead of using a third party's, thereby promoting decentralization
- decentralized: payment is done between a client and server, with no third party needed
- private: since the system is "pay as you go", you don't need to identify yourself to claim a long lived balance
- no payment occurs on the blockchain, so there is no extra transactional load
- one may mine with a beefy server, and use those credits from a phone, by reusing the client ID (at the cost of some privacy)
- no barrier to entry: anyone may run a RPC node, and your expected revenue depends on how much work you do
- Sybil resistant: if you run 1000 idle RPC nodes, you don't magically get more revenue
- no large credit balance maintained on servers, so they have no incentive to exit scam
- you can use any/many node(s), since there's little cost in switching servers
- market based prices: competition between servers to lower costs
- incentive for a distributed third party node system: if some public nodes are overused/slow, traffic can move to others
- increases network security
- helps counteract mining pools' share of the network hash rate
- zero incentive for a payer to "double spend" since a reorg does not give any money back to the miner
And some disadvantages:
- low power clients will have difficulty mining (but one can optionally mine in advance and/or with a faster machine)
- payment is "random", so a server might go a long time without a block before getting one
- a public node's overall expected payment may be small
Public nodes are expected to compete to find a suitable level for
cost of service.
The daemon can be set up this way to require payment for RPC services:
monerod --rpc-payment-address 4xxxxxx \
--rpc-payment-credits 250 --rpc-payment-difficulty 1000
These values are an example only.
The --rpc-payment-difficulty switch selects how hard each "share" should
be, similar to a mining pool. The higher the difficulty, the fewer
shares a client will find.
The --rpc-payment-credits switch selects how many credits are awarded
for each share a client finds.
Considering both options, clients will be awarded credits/difficulty
credits for every hash they calculate. For example, in the command line
above, 0.25 credits per hash. A client mining at 100 H/s will therefore
get an average of 25 credits per second.
For reference, in the current implementation, a credit is enough to
sync 20 blocks, so a 100 H/s client that's just starting to use Monero
and uses this daemon will be able to sync 500 blocks per second.
The wallet can be set to automatically mine if connected to a daemon
which requires payment for RPC usage. It will try to keep a balance
of 50000 credits, stopping mining when it's at this level, and starting
again as credits are spent. With the example above, a new client will
mine this much credits in about half an hour, and this target is enough
to sync 500000 blocks (currently about a third of the monero blockchain).
There are three new settings in the wallet:
- credits-target: this is the amount of credits a wallet will try to
reach before stopping mining. The default of 0 means 50000 credits.
- auto-mine-for-rpc-payment-threshold: this controls the minimum
credit rate which the wallet considers worth mining for. If the
daemon credits less than this ratio, the wallet will consider mining
to be not worth it. In the example above, the rate is 0.25
- persistent-rpc-client-id: if set, this allows the wallet to reuse
a client id across runs. This means a public node can tell a wallet
that's connecting is the same as one that connected previously, but
allows a wallet to keep their credit balance from one run to the
other. Since the wallet only mines to keep a small credit balance,
this is not normally worth doing. However, someone may want to mine
on a fast server, and use that credit balance on a low power device
such as a phone. If left unset, a new client ID is generated at
each wallet start, for privacy reasons.
To mine and use a credit balance on two different devices, you can
use the --rpc-client-secret-key switch. A wallet's client secret key
can be found using the new rpc_payments command in the wallet.
Note: anyone knowing your RPC client secret key is able to use your
credit balance.
The wallet has a few new commands too:
- start_mining_for_rpc: start mining to acquire more credits,
regardless of the auto mining settings
- stop_mining_for_rpc: stop mining to acquire more credits
- rpc_payments: display information about current credits with
the currently selected daemon
The node has an extra command:
- rpc_payments: display information about clients and their
balances
The node will forget about any balance for clients which have
been inactive for 6 months. Balances carry over on node restart.
2018-02-11 15:15:56 +00:00
|
|
|
std::atomic<bool> m_need_payment;
|
|
|
|
|
boost::posix_time::ptime m_last_rpc_payment_mining_time;
|
|
|
|
|
bool m_rpc_payment_mining_requested;
|
|
|
|
|
bool m_daemon_rpc_payment_message_displayed;
|
|
|
|
|
float m_rpc_payment_hash_rate;
|
|
|
|
|
std::atomic<bool> m_suspend_rpc_payment_mining;
|
|
|
|
|
|
2019-06-25 16:50:08 +00:00
|
|
|
std::unordered_map<std::string, uint32_t> m_claimed_cph;
|
|
|
|
|
|
2018-10-28 13:46:58 +00:00
|
|
|
// MMS
|
|
|
|
|
mms::message_store& get_message_store() const { return m_wallet->get_message_store(); };
|
|
|
|
|
mms::multisig_wallet_state get_multisig_wallet_state() const { return m_wallet->get_multisig_wallet_state(); };
|
|
|
|
|
bool mms_active() const { return get_message_store().get_active(); };
|
|
|
|
|
bool choose_mms_processing(const std::vector<mms::processing_data> &data_list, uint32_t &choice);
|
|
|
|
|
void list_mms_messages(const std::vector<mms::message> &messages);
|
|
|
|
|
void list_signers(const std::vector<mms::authorized_signer> &signers);
|
|
|
|
|
void add_signer_config_messages();
|
|
|
|
|
void show_message(const mms::message &m);
|
|
|
|
|
void ask_send_all_ready_messages();
|
|
|
|
|
void check_for_messages();
|
|
|
|
|
bool user_confirms(const std::string &question);
|
|
|
|
|
bool get_message_from_arg(const std::string &arg, mms::message &m);
|
|
|
|
|
bool get_number_from_arg(const std::string &arg, uint32_t &number, const uint32_t lower_bound, const uint32_t upper_bound);
|
|
|
|
|
|
|
|
|
|
void mms_init(const std::vector<std::string> &args);
|
|
|
|
|
void mms_info(const std::vector<std::string> &args);
|
|
|
|
|
void mms_signer(const std::vector<std::string> &args);
|
|
|
|
|
void mms_list(const std::vector<std::string> &args);
|
|
|
|
|
void mms_next(const std::vector<std::string> &args);
|
|
|
|
|
void mms_sync(const std::vector<std::string> &args);
|
|
|
|
|
void mms_transfer(const std::vector<std::string> &args);
|
|
|
|
|
void mms_delete(const std::vector<std::string> &args);
|
|
|
|
|
void mms_send(const std::vector<std::string> &args);
|
|
|
|
|
void mms_receive(const std::vector<std::string> &args);
|
|
|
|
|
void mms_export(const std::vector<std::string> &args);
|
|
|
|
|
void mms_note(const std::vector<std::string> &args);
|
|
|
|
|
void mms_show(const std::vector<std::string> &args);
|
|
|
|
|
void mms_set(const std::vector<std::string> &args);
|
|
|
|
|
void mms_help(const std::vector<std::string> &args);
|
|
|
|
|
void mms_send_signer_config(const std::vector<std::string> &args);
|
|
|
|
|
void mms_start_auto_config(const std::vector<std::string> &args);
|
|
|
|
|
void mms_stop_auto_config(const std::vector<std::string> &args);
|
|
|
|
|
void mms_auto_config(const std::vector<std::string> &args);
|
2014-03-03 22:07:58 +00:00
|
|
|
};
|
|
|
|
|
}
|
