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.
91d97dd4 fuzz_tests: set small subaddress lookahead for speed (moneromooo-monero)
5f85cc7e wallet2: guard against overflowing of subaddress indices (moneromooo-monero)
moneromooo-monero