An override for the wallet to daemon connection is provided, but not for
other SSL contexts. The intent is to prevent users from supplying a
system CA as the "user" whitelisted certificate, which is less secure
since the key is controlled by a third party.
Currently if a user specifies a ca file or fingerprint to verify peer,
the default behavior is SSL autodetect which allows for mitm downgrade
attacks. It should be investigated whether a manual override should be
allowed - the configuration is likely always invalid.
Specifying SSL certificates for peer verification does an exact match,
making it a not-so-obvious alias for the fingerprints option. This
changes the checks to OpenSSL which loads concatenated certificate(s)
from a single file and does a certificate-authority (chain of trust)
check instead. There is no drop in security - a compromised exact match
fingerprint has the same worse case failure. There is increased security
in allowing separate long-term CA key and short-term SSL server keys.
This also removes loading of the system-default CA files if a custom
CA file or certificate fingerprint is specified.
The setup-background-mining option can be used to select
background mining when a wallet loads. The user will be asked
the first time the wallet is created.
f825055d wallet_rpc_server: error out on getting the spend key from a hot wallet (moneromooo-monero)
67aa4adc wallet_rpc_server: add a set_daemon RPC (moneromooo-monero)
705acbac wallet2: init some variables to default values if loading old wallets (moneromooo-monero)
f82bc29e wallet_rpc_server: always fill out subaddr_indices in get_transfers (moneromooo-monero)
01efdc6a wallet_rpc_server: set confirmations to 0 for pending/pool txes (moneromooo-monero)
7c440915 Add get_tx_proof support, needed for new sanity check (cslashm)
98fdcb2a Add support for V11 protocol with BulletProofV2 and short amount. New scheme key destination contrfol Fix dummy decryption in debug mode (cslashm)
3a981a33 Add application version compatibility check. (cslashm)
ae6885f6 blockchain: incremental long term block weight cache (moneromooo-monero)
9b687c78 blockchain: simple cache for the long term block weights (moneromooo-monero)
The original intent of one false positive a week on average
was not met, since what we really want is not the probability
of having N blocks in T seconds, but either N blocks of fewer
in T seconds, or N blocks or more in T seconds.
Some of this could be cached since it calculates the same fairly
complex floating point values, but it seems pretty fast already.
These commands let one freeze outputs by key image, so they
do not appear in balance, nor are considered when creating
a transaction, etc
This is helpful when receiving an output from a suspected spy,
who might try to track your other outputs by seeing with what
other outputs it gets spent.
The frozen command may be used without parameters to list all
currently frozen outputs.
- import only key images generated by cold signing process
- wallet_api: trezor methods added
- wallet: button request code added
- const added to methods
- wallet2::get_tx_key_device() tries to decrypt stored tx private keys using the device.
- simplewallet supports get_tx_key and get_tx_proof on hw device using the get_tx_key feature
- live refresh enables refresh with trezor i.e. computing key images on the fly. More convenient and efficient for users.
- device: has_ki_live_refresh added
- a thread is watching whether live refresh is being computed, if not for 30 seconds, it terminates the live refresh process - switches Trezor state
- enables to perform rescan_spent / ki sync with untrusted daemon. Spent check status involves RPC calls which require trusted daemon status as it leaks information. The new call performs soft reset while preserving key images thus a sequence: refresh, ki sync / import, rescan_bc keep_ki will correctly perform spent checking without need for trusted daemon.
- useful to detect spent outputs with untrusted daemon on watch_only / multisig / hw-cold wallets after expensive key image sync.
- cli: rescan_bc keep_ki
If a thread asks to stop the miner, m_stop will be set, and
that thread will wait to join. If the main thread is exiting
at that time, it will ask the miner to stop, but the miner
will claim it's not mining and early out since m_stop is
set. This will cause the database and other things to get
shutdown. If the miner happens to find a block at that time,
it will try to call core, and crash.
Instead, lock and check whether any threads are currently
in m_threads, since they'll only be cleared once the threads
are joined. Moreover, since we lock, the second thread will
have to wait for the first one to have finished. Calling
join twice on a thread seems fine as per pthread_join(3).
It's better to just ignore them, the user does not really need
to know they're here. If the mask is wrong, they'll fail to be
used, and sweeping will fail as it tries to use it.
Reported by Josh Davis.
- return the right output data when offset is not zero
- do not consider import failed if result height is zero
(it can be 0 if unknown)
- select the right tx pubkey when using subaddresses (it's faster,
and we might select the wrong one if we got an output using one
of the additional tx keys)
- account for skipped outputs for spent/unspent balance info
"spent" is arguably wrong, since it will count spent change
multiple times as it goes through receive/spend cycles.
RPC connections now have optional tranparent SSL.
An optional private key and certificate file can be passed,
using the --{rpc,daemon}-ssl-private-key and
--{rpc,daemon}-ssl-certificate options. Those have as
argument a path to a PEM format private private key and
certificate, respectively.
If not given, a temporary self signed certificate will be used.
SSL can be enabled or disabled using --{rpc}-ssl, which
accepts autodetect (default), disabled or enabled.
Access can be restricted to particular certificates using the
--rpc-ssl-allowed-certificates, which takes a list of
paths to PEM encoded certificates. This can allow a wallet to
connect to only the daemon they think they're connected to,
by forcing SSL and listing the paths to the known good
certificates.
To generate long term certificates:
openssl genrsa -out /tmp/KEY 4096
openssl req -new -key /tmp/KEY -out /tmp/REQ
openssl x509 -req -days 999999 -sha256 -in /tmp/REQ -signkey /tmp/KEY -out /tmp/CERT
/tmp/KEY is the private key, and /tmp/CERT is the certificate,
both in PEM format. /tmp/REQ can be removed. Adjust the last
command to set expiration date, etc, as needed. It doesn't
make a whole lot of sense for monero anyway, since most servers
will run with one time temporary self signed certificates anyway.
SSL support is transparent, so all communication is done on the
existing ports, with SSL autodetection. This means you can start
using an SSL daemon now, but you should not enforce SSL yet or
nothing will talk to you.
1f5680c8 simplewallet: add help for ask-password options (moneromooo-monero)
c7c74caf simplewallet: mark confirm-missing-payment-id as obsolete (moneromooo-monero)
0de14396 tests: add a CNv4 JIT test (moneromooo-monero)
24d281c3 crypto: plug CNv4 JIT into cn_slow_hash (moneromooo-monero)
78ab59ea crypto: clear cache after generating random program (moneromooo-monero)
b9a61884 performance_tests: add tests for new Cryptonight variants (moneromooo-monero)
fff23bf7 CNv4 JIT compiler for x86-64 and tests (SChernykh)
3dde67d8 blockchain: add v10 fork heights (moneromooo-monero)
2dbc487e Add support for V10 protocol with BulletProofV2 and short amount. (cslashm)
63cc02c0 Fix dummy decryption in debug mode (cslashm)
f0e55ceb fix log namespace (cslashm)
460da140 New scheme key destination contrfol (cslashm)
Minimalistic JIT code generator for random math sequence in CryptonightR.
Usage:
- Allocate writable and executable memory
- Call v4_generate_JIT_code with "buf" pointed to memory allocated on the previous step
- Call the generated code instead of "v4_random_math(code, r)", omit the "code" parameter
The 10 minute one will never trigger for 0 blocks, as it's still
fairly likely to happen even without the actual hash rate changing
much, so we add a 20 minute window, where it will (for 0 blocks)
and a one hour window.
This curbs runaway growth while still allowing substantial
spikes in block weight
Original specification from ArticMine:
here is the scaling proposal
Define: LongTermBlockWeight
Before fork:
LongTermBlockWeight = BlockWeight
At or after fork:
LongTermBlockWeight = min(BlockWeight, 1.4*LongTermEffectiveMedianBlockWeight)
Note: To avoid possible consensus issues over rounding the LongTermBlockWeight for a given block should be calculated to the nearest byte, and stored as a integer in the block itself. The stored LongTermBlockWeight is then used for future calculations of the LongTermEffectiveMedianBlockWeight and not recalculated each time.
Define: LongTermEffectiveMedianBlockWeight
LongTermEffectiveMedianBlockWeight = max(300000, MedianOverPrevious100000Blocks(LongTermBlockWeight))
Change Definition of EffectiveMedianBlockWeight
From (current definition)
EffectiveMedianBlockWeight = max(300000, MedianOverPrevious100Blocks(BlockWeight))
To (proposed definition)
EffectiveMedianBlockWeight = min(max(300000, MedianOverPrevious100Blocks(BlockWeight)), 50*LongTermEffectiveMedianBlockWeight)
Notes:
1) There are no other changes to the existing penalty formula, median calculation, fees etc.
2) There is the requirement to store the LongTermBlockWeight of a block unencrypted in the block itself. This is to avoid possible consensus issues over rounding and also to prevent the calculations from becoming unwieldy as we move away from the fork.
3) When the EffectiveMedianBlockWeight cap is reached it is still possible to mine blocks up to 2x the EffectiveMedianBlockWeight by paying the corresponding penalty.
Note: the long term block weight is stored in the database, but not in the actual block itself,
since it requires recalculating anyway for verification.
When all our outgoing peer slots are filled, we cycle one peer at
a time looking for syncing peers until we have at least two such
peers. This brings two advantages:
- Peers without incoming connections will find more syncing peers
that before, thereby strengthening network decentralization
- Peers will have more resistance to isolation attacks, as they
are more likely to find a "good" peer than they were before
NetBSD emits:
warning: Warning: reference to the libc supplied alloca(3); this most likely will not work. Please use the compiler provided version of alloca(3), by supplying the appropriate compiler flags (e.g. not -std=c89).
and man 3 alloca says:
Normally, gcc(1) translates calls to alloca() with inlined code. This is not done when either the -ansi, -std=c89, -std=c99, or the
-std=c11 option is given and the header <alloca.h> is not included. Otherwise, (without an -ansi or -std=c* option) the glibc version of
<stdlib.h> includes <alloca.h> and that contains the lines:
#ifdef __GNUC__
#define alloca(size) __builtin_alloca (size)
#endif
It looks like alloca is a bad idea in modern C/C++, so we use
VLAs for C and std::vector for C++.
Building with docker is arguably easier and more familiar to most people
than either kvm, or lxc.
This commit also relaxes the back compat requirement a bit. 32 bit linux
now uses glibc version 2.0. Also, the docker shell could not handle gcc arguments
containing spaces, so the explicit '-DFELT_TYPE' declaration was dropped.
Lastly, this removes some packages from the osx descriptor.
```
Undefined symbols for architecture x86_64:
"common_category()", referenced from:
make_error_code(common_error) in parse.cpp.o
make_error_code(common_error) in tor_address.cpp.o
"boost::system::detail::system_category_ncx()", referenced from:
boost::system::system_category() in parse.cpp.o
boost::system::system_category() in socks.cpp.o
boost::system::system_category() in libepee.a(net_utils_base.cpp.o)
"boost::system::detail::generic_category_ncx()", referenced from:
boost::system::generic_category() in parse.cpp.o
boost::system::generic_category() in socks.cpp.o
boost::system::generic_category() in tor_address.cpp.o
boost::system::generic_category() in libepee.a(string_tools.cpp.o)
boost::system::generic_category() in libepee.a(net_utils_base.cpp.o)
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make[3]: *** [src/net/libnet.dylib] Error 1
make[2]: *** [src/net/CMakeFiles/net.dir/all] Error 2
```
The change made for v2 broke v1, and we have no way to know which
version we're serializing here. However, since we don't actually
care about space savings in this case, we continue serialiazing
both mask and amount.
RPC connections now have optional tranparent SSL.
An optional private key and certificate file can be passed,
using the --{rpc,daemon}-ssl-private-key and
--{rpc,daemon}-ssl-certificate options. Those have as
argument a path to a PEM format private private key and
certificate, respectively.
If not given, a temporary self signed certificate will be used.
SSL can be enabled or disabled using --{rpc}-ssl, which
accepts autodetect (default), disabled or enabled.
Access can be restricted to particular certificates using the
--rpc-ssl-allowed-certificates, which takes a list of
paths to PEM encoded certificates. This can allow a wallet to
connect to only the daemon they think they're connected to,
by forcing SSL and listing the paths to the known good
certificates.
To generate long term certificates:
openssl genrsa -out /tmp/KEY 4096
openssl req -new -key /tmp/KEY -out /tmp/REQ
openssl x509 -req -days 999999 -sha256 -in /tmp/REQ -signkey /tmp/KEY -out /tmp/CERT
/tmp/KEY is the private key, and /tmp/CERT is the certificate,
both in PEM format. /tmp/REQ can be removed. Adjust the last
command to set expiration date, etc, as needed. It doesn't
make a whole lot of sense for monero anyway, since most servers
will run with one time temporary self signed certificates anyway.
SSL support is transparent, so all communication is done on the
existing ports, with SSL autodetection. This means you can start
using an SSL daemon now, but you should not enforce SSL yet or
nothing will talk to you.
According to [1], the ios_base::streampos member type is deprecated, and
removed in C++17. This type was an alias for pos_type, which this commit
uses instead.
[1]: https://en.cppreference.com/w/cpp/io/ios_base
- Support for ".onion" in --add-exclusive-node and --add-peer
- Add --anonymizing-proxy for outbound Tor connections
- Add --anonymous-inbounds for inbound Tor connections
- Support for sharing ".onion" addresses over Tor connections
- Support for broadcasting transactions received over RPC exclusively
over Tor (else broadcast over public IP when Tor not enabled).
23813c71 blockchain: add --reorg-notify (moneromooo-monero)
f6db59b0 notify: handle arbitrary tags (moneromooo-monero)
ff959216 notify: warn if the spec contains one of '"\ (moneromooo-monero)
13852678 common: set MONERO_DEFAULT_LOG_CATEGORY for notify and spawn (moneromooo-monero)
This will trigger if a reorg is seen. This may be used to do things
like stop automated withdrawals on large reorgs.
%s is replaced by the height at the split point
%h is replaced by the height of the new chain
%n is replaced by the number of new blocks after the reorg
b6534c40 ringct: remove unused senderPk from ecdhTuple (moneromooo-monero)
7d375981 ringct: the commitment mask is now deterministic (moneromooo-monero)
99d946e6 ringct: encode 8 byte amount, saving 24 bytes per output (moneromooo-monero)
cdc3ccec ringct: save 3 bytes on bulletproof size (moneromooo-monero)
f931e16c add a bulletproof version, new bulletproof type, and rct config (moneromooo-monero)
The blockchain prunes seven eighths of prunable tx data.
This saves about two thirds of the blockchain size, while
keeping the node useful as a sync source for an eighth
of the blockchain.
No other data is currently pruned.
There are three ways to prune a blockchain:
- run monerod with --prune-blockchain
- run "prune_blockchain" in the monerod console
- run the monero-blockchain-prune utility
The first two will prune in place. Due to how LMDB works, this
will not reduce the blockchain size on disk. Instead, it will
mark parts of the file as free, so that future data will use
that free space, causing the file to not grow until free space
grows scarce.
The third way will create a second database, a pruned copy of
the original one. Since this is a new file, this one will be
smaller than the original one.
Once the database is pruned, it will stay pruned as it syncs.
That is, there is no need to use --prune-blockchain again, etc.
c6d38718 core: include a dummy encrypted payment id when no payment is used (moneromooo-monero)
b7441c4a core, wallet: remember original text version of destination address (moneromooo-monero)
a9b1c04a crptonote_core: do not error out sending unparsable extra field (moneromooo-monero)
