| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
|
|
To transfer ~5 XMR to an address such that your balance drops by exactly 5 XMR, provide a `subtractfeefrom` flag to the `transfer` command. For example:
transfer 76bDHojqFYiFCCYYtzTveJ8oFtmpNp3X1TgV2oKP7rHmZyFK1RvyE4r8vsJzf7SyNohMnbKT9wbcD3XUTgsZLX8LU5JBCfm 5 subtractfeefrom=all
If my walet balance was exactly 30 XMR before this transaction, it will be exactly 25 XMR afterwards and the destination address will receive slightly
less than 5 XMR. You can manually select which destinations fund the transaction fee and which ones do not by providing the destination index.
For example:
transfer 75sr8AAr... 3 74M7W4eg... 4 7AbWqDZ6... 5 subtractfeefrom=0,2
This will drop your balance by exactly 12 XMR including fees and will spread the fee cost proportionally (3:5 ratio) over destinations with addresses
`75sr8AAr...` and `7AbWqDZ6...`, respectively.
Disclaimer: This feature was paid for by @LocalMonero.
|
|
1. Daemon-specific proxy is exclusive with global proxy (--proxy).
2. If you set global proxy (--proxy) you cannot set daemon-specific proxy.
3. If you don't set global proxy, you can set proxy (or not set) proxy for
each daemon connection with the proxy field in jsonrpc to the wallet-rpc.
|
|
Some downstream code (most notably PR https://github.com/UkoeHB/monero/pull/25) wants to use the src/serialization lib
for storing information persistently. When one builds classes/machines wishing to serialize containers, they must use
the `serializable_*` container classes. In this case, this makes the Seraphis library code unnecessarily tightly coupled
with the src/serialization code since one cannot swap out their type of storage format without major refactoring of class
field types. By serializing STL containers directly, we can abstract the serialization details away, making for much
cleaner design. Also small bonus side effect of this change is that STL containers with custom Comparators, Allocators,
and Hashers are serializable. `std::multimap` is added to the list of serializable containers.
Depends upon https://github.com/monero-project/monero/pull/9069.
|
|
|
|
Multisig keys per-transfer were being wiped, but not erased, which lead to a ginormous
quadratic bloat the more transfers and exports you performed with the wallet.
|
|
Since we are required to check for uniqueness of decoy picks within any given
ring, and since some decoy picks may fail due to unlock time or malformed EC points,
the wallet2 decoy selection code was building up a larger than needed *unique* set of
decoys for each ring according to a certain distribution *without replacement*. After
filtering out the outputs that it couldn't use, it chooses from the remaining decoys
uniformly random *without replacement*.
The problem with this is that the picks later in the picking process are not independent
from the picks earlier in the picking process, and the later picks do not follow the
intended decoy distribution as closely as the earlier picks. To understand this
intuitively, imagine that you have 1023 marbles. You label 512 marbles with the letter A,
label 256 with the letter B, so on and so forth, finally labelling one marble with the
letter J. You put them all into a bag, shake it well, and pick 8 marbles from the bag,
but everytime you pick a marble of a certain letter, you remove all the other marbles
from that bag with the same letter. That very first pick, the odds of picking a certain
marble are exactly how you would expect: you are twice as likely to pick A as you are B,
twice as likely to pick B as you are C, etc. However, on the second pick, the odds of
getting the first pick are 0%, and the chances for everything else is higher. As you go
down the line, your picked marbles will have letters that are increasingly more unlikely
to pick if you hadn't remove the other marbles. In other words, the distribution of the
later marbles will be more "skewed" in comparison to your original distribution of marbles.
In Monero's decoy selection, this same statistical effect applies. It is not as dramatic
since the distribution is not so steep, and we have more unique values to choose from,
but the effect *is* measureable. Because of the protocol rules, we cannot have duplicate
ring members, so unless that restriction is removed, we will never have perfectly
independent picking. However, since the earlier picks are less affected by this
statistical effect, the workaround that this commit offers is to store the order that
the outputs were picked and commit to this order after fetching output information over RPC.
|
|
|
|
The Monero GUI code was calling `Monero::wallet::setPassword()` on every open/close for some reason,
and the old `store_to()` code called `store_keys()` with `watch_only=false`, even for watch-only wallets.
This caused a bug where the watch-only keys file got saved with with the JSON field `watch_only` set to 0,
and after saving a watch-only wallet once, a user could never open it back up against because `load()` errored out.
This never got brought up before this because you would have to change the file location of the watch-only
wallet to see this bug, and I guess that didn't happen often, but calling the new `store_to()` function with the
new `force_rewrite` parameter set to `true` triggers key restoring and the bug appeared.
|
|
Resolves #8932 and:
2. Not storing cache when new path is different from old in `store_to()` and
3. Detecting same path when new path contains entire string of old path in `store_to()` and
4. Changing your password / decrypting your keys (in this method or others) and providing a bad original password and getting no error and
5. Changing your password and storing to a new file
|
|
|
|
|
|
Co-authored-by: woodser <woodser@protonmail.com>
|
|
|
|
|
|
- Detach & re-process txs >= lowest scan height
- ensures that if a user calls scan_tx(tx1) after scanning tx2,
the wallet correctly processes tx1 and tx2
- if a user provides a tx with a height higher than the wallet's
last scanned height, the wallet will scan starting from that tx's
height
- scan_tx requires trusted daemon iff need to re-process existing
txs: in addition to querying a daemon for txids, if a user
provides a txid of a tx with height *lower* than any *already*
scanned txs in the wallet, then the wallet will also query the
daemon for all the *higher* txs as well. This is likely
unexpected behavior to a caller, and so to protect a caller from
revealing txid's to an untrusted daemon in an unexpected way,
require the daemon be trusted.
|
|
Before this change, if a multisig peer asked you to sign a transaction with a frozen enote, the wallet will do it without any error or warning. This change makes it
so that wallets will refuse to sign multisig transactions with frozen enotes.
Disclaimer: This PR was generously funded by @LocalMonero.
|
|
|
|
|
|
|
|
Ensures both transfers and sweeps use a fee that's calculated
from the tx's weight. Using different logic could theoretically
enable distinguishability between the two types of txs. We don't
want that.
|
|
|
|
Using post-PR wallet with pre-PR node will generate error message specific to this PR and not generic "command failed" mesages.
|
|
from first spendable block
|
|
The gamma picker and the caller code did not quite agree on the
number of rct outputs available for use - by one block - which
caused an infinite loop if the picker could never pick outputs
from that block but already had picked all other outputs from
previous blocks.
Also change the range to select from using code from UkoeHB.
|
|
|
|
Fixes #8793
|
|
it was mistaking the number of forks in the fork table for
the last fork, and assuming the table was including every
single fork
|
|
- `/getblocks.bin` respects the `RESTRICTED_TX_COUNT` (=100) when
returning pool txs via a restricted RPC daemon.
- A restricted RPC daemon includes a max of `RESTRICTED_TX_COUNT` txs
in the `added_pool_txs` field, and returns any remaining pool hashes
in the `remaining_added_pool_txids` field. The client then requests
the remaining txs via `/gettransactions` in chunks.
- `/gettransactions` no longer does expensive no-ops for ALL pool txs
if the client requests a subset of pool txs. Instead it searches for
the txs the client explicitly requests.
- Reset `m_pool_info_query_time` when a user:
(1) rescans the chain (so the wallet re-requests the whole pool)
(2) changes the daemon their wallets points to (a new daemon would
have a different view of the pool)
- `/getblocks.bin` respects the `req.prune` field when returning
pool txs.
- Pool extension fields in response to `/getblocks.bin` are optional
with default 0'd values.
|
|
|
|
Co-authored-by: plowsof <plowsof@protonmail.com>
extra files
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Co-authored-by: woodser <woodser@protonmail.com>
|
|
- spend secret key is no longer the sum of multisig key shares;
no need to check that is the case upon restore.
- restoring a multisig wallet from multisig info means that the
wallet must have already completed all setup rounds. Upon restore,
set the number of rounds completed accordingly.
|
|
reported by j-berman
|
|
Being offline is not a good enough heuristic, so we keep track
of whether the wallet ever refreshed from a daemon, which is a
lot better, and probably the best we can do without manual user
designation (which would break existing cold wallet setups till
the user designates those wallets)
|
|
this will make it easier huge wallets to do so without hitting
random limits (eg, max string size in node).
|
|
- only allow offline wallets to import outputs
- don't import empty outputs
- export subaddress indexes when exporting outputs
|
|
|
|
|
|
|
|
key images
|
|
hash_extra: don't test for success in `jh_hash` and `skein_hash` since its guaranteed
device_ledger: move anonymous global variable apdu_verbose into .cpp file
Add comments to `refreshed` method variable in wallet2
|
|
|
|
|
|
|
|
Co-authored-by: j-berman <justinberman@protonmail.com>
|
|
|
|
|
|
|
|
unconfirmed solely uses a - b, and received now accepts b so it can
provide more detailed logs on what occurred (printing a - b, yet with a
and b).
|
|
There are vulnerabilities in multisig protocol if the parties do not
trust each other, and while there is a patch for it, it has not been
throroughly reviewed yet, so it is felt safer to disable multisig by
default for now.
If all parties in a multisig setup trust each other, then it is safe
to enable multisig.
|
|
When forced to deal with an untrusted node, a wallet will quantize
its current height to disguise the real height to the adversary, to
try and minimize the daemon's ability to distinguish returning
wallets.
Daemons will thus return more blocks than the wallet needs, starting
from earlier in the chain. These extra blocks will be disregarded
by the wallet, which had already scanned them.
However, for the purposes of reorg size detection, the wallet assumes
all blocks the daemon sends are different, which is only correct if
the wallet hasn't been coy, which is only the case for trusted
daemons (which you should use). This causes an issue when the size
of this "fake reorg" is above the sanity check threshold at which
the wallet refuses a reorg.
To fix this, the reorg size check is moved later on, when the reorg
is about to actually happen, after the wallet has checked which
blocks are actually different from the ones it expects.
|
|
2.8 seconds -> 2.6 seconds on a test case
|
|
3.3 seconds -> 2.8 seconds on a test case
|
|
5.2 seconds -> 4.1 seconds on a test case
|
|
5.9 second -> 5.2 seconds on a test case
|
|
|
|
have completed the multisig address
|
|
|
|
|
|
Implements view tags as proposed by @UkoeHB in MRL issue
https://github.com/monero-project/research-lab/issues/73
At tx construction, the sender adds a 1-byte view tag to each
output. The view tag is derived from the sender-receiver
shared secret. When scanning for outputs, the receiver can
check the view tag for a match, in order to reduce scanning
time. When the view tag does not match, the wallet avoids the
more expensive EC operations when deriving the output public
key using the shared secret.
|
|
reported by ukoehb
|
|
https://github.com/ArticMine/Monero-Documents/blob/master/MoneroScaling2021-02.pdf
with a change to use 1.7 instead of 2.0 for the max long term increase rate
|
|
It avoids dividing by 8 when deserializing a tx, which is a slow
operation, and multiplies by 8 when verifying and extracing the
amount, which is much faster as well as less frequent
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
we reuse the wallet_keys_unlocker object, which does the right thing
in conjunction with other users of decrypt/encrypt (ie, refresh).
|
|
- combined with patching integer truncation (#7798), this gets the algorithm marginally closer to mirroring empirically observed output ages
- 50 was originally chosen assuming integer truncation would remain in the client for that client release version. But patching integer truncation causes the client to select more outputs in the 10-100 block range, and therefore the benefit of choosing a larger recent spend window of 50 has less merit
- 15 seems well-suited to cover the somewhat sizable observable gap in the early window of blocks
|
|
The fix as suggested by <jberman> on IRC. Before the fix, it would truncate 1.9 to 1 skewing the output selection.
|
|
|
|
RefreshOptimizeCoinbase was an optimization to speed up scanning of coinbase transactions before RingCT (tx version 2) where they split miner reward into multiple denominations, all to the same wallet.
When RingCT was introduced, all coinbase transactions became 1 output only, so this optimization does nothing now.
With p2pool, this optimization will skip scanning p2pool payouts because they use more than 1 output in coinbase transaction.
Fix it by applying this optimization only to pre-RingCT transactions (version < 2).
|
|
|
|
|
|
- matches the paper by Miller et al to apply the gamma from chain tip, rather than after unlock time
- if the gamma produces an output more recent than the unlock time, the algo packs that output into one of the first 50 spendable blocks, respecting the block density factor
|
|
|
|
- Try empty passphrase first when opening a wallet, as all Trezors will have passphrase enabled by default by Trezor Suite by default.
This feature enables easier access to all users using disabled passphrase (or empty passhprase)
- If wallet address differs from device address with empty passphrase, another opening attempt is made, without passphrase suppression,
so user can enter his passhprase if using some. In this scenario, nothing changes to user, wallet opening just consumes one more call
to Trezor (get wallet address with empty passphrase)
- also change how m_passphrase is used. Previous version did not work well with recent passphrase entry mechanism change (made in Trezor),
thus this commit fixes the behaviour).
|
|
|
|
|
|
|
|
|
|
|
|
RPC pay client ID is sent with each RPC request, set a new secret every time we switch nodes to mitigate trivial correlation
|
|
|
|
|
|
|
|
if the wallet does it, it would get a wrong result (possibly even
negative) if its local chain is not synced up to the daemon's yet
|
|
|
|
|
|
On Mac, size_t is a distinct type from uint64_t, and some
types (in wallet cache as well as cold/hot wallet transfer
data) use pairs/containers with size_t as fields. Mac would
save those as full size, while other platforms would save
them as varints. Might apply to other platforms where the
types are distinct.
There's a nasty hack for backward compatibility, which can
go after a couple forks.
|
|
To implement this feature, the wallet2::scan_tx API was implemented.
|
|
There are quite a few variables in the code that are no longer
(or perhaps never were) in use. These were discovered by enabling
compiler warnings for unused variables and cleaning them up.
In most cases where the unused variables were the result
of a function call the call was left but the variable
assignment removed, unless it was obvious that it was
a simple getter with no side effects.
|
|
|
|
Do this for both the estimate and actual fee.
#7337
|
|
If more outputs are requested, they are split across
multiple transactions.
#7322
|
|
|
|
do not include blocked hosts in peer lists or public node lists by default,
warn about no https on clearnet and about untrusted peers likely being spies
|
|
|
|
|
|
|
|
|
|
|
|
|
|
- index out of bounds when importing outputs
- accessing invalid CLSAG data
|
|
|
|
|
|
|
|
|
|
|
|
Those would, if uncaught, exit run and leave the waiter to wait
indefinitely for the number of active jobs to reach 0
|
|
|
|
|
|
They are allowed from v12, and MLSAGs are rejected from v13.
|
|
This reverts commit 921dd8dde5d381052d0aa2936304a3541a230c55.
|
|
This reduces the attack surface for data that can come from
malicious sources (exported output and key images, multisig
transactions...) since the monero serialization is already
exposed to the outside, and the boost lib we were using had
a few known crashers.
For interoperability, a new load-deprecated-formats wallet
setting is added (off by default). This allows loading boost
format data if there is no alternative. It will likely go
at some point, along with the ability to load those.
Notably, the peer lists file still uses the boost serialization
code, as the data it stores is define in epee, while the new
serialization code is in monero, and migrating it was fairly
hairy. Since this file is local and not obtained from anyone
else, the marginal risk is minimal, but it could be migrated
later if needed.
Some tests and tools also do, this will stay as is for now.
|
|
The tx key derivation is different then
|
|
|
|
include all public proof parameters in Schnorr challenges, along with hash function domain separators. Includes new randomized unit tests.
|
|
insert doesn't actually insert if another element with the
same key is already in the map
|
|
The sort predicate is a boolean ordered-before value, but these are
returning the memcmp value directly, and thus returns true whenever the
pubkeys aren't equal. This means:
- it isn't actually sorting.
- it can (and does) segfault for some inputs.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Update copyright year to 2020
|
|
|
|
|
|
- choice where to enter passphrase is now made on the host
- use wipeable string in the comm stack
- wipe passphrase memory
- protocol optimizations, prepare for new firmware version
- minor fixes and improvements
- tests fixes, HF12 support
|
|
|
|
|
|
- Add abstract_http_client.h which http_client.h extends.
- Replace simple_http_client with abstract_http_client in wallet2,
message_store, message_transporter, and node_rpc_proxy.
- Import and export wallet data in wallet2.
- Use #if defined __EMSCRIPTEN__ directives to skip incompatible code.
|
|
Reported by UkoeHB_ and sarang
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
The backward compatibility code was always setting it to 1
in modern wallets since store_tx_keys was not present and thus
assumed to be 1 by default.
Reported by SeventhAlpaca
|
|
Because the user might do this for reasons unknown.
Values beyond l-1 will be reduced, so are accepted.
Reported by who-biz.
|
|
|
|
Adding a new `amounts` field ot the output of `get_transfers` RPC
method. This field specifies individual payments made to a single
subaddress in a single transaction, e.g., made by this command:
transfer <addr1> <amount1> <addr1> <amount2>
|
|
Even if it fails, the ring composition is known to a potential
adversary, and so we should reuse the same ring next time
|
|
|
|
|
|
If more than one thread wants to make sure of the spend secret key,
then we decrypt on the first caller and reencrypt on the last caller,
otherwise we could use an invalid secret key.
|
|
If the hashes received would move the current blockchain past the
stop point, the short history would not be updated, since we do
not expect another loop, but the daemon might return earlier hashes,
causing the end index to not be enough to reach the threshold and
this require another loop, which will download the same hashes and
cause an infinite loop.
|
|
|
|
|
|
|
|
|
|
|
|
Target height would be appropriate for the daemon, which syncs
off other daemons, but the wallet syncs off the daemon it's
connected to, and its target is the daemon's current height.
|
|
We get new pool txes before processing any tx, pool or not.
This ensures that if we're asked for a password, this does not
cause a measurable delay in the txpool query after the last
block query.
|
|
The "everything refreshed" state was detected when a refresh call did
not return any new blocks. This can be detected without that extra
"empty" call by comparing the claimed node height to the height of
the last block retrieved. Doing this avoids that last call, saves
some bandwidth, and makes the common refresh case use only one call
rather than two.
As a side effect, it prevents an information leak reported by
Tramèr et al: if the wallet retrieves a set of blocks which includes
an output sent to the refreshing wallet, the wallet will prompt the
user for the password to decode the amount and calculate the key
image for the new output, and this will delay subsequent calls to
getblocks.bin, allowing a passive adversary to note the delay and
deduce when the wallet receives at least one output.
This can still happen if the wallet downloads more than 1000 blocks,
since this will be split in several calls, but then the most the
adversary can tell is which 1000 block section the user received
some monero (the adversary can estimate the heights of the blocks
by calculating how many "large" transfers are done, which will be
sections of blocks, the last of which will usually be below 1000,
but the size of the data should allow the actual number of blocks
sent to be determined fairly accurately).
This timing trick still be used via the subsequent scan for incoming
txes in the txpool, which will be fixed later.
|
|
This lets a passive attacker with access to the network link
between node and wallet perform traffic analysis to deduce
when an idle wallet receives a transaction.
Reported by Tramèr et al.
|
|
protects against having your keys mangled
|
|
Lists nodes exposing their RPC port for public use
|
|
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.
|
|
|
|
|
|
|
|
|
|
|
|
https://github.com/aeonix/aeon/pull/131
|
|
If the peer (whether pruned or not itself) supports sending pruned blocks
to syncing nodes, the pruned version will be sent along with the hash
of the pruned data and the block weight. The original tx hashes can be
reconstructed from the pruned txes and theur prunable data hash. Those
hashes and the block weights are hashes and checked against the set of
precompiled hashes, ensuring the data we received is the original data.
It is currently not possible to use this system when not using the set
of precompiled hashes, since block weights can not otherwise be checked
for validity.
This is off by default for now, and is enabled by --sync-pruned-blocks
|
|
|
|
|
|
|
|
One considers the blockchain, while the other considers the
blockchain and some recent actions, such as a recently created
transaction which spend some outputs, but isn't yet mined.
Typically, the "balance" command wants the latter, to reflect
the recent action, but things like proving ownership wants
the former.
This fixes a crash in get_reserve_proof, where a preliminary
check and the main code used two concepts of "balance".
|
|
|
|
|
|
|
|
|
|
|
|
|
|
New CLI wallet variable: export-format with options "binary" (the default),
or "ascii". "Binary" behaves as before, "ascii" forces the wallet to convert
data to ASCII using base64.
Reading files from the disk tries to auto detect what format has been
used (using a magic string added when exporting the data).
Implements https://github.com/monero-project/monero/issues/2859
|
|
It lets the user add custom entropy to the PRNG.
It does this by hashing the new data and xoring the resulting
hash with the PRNG state.
|
|
|
|
According to [1], std::random_shuffle is deprecated in C++14 and removed
in C++17. Since std::shuffle is available since C++11 as a replacement
and monero already requires C++11, this is a good replacement.
A cryptographically secure random number generator is used in all cases
to prevent people from perhaps copying an insecure std::shuffle call
over to a place where a secure one would be warranted. A form of
defense-in-depth.
[1]: https://en.cppreference.com/w/cpp/algorithm/random_shuffle
|
