monero/src/wallet/wallet_errors.h

961 lines
36 KiB
C
Raw Normal View History

2022-03-01 11:16:17 +00:00
// Copyright (c) 2014-2022, The Monero Project
2014-07-23 13:03:52 +00:00
//
// All rights reserved.
//
// Redistribution and use in source and binary forms, with or without modification, are
// permitted provided that the following conditions are met:
//
// 1. Redistributions of source code must retain the above copyright notice, this list of
// conditions and the following disclaimer.
//
// 2. Redistributions in binary form must reproduce the above copyright notice, this list
// of conditions and the following disclaimer in the documentation and/or other
// materials provided with the distribution.
//
// 3. Neither the name of the copyright holder nor the names of its contributors may be
// used to endorse or promote products derived from this software without specific
// prior written permission.
//
// THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY
// EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
// MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL
// THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
// SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
// PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
// INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT,
// STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF
// THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
//
// Parts of this file are originally copyright (c) 2012-2013 The Cryptonote developers
2014-04-02 16:00:17 +00:00
#pragma once
#include <stdexcept>
#include <system_error>
2014-04-02 16:00:17 +00:00
#include <string>
#include <vector>
#include "cryptonote_basic/cryptonote_format_utils.h"
#include "cryptonote_core/cryptonote_tx_utils.h"
2014-04-02 16:00:17 +00:00
#include "rpc/core_rpc_server_commands_defs.h"
#include "include_base_utils.h"
namespace tools
{
namespace error
{
// std::exception
// std::runtime_error
// wallet_runtime_error *
// wallet_internal_error
// unexpected_txin_type
// wallet_not_initialized
Add N/N multisig tx generation and signing Scheme by luigi1111: Multisig for RingCT on Monero 2 of 2 User A (coordinator): Spendkey b,B Viewkey a,A (shared) User B: Spendkey c,C Viewkey a,A (shared) Public Address: C+B, A Both have their own watch only wallet via C+B, a A will coordinate spending process (though B could easily as well, coordinator is more needed for more participants) A and B watch for incoming outputs B creates "half" key images for discovered output D: I2_D = (Hs(aR)+c) * Hp(D) B also creates 1.5 random keypairs (one scalar and 2 pubkeys; one on base G and one on base Hp(D)) for each output, storing the scalar(k) (linked to D), and sending the pubkeys with I2_D. A also creates "half" key images: I1_D = (Hs(aR)+b) * Hp(D) Then I_D = I1_D + I2_D Having I_D allows A to check spent status of course, but more importantly allows A to actually build a transaction prefix (and thus transaction). A builds the transaction until most of the way through MLSAG_Gen, adding the 2 pubkeys (per input) provided with I2_D to his own generated ones where they are needed (secret row L, R). At this point, A has a mostly completed transaction (but with an invalid/incomplete signature). A sends over the tx and includes r, which allows B (with the recipient's address) to verify the destination and amount (by reconstructing the stealth address and decoding ecdhInfo). B then finishes the signature by computing ss[secret_index][0] = ss[secret_index][0] + k - cc[secret_index]*c (secret indices need to be passed as well). B can then broadcast the tx, or send it back to A for broadcasting. Once B has completed the signing (and verified the tx to be valid), he can add the full I_D to his cache, allowing him to verify spent status as well. NOTE: A and B *must* present key A and B to each other with a valid signature proving they know a and b respectively. Otherwise, trickery like the following becomes possible: A creates viewkey a,A, spendkey b,B, and sends a,A,B to B. B creates a fake key C = zG - B. B sends C back to A. The combined spendkey C+B then equals zG, allowing B to spend funds at any time! The signature fixes this, because B does not know a c corresponding to C (and thus can't produce a signature). 2 of 3 User A (coordinator) Shared viewkey a,A "spendkey" j,J User B "spendkey" k,K User C "spendkey" m,M A collects K and M from B and C B collects J and M from A and C C collects J and K from A and B A computes N = nG, n = Hs(jK) A computes O = oG, o = Hs(jM) B anc C compute P = pG, p = Hs(kM) || Hs(mK) B and C can also compute N and O respectively if they wish to be able to coordinate Address: N+O+P, A The rest follows as above. The coordinator possesses 2 of 3 needed keys; he can get the other needed part of the signature/key images from either of the other two. Alternatively, if secure communication exists between parties: A gives j to B B gives k to C C gives m to A Address: J+K+M, A 3 of 3 Identical to 2 of 2, except the coordinator must collect the key images from both of the others. The transaction must also be passed an additional hop: A -> B -> C (or A -> C -> B), who can then broadcast it or send it back to A. N-1 of N Generally the same as 2 of 3, except participants need to be arranged in a ring to pass their keys around (using either the secure or insecure method). For example (ignoring viewkey so letters line up): [4 of 5] User: spendkey A: a B: b C: c D: d E: e a -> B, b -> C, c -> D, d -> E, e -> A Order of signing does not matter, it just must reach n-1 users. A "remaining keys" list must be passed around with the transaction so the signers know if they should use 1 or both keys. Collecting key image parts becomes a little messy, but basically every wallet sends over both of their parts with a tag for each. Thia way the coordinating wallet can keep track of which images have been added and which wallet they come from. Reasoning: 1. The key images must be added only once (coordinator will get key images for key a from both A and B, he must add only one to get the proper key actual key image) 2. The coordinator must keep track of which helper pubkeys came from which wallet (discussed in 2 of 2 section). The coordinator must choose only one set to use, then include his choice in the "remaining keys" list so the other wallets know which of their keys to use. You can generalize it further to N-2 of N or even M of N, but I'm not sure there's legitimate demand to justify the complexity. It might also be straightforward enough to support with minimal changes from N-1 format. You basically just give each user additional keys for each additional "-1" you desire. N-2 would be 3 keys per user, N-3 4 keys, etc. The process is somewhat cumbersome: To create a N/N multisig wallet: - each participant creates a normal wallet - each participant runs "prepare_multisig", and sends the resulting string to every other participant - each participant runs "make_multisig N A B C D...", with N being the threshold and A B C D... being the strings received from other participants (the threshold must currently equal N) As txes are received, participants' wallets will need to synchronize so that those new outputs may be spent: - each participant runs "export_multisig FILENAME", and sends the FILENAME file to every other participant - each participant runs "import_multisig A B C D...", with A B C D... being the filenames received from other participants Then, a transaction may be initiated: - one of the participants runs "transfer ADDRESS AMOUNT" - this partly signed transaction will be written to the "multisig_monero_tx" file - the initiator sends this file to another participant - that other participant runs "sign_multisig multisig_monero_tx" - the resulting transaction is written to the "multisig_monero_tx" file again - if the threshold was not reached, the file must be sent to another participant, until enough have signed - the last participant to sign runs "submit_multisig multisig_monero_tx" to relay the transaction to the Monero network
2017-06-03 21:34:26 +00:00
// multisig_export_needed
// multisig_import_needed
// password_needed
2014-04-02 16:00:17 +00:00
// std::logic_error
// wallet_logic_error *
// file_exists
// file_not_found
// file_read_error
// file_save_error
// invalid_password
// invalid_priority
// invalid_multisig_seed
2014-04-02 16:00:17 +00:00
// refresh_error *
// acc_outs_lookup_error
// block_parse_error
// get_blocks_error
// get_hashes_error
2014-04-02 16:00:17 +00:00
// get_out_indexes_error
// tx_parse_error
// get_tx_pool_error
// out_of_hashchain_bounds_error
// signature_check_failed
2014-04-02 16:00:17 +00:00
// transfer_error *
// get_outs_general_error
// not_enough_unlocked_money
2014-04-02 16:00:17 +00:00
// not_enough_money
// tx_not_possible
2014-04-02 16:00:17 +00:00
// not_enough_outs_to_mix
// tx_not_constructed
// tx_rejected
// tx_sum_overflow
// tx_too_big
// zero_amount
2014-04-02 16:00:17 +00:00
// zero_destination
// wallet_rpc_error *
// daemon_busy
// no_connection_to_daemon
// is_key_image_spent_error
// get_histogram_error
// get_output_distribution
daemon, wallet: new pay for RPC use system Daemons intended for public use can be set up to require payment in the form of hashes in exchange for RPC service. This enables public daemons to receive payment for their work over a large number of calls. This system behaves similarly to a pool, so payment takes the form of valid blocks every so often, yielding a large one off payment, rather than constant micropayments. This system can also be used by third parties as a "paywall" layer, where users of a service can pay for use by mining Monero to the service provider's address. An example of this for web site access is Primo, a Monero mining based website "paywall": https://github.com/selene-kovri/primo This has some advantages: - incentive to run a node providing RPC services, thereby promoting the availability of third party nodes for those who can't run their own - incentive to run your own node instead of using a third party's, thereby promoting decentralization - decentralized: payment is done between a client and server, with no third party needed - private: since the system is "pay as you go", you don't need to identify yourself to claim a long lived balance - no payment occurs on the blockchain, so there is no extra transactional load - one may mine with a beefy server, and use those credits from a phone, by reusing the client ID (at the cost of some privacy) - no barrier to entry: anyone may run a RPC node, and your expected revenue depends on how much work you do - Sybil resistant: if you run 1000 idle RPC nodes, you don't magically get more revenue - no large credit balance maintained on servers, so they have no incentive to exit scam - you can use any/many node(s), since there's little cost in switching servers - market based prices: competition between servers to lower costs - incentive for a distributed third party node system: if some public nodes are overused/slow, traffic can move to others - increases network security - helps counteract mining pools' share of the network hash rate - zero incentive for a payer to "double spend" since a reorg does not give any money back to the miner And some disadvantages: - low power clients will have difficulty mining (but one can optionally mine in advance and/or with a faster machine) - payment is "random", so a server might go a long time without a block before getting one - a public node's overall expected payment may be small Public nodes are expected to compete to find a suitable level for cost of service. The daemon can be set up this way to require payment for RPC services: monerod --rpc-payment-address 4xxxxxx \ --rpc-payment-credits 250 --rpc-payment-difficulty 1000 These values are an example only. The --rpc-payment-difficulty switch selects how hard each "share" should be, similar to a mining pool. The higher the difficulty, the fewer shares a client will find. The --rpc-payment-credits switch selects how many credits are awarded for each share a client finds. Considering both options, clients will be awarded credits/difficulty credits for every hash they calculate. For example, in the command line above, 0.25 credits per hash. A client mining at 100 H/s will therefore get an average of 25 credits per second. For reference, in the current implementation, a credit is enough to sync 20 blocks, so a 100 H/s client that's just starting to use Monero and uses this daemon will be able to sync 500 blocks per second. The wallet can be set to automatically mine if connected to a daemon which requires payment for RPC usage. It will try to keep a balance of 50000 credits, stopping mining when it's at this level, and starting again as credits are spent. With the example above, a new client will mine this much credits in about half an hour, and this target is enough to sync 500000 blocks (currently about a third of the monero blockchain). There are three new settings in the wallet: - credits-target: this is the amount of credits a wallet will try to reach before stopping mining. The default of 0 means 50000 credits. - auto-mine-for-rpc-payment-threshold: this controls the minimum credit rate which the wallet considers worth mining for. If the daemon credits less than this ratio, the wallet will consider mining to be not worth it. In the example above, the rate is 0.25 - persistent-rpc-client-id: if set, this allows the wallet to reuse a client id across runs. This means a public node can tell a wallet that's connecting is the same as one that connected previously, but allows a wallet to keep their credit balance from one run to the other. Since the wallet only mines to keep a small credit balance, this is not normally worth doing. However, someone may want to mine on a fast server, and use that credit balance on a low power device such as a phone. If left unset, a new client ID is generated at each wallet start, for privacy reasons. To mine and use a credit balance on two different devices, you can use the --rpc-client-secret-key switch. A wallet's client secret key can be found using the new rpc_payments command in the wallet. Note: anyone knowing your RPC client secret key is able to use your credit balance. The wallet has a few new commands too: - start_mining_for_rpc: start mining to acquire more credits, regardless of the auto mining settings - stop_mining_for_rpc: stop mining to acquire more credits - rpc_payments: display information about current credits with the currently selected daemon The node has an extra command: - rpc_payments: display information about clients and their balances The node will forget about any balance for clients which have been inactive for 6 months. Balances carry over on node restart.
2018-02-11 15:15:56 +00:00
// payment_required
2014-04-02 16:00:17 +00:00
// wallet_files_doesnt_correspond
//
// * - class with protected ctor
//----------------------------------------------------------------------------------------------------
template<typename Base>
struct wallet_error_base : public Base
{
const std::string& location() const { return m_loc; }
std::string to_string() const
{
std::ostringstream ss;
ss << m_loc << ':' << typeid(*this).name() << ": " << Base::what();
return ss.str();
}
protected:
wallet_error_base(std::string&& loc, const std::string& message)
: Base(message)
, m_loc(loc)
{
}
private:
std::string m_loc;
};
//----------------------------------------------------------------------------------------------------
const char* const failed_rpc_request_messages[] = {
"failed to get blocks",
"failed to get hashes",
2014-04-02 16:00:17 +00:00
"failed to get out indices",
"failed to get random outs"
};
enum failed_rpc_request_message_indices
{
get_blocks_error_message_index,
get_hashes_error_message_index,
2014-04-02 16:00:17 +00:00
get_out_indices_error_message_index,
get_outs_error_message_index
2014-04-02 16:00:17 +00:00
};
template<typename Base, int msg_index>
struct failed_rpc_request : public Base
{
explicit failed_rpc_request(std::string&& loc, const std::string& status)
: Base(std::move(loc), failed_rpc_request_messages[msg_index])
, m_status(status)
{
}
const std::string& status() const { return m_status; }
std::string to_string() const
{
std::ostringstream ss;
ss << Base::to_string() << ", status = " << status();
return ss.str();
}
private:
std::string m_status;
};
//----------------------------------------------------------------------------------------------------
typedef wallet_error_base<std::logic_error> wallet_logic_error;
typedef wallet_error_base<std::runtime_error> wallet_runtime_error;
//----------------------------------------------------------------------------------------------------
struct wallet_internal_error : public wallet_runtime_error
{
explicit wallet_internal_error(std::string&& loc, const std::string& message)
: wallet_runtime_error(std::move(loc), message)
{
}
};
//----------------------------------------------------------------------------------------------------
struct unexpected_txin_type : public wallet_internal_error
{
explicit unexpected_txin_type(std::string&& loc, const cryptonote::transaction& tx)
: wallet_internal_error(std::move(loc), "one of tx inputs has unexpected type")
, m_tx(tx)
{
}
const cryptonote::transaction& tx() const { return m_tx; }
std::string to_string() const
{
std::ostringstream ss;
cryptonote::transaction tx = m_tx;
ss << wallet_internal_error::to_string() << ", tx:\n" << cryptonote::obj_to_json_str(tx);
return ss.str();
}
private:
cryptonote::transaction m_tx;
};
//----------------------------------------------------------------------------------------------------
struct wallet_not_initialized : public wallet_internal_error
{
explicit wallet_not_initialized(std::string&& loc)
: wallet_internal_error(std::move(loc), "wallet is not initialized")
{
}
};
Add N/N multisig tx generation and signing Scheme by luigi1111: Multisig for RingCT on Monero 2 of 2 User A (coordinator): Spendkey b,B Viewkey a,A (shared) User B: Spendkey c,C Viewkey a,A (shared) Public Address: C+B, A Both have their own watch only wallet via C+B, a A will coordinate spending process (though B could easily as well, coordinator is more needed for more participants) A and B watch for incoming outputs B creates "half" key images for discovered output D: I2_D = (Hs(aR)+c) * Hp(D) B also creates 1.5 random keypairs (one scalar and 2 pubkeys; one on base G and one on base Hp(D)) for each output, storing the scalar(k) (linked to D), and sending the pubkeys with I2_D. A also creates "half" key images: I1_D = (Hs(aR)+b) * Hp(D) Then I_D = I1_D + I2_D Having I_D allows A to check spent status of course, but more importantly allows A to actually build a transaction prefix (and thus transaction). A builds the transaction until most of the way through MLSAG_Gen, adding the 2 pubkeys (per input) provided with I2_D to his own generated ones where they are needed (secret row L, R). At this point, A has a mostly completed transaction (but with an invalid/incomplete signature). A sends over the tx and includes r, which allows B (with the recipient's address) to verify the destination and amount (by reconstructing the stealth address and decoding ecdhInfo). B then finishes the signature by computing ss[secret_index][0] = ss[secret_index][0] + k - cc[secret_index]*c (secret indices need to be passed as well). B can then broadcast the tx, or send it back to A for broadcasting. Once B has completed the signing (and verified the tx to be valid), he can add the full I_D to his cache, allowing him to verify spent status as well. NOTE: A and B *must* present key A and B to each other with a valid signature proving they know a and b respectively. Otherwise, trickery like the following becomes possible: A creates viewkey a,A, spendkey b,B, and sends a,A,B to B. B creates a fake key C = zG - B. B sends C back to A. The combined spendkey C+B then equals zG, allowing B to spend funds at any time! The signature fixes this, because B does not know a c corresponding to C (and thus can't produce a signature). 2 of 3 User A (coordinator) Shared viewkey a,A "spendkey" j,J User B "spendkey" k,K User C "spendkey" m,M A collects K and M from B and C B collects J and M from A and C C collects J and K from A and B A computes N = nG, n = Hs(jK) A computes O = oG, o = Hs(jM) B anc C compute P = pG, p = Hs(kM) || Hs(mK) B and C can also compute N and O respectively if they wish to be able to coordinate Address: N+O+P, A The rest follows as above. The coordinator possesses 2 of 3 needed keys; he can get the other needed part of the signature/key images from either of the other two. Alternatively, if secure communication exists between parties: A gives j to B B gives k to C C gives m to A Address: J+K+M, A 3 of 3 Identical to 2 of 2, except the coordinator must collect the key images from both of the others. The transaction must also be passed an additional hop: A -> B -> C (or A -> C -> B), who can then broadcast it or send it back to A. N-1 of N Generally the same as 2 of 3, except participants need to be arranged in a ring to pass their keys around (using either the secure or insecure method). For example (ignoring viewkey so letters line up): [4 of 5] User: spendkey A: a B: b C: c D: d E: e a -> B, b -> C, c -> D, d -> E, e -> A Order of signing does not matter, it just must reach n-1 users. A "remaining keys" list must be passed around with the transaction so the signers know if they should use 1 or both keys. Collecting key image parts becomes a little messy, but basically every wallet sends over both of their parts with a tag for each. Thia way the coordinating wallet can keep track of which images have been added and which wallet they come from. Reasoning: 1. The key images must be added only once (coordinator will get key images for key a from both A and B, he must add only one to get the proper key actual key image) 2. The coordinator must keep track of which helper pubkeys came from which wallet (discussed in 2 of 2 section). The coordinator must choose only one set to use, then include his choice in the "remaining keys" list so the other wallets know which of their keys to use. You can generalize it further to N-2 of N or even M of N, but I'm not sure there's legitimate demand to justify the complexity. It might also be straightforward enough to support with minimal changes from N-1 format. You basically just give each user additional keys for each additional "-1" you desire. N-2 would be 3 keys per user, N-3 4 keys, etc. The process is somewhat cumbersome: To create a N/N multisig wallet: - each participant creates a normal wallet - each participant runs "prepare_multisig", and sends the resulting string to every other participant - each participant runs "make_multisig N A B C D...", with N being the threshold and A B C D... being the strings received from other participants (the threshold must currently equal N) As txes are received, participants' wallets will need to synchronize so that those new outputs may be spent: - each participant runs "export_multisig FILENAME", and sends the FILENAME file to every other participant - each participant runs "import_multisig A B C D...", with A B C D... being the filenames received from other participants Then, a transaction may be initiated: - one of the participants runs "transfer ADDRESS AMOUNT" - this partly signed transaction will be written to the "multisig_monero_tx" file - the initiator sends this file to another participant - that other participant runs "sign_multisig multisig_monero_tx" - the resulting transaction is written to the "multisig_monero_tx" file again - if the threshold was not reached, the file must be sent to another participant, until enough have signed - the last participant to sign runs "submit_multisig multisig_monero_tx" to relay the transaction to the Monero network
2017-06-03 21:34:26 +00:00
//----------------------------------------------------------------------------------------------------
struct multisig_export_needed : public wallet_runtime_error
{
explicit multisig_export_needed(std::string&& loc)
: wallet_runtime_error(std::move(loc), "This signature was made with stale data: export fresh multisig data, which other participants must then use")
{
}
};
//----------------------------------------------------------------------------------------------------
struct multisig_import_needed : public wallet_runtime_error
{
explicit multisig_import_needed(std::string&& loc)
: wallet_runtime_error(std::move(loc), "Not enough multisig data was found to sign: import multisig data from more other participants")
{
}
};
2014-04-02 16:00:17 +00:00
//----------------------------------------------------------------------------------------------------
struct password_needed : public wallet_runtime_error
{
explicit password_needed(std::string&& loc, const std::string &msg = "Password needed")
: wallet_runtime_error(std::move(loc), msg)
{
}
};
//----------------------------------------------------------------------------------------------------
struct password_entry_failed : public wallet_runtime_error
{
explicit password_entry_failed(std::string&& loc, const std::string &msg = "Password entry failed")
: wallet_runtime_error(std::move(loc), msg)
{
}
};
//----------------------------------------------------------------------------------------------------
2014-04-02 16:00:17 +00:00
const char* const file_error_messages[] = {
"file already exists",
"file not found",
"failed to read file",
"failed to save file"
};
enum file_error_message_indices
{
file_exists_message_index,
file_not_found_message_index,
file_read_error_message_index,
file_save_error_message_index
};
template<int msg_index>
struct file_error_base : public wallet_logic_error
{
explicit file_error_base(std::string&& loc, const std::string& file)
: wallet_logic_error(std::move(loc), std::string(file_error_messages[msg_index]) + " \"" + file + '\"')
, m_file(file)
{
}
explicit file_error_base(std::string&& loc, const std::string& file, const std::error_code &e)
: wallet_logic_error(std::move(loc), std::string(file_error_messages[msg_index]) + " \"" + file + "\": " + e.message())
, m_file(file)
{
}
2014-04-02 16:00:17 +00:00
const std::string& file() const { return m_file; }
std::string to_string() const { return wallet_logic_error::to_string(); }
private:
std::string m_file;
};
//----------------------------------------------------------------------------------------------------
typedef file_error_base<file_exists_message_index> file_exists;
typedef file_error_base<file_not_found_message_index> file_not_found;
typedef file_error_base<file_read_error_message_index> file_read_error;
typedef file_error_base<file_save_error_message_index> file_save_error;
//----------------------------------------------------------------------------------------------------
struct invalid_password : public wallet_logic_error
{
explicit invalid_password(std::string&& loc)
: wallet_logic_error(std::move(loc), "invalid password")
{
}
std::string to_string() const { return wallet_logic_error::to_string(); }
};
struct invalid_priority : public wallet_logic_error
{
explicit invalid_priority(std::string&& loc)
: wallet_logic_error(std::move(loc), "invalid priority")
{
}
std::string to_string() const { return wallet_logic_error::to_string(); }
};
struct invalid_multisig_seed : public wallet_logic_error
{
explicit invalid_multisig_seed(std::string&& loc)
: wallet_logic_error(std::move(loc), "invalid multisig seed")
{
}
std::string to_string() const { return wallet_logic_error::to_string(); }
};
//----------------------------------------------------------------------------------------------------
struct invalid_pregenerated_random : public wallet_logic_error
{
explicit invalid_pregenerated_random (std::string&& loc)
: wallet_logic_error(std::move(loc), "invalid pregenerated random for wallet creation/recovery")
{
}
std::string to_string() const { return wallet_logic_error::to_string(); }
};
2014-04-02 16:00:17 +00:00
//----------------------------------------------------------------------------------------------------
struct refresh_error : public wallet_logic_error
{
protected:
2014-06-27 16:42:48 +00:00
explicit refresh_error(std::string&& loc, const std::string& message)
2014-04-02 16:00:17 +00:00
: wallet_logic_error(std::move(loc), message)
{
}
};
//----------------------------------------------------------------------------------------------------
struct index_outofbound : public wallet_logic_error
{
explicit index_outofbound(std::string&& loc, const std::string& message)
: wallet_logic_error(std::move(loc), message)
{
}
};
struct account_index_outofbound : public index_outofbound
{
explicit account_index_outofbound(std::string&& loc)
: index_outofbound(std::move(loc), "account index is out of bound")
{
}
};
struct address_index_outofbound: public index_outofbound
{
explicit address_index_outofbound(std::string&& loc)
: index_outofbound(std::move(loc), "address index is out of bound")
{
}
};
//----------------------------------------------------------------------------------------------------
2014-04-02 16:00:17 +00:00
struct acc_outs_lookup_error : public refresh_error
{
explicit acc_outs_lookup_error(std::string&& loc, const cryptonote::transaction& tx,
const crypto::public_key& tx_pub_key, const cryptonote::account_keys& acc_keys)
: refresh_error(std::move(loc), "account outs lookup error")
, m_tx(tx)
, m_tx_pub_key(tx_pub_key)
, m_acc_keys(acc_keys)
{
}
const cryptonote::transaction& tx() const { return m_tx; }
const crypto::public_key& tx_pub_key() const { return m_tx_pub_key; }
const cryptonote::account_keys& acc_keys() const { return m_acc_keys; }
std::string to_string() const
{
std::ostringstream ss;
cryptonote::transaction tx = m_tx;
ss << refresh_error::to_string() << ", tx: " << cryptonote::obj_to_json_str(tx);
return ss.str();
}
private:
const cryptonote::transaction m_tx;
const crypto::public_key m_tx_pub_key;
const cryptonote::account_keys m_acc_keys;
};
//----------------------------------------------------------------------------------------------------
struct block_parse_error : public refresh_error
{
explicit block_parse_error(std::string&& loc, const cryptonote::blobdata& block_data)
: refresh_error(std::move(loc), "block parse error")
, m_block_blob(block_data)
{
}
const cryptonote::blobdata& block_blob() const { return m_block_blob; }
std::string to_string() const { return refresh_error::to_string(); }
private:
cryptonote::blobdata m_block_blob;
};
//----------------------------------------------------------------------------------------------------
typedef failed_rpc_request<refresh_error, get_blocks_error_message_index> get_blocks_error;
//----------------------------------------------------------------------------------------------------
typedef failed_rpc_request<refresh_error, get_hashes_error_message_index> get_hashes_error;
//----------------------------------------------------------------------------------------------------
2014-04-02 16:00:17 +00:00
typedef failed_rpc_request<refresh_error, get_out_indices_error_message_index> get_out_indices_error;
//----------------------------------------------------------------------------------------------------
struct tx_parse_error : public refresh_error
{
explicit tx_parse_error(std::string&& loc, const cryptonote::blobdata& tx_blob)
: refresh_error(std::move(loc), "transaction parse error")
, m_tx_blob(tx_blob)
{
}
const cryptonote::blobdata& tx_blob() const { return m_tx_blob; }
std::string to_string() const { return refresh_error::to_string(); }
private:
cryptonote::blobdata m_tx_blob;
};
//----------------------------------------------------------------------------------------------------
struct get_tx_pool_error : public refresh_error
{
explicit get_tx_pool_error(std::string&& loc)
2018-03-01 11:36:19 +00:00
: refresh_error(std::move(loc), "error getting transaction pool")
{
}
std::string to_string() const { return refresh_error::to_string(); }
};
//----------------------------------------------------------------------------------------------------
struct out_of_hashchain_bounds_error : public refresh_error
{
explicit out_of_hashchain_bounds_error(std::string&& loc)
: refresh_error(std::move(loc), "Index out of bounds of of hashchain")
{
}
std::string to_string() const { return refresh_error::to_string(); }
};
//----------------------------------------------------------------------------------------------------
struct reorg_depth_error : public refresh_error
{
explicit reorg_depth_error(std::string&& loc, const std::string& message)
: refresh_error(std::move(loc), message)
{
}
std::string to_string() const { return refresh_error::to_string(); }
};
//----------------------------------------------------------------------------------------------------
struct signature_check_failed : public wallet_logic_error
{
explicit signature_check_failed(std::string&& loc, const std::string& message)
: wallet_logic_error(std::move(loc), "Signature check failed " + message)
{
}
};
//----------------------------------------------------------------------------------------------------
2014-04-02 16:00:17 +00:00
struct transfer_error : public wallet_logic_error
{
protected:
2014-06-27 16:42:48 +00:00
explicit transfer_error(std::string&& loc, const std::string& message)
2014-04-02 16:00:17 +00:00
: wallet_logic_error(std::move(loc), message)
{
}
};
//----------------------------------------------------------------------------------------------------
typedef failed_rpc_request<transfer_error, get_outs_error_message_index> get_outs_error;
2014-04-02 16:00:17 +00:00
//----------------------------------------------------------------------------------------------------
struct not_enough_unlocked_money : public transfer_error
{
explicit not_enough_unlocked_money(std::string&& loc, uint64_t available, uint64_t tx_amount, uint64_t fee)
: transfer_error(std::move(loc), "not enough unlocked money")
, m_available(available)
, m_tx_amount(tx_amount)
{
}
uint64_t available() const { return m_available; }
uint64_t tx_amount() const { return m_tx_amount; }
std::string to_string() const
{
std::ostringstream ss;
ss << transfer_error::to_string() <<
", available = " << cryptonote::print_money(m_available) <<
", tx_amount = " << cryptonote::print_money(m_tx_amount);
return ss.str();
}
private:
uint64_t m_available;
uint64_t m_tx_amount;
};
//----------------------------------------------------------------------------------------------------
2014-04-02 16:00:17 +00:00
struct not_enough_money : public transfer_error
{
explicit not_enough_money(std::string&& loc, uint64_t available, uint64_t tx_amount, uint64_t fee)
2014-04-02 16:00:17 +00:00
: transfer_error(std::move(loc), "not enough money")
, m_available(available)
2014-04-02 16:00:17 +00:00
, m_tx_amount(tx_amount)
{
}
uint64_t available() const { return m_available; }
uint64_t tx_amount() const { return m_tx_amount; }
std::string to_string() const
{
std::ostringstream ss;
ss << transfer_error::to_string() <<
", available = " << cryptonote::print_money(m_available) <<
", tx_amount = " << cryptonote::print_money(m_tx_amount);
return ss.str();
}
private:
uint64_t m_available;
uint64_t m_tx_amount;
};
//----------------------------------------------------------------------------------------------------
struct tx_not_possible : public transfer_error
{
explicit tx_not_possible(std::string&& loc, uint64_t available, uint64_t tx_amount, uint64_t fee)
: transfer_error(std::move(loc), "tx not possible")
, m_available(available)
, m_tx_amount(tx_amount)
2014-04-02 16:00:17 +00:00
, m_fee(fee)
{
}
uint64_t available() const { return m_available; }
uint64_t tx_amount() const { return m_tx_amount; }
uint64_t fee() const { return m_fee; }
std::string to_string() const
{
std::ostringstream ss;
ss << transfer_error::to_string() <<
", available = " << cryptonote::print_money(m_available) <<
", tx_amount = " << cryptonote::print_money(m_tx_amount) <<
", fee = " << cryptonote::print_money(m_fee);
return ss.str();
}
private:
uint64_t m_available;
uint64_t m_tx_amount;
uint64_t m_fee;
};
//----------------------------------------------------------------------------------------------------
struct not_enough_outs_to_mix : public transfer_error
{
typedef std::unordered_map<uint64_t, uint64_t> scanty_outs_t;
2014-04-02 16:00:17 +00:00
explicit not_enough_outs_to_mix(std::string&& loc, const scanty_outs_t& scanty_outs, size_t mixin_count)
: transfer_error(std::move(loc), "not enough outputs to use")
2014-04-02 16:00:17 +00:00
, m_scanty_outs(scanty_outs)
, m_mixin_count(mixin_count)
{
}
const scanty_outs_t& scanty_outs() const { return m_scanty_outs; }
size_t mixin_count() const { return m_mixin_count; }
std::string to_string() const
{
std::ostringstream ss;
ss << transfer_error::to_string() << ", ring size = " << (m_mixin_count + 1) << ", scanty_outs:";
for (const auto& out: m_scanty_outs)
2014-04-02 16:00:17 +00:00
{
ss << '\n' << cryptonote::print_money(out.first) << " - " << out.second;
2014-04-02 16:00:17 +00:00
}
return ss.str();
}
private:
scanty_outs_t m_scanty_outs;
size_t m_mixin_count;
};
//----------------------------------------------------------------------------------------------------
struct tx_not_constructed : public transfer_error
{
typedef std::vector<cryptonote::tx_source_entry> sources_t;
typedef std::vector<cryptonote::tx_destination_entry> destinations_t;
2014-09-09 14:58:53 +00:00
explicit tx_not_constructed(
std::string && loc
, sources_t const & sources
, destinations_t const & destinations
, uint64_t unlock_time
2018-02-16 11:04:04 +00:00
, cryptonote::network_type nettype
2014-09-09 14:58:53 +00:00
)
: transfer_error(std::move(loc), "transaction was not constructed")
, m_sources(sources)
, m_destinations(destinations)
, m_unlock_time(unlock_time)
2018-02-16 11:04:04 +00:00
, m_nettype(nettype)
2014-04-02 16:00:17 +00:00
{
}
const sources_t& sources() const { return m_sources; }
const destinations_t& destinations() const { return m_destinations; }
uint64_t unlock_time() const { return m_unlock_time; }
std::string to_string() const
{
std::ostringstream ss;
ss << transfer_error::to_string();
ss << "\nSources:";
for (size_t i = 0; i < m_sources.size(); ++i)
{
const cryptonote::tx_source_entry& src = m_sources[i];
ss << "\n source " << i << ":";
ss << "\n amount: " << cryptonote::print_money(src.amount);
// It's not good, if logs will contain such much data
//ss << "\n real_output: " << src.real_output;
//ss << "\n real_output_in_tx_index: " << src.real_output_in_tx_index;
//ss << "\n real_out_tx_key: " << epee::string_tools::pod_to_hex(src.real_out_tx_key);
//ss << "\n outputs:";
//for (size_t j = 0; j < src.outputs.size(); ++j)
//{
// const cryptonote::tx_source_entry::output_entry& out = src.outputs[j];
// ss << "\n " << j << ": " << out.first << ", " << epee::string_tools::pod_to_hex(out.second);
//}
}
ss << "\nDestinations:";
for (size_t i = 0; i < m_destinations.size(); ++i)
{
const cryptonote::tx_destination_entry& dst = m_destinations[i];
2018-02-16 11:04:04 +00:00
ss << "\n " << i << ": " << cryptonote::get_account_address_as_str(m_nettype, dst.is_subaddress, dst.addr) << " " <<
2014-04-02 16:00:17 +00:00
cryptonote::print_money(dst.amount);
}
ss << "\nunlock_time: " << m_unlock_time;
return ss.str();
}
private:
sources_t m_sources;
destinations_t m_destinations;
uint64_t m_unlock_time;
2018-02-16 11:04:04 +00:00
cryptonote::network_type m_nettype;
2014-04-02 16:00:17 +00:00
};
//----------------------------------------------------------------------------------------------------
struct tx_rejected : public transfer_error
{
explicit tx_rejected(std::string&& loc, const cryptonote::transaction& tx, const std::string& status, const std::string& reason)
2014-04-02 16:00:17 +00:00
: transfer_error(std::move(loc), "transaction was rejected by daemon")
, m_tx(tx)
, m_status(status)
, m_reason(reason)
2014-04-02 16:00:17 +00:00
{
}
const cryptonote::transaction& tx() const { return m_tx; }
const std::string& status() const { return m_status; }
const std::string& reason() const { return m_reason; }
2014-04-02 16:00:17 +00:00
std::string to_string() const
{
std::ostringstream ss;
ss << transfer_error::to_string() << ", status = " << m_status << ", tx:\n";
cryptonote::transaction tx = m_tx;
ss << cryptonote::obj_to_json_str(tx);
if (!m_reason.empty())
{
ss << " (" << m_reason << ")";
}
2014-04-02 16:00:17 +00:00
return ss.str();
}
private:
cryptonote::transaction m_tx;
std::string m_status;
std::string m_reason;
2014-04-02 16:00:17 +00:00
};
//----------------------------------------------------------------------------------------------------
struct tx_sum_overflow : public transfer_error
{
2014-09-09 14:58:53 +00:00
explicit tx_sum_overflow(
std::string && loc
, const std::vector<cryptonote::tx_destination_entry>& destinations
, uint64_t fee
2018-02-16 11:04:04 +00:00
, cryptonote::network_type nettype
2014-09-09 14:58:53 +00:00
)
: transfer_error(std::move(loc), "transaction sum + fee exceeds " + cryptonote::print_money(std::numeric_limits<uint64_t>::max()))
, m_destinations(destinations)
, m_fee(fee)
2018-02-16 11:04:04 +00:00
, m_nettype(nettype)
2014-04-02 16:00:17 +00:00
{
}
const std::vector<cryptonote::tx_destination_entry>& destinations() const { return m_destinations; }
uint64_t fee() const { return m_fee; }
std::string to_string() const
{
std::ostringstream ss;
ss << transfer_error::to_string() <<
", fee = " << cryptonote::print_money(m_fee) <<
", destinations:";
for (const auto& dst : m_destinations)
{
2018-02-16 11:04:04 +00:00
ss << '\n' << cryptonote::print_money(dst.amount) << " -> " << cryptonote::get_account_address_as_str(m_nettype, dst.is_subaddress, dst.addr);
2014-04-02 16:00:17 +00:00
}
return ss.str();
}
private:
std::vector<cryptonote::tx_destination_entry> m_destinations;
uint64_t m_fee;
2018-02-16 11:04:04 +00:00
cryptonote::network_type m_nettype;
2014-04-02 16:00:17 +00:00
};
//----------------------------------------------------------------------------------------------------
struct tx_too_big : public transfer_error
{
explicit tx_too_big(std::string&& loc, const cryptonote::transaction& tx, uint64_t tx_weight_limit)
2014-04-02 16:00:17 +00:00
: transfer_error(std::move(loc), "transaction is too big")
, m_tx(tx)
, m_tx_valid(true)
, m_tx_weight(cryptonote::get_transaction_weight(tx))
, m_tx_weight_limit(tx_weight_limit)
2014-04-02 16:00:17 +00:00
{
}
explicit tx_too_big(std::string&& loc, uint64_t tx_weight, uint64_t tx_weight_limit)
: transfer_error(std::move(loc), "transaction would be too big")
, m_tx_valid(false)
, m_tx_weight(tx_weight)
, m_tx_weight_limit(tx_weight_limit)
{
}
bool tx_valid() const { return m_tx_valid; }
2014-04-02 16:00:17 +00:00
const cryptonote::transaction& tx() const { return m_tx; }
uint64_t tx_weight() const { return m_tx_weight; }
uint64_t tx_weight_limit() const { return m_tx_weight_limit; }
2014-04-02 16:00:17 +00:00
std::string to_string() const
{
std::ostringstream ss;
ss << transfer_error::to_string() <<
", tx_weight_limit = " << m_tx_weight_limit <<
", tx weight = " << m_tx_weight;
if (m_tx_valid)
{
cryptonote::transaction tx = m_tx;
ss << ", tx:\n" << cryptonote::obj_to_json_str(tx);
}
2014-04-02 16:00:17 +00:00
return ss.str();
}
private:
cryptonote::transaction m_tx;
bool m_tx_valid;
uint64_t m_tx_weight;
uint64_t m_tx_weight_limit;
2014-04-02 16:00:17 +00:00
};
//----------------------------------------------------------------------------------------------------
struct zero_amount: public transfer_error
{
explicit zero_amount(std::string&& loc)
: transfer_error(std::move(loc), "destination amount is zero")
{
}
};
//----------------------------------------------------------------------------------------------------
2014-04-02 16:00:17 +00:00
struct zero_destination : public transfer_error
{
explicit zero_destination(std::string&& loc)
: transfer_error(std::move(loc), "transaction has no destination")
2014-04-02 16:00:17 +00:00
{
}
};
//----------------------------------------------------------------------------------------------------
struct wallet_rpc_error : public wallet_logic_error
{
const std::string& request() const { return m_request; }
std::string to_string() const
{
std::ostringstream ss;
ss << wallet_logic_error::to_string() << ", request = " << m_request;
return ss.str();
}
protected:
2014-06-27 16:42:48 +00:00
explicit wallet_rpc_error(std::string&& loc, const std::string& message, const std::string& request)
2014-04-02 16:00:17 +00:00
: wallet_logic_error(std::move(loc), message)
, m_request(request)
{
}
private:
std::string m_request;
};
//----------------------------------------------------------------------------------------------------
struct wallet_generic_rpc_error : public wallet_rpc_error
{
explicit wallet_generic_rpc_error(std::string&& loc, const std::string& request, const std::string& status)
: wallet_rpc_error(std::move(loc), std::string("error in ") + request + " RPC: " + status, request),
m_status(status)
{
}
const std::string& status() const { return m_status; }
private:
const std::string m_status;
};
//----------------------------------------------------------------------------------------------------
daemon, wallet: new pay for RPC use system Daemons intended for public use can be set up to require payment in the form of hashes in exchange for RPC service. This enables public daemons to receive payment for their work over a large number of calls. This system behaves similarly to a pool, so payment takes the form of valid blocks every so often, yielding a large one off payment, rather than constant micropayments. This system can also be used by third parties as a "paywall" layer, where users of a service can pay for use by mining Monero to the service provider's address. An example of this for web site access is Primo, a Monero mining based website "paywall": https://github.com/selene-kovri/primo This has some advantages: - incentive to run a node providing RPC services, thereby promoting the availability of third party nodes for those who can't run their own - incentive to run your own node instead of using a third party's, thereby promoting decentralization - decentralized: payment is done between a client and server, with no third party needed - private: since the system is "pay as you go", you don't need to identify yourself to claim a long lived balance - no payment occurs on the blockchain, so there is no extra transactional load - one may mine with a beefy server, and use those credits from a phone, by reusing the client ID (at the cost of some privacy) - no barrier to entry: anyone may run a RPC node, and your expected revenue depends on how much work you do - Sybil resistant: if you run 1000 idle RPC nodes, you don't magically get more revenue - no large credit balance maintained on servers, so they have no incentive to exit scam - you can use any/many node(s), since there's little cost in switching servers - market based prices: competition between servers to lower costs - incentive for a distributed third party node system: if some public nodes are overused/slow, traffic can move to others - increases network security - helps counteract mining pools' share of the network hash rate - zero incentive for a payer to "double spend" since a reorg does not give any money back to the miner And some disadvantages: - low power clients will have difficulty mining (but one can optionally mine in advance and/or with a faster machine) - payment is "random", so a server might go a long time without a block before getting one - a public node's overall expected payment may be small Public nodes are expected to compete to find a suitable level for cost of service. The daemon can be set up this way to require payment for RPC services: monerod --rpc-payment-address 4xxxxxx \ --rpc-payment-credits 250 --rpc-payment-difficulty 1000 These values are an example only. The --rpc-payment-difficulty switch selects how hard each "share" should be, similar to a mining pool. The higher the difficulty, the fewer shares a client will find. The --rpc-payment-credits switch selects how many credits are awarded for each share a client finds. Considering both options, clients will be awarded credits/difficulty credits for every hash they calculate. For example, in the command line above, 0.25 credits per hash. A client mining at 100 H/s will therefore get an average of 25 credits per second. For reference, in the current implementation, a credit is enough to sync 20 blocks, so a 100 H/s client that's just starting to use Monero and uses this daemon will be able to sync 500 blocks per second. The wallet can be set to automatically mine if connected to a daemon which requires payment for RPC usage. It will try to keep a balance of 50000 credits, stopping mining when it's at this level, and starting again as credits are spent. With the example above, a new client will mine this much credits in about half an hour, and this target is enough to sync 500000 blocks (currently about a third of the monero blockchain). There are three new settings in the wallet: - credits-target: this is the amount of credits a wallet will try to reach before stopping mining. The default of 0 means 50000 credits. - auto-mine-for-rpc-payment-threshold: this controls the minimum credit rate which the wallet considers worth mining for. If the daemon credits less than this ratio, the wallet will consider mining to be not worth it. In the example above, the rate is 0.25 - persistent-rpc-client-id: if set, this allows the wallet to reuse a client id across runs. This means a public node can tell a wallet that's connecting is the same as one that connected previously, but allows a wallet to keep their credit balance from one run to the other. Since the wallet only mines to keep a small credit balance, this is not normally worth doing. However, someone may want to mine on a fast server, and use that credit balance on a low power device such as a phone. If left unset, a new client ID is generated at each wallet start, for privacy reasons. To mine and use a credit balance on two different devices, you can use the --rpc-client-secret-key switch. A wallet's client secret key can be found using the new rpc_payments command in the wallet. Note: anyone knowing your RPC client secret key is able to use your credit balance. The wallet has a few new commands too: - start_mining_for_rpc: start mining to acquire more credits, regardless of the auto mining settings - stop_mining_for_rpc: stop mining to acquire more credits - rpc_payments: display information about current credits with the currently selected daemon The node has an extra command: - rpc_payments: display information about clients and their balances The node will forget about any balance for clients which have been inactive for 6 months. Balances carry over on node restart.
2018-02-11 15:15:56 +00:00
struct wallet_coded_rpc_error : public wallet_rpc_error
{
explicit wallet_coded_rpc_error(std::string&& loc, const std::string& request, int code, const std::string& status)
: wallet_rpc_error(std::move(loc), std::string("error ") + std::to_string(code) + (" in ") + request + " RPC: " + status, request),
m_code(code), m_status(status)
{
}
int code() const { return m_code; }
const std::string& status() const { return m_status; }
private:
int m_code;
const std::string m_status;
};
//----------------------------------------------------------------------------------------------------
2014-04-02 16:00:17 +00:00
struct daemon_busy : public wallet_rpc_error
{
explicit daemon_busy(std::string&& loc, const std::string& request)
: wallet_rpc_error(std::move(loc), "daemon is busy", request)
{
}
};
//----------------------------------------------------------------------------------------------------
struct no_connection_to_daemon : public wallet_rpc_error
{
explicit no_connection_to_daemon(std::string&& loc, const std::string& request)
: wallet_rpc_error(std::move(loc), "no connection to daemon", request)
{
}
};
//----------------------------------------------------------------------------------------------------
struct is_key_image_spent_error : public wallet_rpc_error
{
explicit is_key_image_spent_error(std::string&& loc, const std::string& request)
: wallet_rpc_error(std::move(loc), "error from is_key_image_spent call", request)
{
}
};
//----------------------------------------------------------------------------------------------------
struct get_histogram_error : public wallet_rpc_error
{
explicit get_histogram_error(std::string&& loc, const std::string& request)
: wallet_rpc_error(std::move(loc), "failed to get output histogram", request)
{
}
};
//----------------------------------------------------------------------------------------------------
struct get_output_distribution : public wallet_rpc_error
{
explicit get_output_distribution(std::string&& loc, const std::string& request)
: wallet_rpc_error(std::move(loc), "failed to get output distribution", request)
{
}
};
//----------------------------------------------------------------------------------------------------
daemon, wallet: new pay for RPC use system Daemons intended for public use can be set up to require payment in the form of hashes in exchange for RPC service. This enables public daemons to receive payment for their work over a large number of calls. This system behaves similarly to a pool, so payment takes the form of valid blocks every so often, yielding a large one off payment, rather than constant micropayments. This system can also be used by third parties as a "paywall" layer, where users of a service can pay for use by mining Monero to the service provider's address. An example of this for web site access is Primo, a Monero mining based website "paywall": https://github.com/selene-kovri/primo This has some advantages: - incentive to run a node providing RPC services, thereby promoting the availability of third party nodes for those who can't run their own - incentive to run your own node instead of using a third party's, thereby promoting decentralization - decentralized: payment is done between a client and server, with no third party needed - private: since the system is "pay as you go", you don't need to identify yourself to claim a long lived balance - no payment occurs on the blockchain, so there is no extra transactional load - one may mine with a beefy server, and use those credits from a phone, by reusing the client ID (at the cost of some privacy) - no barrier to entry: anyone may run a RPC node, and your expected revenue depends on how much work you do - Sybil resistant: if you run 1000 idle RPC nodes, you don't magically get more revenue - no large credit balance maintained on servers, so they have no incentive to exit scam - you can use any/many node(s), since there's little cost in switching servers - market based prices: competition between servers to lower costs - incentive for a distributed third party node system: if some public nodes are overused/slow, traffic can move to others - increases network security - helps counteract mining pools' share of the network hash rate - zero incentive for a payer to "double spend" since a reorg does not give any money back to the miner And some disadvantages: - low power clients will have difficulty mining (but one can optionally mine in advance and/or with a faster machine) - payment is "random", so a server might go a long time without a block before getting one - a public node's overall expected payment may be small Public nodes are expected to compete to find a suitable level for cost of service. The daemon can be set up this way to require payment for RPC services: monerod --rpc-payment-address 4xxxxxx \ --rpc-payment-credits 250 --rpc-payment-difficulty 1000 These values are an example only. The --rpc-payment-difficulty switch selects how hard each "share" should be, similar to a mining pool. The higher the difficulty, the fewer shares a client will find. The --rpc-payment-credits switch selects how many credits are awarded for each share a client finds. Considering both options, clients will be awarded credits/difficulty credits for every hash they calculate. For example, in the command line above, 0.25 credits per hash. A client mining at 100 H/s will therefore get an average of 25 credits per second. For reference, in the current implementation, a credit is enough to sync 20 blocks, so a 100 H/s client that's just starting to use Monero and uses this daemon will be able to sync 500 blocks per second. The wallet can be set to automatically mine if connected to a daemon which requires payment for RPC usage. It will try to keep a balance of 50000 credits, stopping mining when it's at this level, and starting again as credits are spent. With the example above, a new client will mine this much credits in about half an hour, and this target is enough to sync 500000 blocks (currently about a third of the monero blockchain). There are three new settings in the wallet: - credits-target: this is the amount of credits a wallet will try to reach before stopping mining. The default of 0 means 50000 credits. - auto-mine-for-rpc-payment-threshold: this controls the minimum credit rate which the wallet considers worth mining for. If the daemon credits less than this ratio, the wallet will consider mining to be not worth it. In the example above, the rate is 0.25 - persistent-rpc-client-id: if set, this allows the wallet to reuse a client id across runs. This means a public node can tell a wallet that's connecting is the same as one that connected previously, but allows a wallet to keep their credit balance from one run to the other. Since the wallet only mines to keep a small credit balance, this is not normally worth doing. However, someone may want to mine on a fast server, and use that credit balance on a low power device such as a phone. If left unset, a new client ID is generated at each wallet start, for privacy reasons. To mine and use a credit balance on two different devices, you can use the --rpc-client-secret-key switch. A wallet's client secret key can be found using the new rpc_payments command in the wallet. Note: anyone knowing your RPC client secret key is able to use your credit balance. The wallet has a few new commands too: - start_mining_for_rpc: start mining to acquire more credits, regardless of the auto mining settings - stop_mining_for_rpc: stop mining to acquire more credits - rpc_payments: display information about current credits with the currently selected daemon The node has an extra command: - rpc_payments: display information about clients and their balances The node will forget about any balance for clients which have been inactive for 6 months. Balances carry over on node restart.
2018-02-11 15:15:56 +00:00
struct payment_required: public wallet_rpc_error
{
explicit payment_required(std::string&& loc, const std::string& request)
: wallet_rpc_error(std::move(loc), "payment required", request)
{
}
};
//----------------------------------------------------------------------------------------------------
2014-04-02 16:00:17 +00:00
struct wallet_files_doesnt_correspond : public wallet_logic_error
{
explicit wallet_files_doesnt_correspond(std::string&& loc, const std::string& keys_file, const std::string& wallet_file)
: wallet_logic_error(std::move(loc), "file " + wallet_file + " does not correspond to " + keys_file)
{
}
const std::string& keys_file() const { return m_keys_file; }
const std::string& wallet_file() const { return m_wallet_file; }
std::string to_string() const { return wallet_logic_error::to_string(); }
private:
std::string m_keys_file;
std::string m_wallet_file;
};
//----------------------------------------------------------------------------------------------------
struct mms_error : public wallet_logic_error
{
protected:
explicit mms_error(std::string&& loc, const std::string& message)
: wallet_logic_error(std::move(loc), message)
{
}
};
//----------------------------------------------------------------------------------------------------
struct no_connection_to_bitmessage : public mms_error
{
explicit no_connection_to_bitmessage(std::string&& loc, const std::string& address)
: mms_error(std::move(loc), "no connection to PyBitmessage at address " + address)
{
}
};
//----------------------------------------------------------------------------------------------------
struct bitmessage_api_error : public mms_error
{
explicit bitmessage_api_error(std::string&& loc, const std::string& error_string)
: mms_error(std::move(loc), "PyBitmessage returned " + error_string)
{
}
};
//----------------------------------------------------------------------------------------------------
2014-04-02 16:00:17 +00:00
#if !defined(_MSC_VER)
template<typename TException, typename... TArgs>
void throw_wallet_ex(std::string&& loc, const TArgs&... args)
{
TException e(std::move(loc), args...);
LOG_PRINT_L0(e.to_string());
throw e;
}
#else
#include <boost/preprocessor/repetition/enum_binary_params.hpp>
#include <boost/preprocessor/repetition/enum_params.hpp>
#include <boost/preprocessor/repetition/repeat_from_to.hpp>
template<typename TException>
void throw_wallet_ex(std::string&& loc)
{
TException e(std::move(loc));
LOG_PRINT_L0(e.to_string());
throw e;
}
#define GEN_throw_wallet_ex(z, n, data) \
template<typename TException, BOOST_PP_ENUM_PARAMS(n, typename TArg)> \
void throw_wallet_ex(std::string&& loc, BOOST_PP_ENUM_BINARY_PARAMS(n, const TArg, &arg)) \
{ \
TException e(std::move(loc), BOOST_PP_ENUM_PARAMS(n, arg)); \
LOG_PRINT_L0(e.to_string()); \
throw e; \
}
BOOST_PP_REPEAT_FROM_TO(1, 6, GEN_throw_wallet_ex, ~)
#endif
}
}
#define STRINGIZE_DETAIL(x) #x
#define STRINGIZE(x) STRINGIZE_DETAIL(x)
#define THROW_WALLET_EXCEPTION(err_type, ...) \
do { \
LOG_ERROR("THROW EXCEPTION: " << #err_type); \
tools::error::throw_wallet_ex<err_type>(std::string(__FILE__ ":" STRINGIZE(__LINE__)), ## __VA_ARGS__); \
} while(0)
2014-04-07 15:02:15 +00:00
#define THROW_WALLET_EXCEPTION_IF(cond, err_type, ...) \
2014-04-02 16:00:17 +00:00
if (cond) \
{ \
LOG_ERROR(#cond << ". THROW EXCEPTION: " << #err_type); \
tools::error::throw_wallet_ex<err_type>(std::string(__FILE__ ":" STRINGIZE(__LINE__)), ## __VA_ARGS__); \
}