monzero-core.git/src/wallet/api/wallet.cpp, branch v0.10.0Monzero core node, command-line wallet, consensus code, and release tooling.
https://code.monzero.org/monzero-core.git/atom?h=v0.10.02016-09-18T15:37:47Zswitch wallet API from std thread/mutex to boost2016-09-18T15:37:47ZRiccardo Spagniric@spagni.net2016-09-18T15:21:44Zurn:sha1:8a274eab3feab820f38503f98a3caecb5dded4a5wallet: change priority/fee to ArticMine's recommendation2016-09-16T10:50:52Zmoneromooo-moneromoneromooo-monero@users.noreply.github.com2016-09-16T10:50:52Zurn:sha1:9c7b0cb28e015f5f7542932e0edcade748c1a67d
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.
wallet2_api: zero amounts are now allowed with rct2016-08-28T20:29:41Zmoneromooo-moneromoneromooo-monero@users.noreply.github.com2016-07-17T09:02:20Zurn:sha1:83ab3151e877882286afa071046d8b56dd495938wallet2_api: update on_money_{received,spent} prototypes for rct changes2016-08-28T20:29:40Zmoneromooo-moneromoneromooo-monero@users.noreply.github.com2016-07-17T08:58:15Zurn:sha1:096ac06521bc11c5a4f2cbdbf62ce611592aa53alibwallet_api: Wallet::amountFromString fixed2016-08-23T10:47:21ZIlya Kitaevmbg033@gmail.com2016-08-23T10:46:51Zurn:sha1:bcf7b67cd6f85cdf8bf7799aa3890a56ea58ddc8libwallet_api: helper method to return maximumAllowedAmount2016-08-23T09:35:45ZIlya Kitaevmbg033@gmail.com2016-08-23T09:35:01Zurn:sha1:32bc7b41c0193297cc3b67a1b7a941813a407679libwallet_api: do not store wallet on close if status is not ok2016-08-22T19:47:59ZIlya Kitaevmbg033@gmail.com2016-08-22T12:53:07Zurn:sha1:b1a5a937ff6177723c729f94624e282351de27bbFake outs set is now decided by the wallet2016-08-11T13:35:27Zmoneromooo-moneromoneromooo-monero@users.noreply.github.com2016-08-02T20:48:09Zurn:sha1:11dc091464a6cef41434a0bb9f8604f6151c8dc5
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.
refreshing wallet even if error happened2016-07-18T20:03:09ZIlya Kitaevmbg033@gmail.com2016-07-14T10:33:49Zurn:sha1:d7597c5961ed1e8be8a7eca8c52e491b500797c6wallet_api: async init, Wallet::connected status, log level2016-07-18T20:03:09ZIlya Kitaevmbg033@gmail.com2016-07-14T09:47:01Zurn:sha1:6d32a3d16b8bb1bf2a51a41ce9f826cf31d02352