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
# pragma once
# include <memory>
2016-11-09 03:55:41 +00:00
# include <boost/program_options/options_description.hpp>
# include <boost/program_options/variables_map.hpp>
2014-03-03 22:07:58 +00:00
# include <boost/serialization/list.hpp>
# include <boost/serialization/vector.hpp>
2017-09-11 13:38:37 +00:00
# include <boost/serialization/deque.hpp>
2018-11-15 16:29:34 +00:00
# include <boost/thread/lock_guard.hpp>
2014-03-03 22:07:58 +00:00
# include <atomic>
2019-04-02 14:16:45 +00:00
# include <random>
2014-04-02 16:00:17 +00:00
2014-03-03 22:07:58 +00:00
# include "include_base_utils.h"
2017-01-26 15:07:23 +00:00
# include "cryptonote_basic/account.h"
# include "cryptonote_basic/account_boost_serialization.h"
# include "cryptonote_basic/cryptonote_basic_impl.h"
2014-03-03 22:07:58 +00:00
# include "net/http_client.h"
# include "storages/http_abstract_invoke.h"
# include "rpc/core_rpc_server_commands_defs.h"
2017-01-26 15:07:23 +00:00
# include "cryptonote_basic/cryptonote_format_utils.h"
# include "cryptonote_core/cryptonote_tx_utils.h"
2014-03-03 22:07:58 +00:00
# include "common/unordered_containers_boost_serialization.h"
2018-11-15 16:29:34 +00:00
# include "common/util.h"
2017-12-07 13:27:11 +00:00
# include "crypto/chacha.h"
2014-03-03 22:07:58 +00:00
# include "crypto/hash.h"
2016-06-15 22:37:13 +00:00
# include "ringct/rctTypes.h"
# include "ringct/rctOps.h"
2017-09-11 13:38:37 +00:00
# include "checkpoints/checkpoints.h"
2018-08-23 21:50:53 +00:00
# include "serialization/pair.h"
2014-03-03 22:07:58 +00:00
2014-04-02 16:00:17 +00:00
# include "wallet_errors.h"
2017-02-05 22:48:03 +00:00
# include "common/password.h"
2017-01-07 19:23:57 +00:00
# include "node_rpc_proxy.h"
2018-10-28 13:46:58 +00:00
# include "message_store.h"
2019-03-15 13:34:08 +00:00
# include "wallet_light_rpc.h"
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
# include "wallet_rpc_helpers.h"
2014-04-02 16:00:17 +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.wallet2"
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
# define THROW_ON_RPC_RESPONSE_ERROR(r, error, res, method, ...) \
do { \
handle_payment_changes ( res , std : : integral_constant < bool , HasCredits < decltype ( res ) > : : Has > ( ) ) ; \
throw_on_rpc_response_error ( r , error , res . status , method ) ; \
THROW_WALLET_EXCEPTION_IF ( res . status ! = CORE_RPC_STATUS_OK , # # __VA_ARGS__ ) ; \
} while ( 0 )
# define THROW_ON_RPC_RESPONSE_ERROR_GENERIC(r, err, res, method) \
THROW_ON_RPC_RESPONSE_ERROR ( r , err , res , method , tools : : error : : wallet_generic_rpc_error , method , res . status )
2017-01-02 01:43:20 +00:00
class Serialization_portability_wallet_Test ;
2018-11-20 13:40:51 +00:00
class wallet_accessor_test ;
2017-01-02 01:43:20 +00:00
2014-03-03 22:07:58 +00:00
namespace tools
{
2018-02-27 08:30:59 +00:00
class ringdb ;
2018-07-08 20:12:33 +00:00
class wallet2 ;
2018-09-29 20:18:08 +00:00
class Notify ;
2018-07-08 20:12:33 +00:00
2019-04-02 14:16:45 +00:00
class gamma_picker
{
public :
uint64_t pick ( ) ;
gamma_picker ( const std : : vector < uint64_t > & rct_offsets ) ;
gamma_picker ( const std : : vector < uint64_t > & rct_offsets , double shape , double scale ) ;
private :
struct gamma_engine
{
typedef uint64_t result_type ;
static constexpr result_type min ( ) { return 0 ; }
static constexpr result_type max ( ) { return std : : numeric_limits < result_type > : : max ( ) ; }
result_type operator ( ) ( ) { return crypto : : rand < result_type > ( ) ; }
} engine ;
private :
std : : gamma_distribution < double > gamma ;
const std : : vector < uint64_t > & rct_offsets ;
const uint64_t * begin , * end ;
uint64_t num_rct_outputs ;
double average_output_time ;
} ;
2018-07-08 20:12:33 +00:00
class wallet_keys_unlocker
{
public :
wallet_keys_unlocker ( wallet2 & w , const boost : : optional < tools : : password_container > & password ) ;
wallet_keys_unlocker ( wallet2 & w , bool locked , const epee : : wipeable_string & password ) ;
~ wallet_keys_unlocker ( ) ;
private :
wallet2 & w ;
bool locked ;
crypto : : chacha_key key ;
2019-10-29 13:53:07 +00:00
static boost : : mutex lockers_lock ;
static unsigned int lockers ;
2018-07-08 20:12:33 +00:00
} ;
2018-02-27 08:30:59 +00:00
2014-04-02 16:00:17 +00:00
class i_wallet2_callback
2014-03-20 11:46:11 +00:00
{
2014-04-02 16:00:17 +00:00
public :
2017-08-05 15:01:50 +00:00
// Full wallet callbacks
2014-04-02 16:00:17 +00:00
virtual void on_new_block ( uint64_t height , const cryptonote : : block & block ) { }
2020-05-13 00:25:56 +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 , bool is_change , 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 ) { return boost : : none ; }
2017-08-05 15:01:50 +00:00
// Light wallet callbacks
virtual void on_lw_new_block ( uint64_t height ) { }
virtual void on_lw_money_received ( uint64_t height , const crypto : : hash & txid , uint64_t amount ) { }
virtual void on_lw_unconfirmed_money_received ( uint64_t height , const crypto : : hash & txid , uint64_t amount ) { }
virtual void on_lw_money_spent ( uint64_t height , const crypto : : hash & txid , uint64_t amount ) { }
2018-11-11 19:07:25 +00:00
// Device callbacks
2019-02-23 14:28:18 +00:00
virtual void on_device_button_request ( uint64_t code ) { }
2019-04-05 19:47:24 +00:00
virtual void on_device_button_pressed ( ) { }
2019-02-23 14:28:18 +00:00
virtual boost : : optional < epee : : wipeable_string > on_device_pin_request ( ) { return boost : : none ; }
2020-04-07 16:25:25 +00:00
virtual boost : : optional < epee : : wipeable_string > on_device_passphrase_request ( bool & on_device ) { on_device = true ; return boost : : none ; }
2019-02-23 14:28:18 +00:00
virtual void on_device_progress ( const hw : : device_progress & event ) { } ;
2017-08-05 15:01:50 +00:00
// Common callbacks
2017-08-04 21:18:46 +00:00
virtual void on_pool_tx_removed ( const crypto : : hash & txid ) { }
2016-05-13 09:59:29 +00:00
virtual ~ i_wallet2_callback ( ) { }
2014-04-02 16:00:17 +00:00
} ;
2018-11-11 19:07:25 +00:00
class wallet_device_callback : public hw : : i_device_callback
{
public :
wallet_device_callback ( wallet2 * wallet ) : wallet ( wallet ) { } ;
2019-02-23 14:28:18 +00:00
void on_button_request ( uint64_t code = 0 ) override ;
2019-04-05 19:47:24 +00:00
void on_button_pressed ( ) override ;
2019-02-23 14:28:18 +00:00
boost : : optional < epee : : wipeable_string > on_pin_request ( ) override ;
2020-04-07 16:25:25 +00:00
boost : : optional < epee : : wipeable_string > on_passphrase_request ( bool & on_device ) override ;
2019-02-23 14:28:18 +00:00
void on_progress ( const hw : : device_progress & event ) override ;
2018-11-11 19:07:25 +00:00
private :
wallet2 * wallet ;
} ;
2014-04-02 16:00:17 +00:00
struct tx_dust_policy
{
uint64_t dust_threshold ;
bool add_to_fee ;
cryptonote : : account_public_address addr_for_dust ;
tx_dust_policy ( uint64_t a_dust_threshold = 0 , bool an_add_to_fee = true , cryptonote : : account_public_address an_addr_for_dust = cryptonote : : account_public_address ( ) )
: dust_threshold ( a_dust_threshold )
, add_to_fee ( an_add_to_fee )
, addr_for_dust ( an_addr_for_dust )
2014-03-20 11:46:11 +00:00
{
}
2014-04-02 16:00:17 +00:00
} ;
2014-03-20 11:46:11 +00:00
2017-09-11 13:38:37 +00:00
class hashchain
{
public :
hashchain ( ) : m_genesis ( crypto : : null_hash ) , m_offset ( 0 ) { }
size_t size ( ) const { return m_blockchain . size ( ) + m_offset ; }
size_t offset ( ) const { return m_offset ; }
const crypto : : hash & genesis ( ) const { return m_genesis ; }
void push_back ( const crypto : : hash & hash ) { if ( m_offset = = 0 & & m_blockchain . empty ( ) ) m_genesis = hash ; m_blockchain . push_back ( hash ) ; }
bool is_in_bounds ( size_t idx ) const { return idx > = m_offset & & idx < size ( ) ; }
const crypto : : hash & operator [ ] ( size_t idx ) const { return m_blockchain [ idx - m_offset ] ; }
crypto : : hash & operator [ ] ( size_t idx ) { return m_blockchain [ idx - m_offset ] ; }
void crop ( size_t height ) { m_blockchain . resize ( height - m_offset ) ; }
void clear ( ) { m_offset = 0 ; m_blockchain . clear ( ) ; }
bool empty ( ) const { return m_blockchain . empty ( ) & & m_offset = = 0 ; }
2017-10-02 23:51:53 +00:00
void trim ( size_t height ) { while ( height > m_offset & & m_blockchain . size ( ) > 1 ) { m_blockchain . pop_front ( ) ; + + m_offset ; } m_blockchain . shrink_to_fit ( ) ; }
2017-10-01 15:02:14 +00:00
void refill ( const crypto : : hash & hash ) { m_blockchain . push_back ( hash ) ; - - m_offset ; }
2017-09-11 13:38:37 +00:00
template < class t_archive >
inline void serialize ( t_archive & a , const unsigned int ver )
{
a & m_offset ;
a & m_genesis ;
a & m_blockchain ;
}
private :
size_t m_offset ;
crypto : : hash m_genesis ;
std : : deque < crypto : : hash > m_blockchain ;
} ;
2018-07-08 20:12:33 +00:00
class wallet_keys_unlocker ;
2014-03-03 22:07:58 +00:00
class wallet2
{
2017-01-02 01:43:20 +00:00
friend class : : Serialization_portability_wallet_Test ;
2018-11-20 13:40:51 +00:00
friend class : : wallet_accessor_test ;
2018-07-08 20:12:33 +00:00
friend class wallet_keys_unlocker ;
2018-11-11 19:07:25 +00:00
friend class wallet_device_callback ;
2014-03-03 22:07:58 +00:00
public :
2017-01-25 05:16:05 +00:00
static constexpr const std : : chrono : : seconds rpc_timeout = std : : chrono : : minutes ( 3 ) + std : : chrono : : seconds ( 30 ) ;
2015-11-22 19:03:10 +00:00
enum RefreshType {
RefreshFull ,
RefreshOptimizeCoinbase ,
RefreshNoCoinbase ,
2015-12-05 21:44:25 +00:00
RefreshDefault = RefreshOptimizeCoinbase ,
2015-11-22 19:03:10 +00:00
} ;
2018-09-02 09:59:01 +00:00
enum AskPasswordType {
AskPasswordNever = 0 ,
AskPasswordOnAction = 1 ,
AskPasswordToDecrypt = 2 ,
} ;
2019-03-30 19:21:30 +00:00
enum BackgroundMiningSetupType {
BackgroundMiningMaybe = 0 ,
BackgroundMiningYes = 1 ,
BackgroundMiningNo = 2 ,
} ;
2019-04-10 09:20:12 +00:00
enum ExportFormat {
Binary = 0 ,
Ascii ,
} ;
2017-01-25 05:16:05 +00:00
static const char * tr ( const char * str ) ;
2016-11-09 03:55:41 +00:00
static bool has_testnet_option ( const boost : : program_options : : variables_map & vm ) ;
2018-02-16 11:04:04 +00:00
static bool has_stagenet_option ( const boost : : program_options : : variables_map & vm ) ;
2018-08-23 22:50:31 +00:00
static std : : string device_name_option ( const boost : : program_options : : variables_map & vm ) ;
2018-11-11 23:07:25 +00:00
static std : : string device_derivation_path_option ( const boost : : program_options : : variables_map & vm ) ;
2016-11-09 03:55:41 +00:00
static void init_options ( boost : : program_options : : options_description & desc_params ) ;
//! Uses stdin and stdout. Returns a wallet2 if no errors.
2018-10-01 11:18:50 +00:00
static std : : pair < std : : unique_ptr < wallet2 > , password_container > make_from_json ( const boost : : program_options : : variables_map & vm , bool unattended , const std : : string & json_file , const std : : function < boost : : optional < password_container > ( const char * , bool ) > & password_prompter ) ;
2016-11-09 03:55:41 +00:00
//! Uses stdin and stdout. Returns a wallet2 and password for `wallet_file` if no errors.
static std : : pair < std : : unique_ptr < wallet2 > , password_container >
2018-09-02 09:59:01 +00:00
make_from_file ( const boost : : program_options : : variables_map & vm , bool unattended , const std : : string & wallet_file , const std : : function < boost : : optional < password_container > ( const char * , bool ) > & password_prompter ) ;
2016-11-09 03:55:41 +00:00
//! Uses stdin and stdout. Returns a wallet2 and password for wallet with no file if no errors.
2018-09-02 09:59:01 +00:00
static std : : pair < std : : unique_ptr < wallet2 > , password_container > make_new ( const boost : : program_options : : variables_map & vm , bool unattended , const std : : function < boost : : optional < password_container > ( const char * , bool ) > & password_prompter ) ;
2016-11-09 03:55:41 +00:00
2017-04-02 22:09:36 +00:00
//! Just parses variables.
2018-09-02 09:59:01 +00:00
static std : : unique_ptr < wallet2 > make_dummy ( const boost : : program_options : : variables_map & vm , bool unattended , const std : : function < boost : : optional < password_container > ( const char * , bool ) > & password_prompter ) ;
2017-04-02 22:09:36 +00:00
2018-07-06 06:42:08 +00:00
static bool verify_password ( const std : : string & keys_file_name , const epee : : wipeable_string & password , bool no_spend_key , hw : : device & hwdev , uint64_t kdf_rounds ) ;
2018-08-16 08:31:48 +00:00
static bool query_device ( hw : : device : : device_type & device_type , const std : : string & keys_file_name , const epee : : wipeable_string & password , uint64_t kdf_rounds = 1 ) ;
2017-08-01 22:41:05 +00:00
2020-04-15 17:22:46 +00:00
wallet2 ( cryptonote : : network_type nettype = cryptonote : : MAINNET , uint64_t kdf_rounds = 1 , bool unattended = false , std : : unique_ptr < epee : : net_utils : : http : : http_client_factory > http_client_factory = std : : unique_ptr < epee : : net_utils : : http : : http_simple_client_factory > ( new epee : : net_utils : : http : : http_simple_client_factory ( ) ) ) ;
2018-02-27 08:30:59 +00:00
~ wallet2 ( ) ;
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
struct multisig_info
{
2017-08-13 14:29:31 +00:00
struct LR
{
rct : : key m_L ;
rct : : key m_R ;
BEGIN_SERIALIZE_OBJECT ( )
FIELD ( m_L )
FIELD ( m_R )
END_SERIALIZE ( )
} ;
crypto : : public_key m_signer ;
std : : vector < LR > m_LR ;
std : : vector < crypto : : key_image > m_partial_key_images ; // one per key the participant has
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
BEGIN_SERIALIZE_OBJECT ( )
2017-08-13 14:29:31 +00:00
FIELD ( m_signer )
FIELD ( m_LR )
FIELD ( m_partial_key_images )
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
END_SERIALIZE ( )
} ;
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
2017-09-12 11:03:56 +00:00
struct tx_scan_info_t
{
cryptonote : : keypair in_ephemeral ;
crypto : : key_image ki ;
rct : : key mask ;
uint64_t amount ;
uint64_t money_transfered ;
bool error ;
2017-02-19 02:42:10 +00:00
boost : : optional < cryptonote : : subaddress_receive_info > received ;
2017-09-12 11:03:56 +00:00
2018-10-08 13:09:18 +00:00
tx_scan_info_t ( ) : amount ( 0 ) , money_transfered ( 0 ) , error ( true ) { }
2017-09-12 11:03:56 +00:00
} ;
2014-03-03 22:07:58 +00:00
struct transfer_details
{
uint64_t m_block_height ;
2016-08-06 18:19:25 +00:00
cryptonote : : transaction_prefix m_tx ;
crypto : : hash m_txid ;
2014-03-03 22:07:58 +00:00
size_t m_internal_output_index ;
uint64_t m_global_output_index ;
bool m_spent ;
2019-03-13 21:51:41 +00:00
bool m_frozen ;
2016-06-16 22:58:54 +00:00
uint64_t m_spent_height ;
2014-03-03 22:07:58 +00:00
crypto : : key_image m_key_image ; //TODO: key_image stored twice :(
2016-06-15 22:37:13 +00:00
rct : : key m_mask ;
uint64_t m_amount ;
2016-08-12 17:45:07 +00:00
bool m_rct ;
2016-11-07 18:50:05 +00:00
bool m_key_image_known ;
2018-12-25 13:59:44 +00:00
bool m_key_image_request ; // view wallets: we want to request it; cold wallets: it was requested
2016-12-09 18:21:21 +00:00
size_t m_pk_index ;
2017-02-19 02:42:10 +00:00
cryptonote : : subaddress_index m_subaddr_index ;
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 m_key_image_partial ;
2017-08-13 14:29:31 +00:00
std : : vector < rct : : key > m_multisig_k ;
std : : vector < multisig_info > m_multisig_info ; // one per other participant
2018-12-03 15:32:14 +00:00
std : : vector < std : : pair < uint64_t , crypto : : hash > > m_uses ;
2014-03-03 22:07:58 +00:00
2016-08-12 17:45:07 +00:00
bool is_rct ( ) const { return m_rct ; }
2016-06-15 22:37:13 +00:00
uint64_t amount ( ) const { return m_amount ; }
2016-11-07 18:50:05 +00:00
const crypto : : public_key & get_public_key ( ) const { return boost : : get < const cryptonote : : txout_to_key > ( m_tx . vout [ m_internal_output_index ] . target ) . key ; }
2016-11-15 21:22:04 +00:00
BEGIN_SERIALIZE_OBJECT ( )
FIELD ( m_block_height )
FIELD ( m_tx )
FIELD ( m_txid )
FIELD ( m_internal_output_index )
FIELD ( m_global_output_index )
FIELD ( m_spent )
2019-03-13 21:51:41 +00:00
FIELD ( m_frozen )
2016-11-15 21:22:04 +00:00
FIELD ( m_spent_height )
FIELD ( m_key_image )
FIELD ( m_mask )
FIELD ( m_amount )
FIELD ( m_rct )
FIELD ( m_key_image_known )
2018-12-25 13:59:44 +00:00
FIELD ( m_key_image_request )
2016-12-09 18:21:21 +00:00
FIELD ( m_pk_index )
2017-02-19 02:42:10 +00:00
FIELD ( m_subaddr_index )
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
FIELD ( m_key_image_partial )
FIELD ( m_multisig_k )
FIELD ( m_multisig_info )
2018-12-03 15:32:14 +00:00
FIELD ( m_uses )
2016-11-15 21:22:04 +00:00
END_SERIALIZE ( )
2014-03-03 22:07:58 +00:00
} ;
2020-01-09 09:01:56 +00:00
typedef std : : vector < uint64_t > amounts_container ;
2014-05-03 16:19:43 +00:00
struct payment_details
{
crypto : : hash m_tx_hash ;
uint64_t m_amount ;
2020-01-09 09:01:56 +00:00
amounts_container m_amounts ;
2018-01-14 04:37:57 +00:00
uint64_t m_fee ;
2014-05-03 16:19:43 +00:00
uint64_t m_block_height ;
uint64_t m_unlock_time ;
2016-04-19 20:18:43 +00:00
uint64_t m_timestamp ;
2018-07-19 16:49:15 +00:00
bool m_coinbase ;
2017-02-19 02:42:10 +00:00
cryptonote : : subaddress_index m_subaddr_index ;
2014-05-03 16:19:43 +00:00
} ;
2017-08-04 21:58:08 +00:00
struct address_tx : payment_details
{
bool m_mempool ;
bool m_incoming ;
} ;
2017-09-22 12:57:20 +00:00
struct pool_payment_details
{
payment_details m_pd ;
bool m_double_spend_seen ;
} ;
2014-04-02 16:00:17 +00:00
struct unconfirmed_transfer_details
2014-03-03 22:07:58 +00:00
{
2016-08-06 18:19:25 +00:00
cryptonote : : transaction_prefix m_tx ;
2016-06-15 22:37:13 +00:00
uint64_t m_amount_in ;
uint64_t m_amount_out ;
2014-04-02 16:00:17 +00:00
uint64_t m_change ;
2014-05-03 16:19:43 +00:00
time_t m_sent_time ;
2015-11-22 12:13:59 +00:00
std : : vector < cryptonote : : tx_destination_entry > m_dests ;
crypto : : hash m_payment_id ;
2016-01-29 19:44:48 +00:00
enum { pending , pending_not_in_pool , failed } m_state ;
2016-04-19 20:18:43 +00:00
uint64_t m_timestamp ;
2017-02-19 02:42:10 +00:00
uint32_t m_subaddr_account ; // subaddress account of your wallet to be used in this transfer
std : : set < uint32_t > m_subaddr_indices ; // set of address indices used as inputs in this transfer
2018-03-14 19:13:55 +00:00
std : : vector < std : : pair < crypto : : key_image , std : : vector < uint64_t > > > m_rings ; // relative
2014-03-03 22:07:58 +00:00
} ;
2015-11-15 21:59:40 +00:00
struct confirmed_transfer_details
{
uint64_t m_amount_in ;
uint64_t m_amount_out ;
uint64_t m_change ;
uint64_t m_block_height ;
2015-11-22 12:13:59 +00:00
std : : vector < cryptonote : : tx_destination_entry > m_dests ;
crypto : : hash m_payment_id ;
2016-04-19 20:18:43 +00:00
uint64_t m_timestamp ;
2017-07-25 15:28:48 +00:00
uint64_t m_unlock_time ;
2017-02-19 02:42:10 +00:00
uint32_t m_subaddr_account ; // subaddress account of your wallet to be used in this transfer
std : : set < uint32_t > m_subaddr_indices ; // set of address indices used as inputs in this transfer
2018-03-14 19:13:55 +00:00
std : : vector < std : : pair < crypto : : key_image , std : : vector < uint64_t > > > m_rings ; // relative
2015-11-22 12:13:59 +00:00
2017-02-19 02:42:10 +00:00
confirmed_transfer_details ( ) : m_amount_in ( 0 ) , m_amount_out ( 0 ) , m_change ( ( uint64_t ) - 1 ) , m_block_height ( 0 ) , m_payment_id ( crypto : : null_hash ) , m_timestamp ( 0 ) , m_unlock_time ( 0 ) , m_subaddr_account ( ( uint32_t ) - 1 ) { }
2015-11-15 21:59:40 +00:00
confirmed_transfer_details ( const unconfirmed_transfer_details & utd , uint64_t height ) :
2018-03-14 19:13:55 +00:00
m_amount_in ( utd . m_amount_in ) , m_amount_out ( utd . m_amount_out ) , m_change ( utd . m_change ) , m_block_height ( height ) , m_dests ( utd . m_dests ) , m_payment_id ( utd . m_payment_id ) , m_timestamp ( utd . m_timestamp ) , m_unlock_time ( utd . m_tx . unlock_time ) , m_subaddr_account ( utd . m_subaddr_account ) , m_subaddr_indices ( utd . m_subaddr_indices ) , m_rings ( utd . m_rings ) { }
2015-11-15 21:59:40 +00:00
} ;
2016-09-26 22:11:10 +00:00
struct tx_construction_data
{
std : : vector < cryptonote : : tx_source_entry > sources ;
cryptonote : : tx_destination_entry change_dts ;
2016-11-23 20:10:34 +00:00
std : : vector < cryptonote : : tx_destination_entry > splitted_dsts ; // split, includes change
2017-10-22 08:54:07 +00:00
std : : vector < size_t > selected_transfers ;
2016-09-26 22:11:10 +00:00
std : : vector < uint8_t > extra ;
uint64_t unlock_time ;
bool use_rct ;
2019-03-13 11:32:44 +00:00
rct : : RCTConfig rct_config ;
2016-11-23 20:10:34 +00:00
std : : vector < cryptonote : : tx_destination_entry > dests ; // original setup, does not include change
2017-02-19 02:42:10 +00:00
uint32_t subaddr_account ; // subaddress account of your wallet to be used in this transfer
std : : set < uint32_t > subaddr_indices ; // set of address indices used as inputs in this transfer
2017-11-10 19:39:09 +00:00
BEGIN_SERIALIZE_OBJECT ( )
FIELD ( sources )
FIELD ( change_dts )
FIELD ( splitted_dsts )
FIELD ( selected_transfers )
FIELD ( extra )
FIELD ( unlock_time )
FIELD ( use_rct )
2019-03-13 11:32:44 +00:00
FIELD ( rct_config )
2017-11-10 19:39:09 +00:00
FIELD ( dests )
FIELD ( subaddr_account )
FIELD ( subaddr_indices )
END_SERIALIZE ( )
2016-09-26 22:11:10 +00:00
} ;
2014-04-02 16:00:17 +00:00
typedef std : : vector < transfer_details > transfer_container ;
2014-05-03 16:19:43 +00:00
typedef std : : unordered_multimap < crypto : : hash , payment_details > payment_container ;
2014-04-02 16:00:17 +00:00
2017-08-13 14:29:31 +00:00
struct multisig_sig
{
rct : : rctSig sigs ;
2018-11-12 17:46:00 +00:00
std : : unordered_set < crypto : : public_key > ignore ;
2017-08-13 14:29:31 +00:00
std : : unordered_set < rct : : key > used_L ;
std : : unordered_set < crypto : : public_key > signing_keys ;
rct : : multisig_out msout ;
} ;
2016-11-23 20:10:34 +00:00
// The convention for destinations is:
// dests does not include change
// splitted_dsts (in construction_data) does
2014-06-16 00:36:44 +00:00
struct pending_tx
{
cryptonote : : transaction tx ;
uint64_t dust , fee ;
2016-04-18 08:20:31 +00:00
bool dust_added_to_fee ;
2014-06-16 00:36:44 +00:00
cryptonote : : tx_destination_entry change_dts ;
2017-10-22 08:54:07 +00:00
std : : vector < size_t > selected_transfers ;
2014-06-16 00:36:44 +00:00
std : : string key_images ;
2015-08-19 19:59:44 +00:00
crypto : : secret_key tx_key ;
2017-02-19 02:42:10 +00:00
std : : vector < crypto : : secret_key > additional_tx_keys ;
2015-11-22 12:13:59 +00:00
std : : vector < cryptonote : : tx_destination_entry > dests ;
2017-08-13 14:29:31 +00:00
std : : vector < multisig_sig > multisig_sigs ;
2016-09-26 22:11:10 +00:00
tx_construction_data construction_data ;
2017-11-10 19:39:09 +00:00
BEGIN_SERIALIZE_OBJECT ( )
FIELD ( tx )
FIELD ( dust )
FIELD ( fee )
FIELD ( dust_added_to_fee )
FIELD ( change_dts )
FIELD ( selected_transfers )
FIELD ( key_images )
FIELD ( tx_key )
FIELD ( additional_tx_keys )
FIELD ( dests )
FIELD ( construction_data )
2017-08-13 14:29:31 +00:00
FIELD ( multisig_sigs )
2017-11-10 19:39:09 +00:00
END_SERIALIZE ( )
2016-09-26 22:11:10 +00:00
} ;
2017-01-08 12:17:09 +00:00
// The term "Unsigned tx" is not really a tx since it's not signed yet.
// It doesnt have tx hash, key and the integrated address is not separated into addr + payment id.
2016-09-26 22:11:10 +00:00
struct unsigned_tx_set
{
std : : vector < tx_construction_data > txes ;
2018-10-24 18:24:11 +00:00
std : : pair < size_t , wallet2 : : transfer_container > transfers ;
2016-09-26 22:11:10 +00:00
} ;
struct signed_tx_set
{
std : : vector < pending_tx > ptx ;
2016-11-15 21:22:04 +00:00
std : : vector < crypto : : key_image > key_images ;
2018-12-25 13:59:44 +00:00
std : : unordered_map < crypto : : public_key , crypto : : key_image > tx_key_images ;
2014-06-16 00:36:44 +00:00
} ;
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
struct multisig_tx_set
{
std : : vector < pending_tx > m_ptx ;
2017-08-13 14:29:31 +00:00
std : : unordered_set < crypto : : public_key > m_signers ;
2017-11-27 20:09:16 +00:00
BEGIN_SERIALIZE_OBJECT ( )
FIELD ( m_ptx )
FIELD ( m_signers )
END_SERIALIZE ( )
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
} ;
2014-03-03 22:07:58 +00:00
struct keys_file_data
{
2017-12-07 13:27:11 +00:00
crypto : : chacha_iv iv ;
2014-03-03 22:07:58 +00:00
std : : string account_data ;
BEGIN_SERIALIZE_OBJECT ( )
FIELD ( iv )
FIELD ( account_data )
END_SERIALIZE ( )
} ;
2015-08-22 13:21:32 +00:00
struct cache_file_data
{
2017-12-07 13:27:11 +00:00
crypto : : chacha_iv iv ;
2015-08-22 13:21:32 +00:00
std : : string cache_data ;
BEGIN_SERIALIZE_OBJECT ( )
FIELD ( iv )
FIELD ( cache_data )
END_SERIALIZE ( )
} ;
2016-12-11 23:42:46 +00:00
// GUI Address book
struct address_book_row
{
cryptonote : : account_public_address m_address ;
2019-11-19 16:30:19 +00:00
crypto : : hash8 m_payment_id ;
2016-12-12 20:39:29 +00:00
std : : string m_description ;
2017-02-19 02:42:10 +00:00
bool m_is_subaddress ;
2019-11-19 16:30:19 +00:00
bool m_has_payment_id ;
2016-12-11 23:42:46 +00:00
} ;
2015-08-22 13:21:32 +00:00
2017-12-28 13:50:10 +00:00
struct reserve_proof_entry
{
crypto : : hash txid ;
uint64_t index_in_tx ;
crypto : : public_key shared_secret ;
crypto : : key_image key_image ;
crypto : : signature shared_secret_sig ;
crypto : : signature key_image_sig ;
} ;
2017-01-07 16:06:07 +00:00
typedef std : : tuple < uint64_t , crypto : : public_key , rct : : key > get_outs_entry ;
2018-04-17 17:16:19 +00:00
struct parsed_block
{
crypto : : hash hash ;
cryptonote : : block block ;
2018-04-21 11:33:02 +00:00
std : : vector < cryptonote : : transaction > txes ;
2018-04-17 17:16:19 +00:00
cryptonote : : COMMAND_RPC_GET_BLOCKS_FAST : : block_output_indices o_indices ;
bool error ;
} ;
2018-04-21 11:33:02 +00:00
struct is_out_data
{
crypto : : public_key pkey ;
crypto : : key_derivation derivation ;
std : : vector < boost : : optional < cryptonote : : subaddress_receive_info > > received ;
} ;
struct tx_cache_data
{
std : : vector < cryptonote : : tx_extra_field > tx_extra_fields ;
std : : vector < is_out_data > primary ;
std : : vector < is_out_data > additional ;
2018-12-16 10:40:09 +00:00
bool empty ( ) const { return tx_extra_fields . empty ( ) & & primary . empty ( ) & & additional . empty ( ) ; }
2018-04-21 11:33:02 +00:00
} ;
2017-11-09 10:59:41 +00:00
/*!
* \ brief Generates a wallet or restores one .
2018-02-25 16:59:52 +00:00
* \ param wallet_ Name of wallet file
* \ param password Password of wallet file
* \ param multisig_data The multisig restore info and keys
* \ param create_address_file Whether to create an address file
2017-11-09 10:59:41 +00:00
*/
void generate ( const std : : string & wallet_ , const epee : : wipeable_string & password ,
2018-07-06 23:03:15 +00:00
const epee : : wipeable_string & multisig_data , bool create_address_file = false ) ;
2017-11-09 10:59:41 +00:00
2014-10-18 19:38:21 +00:00
/*!
* \ brief Generates a wallet or restores one .
2018-02-25 16:59:52 +00:00
* \ param wallet_ Name of wallet file
* \ param password Password of wallet file
* \ param recovery_param If it is a restore , the recovery key
* \ param recover Whether it is a restore
* \ param two_random Whether it is a non - deterministic wallet
* \ param create_address_file Whether to create an address file
* \ return The secret key of the generated wallet
2014-10-18 19:38:21 +00:00
*/
2017-11-25 14:50:15 +00:00
crypto : : secret_key generate ( const std : : string & wallet , const epee : : wipeable_string & password ,
2014-10-18 19:30:18 +00:00
const crypto : : secret_key & recovery_param = crypto : : secret_key ( ) , bool recover = false ,
2018-02-25 16:59:52 +00:00
bool two_random = false , bool create_address_file = false ) ;
2016-02-22 22:10:55 +00:00
/*!
* \ brief Creates a wallet from a public address and a spend / view secret key pair .
2018-03-14 15:41:24 +00:00
* \ param wallet_ Name of wallet file
* \ param password Password of wallet file
* \ param account_public_address The account ' s public address
* \ param spendkey spend secret key
* \ param viewkey view secret key
* \ param create_address_file Whether to create an address file
2016-02-22 22:10:55 +00:00
*/
2017-11-25 14:50:15 +00:00
void generate ( const std : : string & wallet , const epee : : wipeable_string & password ,
2016-02-22 22:10:55 +00:00
const cryptonote : : account_public_address & account_public_address ,
2018-02-25 16:59:52 +00:00
const crypto : : secret_key & spendkey , const crypto : : secret_key & viewkey , bool create_address_file = false ) ;
2015-06-20 11:31:53 +00:00
/*!
* \ brief Creates a watch only wallet from a public address and a view secret key .
2018-03-14 15:41:24 +00:00
* \ param wallet_ Name of wallet file
* \ param password Password of wallet file
* \ param account_public_address The account ' s public address
* \ param viewkey view secret key
* \ param create_address_file Whether to create an address file
2015-06-20 11:31:53 +00:00
*/
2017-11-25 14:50:15 +00:00
void generate ( const std : : string & wallet , const epee : : wipeable_string & password ,
2015-06-20 11:31:53 +00:00
const cryptonote : : account_public_address & account_public_address ,
2018-02-25 16:59:52 +00:00
const crypto : : secret_key & viewkey = crypto : : secret_key ( ) , bool create_address_file = false ) ;
2018-02-20 16:01:27 +00:00
/*!
* \ brief Restore a wallet hold by an HW .
* \ param wallet_ Name of wallet file
* \ param password Password of wallet file
* \ param device_name name of HW to use
2018-09-03 11:13:23 +00:00
* \ param create_address_file Whether to create an address file
2018-02-20 16:01:27 +00:00
*/
2018-09-29 20:16:40 +00:00
void restore ( const std : : string & wallet_ , const epee : : wipeable_string & password , const std : : string & device_name , bool create_address_file = false ) ;
2018-02-20 16:01:27 +00:00
2017-05-28 11:18:51 +00:00
/*!
* \ brief Creates a multisig wallet
2017-08-13 14:29:31 +00:00
* \ return empty if done , non empty if we need to send another string
* to other participants
2017-05-28 11:18:51 +00:00
*/
2017-11-18 11:24:38 +00:00
std : : string make_multisig ( const epee : : wipeable_string & password ,
const std : : vector < std : : string > & info ,
uint32_t threshold ) ;
/*!
* \ brief Creates a multisig wallet
* \ return empty if done , non empty if we need to send another string
* to other participants
*/
2017-08-13 14:29:31 +00:00
std : : string make_multisig ( const epee : : wipeable_string & password ,
2017-05-28 11:18:51 +00:00
const std : : vector < crypto : : secret_key > & view_keys ,
const std : : vector < crypto : : public_key > & spend_keys ,
uint32_t threshold ) ;
2018-07-12 09:55:52 +00:00
std : : string exchange_multisig_keys ( const epee : : wipeable_string & password ,
const std : : vector < std : : string > & info ) ;
/*!
* \ brief Any but first round of keys exchange
*/
std : : string exchange_multisig_keys ( const epee : : wipeable_string & password ,
std : : unordered_set < crypto : : public_key > pkeys ,
std : : vector < crypto : : public_key > signers ) ;
2017-09-26 22:16:25 +00:00
/*!
* \ brief Finalizes creation of a multisig wallet
*/
bool finalize_multisig ( const epee : : wipeable_string & password , const std : : vector < std : : string > & info ) ;
2017-08-13 14:29:31 +00:00
/*!
* \ brief Finalizes creation of a multisig wallet
*/
2018-11-23 13:25:15 +00:00
bool finalize_multisig ( const epee : : wipeable_string & password , const std : : unordered_set < crypto : : public_key > & pkeys , std : : vector < crypto : : public_key > signers ) ;
2017-05-28 11:18:51 +00:00
/*!
* Get a packaged multisig information string
*/
std : : string get_multisig_info ( ) const ;
/*!
* Verifies and extracts keys from a packaged multisig information string
*/
static bool verify_multisig_info ( const std : : string & data , crypto : : secret_key & skey , crypto : : public_key & pkey ) ;
2017-08-13 14:29:31 +00:00
/*!
* Verifies and extracts keys from a packaged multisig information string
*/
static bool verify_extra_multisig_info ( const std : : string & data , std : : unordered_set < crypto : : public_key > & pkeys , crypto : : public_key & signer ) ;
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
/*!
* Export multisig info
* This will generate and remember new k values
*/
2017-11-13 16:24:42 +00:00
cryptonote : : blobdata export_multisig ( ) ;
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
/*!
* Import a set of multisig info from multisig partners
* \ return the number of inputs which were imported
*/
2017-11-13 16:24:42 +00:00
size_t import_multisig ( std : : vector < cryptonote : : blobdata > info ) ;
2014-10-18 19:38:21 +00:00
/*!
* \ brief Rewrites to the wallet file for wallet upgrade ( doesn ' t generate key , assumes it ' s already there )
* \ param wallet_name Name of wallet file ( should exist )
* \ param password Password for wallet file
*/
2017-11-25 14:50:15 +00:00
void rewrite ( const std : : string & wallet_name , const epee : : wipeable_string & password ) ;
2018-03-07 13:54:18 +00:00
void write_watch_only_wallet ( const std : : string & wallet_name , const epee : : wipeable_string & password , std : : string & new_keys_filename ) ;
2020-04-15 17:22:46 +00:00
void load ( const std : : string & wallet , const epee : : wipeable_string & password , const std : : string & keys_buf = " " , const std : : string & cache_buf = " " ) ;
2014-04-02 16:00:17 +00:00
void store ( ) ;
2016-03-15 20:11:38 +00:00
/*!
2018-03-14 15:41:24 +00:00
* \ brief store_to Stores wallet to another file ( s ) , deleting old ones
* \ param path Path to the wallet file ( keys and address filenames will be generated based on this filename )
* \ param password Password to protect new wallet ( TODO : probably better save the password in the wallet object ? )
2016-03-15 20:11:38 +00:00
*/
2017-11-25 14:50:15 +00:00
void store_to ( const std : : string & path , const epee : : wipeable_string & password ) ;
2020-04-15 17:22:46 +00:00
/*!
* \ brief get_keys_file_data Get wallet keys data which can be stored to a wallet file .
* \ param password Password of the encrypted wallet buffer ( TODO : probably better save the password in the wallet object ? )
* \ param watch_only true to include only view key , false to include both spend and view keys
* \ return Encrypted wallet keys data which can be stored to a wallet file
*/
boost : : optional < wallet2 : : keys_file_data > get_keys_file_data ( const epee : : wipeable_string & password , bool watch_only ) ;
/*!
* \ brief get_cache_file_data Get wallet cache data which can be stored to a wallet file .
* \ param password Password to protect the wallet cache data ( TODO : probably better save the password in the wallet object ? )
* \ return Encrypted wallet cache data which can be stored to a wallet file
*/
boost : : optional < wallet2 : : cache_file_data > get_cache_file_data ( const epee : : wipeable_string & password ) ;
2014-12-06 14:55:56 +00:00
2016-11-26 14:19:57 +00:00
std : : string path ( ) const ;
2014-12-06 14:55:56 +00:00
/*!
* \ brief verifies given password is correct for default wallet keys file
*/
2018-07-03 02:33:11 +00:00
bool verify_password ( const epee : : wipeable_string & password ) ;
2014-03-03 22:07:58 +00:00
cryptonote : : account_base & get_account ( ) { return m_account ; }
2015-05-27 18:00:57 +00:00
const cryptonote : : account_base & get_account ( ) const { return m_account ; }
2014-03-03 22:07:58 +00:00
2018-07-08 20:12:33 +00:00
void encrypt_keys ( const crypto : : chacha_key & key ) ;
void encrypt_keys ( const epee : : wipeable_string & password ) ;
void decrypt_keys ( const crypto : : chacha_key & key ) ;
void decrypt_keys ( const epee : : wipeable_string & password ) ;
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
void set_refresh_from_block_height ( uint64_t height ) { m_refresh_from_block_height = height ; }
2017-01-10 21:34:15 +00:00
uint64_t get_refresh_from_block_height ( ) const { return m_refresh_from_block_height ; }
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
2018-01-23 14:42:11 +00:00
void explicit_refresh_from_block_height ( bool expl ) { m_explicit_refresh_from_block_height = expl ; }
bool explicit_refresh_from_block_height ( ) const { return m_explicit_refresh_from_block_height ; }
2014-03-03 22:07:58 +00:00
bool deinit ( ) ;
2018-08-25 05:22:26 +00:00
bool init ( std : : string daemon_address = " http://localhost:8080 " ,
2019-01-23 21:37:43 +00:00
boost : : optional < epee : : net_utils : : http : : login > daemon_login = boost : : none ,
boost : : asio : : ip : : tcp : : endpoint proxy = { } ,
uint64_t upper_transaction_weight_limit = 0 ,
epee: add SSL support
RPC connections now have optional tranparent SSL.
An optional private key and certificate file can be passed,
using the --{rpc,daemon}-ssl-private-key and
--{rpc,daemon}-ssl-certificate options. Those have as
argument a path to a PEM format private private key and
certificate, respectively.
If not given, a temporary self signed certificate will be used.
SSL can be enabled or disabled using --{rpc}-ssl, which
accepts autodetect (default), disabled or enabled.
Access can be restricted to particular certificates using the
--rpc-ssl-allowed-certificates, which takes a list of
paths to PEM encoded certificates. This can allow a wallet to
connect to only the daemon they think they're connected to,
by forcing SSL and listing the paths to the known good
certificates.
To generate long term certificates:
openssl genrsa -out /tmp/KEY 4096
openssl req -new -key /tmp/KEY -out /tmp/REQ
openssl x509 -req -days 999999 -sha256 -in /tmp/REQ -signkey /tmp/KEY -out /tmp/CERT
/tmp/KEY is the private key, and /tmp/CERT is the certificate,
both in PEM format. /tmp/REQ can be removed. Adjust the last
command to set expiration date, etc, as needed. It doesn't
make a whole lot of sense for monero anyway, since most servers
will run with one time temporary self signed certificates anyway.
SSL support is transparent, so all communication is done on the
existing ports, with SSL autodetection. This means you can start
using an SSL daemon now, but you should not enforce SSL yet or
nothing will talk to you.
2018-06-14 22:44:48 +00:00
bool trusted_daemon = true ,
2019-03-15 04:03:32 +00:00
epee : : net_utils : : ssl_options_t ssl_options = epee : : net_utils : : ssl_support_t : : e_ssl_support_autodetect ) ;
2019-03-18 11:45:31 +00:00
bool set_daemon ( std : : string daemon_address = " http://localhost:8080 " ,
boost : : optional < epee : : net_utils : : http : : login > daemon_login = boost : : none , bool trusted_daemon = true ,
2019-03-15 04:03:32 +00:00
epee : : net_utils : : ssl_options_t ssl_options = epee : : net_utils : : ssl_support_t : : e_ssl_support_autodetect ) ;
2014-03-03 22:07:58 +00:00
2018-10-28 13:46:58 +00:00
void stop ( ) { m_run . store ( false , std : : memory_order_relaxed ) ; m_message_store . stop ( ) ; }
2014-03-20 11:46:11 +00:00
2014-04-02 16:00:17 +00:00
i_wallet2_callback * callback ( ) const { return m_callback ; }
void callback ( i_wallet2_callback * callback ) { m_callback = callback ; }
2018-08-10 12:15:40 +00:00
bool is_trusted_daemon ( ) const { return m_trusted_daemon ; }
void set_trusted_daemon ( bool trusted ) { m_trusted_daemon = trusted ; }
2014-12-06 09:59:13 +00:00
/*!
* \ brief Checks if deterministic wallet
*/
2015-05-27 18:00:57 +00:00
bool is_deterministic ( ) const ;
2018-07-06 23:03:15 +00:00
bool get_seed ( epee : : wipeable_string & electrum_words , const epee : : wipeable_string & passphrase = epee : : wipeable_string ( ) ) const ;
2017-08-04 21:58:08 +00:00
/*!
* \ brief Checks if light wallet . A light wallet sends view key to a server where the blockchain is scanned .
*/
bool light_wallet ( ) const { return m_light_wallet ; }
void set_light_wallet ( bool light_wallet ) { m_light_wallet = light_wallet ; }
uint64_t get_light_wallet_scanned_block_height ( ) const { return m_light_wallet_scanned_block_height ; }
uint64_t get_light_wallet_blockchain_height ( ) const { return m_light_wallet_blockchain_height ; }
2014-11-06 22:36:36 +00:00
/*!
* \ brief Gets the seed language
*/
2015-05-27 18:00:57 +00:00
const std : : string & get_seed_language ( ) const ;
2014-10-02 12:45:18 +00:00
/*!
* \ brief Sets the seed language
*/
2014-10-17 20:51:37 +00:00
void set_seed_language ( const std : : string & language ) ;
2017-02-19 02:42:10 +00:00
// Subaddress scheme
cryptonote : : account_public_address get_subaddress ( const cryptonote : : subaddress_index & index ) const ;
cryptonote : : account_public_address get_address ( ) const { return get_subaddress ( { 0 , 0 } ) ; }
2018-07-23 14:45:11 +00:00
boost : : optional < cryptonote : : subaddress_index > get_subaddress_index ( const cryptonote : : account_public_address & address ) const ;
2017-02-19 02:42:10 +00:00
crypto : : public_key get_subaddress_spend_public_key ( const cryptonote : : subaddress_index & index ) const ;
2018-02-10 10:38:33 +00:00
std : : vector < crypto : : public_key > get_subaddress_spend_public_keys ( uint32_t account , uint32_t begin , uint32_t end ) const ;
2017-02-19 02:42:10 +00:00
std : : string get_subaddress_as_str ( const cryptonote : : subaddress_index & index ) const ;
std : : string get_address_as_str ( ) const { return get_subaddress_as_str ( { 0 , 0 } ) ; }
std : : string get_integrated_address_as_str ( const crypto : : hash8 & payment_id ) const ;
void add_subaddress_account ( const std : : string & label ) ;
size_t get_num_subaddress_accounts ( ) const { return m_subaddress_labels . size ( ) ; }
size_t get_num_subaddresses ( uint32_t index_major ) const { return index_major < m_subaddress_labels . size ( ) ? m_subaddress_labels [ index_major ] . size ( ) : 0 ; }
void add_subaddress ( uint32_t index_major , const std : : string & label ) ; // throws when index is out of bound
void expand_subaddresses ( const cryptonote : : subaddress_index & index ) ;
2020-03-19 17:27:19 +00:00
void create_one_off_subaddress ( const cryptonote : : subaddress_index & index ) ;
2017-10-22 14:21:44 +00:00
std : : string get_subaddress_label ( const cryptonote : : subaddress_index & index ) const ;
void set_subaddress_label ( const cryptonote : : subaddress_index & index , const std : : string & label ) ;
2017-10-21 17:31:30 +00:00
void set_subaddress_lookahead ( size_t major , size_t minor ) ;
2018-03-16 04:11:45 +00:00
std : : pair < size_t , size_t > get_subaddress_lookahead ( ) const { return { m_subaddress_lookahead_major , m_subaddress_lookahead_minor } ; }
2014-10-17 20:51:37 +00:00
/*!
* \ brief Tells if the wallet file is deprecated .
*/
bool is_deprecated ( ) const ;
2018-06-13 11:16:07 +00:00
void refresh ( bool trusted_daemon ) ;
void refresh ( bool trusted_daemon , uint64_t start_height , uint64_t & blocks_fetched ) ;
2019-01-09 11:20:14 +00:00
void refresh ( bool trusted_daemon , uint64_t start_height , uint64_t & blocks_fetched , bool & received_money , bool check_pool = true ) ;
2018-06-13 11:16:07 +00:00
bool refresh ( bool trusted_daemon , uint64_t & blocks_fetched , bool & received_money , bool & ok ) ;
2014-04-02 16:00:17 +00:00
2015-11-22 19:03:10 +00:00
void set_refresh_type ( RefreshType refresh_type ) { m_refresh_type = refresh_type ; }
2015-12-05 21:44:25 +00:00
RefreshType get_refresh_type ( ) const { return m_refresh_type ; }
2015-11-22 19:03:10 +00:00
2018-02-16 11:04:04 +00:00
cryptonote : : network_type nettype ( ) const { return m_nettype ; }
2015-05-31 14:34:55 +00:00
bool watch_only ( ) const { return m_watch_only ; }
2017-10-01 13:06:54 +00:00
bool multisig ( bool * ready = NULL , uint32_t * threshold = NULL , uint32_t * total = NULL ) const ;
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 has_multisig_partial_key_images ( ) const ;
2018-04-19 02:17:45 +00:00
bool has_unknown_key_images ( ) const ;
2018-07-06 23:03:15 +00:00
bool get_multisig_seed ( epee : : wipeable_string & seed , const epee : : wipeable_string & passphrase = std : : string ( ) , bool raw = true ) const ;
2018-08-16 08:31:48 +00:00
bool key_on_device ( ) const { return get_device_type ( ) ! = hw : : device : : device_type : : SOFTWARE ; }
hw : : device : : device_type get_device_type ( ) const { return m_key_device_type ; }
2018-08-23 22:50:31 +00:00
bool reconnect_device ( ) ;
2014-09-09 14:58:53 +00:00
2017-02-19 02:42:10 +00:00
// locked & unlocked balance of given or current subaddress account
2019-05-10 17:20:20 +00:00
uint64_t balance ( uint32_t subaddr_index_major , bool strict ) const ;
2020-04-19 15:57:11 +00:00
uint64_t unlocked_balance ( uint32_t subaddr_index_major , bool strict , uint64_t * blocks_to_unlock = NULL , uint64_t * time_to_unlock = NULL ) const ;
2017-02-19 02:42:10 +00:00
// locked & unlocked balance per subaddress of given or current subaddress account
2019-05-10 17:20:20 +00:00
std : : map < uint32_t , uint64_t > balance_per_subaddress ( uint32_t subaddr_index_major , bool strict ) const ;
2020-04-19 15:57:11 +00:00
std : : map < uint32_t , std : : pair < uint64_t , std : : pair < uint64_t , uint64_t > > > unlocked_balance_per_subaddress ( uint32_t subaddr_index_major , bool strict ) const ;
2017-02-19 02:42:10 +00:00
// all locked & unlocked balances of all subaddress accounts
2019-05-10 17:20:20 +00:00
uint64_t balance_all ( bool strict ) const ;
2020-04-19 15:57:11 +00:00
uint64_t unlocked_balance_all ( bool strict , uint64_t * blocks_to_unlock = NULL , uint64_t * time_to_unlock = NULL ) const ;
2014-03-20 11:46:11 +00:00
template < typename T >
2017-10-22 08:54:07 +00:00
void transfer_selected ( const std : : vector < cryptonote : : tx_destination_entry > & dsts , const std : : vector < size_t > & selected_transfers , size_t fake_outputs_count ,
2017-01-07 16:06:07 +00:00
std : : vector < std : : vector < tools : : wallet2 : : get_outs_entry > > & outs ,
2015-07-19 22:47:13 +00:00
uint64_t unlock_time , uint64_t fee , const std : : vector < uint8_t > & extra , T destination_split_strategy , const tx_dust_policy & dust_policy , cryptonote : : transaction & tx , pending_tx & ptx ) ;
2017-10-22 08:54:07 +00:00
void transfer_selected_rct ( std : : vector < cryptonote : : tx_destination_entry > dsts , const std : : vector < size_t > & selected_transfers , size_t fake_outputs_count ,
2017-01-07 16:06:07 +00:00
std : : vector < std : : vector < tools : : wallet2 : : get_outs_entry > > & outs ,
2019-01-06 13:47:16 +00:00
uint64_t unlock_time , uint64_t fee , const std : : vector < uint8_t > & extra , cryptonote : : transaction & tx , pending_tx & ptx , const rct : : RCTConfig & rct_config ) ;
2015-07-19 22:47:13 +00:00
2014-06-17 22:15:21 +00:00
void commit_tx ( pending_tx & ptx_vector ) ;
void commit_tx ( std : : vector < pending_tx > & ptx_vector ) ;
2018-01-17 01:58:34 +00:00
bool save_tx ( const std : : vector < pending_tx > & ptx_vector , const std : : string & filename ) const ;
wallet-rpc: watch-only and cold wallet features added
- unsigned_txset, signed_txset in transfer / submit_transfer / sign_transfer
- export_outputs, import_outputs
Squashed commits:
[f4d9f3d4] wallet-rpc: do_not_relay removed from submit_transfer
[5b16a86f] wallet-rpc: review-fix - method signature changes, renaming
[b7fbb10a] wallet-rpc: naming fixes (unsigned vs signed), consts renamed
[8c7d2727] wallet-rpc: sign_transfer added
[481d024a] wallet2: sign_tx splitted to work with strings and structs, more granular
[2a474db9] wallet-rpc: wallet2::load_unsigned_tx split to load from str, file
[b1e3a018] wallet-rpc: review fix, load_tx_from_str variable rename
[1f6373be] wallet-rpc: review fix: save_tx_to_{str,file}
[2a08eafc] wallet-rpc: review comments fixes
- redundant this removed from wallet2.cpp
- load_tx_from_str, load_tx_from_file
[43498052] wallet-rpc: submit_transfer added
[9c45d1ad] wallet-rpc: watch_only check, return unsigned_txset
[62831396] wallet2: added string variants to load_tx, save_tx
- analogously to save_multisig_tx
- required for monero-wallet-rpc to support watch-only wallet
2018-05-07 21:23:47 +00:00
std : : string dump_tx_to_str ( const std : : vector < pending_tx > & ptx_vector ) const ;
2017-11-27 20:09:04 +00:00
std : : string save_multisig_tx ( multisig_tx_set txs ) ;
bool save_multisig_tx ( const multisig_tx_set & txs , const std : : string & filename ) ;
std : : string save_multisig_tx ( const std : : vector < pending_tx > & ptx_vector ) ;
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 save_multisig_tx ( const std : : vector < pending_tx > & ptx_vector , const std : : string & filename ) ;
2018-03-21 15:57:15 +00:00
multisig_tx_set make_multisig_tx_set ( const std : : vector < pending_tx > & ptx_vector ) const ;
2017-01-08 12:17:09 +00:00
// load unsigned tx from file and sign it. Takes confirmation callback as argument. Used by the cli wallet
2017-09-30 04:28:17 +00:00
bool sign_tx ( const std : : string & unsigned_filename , const std : : string & signed_filename , std : : vector < wallet2 : : pending_tx > & ptx , std : : function < bool ( const unsigned_tx_set & ) > accept_func = NULL , bool export_raw = false ) ;
2017-01-08 12:17:09 +00:00
// sign unsigned tx. Takes unsigned_tx_set as argument. Used by GUI
2017-09-30 04:28:17 +00:00
bool sign_tx ( unsigned_tx_set & exported_txs , const std : : string & signed_filename , std : : vector < wallet2 : : pending_tx > & ptx , bool export_raw = false ) ;
wallet-rpc: watch-only and cold wallet features added
- unsigned_txset, signed_txset in transfer / submit_transfer / sign_transfer
- export_outputs, import_outputs
Squashed commits:
[f4d9f3d4] wallet-rpc: do_not_relay removed from submit_transfer
[5b16a86f] wallet-rpc: review-fix - method signature changes, renaming
[b7fbb10a] wallet-rpc: naming fixes (unsigned vs signed), consts renamed
[8c7d2727] wallet-rpc: sign_transfer added
[481d024a] wallet2: sign_tx splitted to work with strings and structs, more granular
[2a474db9] wallet-rpc: wallet2::load_unsigned_tx split to load from str, file
[b1e3a018] wallet-rpc: review fix, load_tx_from_str variable rename
[1f6373be] wallet-rpc: review fix: save_tx_to_{str,file}
[2a08eafc] wallet-rpc: review comments fixes
- redundant this removed from wallet2.cpp
- load_tx_from_str, load_tx_from_file
[43498052] wallet-rpc: submit_transfer added
[9c45d1ad] wallet-rpc: watch_only check, return unsigned_txset
[62831396] wallet2: added string variants to load_tx, save_tx
- analogously to save_multisig_tx
- required for monero-wallet-rpc to support watch-only wallet
2018-05-07 21:23:47 +00:00
bool sign_tx ( unsigned_tx_set & exported_txs , std : : vector < wallet2 : : pending_tx > & ptx , signed_tx_set & signed_txs ) ;
std : : string sign_tx_dump_to_str ( unsigned_tx_set & exported_txs , std : : vector < wallet2 : : pending_tx > & ptx , signed_tx_set & signed_txes ) ;
2017-01-08 12:17:09 +00:00
// load unsigned_tx_set from file.
2018-01-17 01:58:34 +00:00
bool load_unsigned_tx ( const std : : string & unsigned_filename , unsigned_tx_set & exported_txs ) const ;
wallet-rpc: watch-only and cold wallet features added
- unsigned_txset, signed_txset in transfer / submit_transfer / sign_transfer
- export_outputs, import_outputs
Squashed commits:
[f4d9f3d4] wallet-rpc: do_not_relay removed from submit_transfer
[5b16a86f] wallet-rpc: review-fix - method signature changes, renaming
[b7fbb10a] wallet-rpc: naming fixes (unsigned vs signed), consts renamed
[8c7d2727] wallet-rpc: sign_transfer added
[481d024a] wallet2: sign_tx splitted to work with strings and structs, more granular
[2a474db9] wallet-rpc: wallet2::load_unsigned_tx split to load from str, file
[b1e3a018] wallet-rpc: review fix, load_tx_from_str variable rename
[1f6373be] wallet-rpc: review fix: save_tx_to_{str,file}
[2a08eafc] wallet-rpc: review comments fixes
- redundant this removed from wallet2.cpp
- load_tx_from_str, load_tx_from_file
[43498052] wallet-rpc: submit_transfer added
[9c45d1ad] wallet-rpc: watch_only check, return unsigned_txset
[62831396] wallet2: added string variants to load_tx, save_tx
- analogously to save_multisig_tx
- required for monero-wallet-rpc to support watch-only wallet
2018-05-07 21:23:47 +00:00
bool parse_unsigned_tx_from_str ( const std : : string & unsigned_tx_st , unsigned_tx_set & exported_txs ) const ;
2016-10-30 10:49:22 +00:00
bool load_tx ( const std : : string & signed_filename , std : : vector < tools : : wallet2 : : pending_tx > & ptx , std : : function < bool ( const signed_tx_set & ) > accept_func = NULL ) ;
wallet-rpc: watch-only and cold wallet features added
- unsigned_txset, signed_txset in transfer / submit_transfer / sign_transfer
- export_outputs, import_outputs
Squashed commits:
[f4d9f3d4] wallet-rpc: do_not_relay removed from submit_transfer
[5b16a86f] wallet-rpc: review-fix - method signature changes, renaming
[b7fbb10a] wallet-rpc: naming fixes (unsigned vs signed), consts renamed
[8c7d2727] wallet-rpc: sign_transfer added
[481d024a] wallet2: sign_tx splitted to work with strings and structs, more granular
[2a474db9] wallet-rpc: wallet2::load_unsigned_tx split to load from str, file
[b1e3a018] wallet-rpc: review fix, load_tx_from_str variable rename
[1f6373be] wallet-rpc: review fix: save_tx_to_{str,file}
[2a08eafc] wallet-rpc: review comments fixes
- redundant this removed from wallet2.cpp
- load_tx_from_str, load_tx_from_file
[43498052] wallet-rpc: submit_transfer added
[9c45d1ad] wallet-rpc: watch_only check, return unsigned_txset
[62831396] wallet2: added string variants to load_tx, save_tx
- analogously to save_multisig_tx
- required for monero-wallet-rpc to support watch-only wallet
2018-05-07 21:23:47 +00:00
bool parse_tx_from_str ( const std : : string & signed_tx_st , std : : vector < tools : : wallet2 : : pending_tx > & ptx , std : : function < bool ( const signed_tx_set & ) > accept_func ) ;
2018-08-10 12:15:40 +00:00
std : : vector < wallet2 : : pending_tx > create_transactions_2 ( std : : vector < cryptonote : : tx_destination_entry > dsts , const size_t fake_outs_count , const uint64_t unlock_time , uint32_t priority , const std : : vector < uint8_t > & extra , uint32_t subaddr_account , std : : set < uint32_t > subaddr_indices ) ; // pass subaddr_indices by value on purpose
2018-05-06 08:38:47 +00:00
std : : vector < wallet2 : : pending_tx > create_transactions_all ( uint64_t below , const cryptonote : : account_public_address & address , bool is_subaddress , const size_t outputs , const size_t fake_outs_count , const uint64_t unlock_time , uint32_t priority , const std : : vector < uint8_t > & extra , uint32_t subaddr_account , std : : set < uint32_t > subaddr_indices ) ;
std : : vector < wallet2 : : pending_tx > create_transactions_single ( const crypto : : key_image & ki , const cryptonote : : account_public_address & address , bool is_subaddress , const size_t outputs , const size_t fake_outs_count , const uint64_t unlock_time , uint32_t priority , const std : : vector < uint8_t > & extra ) ;
std : : vector < wallet2 : : pending_tx > create_transactions_from ( const cryptonote : : account_public_address & address , bool is_subaddress , const size_t outputs , std : : vector < size_t > unused_transfers_indices , std : : vector < size_t > unused_dust_indices , const size_t fake_outs_count , const uint64_t unlock_time , uint32_t priority , const std : : vector < uint8_t > & extra ) ;
2019-03-09 16:21:19 +00:00
bool sanity_check ( const std : : vector < wallet2 : : pending_tx > & ptx_vector , std : : vector < cryptonote : : tx_destination_entry > dsts ) const ;
2018-08-23 21:50:53 +00:00
void cold_tx_aux_import ( const std : : vector < pending_tx > & ptx , const std : : vector < std : : string > & tx_device_aux ) ;
void cold_sign_tx ( const std : : vector < pending_tx > & ptx_vector , signed_tx_set & exported_txs , std : : vector < cryptonote : : address_parse_info > & dsts_info , std : : vector < std : : string > & tx_device_aux ) ;
uint64_t cold_key_image_sync ( uint64_t & spent , uint64_t & unspent ) ;
2019-05-31 08:41:52 +00:00
void device_show_address ( uint32_t account_index , uint32_t address_index , const boost : : optional < crypto : : hash8 > & payment_id ) ;
2019-03-05 13:42:43 +00:00
bool parse_multisig_tx_from_str ( std : : string multisig_tx_st , multisig_tx_set & exported_txs ) const ;
2017-11-27 20:09:16 +00:00
bool load_multisig_tx ( cryptonote : : blobdata blob , multisig_tx_set & exported_txs , std : : function < bool ( const multisig_tx_set & ) > accept_func = NULL ) ;
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 load_multisig_tx_from_file ( const std : : string & filename , multisig_tx_set & exported_txs , std : : function < bool ( const multisig_tx_set & ) > accept_func = NULL ) ;
bool sign_multisig_tx_from_file ( const std : : string & filename , std : : vector < crypto : : hash > & txids , std : : function < bool ( const multisig_tx_set & ) > accept_func ) ;
2017-08-13 14:29:31 +00:00
bool sign_multisig_tx ( multisig_tx_set & exported_txs , std : : vector < crypto : : hash > & txids ) ;
2017-09-26 22:16:25 +00:00
bool sign_multisig_tx_to_file ( multisig_tx_set & exported_txs , const std : : string & filename , std : : vector < crypto : : hash > & txids ) ;
2018-08-10 12:15:40 +00:00
std : : vector < pending_tx > create_unmixable_sweep_transactions ( ) ;
void discard_unmixable_outputs ( ) ;
epee: add SSL support
RPC connections now have optional tranparent SSL.
An optional private key and certificate file can be passed,
using the --{rpc,daemon}-ssl-private-key and
--{rpc,daemon}-ssl-certificate options. Those have as
argument a path to a PEM format private private key and
certificate, respectively.
If not given, a temporary self signed certificate will be used.
SSL can be enabled or disabled using --{rpc}-ssl, which
accepts autodetect (default), disabled or enabled.
Access can be restricted to particular certificates using the
--rpc-ssl-allowed-certificates, which takes a list of
paths to PEM encoded certificates. This can allow a wallet to
connect to only the daemon they think they're connected to,
by forcing SSL and listing the paths to the known good
certificates.
To generate long term certificates:
openssl genrsa -out /tmp/KEY 4096
openssl req -new -key /tmp/KEY -out /tmp/REQ
openssl x509 -req -days 999999 -sha256 -in /tmp/REQ -signkey /tmp/KEY -out /tmp/CERT
/tmp/KEY is the private key, and /tmp/CERT is the certificate,
both in PEM format. /tmp/REQ can be removed. Adjust the last
command to set expiration date, etc, as needed. It doesn't
make a whole lot of sense for monero anyway, since most servers
will run with one time temporary self signed certificates anyway.
SSL support is transparent, so all communication is done on the
existing ports, with SSL autodetection. This means you can start
using an SSL daemon now, but you should not enforce SSL yet or
nothing will talk to you.
2018-06-14 22:44:48 +00:00
bool check_connection ( uint32_t * version = NULL , bool * ssl = NULL , uint32_t timeout = 200000 ) ;
2014-04-02 16:00:17 +00:00
void get_transfers ( wallet2 : : transfer_container & incoming_transfers ) const ;
2017-02-19 02:42:10 +00:00
void get_payments ( const crypto : : hash & payment_id , std : : list < wallet2 : : payment_details > & payments , uint64_t min_height = 0 , const boost : : optional < uint32_t > & subaddr_account = boost : : none , const std : : set < uint32_t > & subaddr_indices = { } ) const ;
void get_payments ( std : : list < std : : pair < crypto : : hash , wallet2 : : payment_details > > & payments , uint64_t min_height , uint64_t max_height = ( uint64_t ) - 1 , const boost : : optional < uint32_t > & subaddr_account = boost : : none , const std : : set < uint32_t > & subaddr_indices = { } ) const ;
2015-11-15 21:59:40 +00:00
void get_payments_out ( std : : list < std : : pair < crypto : : hash , wallet2 : : confirmed_transfer_details > > & confirmed_payments ,
2017-02-19 02:42:10 +00:00
uint64_t min_height , uint64_t max_height = ( uint64_t ) - 1 , const boost : : optional < uint32_t > & subaddr_account = boost : : none , const std : : set < uint32_t > & subaddr_indices = { } ) const ;
void get_unconfirmed_payments_out ( std : : list < std : : pair < crypto : : hash , wallet2 : : unconfirmed_transfer_details > > & unconfirmed_payments , const boost : : optional < uint32_t > & subaddr_account = boost : : none , const std : : set < uint32_t > & subaddr_indices = { } ) const ;
2017-09-22 12:57:20 +00:00
void get_unconfirmed_payments ( std : : list < std : : pair < crypto : : hash , wallet2 : : pool_payment_details > > & unconfirmed_payments , const boost : : optional < uint32_t > & subaddr_account = boost : : none , const std : : set < uint32_t > & subaddr_indices = { } ) const ;
2016-05-23 20:40:12 +00:00
2018-04-24 00:03:34 +00:00
uint64_t get_blockchain_current_height ( ) const { return m_light_wallet_blockchain_height ? m_light_wallet_blockchain_height : m_blockchain . size ( ) ; }
2015-08-11 14:14:44 +00:00
void rescan_spent ( ) ;
2018-11-12 03:31:46 +00:00
void rescan_blockchain ( bool hard , bool refresh = true , bool keep_key_images = false ) ;
2016-06-15 22:37:13 +00:00
bool is_transfer_unlocked ( const transfer_details & td ) const ;
2017-08-04 21:05:02 +00:00
bool is_transfer_unlocked ( uint64_t unlock_time , uint64_t block_height ) const ;
2018-06-02 12:06:41 +00:00
uint64_t get_last_block_reward ( ) const { return m_last_block_reward ; }
2018-11-12 03:13:54 +00:00
uint64_t get_device_last_key_image_sync ( ) const { return m_device_last_key_image_sync ; }
2018-06-02 12:06:41 +00:00
2019-06-25 16:50:08 +00:00
std : : vector < cryptonote : : public_node > get_public_nodes ( bool white_only = true ) ;
2014-03-03 22:07:58 +00:00
template < class t_archive >
inline void serialize ( t_archive & a , const unsigned int ver )
{
2016-04-29 14:17:12 +00:00
uint64_t dummy_refresh_height = 0 ; // moved to keys file
2014-03-03 22:07:58 +00:00
if ( ver < 5 )
return ;
2017-09-11 13:38:37 +00:00
if ( ver < 19 )
{
std : : vector < crypto : : hash > blockchain ;
a & blockchain ;
for ( const auto & b : blockchain )
{
m_blockchain . push_back ( b ) ;
}
}
else
{
a & m_blockchain ;
}
2014-03-03 22:07:58 +00:00
a & m_transfers ;
a & m_account_public_address ;
a & m_key_images ;
2014-04-02 16:00:17 +00:00
if ( ver < 6 )
return ;
a & m_unconfirmed_txs ;
2014-05-03 16:19:43 +00:00
if ( ver < 7 )
return ;
a & m_payments ;
2015-08-19 19:59:44 +00:00
if ( ver < 8 )
return ;
a & m_tx_keys ;
2015-11-15 21:59:40 +00:00
if ( ver < 9 )
return ;
a & m_confirmed_txs ;
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
if ( ver < 11 )
return ;
2016-04-29 14:17:12 +00:00
a & dummy_refresh_height ;
2016-04-20 17:19:42 +00:00
if ( ver < 12 )
return ;
a & m_tx_notes ;
2016-05-23 20:40:12 +00:00
if ( ver < 13 )
return ;
2017-03-04 21:47:53 +00:00
if ( ver < 17 )
{
// we're loading an old version, where m_unconfirmed_payments was a std::map
std : : unordered_map < crypto : : hash , payment_details > m ;
a & m ;
for ( std : : unordered_map < crypto : : hash , payment_details > : : const_iterator i = m . begin ( ) ; i ! = m . end ( ) ; + + i )
2017-09-22 12:57:20 +00:00
m_unconfirmed_payments . insert ( std : : make_pair ( i - > first , pool_payment_details { i - > second , false } ) ) ;
2017-03-04 21:47:53 +00:00
}
2016-07-11 22:14:58 +00:00
if ( ver < 14 )
return ;
2016-11-07 18:50:05 +00:00
if ( ver < 15 )
{
// we're loading an older wallet without a pubkey map, rebuild it
for ( size_t i = 0 ; i < m_transfers . size ( ) ; + + i )
{
const transfer_details & td = m_transfers [ i ] ;
const cryptonote : : tx_out & out = td . m_tx . vout [ td . m_internal_output_index ] ;
const cryptonote : : txout_to_key & o = boost : : get < const cryptonote : : txout_to_key > ( out . target ) ;
m_pub_keys . emplace ( o . key , i ) ;
}
return ;
}
a & m_pub_keys ;
2016-12-11 23:42:46 +00:00
if ( ver < 16 )
return ;
a & m_address_book ;
2017-03-04 21:47:53 +00:00
if ( ver < 17 )
return ;
2017-11-15 08:30:49 +00:00
if ( ver < 22 )
2017-09-22 12:57:20 +00:00
{
// we're loading an old version, where m_unconfirmed_payments payload was payment_details
2017-11-15 08:30:49 +00:00
std : : unordered_multimap < crypto : : hash , payment_details > m ;
2017-09-22 12:57:20 +00:00
a & m ;
for ( const auto & i : m )
m_unconfirmed_payments . insert ( std : : make_pair ( i . first , pool_payment_details { i . second , false } ) ) ;
}
2017-03-21 10:30:25 +00:00
if ( ver < 18 )
return ;
a & m_scanned_pool_txs [ 0 ] ;
a & m_scanned_pool_txs [ 1 ] ;
2017-02-19 02:42:10 +00:00
if ( ver < 20 )
return ;
a & m_subaddresses ;
2018-02-13 16:45:04 +00:00
std : : unordered_map < cryptonote : : subaddress_index , crypto : : public_key > dummy_subaddresses_inv ;
a & dummy_subaddresses_inv ;
2017-02-19 02:42:10 +00:00
a & m_subaddress_labels ;
a & m_additional_tx_keys ;
2017-10-08 07:15:06 +00:00
if ( ver < 21 )
return ;
a & m_attributes ;
2017-09-22 12:57:20 +00:00
if ( ver < 22 )
return ;
a & m_unconfirmed_payments ;
2017-12-15 03:08:36 +00:00
if ( ver < 23 )
return ;
a & m_account_tags ;
2018-02-18 10:47:25 +00:00
if ( ver < 24 )
return ;
a & m_ring_history_saved ;
2018-06-02 12:06:41 +00:00
if ( ver < 25 )
return ;
a & m_last_block_reward ;
2018-08-23 21:50:53 +00:00
if ( ver < 26 )
return ;
a & m_tx_device ;
2018-11-12 03:13:54 +00:00
if ( ver < 27 )
return ;
a & m_device_last_key_image_sync ;
2018-12-25 13:59:44 +00:00
if ( ver < 28 )
return ;
a & m_cold_key_images ;
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
if ( ver < 29 )
return ;
a & m_rpc_client_secret_key ;
2014-03-03 22:07:58 +00:00
}
2014-12-11 10:48:04 +00:00
/*!
* \ brief Check if wallet keys and bin files exist
* \ param file_path Wallet file path
* \ param keys_file_exists Whether keys file exists
* \ param wallet_file_exists Whether bin file exists
*/
2014-05-25 17:06:40 +00:00
static void wallet_exists ( const std : : string & file_path , bool & keys_file_exists , bool & wallet_file_exists ) ;
2014-12-11 10:47:24 +00:00
/*!
* \ brief Check if wallet file path is valid format
* \ param file_path Wallet file path
* \ return Whether path is valid format
*/
static bool wallet_valid_path_format ( const std : : string & file_path ) ;
2015-08-09 09:09:39 +00:00
static bool parse_long_payment_id ( const std : : string & payment_id_str , crypto : : hash & payment_id ) ;
static bool parse_short_payment_id ( const std : : string & payment_id_str , crypto : : hash8 & payment_id ) ;
2014-06-01 22:22:42 +00:00
static bool parse_payment_id ( const std : : string & payment_id_str , crypto : : hash & payment_id ) ;
2015-07-18 21:03:35 +00:00
bool always_confirm_transfers ( ) const { return m_always_confirm_transfers ; }
void always_confirm_transfers ( bool always ) { m_always_confirm_transfers = always ; }
2016-12-23 12:04:54 +00:00
bool print_ring_members ( ) const { return m_print_ring_members ; }
void print_ring_members ( bool value ) { m_print_ring_members = value ; }
2015-11-22 12:26:27 +00:00
bool store_tx_info ( ) const { return m_store_tx_info ; }
void store_tx_info ( bool store ) { m_store_tx_info = store ; }
2015-10-30 21:16:51 +00:00
uint32_t default_mixin ( ) const { return m_default_mixin ; }
void default_mixin ( uint32_t m ) { m_default_mixin = m ; }
2016-09-16 10:50:52 +00:00
uint32_t get_default_priority ( ) const { return m_default_priority ; }
void set_default_priority ( uint32_t p ) { m_default_priority = p ; }
2015-11-28 12:38:58 +00:00
bool auto_refresh ( ) const { return m_auto_refresh ; }
void auto_refresh ( bool r ) { m_auto_refresh = r ; }
2018-09-02 09:59:01 +00:00
AskPasswordType ask_password ( ) const { return m_ask_password ; }
void ask_password ( AskPasswordType ask ) { m_ask_password = ask ; }
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
void set_min_output_count ( uint32_t count ) { m_min_output_count = count ; }
uint32_t get_min_output_count ( ) const { return m_min_output_count ; }
void set_min_output_value ( uint64_t value ) { m_min_output_value = value ; }
uint64_t get_min_output_value ( ) const { return m_min_output_value ; }
2017-03-24 21:56:58 +00:00
void merge_destinations ( bool merge ) { m_merge_destinations = merge ; }
bool merge_destinations ( ) const { return m_merge_destinations ; }
2017-08-26 15:23:54 +00:00
bool confirm_backlog ( ) const { return m_confirm_backlog ; }
void confirm_backlog ( bool always ) { m_confirm_backlog = always ; }
2017-09-18 11:46:33 +00:00
void set_confirm_backlog_threshold ( uint32_t threshold ) { m_confirm_backlog_threshold = threshold ; } ;
uint32_t get_confirm_backlog_threshold ( ) const { return m_confirm_backlog_threshold ; } ;
2018-01-14 23:36:13 +00:00
bool confirm_export_overwrite ( ) const { return m_confirm_export_overwrite ; }
void confirm_export_overwrite ( bool always ) { m_confirm_export_overwrite = always ; }
2018-01-15 03:05:16 +00:00
bool auto_low_priority ( ) const { return m_auto_low_priority ; }
void auto_low_priority ( bool value ) { m_auto_low_priority = value ; }
2018-02-19 10:23:23 +00:00
bool segregate_pre_fork_outputs ( ) const { return m_segregate_pre_fork_outputs ; }
void segregate_pre_fork_outputs ( bool value ) { m_segregate_pre_fork_outputs = value ; }
bool key_reuse_mitigation2 ( ) const { return m_key_reuse_mitigation2 ; }
void key_reuse_mitigation2 ( bool value ) { m_key_reuse_mitigation2 = value ; }
2018-03-13 19:38:52 +00:00
uint64_t segregation_height ( ) const { return m_segregation_height ; }
void segregation_height ( uint64_t height ) { m_segregation_height = height ; }
2018-06-28 02:31:50 +00:00
bool ignore_fractional_outputs ( ) const { return m_ignore_fractional_outputs ; }
void ignore_fractional_outputs ( bool value ) { m_ignore_fractional_outputs = value ; }
2018-03-31 13:20:48 +00:00
bool confirm_non_default_ring_size ( ) const { return m_confirm_non_default_ring_size ; }
void confirm_non_default_ring_size ( bool always ) { m_confirm_non_default_ring_size = always ; }
2019-10-02 04:04:24 +00:00
uint64_t ignore_outputs_above ( ) const { return m_ignore_outputs_above ; }
void ignore_outputs_above ( uint64_t value ) { m_ignore_outputs_above = value ; }
uint64_t ignore_outputs_below ( ) const { return m_ignore_outputs_below ; }
void ignore_outputs_below ( uint64_t value ) { m_ignore_outputs_below = value ; }
2018-12-03 15:32:14 +00:00
bool track_uses ( ) const { return m_track_uses ; }
void track_uses ( bool value ) { m_track_uses = value ; }
2019-03-30 19:21:30 +00:00
BackgroundMiningSetupType setup_background_mining ( ) const { return m_setup_background_mining ; }
void setup_background_mining ( BackgroundMiningSetupType value ) { m_setup_background_mining = value ; }
2019-05-06 08:44:50 +00:00
uint32_t inactivity_lock_timeout ( ) const { return m_inactivity_lock_timeout ; }
void inactivity_lock_timeout ( uint32_t seconds ) { m_inactivity_lock_timeout = seconds ; }
2018-08-23 22:50:31 +00:00
const std : : string & device_name ( ) const { return m_device_name ; }
void device_name ( const std : : string & device_name ) { m_device_name = device_name ; }
2018-11-11 23:07:25 +00:00
const std : : string & device_derivation_path ( ) const { return m_device_derivation_path ; }
void device_derivation_path ( const std : : string & device_derivation_path ) { m_device_derivation_path = device_derivation_path ; }
2019-04-10 09:20:12 +00:00
const ExportFormat & export_format ( ) const { return m_export_format ; }
inline void set_export_format ( const ExportFormat & export_format ) { m_export_format = export_format ; }
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 persistent_rpc_client_id ( ) const { return m_persistent_rpc_client_id ; }
void persistent_rpc_client_id ( bool persistent ) { m_persistent_rpc_client_id = persistent ; }
void auto_mine_for_rpc_payment_threshold ( float threshold ) { m_auto_mine_for_rpc_payment_threshold = threshold ; }
float auto_mine_for_rpc_payment_threshold ( ) const { return m_auto_mine_for_rpc_payment_threshold ; }
crypto : : secret_key get_rpc_client_secret_key ( ) const { return m_rpc_client_secret_key ; }
void set_rpc_client_secret_key ( const crypto : : secret_key & key ) { m_rpc_client_secret_key = key ; m_node_rpc_proxy . set_client_secret_key ( key ) ; }
uint64_t credits_target ( ) const { return m_credits_target ; }
void credits_target ( uint64_t threshold ) { m_credits_target = threshold ; }
2015-07-18 21:03:35 +00:00
2019-02-23 14:28:18 +00:00
bool get_tx_key_cached ( const crypto : : hash & txid , crypto : : secret_key & tx_key , std : : vector < crypto : : secret_key > & additional_tx_keys ) const ;
2018-07-29 12:29:56 +00:00
void set_tx_key ( const crypto : : hash & txid , const crypto : : secret_key & tx_key , const std : : vector < crypto : : secret_key > & additional_tx_keys ) ;
2019-02-23 14:28:18 +00:00
bool get_tx_key ( const crypto : : hash & txid , crypto : : secret_key & tx_key , std : : vector < crypto : : secret_key > & additional_tx_keys ) ;
2017-09-12 01:05:41 +00:00
void check_tx_key ( const crypto : : hash & txid , const crypto : : secret_key & tx_key , const std : : vector < crypto : : secret_key > & additional_tx_keys , const cryptonote : : account_public_address & address , uint64_t & received , bool & in_pool , uint64_t & confirmations ) ;
void check_tx_key_helper ( const crypto : : hash & txid , const crypto : : key_derivation & derivation , const std : : vector < crypto : : key_derivation > & additional_derivations , const cryptonote : : account_public_address & address , uint64_t & received , bool & in_pool , uint64_t & confirmations ) ;
2019-03-09 16:21:19 +00:00
void check_tx_key_helper ( const cryptonote : : transaction & tx , const crypto : : key_derivation & derivation , const std : : vector < crypto : : key_derivation > & additional_derivations , const cryptonote : : account_public_address & address , uint64_t & received ) const ;
2017-11-20 09:10:58 +00:00
std : : string get_tx_proof ( const crypto : : hash & txid , const cryptonote : : account_public_address & address , bool is_subaddress , const std : : string & message ) ;
2019-03-09 16:21:19 +00:00
std : : string get_tx_proof ( const cryptonote : : transaction & tx , const crypto : : secret_key & tx_key , const std : : vector < crypto : : secret_key > & additional_tx_keys , const cryptonote : : account_public_address & address , bool is_subaddress , const std : : string & message ) const ;
2017-09-12 01:05:41 +00:00
bool check_tx_proof ( const crypto : : hash & txid , const cryptonote : : account_public_address & address , bool is_subaddress , const std : : string & message , const std : : string & sig_str , uint64_t & received , bool & in_pool , uint64_t & confirmations ) ;
2019-03-09 16:21:19 +00:00
bool check_tx_proof ( const cryptonote : : transaction & tx , const cryptonote : : account_public_address & address , bool is_subaddress , const std : : string & message , const std : : string & sig_str , uint64_t & received ) const ;
2015-08-19 19:59:44 +00:00
2017-08-28 15:34:17 +00:00
std : : string get_spend_proof ( const crypto : : hash & txid , const std : : string & message ) ;
bool check_spend_proof ( const crypto : : hash & txid , const std : : string & message , const std : : string & sig_str ) ;
2017-12-28 13:50:10 +00:00
/*!
* \ brief Generates a proof that proves the reserve of unspent funds
* \ param account_minreserve When specified , collect outputs only belonging to the given account and prove the smallest reserve above the given amount
* When unspecified , proves for all unspent outputs across all accounts
* \ param message Arbitrary challenge message to be signed together
* \ return Signature string
*/
std : : string get_reserve_proof ( const boost : : optional < std : : pair < uint32_t , uint64_t > > & account_minreserve , const std : : string & message ) ;
/*!
* \ brief Verifies a proof of reserve
* \ param address The signer ' s address
* \ param message Challenge message used for signing
* \ param sig_str Signature string
* \ param total [ OUT ] the sum of funds included in the signature
* \ param spent [ OUT ] the sum of spent funds included in the signature
* \ return true if the signature verifies correctly
*/
bool check_reserve_proof ( const cryptonote : : account_public_address & address , const std : : string & message , const std : : string & sig_str , uint64_t & total , uint64_t & spent ) ;
2016-12-11 23:42:46 +00:00
/*!
* \ brief GUI Address book get / store
*/
2016-12-12 20:39:29 +00:00
std : : vector < address_book_row > get_address_book ( ) const { return m_address_book ; }
2019-11-19 16:30:19 +00:00
bool add_address_book_row ( const cryptonote : : account_public_address & address , const crypto : : hash8 * payment_id , const std : : string & description , bool is_subaddress ) ;
bool set_address_book_row ( size_t row_id , const cryptonote : : account_public_address & address , const crypto : : hash8 * payment_id , const std : : string & description , bool is_subaddress ) ;
2016-12-14 21:37:49 +00:00
bool delete_address_book_row ( std : : size_t row_id ) ;
2016-12-11 23:42:46 +00:00
2016-07-27 20:37:58 +00:00
uint64_t get_num_rct_outputs ( ) ;
2017-05-28 11:18:51 +00:00
size_t get_num_transfer_details ( ) const { return m_transfers . size ( ) ; }
2016-10-15 18:18:52 +00:00
const transfer_details & get_transfer_details ( size_t idx ) const ;
2016-07-27 20:37:58 +00:00
2019-05-31 08:41:52 +00:00
uint8_t get_current_hard_fork ( ) ;
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
void get_hard_fork_info ( uint8_t version , uint64_t & earliest_height ) ;
bool use_fork_rules ( uint8_t version , int64_t early_blocks = 0 ) ;
int get_fee_algorithm ( ) ;
2016-03-11 21:31:50 +00:00
2016-03-11 14:05:36 +00:00
std : : string get_wallet_file ( ) const ;
std : : string get_keys_file ( ) const ;
2016-03-25 14:06:30 +00:00
std : : string get_daemon_address ( ) const ;
2017-02-05 22:48:03 +00:00
const boost : : optional < epee : : net_utils : : http : : login > & get_daemon_login ( ) const { return m_daemon_login ; }
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
uint64_t get_daemon_blockchain_height ( std : : string & err ) ;
2016-10-03 18:47:41 +00:00
uint64_t get_daemon_blockchain_target_height ( std : : string & err ) ;
2016-11-10 14:36:16 +00:00
/*!
* \ brief Calculates the approximate blockchain height from current date / time .
*/
uint64_t get_approximate_blockchain_height ( ) const ;
2017-11-16 23:00:06 +00:00
uint64_t estimate_blockchain_height ( ) ;
2018-08-10 12:15:40 +00:00
std : : vector < size_t > select_available_outputs_from_histogram ( uint64_t count , bool atleast , bool unlocked , bool allow_rct ) ;
2018-01-17 01:58:34 +00:00
std : : vector < size_t > select_available_outputs ( const std : : function < bool ( const transfer_details & td ) > & f ) const ;
2018-08-10 12:15:40 +00:00
std : : vector < size_t > select_available_unmixable_outputs ( ) ;
std : : vector < size_t > select_available_mixable_outputs ( ) ;
2016-04-17 10:20:44 +00:00
2017-10-22 08:54:07 +00:00
size_t pop_best_value_from ( const transfer_container & transfers , std : : vector < size_t > & unused_dust_indices , const std : : vector < size_t > & selected_transfers , bool smallest = false ) const ;
size_t pop_best_value ( std : : vector < size_t > & unused_dust_indices , const std : : vector < size_t > & selected_transfers , bool smallest = false ) const ;
2016-07-12 21:00:43 +00:00
2016-04-20 17:19:42 +00:00
void set_tx_note ( const crypto : : hash & txid , const std : : string & note ) ;
std : : string get_tx_note ( const crypto : : hash & txid ) const ;
2018-08-23 21:50:53 +00:00
void set_tx_device_aux ( const crypto : : hash & txid , const std : : string & aux ) ;
std : : string get_tx_device_aux ( const crypto : : hash & txid ) const ;
2017-10-08 07:15:06 +00:00
void set_description ( const std : : string & description ) ;
std : : string get_description ( ) const ;
2017-12-15 03:08:36 +00:00
/*!
* \ brief Get the list of registered account tags .
* \ return first . Key = ( tag ' s name ) , first . Value = ( tag ' s label ) , second [ i ] = ( i - th account ' s tag )
*/
const std : : pair < std : : map < std : : string , std : : string > , std : : vector < std : : string > > & get_account_tags ( ) ;
/*!
* \ brief Set a tag to the given accounts .
* \ param account_indices Indices of accounts .
* \ param tag Tag ' s name . If empty , the accounts become untagged .
*/
2018-11-23 13:25:15 +00:00
void set_account_tag ( const std : : set < uint32_t > & account_indices , const std : : string & tag ) ;
2017-12-15 03:08:36 +00:00
/*!
* \ brief Set the label of the given tag .
* \ param tag Tag ' s name ( which must be non - empty ) .
2018-03-14 15:41:24 +00:00
* \ param description Tag ' s description .
2017-12-15 03:08:36 +00:00
*/
void set_account_tag_description ( const std : : string & tag , const std : : string & description ) ;
2019-10-31 14:09:19 +00:00
std : : string sign ( const std : : string & data , cryptonote : : subaddress_index index = { 0 , 0 } ) const ;
2016-04-23 20:46:48 +00:00
bool verify ( const std : : string & data , const cryptonote : : account_public_address & address , const std : : string & signature ) const ;
2018-04-10 15:38:54 +00:00
/*!
* \ brief sign_multisig_participant signs given message with the multisig public signer key
* \ param data message to sign
* \ throws if wallet is not multisig
* \ return signature
*/
std : : string sign_multisig_participant ( const std : : string & data ) const ;
/*!
* \ brief verify_with_public_key verifies message was signed with given public key
* \ param data message
* \ param public_key public key to check signature
* \ param signature signature of the message
* \ return true if the signature is correct
*/
bool verify_with_public_key ( const std : : string & data , const crypto : : public_key & public_key , const std : : string & signature ) const ;
2017-08-18 12:27:54 +00:00
// Import/Export wallet data
2019-04-10 10:37:34 +00:00
std : : pair < size_t , std : : vector < tools : : wallet2 : : transfer_details > > export_outputs ( bool all = false ) const ;
std : : string export_outputs_to_str ( bool all = false ) const ;
2018-10-24 18:24:11 +00:00
size_t import_outputs ( const std : : pair < size_t , std : : vector < tools : : wallet2 : : transfer_details > > & outputs ) ;
wallet-rpc: watch-only and cold wallet features added
- unsigned_txset, signed_txset in transfer / submit_transfer / sign_transfer
- export_outputs, import_outputs
Squashed commits:
[f4d9f3d4] wallet-rpc: do_not_relay removed from submit_transfer
[5b16a86f] wallet-rpc: review-fix - method signature changes, renaming
[b7fbb10a] wallet-rpc: naming fixes (unsigned vs signed), consts renamed
[8c7d2727] wallet-rpc: sign_transfer added
[481d024a] wallet2: sign_tx splitted to work with strings and structs, more granular
[2a474db9] wallet-rpc: wallet2::load_unsigned_tx split to load from str, file
[b1e3a018] wallet-rpc: review fix, load_tx_from_str variable rename
[1f6373be] wallet-rpc: review fix: save_tx_to_{str,file}
[2a08eafc] wallet-rpc: review comments fixes
- redundant this removed from wallet2.cpp
- load_tx_from_str, load_tx_from_file
[43498052] wallet-rpc: submit_transfer added
[9c45d1ad] wallet-rpc: watch_only check, return unsigned_txset
[62831396] wallet2: added string variants to load_tx, save_tx
- analogously to save_multisig_tx
- required for monero-wallet-rpc to support watch-only wallet
2018-05-07 21:23:47 +00:00
size_t import_outputs_from_str ( const std : : string & outputs_st ) ;
2017-08-18 12:27:54 +00:00
payment_container export_payments ( ) const ;
void import_payments ( const payment_container & payments ) ;
void import_payments_out ( const std : : list < std : : pair < crypto : : hash , wallet2 : : confirmed_transfer_details > > & confirmed_payments ) ;
2017-09-11 13:38:37 +00:00
std : : tuple < size_t , crypto : : hash , std : : vector < crypto : : hash > > export_blockchain ( ) const ;
void import_blockchain ( const std : : tuple < size_t , crypto : : hash , std : : vector < crypto : : hash > > & bc ) ;
2019-07-02 19:41:41 +00:00
bool export_key_images ( const std : : string & filename , bool all = false ) const ;
2018-12-24 12:58:25 +00:00
std : : pair < size_t , std : : vector < std : : pair < crypto : : key_image , crypto : : signature > > > export_key_images ( bool all = false ) const ;
2018-10-24 18:24:11 +00:00
uint64_t import_key_images ( const std : : vector < std : : pair < crypto : : key_image , crypto : : signature > > & signed_key_images , size_t offset , uint64_t & spent , uint64_t & unspent , bool check_spent = true ) ;
2017-01-13 11:02:13 +00:00
uint64_t import_key_images ( const std : : string & filename , uint64_t & spent , uint64_t & unspent ) ;
2019-02-23 14:28:18 +00:00
bool import_key_images ( std : : vector < crypto : : key_image > key_images , size_t offset = 0 , boost : : optional < std : : unordered_set < size_t > > selected_transfers = boost : : none ) ;
bool import_key_images ( signed_tx_set & signed_tx , size_t offset = 0 , bool only_selected_transfers = false ) ;
2018-08-23 21:50:53 +00:00
crypto : : public_key get_tx_pub_key_from_received_outs ( const tools : : wallet2 : : transfer_details & td ) const ;
2016-05-23 20:40:12 +00:00
2019-12-30 03:09:00 +00:00
void update_pool_state ( std : : vector < std : : tuple < cryptonote : : transaction , crypto : : hash , bool > > & process_txs , bool refreshed = false ) ;
void process_pool_state ( const std : : vector < std : : tuple < cryptonote : : transaction , crypto : : hash , bool > > & txs ) ;
2017-08-04 20:38:37 +00:00
void remove_obsolete_pool_txs ( const std : : vector < crypto : : hash > & tx_hashes ) ;
2016-11-07 19:28:15 +00:00
2018-07-06 23:03:15 +00:00
std : : string encrypt ( const char * plaintext , size_t len , const crypto : : secret_key & skey , bool authenticated = true ) const ;
std : : string encrypt ( const epee : : span < char > & span , const crypto : : secret_key & skey , bool authenticated = true ) const ;
2016-11-07 19:28:15 +00:00
std : : string encrypt ( const std : : string & plaintext , const crypto : : secret_key & skey , bool authenticated = true ) const ;
2018-07-06 23:03:15 +00:00
std : : string encrypt ( const epee : : wipeable_string & plaintext , const crypto : : secret_key & skey , bool authenticated = true ) const ;
2016-11-07 19:28:15 +00:00
std : : string encrypt_with_view_secret_key ( const std : : string & plaintext , bool authenticated = true ) const ;
2018-07-06 23:03:15 +00:00
template < typename T = std : : string > T decrypt ( const std : : string & ciphertext , const crypto : : secret_key & skey , bool authenticated = true ) const ;
2016-11-07 19:28:15 +00:00
std : : string decrypt_with_view_secret_key ( const std : : string & ciphertext , bool authenticated = true ) const ;
2018-01-17 01:58:34 +00:00
std : : string make_uri ( const std : : string & address , const std : : string & payment_id , uint64_t amount , const std : : string & tx_description , const std : : string & recipient_name , std : : string & error ) const ;
2016-11-28 14:07:25 +00:00
bool parse_uri ( const std : : string & uri , std : : string & address , std : : string & payment_id , uint64_t & amount , std : : string & tx_description , std : : string & recipient_name , std : : vector < std : : string > & unknown_parameters , std : : string & error ) ;
2016-12-25 08:18:15 +00:00
uint64_t get_blockchain_height_by_date ( uint16_t year , uint8_t month , uint8_t day ) ; // 1<=month<=12, 1<=day<=31
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 is_synced ( ) ;
2017-08-02 13:44:19 +00:00
2018-01-15 12:48:25 +00:00
std : : vector < std : : pair < uint64_t , uint64_t > > estimate_backlog ( const std : : vector < std : : pair < double , double > > & fee_levels ) ;
2018-07-18 21:24:53 +00:00
std : : vector < std : : pair < uint64_t , uint64_t > > estimate_backlog ( uint64_t min_tx_weight , uint64_t max_tx_weight , const std : : vector < uint64_t > & fees ) ;
2017-08-27 20:04:56 +00:00
2020-01-22 16:30:47 +00:00
uint64_t estimate_fee ( bool use_per_byte_fee , bool use_rct , int n_inputs , int mixin , int n_outputs , size_t extra_size , bool bulletproof , uint64_t base_fee , uint64_t fee_multiplier , uint64_t fee_quantization_mask ) const ;
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
uint64_t get_fee_multiplier ( uint32_t priority , int fee_algorithm = - 1 ) ;
uint64_t get_base_fee ( ) ;
uint64_t get_fee_quantization_mask ( ) ;
uint64_t get_min_ring_size ( ) ;
uint64_t get_max_ring_size ( ) ;
uint64_t adjust_mixin ( uint64_t mixin ) ;
2018-01-15 03:05:16 +00:00
uint32_t adjust_priority ( uint32_t priority ) ;
2017-08-26 15:23:54 +00:00
2018-09-02 09:59:01 +00:00
bool is_unattended ( ) const { return m_unattended ; }
2018-07-08 20:12:33 +00:00
2019-11-06 14:18:54 +00:00
std : : pair < size_t , uint64_t > estimate_tx_size_and_weight ( bool use_rct , int n_inputs , int ring_size , int n_outputs , size_t extra_size ) ;
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 get_rpc_payment_info ( bool mining , bool & payment_required , uint64_t & credits , uint64_t & diff , uint64_t & credits_per_hash_found , cryptonote : : blobdata & hashing_blob , uint64_t & height , uint64_t & seed_height , crypto : : hash & seed_hash , crypto : : hash & next_seed_hash , uint32_t & cookie ) ;
bool daemon_requires_payment ( ) ;
bool make_rpc_payment ( uint32_t nonce , uint32_t cookie , uint64_t & credits , uint64_t & balance ) ;
bool search_for_rpc_payment ( uint64_t credits_target , const std : : function < bool ( uint64_t , uint64_t ) > & startfunc , const std : : function < bool ( unsigned ) > & contfunc , const std : : function < bool ( uint64_t ) > & foundfunc = NULL , const std : : function < void ( const std : : string & ) > & errorfunc = NULL ) ;
template < typename T > void handle_payment_changes ( const T & res , std : : true_type ) {
if ( res . status = = CORE_RPC_STATUS_OK | | res . status = = CORE_RPC_STATUS_PAYMENT_REQUIRED )
m_rpc_payment_state . credits = res . credits ;
if ( res . top_hash ! = m_rpc_payment_state . top_hash )
{
m_rpc_payment_state . top_hash = res . top_hash ;
m_rpc_payment_state . stale = true ;
}
}
template < typename T > void handle_payment_changes ( const T & res , std : : false_type ) { }
2017-08-04 21:58:08 +00:00
// Light wallet specific functions
// fetch unspent outs from lw node and store in m_transfers
void light_wallet_get_unspent_outs ( ) ;
// fetch txs and store in m_payments
void light_wallet_get_address_txs ( ) ;
// get_address_info
2019-03-15 13:34:08 +00:00
bool light_wallet_get_address_info ( tools : : COMMAND_RPC_GET_ADDRESS_INFO : : response & response ) ;
2017-08-04 21:58:08 +00:00
// Login. new_address is true if address hasn't been used on lw node before.
bool light_wallet_login ( bool & new_address ) ;
// Send an import request to lw node. returns info about import fee, address and payment_id
2019-03-15 13:34:08 +00:00
bool light_wallet_import_wallet_request ( tools : : COMMAND_RPC_IMPORT_WALLET_REQUEST : : response & response ) ;
2017-08-04 21:58:08 +00:00
// get random outputs from light wallet server
2017-10-22 08:54:07 +00:00
void light_wallet_get_outs ( std : : vector < std : : vector < get_outs_entry > > & outs , const std : : vector < size_t > & selected_transfers , size_t fake_outputs_count ) ;
2017-08-04 21:58:08 +00:00
// Parse rct string
bool light_wallet_parse_rct_str ( const std : : string & rct_string , const crypto : : public_key & tx_pub_key , uint64_t internal_output_index , rct : : key & decrypted_mask , rct : : key & rct_commit , bool decrypt ) const ;
// check if key image is ours
bool light_wallet_key_image_is_ours ( const crypto : : key_image & key_image , const crypto : : public_key & tx_public_key , uint64_t out_index ) ;
2017-10-08 07:15:06 +00:00
/*
* " attributes " are a mechanism to store an arbitrary number of string values
* on the level of the wallet as a whole , identified by keys . Their introduction ,
* technically the unordered map m_attributes stored as part of a wallet file ,
* led to a new wallet file version , but now new singular pieces of info may be added
* without the need for a new version .
*
* The first and so far only value stored as such an attribute is the description .
* It ' s stored under the standard key ATTRIBUTE_DESCRIPTION ( see method set_description ) .
*
* The mechanism is open to all clients and allows them to use it for storing basically any
* single string values in a wallet . To avoid the problem that different clients possibly
* overwrite or misunderstand each other ' s attributes , a two - part key scheme is
* proposed : < client name > . < value name >
*/
const char * const ATTRIBUTE_DESCRIPTION = " wallet2.description " ;
void set_attribute ( const std : : string & key , const std : : string & value ) ;
2019-05-02 12:18:47 +00:00
bool get_attribute ( const std : : string & key , std : : string & value ) const ;
2017-10-08 07:15:06 +00:00
2017-08-13 14:29:31 +00:00
crypto : : public_key get_multisig_signer_public_key ( const crypto : : secret_key & spend_skey ) const ;
crypto : : public_key get_multisig_signer_public_key ( ) const ;
crypto : : public_key get_multisig_signing_public_key ( size_t idx ) const ;
crypto : : public_key get_multisig_signing_public_key ( const crypto : : secret_key & skey ) const ;
2018-02-16 01:19:39 +00:00
template < class t_request , class t_response >
2020-04-15 17:22:46 +00:00
inline bool invoke_http_json ( const boost : : string_ref uri , const t_request & req , t_response & res , std : : chrono : : milliseconds timeout = std : : chrono : : seconds ( 15 ) , const boost : : string_ref http_method = " POST " )
2018-02-16 01:19:39 +00:00
{
2019-04-13 09:19:38 +00:00
if ( m_offline ) return false ;
boost : : lock_guard < boost : : recursive_mutex > lock ( m_daemon_rpc_mutex ) ;
2020-04-15 17:22:46 +00:00
return epee : : net_utils : : invoke_http_json ( uri , req , res , * m_http_client , timeout , http_method ) ;
2018-02-16 01:19:39 +00:00
}
template < class t_request , class t_response >
2020-04-15 17:22:46 +00:00
inline bool invoke_http_bin ( const boost : : string_ref uri , const t_request & req , t_response & res , std : : chrono : : milliseconds timeout = std : : chrono : : seconds ( 15 ) , const boost : : string_ref http_method = " POST " )
2018-02-16 01:19:39 +00:00
{
2019-04-13 09:19:38 +00:00
if ( m_offline ) return false ;
boost : : lock_guard < boost : : recursive_mutex > lock ( m_daemon_rpc_mutex ) ;
2020-04-15 17:22:46 +00:00
return epee : : net_utils : : invoke_http_bin ( uri , req , res , * m_http_client , timeout , http_method ) ;
2018-02-16 01:19:39 +00:00
}
template < class t_request , class t_response >
2020-04-15 17:22:46 +00:00
inline bool invoke_http_json_rpc ( const boost : : string_ref uri , const std : : string & method_name , const t_request & req , t_response & res , std : : chrono : : milliseconds timeout = std : : chrono : : seconds ( 15 ) , const boost : : string_ref http_method = " POST " , const std : : string & req_id = " 0 " )
2018-02-16 01:19:39 +00:00
{
2019-04-13 09:19:38 +00:00
if ( m_offline ) return false ;
boost : : lock_guard < boost : : recursive_mutex > lock ( m_daemon_rpc_mutex ) ;
2020-04-15 17:22:46 +00:00
return epee : : net_utils : : invoke_http_json_rpc ( uri , method_name , req , res , * m_http_client , timeout , http_method , req_id ) ;
2018-02-16 01:19:39 +00:00
}
2018-03-21 14:29:49 +00:00
bool set_ring_database ( const std : : string & filename ) ;
2018-02-18 10:47:25 +00:00
const std : : string get_ring_database ( ) const { return m_ring_database ; }
2018-02-27 08:30:59 +00:00
bool get_ring ( const crypto : : key_image & key_image , std : : vector < uint64_t > & outs ) ;
2018-03-14 19:13:55 +00:00
bool get_rings ( const crypto : : hash & txid , std : : vector < std : : pair < crypto : : key_image , std : : vector < uint64_t > > > & outs ) ;
2018-02-28 18:26:06 +00:00
bool set_ring ( const crypto : : key_image & key_image , const std : : vector < uint64_t > & outs , bool relative ) ;
2019-04-02 14:03:25 +00:00
bool unset_ring ( const std : : vector < crypto : : key_image > & key_images ) ;
bool unset_ring ( const crypto : : hash & txid ) ;
2018-02-27 08:30:59 +00:00
bool find_and_save_rings ( bool force = true ) ;
2018-02-18 10:47:25 +00:00
2018-08-29 16:57:12 +00:00
bool blackball_output ( const std : : pair < uint64_t , uint64_t > & output ) ;
bool set_blackballed_outputs ( const std : : vector < std : : pair < uint64_t , uint64_t > > & outputs , bool add = false ) ;
bool unblackball_output ( const std : : pair < uint64_t , uint64_t > & output ) ;
bool is_output_blackballed ( const std : : pair < uint64_t , uint64_t > & output ) const ;
2018-02-25 19:20:07 +00:00
2019-03-13 21:51:41 +00:00
void freeze ( size_t idx ) ;
void thaw ( size_t idx ) ;
bool frozen ( size_t idx ) const ;
void freeze ( const crypto : : key_image & ki ) ;
void thaw ( const crypto : : key_image & ki ) ;
bool frozen ( const crypto : : key_image & ki ) const ;
bool frozen ( const transfer_details & td ) const ;
2019-04-10 09:20:12 +00:00
bool save_to_file ( const std : : string & path_to_file , const std : : string & binary , bool is_printable = false ) const ;
static bool load_from_file ( const std : : string & path_to_file , std : : string & target_str , size_t max_size = 1000000000 ) ;
2019-03-29 22:03:52 +00:00
uint64_t get_bytes_sent ( ) const ;
uint64_t get_bytes_received ( ) const ;
2018-10-28 13:46:58 +00:00
// MMS -------------------------------------------------------------------------------------------------
mms : : message_store & get_message_store ( ) { return m_message_store ; } ;
const mms : : message_store & get_message_store ( ) const { return m_message_store ; } ;
mms : : multisig_wallet_state get_multisig_wallet_state ( ) const ;
2018-07-03 02:33:11 +00:00
bool lock_keys_file ( ) ;
bool unlock_keys_file ( ) ;
bool is_keys_file_locked ( ) const ;
2018-07-08 20:12:33 +00:00
void change_password ( const std : : string & filename , const epee : : wipeable_string & original_password , const epee : : wipeable_string & new_password ) ;
2018-09-29 20:18:08 +00:00
void set_tx_notify ( const std : : shared_ptr < tools : : Notify > & notify ) { m_tx_notify = notify ; }
2018-10-25 23:02:42 +00:00
bool is_tx_spendtime_unlocked ( uint64_t unlock_time , uint64_t block_height ) const ;
2018-11-12 03:31:46 +00:00
void hash_m_transfer ( const transfer_details & transfer , crypto : : hash & hash ) const ;
uint64_t hash_m_transfers ( int64_t transfer_height , crypto : : hash & hash ) const ;
void finish_rescan_bc_keep_key_images ( uint64_t transfer_height , const crypto : : hash & hash ) ;
2019-04-03 21:34:16 +00:00
void enable_dns ( bool enable ) { m_use_dns = enable ; }
2019-04-13 09:19:38 +00:00
void set_offline ( bool offline = true ) ;
2018-10-25 23:02:42 +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
uint64_t credits ( ) const { return m_rpc_payment_state . credits ; }
void credit_report ( uint64_t & expected_spent , uint64_t & discrepancy ) const { expected_spent = m_rpc_payment_state . expected_spent ; discrepancy = m_rpc_payment_state . discrepancy ; }
2020-01-17 22:09:39 +00:00
static std : : string get_default_daemon_address ( ) { CRITICAL_REGION_LOCAL ( default_daemon_address_lock ) ; return default_daemon_address ; }
2014-03-03 22:07:58 +00:00
private :
2014-10-18 17:41:05 +00:00
/*!
2014-10-18 19:38:21 +00:00
* \ brief Stores wallet information to wallet file .
* \ param keys_file_name Name of wallet file
* \ param password Password of wallet file
2015-05-31 14:34:55 +00:00
* \ param watch_only true to save only view key , false to save both spend and view keys
2014-10-18 19:38:21 +00:00
* \ return Whether it was successful .
2014-10-18 17:41:05 +00:00
*/
2017-11-25 14:50:15 +00:00
bool store_keys ( const std : : string & keys_file_name , const epee : : wipeable_string & password , bool watch_only = false ) ;
2014-10-18 17:41:05 +00:00
/*!
2020-04-15 17:22:46 +00:00
* \ brief Load wallet keys information from wallet file .
2014-10-18 19:38:21 +00:00
* \ param keys_file_name Name of wallet file
* \ param password Password of wallet file
2014-10-18 17:41:05 +00:00
*/
2017-11-25 14:50:15 +00:00
bool load_keys ( const std : : string & keys_file_name , const epee : : wipeable_string & password ) ;
2020-04-15 17:22:46 +00:00
/*!
* \ brief Load wallet keys information from a string buffer .
* \ param keys_buf Keys buffer to load
* \ param password Password of keys buffer
*/
bool load_keys_buf ( const std : : string & keys_buf , const epee : : wipeable_string & password ) ;
bool load_keys_buf ( const std : : string & keys_buf , const epee : : wipeable_string & password , boost : : optional < crypto : : chacha_key > & keys_to_encrypt ) ;
2019-06-17 15:39:29 +00:00
void process_new_transaction ( const crypto : : hash & txid , const cryptonote : : transaction & tx , const std : : vector < uint64_t > & o_indices , uint64_t height , uint8_t block_version , uint64_t ts , bool miner_tx , bool pool , bool double_spend_seen , const tx_cache_data & tx_cache_data , std : : map < std : : pair < uint64_t , uint64_t > , size_t > * output_tracker_cache = NULL ) ;
2018-12-16 10:40:09 +00:00
bool should_skip_block ( const cryptonote : : block & b , uint64_t height ) const ;
2018-12-03 17:45:18 +00:00
void process_new_blockchain_entry ( const cryptonote : : block & b , const cryptonote : : block_complete_entry & bche , const parsed_block & parsed_block , const crypto : : hash & bl_id , uint64_t height , const std : : vector < tx_cache_data > & tx_cache_data , size_t tx_cache_data_offset , std : : map < std : : pair < uint64_t , uint64_t > , size_t > * output_tracker_cache = NULL ) ;
2019-03-17 10:31:44 +00:00
void detach_blockchain ( uint64_t height , std : : map < std : : pair < uint64_t , uint64_t > , size_t > * output_tracker_cache = NULL ) ;
2018-06-13 11:16:07 +00:00
void get_short_chain_history ( std : : list < crypto : : hash > & ids , uint64_t granularity = 1 ) const ;
2014-03-03 22:07:58 +00:00
bool clear ( ) ;
2018-11-12 03:31:46 +00:00
void clear_soft ( bool keep_key_images = false ) ;
wallet2: do not send an unnecessary last getblocks.bin call on refresh
The "everything refreshed" state was detected when a refresh call did
not return any new blocks. This can be detected without that extra
"empty" call by comparing the claimed node height to the height of
the last block retrieved. Doing this avoids that last call, saves
some bandwidth, and makes the common refresh case use only one call
rather than two.
As a side effect, it prevents an information leak reported by
Tramèr et al: if the wallet retrieves a set of blocks which includes
an output sent to the refreshing wallet, the wallet will prompt the
user for the password to decode the amount and calculate the key
image for the new output, and this will delay subsequent calls to
getblocks.bin, allowing a passive adversary to note the delay and
deduce when the wallet receives at least one output.
This can still happen if the wallet downloads more than 1000 blocks,
since this will be split in several calls, but then the most the
adversary can tell is which 1000 block section the user received
some monero (the adversary can estimate the heights of the blocks
by calculating how many "large" transfers are done, which will be
sections of blocks, the last of which will usually be below 1000,
but the size of the data should allow the actual number of blocks
sent to be determined fairly accurately).
This timing trick still be used via the subsequent scan for incoming
txes in the txpool, which will be fixed later.
2019-10-15 12:25:26 +00:00
void pull_blocks ( uint64_t start_height , uint64_t & blocks_start_height , const std : : list < crypto : : hash > & short_chain_history , std : : vector < cryptonote : : block_complete_entry > & blocks , std : : vector < cryptonote : : COMMAND_RPC_GET_BLOCKS_FAST : : block_output_indices > & o_indices , uint64_t & current_height ) ;
2018-04-15 23:16:02 +00:00
void pull_hashes ( uint64_t start_height , uint64_t & blocks_start_height , const std : : list < crypto : : hash > & short_chain_history , std : : vector < crypto : : hash > & hashes ) ;
2018-04-28 11:11:42 +00:00
void fast_refresh ( uint64_t stop_height , uint64_t & blocks_start_height , std : : list < crypto : : hash > & short_chain_history , bool force = false ) ;
wallet2: do not send an unnecessary last getblocks.bin call on refresh
The "everything refreshed" state was detected when a refresh call did
not return any new blocks. This can be detected without that extra
"empty" call by comparing the claimed node height to the height of
the last block retrieved. Doing this avoids that last call, saves
some bandwidth, and makes the common refresh case use only one call
rather than two.
As a side effect, it prevents an information leak reported by
Tramèr et al: if the wallet retrieves a set of blocks which includes
an output sent to the refreshing wallet, the wallet will prompt the
user for the password to decode the amount and calculate the key
image for the new output, and this will delay subsequent calls to
getblocks.bin, allowing a passive adversary to note the delay and
deduce when the wallet receives at least one output.
This can still happen if the wallet downloads more than 1000 blocks,
since this will be split in several calls, but then the most the
adversary can tell is which 1000 block section the user received
some monero (the adversary can estimate the heights of the blocks
by calculating how many "large" transfers are done, which will be
sections of blocks, the last of which will usually be below 1000,
but the size of the data should allow the actual number of blocks
sent to be determined fairly accurately).
This timing trick still be used via the subsequent scan for incoming
txes in the txpool, which will be fixed later.
2019-10-15 12:25:26 +00:00
void pull_and_parse_next_blocks ( uint64_t start_height , uint64_t & blocks_start_height , std : : list < crypto : : hash > & short_chain_history , const std : : vector < cryptonote : : block_complete_entry > & prev_blocks , const std : : vector < parsed_block > & prev_parsed_blocks , std : : vector < cryptonote : : block_complete_entry > & blocks , std : : vector < parsed_block > & parsed_blocks , bool & last , bool & error , std : : exception_ptr & exception ) ;
2018-12-03 17:45:18 +00:00
void process_parsed_blocks ( uint64_t start_height , const std : : vector < cryptonote : : block_complete_entry > & blocks , const std : : vector < parsed_block > & parsed_blocks , uint64_t & blocks_added , std : : map < std : : pair < uint64_t , uint64_t > , size_t > * output_tracker_cache = NULL ) ;
2018-08-10 12:15:40 +00:00
uint64_t select_transfers ( uint64_t needed_money , std : : vector < size_t > unused_transfers_indices , std : : vector < size_t > & selected_transfers ) const ;
2014-03-03 22:07:58 +00:00
bool prepare_file_names ( const std : : string & file_path ) ;
2017-02-27 20:26:17 +00:00
void process_unconfirmed ( const crypto : : hash & txid , const cryptonote : : transaction & tx , uint64_t height ) ;
2017-02-19 02:42:10 +00:00
void process_outgoing ( const crypto : : hash & txid , const cryptonote : : transaction & tx , uint64_t height , uint64_t ts , uint64_t spent , uint64_t received , uint32_t subaddr_account , const std : : set < uint32_t > & subaddr_indices ) ;
void add_unconfirmed_tx ( const cryptonote : : transaction & tx , uint64_t amount_in , const std : : vector < cryptonote : : tx_destination_entry > & dests , const crypto : : hash & payment_id , uint64_t change_amount , uint32_t subaddr_account , const std : : set < uint32_t > & subaddr_indices ) ;
2018-01-17 01:58:34 +00:00
void generate_genesis ( cryptonote : : block & b ) const ;
2015-05-27 18:00:57 +00:00
void check_genesis ( const crypto : : hash & genesis_hash ) const ; //throws
2017-12-07 13:27:11 +00:00
bool generate_chacha_key_from_secret_keys ( crypto : : chacha_key & key ) const ;
2018-07-08 20:12:33 +00:00
void generate_chacha_key_from_password ( const epee : : wipeable_string & pass , crypto : : chacha_key & key ) const ;
2015-11-22 12:13:59 +00:00
crypto : : hash get_payment_id ( const pending_tx & ptx ) const ;
2017-02-19 02:42:10 +00:00
void check_acc_out_precomp ( const cryptonote : : tx_out & o , const crypto : : key_derivation & derivation , const std : : vector < crypto : : key_derivation > & additional_derivations , size_t i , tx_scan_info_t & tx_scan_info ) const ;
2018-04-21 11:33:02 +00:00
void check_acc_out_precomp ( const cryptonote : : tx_out & o , const crypto : : key_derivation & derivation , const std : : vector < crypto : : key_derivation > & additional_derivations , size_t i , const is_out_data * is_out_data , tx_scan_info_t & tx_scan_info ) const ;
2018-07-08 10:01:13 +00:00
void check_acc_out_precomp_once ( const cryptonote : : tx_out & o , const crypto : : key_derivation & derivation , const std : : vector < crypto : : key_derivation > & additional_derivations , size_t i , const is_out_data * is_out_data , tx_scan_info_t & tx_scan_info , bool & already_seen ) const ;
2015-11-22 15:18:36 +00:00
void parse_block_round ( const cryptonote : : blobdata & blob , cryptonote : : block & bl , crypto : : hash & bl_id , bool & error ) const ;
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
uint64_t get_upper_transaction_weight_limit ( ) ;
std : : vector < uint64_t > get_unspent_amounts_vector ( bool strict ) ;
uint64_t get_dynamic_base_fee_estimate ( ) ;
2016-07-02 16:37:39 +00:00
float get_output_relatedness ( const transfer_details & td0 , const transfer_details & td1 ) const ;
2017-02-19 02:42:10 +00:00
std : : vector < size_t > pick_preferred_rct_inputs ( uint64_t needed_money , uint32_t subaddr_account , const std : : set < uint32_t > & subaddr_indices ) const ;
2016-09-26 22:11:10 +00:00
void set_spent ( size_t idx , uint64_t height ) ;
void set_unspent ( size_t idx ) ;
2019-05-10 17:20:20 +00:00
bool is_spent ( const transfer_details & td , bool strict = true ) const ;
bool is_spent ( size_t idx , bool strict = true ) const ;
2017-10-22 08:54:07 +00:00
void get_outs ( std : : vector < std : : vector < get_outs_entry > > & outs , const std : : vector < size_t > & selected_transfers , size_t fake_outputs_count ) ;
2020-01-10 15:25:29 +00:00
void get_outs ( std : : vector < std : : vector < get_outs_entry > > & outs , const std : : vector < size_t > & selected_transfers , size_t fake_outputs_count , std : : vector < uint64_t > & rct_offsets ) ;
2017-08-04 21:12:37 +00:00
bool tx_add_fake_output ( std : : vector < std : : vector < tools : : wallet2 : : get_outs_entry > > & outs , uint64_t global_index , const crypto : : public_key & tx_public_key , const rct : : key & mask , uint64_t real_index , bool unlocked ) const ;
2017-03-20 08:44:28 +00:00
bool should_pick_a_second_output ( bool use_rct , size_t n_transfers , const std : : vector < size_t > & unused_transfers_indices , const std : : vector < size_t > & unused_dust_indices ) const ;
std : : vector < size_t > get_only_rct ( const std : : vector < size_t > & unused_dust_indices , const std : : vector < size_t > & unused_transfers_indices ) const ;
2019-02-28 18:44:35 +00:00
void scan_output ( const cryptonote : : transaction & tx , bool miner_tx , const crypto : : public_key & tx_pub_key , size_t i , tx_scan_info_t & tx_scan_info , int & num_vouts_received , std : : unordered_map < cryptonote : : subaddress_index , uint64_t > & tx_money_got_in_outs , std : : vector < size_t > & outs , bool pool ) ;
2017-09-11 13:38:37 +00:00
void trim_hashchain ( ) ;
2017-08-13 14:29:31 +00:00
crypto : : key_image get_multisig_composite_key_image ( size_t n ) const ;
2018-11-12 17:46:00 +00:00
rct : : multisig_kLRki get_multisig_composite_kLRki ( size_t n , const std : : unordered_set < crypto : : public_key > & ignore_set , std : : unordered_set < rct : : key > & used_L , std : : unordered_set < rct : : key > & new_used_L ) const ;
2017-08-13 14:29:31 +00:00
rct : : multisig_kLRki get_multisig_kLRki ( size_t n , const rct : : key & k ) const ;
rct : : key get_multisig_k ( size_t idx , const std : : unordered_set < rct : : key > & used_L ) const ;
void update_multisig_rescan_info ( const std : : vector < std : : vector < rct : : key > > & multisig_k , const std : : vector < std : : vector < tools : : wallet2 : : multisig_info > > & info , size_t n ) ;
2018-02-27 08:30:59 +00:00
bool add_rings ( const crypto : : chacha_key & key , const cryptonote : : transaction_prefix & tx ) ;
bool add_rings ( const cryptonote : : transaction_prefix & tx ) ;
bool remove_rings ( const cryptonote : : transaction_prefix & tx ) ;
bool get_ring ( const crypto : : chacha_key & key , const crypto : : key_image & key_image , std : : vector < uint64_t > & outs ) ;
2018-04-27 10:08:24 +00:00
crypto : : chacha_key get_ringdb_key ( ) ;
2018-07-08 20:12:33 +00:00
void setup_keys ( const epee : : wipeable_string & password ) ;
2019-03-13 21:51:41 +00:00
size_t get_transfer_details ( const crypto : : key_image & ki ) const ;
2014-03-03 22:07:58 +00:00
2018-08-23 21:50:53 +00:00
void register_devices ( ) ;
hw : : device & lookup_device ( const std : : string & device_descriptor ) ;
2018-03-23 15:43:38 +00:00
bool get_rct_distribution ( uint64_t & start_height , std : : vector < uint64_t > & distribution ) ;
2018-02-19 11:15:15 +00:00
2018-03-13 19:38:52 +00:00
uint64_t get_segregation_fork_height ( ) const ;
2018-07-12 09:55:52 +00:00
void unpack_multisig_info ( const std : : vector < std : : string > & info ,
std : : vector < crypto : : public_key > & public_keys ,
std : : vector < crypto : : secret_key > & secret_keys ) const ;
bool unpack_extra_multisig_info ( const std : : vector < std : : string > & info ,
std : : vector < crypto : : public_key > & signers ,
std : : unordered_set < crypto : : public_key > & pkeys ) const ;
2018-03-13 19:38:52 +00:00
2018-04-21 11:33:02 +00:00
void cache_tx_data ( const cryptonote : : transaction & tx , const crypto : : hash & txid , tx_cache_data & tx_cache_data ) const ;
2018-12-03 17:45:18 +00:00
std : : shared_ptr < std : : map < std : : pair < uint64_t , uint64_t > , size_t > > create_output_tracker_cache ( ) const ;
2018-04-21 11:33:02 +00:00
2019-03-26 00:20:46 +00:00
void init_type ( hw : : device : : device_type device_type ) ;
2018-09-03 10:48:28 +00:00
void setup_new_blockchain ( ) ;
2018-09-03 11:13:23 +00:00
void create_keys_file ( const std : : string & wallet_ , bool watch_only , const epee : : wipeable_string & password , bool create_address_file ) ;
2018-09-03 10:48:28 +00:00
2018-11-11 19:07:25 +00:00
wallet_device_callback * get_device_callback ( ) ;
2019-02-23 14:28:18 +00:00
void on_device_button_request ( uint64_t code ) ;
2019-04-05 19:47:24 +00:00
void on_device_button_pressed ( ) ;
2019-02-23 14:28:18 +00:00
boost : : optional < epee : : wipeable_string > on_device_pin_request ( ) ;
2020-04-07 16:25:25 +00:00
boost : : optional < epee : : wipeable_string > on_device_passphrase_request ( bool & on_device ) ;
2019-02-23 14:28:18 +00:00
void on_device_progress ( const hw : : device_progress & event ) ;
2018-11-11 19:07:25 +00:00
2018-12-30 01:32:20 +00:00
std : : string get_rpc_status ( const std : : string & s ) const ;
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
void throw_on_rpc_response_error ( bool r , const epee : : json_rpc : : error & error , const std : : string & status , const char * method ) const ;
std : : string get_client_signature ( ) const ;
void check_rpc_cost ( const char * call , uint64_t post_call_credits , uint64_t pre_credits , double expected_cost ) ;
2018-12-30 01:32:20 +00:00
2020-04-27 16:47:53 +00:00
bool should_expand ( const cryptonote : : subaddress_index & index ) const ;
2020-05-13 00:25:56 +00:00
bool spends_one_of_ours ( const cryptonote : : transaction & tx ) const ;
2020-04-27 16:47:53 +00:00
2014-03-03 22:07:58 +00:00
cryptonote : : account_base m_account ;
2017-02-05 22:48:03 +00:00
boost : : optional < epee : : net_utils : : http : : login > m_daemon_login ;
2014-03-03 22:07:58 +00:00
std : : string m_daemon_address ;
std : : string m_wallet_file ;
std : : string m_keys_file ;
2018-10-28 13:46:58 +00:00
std : : string m_mms_file ;
2020-04-15 17:22:46 +00:00
const std : : unique_ptr < epee : : net_utils : : http : : abstract_http_client > m_http_client ;
2017-09-11 13:38:37 +00:00
hashchain m_blockchain ;
2014-04-02 16:00:17 +00:00
std : : unordered_map < crypto : : hash , unconfirmed_transfer_details > m_unconfirmed_txs ;
2015-11-15 21:59:40 +00:00
std : : unordered_map < crypto : : hash , confirmed_transfer_details > m_confirmed_txs ;
2017-09-22 12:57:20 +00:00
std : : unordered_multimap < crypto : : hash , pool_payment_details > m_unconfirmed_payments ;
2015-08-19 19:59:44 +00:00
std : : unordered_map < crypto : : hash , crypto : : secret_key > m_tx_keys ;
2017-09-11 13:38:37 +00:00
cryptonote : : checkpoints m_checkpoints ;
2017-02-19 02:42:10 +00:00
std : : unordered_map < crypto : : hash , std : : vector < crypto : : secret_key > > m_additional_tx_keys ;
2014-03-03 22:07:58 +00:00
transfer_container m_transfers ;
2014-05-03 16:19:43 +00:00
payment_container m_payments ;
2014-03-03 22:07:58 +00:00
std : : unordered_map < crypto : : key_image , size_t > m_key_images ;
2016-11-07 18:50:05 +00:00
std : : unordered_map < crypto : : public_key , size_t > m_pub_keys ;
2014-03-03 22:07:58 +00:00
cryptonote : : account_public_address m_account_public_address ;
2017-02-19 02:42:10 +00:00
std : : unordered_map < crypto : : public_key , cryptonote : : subaddress_index > m_subaddresses ;
std : : vector < std : : vector < std : : string > > m_subaddress_labels ;
2016-04-20 17:19:42 +00:00
std : : unordered_map < crypto : : hash , std : : string > m_tx_notes ;
2017-10-08 07:15:06 +00:00
std : : unordered_map < std : : string , std : : string > m_attributes ;
2016-12-12 20:39:29 +00:00
std : : vector < tools : : wallet2 : : address_book_row > m_address_book ;
2017-12-15 03:08:36 +00:00
std : : pair < std : : map < std : : string , std : : string > , std : : vector < std : : string > > m_account_tags ;
2018-07-18 21:24:53 +00:00
uint64_t m_upper_transaction_weight_limit ; //TODO: auto-calc this value or request from daemon, now use some fixed value
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
const std : : vector < std : : vector < tools : : wallet2 : : multisig_info > > * m_multisig_rescan_info ;
2017-08-13 14:29:31 +00:00
const std : : vector < std : : vector < rct : : key > > * m_multisig_rescan_k ;
2018-12-25 13:59:44 +00:00
std : : unordered_map < crypto : : public_key , crypto : : key_image > m_cold_key_images ;
2014-03-20 11:46:11 +00:00
std : : atomic < bool > m_run ;
2014-04-02 16:00:17 +00:00
2019-04-13 09:19:38 +00:00
boost : : recursive_mutex m_daemon_rpc_mutex ;
2015-11-27 17:25:15 +00:00
2018-08-10 12:15:40 +00:00
bool m_trusted_daemon ;
2014-04-02 16:00:17 +00:00
i_wallet2_callback * m_callback ;
2018-08-16 08:31:48 +00:00
hw : : device : : device_type m_key_device_type ;
2018-02-16 11:04:04 +00:00
cryptonote : : network_type m_nettype ;
2018-07-06 06:42:08 +00:00
uint64_t m_kdf_rounds ;
2014-10-18 17:41:05 +00:00
std : : string seed_language ; /*!< Language of the mnemonics (seed). */
bool is_old_file_format ; /*!< Whether the wallet file is of an old file format */
2015-05-31 14:34:55 +00:00
bool m_watch_only ; /*!< no spend key */
2017-05-28 11:18:51 +00:00
bool m_multisig ; /*!< if > 1 spend secret key will not match spend public key */
uint32_t m_multisig_threshold ;
2017-08-13 14:29:31 +00:00
std : : vector < crypto : : public_key > m_multisig_signers ;
2018-07-12 09:55:52 +00:00
//in case of general M/N multisig wallet we should perform N - M + 1 key exchange rounds and remember how many rounds are passed.
uint32_t m_multisig_rounds_passed ;
std : : vector < crypto : : public_key > m_multisig_derivations ;
2015-07-18 21:03:35 +00:00
bool m_always_confirm_transfers ;
2016-12-23 12:04:54 +00:00
bool m_print_ring_members ;
2015-11-22 12:26:27 +00:00
bool m_store_tx_info ; /*!< request txkey to be returned in RPC, and store in the wallet cache file */
2015-10-30 21:16:51 +00:00
uint32_t m_default_mixin ;
2016-09-16 10:50:52 +00:00
uint32_t m_default_priority ;
2015-11-22 19:03:10 +00:00
RefreshType m_refresh_type ;
2015-11-28 12:38:58 +00:00
bool m_auto_refresh ;
2018-06-13 11:16:07 +00:00
bool m_first_refresh_done ;
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
uint64_t m_refresh_from_block_height ;
2018-01-23 14:42:11 +00:00
// If m_refresh_from_block_height is explicitly set to zero we need this to differentiate it from the case that
// m_refresh_from_block_height was defaulted to zero.*/
bool m_explicit_refresh_from_block_height ;
2018-03-31 13:20:48 +00:00
bool m_confirm_non_default_ring_size ;
2018-09-02 09:59:01 +00:00
AskPasswordType m_ask_password ;
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
uint32_t m_min_output_count ;
uint64_t m_min_output_value ;
2017-03-24 21:56:58 +00:00
bool m_merge_destinations ;
2017-08-26 15:23:54 +00:00
bool m_confirm_backlog ;
2017-09-18 11:46:33 +00:00
uint32_t m_confirm_backlog_threshold ;
2018-01-14 23:36:13 +00:00
bool m_confirm_export_overwrite ;
2018-01-15 03:05:16 +00:00
bool m_auto_low_priority ;
2018-02-19 10:23:23 +00:00
bool m_segregate_pre_fork_outputs ;
bool m_key_reuse_mitigation2 ;
2018-03-13 19:38:52 +00:00
uint64_t m_segregation_height ;
2018-06-28 02:31:50 +00:00
bool m_ignore_fractional_outputs ;
2019-10-02 04:04:24 +00:00
uint64_t m_ignore_outputs_above ;
uint64_t m_ignore_outputs_below ;
2018-12-03 15:32:14 +00:00
bool m_track_uses ;
2019-05-06 08:44:50 +00:00
uint32_t m_inactivity_lock_timeout ;
2019-03-30 19:21:30 +00:00
BackgroundMiningSetupType m_setup_background_mining ;
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 m_persistent_rpc_client_id ;
float m_auto_mine_for_rpc_payment_threshold ;
2017-06-04 00:56:51 +00:00
bool m_is_initialized ;
2017-01-07 19:23:57 +00:00
NodeRPCProxy m_node_rpc_proxy ;
2017-03-21 10:30:25 +00:00
std : : unordered_set < crypto : : hash > m_scanned_pool_txs [ 2 ] ;
2017-10-21 17:31:30 +00:00
size_t m_subaddress_lookahead_major , m_subaddress_lookahead_minor ;
2018-08-23 22:50:31 +00:00
std : : string m_device_name ;
2018-11-11 23:07:25 +00:00
std : : string m_device_derivation_path ;
2018-11-12 03:13:54 +00:00
uint64_t m_device_last_key_image_sync ;
2019-04-03 21:34:16 +00:00
bool m_use_dns ;
2019-04-13 09:19:38 +00:00
bool m_offline ;
2019-06-02 08:27:16 +00:00
uint32_t m_rpc_version ;
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
crypto : : secret_key m_rpc_client_secret_key ;
rpc_payment_state_t m_rpc_payment_state ;
uint64_t m_credits_target ;
2017-08-04 20:36:27 +00:00
2018-08-23 21:50:53 +00:00
// Aux transaction data from device
std : : unordered_map < crypto : : hash , std : : string > m_tx_device ;
2017-08-04 20:36:27 +00:00
// Light wallet
bool m_light_wallet ; /* sends view key to daemon for scanning */
uint64_t m_light_wallet_scanned_block_height ;
uint64_t m_light_wallet_blockchain_height ;
uint64_t m_light_wallet_per_kb_fee = FEE_PER_KB ;
bool m_light_wallet_connected ;
uint64_t m_light_wallet_balance ;
uint64_t m_light_wallet_unlocked_balance ;
// Light wallet info needed to populate m_payment requires 2 separate api calls (get_address_txs and get_unspent_outs)
// We save the info from the first call in m_light_wallet_address_txs for easier lookup.
std : : unordered_map < crypto : : hash , address_tx > m_light_wallet_address_txs ;
// store calculated key image for faster lookup
std : : unordered_map < crypto : : public_key , std : : map < uint64_t , crypto : : key_image > > m_key_image_cache ;
2018-02-18 10:47:25 +00:00
std : : string m_ring_database ;
bool m_ring_history_saved ;
2018-02-27 08:30:59 +00:00
std : : unique_ptr < ringdb > m_ringdb ;
2018-04-27 10:08:24 +00:00
boost : : optional < crypto : : chacha_key > m_ringdb_key ;
2018-06-02 12:06:41 +00:00
uint64_t m_last_block_reward ;
2018-06-12 06:29:33 +00:00
std : : unique_ptr < tools : : file_locker > m_keys_file_locker ;
2018-10-28 13:46:58 +00:00
mms : : message_store m_message_store ;
bool m_original_keys_available ;
cryptonote : : account_public_address m_original_address ;
crypto : : secret_key m_original_view_secret_key ;
2018-07-08 20:12:33 +00:00
crypto : : chacha_key m_cache_key ;
boost : : optional < epee : : wipeable_string > m_encrypt_keys_after_refresh ;
2019-12-14 21:15:02 +00:00
boost : : mutex m_decrypt_keys_lock ;
unsigned int m_decrypt_keys_lockers ;
2018-07-08 20:12:33 +00:00
2018-09-02 09:59:01 +00:00
bool m_unattended ;
2018-08-23 21:50:53 +00:00
bool m_devices_registered ;
2018-09-29 20:18:08 +00:00
std : : shared_ptr < tools : : Notify > m_tx_notify ;
2018-11-11 19:07:25 +00:00
std : : unique_ptr < wallet_device_callback > m_device_callback ;
2019-04-10 09:20:12 +00:00
ExportFormat m_export_format ;
2020-01-17 22:09:39 +00:00
static boost : : mutex default_daemon_address_lock ;
static std : : string default_daemon_address ;
2014-03-03 22:07: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
BOOST_CLASS_VERSION ( tools : : wallet2 , 29 )
2019-03-13 21:51:41 +00:00
BOOST_CLASS_VERSION ( tools : : wallet2 : : transfer_details , 12 )
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
BOOST_CLASS_VERSION ( tools : : wallet2 : : multisig_info , 1 )
2017-08-13 14:29:31 +00:00
BOOST_CLASS_VERSION ( tools : : wallet2 : : multisig_info : : LR , 0 )
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
BOOST_CLASS_VERSION ( tools : : wallet2 : : multisig_tx_set , 1 )
2020-01-09 09:01:56 +00:00
BOOST_CLASS_VERSION ( tools : : wallet2 : : payment_details , 5 )
2017-09-22 12:57:20 +00:00
BOOST_CLASS_VERSION ( tools : : wallet2 : : pool_payment_details , 1 )
2018-03-14 19:13:55 +00:00
BOOST_CLASS_VERSION ( tools : : wallet2 : : unconfirmed_transfer_details , 8 )
BOOST_CLASS_VERSION ( tools : : wallet2 : : confirmed_transfer_details , 6 )
2019-11-19 16:30:19 +00:00
BOOST_CLASS_VERSION ( tools : : wallet2 : : address_book_row , 18 )
2017-12-28 13:50:10 +00:00
BOOST_CLASS_VERSION ( tools : : wallet2 : : reserve_proof_entry , 0 )
2016-12-30 13:51:43 +00:00
BOOST_CLASS_VERSION ( tools : : wallet2 : : unsigned_tx_set , 0 )
2018-12-25 13:59:44 +00:00
BOOST_CLASS_VERSION ( tools : : wallet2 : : signed_tx_set , 1 )
2019-03-13 11:32:44 +00:00
BOOST_CLASS_VERSION ( tools : : wallet2 : : tx_construction_data , 4 )
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
BOOST_CLASS_VERSION ( tools : : wallet2 : : pending_tx , 3 )
2017-08-13 14:29:31 +00:00
BOOST_CLASS_VERSION ( tools : : wallet2 : : multisig_sig , 0 )
2014-03-03 22:07:58 +00:00
namespace boost
{
namespace serialization
{
2016-06-15 22:37:13 +00:00
template < class Archive >
2016-12-16 09:10:03 +00:00
inline typename std : : enable_if < ! Archive : : is_loading : : value , void > : : type initialize_transfer_details ( Archive & a , tools : : wallet2 : : transfer_details & x , const boost : : serialization : : version_type ver )
2016-06-15 22:37:13 +00:00
{
}
2016-12-16 09:10:03 +00:00
template < class Archive >
inline typename std : : enable_if < Archive : : is_loading : : value , void > : : type initialize_transfer_details ( Archive & a , tools : : wallet2 : : transfer_details & x , const boost : : serialization : : version_type ver )
2016-06-15 22:37:13 +00:00
{
2016-06-16 22:58:54 +00:00
if ( ver < 1 )
{
x . m_mask = rct : : identity ( ) ;
x . m_amount = x . m_tx . vout [ x . m_internal_output_index ] . amount ;
}
if ( ver < 2 )
{
x . m_spent_height = 0 ;
}
2016-08-12 17:45:07 +00:00
if ( ver < 4 )
{
x . m_rct = x . m_tx . vout [ x . m_internal_output_index ] . amount = = 0 ;
}
2016-11-13 11:34:43 +00:00
if ( ver < 6 )
{
x . m_key_image_known = true ;
}
2016-12-09 18:21:21 +00:00
if ( ver < 7 )
{
x . m_pk_index = 0 ;
}
2017-02-19 02:42:10 +00:00
if ( ver < 8 )
{
x . m_subaddr_index = { } ;
}
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
if ( ver < 9 )
{
x . m_key_image_partial = false ;
2017-08-13 14:29:31 +00:00
x . m_multisig_k . clear ( ) ;
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
x . m_multisig_info . clear ( ) ;
}
2018-10-24 18:24:11 +00:00
if ( ver < 10 )
{
2018-12-25 13:59:44 +00:00
x . m_key_image_request = false ;
2018-10-24 18:24:11 +00:00
}
2019-03-13 21:51:41 +00:00
if ( ver < 12 )
{
x . m_frozen = false ;
}
2016-06-15 22:37:13 +00:00
}
2014-03-03 22:07:58 +00:00
template < class Archive >
inline void serialize ( Archive & a , tools : : wallet2 : : transfer_details & x , const boost : : serialization : : version_type ver )
{
a & x . m_block_height ;
a & x . m_global_output_index ;
a & x . m_internal_output_index ;
2016-08-06 18:19:25 +00:00
if ( ver < 3 )
{
cryptonote : : transaction tx ;
a & tx ;
x . m_tx = ( const cryptonote : : transaction_prefix & ) tx ;
x . m_txid = cryptonote : : get_transaction_hash ( tx ) ;
}
else
{
a & x . m_tx ;
}
2014-03-03 22:07:58 +00:00
a & x . m_spent ;
a & x . m_key_image ;
2016-06-15 22:37:13 +00:00
if ( ver < 1 )
{
// ensure mask and amount are set
2016-06-16 22:58:54 +00:00
initialize_transfer_details ( a , x , ver ) ;
2016-06-15 22:37:13 +00:00
return ;
}
a & x . m_mask ;
a & x . m_amount ;
2016-06-16 22:58:54 +00:00
if ( ver < 2 )
{
initialize_transfer_details ( a , x , ver ) ;
return ;
}
a & x . m_spent_height ;
2016-08-06 18:19:25 +00:00
if ( ver < 3 )
2016-08-12 17:45:07 +00:00
{
initialize_transfer_details ( a , x , ver ) ;
2016-08-06 18:19:25 +00:00
return ;
2016-08-12 17:45:07 +00:00
}
2016-08-06 18:19:25 +00:00
a & x . m_txid ;
2016-08-12 17:45:07 +00:00
if ( ver < 4 )
{
initialize_transfer_details ( a , x , ver ) ;
return ;
}
a & x . m_rct ;
2016-11-07 18:50:05 +00:00
if ( ver < 5 )
2016-11-13 11:34:43 +00:00
{
initialize_transfer_details ( a , x , ver ) ;
2016-11-07 18:50:05 +00:00
return ;
2016-11-13 11:34:43 +00:00
}
if ( ver < 6 )
{
// v5 did not properly initialize
uint8_t u ;
a & u ;
x . m_key_image_known = true ;
return ;
}
2016-11-07 18:50:05 +00:00
a & x . m_key_image_known ;
2016-12-09 18:21:21 +00:00
if ( ver < 7 )
{
initialize_transfer_details ( a , x , ver ) ;
return ;
}
a & x . m_pk_index ;
2017-02-19 02:42:10 +00:00
if ( ver < 8 )
{
initialize_transfer_details ( a , x , ver ) ;
return ;
}
a & x . m_subaddr_index ;
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
if ( ver < 9 )
{
initialize_transfer_details ( a , x , ver ) ;
return ;
}
a & x . m_multisig_info ;
a & x . m_multisig_k ;
a & x . m_key_image_partial ;
2018-10-24 18:24:11 +00:00
if ( ver < 10 )
{
initialize_transfer_details ( a , x , ver ) ;
return ;
}
2018-12-25 13:59:44 +00:00
a & x . m_key_image_request ;
2018-12-03 15:32:14 +00:00
if ( ver < 11 )
2019-03-13 21:51:41 +00:00
{
initialize_transfer_details ( a , x , ver ) ;
2018-12-03 15:32:14 +00:00
return ;
2019-03-13 21:51:41 +00:00
}
2018-12-03 15:32:14 +00:00
a & x . m_uses ;
2019-03-13 21:51:41 +00:00
if ( ver < 12 )
{
initialize_transfer_details ( a , x , ver ) ;
return ;
}
a & x . m_frozen ;
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
}
template < class Archive >
2017-08-13 14:29:31 +00:00
inline void serialize ( Archive & a , tools : : wallet2 : : multisig_info : : LR & x , const boost : : serialization : : version_type ver )
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
{
a & x . m_L ;
a & x . m_R ;
}
2017-08-13 14:29:31 +00:00
template < class Archive >
inline void serialize ( Archive & a , tools : : wallet2 : : multisig_info & x , const boost : : serialization : : version_type ver )
{
a & x . m_signer ;
a & x . m_LR ;
a & x . m_partial_key_images ;
}
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
template < class Archive >
inline void serialize ( Archive & a , tools : : wallet2 : : multisig_tx_set & x , const boost : : serialization : : version_type ver )
{
a & x . m_ptx ;
a & x . m_signers ;
2014-03-03 22:07:58 +00:00
}
2014-04-02 16:00:17 +00:00
template < class Archive >
inline void serialize ( Archive & a , tools : : wallet2 : : unconfirmed_transfer_details & x , const boost : : serialization : : version_type ver )
{
a & x . m_change ;
a & x . m_sent_time ;
2016-08-06 18:19:25 +00:00
if ( ver < 5 )
{
cryptonote : : transaction tx ;
a & tx ;
x . m_tx = ( const cryptonote : : transaction_prefix & ) tx ;
}
else
{
a & x . m_tx ;
}
2015-12-20 13:51:55 +00:00
if ( ver < 1 )
2015-11-22 12:13:59 +00:00
return ;
a & x . m_dests ;
a & x . m_payment_id ;
2016-01-29 19:44:48 +00:00
if ( ver < 2 )
return ;
a & x . m_state ;
2016-04-19 20:18:43 +00:00
if ( ver < 3 )
return ;
a & x . m_timestamp ;
2016-06-15 22:37:13 +00:00
if ( ver < 4 )
return ;
a & x . m_amount_in ;
a & x . m_amount_out ;
2016-11-02 23:11:30 +00:00
if ( ver < 6 )
{
// v<6 may not have change accumulated in m_amount_out, which is a pain,
// as it's readily understood to be sum of outputs.
// We convert it to include change from v6
if ( ! typename Archive : : is_saving ( ) & & x . m_change ! = ( uint64_t ) - 1 )
x . m_amount_out + = x . m_change ;
}
2017-02-19 02:42:10 +00:00
if ( ver < 7 )
2017-10-23 10:53:49 +00:00
{
x . m_subaddr_account = 0 ;
2017-02-19 02:42:10 +00:00
return ;
2017-10-23 10:53:49 +00:00
}
2017-02-19 02:42:10 +00:00
a & x . m_subaddr_account ;
a & x . m_subaddr_indices ;
2018-03-14 19:13:55 +00:00
if ( ver < 8 )
return ;
a & x . m_rings ;
2014-04-02 16:00:17 +00:00
}
2015-11-15 21:59:40 +00:00
template < class Archive >
inline void serialize ( Archive & a , tools : : wallet2 : : confirmed_transfer_details & x , const boost : : serialization : : version_type ver )
{
a & x . m_amount_in ;
a & x . m_amount_out ;
a & x . m_change ;
a & x . m_block_height ;
2015-12-20 13:51:55 +00:00
if ( ver < 1 )
2015-11-22 12:13:59 +00:00
return ;
a & x . m_dests ;
a & x . m_payment_id ;
2016-04-19 20:18:43 +00:00
if ( ver < 2 )
return ;
a & x . m_timestamp ;
2016-11-02 23:11:30 +00:00
if ( ver < 3 )
{
// v<3 may not have change accumulated in m_amount_out, which is a pain,
// as it's readily understood to be sum of outputs. Whether it got added
// or not depends on whether it came from a unconfirmed_transfer_details
// (not included) or not (included). We can't reliably tell here, so we
// check whether either yields a "negative" fee, or use the other if so.
// We convert it to include change from v3
if ( ! typename Archive : : is_saving ( ) & & x . m_change ! = ( uint64_t ) - 1 )
{
if ( x . m_amount_in > ( x . m_amount_out + x . m_change ) )
x . m_amount_out + = x . m_change ;
}
}
2017-07-25 15:28:48 +00:00
if ( ver < 4 )
{
if ( ! typename Archive : : is_saving ( ) )
x . m_unlock_time = 0 ;
return ;
}
a & x . m_unlock_time ;
2017-02-19 02:42:10 +00:00
if ( ver < 5 )
2017-10-23 10:53:49 +00:00
{
x . m_subaddr_account = 0 ;
2017-02-19 02:42:10 +00:00
return ;
2017-10-23 10:53:49 +00:00
}
2017-02-19 02:42:10 +00:00
a & x . m_subaddr_account ;
a & x . m_subaddr_indices ;
2018-03-14 19:13:55 +00:00
if ( ver < 6 )
return ;
a & x . m_rings ;
2015-11-15 21:59:40 +00:00
}
2014-05-03 16:19:43 +00:00
template < class Archive >
inline void serialize ( Archive & a , tools : : wallet2 : : payment_details & x , const boost : : serialization : : version_type ver )
{
a & x . m_tx_hash ;
a & x . m_amount ;
a & x . m_block_height ;
a & x . m_unlock_time ;
2016-04-19 20:18:43 +00:00
if ( ver < 1 )
return ;
a & x . m_timestamp ;
2017-02-19 02:42:10 +00:00
if ( ver < 2 )
2017-10-23 10:53:49 +00:00
{
2018-07-19 16:49:15 +00:00
x . m_coinbase = false ;
2017-10-23 10:53:49 +00:00
x . m_subaddr_index = { } ;
2017-02-19 02:42:10 +00:00
return ;
2017-10-23 10:53:49 +00:00
}
2017-02-19 02:42:10 +00:00
a & x . m_subaddr_index ;
2018-01-14 04:37:57 +00:00
if ( ver < 3 )
{
2018-07-19 16:49:15 +00:00
x . m_coinbase = false ;
2018-01-14 04:37:57 +00:00
x . m_fee = 0 ;
return ;
}
a & x . m_fee ;
2018-07-19 16:49:15 +00:00
if ( ver < 4 )
{
x . m_coinbase = false ;
return ;
}
a & x . m_coinbase ;
2020-01-09 09:01:56 +00:00
if ( ver < 5 )
return ;
a & x . m_amounts ;
2015-11-22 12:13:59 +00:00
}
2017-09-22 12:57:20 +00:00
template < class Archive >
inline void serialize ( Archive & a , tools : : wallet2 : : pool_payment_details & x , const boost : : serialization : : version_type ver )
{
a & x . m_pd ;
a & x . m_double_spend_seen ;
}
2016-12-11 23:42:46 +00:00
template < class Archive >
inline void serialize ( Archive & a , tools : : wallet2 : : address_book_row & x , const boost : : serialization : : version_type ver )
{
a & x . m_address ;
2019-11-19 16:30:19 +00:00
if ( ver < 18 )
{
crypto : : hash payment_id ;
a & payment_id ;
x . m_has_payment_id = ! ( payment_id = = crypto : : null_hash ) ;
if ( x . m_has_payment_id )
{
bool is_long = false ;
for ( int i = 8 ; i < 32 ; + + i )
is_long | = payment_id . data [ i ] ;
if ( is_long )
{
MWARNING ( " Long payment ID ignored on address book load " ) ;
x . m_payment_id = crypto : : null_hash8 ;
x . m_has_payment_id = false ;
}
else
memcpy ( x . m_payment_id . data , payment_id . data , 8 ) ;
}
}
2016-12-11 23:42:46 +00:00
a & x . m_description ;
2017-02-19 02:42:10 +00:00
if ( ver < 17 )
2017-10-23 10:53:49 +00:00
{
x . m_is_subaddress = false ;
2017-02-19 02:42:10 +00:00
return ;
2017-10-23 10:53:49 +00:00
}
2017-02-19 02:42:10 +00:00
a & x . m_is_subaddress ;
2019-11-19 16:30:19 +00:00
if ( ver < 18 )
return ;
a & x . m_has_payment_id ;
if ( x . m_has_payment_id )
a & x . m_payment_id ;
2016-12-11 23:42:46 +00:00
}
2017-12-28 13:50:10 +00:00
template < class Archive >
inline void serialize ( Archive & a , tools : : wallet2 : : reserve_proof_entry & x , const boost : : serialization : : version_type ver )
{
a & x . txid ;
a & x . index_in_tx ;
a & x . shared_secret ;
a & x . key_image ;
a & x . shared_secret_sig ;
a & x . key_image_sig ;
}
2016-12-30 13:51:43 +00:00
template < class Archive >
inline void serialize ( Archive & a , tools : : wallet2 : : unsigned_tx_set & x , const boost : : serialization : : version_type ver )
{
a & x . txes ;
a & x . transfers ;
}
template < class Archive >
inline void serialize ( Archive & a , tools : : wallet2 : : signed_tx_set & x , const boost : : serialization : : version_type ver )
{
a & x . ptx ;
a & x . key_images ;
2018-12-25 13:59:44 +00:00
if ( ver < 1 )
return ;
a & x . tx_key_images ;
2016-12-30 13:51:43 +00:00
}
template < class Archive >
inline void serialize ( Archive & a , tools : : wallet2 : : tx_construction_data & x , const boost : : serialization : : version_type ver )
{
a & x . sources ;
a & x . change_dts ;
a & x . splitted_dsts ;
2017-10-22 08:54:07 +00:00
if ( ver < 2 )
{
// load list to vector
std : : list < size_t > selected_transfers ;
a & selected_transfers ;
x . selected_transfers . clear ( ) ;
x . selected_transfers . reserve ( selected_transfers . size ( ) ) ;
for ( size_t t : selected_transfers )
x . selected_transfers . push_back ( t ) ;
}
2016-12-30 13:51:43 +00:00
a & x . extra ;
a & x . unlock_time ;
a & x . use_rct ;
a & x . dests ;
2017-02-19 02:42:10 +00:00
if ( ver < 1 )
2017-10-23 10:53:49 +00:00
{
x . subaddr_account = 0 ;
2017-02-19 02:42:10 +00:00
return ;
2017-10-23 10:53:49 +00:00
}
2017-02-19 02:42:10 +00:00
a & x . subaddr_account ;
a & x . subaddr_indices ;
2017-10-22 08:54:07 +00:00
if ( ver < 2 )
2019-03-13 11:32:44 +00:00
{
if ( ! typename Archive : : is_saving ( ) )
x . rct_config = { rct : : RangeProofBorromean , 0 } ;
2017-10-22 08:54:07 +00:00
return ;
2019-03-13 11:32:44 +00:00
}
2017-10-22 08:54:07 +00:00
a & x . selected_transfers ;
2018-06-07 11:28:23 +00:00
if ( ver < 3 )
2019-03-13 11:32:44 +00:00
{
if ( ! typename Archive : : is_saving ( ) )
x . rct_config = { rct : : RangeProofBorromean , 0 } ;
2018-06-07 11:28:23 +00:00
return ;
2019-03-13 11:32:44 +00:00
}
if ( ver < 4 )
{
bool use_bulletproofs = x . rct_config . range_proof_type ! = rct : : RangeProofBorromean ;
a & use_bulletproofs ;
if ( ! typename Archive : : is_saving ( ) )
x . rct_config = { use_bulletproofs ? rct : : RangeProofBulletproof : rct : : RangeProofBorromean , 0 } ;
return ;
}
a & x . rct_config ;
2016-12-30 13:51:43 +00:00
}
2017-08-13 14:29:31 +00:00
template < class Archive >
inline void serialize ( Archive & a , tools : : wallet2 : : multisig_sig & x , const boost : : serialization : : version_type ver )
{
a & x . sigs ;
a & x . ignore ;
a & x . used_L ;
a & x . signing_keys ;
a & x . msout ;
}
2016-12-30 13:51:43 +00:00
template < class Archive >
inline void serialize ( Archive & a , tools : : wallet2 : : pending_tx & x , const boost : : serialization : : version_type ver )
{
a & x . tx ;
a & x . dust ;
a & x . fee ;
a & x . dust_added_to_fee ;
a & x . change_dts ;
2017-10-22 08:54:07 +00:00
if ( ver < 2 )
{
// load list to vector
std : : list < size_t > selected_transfers ;
a & selected_transfers ;
x . selected_transfers . clear ( ) ;
x . selected_transfers . reserve ( selected_transfers . size ( ) ) ;
for ( size_t t : selected_transfers )
x . selected_transfers . push_back ( t ) ;
}
2016-12-30 13:51:43 +00:00
a & x . key_images ;
a & x . tx_key ;
a & x . dests ;
a & x . construction_data ;
2017-02-19 02:42:10 +00:00
if ( ver < 1 )
return ;
a & x . additional_tx_keys ;
2017-10-22 08:54:07 +00:00
if ( ver < 2 )
return ;
a & x . selected_transfers ;
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
if ( ver < 3 )
return ;
2017-08-13 14:29:31 +00:00
a & x . multisig_sigs ;
2016-12-30 13:51:43 +00:00
}
2014-03-03 22:07:58 +00:00
}
}
namespace tools
{
2014-06-04 22:59:47 +00:00
2014-03-03 22:07:58 +00:00
namespace detail
{
//----------------------------------------------------------------------------------------------------
inline void digit_split_strategy ( const std : : vector < cryptonote : : tx_destination_entry > & dsts ,
const cryptonote : : tx_destination_entry & change_dst , uint64_t dust_threshold ,
2015-10-06 15:22:19 +00:00
std : : vector < cryptonote : : tx_destination_entry > & splitted_dsts , std : : vector < cryptonote : : tx_destination_entry > & dust_dsts )
2014-03-03 22:07:58 +00:00
{
splitted_dsts . clear ( ) ;
2015-10-06 15:22:19 +00:00
dust_dsts . clear ( ) ;
2014-03-03 22:07:58 +00:00
2017-01-22 20:38:10 +00:00
for ( auto & de : dsts )
2014-03-03 22:07:58 +00:00
{
2015-10-06 15:22:19 +00:00
cryptonote : : decompose_amount_into_digits ( de . amount , 0 ,
2017-02-19 02:42:10 +00:00
[ & ] ( uint64_t chunk ) { splitted_dsts . push_back ( cryptonote : : tx_destination_entry ( chunk , de . addr , de . is_subaddress ) ) ; } ,
[ & ] ( uint64_t a_dust ) { splitted_dsts . push_back ( cryptonote : : tx_destination_entry ( a_dust , de . addr , de . is_subaddress ) ) ; } ) ;
2014-03-03 22:07:58 +00:00
}
2015-10-06 15:22:19 +00:00
cryptonote : : decompose_amount_into_digits ( change_dst . amount , 0 ,
[ & ] ( uint64_t chunk ) {
if ( chunk < = dust_threshold )
2017-02-19 02:42:10 +00:00
dust_dsts . push_back ( cryptonote : : tx_destination_entry ( chunk , change_dst . addr , false ) ) ;
2015-10-06 15:22:19 +00:00
else
2017-02-19 02:42:10 +00:00
splitted_dsts . push_back ( cryptonote : : tx_destination_entry ( chunk , change_dst . addr , false ) ) ;
2015-10-06 15:22:19 +00:00
} ,
2017-02-19 02:42:10 +00:00
[ & ] ( uint64_t a_dust ) { dust_dsts . push_back ( cryptonote : : tx_destination_entry ( a_dust , change_dst . addr , false ) ) ; } ) ;
2014-03-03 22:07:58 +00:00
}
//----------------------------------------------------------------------------------------------------
inline void null_split_strategy ( const std : : vector < cryptonote : : tx_destination_entry > & dsts ,
const cryptonote : : tx_destination_entry & change_dst , uint64_t dust_threshold ,
2015-10-06 15:22:19 +00:00
std : : vector < cryptonote : : tx_destination_entry > & splitted_dsts , std : : vector < cryptonote : : tx_destination_entry > & dust_dsts )
2014-03-03 22:07:58 +00:00
{
splitted_dsts = dsts ;
2015-10-06 15:22:19 +00:00
dust_dsts . clear ( ) ;
2014-03-03 22:07:58 +00:00
uint64_t change = change_dst . amount ;
if ( 0 ! = change )
{
2017-02-19 02:42:10 +00:00
splitted_dsts . push_back ( cryptonote : : tx_destination_entry ( change , change_dst . addr , false ) ) ;
2014-03-03 22:07:58 +00:00
}
}
//----------------------------------------------------------------------------------------------------
inline void print_source_entry ( const cryptonote : : tx_source_entry & src )
{
std : : string indexes ;
std : : for_each ( src . outputs . begin ( ) , src . outputs . end ( ) , [ & ] ( const cryptonote : : tx_source_entry : : output_entry & s_e ) { indexes + = boost : : to_string ( s_e . first ) + " " ; } ) ;
2014-03-20 11:46:11 +00:00
LOG_PRINT_L0 ( " amount= " < < cryptonote : : print_money ( src . amount ) < < " , real_output= " < < src . real_output < < " , real_output_in_tx_index= " < < src . real_output_in_tx_index < < " , indexes: " < < indexes ) ;
2014-03-03 22:07:58 +00:00
}
//----------------------------------------------------------------------------------------------------
}
//----------------------------------------------------------------------------------------------------
}
