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.
a7266d6d wallet2+cli+rpc: eliminate redundant m_http_client from cli/rpc and delegate calls to wallet2 (stoffu)
71d18656 replace invoke_http_json("/json_rpc",...) with invoke_http_json_rpc("/json_rpc",methodname,...) to reduce boilerplate (stoffu)
4405e4fc wallet2: check_tx_key() shouldn't require hardware encryption (stoffu)
7dfa5e9e chacha: call prehashed version explicitly as generate_chacha_key_prehashed hash: add prehashed version cn_slow_hash_prehashed slow-hash: let cn_slow_hash take 4th parameter for deciding prehashed or not slow-hash: add support for prehashed version for the other 3 platforms (stoffu)
b2d23b18 crypto: revert odd namespace changes made in #3303 (stoffu)
8705beaf keypair::generate: always require hw::device to avoid possible mistake (stoffu)
27a196b1 device: untangle cyclic depenency (stoffu)
c9b38b47 device: made function prototypes consistent with pre-#3303 codebase (stoffu)
hash: add prehashed version cn_slow_hash_prehashed
slow-hash: let cn_slow_hash take 4th parameter for deciding prehashed or not
slow-hash: add support for prehashed version for the other 3 platforms
When #3303 was merged, a cyclic dependency chain was generated:
libdevice <- libcncrypto <- libringct <- libdevice
This was because libdevice needs access to a set of basic crypto operations
implemented in libringct such as scalarmultBase(), while libringct also needs
access to abstracted crypto operations implemented in libdevice such as
ecdhEncode(). To untangle this cyclic dependency chain, this patch splits libringct
into libringct_basic and libringct, where the basic crypto ops previously in
libringct are moved into libringct_basic. The cyclic dependency is now resolved
thanks to this separation:
libcncrypto <- libringct_basic <- libdevice <- libcryptonote_basic <- libringct
This eliminates the need for crypto_device.cpp and rctOps_device.cpp.
Also, many abstracted interfaces of hw::device such as encrypt_payment_id() and
get_subaddress_secret_key() were previously implemented in libcryptonote_basic
(cryptonote_format_utils.cpp) and were then called from hw::core::device_default,
which is odd because libdevice is supposed to be independent of libcryptonote_basic.
Therefore, those functions were moved to device_default.cpp.
Riccardo Spagni