Changed the wording from "from 0 to maximum available" to "from 2 to maximum available".
May I also suggest putting in a number rather than "maximum available" and also clarifying that mixin = 0 is still allowed if the user has unmixable outputs (dust), which he wants to "undust" using sweep_unmixable (comment from dEBRUYNE-1 ).
This change adds the ability to create a new unsigned transaction
from a watch only wallet, and save it to a file. This file can
then be moved to another computer/VM where a cold wallet may load
it, sign it, and save it. That cold wallet does not need to have
a blockchain nor daemon. The signed transaction file can then be
moved back to the watch only wallet, which can load it and send
it to the daemon.
Two new simplewallet commands to use it:
sign_transfer (on the cold wallet)
submit_transfer (on the watch only wallet)
The transfer command used on a watch only wallet now writes an
unsigned transaction set in a file called 'unsigned_monero_tx'
instead of submitting the tx to the daemon as a normal wallet does.
The signed tx file is called 'signed_monero_tx'.
This is intended to catch traffic coming from a web browser,
so we avoid issues with a web page sending a transfer RPC to
the wallet. Requiring a particular user agent can act as a
simple password scheme, while we wait for 0MQ and proper
authentication to be merged.
This fixes misreporting of amount/fee in rct txes, as the rct
tx construction code was lumping all dests (whether change or
not) in the same dests vector, while the pre-rct code was
keeping it separate.
Support building internal libraries as shared. This reduces
development time by eliminating the need to re-link all
binaries every time non-interface code in the library changes.
Instead, can hack on libxyz, then `make libxyz`, and re-run
monerod.
By default BUILD_SHARED_LIBS is OFF in release build type,
and ON in debug build type, but can be overriden with -D.
Keep the immediate direct deps at the library that depends on them,
declare deps as PUBLIC so that targets that link against that library
get the library's deps as transitive deps.
Break dep cycle between blockchain_db <-> crytonote_core.
No code refactoring, just hide cycle from cmake so that
it doesn't complain (cycles are allowed only between
static libs, not shared libs).
This is in preparation for supproting BUILD_SHARED_LIBS cmake
built-in option for building internal libs as shared.
We keep 1, 2, 3 multipliers till the fee decrase from 0.01/kB
to 0.002/kB, where we start using 1, 20, 166 multipliers.
This ensures the higher multiplier will compensate for the
block reward penalty when pushing past 100% of the past median.
The fee-multiplier wallet setting is now rename to priority,
since it keeps its [0..3] range, but maps to different multiplier
values.
This adds [snap](https://snapcraft.io) packaging to the project. See the
link for more information on snaps. Snap packages install on all Linux
distributions. On Ubuntu, snap confinement with apparmor and seccomp
provide an additional layer of security.
This snap sets up monerod as a systemd service, which should start
immediately on install. To access the wallet CLI, simply run `monero`
(/snap/bin/monero). I think it's a really quick & easy way to get
started with monero.
I've made some opinionated decisions in the packaging just to kick this
off, but I'm happy to iterate on this stuff.
This was disabled earlier as part of diagnosing failing tests
on ARM, which turned out to be due to aliasing, fixed by
adding -fno-strict-aliasing. So, re-enabling it back.
32-bit build would fail to link with 'mdb_env_create undefined' (because
for 32-bit build, mdb_env_create_vl32 is defined instead).
This bug was introduced with the recent change to virtual object
libraries. The problem is that the COMPILE_DEFINITIONS property
was not propagated from dependee target (lmdb) to depedent
target's (blockchain_db) virtual object lib (obj_blockchain_db).
This patch makes that happen.
I chose to include INTERFACE_COMPILE_DEFINITIONS because there
should not be a need to propagate private defs, but it doesn't
make a difference in this case.
f1d87c8 simplewallet: add magic and public keys to key image export file (moneromooo-monero)
f4e894a simplewallet: make the key image export format binary (moneromooo-monero)
Since this queries block heights for blocks that may or may not
exist, queries for non existing blocks would throw an exception,
and that would slow down the loop a lot. 7 seconds to go through
a 30 hash list.
Fix this by adding an optional return block height to block_exists
and using this instead. Actual errors will still throw an
exception.
This also cuts down on log exception spam.
CMake issued a warming about policy CMP0026: access of LOCATION
target property at config time was disallowed. Offending code
was the code that merged static libraries to generate
libwallet_merged.a.
This patch does that same merge task in a much simpler way. And,
since it doesn't violate the policy, the warning went away.
The code used to cap at 5000 blocks per sync. It also treated 0 as 1.
Remove these checks; if specified as 0 do no periodic syncs at all.
Then the user is responsible for syncing in some external process.
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.
The whole rct data apart from the MLSAGs is now included in
the signed message, to avoid malleability issues.
Instead of passing the data that's not serialized as extra
parameters to the verification API, the transaction is modified
to fill all that information. This means the transaction can
not be const anymore, but it cleaner in other ways.
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.
Since these are needed at the same time as the output pubkeys,
this is a whole lot faster, and takes less space. Only outputs
of 0 amount store the commitment. When reading other outputs,
a fake commitment is regenerated on the fly. This avoids having
to rewrite the database to add space for fake commitments for
existing outputs.
This code relies on two things:
- LMDB must support fixed size records per key, rather than
per database (ie, all records on key 0 are the same size, all
records for non 0 keys are same size, but records from key 0
and non 0 keys do have different sizes).
- the commitment must be directly after the rest of the data
in outkey and output_data_t.
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).
It may be suboptimal, but it's a pain to have to rebuild everything
when some of this changes.
Also, no clue why there seems to be two different code paths for
serializing a tx...
A new version of genRct takes the mixRing as parameter, instead
of the inPk. inPk are part of the mixRing, and it is cleaner to
pass the mixRing data than to fetch it from the RingCT code.
A new version of decodeRct also returns the mask.
Also, failure to decode throws, so errors are properly detected.
This lets my gcc picks those instead of the generic template
where appropriate (and then fail since std::vector<something>
does not have a serialize method.
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.
f0c0a3fFix#864 Squashed commit of the following: commit 9af9e4223b fixed some formatting commit c7920e1cf8 Merge: 97eb28b1da1c68 fix#864 fix using boolean commit 97eb28ba5dFix#864 boolean value used to verify on new wallet commit 1da1c68bd3fix#864 changed to boolean to prompt for verify commit 5bee966524 fix 864; made variable names easier for understanding branching. commit 45715960d3fix#864; allow password to be entered twice for new wallets for verification. fix#864 password entry verification; ammended boolean fix#864 ; default constructor for password_container should set verify=true (guzzi_jones)
Simplewallet improperly skipped the restore from height code if
restoring a deterministic wallet AND not specifying a wallet file in the
command line. The other generate options require a wallet file as an
argument, which prevents "ask_wallet_create_if_needed()" from being
called, which in turn causes "m_generate_new" to remain unset.
Specifying a wallet file at launch with --restore-deterministic emulated
this behavior.
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).
Squashed commit of the following:
commit 9af9e4223b
fixed some formatting
commit c7920e1cf8
Merge: 97eb28b1da1c68
fix#864 fix using boolean
commit 97eb28ba5dFix#864 boolean value used to verify on new wallet
commit 1da1c68bd3fix#864 changed to boolean to prompt for verify
commit 5bee966524
fix 864; made variable names easier for understanding branching.
commit 45715960d3fix#864; allow password to be entered twice for new wallets for verification.
fix#864 password entry verification; ammended boolean
fix#864 ; default constructor for password_container should set verify=true
The previous logic that used a COMMON_*_FLAGS intermediate variable
and then re-assigned CMAKE_*_FLAGS before including each subdirectory
was confusing and ugly. This PR is the right way to do it.
This commit is purely refactoring: built binaries unchanged.
By default the flag is enabled whenever libunwind is found on the
system, with the exception of static build on OSX (for which we can't
install the throw hook #932 due to lack of support for --wrap in OSX
ld64 linker).
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.
