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 9af9e4223b58bbb65a3519af2c2bfc273cbd23d6 fixed some formatting commit c7920e1cf88ff46eb9294101344d9a567f22e2da Merge: 97eb28b 1da1c68 fix#864 fix using boolean commit 97eb28ba5dd49ddde8c8785f39b24d955e5de31c Fix#864 boolean value used to verify on new wallet commit 1da1c68bd3a9a373c70482b6e6e95251096149f1 fix#864 changed to boolean to prompt for verify commit 5bee96652434762d2c91ce31a1b1c9f169446ddc fix 864; made variable names easier for understanding branching. commit 45715960d30293f781b2ff9e5e647c2ec893f4a3 fix#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)
e890f51 Build: take out tests in Travis CI (anonimal)
198e408 Build: add vanilla clang to Travis CI (anonimal)
659bee6 Build: add make release-test to Travis CI (anonimal)
33b5ebd cmake: do not pass -O2 in debug build on ARM (redfish)
35dc40a cmake: libatomic only needed for 32-bit Clang builds (redfish)
042db0b cmake: cleanup logic that sets flags per target/subdir (redfish)
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).
Riccardo Spagni
anonimal
Jacob Torrey
redfish
moneromooo-monero
Howard Chu
luigi1111