2018-01-07 00:05:16 -05:00
// Copyright (c) 2014-2018, The Monero Project
2014-07-23 09:03:52 -04: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 17:07:58 -05:00
# pragma once
# include <memory>
2016-11-08 22:55:41 -05:00
# include <boost/program_options/options_description.hpp>
# include <boost/program_options/variables_map.hpp>
2014-03-03 17:07:58 -05:00
# include <boost/serialization/list.hpp>
# include <boost/serialization/vector.hpp>
2017-09-11 09:38:37 -04:00
# include <boost/serialization/deque.hpp>
2014-03-03 17:07:58 -05:00
# include <atomic>
2014-04-02 12:00:17 -04:00
2014-03-03 17:07:58 -05:00
# include "include_base_utils.h"
2017-01-26 10:07:23 -05:00
# include "cryptonote_basic/account.h"
# include "cryptonote_basic/account_boost_serialization.h"
# include "cryptonote_basic/cryptonote_basic_impl.h"
2014-03-03 17:07:58 -05:00
# include "net/http_client.h"
# include "storages/http_abstract_invoke.h"
# include "rpc/core_rpc_server_commands_defs.h"
2017-01-26 10:07:23 -05:00
# include "cryptonote_basic/cryptonote_format_utils.h"
# include "cryptonote_core/cryptonote_tx_utils.h"
2014-03-03 17:07:58 -05:00
# include "common/unordered_containers_boost_serialization.h"
2017-12-07 08:27:11 -05:00
# include "crypto/chacha.h"
2014-03-03 17:07:58 -05:00
# include "crypto/hash.h"
2016-06-15 18:37:13 -04:00
# include "ringct/rctTypes.h"
# include "ringct/rctOps.h"
2017-09-11 09:38:37 -04:00
# include "checkpoints/checkpoints.h"
2014-03-03 17:07:58 -05:00
2014-04-02 12:00:17 -04:00
# include "wallet_errors.h"
2017-02-05 17:48:03 -05:00
# include "common/password.h"
2017-01-07 14:23:57 -05:00
# include "node_rpc_proxy.h"
2014-04-02 12:00:17 -04: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 11:34:23 -05:00
# undef MONERO_DEFAULT_LOG_CATEGORY
# define MONERO_DEFAULT_LOG_CATEGORY "wallet.wallet2"
2017-01-01 20:43:20 -05:00
class Serialization_portability_wallet_Test ;
2014-03-03 17:07:58 -05:00
namespace tools
{
2018-02-27 03:30:59 -05:00
class ringdb ;
2014-04-02 12:00:17 -04:00
class i_wallet2_callback
2014-03-20 07:46:11 -04:00
{
2014-04-02 12:00:17 -04:00
public :
2017-08-05 11:01:50 -04:00
// Full wallet callbacks
2014-04-02 12:00:17 -04:00
virtual void on_new_block ( uint64_t height , const cryptonote : : block & block ) { }
2017-02-18 21:42:10 -05: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 ) { }
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 15:26:17 -05:00
virtual void on_skip_transaction ( uint64_t height , const crypto : : hash & txid , const cryptonote : : transaction & tx ) { }
2017-08-05 11:01:50 -04: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 ) { }
// Common callbacks
2017-08-04 17:18:46 -04:00
virtual void on_pool_tx_removed ( const crypto : : hash & txid ) { }
2016-05-13 05:59:29 -04:00
virtual ~ i_wallet2_callback ( ) { }
2014-04-02 12:00:17 -04: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 07:46:11 -04:00
{
}
2014-04-02 12:00:17 -04:00
} ;
2014-03-20 07:46:11 -04:00
2017-09-11 09:38:37 -04: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 19:51:53 -04: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 11:02:14 -04:00
void refill ( const crypto : : hash & hash ) { m_blockchain . push_back ( hash ) ; - - m_offset ; }
2017-09-11 09:38:37 -04: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 ;
} ;
2014-03-03 17:07:58 -05:00
class wallet2
{
2017-01-01 20:43:20 -05:00
friend class : : Serialization_portability_wallet_Test ;
2014-03-03 17:07:58 -05:00
public :
2017-01-25 00:16:05 -05:00
static constexpr const std : : chrono : : seconds rpc_timeout = std : : chrono : : minutes ( 3 ) + std : : chrono : : seconds ( 30 ) ;
2015-11-22 14:03:10 -05:00
enum RefreshType {
RefreshFull ,
RefreshOptimizeCoinbase ,
RefreshNoCoinbase ,
2015-12-05 16:44:25 -05:00
RefreshDefault = RefreshOptimizeCoinbase ,
2015-11-22 14:03:10 -05:00
} ;
2017-01-25 00:16:05 -05:00
static const char * tr ( const char * str ) ;
2016-11-08 22:55:41 -05:00
static bool has_testnet_option ( const boost : : program_options : : variables_map & vm ) ;
2018-02-16 06:04:04 -05:00
static bool has_stagenet_option ( const boost : : program_options : : variables_map & vm ) ;
2016-11-08 22:55:41 -05:00
static void init_options ( boost : : program_options : : options_description & desc_params ) ;
//! Uses stdin and stdout. Returns a wallet2 if no errors.
2017-10-28 14:13:42 -04:00
static std : : unique_ptr < wallet2 > make_from_json ( const boost : : program_options : : variables_map & vm , const std : : string & json_file , const std : : function < boost : : optional < password_container > ( const char * , bool ) > & password_prompter ) ;
2016-11-08 22:55:41 -05: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 >
2017-10-28 14:13:42 -04:00
make_from_file ( const boost : : program_options : : variables_map & vm , const std : : string & wallet_file , const std : : function < boost : : optional < password_container > ( const char * , bool ) > & password_prompter ) ;
2016-11-08 22:55:41 -05:00
//! Uses stdin and stdout. Returns a wallet2 and password for wallet with no file if no errors.
2017-10-28 14:13:42 -04:00
static std : : pair < std : : unique_ptr < wallet2 > , password_container > make_new ( const boost : : program_options : : variables_map & vm , const std : : function < boost : : optional < password_container > ( const char * , bool ) > & password_prompter ) ;
2016-11-08 22:55:41 -05:00
2017-04-02 18:09:36 -04:00
//! Just parses variables.
2017-10-28 14:13:42 -04:00
static std : : unique_ptr < wallet2 > make_dummy ( const boost : : program_options : : variables_map & vm , const std : : function < boost : : optional < password_container > ( const char * , bool ) > & password_prompter ) ;
2017-04-02 18:09:36 -04:00
2018-02-20 11:01:27 -05:00
static bool verify_password ( const std : : string & keys_file_name , const epee : : wipeable_string & password , bool no_spend_key , hw : : device & hwdev ) ;
2017-08-01 18:41:05 -04:00
2018-02-16 06:04:04 -05:00
wallet2 ( cryptonote : : network_type nettype = cryptonote : : MAINNET , bool restricted = false ) ;
2018-02-27 03:30:59 -05: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 17:34:26 -04:00
struct multisig_info
{
2017-08-13 10:29:31 -04: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 17:34:26 -04:00
BEGIN_SERIALIZE_OBJECT ( )
2017-08-13 10:29:31 -04: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 17:34:26 -04: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 16:58:02 -04:00
2017-09-12 07:03:56 -04: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-18 21:42:10 -05:00
boost : : optional < cryptonote : : subaddress_receive_info > received ;
2017-09-12 07:03:56 -04:00
2017-02-18 21:42:10 -05:00
tx_scan_info_t ( ) : money_transfered ( 0 ) , error ( true ) { }
2017-09-12 07:03:56 -04:00
} ;
2014-03-03 17:07:58 -05:00
struct transfer_details
{
uint64_t m_block_height ;
2016-08-06 14:19:25 -04:00
cryptonote : : transaction_prefix m_tx ;
crypto : : hash m_txid ;
2014-03-03 17:07:58 -05:00
size_t m_internal_output_index ;
uint64_t m_global_output_index ;
bool m_spent ;
2016-06-16 18:58:54 -04:00
uint64_t m_spent_height ;
2014-03-03 17:07:58 -05:00
crypto : : key_image m_key_image ; //TODO: key_image stored twice :(
2016-06-15 18:37:13 -04:00
rct : : key m_mask ;
uint64_t m_amount ;
2016-08-12 13:45:07 -04:00
bool m_rct ;
2016-11-07 13:50:05 -05:00
bool m_key_image_known ;
2016-12-09 13:21:21 -05:00
size_t m_pk_index ;
2017-02-18 21:42:10 -05: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 17:34:26 -04:00
bool m_key_image_partial ;
2017-08-13 10:29:31 -04:00
std : : vector < rct : : key > m_multisig_k ;
std : : vector < multisig_info > m_multisig_info ; // one per other participant
2014-03-03 17:07:58 -05:00
2016-08-12 13:45:07 -04:00
bool is_rct ( ) const { return m_rct ; }
2016-06-15 18:37:13 -04:00
uint64_t amount ( ) const { return m_amount ; }
2016-11-07 13:50:05 -05: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 16:22:04 -05: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 )
FIELD ( m_spent_height )
FIELD ( m_key_image )
FIELD ( m_mask )
FIELD ( m_amount )
FIELD ( m_rct )
FIELD ( m_key_image_known )
2016-12-09 13:21:21 -05:00
FIELD ( m_pk_index )
2017-02-18 21:42:10 -05: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 17:34:26 -04:00
FIELD ( m_key_image_partial )
FIELD ( m_multisig_k )
FIELD ( m_multisig_info )
2016-11-15 16:22:04 -05:00
END_SERIALIZE ( )
2014-03-03 17:07:58 -05:00
} ;
2014-05-03 12:19:43 -04:00
struct payment_details
{
crypto : : hash m_tx_hash ;
uint64_t m_amount ;
2018-01-13 23:37:57 -05:00
uint64_t m_fee ;
2014-05-03 12:19:43 -04:00
uint64_t m_block_height ;
uint64_t m_unlock_time ;
2016-04-19 16:18:43 -04:00
uint64_t m_timestamp ;
2017-02-18 21:42:10 -05:00
cryptonote : : subaddress_index m_subaddr_index ;
2014-05-03 12:19:43 -04:00
} ;
2017-08-04 17:58:08 -04:00
struct address_tx : payment_details
{
bool m_coinbase ;
bool m_mempool ;
bool m_incoming ;
} ;
2017-09-22 08:57:20 -04:00
struct pool_payment_details
{
payment_details m_pd ;
bool m_double_spend_seen ;
} ;
2014-04-02 12:00:17 -04:00
struct unconfirmed_transfer_details
2014-03-03 17:07:58 -05:00
{
2016-08-06 14:19:25 -04:00
cryptonote : : transaction_prefix m_tx ;
2016-06-15 18:37:13 -04:00
uint64_t m_amount_in ;
uint64_t m_amount_out ;
2014-04-02 12:00:17 -04:00
uint64_t m_change ;
2014-05-03 12:19:43 -04:00
time_t m_sent_time ;
2015-11-22 07:13:59 -05:00
std : : vector < cryptonote : : tx_destination_entry > m_dests ;
crypto : : hash m_payment_id ;
2016-01-29 14:44:48 -05:00
enum { pending , pending_not_in_pool , failed } m_state ;
2016-04-19 16:18:43 -04:00
uint64_t m_timestamp ;
2017-02-18 21:42:10 -05: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 15:13:55 -04:00
std : : vector < std : : pair < crypto : : key_image , std : : vector < uint64_t > > > m_rings ; // relative
2014-03-03 17:07:58 -05:00
} ;
2015-11-15 16:59:40 -05: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 07:13:59 -05:00
std : : vector < cryptonote : : tx_destination_entry > m_dests ;
crypto : : hash m_payment_id ;
2016-04-19 16:18:43 -04:00
uint64_t m_timestamp ;
2017-07-25 11:28:48 -04:00
uint64_t m_unlock_time ;
2017-02-18 21:42:10 -05: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 15:13:55 -04:00
std : : vector < std : : pair < crypto : : key_image , std : : vector < uint64_t > > > m_rings ; // relative
2015-11-22 07:13:59 -05:00
2017-02-18 21:42:10 -05: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 16:59:40 -05:00
confirmed_transfer_details ( const unconfirmed_transfer_details & utd , uint64_t height ) :
2018-03-14 15:13:55 -04: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 16:59:40 -05:00
} ;
2016-09-26 18:11:10 -04:00
struct tx_construction_data
{
std : : vector < cryptonote : : tx_source_entry > sources ;
cryptonote : : tx_destination_entry change_dts ;
2016-11-23 15:10:34 -05:00
std : : vector < cryptonote : : tx_destination_entry > splitted_dsts ; // split, includes change
2017-10-22 04:54:07 -04:00
std : : vector < size_t > selected_transfers ;
2016-09-26 18:11:10 -04:00
std : : vector < uint8_t > extra ;
uint64_t unlock_time ;
bool use_rct ;
2016-11-23 15:10:34 -05:00
std : : vector < cryptonote : : tx_destination_entry > dests ; // original setup, does not include change
2017-02-18 21:42:10 -05: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 14:39:09 -05:00
BEGIN_SERIALIZE_OBJECT ( )
FIELD ( sources )
FIELD ( change_dts )
FIELD ( splitted_dsts )
FIELD ( selected_transfers )
FIELD ( extra )
FIELD ( unlock_time )
FIELD ( use_rct )
FIELD ( dests )
FIELD ( subaddr_account )
FIELD ( subaddr_indices )
END_SERIALIZE ( )
2016-09-26 18:11:10 -04:00
} ;
2014-04-02 12:00:17 -04:00
typedef std : : vector < transfer_details > transfer_container ;
2014-05-03 12:19:43 -04:00
typedef std : : unordered_multimap < crypto : : hash , payment_details > payment_container ;
2014-04-02 12:00:17 -04:00
2017-08-13 10:29:31 -04:00
struct multisig_sig
{
rct : : rctSig sigs ;
crypto : : public_key ignore ;
std : : unordered_set < rct : : key > used_L ;
std : : unordered_set < crypto : : public_key > signing_keys ;
rct : : multisig_out msout ;
} ;
2016-11-23 15:10:34 -05:00
// The convention for destinations is:
// dests does not include change
// splitted_dsts (in construction_data) does
2014-06-15 20:36:44 -04:00
struct pending_tx
{
cryptonote : : transaction tx ;
uint64_t dust , fee ;
2016-04-18 04:20:31 -04:00
bool dust_added_to_fee ;
2014-06-15 20:36:44 -04:00
cryptonote : : tx_destination_entry change_dts ;
2017-10-22 04:54:07 -04:00
std : : vector < size_t > selected_transfers ;
2014-06-15 20:36:44 -04:00
std : : string key_images ;
2015-08-19 15:59:44 -04:00
crypto : : secret_key tx_key ;
2017-02-18 21:42:10 -05:00
std : : vector < crypto : : secret_key > additional_tx_keys ;
2015-11-22 07:13:59 -05:00
std : : vector < cryptonote : : tx_destination_entry > dests ;
2017-08-13 10:29:31 -04:00
std : : vector < multisig_sig > multisig_sigs ;
2016-09-26 18:11:10 -04:00
tx_construction_data construction_data ;
2017-11-10 14:39:09 -05: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 10:29:31 -04:00
FIELD ( multisig_sigs )
2017-11-10 14:39:09 -05:00
END_SERIALIZE ( )
2016-09-26 18:11:10 -04:00
} ;
2017-01-08 07:17:09 -05: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 18:11:10 -04:00
struct unsigned_tx_set
{
std : : vector < tx_construction_data > txes ;
2016-11-15 16:22:04 -05:00
wallet2 : : transfer_container transfers ;
2016-09-26 18:11:10 -04:00
} ;
struct signed_tx_set
{
std : : vector < pending_tx > ptx ;
2016-11-15 16:22:04 -05:00
std : : vector < crypto : : key_image > key_images ;
2014-06-15 20:36:44 -04: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 17:34:26 -04:00
struct multisig_tx_set
{
std : : vector < pending_tx > m_ptx ;
2017-08-13 10:29:31 -04:00
std : : unordered_set < crypto : : public_key > m_signers ;
2017-11-27 15:09:16 -05: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 17:34:26 -04:00
} ;
2014-03-03 17:07:58 -05:00
struct keys_file_data
{
2017-12-07 08:27:11 -05:00
crypto : : chacha_iv iv ;
2014-03-03 17:07:58 -05:00
std : : string account_data ;
BEGIN_SERIALIZE_OBJECT ( )
FIELD ( iv )
FIELD ( account_data )
END_SERIALIZE ( )
} ;
2015-08-22 09:21:32 -04:00
struct cache_file_data
{
2017-12-07 08:27:11 -05:00
crypto : : chacha_iv iv ;
2015-08-22 09:21:32 -04:00
std : : string cache_data ;
BEGIN_SERIALIZE_OBJECT ( )
FIELD ( iv )
FIELD ( cache_data )
END_SERIALIZE ( )
} ;
2016-12-11 18:42:46 -05:00
// GUI Address book
struct address_book_row
{
cryptonote : : account_public_address m_address ;
crypto : : hash m_payment_id ;
2016-12-12 15:39:29 -05:00
std : : string m_description ;
2017-02-18 21:42:10 -05:00
bool m_is_subaddress ;
2016-12-11 18:42:46 -05:00
} ;
2015-08-22 09:21:32 -04:00
2017-12-28 08:50:10 -05: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 11:06:07 -05:00
typedef std : : tuple < uint64_t , crypto : : public_key , rct : : key > get_outs_entry ;
2017-11-09 05:59:41 -05:00
/*!
* \ brief Generates a wallet or restores one .
2018-02-25 11:59:52 -05: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 05:59:41 -05:00
*/
void generate ( const std : : string & wallet_ , const epee : : wipeable_string & password ,
2018-02-25 11:59:52 -05:00
const std : : string & multisig_data , bool create_address_file = false ) ;
2017-11-09 05:59:41 -05:00
2014-10-18 15:38:21 -04:00
/*!
* \ brief Generates a wallet or restores one .
2018-02-25 11:59:52 -05: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 15:38:21 -04:00
*/
2017-11-25 09:50:15 -05:00
crypto : : secret_key generate ( const std : : string & wallet , const epee : : wipeable_string & password ,
2014-10-18 15:30:18 -04:00
const crypto : : secret_key & recovery_param = crypto : : secret_key ( ) , bool recover = false ,
2018-02-25 11:59:52 -05:00
bool two_random = false , bool create_address_file = false ) ;
2016-02-22 17:10:55 -05:00
/*!
* \ brief Creates a wallet from a public address and a spend / view secret key pair .
2018-03-14 11:41:24 -04: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 17:10:55 -05:00
*/
2017-11-25 09:50:15 -05:00
void generate ( const std : : string & wallet , const epee : : wipeable_string & password ,
2016-02-22 17:10:55 -05:00
const cryptonote : : account_public_address & account_public_address ,
2018-02-25 11:59:52 -05:00
const crypto : : secret_key & spendkey , const crypto : : secret_key & viewkey , bool create_address_file = false ) ;
2015-06-20 07:31:53 -04:00
/*!
* \ brief Creates a watch only wallet from a public address and a view secret key .
2018-03-14 11:41:24 -04: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 07:31:53 -04:00
*/
2017-11-25 09:50:15 -05:00
void generate ( const std : : string & wallet , const epee : : wipeable_string & password ,
2015-06-20 07:31:53 -04:00
const cryptonote : : account_public_address & account_public_address ,
2018-02-25 11:59:52 -05:00
const crypto : : secret_key & viewkey = crypto : : secret_key ( ) , bool create_address_file = false ) ;
2018-02-20 11:01:27 -05: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
*/
void restore ( const std : : string & wallet_ , const epee : : wipeable_string & password , const std : : string & device_name ) ;
2017-05-28 07:18:51 -04:00
/*!
* \ brief Creates a multisig wallet
2017-08-13 10:29:31 -04:00
* \ return empty if done , non empty if we need to send another string
* to other participants
2017-05-28 07:18:51 -04:00
*/
2017-11-18 06:24:38 -05: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 10:29:31 -04:00
std : : string make_multisig ( const epee : : wipeable_string & password ,
2017-05-28 07:18:51 -04:00
const std : : vector < crypto : : secret_key > & view_keys ,
const std : : vector < crypto : : public_key > & spend_keys ,
uint32_t threshold ) ;
2017-09-26 18:16:25 -04: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 10:29:31 -04:00
/*!
* \ brief Finalizes creation of a multisig wallet
*/
bool finalize_multisig ( const epee : : wipeable_string & password , std : : unordered_set < crypto : : public_key > pkeys , std : : vector < crypto : : public_key > signers ) ;
2017-05-28 07:18:51 -04: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 10:29:31 -04: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 17:34:26 -04:00
/*!
* Export multisig info
* This will generate and remember new k values
*/
2017-11-13 11:24:42 -05: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 17:34:26 -04:00
/*!
* Import a set of multisig info from multisig partners
* \ return the number of inputs which were imported
*/
2017-11-13 11:24:42 -05:00
size_t import_multisig ( std : : vector < cryptonote : : blobdata > info ) ;
2014-10-18 15:38:21 -04: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 09:50:15 -05:00
void rewrite ( const std : : string & wallet_name , const epee : : wipeable_string & password ) ;
2018-03-07 08:54:18 -05:00
void write_watch_only_wallet ( const std : : string & wallet_name , const epee : : wipeable_string & password , std : : string & new_keys_filename ) ;
2017-11-25 09:50:15 -05:00
void load ( const std : : string & wallet , const epee : : wipeable_string & password ) ;
2014-04-02 12:00:17 -04:00
void store ( ) ;
2016-03-15 16:11:38 -04:00
/*!
2018-03-14 11:41:24 -04: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 16:11:38 -04:00
*/
2017-11-25 09:50:15 -05:00
void store_to ( const std : : string & path , const epee : : wipeable_string & password ) ;
2014-12-06 09:55:56 -05:00
2016-11-26 09:19:57 -05:00
std : : string path ( ) const ;
2014-12-06 09:55:56 -05:00
/*!
* \ brief verifies given password is correct for default wallet keys file
*/
2017-11-25 09:50:15 -05:00
bool verify_password ( const epee : : wipeable_string & password ) const ;
2014-03-03 17:07:58 -05:00
cryptonote : : account_base & get_account ( ) { return m_account ; }
2015-05-27 14:00:57 -04:00
const cryptonote : : account_base & get_account ( ) const { return m_account ; }
2014-03-03 17:07:58 -05:00
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-24 20:48:11 -04:00
void set_refresh_from_block_height ( uint64_t height ) { m_refresh_from_block_height = height ; }
2017-01-10 16:34:15 -05: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-24 20:48:11 -04:00
2018-01-23 09:42:11 -05: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-05-25 20:25:37 -04:00
// upper_transaction_size_limit as defined below is set to
// approximately 125% of the fixed minimum allowable penalty
// free block size. TODO: fix this so that it actually takes
// into account the current median block size rather than
// the minimum block size.
2014-03-03 17:07:58 -05:00
bool deinit ( ) ;
2017-02-05 17:48:03 -05:00
bool init ( std : : string daemon_address = " http://localhost:8080 " ,
2017-08-04 16:34:13 -04:00
boost : : optional < epee : : net_utils : : http : : login > daemon_login = boost : : none , uint64_t upper_transaction_size_limit = 0 , bool ssl = false ) ;
2014-03-03 17:07:58 -05:00
2014-03-20 07:46:11 -04:00
void stop ( ) { m_run . store ( false , std : : memory_order_relaxed ) ; }
2014-04-02 12:00:17 -04:00
i_wallet2_callback * callback ( ) const { return m_callback ; }
void callback ( i_wallet2_callback * callback ) { m_callback = callback ; }
2014-12-06 04:59:13 -05:00
/*!
* \ brief Checks if deterministic wallet
*/
2015-05-27 14:00:57 -04:00
bool is_deterministic ( ) const ;
2017-11-25 09:50:15 -05:00
bool get_seed ( std : : string & electrum_words , const epee : : wipeable_string & passphrase = epee : : wipeable_string ( ) ) const ;
2017-08-04 17:58:08 -04: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 17:36:36 -05:00
/*!
* \ brief Gets the seed language
*/
2015-05-27 14:00:57 -04:00
const std : : string & get_seed_language ( ) const ;
2014-10-02 08:45:18 -04:00
/*!
* \ brief Sets the seed language
*/
2014-10-17 16:51:37 -04:00
void set_seed_language ( const std : : string & language ) ;
2017-02-18 21:42:10 -05: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 } ) ; }
crypto : : public_key get_subaddress_spend_public_key ( const cryptonote : : subaddress_index & index ) const ;
2018-02-10 05:38:33 -05:00
std : : vector < crypto : : public_key > get_subaddress_spend_public_keys ( uint32_t account , uint32_t begin , uint32_t end ) const ;
2017-02-18 21:42:10 -05: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 ) ;
2017-10-22 10:21:44 -04: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 13:31:30 -04:00
void set_subaddress_lookahead ( size_t major , size_t minor ) ;
2018-03-16 00:11:45 -04:00
std : : pair < size_t , size_t > get_subaddress_lookahead ( ) const { return { m_subaddress_lookahead_major , m_subaddress_lookahead_minor } ; }
2014-10-17 16:51:37 -04:00
/*!
* \ brief Tells if the wallet file is deprecated .
*/
bool is_deprecated ( ) const ;
2014-04-02 12:00:17 -04:00
void refresh ( ) ;
2015-10-27 05:05:07 -04:00
void refresh ( uint64_t start_height , uint64_t & blocks_fetched ) ;
void refresh ( uint64_t start_height , uint64_t & blocks_fetched , bool & received_money ) ;
bool refresh ( uint64_t & blocks_fetched , bool & received_money , bool & ok ) ;
2014-04-02 12:00:17 -04:00
2015-11-22 14:03:10 -05:00
void set_refresh_type ( RefreshType refresh_type ) { m_refresh_type = refresh_type ; }
2015-12-05 16:44:25 -05:00
RefreshType get_refresh_type ( ) const { return m_refresh_type ; }
2015-11-22 14:03:10 -05:00
2018-02-16 06:04:04 -05:00
cryptonote : : network_type nettype ( ) const { return m_nettype ; }
2015-01-11 06:06:35 -05:00
bool restricted ( ) const { return m_restricted ; }
2015-05-31 10:34:55 -04:00
bool watch_only ( ) const { return m_watch_only ; }
2017-10-01 09:06:54 -04: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 17:34:26 -04:00
bool has_multisig_partial_key_images ( ) const ;
2017-11-09 05:59:41 -05:00
bool get_multisig_seed ( std : : string & seed , const epee : : wipeable_string & passphrase = std : : string ( ) , bool raw = true ) const ;
2018-02-20 11:01:27 -05:00
bool key_on_device ( ) const { return m_key_on_device ; }
2014-09-09 10:58:53 -04:00
2017-02-18 21:42:10 -05:00
// locked & unlocked balance of given or current subaddress account
uint64_t balance ( uint32_t subaddr_index_major ) const ;
uint64_t unlocked_balance ( uint32_t subaddr_index_major ) const ;
// locked & unlocked balance per subaddress of given or current subaddress account
std : : map < uint32_t , uint64_t > balance_per_subaddress ( uint32_t subaddr_index_major ) const ;
std : : map < uint32_t , uint64_t > unlocked_balance_per_subaddress ( uint32_t subaddr_index_major ) const ;
// all locked & unlocked balances of all subaddress accounts
uint64_t balance_all ( ) const ;
uint64_t unlocked_balance_all ( ) const ;
2014-03-20 07:46:11 -04:00
template < typename T >
2016-04-02 08:06:39 -04:00
void transfer ( const std : : vector < cryptonote : : tx_destination_entry > & dsts , const size_t fake_outputs_count , const std : : vector < size_t > & unused_transfers_indices , uint64_t unlock_time , uint64_t fee , const std : : vector < uint8_t > & extra , T destination_split_strategy , const tx_dust_policy & dust_policy , bool trusted_daemon ) ;
2014-03-03 17:07:58 -05:00
template < typename T >
2016-04-02 08:06:39 -04:00
void transfer ( const std : : vector < cryptonote : : tx_destination_entry > & dsts , const size_t fake_outputs_count , const std : : vector < size_t > & unused_transfers_indices , 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 , bool trusted_daemon ) ;
void transfer ( const std : : vector < cryptonote : : tx_destination_entry > & dsts , const size_t fake_outputs_count , const std : : vector < size_t > & unused_transfers_indices , uint64_t unlock_time , uint64_t fee , const std : : vector < uint8_t > & extra , bool trusted_daemon ) ;
void transfer ( const std : : vector < cryptonote : : tx_destination_entry > & dsts , const size_t fake_outputs_count , const std : : vector < size_t > & unused_transfers_indices , uint64_t unlock_time , uint64_t fee , const std : : vector < uint8_t > & extra , cryptonote : : transaction & tx , pending_tx & ptx , bool trusted_daemon ) ;
2015-05-30 04:13:52 -04:00
template < typename T >
2017-10-22 04:54:07 -04: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 11:06:07 -05:00
std : : vector < std : : vector < tools : : wallet2 : : get_outs_entry > > & outs ,
2015-07-19 18:47:13 -04: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 04:54:07 -04: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 11:06:07 -05:00
std : : vector < std : : vector < tools : : wallet2 : : get_outs_entry > > & outs ,
2017-12-02 16:17:42 -05:00
uint64_t unlock_time , uint64_t fee , const std : : vector < uint8_t > & extra , cryptonote : : transaction & tx , pending_tx & ptx , bool bulletproof ) ;
2015-07-19 18:47:13 -04:00
2014-06-17 18:15:21 -04:00
void commit_tx ( pending_tx & ptx_vector ) ;
void commit_tx ( std : : vector < pending_tx > & ptx_vector ) ;
2018-01-16 20:58:34 -05:00
bool save_tx ( const std : : vector < pending_tx > & ptx_vector , const std : : string & filename ) const ;
2017-11-27 15:09:04 -05: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 17:34:26 -04:00
bool save_multisig_tx ( const std : : vector < pending_tx > & ptx_vector , const std : : string & filename ) ;
2018-03-21 11:57:15 -04:00
multisig_tx_set make_multisig_tx_set ( const std : : vector < pending_tx > & ptx_vector ) const ;
2017-01-08 07:17:09 -05:00
// load unsigned tx from file and sign it. Takes confirmation callback as argument. Used by the cli wallet
2017-09-30 00:28:17 -04: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 07:17:09 -05:00
// sign unsigned tx. Takes unsigned_tx_set as argument. Used by GUI
2017-09-30 00:28:17 -04:00
bool sign_tx ( unsigned_tx_set & exported_txs , const std : : string & signed_filename , std : : vector < wallet2 : : pending_tx > & ptx , bool export_raw = false ) ;
2017-01-08 07:17:09 -05:00
// load unsigned_tx_set from file.
2018-01-16 20:58:34 -05:00
bool load_unsigned_tx ( const std : : string & unsigned_filename , unsigned_tx_set & exported_txs ) const ;
2016-10-30 06:49:22 -04: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 ) ;
2017-02-18 21:42:10 -05:00
std : : vector < pending_tx > create_transactions ( 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 , bool trusted_daemon ) ;
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 , bool trusted_daemon ) ; // pass subaddr_indices by value on purpose
std : : vector < wallet2 : : pending_tx > create_transactions_all ( uint64_t below , const cryptonote : : account_public_address & address , bool is_subaddress , 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 , bool trusted_daemon ) ;
2017-10-10 21:32:06 -04:00
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 fake_outs_count , const uint64_t unlock_time , uint32_t priority , const std : : vector < uint8_t > & extra , bool trusted_daemon ) ;
2017-02-18 21:42:10 -05:00
std : : vector < wallet2 : : pending_tx > create_transactions_from ( const cryptonote : : account_public_address & address , bool is_subaddress , 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 , bool trusted_daemon ) ;
2017-11-27 15:09:16 -05: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 17:34:26 -04: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 10:29:31 -04:00
bool sign_multisig_tx ( multisig_tx_set & exported_txs , std : : vector < crypto : : hash > & txids ) ;
2017-09-26 18:16:25 -04:00
bool sign_multisig_tx_to_file ( multisig_tx_set & exported_txs , const std : : string & filename , std : : vector < crypto : : hash > & txids ) ;
2016-03-26 19:22:57 -04:00
std : : vector < pending_tx > create_unmixable_sweep_transactions ( bool trusted_daemon ) ;
2017-01-14 08:41:56 -05:00
bool check_connection ( uint32_t * version = NULL , uint32_t timeout = 200000 ) ;
2014-04-02 12:00:17 -04:00
void get_transfers ( wallet2 : : transfer_container & incoming_transfers ) const ;
2017-02-18 21:42:10 -05: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 16:59:40 -05:00
void get_payments_out ( std : : list < std : : pair < crypto : : hash , wallet2 : : confirmed_transfer_details > > & confirmed_payments ,
2017-02-18 21:42:10 -05: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 08:57:20 -04: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 16:40:12 -04:00
2014-03-03 17:07:58 -05:00
uint64_t get_blockchain_current_height ( ) const { return m_local_bc_height ; }
2015-08-11 10:14:44 -04:00
void rescan_spent ( ) ;
2015-12-30 07:58:15 -05:00
void rescan_blockchain ( bool refresh = true ) ;
2016-06-15 18:37:13 -04:00
bool is_transfer_unlocked ( const transfer_details & td ) const ;
2017-08-04 17:05:02 -04:00
bool is_transfer_unlocked ( uint64_t unlock_time , uint64_t block_height ) const ;
2014-03-03 17:07:58 -05:00
template < class t_archive >
inline void serialize ( t_archive & a , const unsigned int ver )
{
2016-04-29 10:17:12 -04:00
uint64_t dummy_refresh_height = 0 ; // moved to keys file
2014-03-03 17:07:58 -05:00
if ( ver < 5 )
return ;
2017-09-11 09:38:37 -04: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 17:07:58 -05:00
a & m_transfers ;
a & m_account_public_address ;
a & m_key_images ;
2014-04-02 12:00:17 -04:00
if ( ver < 6 )
return ;
a & m_unconfirmed_txs ;
2014-05-03 12:19:43 -04:00
if ( ver < 7 )
return ;
a & m_payments ;
2015-08-19 15:59:44 -04:00
if ( ver < 8 )
return ;
a & m_tx_keys ;
2015-11-15 16:59:40 -05: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-24 20:48:11 -04:00
if ( ver < 11 )
return ;
2016-04-29 10:17:12 -04:00
a & dummy_refresh_height ;
2016-04-20 13:19:42 -04:00
if ( ver < 12 )
return ;
a & m_tx_notes ;
2016-05-23 16:40:12 -04:00
if ( ver < 13 )
return ;
2017-03-04 16:47:53 -05: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 08:57:20 -04:00
m_unconfirmed_payments . insert ( std : : make_pair ( i - > first , pool_payment_details { i - > second , false } ) ) ;
2017-03-04 16:47:53 -05:00
}
2016-07-11 18:14:58 -04:00
if ( ver < 14 )
return ;
2016-11-07 13:50:05 -05: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 18:42:46 -05:00
if ( ver < 16 )
return ;
a & m_address_book ;
2017-03-04 16:47:53 -05:00
if ( ver < 17 )
return ;
2017-11-15 03:30:49 -05:00
if ( ver < 22 )
2017-09-22 08:57:20 -04:00
{
// we're loading an old version, where m_unconfirmed_payments payload was payment_details
2017-11-15 03:30:49 -05:00
std : : unordered_multimap < crypto : : hash , payment_details > m ;
2017-09-22 08:57:20 -04: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 06:30:25 -04:00
if ( ver < 18 )
return ;
a & m_scanned_pool_txs [ 0 ] ;
a & m_scanned_pool_txs [ 1 ] ;
2017-02-18 21:42:10 -05:00
if ( ver < 20 )
return ;
a & m_subaddresses ;
2018-02-13 11:45:04 -05:00
std : : unordered_map < cryptonote : : subaddress_index , crypto : : public_key > dummy_subaddresses_inv ;
a & dummy_subaddresses_inv ;
2017-02-18 21:42:10 -05:00
a & m_subaddress_labels ;
a & m_additional_tx_keys ;
2017-10-08 03:15:06 -04:00
if ( ver < 21 )
return ;
a & m_attributes ;
2017-09-22 08:57:20 -04:00
if ( ver < 22 )
return ;
a & m_unconfirmed_payments ;
2017-12-14 22:08:36 -05:00
if ( ver < 23 )
return ;
a & m_account_tags ;
2018-02-18 05:47:25 -05:00
if ( ver < 24 )
return ;
a & m_ring_history_saved ;
2014-03-03 17:07:58 -05:00
}
2014-12-11 05:48:04 -05: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 13:06:40 -04:00
static void wallet_exists ( const std : : string & file_path , bool & keys_file_exists , bool & wallet_file_exists ) ;
2014-12-11 05:47:24 -05: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 05:09:39 -04: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 18:22:42 -04:00
static bool parse_payment_id ( const std : : string & payment_id_str , crypto : : hash & payment_id ) ;
2015-07-18 17:03:35 -04: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 07:04:54 -05: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 07:26:27 -05: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 17:16:51 -04:00
uint32_t default_mixin ( ) const { return m_default_mixin ; }
void default_mixin ( uint32_t m ) { m_default_mixin = m ; }
2016-09-16 06:50:52 -04: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 07:38:58 -05:00
bool auto_refresh ( ) const { return m_auto_refresh ; }
void auto_refresh ( bool r ) { m_auto_refresh = r ; }
2016-10-01 12:03:53 -04:00
bool confirm_missing_payment_id ( ) const { return m_confirm_missing_payment_id ; }
void confirm_missing_payment_id ( bool always ) { m_confirm_missing_payment_id = always ; }
2017-01-27 07:26:52 -05:00
bool ask_password ( ) const { return m_ask_password ; }
void ask_password ( bool always ) { m_ask_password = always ; }
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 16:58:02 -04: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 17:56:58 -04:00
void merge_destinations ( bool merge ) { m_merge_destinations = merge ; }
bool merge_destinations ( ) const { return m_merge_destinations ; }
2017-08-26 11:23:54 -04:00
bool confirm_backlog ( ) const { return m_confirm_backlog ; }
void confirm_backlog ( bool always ) { m_confirm_backlog = always ; }
2017-09-18 07:46:33 -04: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 18:36:13 -05:00
bool confirm_export_overwrite ( ) const { return m_confirm_export_overwrite ; }
void confirm_export_overwrite ( bool always ) { m_confirm_export_overwrite = always ; }
2018-01-14 22:05:16 -05: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 05:23:23 -05: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 15:38:52 -04:00
uint64_t segregation_height ( ) const { return m_segregation_height ; }
void segregation_height ( uint64_t height ) { m_segregation_height = height ; }
2018-03-31 09:20:48 -04: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 ; }
2015-07-18 17:03:35 -04:00
2017-02-18 21:42:10 -05:00
bool get_tx_key ( const crypto : : hash & txid , crypto : : secret_key & tx_key , std : : vector < crypto : : secret_key > & additional_tx_keys ) const ;
2017-09-11 21:05:41 -04: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 ) ;
2017-11-20 04:10:58 -05:00
std : : string get_tx_proof ( const crypto : : hash & txid , const cryptonote : : account_public_address & address , bool is_subaddress , const std : : string & message ) ;
2017-09-11 21:05:41 -04: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 ) ;
2015-08-19 15:59:44 -04:00
2017-08-28 11:34:17 -04: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 08:50:10 -05: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 18:42:46 -05:00
/*!
* \ brief GUI Address book get / store
*/
2016-12-12 15:39:29 -05:00
std : : vector < address_book_row > get_address_book ( ) const { return m_address_book ; }
2017-02-18 21:42:10 -05:00
bool add_address_book_row ( const cryptonote : : account_public_address & address , const crypto : : hash & payment_id , const std : : string & description , bool is_subaddress ) ;
2016-12-14 16:37:49 -05:00
bool delete_address_book_row ( std : : size_t row_id ) ;
2016-12-11 18:42:46 -05:00
2016-07-27 16:37:58 -04:00
uint64_t get_num_rct_outputs ( ) ;
2017-05-28 07:18:51 -04:00
size_t get_num_transfer_details ( ) const { return m_transfers . size ( ) ; }
2016-10-15 14:18:52 -04:00
const transfer_details & get_transfer_details ( size_t idx ) const ;
2016-07-27 16:37:58 -04:00
2018-01-16 20:58:34 -05:00
void get_hard_fork_info ( uint8_t version , uint64_t & earliest_height ) const ;
bool use_fork_rules ( uint8_t version , int64_t early_blocks = 0 ) const ;
int get_fee_algorithm ( ) const ;
2016-03-11 16:31:50 -05:00
2016-03-11 09:05:36 -05:00
std : : string get_wallet_file ( ) const ;
std : : string get_keys_file ( ) const ;
2016-03-25 10:06:30 -04:00
std : : string get_daemon_address ( ) const ;
2017-02-05 17:48:03 -05:00
const boost : : optional < epee : : net_utils : : http : : login > & get_daemon_login ( ) const { return m_daemon_login ; }
2018-01-16 20:58:34 -05:00
uint64_t get_daemon_blockchain_height ( std : : string & err ) const ;
2016-10-03 14:47:41 -04:00
uint64_t get_daemon_blockchain_target_height ( std : : string & err ) ;
2016-11-10 09:36:16 -05:00
/*!
* \ brief Calculates the approximate blockchain height from current date / time .
*/
uint64_t get_approximate_blockchain_height ( ) const ;
2017-11-16 18:00:06 -05:00
uint64_t estimate_blockchain_height ( ) ;
2017-02-05 16:30:14 -05:00
std : : vector < size_t > select_available_outputs_from_histogram ( uint64_t count , bool atleast , bool unlocked , bool allow_rct , bool trusted_daemon ) ;
2018-01-16 20:58:34 -05:00
std : : vector < size_t > select_available_outputs ( const std : : function < bool ( const transfer_details & td ) > & f ) const ;
2016-04-17 06:20:44 -04:00
std : : vector < size_t > select_available_unmixable_outputs ( bool trusted_daemon ) ;
std : : vector < size_t > select_available_mixable_outputs ( bool trusted_daemon ) ;
2017-10-22 04:54:07 -04: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 17:00:43 -04:00
2016-04-20 13:19:42 -04:00
void set_tx_note ( const crypto : : hash & txid , const std : : string & note ) ;
std : : string get_tx_note ( const crypto : : hash & txid ) const ;
2017-10-08 03:15:06 -04:00
void set_description ( const std : : string & description ) ;
std : : string get_description ( ) const ;
2017-12-14 22:08:36 -05: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 .
*/
void set_account_tag ( const std : : set < uint32_t > account_indices , const std : : string & tag ) ;
/*!
* \ brief Set the label of the given tag .
* \ param tag Tag ' s name ( which must be non - empty ) .
2018-03-14 11:41:24 -04:00
* \ param description Tag ' s description .
2017-12-14 22:08:36 -05:00
*/
void set_account_tag_description ( const std : : string & tag , const std : : string & description ) ;
2016-04-23 16:46:48 -04:00
std : : string sign ( const std : : string & data ) const ;
bool verify ( const std : : string & data , const cryptonote : : account_public_address & address , const std : : string & signature ) const ;
2018-04-10 11:38:54 -04: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 08:27:54 -04:00
// Import/Export wallet data
2016-10-30 15:37:09 -04:00
std : : vector < tools : : wallet2 : : transfer_details > export_outputs ( ) const ;
size_t import_outputs ( const std : : vector < tools : : wallet2 : : transfer_details > & outputs ) ;
2017-08-18 08:27:54 -04: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 09:38:37 -04: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 ) ;
2018-01-16 20:58:34 -05:00
bool export_key_images ( const std : : string & filename ) const ;
2016-07-15 07:11:55 -04:00
std : : vector < std : : pair < crypto : : key_image , crypto : : signature > > export_key_images ( ) const ;
2017-08-18 08:19:07 -04:00
uint64_t import_key_images ( const std : : vector < std : : pair < crypto : : key_image , crypto : : signature > > & signed_key_images , uint64_t & spent , uint64_t & unspent , bool check_spent = true ) ;
2017-01-13 06:02:13 -05:00
uint64_t import_key_images ( const std : : string & filename , uint64_t & spent , uint64_t & unspent ) ;
2016-05-23 16:40:12 -04:00
2017-07-25 04:30:06 -04:00
void update_pool_state ( bool refreshed = false ) ;
2017-08-04 16:38:37 -04:00
void remove_obsolete_pool_txs ( const std : : vector < crypto : : hash > & tx_hashes ) ;
2016-11-07 14:28:15 -05:00
std : : string encrypt ( const std : : string & plaintext , const crypto : : secret_key & skey , bool authenticated = true ) const ;
std : : string encrypt_with_view_secret_key ( const std : : string & plaintext , bool authenticated = true ) const ;
std : : string decrypt ( const std : : string & ciphertext , const crypto : : secret_key & skey , bool authenticated = true ) const ;
std : : string decrypt_with_view_secret_key ( const std : : string & ciphertext , bool authenticated = true ) const ;
2018-01-16 20:58:34 -05: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 09:07:25 -05: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 03:18:15 -05:00
uint64_t get_blockchain_height_by_date ( uint16_t year , uint8_t month , uint8_t day ) ; // 1<=month<=12, 1<=day<=31
2017-08-02 09:44:19 -04:00
bool is_synced ( ) const ;
2018-01-15 07:48:25 -05:00
std : : vector < std : : pair < uint64_t , uint64_t > > estimate_backlog ( const std : : vector < std : : pair < double , double > > & fee_levels ) ;
2017-08-27 16:04:56 -04:00
std : : vector < std : : pair < uint64_t , uint64_t > > estimate_backlog ( uint64_t min_blob_size , uint64_t max_blob_size , const std : : vector < uint64_t > & fees ) ;
2018-01-16 20:58:34 -05:00
uint64_t get_fee_multiplier ( uint32_t priority , int fee_algorithm = - 1 ) const ;
uint64_t get_per_kb_fee ( ) const ;
uint64_t adjust_mixin ( uint64_t mixin ) const ;
2018-01-14 22:05:16 -05:00
uint32_t adjust_priority ( uint32_t priority ) ;
2017-08-26 11:23:54 -04:00
2017-08-04 17:58:08 -04: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
bool light_wallet_get_address_info ( cryptonote : : COMMAND_RPC_GET_ADDRESS_INFO : : response & response ) ;
// 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
bool light_wallet_import_wallet_request ( cryptonote : : COMMAND_RPC_IMPORT_WALLET_REQUEST : : response & response ) ;
// get random outputs from light wallet server
2017-10-22 04:54:07 -04: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 17:58:08 -04: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 03:15:06 -04: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 ) ;
std : : string get_attribute ( const std : : string & key ) const ;
2017-08-13 10:29:31 -04: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-15 20:19:39 -05:00
template < class t_request , class t_response >
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 = " GET " )
{
boost : : lock_guard < boost : : mutex > lock ( m_daemon_rpc_mutex ) ;
return epee : : net_utils : : invoke_http_json ( uri , req , res , m_http_client , timeout , http_method ) ;
}
template < class t_request , class t_response >
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 = " GET " )
{
boost : : lock_guard < boost : : mutex > lock ( m_daemon_rpc_mutex ) ;
return epee : : net_utils : : invoke_http_bin ( uri , req , res , m_http_client , timeout , http_method ) ;
}
template < class t_request , class t_response >
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 = " GET " , const std : : string & req_id = " 0 " )
{
boost : : lock_guard < boost : : mutex > lock ( m_daemon_rpc_mutex ) ;
return epee : : net_utils : : invoke_http_json_rpc ( uri , method_name , req , res , m_http_client , timeout , http_method , req_id ) ;
}
2018-03-21 10:29:49 -04:00
bool set_ring_database ( const std : : string & filename ) ;
2018-02-18 05:47:25 -05:00
const std : : string get_ring_database ( ) const { return m_ring_database ; }
2018-02-27 03:30:59 -05:00
bool get_ring ( const crypto : : key_image & key_image , std : : vector < uint64_t > & outs ) ;
2018-03-14 15:13:55 -04:00
bool get_rings ( const crypto : : hash & txid , std : : vector < std : : pair < crypto : : key_image , std : : vector < uint64_t > > > & outs ) ;
2018-02-28 13:26:06 -05:00
bool set_ring ( const crypto : : key_image & key_image , const std : : vector < uint64_t > & outs , bool relative ) ;
2018-02-27 03:30:59 -05:00
bool find_and_save_rings ( bool force = true ) ;
2018-02-18 05:47:25 -05:00
2018-02-25 14:20:07 -05:00
bool blackball_output ( const crypto : : public_key & output ) ;
bool set_blackballed_outputs ( const std : : vector < crypto : : public_key > & outputs , bool add = false ) ;
bool unblackball_output ( const crypto : : public_key & output ) ;
bool is_output_blackballed ( const crypto : : public_key & output ) const ;
2014-03-03 17:07:58 -05:00
private :
2014-10-18 13:41:05 -04:00
/*!
2014-10-18 15:38:21 -04: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 10:34:55 -04:00
* \ param watch_only true to save only view key , false to save both spend and view keys
2014-10-18 15:38:21 -04:00
* \ return Whether it was successful .
2014-10-18 13:41:05 -04:00
*/
2017-11-25 09:50:15 -05:00
bool store_keys ( const std : : string & keys_file_name , const epee : : wipeable_string & password , bool watch_only = false ) ;
2014-10-18 13:41:05 -04:00
/*!
2014-10-18 15:38:21 -04:00
* \ brief Load wallet information from wallet file .
* \ param keys_file_name Name of wallet file
* \ param password Password of wallet file
2014-10-18 13:41:05 -04:00
*/
2017-11-25 09:50:15 -05:00
bool load_keys ( const std : : string & keys_file_name , const epee : : wipeable_string & password ) ;
2017-09-22 08:57:20 -04:00
void process_new_transaction ( const crypto : : hash & txid , const cryptonote : : transaction & tx , const std : : vector < uint64_t > & o_indices , uint64_t height , uint64_t ts , bool miner_tx , bool pool , bool double_spend_seen ) ;
2016-07-13 14:26:11 -04:00
void process_new_blockchain_entry ( const cryptonote : : block & b , const cryptonote : : block_complete_entry & bche , const crypto : : hash & bl_id , uint64_t height , const cryptonote : : COMMAND_RPC_GET_BLOCKS_FAST : : block_output_indices & o_indices ) ;
2014-04-02 12:00:17 -04:00
void detach_blockchain ( uint64_t height ) ;
2015-05-27 14:00:57 -04:00
void get_short_chain_history ( std : : list < crypto : : hash > & ids ) const ;
2016-01-29 10:09:17 -05:00
bool is_tx_spendtime_unlocked ( uint64_t unlock_time , uint64_t block_height ) const ;
2014-03-03 17:07:58 -05:00
bool clear ( ) ;
2016-07-13 14:26:11 -04:00
void pull_blocks ( uint64_t start_height , uint64_t & blocks_start_height , const std : : list < crypto : : hash > & short_chain_history , std : : list < cryptonote : : block_complete_entry > & blocks , std : : vector < cryptonote : : COMMAND_RPC_GET_BLOCKS_FAST : : block_output_indices > & o_indices ) ;
2016-04-13 18:45:02 -04:00
void pull_hashes ( uint64_t start_height , uint64_t & blocks_start_height , const std : : list < crypto : : hash > & short_chain_history , std : : list < crypto : : hash > & hashes ) ;
void fast_refresh ( uint64_t stop_height , uint64_t & blocks_start_height , std : : list < crypto : : hash > & short_chain_history ) ;
2016-07-13 14:26:11 -04:00
void pull_next_blocks ( uint64_t start_height , uint64_t & blocks_start_height , std : : list < crypto : : hash > & short_chain_history , const std : : list < cryptonote : : block_complete_entry > & prev_blocks , std : : list < cryptonote : : block_complete_entry > & blocks , std : : vector < cryptonote : : COMMAND_RPC_GET_BLOCKS_FAST : : block_output_indices > & o_indices , bool & error ) ;
void process_blocks ( uint64_t start_height , const std : : list < cryptonote : : block_complete_entry > & blocks , const std : : vector < cryptonote : : COMMAND_RPC_GET_BLOCKS_FAST : : block_output_indices > & o_indices , uint64_t & blocks_added ) ;
2018-01-16 20:58:34 -05:00
uint64_t select_transfers ( uint64_t needed_money , std : : vector < size_t > unused_transfers_indices , std : : vector < size_t > & selected_transfers , bool trusted_daemon ) const ;
2014-03-03 17:07:58 -05:00
bool prepare_file_names ( const std : : string & file_path ) ;
2017-02-27 15:26:17 -05:00
void process_unconfirmed ( const crypto : : hash & txid , const cryptonote : : transaction & tx , uint64_t height ) ;
2017-02-18 21:42:10 -05: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-16 20:58:34 -05:00
void generate_genesis ( cryptonote : : block & b ) const ;
2015-05-27 14:00:57 -04:00
void check_genesis ( const crypto : : hash & genesis_hash ) const ; //throws
2017-12-07 08:27:11 -05:00
bool generate_chacha_key_from_secret_keys ( crypto : : chacha_key & key ) const ;
2015-11-22 07:13:59 -05:00
crypto : : hash get_payment_id ( const pending_tx & ptx ) const ;
2017-02-18 21:42:10 -05: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 ;
2015-11-22 10:18:36 -05:00
void parse_block_round ( const cryptonote : : blobdata & blob , cryptonote : : block & bl , crypto : : hash & bl_id , bool & error ) const ;
2018-01-16 20:58:34 -05:00
uint64_t get_upper_transaction_size_limit ( ) const ;
std : : vector < uint64_t > get_unspent_amounts_vector ( ) const ;
uint64_t get_dynamic_per_kb_fee_estimate ( ) const ;
2016-07-02 12:37:39 -04:00
float get_output_relatedness ( const transfer_details & td0 , const transfer_details & td1 ) const ;
2017-02-18 21:42:10 -05: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 18:11:10 -04:00
void set_spent ( size_t idx , uint64_t height ) ;
void set_unspent ( size_t idx ) ;
2017-10-22 04:54:07 -04:00
void 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 17:12:37 -04: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 ;
2016-11-19 04:36:40 -05:00
crypto : : public_key get_tx_pub_key_from_received_outs ( const tools : : wallet2 : : transfer_details & td ) const ;
2017-03-20 04:44:28 -04: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 ;
2018-01-16 20:08:18 -05:00
void scan_output ( const cryptonote : : transaction & 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 ) const ;
2017-09-11 09:38:37 -04:00
void trim_hashchain ( ) ;
2017-08-13 10:29:31 -04:00
crypto : : key_image get_multisig_composite_key_image ( size_t n ) const ;
rct : : multisig_kLRki get_multisig_composite_kLRki ( size_t n , const crypto : : public_key & ignore , std : : unordered_set < rct : : key > & used_L , std : : unordered_set < rct : : key > & new_used_L ) const ;
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 03:30:59 -05: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 ) ;
2014-03-03 17:07:58 -05:00
2018-02-19 06:15:15 -05:00
bool get_output_distribution ( uint64_t & start_height , std : : vector < uint64_t > & distribution ) ;
2018-03-13 15:38:52 -04:00
uint64_t get_segregation_fork_height ( ) const ;
2014-03-03 17:07:58 -05:00
cryptonote : : account_base m_account ;
2017-02-05 17:48:03 -05:00
boost : : optional < epee : : net_utils : : http : : login > m_daemon_login ;
2014-03-03 17:07:58 -05:00
std : : string m_daemon_address ;
std : : string m_wallet_file ;
std : : string m_keys_file ;
epee : : net_utils : : http : : http_simple_client m_http_client ;
2017-09-11 09:38:37 -04:00
hashchain m_blockchain ;
2014-05-03 12:19:43 -04:00
std : : atomic < uint64_t > m_local_bc_height ; //temporary workaround
2014-04-02 12:00:17 -04:00
std : : unordered_map < crypto : : hash , unconfirmed_transfer_details > m_unconfirmed_txs ;
2015-11-15 16:59:40 -05:00
std : : unordered_map < crypto : : hash , confirmed_transfer_details > m_confirmed_txs ;
2017-09-22 08:57:20 -04:00
std : : unordered_multimap < crypto : : hash , pool_payment_details > m_unconfirmed_payments ;
2015-08-19 15:59:44 -04:00
std : : unordered_map < crypto : : hash , crypto : : secret_key > m_tx_keys ;
2017-09-11 09:38:37 -04:00
cryptonote : : checkpoints m_checkpoints ;
2017-02-18 21:42:10 -05:00
std : : unordered_map < crypto : : hash , std : : vector < crypto : : secret_key > > m_additional_tx_keys ;
2014-03-03 17:07:58 -05:00
transfer_container m_transfers ;
2014-05-03 12:19:43 -04:00
payment_container m_payments ;
2014-03-03 17:07:58 -05:00
std : : unordered_map < crypto : : key_image , size_t > m_key_images ;
2016-11-07 13:50:05 -05:00
std : : unordered_map < crypto : : public_key , size_t > m_pub_keys ;
2014-03-03 17:07:58 -05:00
cryptonote : : account_public_address m_account_public_address ;
2017-02-18 21:42:10 -05:00
std : : unordered_map < crypto : : public_key , cryptonote : : subaddress_index > m_subaddresses ;
std : : vector < std : : vector < std : : string > > m_subaddress_labels ;
2016-04-20 13:19:42 -04:00
std : : unordered_map < crypto : : hash , std : : string > m_tx_notes ;
2017-10-08 03:15:06 -04:00
std : : unordered_map < std : : string , std : : string > m_attributes ;
2016-12-12 15:39:29 -05:00
std : : vector < tools : : wallet2 : : address_book_row > m_address_book ;
2017-12-14 22:08:36 -05:00
std : : pair < std : : map < std : : string , std : : string > , std : : vector < std : : string > > m_account_tags ;
2014-03-03 17:07:58 -05:00
uint64_t m_upper_transaction_size_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 17:34:26 -04:00
const std : : vector < std : : vector < tools : : wallet2 : : multisig_info > > * m_multisig_rescan_info ;
2017-08-13 10:29:31 -04:00
const std : : vector < std : : vector < rct : : key > > * m_multisig_rescan_k ;
2014-03-20 07:46:11 -04:00
std : : atomic < bool > m_run ;
2014-04-02 12:00:17 -04:00
2016-03-11 07:25:28 -05:00
boost : : mutex m_daemon_rpc_mutex ;
2015-11-27 12:25:15 -05:00
2014-04-02 12:00:17 -04:00
i_wallet2_callback * m_callback ;
2018-02-20 11:01:27 -05:00
bool m_key_on_device ;
2018-02-16 06:04:04 -05:00
cryptonote : : network_type m_nettype ;
2015-01-11 06:06:35 -05:00
bool m_restricted ;
2014-10-18 13:41:05 -04: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 10:34:55 -04:00
bool m_watch_only ; /*!< no spend key */
2017-05-28 07:18:51 -04:00
bool m_multisig ; /*!< if > 1 spend secret key will not match spend public key */
uint32_t m_multisig_threshold ;
2017-08-13 10:29:31 -04:00
std : : vector < crypto : : public_key > m_multisig_signers ;
2015-07-18 17:03:35 -04:00
bool m_always_confirm_transfers ;
2016-12-23 07:04:54 -05:00
bool m_print_ring_members ;
2015-11-22 07:26:27 -05:00
bool m_store_tx_info ; /*!< request txkey to be returned in RPC, and store in the wallet cache file */
2015-10-30 17:16:51 -04:00
uint32_t m_default_mixin ;
2016-09-16 06:50:52 -04:00
uint32_t m_default_priority ;
2015-11-22 14:03:10 -05:00
RefreshType m_refresh_type ;
2015-11-28 07:38:58 -05:00
bool m_auto_refresh ;
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-24 20:48:11 -04:00
uint64_t m_refresh_from_block_height ;
2018-01-23 09:42:11 -05: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 ;
2016-10-01 12:03:53 -04:00
bool m_confirm_missing_payment_id ;
2018-03-31 09:20:48 -04:00
bool m_confirm_non_default_ring_size ;
2017-01-27 07:26:52 -05:00
bool 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 16:58:02 -04:00
uint32_t m_min_output_count ;
uint64_t m_min_output_value ;
2017-03-24 17:56:58 -04:00
bool m_merge_destinations ;
2017-08-26 11:23:54 -04:00
bool m_confirm_backlog ;
2017-09-18 07:46:33 -04:00
uint32_t m_confirm_backlog_threshold ;
2018-01-14 18:36:13 -05:00
bool m_confirm_export_overwrite ;
2018-01-14 22:05:16 -05:00
bool m_auto_low_priority ;
2018-02-19 05:23:23 -05:00
bool m_segregate_pre_fork_outputs ;
bool m_key_reuse_mitigation2 ;
2018-03-13 15:38:52 -04:00
uint64_t m_segregation_height ;
2017-06-03 20:56:51 -04:00
bool m_is_initialized ;
2017-01-07 14:23:57 -05:00
NodeRPCProxy m_node_rpc_proxy ;
2017-03-21 06:30:25 -04:00
std : : unordered_set < crypto : : hash > m_scanned_pool_txs [ 2 ] ;
2017-10-21 13:31:30 -04:00
size_t m_subaddress_lookahead_major , m_subaddress_lookahead_minor ;
2017-08-04 16:36:27 -04: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 05:47:25 -05:00
std : : string m_ring_database ;
bool m_ring_history_saved ;
2018-02-27 03:30:59 -05:00
std : : unique_ptr < ringdb > m_ringdb ;
2014-03-03 17:07:58 -05:00
} ;
}
2018-02-18 05:47:25 -05:00
BOOST_CLASS_VERSION ( tools : : wallet2 , 24 )
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 17:34:26 -04:00
BOOST_CLASS_VERSION ( tools : : wallet2 : : transfer_details , 9 )
BOOST_CLASS_VERSION ( tools : : wallet2 : : multisig_info , 1 )
2017-08-13 10:29:31 -04: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 17:34:26 -04:00
BOOST_CLASS_VERSION ( tools : : wallet2 : : multisig_tx_set , 1 )
2018-01-13 23:37:57 -05:00
BOOST_CLASS_VERSION ( tools : : wallet2 : : payment_details , 3 )
2017-09-22 08:57:20 -04:00
BOOST_CLASS_VERSION ( tools : : wallet2 : : pool_payment_details , 1 )
2018-03-14 15:13:55 -04:00
BOOST_CLASS_VERSION ( tools : : wallet2 : : unconfirmed_transfer_details , 8 )
BOOST_CLASS_VERSION ( tools : : wallet2 : : confirmed_transfer_details , 6 )
2017-02-18 21:42:10 -05:00
BOOST_CLASS_VERSION ( tools : : wallet2 : : address_book_row , 17 )
2017-12-28 08:50:10 -05:00
BOOST_CLASS_VERSION ( tools : : wallet2 : : reserve_proof_entry , 0 )
2016-12-30 08:51:43 -05:00
BOOST_CLASS_VERSION ( tools : : wallet2 : : unsigned_tx_set , 0 )
BOOST_CLASS_VERSION ( tools : : wallet2 : : signed_tx_set , 0 )
2017-10-22 04:54:07 -04:00
BOOST_CLASS_VERSION ( tools : : wallet2 : : tx_construction_data , 2 )
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 17:34:26 -04:00
BOOST_CLASS_VERSION ( tools : : wallet2 : : pending_tx , 3 )
2017-08-13 10:29:31 -04:00
BOOST_CLASS_VERSION ( tools : : wallet2 : : multisig_sig , 0 )
2014-03-03 17:07:58 -05:00
namespace boost
{
namespace serialization
{
2016-06-15 18:37:13 -04:00
template < class Archive >
2016-12-16 04:10:03 -05: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 18:37:13 -04:00
{
}
2016-12-16 04:10:03 -05: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 18:37:13 -04:00
{
2016-06-16 18:58:54 -04: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 13:45:07 -04:00
if ( ver < 4 )
{
x . m_rct = x . m_tx . vout [ x . m_internal_output_index ] . amount = = 0 ;
}
2016-11-13 06:34:43 -05:00
if ( ver < 6 )
{
x . m_key_image_known = true ;
}
2016-12-09 13:21:21 -05:00
if ( ver < 7 )
{
x . m_pk_index = 0 ;
}
2017-02-18 21:42:10 -05: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 17:34:26 -04:00
if ( ver < 9 )
{
x . m_key_image_partial = false ;
2017-08-13 10:29:31 -04: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 17:34:26 -04:00
x . m_multisig_info . clear ( ) ;
}
2016-06-15 18:37:13 -04:00
}
2014-03-03 17:07:58 -05: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 14:19:25 -04: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 17:07:58 -05:00
a & x . m_spent ;
a & x . m_key_image ;
2016-06-15 18:37:13 -04:00
if ( ver < 1 )
{
// ensure mask and amount are set
2016-06-16 18:58:54 -04:00
initialize_transfer_details ( a , x , ver ) ;
2016-06-15 18:37:13 -04:00
return ;
}
a & x . m_mask ;
a & x . m_amount ;
2016-06-16 18:58:54 -04:00
if ( ver < 2 )
{
initialize_transfer_details ( a , x , ver ) ;
return ;
}
a & x . m_spent_height ;
2016-08-06 14:19:25 -04:00
if ( ver < 3 )
2016-08-12 13:45:07 -04:00
{
initialize_transfer_details ( a , x , ver ) ;
2016-08-06 14:19:25 -04:00
return ;
2016-08-12 13:45:07 -04:00
}
2016-08-06 14:19:25 -04:00
a & x . m_txid ;
2016-08-12 13:45:07 -04:00
if ( ver < 4 )
{
initialize_transfer_details ( a , x , ver ) ;
return ;
}
a & x . m_rct ;
2016-11-07 13:50:05 -05:00
if ( ver < 5 )
2016-11-13 06:34:43 -05:00
{
initialize_transfer_details ( a , x , ver ) ;
2016-11-07 13:50:05 -05:00
return ;
2016-11-13 06:34:43 -05:00
}
if ( ver < 6 )
{
// v5 did not properly initialize
uint8_t u ;
a & u ;
x . m_key_image_known = true ;
return ;
}
2016-11-07 13:50:05 -05:00
a & x . m_key_image_known ;
2016-12-09 13:21:21 -05:00
if ( ver < 7 )
{
initialize_transfer_details ( a , x , ver ) ;
return ;
}
a & x . m_pk_index ;
2017-02-18 21:42:10 -05: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 17:34:26 -04: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 ;
}
template < class Archive >
2017-08-13 10:29:31 -04: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 17:34:26 -04:00
{
a & x . m_L ;
a & x . m_R ;
}
2017-08-13 10:29:31 -04: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 17:34:26 -04: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 17:07:58 -05:00
}
2014-04-02 12:00:17 -04: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 14:19:25 -04: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 08:51:55 -05:00
if ( ver < 1 )
2015-11-22 07:13:59 -05:00
return ;
a & x . m_dests ;
a & x . m_payment_id ;
2016-01-29 14:44:48 -05:00
if ( ver < 2 )
return ;
a & x . m_state ;
2016-04-19 16:18:43 -04:00
if ( ver < 3 )
return ;
a & x . m_timestamp ;
2016-06-15 18:37:13 -04:00
if ( ver < 4 )
return ;
a & x . m_amount_in ;
a & x . m_amount_out ;
2016-11-02 19:11:30 -04: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-18 21:42:10 -05:00
if ( ver < 7 )
2017-10-23 06:53:49 -04:00
{
x . m_subaddr_account = 0 ;
2017-02-18 21:42:10 -05:00
return ;
2017-10-23 06:53:49 -04:00
}
2017-02-18 21:42:10 -05:00
a & x . m_subaddr_account ;
a & x . m_subaddr_indices ;
2018-03-14 15:13:55 -04:00
if ( ver < 8 )
return ;
a & x . m_rings ;
2014-04-02 12:00:17 -04:00
}
2015-11-15 16:59:40 -05: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 08:51:55 -05:00
if ( ver < 1 )
2015-11-22 07:13:59 -05:00
return ;
a & x . m_dests ;
a & x . m_payment_id ;
2016-04-19 16:18:43 -04:00
if ( ver < 2 )
return ;
a & x . m_timestamp ;
2016-11-02 19:11:30 -04: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 11:28:48 -04:00
if ( ver < 4 )
{
if ( ! typename Archive : : is_saving ( ) )
x . m_unlock_time = 0 ;
return ;
}
a & x . m_unlock_time ;
2017-02-18 21:42:10 -05:00
if ( ver < 5 )
2017-10-23 06:53:49 -04:00
{
x . m_subaddr_account = 0 ;
2017-02-18 21:42:10 -05:00
return ;
2017-10-23 06:53:49 -04:00
}
2017-02-18 21:42:10 -05:00
a & x . m_subaddr_account ;
a & x . m_subaddr_indices ;
2018-03-14 15:13:55 -04:00
if ( ver < 6 )
return ;
a & x . m_rings ;
2015-11-15 16:59:40 -05:00
}
2014-05-03 12:19:43 -04: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 16:18:43 -04:00
if ( ver < 1 )
return ;
a & x . m_timestamp ;
2017-02-18 21:42:10 -05:00
if ( ver < 2 )
2017-10-23 06:53:49 -04:00
{
x . m_subaddr_index = { } ;
2017-02-18 21:42:10 -05:00
return ;
2017-10-23 06:53:49 -04:00
}
2017-02-18 21:42:10 -05:00
a & x . m_subaddr_index ;
2018-01-13 23:37:57 -05:00
if ( ver < 3 )
{
x . m_fee = 0 ;
return ;
}
a & x . m_fee ;
2015-11-22 07:13:59 -05:00
}
2017-09-22 08:57:20 -04: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 18:42:46 -05: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 ;
a & x . m_payment_id ;
a & x . m_description ;
2017-02-18 21:42:10 -05:00
if ( ver < 17 )
2017-10-23 06:53:49 -04:00
{
x . m_is_subaddress = false ;
2017-02-18 21:42:10 -05:00
return ;
2017-10-23 06:53:49 -04:00
}
2017-02-18 21:42:10 -05:00
a & x . m_is_subaddress ;
2016-12-11 18:42:46 -05:00
}
2017-12-28 08:50:10 -05: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 08:51:43 -05: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 ;
}
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 04:54:07 -04: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 08:51:43 -05:00
a & x . extra ;
a & x . unlock_time ;
a & x . use_rct ;
a & x . dests ;
2017-02-18 21:42:10 -05:00
if ( ver < 1 )
2017-10-23 06:53:49 -04:00
{
x . subaddr_account = 0 ;
2017-02-18 21:42:10 -05:00
return ;
2017-10-23 06:53:49 -04:00
}
2017-02-18 21:42:10 -05:00
a & x . subaddr_account ;
a & x . subaddr_indices ;
2017-10-22 04:54:07 -04:00
if ( ver < 2 )
return ;
a & x . selected_transfers ;
2016-12-30 08:51:43 -05:00
}
2017-08-13 10:29:31 -04: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 08:51:43 -05: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 04:54:07 -04: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 08:51:43 -05:00
a & x . key_images ;
a & x . tx_key ;
a & x . dests ;
a & x . construction_data ;
2017-02-18 21:42:10 -05:00
if ( ver < 1 )
return ;
a & x . additional_tx_keys ;
2017-10-22 04:54:07 -04: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 17:34:26 -04:00
if ( ver < 3 )
return ;
2017-08-13 10:29:31 -04:00
a & x . multisig_sigs ;
2016-12-30 08:51:43 -05:00
}
2014-03-03 17:07:58 -05:00
}
}
namespace tools
{
2014-06-04 18:59:47 -04:00
2014-03-03 17:07:58 -05: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 11:22:19 -04:00
std : : vector < cryptonote : : tx_destination_entry > & splitted_dsts , std : : vector < cryptonote : : tx_destination_entry > & dust_dsts )
2014-03-03 17:07:58 -05:00
{
splitted_dsts . clear ( ) ;
2015-10-06 11:22:19 -04:00
dust_dsts . clear ( ) ;
2014-03-03 17:07:58 -05:00
2017-01-22 15:38:10 -05:00
for ( auto & de : dsts )
2014-03-03 17:07:58 -05:00
{
2015-10-06 11:22:19 -04:00
cryptonote : : decompose_amount_into_digits ( de . amount , 0 ,
2017-02-18 21:42:10 -05: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 17:07:58 -05:00
}
2015-10-06 11:22:19 -04:00
cryptonote : : decompose_amount_into_digits ( change_dst . amount , 0 ,
[ & ] ( uint64_t chunk ) {
if ( chunk < = dust_threshold )
2017-02-18 21:42:10 -05:00
dust_dsts . push_back ( cryptonote : : tx_destination_entry ( chunk , change_dst . addr , false ) ) ;
2015-10-06 11:22:19 -04:00
else
2017-02-18 21:42:10 -05:00
splitted_dsts . push_back ( cryptonote : : tx_destination_entry ( chunk , change_dst . addr , false ) ) ;
2015-10-06 11:22:19 -04:00
} ,
2017-02-18 21:42:10 -05:00
[ & ] ( uint64_t a_dust ) { dust_dsts . push_back ( cryptonote : : tx_destination_entry ( a_dust , change_dst . addr , false ) ) ; } ) ;
2014-03-03 17:07:58 -05: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 11:22:19 -04:00
std : : vector < cryptonote : : tx_destination_entry > & splitted_dsts , std : : vector < cryptonote : : tx_destination_entry > & dust_dsts )
2014-03-03 17:07:58 -05:00
{
splitted_dsts = dsts ;
2015-10-06 11:22:19 -04:00
dust_dsts . clear ( ) ;
2014-03-03 17:07:58 -05:00
uint64_t change = change_dst . amount ;
if ( 0 ! = change )
{
2017-02-18 21:42:10 -05:00
splitted_dsts . push_back ( cryptonote : : tx_destination_entry ( change , change_dst . addr , false ) ) ;
2014-03-03 17:07:58 -05: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 07:46:11 -04: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 17:07:58 -05:00
}
//----------------------------------------------------------------------------------------------------
}
//----------------------------------------------------------------------------------------------------
template < typename T >
2016-04-02 08:06:39 -04:00
void wallet2 : : transfer ( const std : : vector < cryptonote : : tx_destination_entry > & dsts , const size_t fake_outs_count , const std : : vector < size_t > & unused_transfers_indices ,
uint64_t unlock_time , uint64_t fee , const std : : vector < uint8_t > & extra , T destination_split_strategy , const tx_dust_policy & dust_policy , bool trusted_daemon )
2014-03-03 17:07:58 -05:00
{
2014-06-15 20:36:44 -04:00
pending_tx ptx ;
2014-03-03 17:07:58 -05:00
cryptonote : : transaction tx ;
2016-04-02 08:06:39 -04:00
transfer ( dsts , fake_outs_count , unused_transfers_indices , unlock_time , fee , extra , destination_split_strategy , dust_policy , tx , ptx , trusted_daemon ) ;
2014-03-03 17:07:58 -05:00
}
template < typename T >
2017-02-18 21:42:10 -05:00
void wallet2 : : transfer ( const std : : vector < cryptonote : : tx_destination_entry > & dsts , const size_t fake_outputs_count , const std : : vector < size_t > & unused_transfers_indices ,
2016-04-02 08:06:39 -04: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 , bool trusted_daemon )
2014-03-03 17:07:58 -05:00
{
using namespace cryptonote ;
2014-06-13 14:05:15 -04:00
// throw if attempting a transaction with no destinations
2014-04-07 11:02:15 -04:00
THROW_WALLET_EXCEPTION_IF ( dsts . empty ( ) , error : : zero_destination ) ;
2014-03-03 17:07:58 -05:00
2017-08-13 10:29:31 -04:00
THROW_WALLET_EXCEPTION_IF ( m_multisig , error : : wallet_internal_error , " Multisig wallets cannot spend non rct outputs " ) ;
2017-05-09 11:02:57 -04:00
uint64_t upper_transaction_size_limit = get_upper_transaction_size_limit ( ) ;
2014-03-03 17:07:58 -05:00
uint64_t needed_money = fee ;
2014-06-13 14:05:15 -04:00
// calculate total amount being sent to all destinations
// throw if total amount overflows uint64_t
2017-01-22 15:38:10 -05:00
for ( auto & dt : dsts )
2014-03-03 17:07:58 -05:00
{
2014-04-07 11:02:15 -04:00
THROW_WALLET_EXCEPTION_IF ( 0 = = dt . amount , error : : zero_destination ) ;
2014-03-03 17:07:58 -05:00
needed_money + = dt . amount ;
2018-02-16 06:04:04 -05:00
THROW_WALLET_EXCEPTION_IF ( needed_money < dt . amount , error : : tx_sum_overflow , dsts , fee , m_nettype ) ;
2014-03-03 17:07:58 -05:00
}
2014-06-13 14:05:15 -04:00
// randomly select inputs for transaction
2017-10-16 09:13:23 -04:00
// throw if requested send amount is greater than (unlocked) amount available to send
2017-10-22 04:54:07 -04:00
std : : vector < size_t > selected_transfers ;
2016-04-02 08:06:39 -04:00
uint64_t found_money = select_transfers ( needed_money , unused_transfers_indices , selected_transfers , trusted_daemon ) ;
2017-10-16 09:13:23 -04:00
THROW_WALLET_EXCEPTION_IF ( found_money < needed_money , error : : not_enough_unlocked_money , found_money , needed_money - fee , fee ) ;
2014-03-03 17:07:58 -05:00
2017-02-18 21:42:10 -05:00
uint32_t subaddr_account = m_transfers [ * selected_transfers . begin ( ) ] . m_subaddr_index . major ;
for ( auto i = + + selected_transfers . begin ( ) ; i ! = selected_transfers . end ( ) ; + + i )
THROW_WALLET_EXCEPTION_IF ( subaddr_account ! = * i , error : : wallet_internal_error , " the tx uses funds from multiple accounts " ) ;
2014-03-03 17:07:58 -05:00
typedef COMMAND_RPC_GET_RANDOM_OUTPUTS_FOR_AMOUNTS : : out_entry out_entry ;
typedef cryptonote : : tx_source_entry : : output_entry tx_output_entry ;
COMMAND_RPC_GET_RANDOM_OUTPUTS_FOR_AMOUNTS : : response daemon_resp = AUTO_VAL_INIT ( daemon_resp ) ;
if ( fake_outputs_count )
{
COMMAND_RPC_GET_RANDOM_OUTPUTS_FOR_AMOUNTS : : request req = AUTO_VAL_INIT ( req ) ;
req . outs_count = fake_outputs_count + 1 ; // add one to make possible (if need) to skip real output key
2017-01-22 15:38:10 -05:00
for ( size_t idx : selected_transfers )
2014-03-03 17:07:58 -05:00
{
2016-09-26 18:11:10 -04:00
const transfer_container : : const_iterator it = m_transfers . begin ( ) + idx ;
2014-04-07 11:02:15 -04:00
THROW_WALLET_EXCEPTION_IF ( it - > m_tx . vout . size ( ) < = it - > m_internal_output_index , error : : wallet_internal_error ,
2014-04-02 12:00:17 -04:00
" m_internal_output_index = " + std : : to_string ( it - > m_internal_output_index ) +
" is greater or equal to outputs count = " + std : : to_string ( it - > m_tx . vout . size ( ) ) ) ;
2014-03-03 17:07:58 -05:00
req . amounts . push_back ( it - > amount ( ) ) ;
}
2014-03-20 07:46:11 -04:00
2015-11-27 12:25:15 -05:00
m_daemon_rpc_mutex . lock ( ) ;
2017-01-25 00:16:05 -05:00
bool r = epee : : net_utils : : invoke_http_bin ( " /getrandom_outs.bin " , req , daemon_resp , m_http_client , rpc_timeout ) ;
2015-11-27 12:25:15 -05:00
m_daemon_rpc_mutex . unlock ( ) ;
2014-04-07 11:02:15 -04:00
THROW_WALLET_EXCEPTION_IF ( ! r , error : : no_connection_to_daemon , " getrandom_outs.bin " ) ;
THROW_WALLET_EXCEPTION_IF ( daemon_resp . status = = CORE_RPC_STATUS_BUSY , error : : daemon_busy , " getrandom_outs.bin " ) ;
THROW_WALLET_EXCEPTION_IF ( daemon_resp . status ! = CORE_RPC_STATUS_OK , error : : get_random_outs_error , daemon_resp . status ) ;
THROW_WALLET_EXCEPTION_IF ( daemon_resp . outs . size ( ) ! = selected_transfers . size ( ) , error : : wallet_internal_error ,
2014-04-02 12:00:17 -04:00
" daemon returned wrong response for getrandom_outs.bin, wrong amounts count = " +
std : : to_string ( daemon_resp . outs . size ( ) ) + " , expected " + std : : to_string ( selected_transfers . size ( ) ) ) ;
2016-08-02 16:48:09 -04:00
std : : unordered_map < uint64_t , uint64_t > scanty_outs ;
2017-01-22 15:38:10 -05:00
for ( COMMAND_RPC_GET_RANDOM_OUTPUTS_FOR_AMOUNTS : : outs_for_amount & amount_outs : daemon_resp . outs )
2014-03-20 07:46:11 -04:00
{
2014-04-02 12:00:17 -04:00
if ( amount_outs . outs . size ( ) < fake_outputs_count )
2014-03-20 07:46:11 -04:00
{
2016-08-02 16:48:09 -04:00
scanty_outs [ amount_outs . amount ] = amount_outs . outs . size ( ) ;
2014-03-20 07:46:11 -04:00
}
}
2014-04-07 11:02:15 -04:00
THROW_WALLET_EXCEPTION_IF ( ! scanty_outs . empty ( ) , error : : not_enough_outs_to_mix , scanty_outs , fake_outputs_count ) ;
2014-03-03 17:07:58 -05:00
}
2014-05-03 12:19:43 -04:00
2014-03-03 17:07:58 -05:00
//prepare inputs
size_t i = 0 ;
std : : vector < cryptonote : : tx_source_entry > sources ;
2017-01-22 15:38:10 -05:00
for ( size_t idx : selected_transfers )
2014-03-03 17:07:58 -05:00
{
sources . resize ( sources . size ( ) + 1 ) ;
cryptonote : : tx_source_entry & src = sources . back ( ) ;
2016-09-26 18:11:10 -04:00
const transfer_details & td = m_transfers [ idx ] ;
2014-03-03 17:07:58 -05:00
src . amount = td . amount ( ) ;
2016-08-12 13:45:07 -04:00
src . rct = false ;
2014-03-03 17:07:58 -05:00
//paste mixin transaction
if ( daemon_resp . outs . size ( ) )
{
daemon_resp . outs [ i ] . outs . sort ( [ ] ( const out_entry & a , const out_entry & b ) { return a . global_amount_index < b . global_amount_index ; } ) ;
2017-01-22 15:38:10 -05:00
for ( out_entry & daemon_oe : daemon_resp . outs [ i ] . outs )
2014-03-03 17:07:58 -05:00
{
if ( td . m_global_output_index = = daemon_oe . global_amount_index )
continue ;
tx_output_entry oe ;
oe . first = daemon_oe . global_amount_index ;
2016-06-15 18:37:13 -04:00
oe . second . dest = rct : : pk2rct ( daemon_oe . out_key ) ;
oe . second . mask = rct : : identity ( ) ;
2014-03-03 17:07:58 -05:00
src . outputs . push_back ( oe ) ;
if ( src . outputs . size ( ) > = fake_outputs_count )
break ;
}
}
//paste real transaction to the random index
auto it_to_insert = std : : find_if ( src . outputs . begin ( ) , src . outputs . end ( ) , [ & ] ( const tx_output_entry & a )
{
return a . first > = td . m_global_output_index ;
} ) ;
//size_t real_index = src.outputs.size() ? (rand() % src.outputs.size() ):0;
tx_output_entry real_oe ;
real_oe . first = td . m_global_output_index ;
2016-06-15 18:37:13 -04:00
real_oe . second . dest = rct : : pk2rct ( boost : : get < txout_to_key > ( td . m_tx . vout [ td . m_internal_output_index ] . target ) . key ) ;
real_oe . second . mask = rct : : identity ( ) ;
2014-03-03 17:07:58 -05:00
auto interted_it = src . outputs . insert ( it_to_insert , real_oe ) ;
src . real_out_tx_key = get_tx_pub_key_from_extra ( td . m_tx ) ;
src . real_output = interted_it - src . outputs . begin ( ) ;
src . real_output_in_tx_index = td . m_internal_output_index ;
2017-08-13 10:29:31 -04:00
src . multisig_kLRki = rct : : multisig_kLRki ( { rct : : zero ( ) , rct : : zero ( ) , rct : : zero ( ) , rct : : zero ( ) } ) ;
2014-03-03 17:07:58 -05:00
detail : : print_source_entry ( src ) ;
+ + i ;
}
cryptonote : : tx_destination_entry change_dts = AUTO_VAL_INIT ( change_dts ) ;
if ( needed_money < found_money )
{
2017-02-18 21:42:10 -05:00
change_dts . addr = get_subaddress ( { subaddr_account , 0 } ) ;
2014-03-03 17:07:58 -05:00
change_dts . amount = found_money - needed_money ;
}
2015-10-06 11:22:19 -04:00
std : : vector < cryptonote : : tx_destination_entry > splitted_dsts , dust_dsts ;
2014-03-03 17:07:58 -05:00
uint64_t dust = 0 ;
2015-10-06 11:22:19 -04:00
destination_split_strategy ( dsts , change_dts , dust_policy . dust_threshold , splitted_dsts , dust_dsts ) ;
2017-01-22 15:38:10 -05:00
for ( auto & d : dust_dsts ) {
2015-10-06 11:22:19 -04:00
THROW_WALLET_EXCEPTION_IF ( dust_policy . dust_threshold < d . amount , error : : wallet_internal_error , " invalid dust value: dust = " +
std : : to_string ( d . amount ) + " , dust_threshold = " + std : : to_string ( dust_policy . dust_threshold ) ) ;
}
2017-01-22 15:38:10 -05:00
for ( auto & d : dust_dsts ) {
2015-10-06 11:22:19 -04:00
if ( ! dust_policy . add_to_fee )
2017-02-18 21:42:10 -05:00
splitted_dsts . push_back ( cryptonote : : tx_destination_entry ( d . amount , dust_policy . addr_for_dust , d . is_subaddress ) ) ;
2015-10-06 11:22:19 -04:00
dust + = d . amount ;
2014-03-03 17:07:58 -05:00
}
2014-03-20 07:46:11 -04:00
2015-08-19 15:59:44 -04:00
crypto : : secret_key tx_key ;
2017-02-18 21:42:10 -05:00
std : : vector < crypto : : secret_key > additional_tx_keys ;
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 17:34:26 -04:00
rct : : multisig_out msout ;
bool r = cryptonote : : construct_tx_and_get_tx_key ( m_account . get_keys ( ) , m_subaddresses , sources , splitted_dsts , change_dts . addr , extra , tx , unlock_time , tx_key , additional_tx_keys , false , false , m_multisig ? & msout : NULL ) ;
2018-02-16 06:04:04 -05:00
THROW_WALLET_EXCEPTION_IF ( ! r , error : : tx_not_constructed , sources , splitted_dsts , unlock_time , m_nettype ) ;
2016-01-10 06:56:13 -05:00
THROW_WALLET_EXCEPTION_IF ( upper_transaction_size_limit < = get_object_blobsize ( tx ) , error : : tx_too_big , tx , upper_transaction_size_limit ) ;
2014-03-03 17:07:58 -05:00
2014-04-02 12:00:17 -04:00
std : : string key_images ;
bool all_are_txin_to_key = std : : all_of ( tx . vin . begin ( ) , tx . vin . end ( ) , [ & ] ( const txin_v & s_e ) - > bool
2014-03-03 17:07:58 -05:00
{
2014-04-02 12:00:17 -04:00
CHECKED_GET_SPECIFIC_VARIANT ( s_e , const txin_to_key , in , false ) ;
key_images + = boost : : to_string ( in . k_image ) + " " ;
return true ;
} ) ;
2014-04-07 11:02:15 -04:00
THROW_WALLET_EXCEPTION_IF ( ! all_are_txin_to_key , error : : unexpected_txin_type , tx ) ;
2016-04-17 22:57:47 -04:00
bool dust_sent_elsewhere = ( dust_policy . addr_for_dust . m_view_public_key ! = change_dts . addr . m_view_public_key
| | dust_policy . addr_for_dust . m_spend_public_key ! = change_dts . addr . m_spend_public_key ) ;
if ( dust_policy . add_to_fee | | dust_sent_elsewhere ) change_dts . amount - = dust ;
2014-03-03 17:07:58 -05:00
2014-06-15 20:36:44 -04:00
ptx . key_images = key_images ;
2016-04-17 22:57:47 -04:00
ptx . fee = ( dust_policy . add_to_fee ? fee + dust : fee ) ;
ptx . dust = ( ( dust_policy . add_to_fee | | dust_sent_elsewhere ) ? dust : 0 ) ;
2016-04-18 04:20:31 -04:00
ptx . dust_added_to_fee = dust_policy . add_to_fee ;
2014-06-15 20:36:44 -04:00
ptx . tx = tx ;
ptx . change_dts = change_dts ;
ptx . selected_transfers = selected_transfers ;
2015-08-19 15:59:44 -04:00
ptx . tx_key = tx_key ;
2017-02-18 21:42:10 -05:00
ptx . additional_tx_keys = additional_tx_keys ;
2015-11-22 07:13:59 -05:00
ptx . dests = dsts ;
2016-09-26 18:11:10 -04:00
ptx . construction_data . sources = sources ;
ptx . construction_data . change_dts = change_dts ;
2016-10-25 16:19:47 -04:00
ptx . construction_data . splitted_dsts = splitted_dsts ;
ptx . construction_data . selected_transfers = selected_transfers ;
2016-09-26 18:11:10 -04:00
ptx . construction_data . extra = tx . extra ;
ptx . construction_data . unlock_time = unlock_time ;
ptx . construction_data . use_rct = false ;
2016-11-23 15:10:34 -05:00
ptx . construction_data . dests = dsts ;
2017-02-18 21:42:10 -05:00
// record which subaddress indices are being used as inputs
ptx . construction_data . subaddr_account = subaddr_account ;
ptx . construction_data . subaddr_indices . clear ( ) ;
for ( size_t idx : selected_transfers )
ptx . construction_data . subaddr_indices . insert ( m_transfers [ idx ] . m_subaddr_index . minor ) ;
2014-06-15 20:36:44 -04:00
}
2014-03-03 17:07:58 -05:00
}
