Takes about 10 ms, which takes pretty much all of the get_info
RPC, which is called pretty often from wallets.
Also add a new lock so we don't need to lock the blockchain lock,
which will avoid blocking for a long time when calling the getinfo
RPC while syncing. Users of get_difficulty_for_next_block who need
the lock will have locked it already.
b86f1e5d Add command line option allowing to restrict the default sub-address lookahead in order to avoid so looooong time of set-up when creating a HW based wallet. (stoffu)
eac3a11e wallet: more user friendly print_ring (moneromooo-monero)
79853514 wallet2_api: add key reuse mitigations API (moneromooo-monero)
b057a21d wallet2_api: add ring api (moneromooo-monero)
d32ef7b0 ringdb: factor ring addition code (moneromooo-monero)
a7da8208 wallet2_api: add blackball api (moneromooo-monero)
2ab66ff1 liblmdb: install lmdb library for wallet2_api usage (stoffu)
504428ab ringdb: use the genesis block as a db name (moneromooo-monero)
b09e5181 wallet: add a set_ring command (moneromooo-monero)
0590f62a new blockchain_usage tool, reports on output usage (moneromooo-monero)
db10dd6d wallet: make ringdb an object with database state (moneromooo-monero)
df6fad4c blockchain_utilities: new blockchain_blackball tool (moneromooo-monero)
d29ea045 wallet: add an output blackball list to avoid using those in rings (moneromooo-monero)
18eaf194 wallet: key reuse mitigation options (moneromooo-monero)
5f146873 wallet: add shared ring database (moneromooo-monero)
41f727ce add RPC to get a histogram of outputs of a given amount (moneromooo-monero)
This will avoid careless forkers polluting the shared database
even if they make their own chain. They'll then automatically
start using another subdb, and any key-reusing fork of those
forks will reuse their subdbs.
It scans for known spent outputs and stores their public keys
in a database which can then be read by the wallet, which can
then avoid using those as fake outs in new transactions.
Usage: monero-blockchain-blackball db1 db2...
This uses the shared database in ~/.shared-ringdb
If a pre-fork output is spent on both Monero and attack chain,
any post-fork output can be deduced to be a fake output, thereby
decreasing the effective ring size.
The segregate-per-fork-outputs option, on by default, allows
selecting only pre-fork outputs in this case, so that the same
ring can be used when spending it on the other side, which does
not decrease the effective ring size.
This is intended to be SET when intending to spend Monero on the
attack fork, and to be UNSET if not intending to spend Monero
on the attack fork (since it leaks the fact that the output being
spent is pre-fork).
If the user is not certain yet whether they will spend pre-fork
outputs on a key reusing fork, the key-reuse-mitigation2 option
should be SET instead.
If you use this option and intend to spend Monero on both forks,
then spend real Monero first.
This maps key images to rings, so that different forks can reuse
the rings by key image. This avoids revealing the real inputs like
would happen if two forks spent the same outputs with different
rings. This database is meant to be shared with all Monero forks
which don't bother making a new chain, putting users' privacy at
risk in the process. It is placed in a shared data directory by
default ($HOME/.shared-ringdb on UNIX like systems). You may
use --shared-ringdb-dir to override this location, and should
then do so for all Monero forks for them to share the database.
