When RingCT is enabled, outputs from coinbase transactions
are created as a single output, and stored as RingCT output,
with a fake mask. Their amount is not hidden on the blockchain
itself, but they are then able to be used as fake inputs in
a RingCT ring. Since the output amounts are hidden, their
"dustiness" is not an obstacle anymore to mixing, and this
makes the coinbase transactions a lot smaller, as well as
helping the TXO set to grow more slowly.
Also add a new "Null" type of rct signature, which decreases
the size required when no signatures are to be stored, as
in a coinbase tx.
This allows the key to be not the same for two outputs sent to
the same address (eg, if you pay yourself, and also get change
back). Also remove the key amounts lists and return parameters
since we don't actually generate random ones, so we don't need
to save them as we can recalculate them when needed if we have
the correct keys.
This plugs a privacy leak, where the wallet tells the daemon
which transactions contain outputs for the wallet by asking
for additional information for that particular transaction.
As a nice bonus, this actually makes refresh slightly faster.
With RCT, we allow 0 size outputs, to try and encourage txes
with two inputs and two outputs. Consolidation would then
have two non zero inputs, one zero output, and one larger
output.
Before the normal selection, we attempt to find either one or two
suitable outputs to use as inputs to the rct tx. The intent is that
most rct txes will have one or two inputs, and we want all to look
the same if possible.
When two outputs are needed, we try to find a pair which are not
related (ie, by being from the same or similar block height).
The "transfer" simplewallet command is renamed to "transfer_original".
"transfer_new" is renamed "transfer", "transfer_rct" is removed,
and the new "transfer" now selects rct or non rct transactions
based on the current block height.
The mixRing (output keys and commitments) and II fields (key images)
can be reconstructed from vin data.
This saves some modest amount of space in the tx.
If the blockchain gets reorganized, all outputs spent in the part
of the blockchain that's blown away need to be reset to unspent
(they may end up spent again on the blocks that replace the blocks
that are removed, however).
99dd572 libwallet_api: tests: checking for result while opening wallet (Ilya Kitaev)
bcf7b67 libwallet_api: Wallet::amountFromString fixed (Ilya Kitaev)
32bc7b4 libwallet_api: helper method to return maximumAllowedAmount (Ilya Kitaev)
cbe534d libwallet_api: tests: removed logged passwords (Ilya Kitaev)
b1a5a93 libwallet_api: do not store wallet on close if status is not ok (Ilya Kitaev)
This plugs a privacy leak from the wallet to the daemon,
as the daemon could previously see what input is included
as a transaction input, which the daemon hadn't previously
supplied. Now, the wallet requests a particular set of
outputs, including the real one.
This can result in transactions that can't be accepted if
the wallet happens to select too many outputs with non standard
unlock times. The daemon could know this and select another
output, but the wallet is blind to it. It's currently very
unlikely since I don't think anything uses non default
unlock times. The wallet requests more outputs than necessary
so it can use spares if any of the returns outputs are still
locked. If there are not enough spares to reach the desired
mixin, the transaction will fail.
This constrains the number of instances of any amount
to the unlocked ones (as defined by the default unlock time
setting: outputs with non default unlock time are not
considered, so may be counted as unlocked even if they are
not actually unlocked).
They are used to export a signed set of key images from a wallet
with a private spend key, so an auditor with the matching view key
may see which of those are spent, and which are not.
It is not clear why libunbound was added to this in the first place,
since it wasn't here before and #915 doesn't seem to introduce any
new dependency on it.
Tested build with STATIC=OFF (with and without libunbound-dev libunbound8
installed) and STATIC=ON, on Ubuntu Trusty, Debian Jessie, and Arch
Linux. For static builds, beware of #926 and #907.
If this hack was introduced to make it build on some other system
(Windows? OS X?), then it will have to be dealt with, but not this way.
Signing is done using the spend key, since the view key may
be shared. This could be extended later, to let the user choose
which key (even a per tx key).
simplewallet's sign/verify API uses a file. The RPC uses a
string (simplewallet can't easily do strings since commands
receive a tokenized set of arguments).
Fee can now be multiplied by 2 or 3, if users want to give
priority to their transactions. There are only three levels
to avoid too much fingerprinting. Default is 1 (minimum fee).
The default multiplier can be set by "set fee-multiplier X".
It sets the max number of threads to use for a parallel job.
This is different that the number of total threads, since monero
binaries typically start a lot of them.
It allows a simple get_transfers (with default 0 min_height and
max_height) to return all transactions, instead of the unexpected
set of txes in block 0, which is probably none at all.
This sends all outputs in a wallet to a given address, alleviating
the difficulty people have had trying to send all monero but
being left with some small amount left.
modified: src/wallet/wallet2.cpp
modified: src/wallet/wallet2.h
Update to fix unconfirmed balance and give a slightly more verbose and informative confirmation message for transfers
When m_refresh_from_block_height has been set, only hashes will be
retrieved up to that height, instead of full blocks. The same will
be done for "refresh <height>" when the specified height is beyond
the current local blockchain.
b4eada9 wallet: make load_keys check types when loading JSON (moneromooo-monero)
3e55725 wallet: make the JSON reading type safe (moneromooo-monero)
f8d05f3 common: new json_util.h (moneromooo-monero)
This allows appropriate action to be taken, like displaying
the reason to the user.
Do just that in simplewallet, which should help a lot in
determining why users fail to send.
Also make it so a tx which is accepted but not relayed is
seen as a success rather than a failure.
With the change in mixin rules for v2, the "annoying" outputs are
slightly changed. There is high correlation between dust and
unmixable, but no equivalence.
It takes a filename containing JSON data to generate a wallet.
The following fields are valid:
version: integer, should be 1
filename: string, path/filename for the newly created wallet
scan_from_height: 64 bit unsigned integer, optional
password: string, optional
viewkey: string, hex representation
spendkey: string, hex representation
seed: string, optional, list of words separated by spaces
Either seed or private keys should be given. If using private
keys, the spend key may be omitted (the wallet will not be
able to spend, but will see incoming transactions).
If scan_from_height is given, blocks below this height will not
be checked for transactions as an optimization.
After the fork, normal transfer functions called via RPC
use the minimum mixin 2 if 0 or 1 is requested. While the
incoming transaction may be valid (eg, it has an unmixable
and at most a mixable input), it is a simple way to make
sure RPC users can't get a seemingly random accept/reject
behavior if they don't update their requested mixin.
If it is, it points to reuse of a tx key, which isn't meant to happen.
If it does, a key image collision means that only one of those
outputs is spendable, so the wallet selects the larger amount,
unless that output was spent already.
This causes a discrepancy betewen reported received inputs and
payment total.
Since tx keys are 256 bits, this should never happen except if
done on purpose, or if a sender uses a bad PRNG.
7fc6fa3 wallet: forbid dust altogether in output selection where appropriate (moneromooo-monero)
5e1a739 blockchain: log number of outputs available for a new tx (moneromooo-monero)
The value will be different depending on whether we've reached
the first hard fork, which allows a larger size, or not.
This fixes transactions being rejected by the daemon on mainnet
where the first hard fork is not yet active.
Blockchain hashes and key images are flushed, and blocks are
pulled anew from the daemon.
The console command is shortened to match bc_height.
This should make it a lot easier on users who are currently
told to remove this particular cache file but keep the keys
one, etc, etc.
The version number passed to those data's serialize function
was always 0, not the wallet's version as I had expected.
A version number now exists for these structures so they're
versioned correctly.
^C while in manual refresh will cancel the refresh, since that's
often an annoying thing to have to wait for. Also, a manual refresh
command will interrupt any running background refresh and take
over, rather than wait for the background refresh to be done, and
look to be hanging.
The daemon will be polled every 90 seconds for new blocks.
It is enabled by default, and can be turned on/off with
set auto-refresh 1 and set auto-refresh 0 in the wallet.
Assume the whole of a coinbase goes to the same address (so that
if the first output isn't for us, none of it is), and only look
for payment id when we received something in the transaction.
The wallet and the daemon applied different height considerations
when selecting outputs to use. This can leak information on which
input in a ring signature is the real one.
Found and originally fixed by smooth on Aeon.
f197599 wallet: encrypt the cache file (moneromooo-monero)
98c76a3 chacha8: add a key generation variant that take a pointer and size (moneromooo-monero)
It contains private data, such as a record of transactions.
The key is derived from the view and spend secret keys.
The encryption currently is one shot, so may require a lot of
memory for large wallet caches.
This obsoletes the need for a lengthy blockchain rescan when
a transaction doesn't end up in the chain after being accepted
by the daemon, or any other reason why the wallet's idea of
spent and unspent outputs gets out of sync from the blockchain's.
Pros:
- smaller on the blockchain
- shorter integrated addresses
Cons:
- less sparseness
- less ability to embed actual information
The boolean argument to encrypt payment ids is now gone from the
RPC calls, since the decision is made based on the length of the
payment id passed.
A payment ID may be encrypted using the tx secret key and the
receiver's public view key. The receiver can decrypt it with
the tx public key and the receiver's secret view key.
Using integrated addresses now cause the payment IDs to be
encrypted. Payment IDs used manually are not encrypted by default,
but can be encrypted using the new 'encrypt_payment_id' field
in the transfer and transfer_split RPC calls. It is not possible
to use an encrypted payment ID by specifying a manual simplewallet
transfer/transfer_new command, though this is just a limitation
due to input parsing.
