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)
464097e5 blockchain_ancestry: allow getting ancestry of a single output (moneromooo-monero)
a6216d1a blockchain_db: allow getting output keys without commitment (moneromooo-monero)
15904610 simplewallet: remove extra colon in a few calls to input_secure_line (stoffu)
247dab73 simplewallet: avoid conversion to string in input_secure_line (stoffu)
bf9ef7ad simplewallet: factor yesno hint into input_line (stoffu)
This involved a reorg of the code, to factor and speedup some bits,
as well as using the cache for all modes, and making both modes
usable in the same run.
5ee6f037 blockchain: fix wrong hf version when popping multiple blocks (moneromooo-monero)
634d359a blockchain: use the version passed as parameter, not a new one (moneromooo-monero)
94a375d5 hardfork: remove batch transactions setup (moneromooo-monero)
Half of the patch was correct, but half was introducing another bug,
where a wallet asking for a fork that the daemon does not know about
yet would decide to use those rules.
(1) If the user denies something on the Ledger,
a proper error message is now shown.
(2) Ledger doesn't time out anymore while waiting
on user input.
(3) Lower the timeout to 2 seconds, this is enough for
normal Ledger <-> System communication.
This avoids the constant message about needed to run refresh
to enter a password.
Also mention the txpool when asking for the password if the
reason is a pool tx.
get_output_key method is commonly used when working with txs and their key images. Because the method is not const, passing blockchain object though const& or pointers to const is not possible in this context. This is especially problematic in external projects (e.g., projects in moneroexamples) that use monero C++ api to operate on the blockchain and txs.
Thus, having get_output_key method will simplify moving blockchain object around through const references and pointers to const objects.
93c59b29 perf_timer: check allowed categories before logging (moneromooo-monero)
6a507dab perf_timer: add a way to get and reset the current time (moneromooo-monero)
c1581a5b perf_timer: only log to file (moneromooo-monero)
a13eb0a1 epee: speed up string matching a bit (moneromooo-monero)
3a3858dc epee: avoid string allocation when parsing a pod from string (moneromooo-monero)
