1542d5d9 cryptonote_protocol: drop peers we can't download from when syncing (moneromooo-monero)
ff42af87 p2p: add a few missing connection close calls (moneromooo-monero)
5157060 Add debug targets to depends Makefile (TheCharlatan)
8475cbb Remove clutter in depends installed packages (TheCharlatan)
48c2659 Add ncurses package for linux and darwin readline (TheCharlatan)
Any peer that's behind us while syncing is useless to us (though
not to them). This ensures that we don't get our peer slots filled
with peers that we can't use. Once we've synced, we can connect
to them and they can then sync off us if they want.
The macos binaries in release v0.14.1.0 were compiled with the buggy
hidapi-0.8.0-rc1 version. This resulted in users not being able to use
their Ledger with the latest cli wallet. After the patch depends now
fetches the source from the libusb hidapi repository that has taken over
maintenance of hidapi.
To speedup the depends cached builds, remove some some clutter from the package
files. This mainly incldues removing all the shared libraries and .la
linker files. It also gives stronger guarantees that monero only links
the static libs without any external rvalues.
542cab02 rpc: restrict the recent cutoff size in restricted RPC mode (moneromooo-monero)
434e617a ensure no NULL is passed to memcpy (moneromooo-monero)
279f1f2c abstract_tcp_server2: improve DoS resistance (moneromooo-monero)
756773e5 serialization: check stream good flag at the end (moneromooo-monero)
e3f714aa tree-hash: allocate variable memory on heap, not stack (moneromooo-monero)
67baa3a6 cryptonote: throw on tx hash calculation error (moneromooo-monero)
d6bb9ecc serialization: fail on read_varint error (moneromooo-monero)
19490e44 cryptonote_protocol: fix another potential P2P DoS (moneromooo-monero)
fa4aa47e cryptonote_protocol: expand basic DoS protection (moneromooo-monero)
3c953d53 cryptonote_protocol_handler: prevent potential DoS (anonimal)
b873b69d epee: basic sanity check on allocation size from untrusted source (moneromooo-monero)
Essentially, one can send such a large amount of IDs that core exhausts
all free memory. This issue can theoretically be exploited using very
large CN blockchains, such as Monero.
This is a partial fix. Thanks and credit given to CryptoNote author
'cryptozoidberg' for collaboration and the fix. Also thanks to
'moneromooo'. Referencing HackerOne report #506595.
a663ccba blockchain: do not try to pop blocks down to the genesis block (moneromooo-monero)
8f2a99d8 core: do not commit half constructed batch db txn (moneromooo-monero)
4456a4b9 Fix allow any cert mode in wallet rpc when configured over rpc (Lee Clagett)
fafc5c36 Add ssl_options support to monerod's rpc mode. (Lee Clagett)
ce73cc3a Fix configuration bug; wallet2 --daemon-ssl-allow-any-cert now works. (Lee Clagett)
When the wallet auto refreshes after mining the last two blocks
but before popping them, it will then try to use outputs which
are not unlocked yet. This is really a wallet problem, which
will be fixed later.
- This addresses https://www.openssl.org/news/secadv/20190226.txt (CVE: 2019-1559) which impacted all versions of openssl-1.0.
Note that this does not address CVE-2019-1543 (https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-1543), which impacts all versions of openssl 1.1 through 1.1.0j and 1.1.1b.
The above (1.1) is patched in openssl, where it was marked as low severity. Similar issues possibly present in monero, should be looked into w.r.t. CVE-2019-1543.
3f612cda Changed odd bullet point to low level header (Rohaq)
af9bc4ec Used subeaders to avoid slightly wonky looking formatting (Rohaq)
1873af35 Made code block usage consistent across all .md files (Rohaq)
68103075 Updated Copyright notice (Rohaq)
39bd157f Added Table of Contents to main README.md (Rohaq)
add two RSA based ciphers for Windows/depends compatibility
also enforce server cipher ordering
also set ECDH to auto because vtnerd says it is good :)
When built with the depends system, openssl does not include any
cipher on the current whitelist, so add this one, which fixes the
problem, and does seem sensible.
98fb98f9 wallet_rpc_server: adding missing return on error in set_daemon (moneromooo-monero)
9074c0d8 wallet_rpc_server: return false on error in set_log_categories (moneromooo-monero)
968848a7 wallet_rpc_server: fix crash in validate_address if no wallet is loaded (moneromooo-monero)
If we have fewer outputs available on the chain than what we
require, but the output we're spending already has a ring,
it would loop picking outputs randomly, but never find enough.
Also tune logs for better debugging this kind of thing.
- Trezor type detection refactored, T1 disabled (was enabled before which was a bug)
- Sort connected devices by env TREZOR_PATH
- Compatibility with Trezor ecosystem using TREZOR_PATH env var
- Enables to pick particular Trezor to use in GUI as we don't have the multi-device selection yet
- Dump all detected devices to log for better debugging / troubleshooting
aba2b2e7 functional_tests: reset blockchain on test start (moneromooo-monero)
375fde94 hardfork: fix off by one updating fork index after popping (moneromooo-monero)
This can be used for fingerprinting and working out the
network topology.
Instead of sending the first N (which are sorted by last
seen time), we sent a random subset of the first N+N/5,
which ensures reasonably recent peers are used, while
preventing repeated calls from deducing new entries are
peers the target node just connected to.
The list is also randomly shuffled so the original set of
timestamps cannot be approximated.
In the case where previously a second unneeded output would be
added to a transaction. This should help *some* of the cases
where outputs are slowly being consolidated, leading to the
whole balance being locked when sending monero.
It can allocate a lot when getting a lot of connections
(in particular, the stress test on windows apparently pushes
that memory to actual use, rather than just allocated)
Boost got upgraded to 1.70.0 in MSYS2. As a result, cmake (v3.13.4 as of this commit) can not configure boost properly, and cmake configuration fails as a result. This is a workaround as per https://gitlab.kitware.com/cmake/cmake/issues/18865
d009f6dd rpc: fix get_block_hashes.bin from wallet on pruned blockchain (moneromooo-monero)
bb0ef5b1 blockchain: lock the blockchain while pruning (moneromooo-monero)
b3648232 daemon: fix ratio not being floating point (moneromooo-monero)
e1b097b9 core_rpc_server: remove dummy assigning int to bool (moneromooo-monero)
e9fac29a unit_tests/long_term_block_weight: some tweaks that seem to make more sense (stoffu)
467f4c7e tests/block_weight: use integer division when computing median (stoffu)
815d08dc tests/block_weight: remove unused MULTIPLIER_SMALL (stoffu)
661f1fb8 blockchain: remove unused calc of short_term_constraint (stoffu)
The db txn in add_block ending caused the entire overarching
batch txn to stop.
Also add a new guard class so a db txn can be stopped in the
face of exceptions.
Also use a read only db txn in init when the db itself is
read only, and do not save the max tx size in that case.
When closing connections due to exiting, the IO service is
already gone, so the data exchange needed for a gracious SSL
shutdown cannot happen. We just close the socket in that case.
Loading the same wallet as the currently loaded one would autosave
the current state after loading it, leading to some kind of rollback
effect. We now save before loading to avoid this. If loading fails,
it means the current wallet will be saved (or maybe not, depending
on where the failure occurs: most of the sanity checks occur before
saving). There is a new autosave_current flag to open/restore calls
so the (enabled by default) autosave can be skipped.
0eee6cd7 block_weight: catch exceptions in main for clean exit on error (moneromooo-monero)
4b3bb829 epee: init a new ssl related variable in ctor (moneromooo-monero)
I saw one when landing on www.tribler.org, and it seemed
like a good idea to have something similar, alongside some
more general "what is monero" text.
Also throw exceptions instead of print+exit, since that makes
the error print last, below the python stack trace, where it's
much less easy to miss it.
c12b43cb wallet: add number of blocks required for the balance to fully unlock (moneromooo-monero)
3f1e9e84 wallet2: set confirmations to 0 for pool txes in proofs (moneromooo-monero)
36c037ec wallet_rpc_server: error out on getting the spend key from a hot wallet (moneromooo-monero)
cd1eaff2 wallet_rpc_server: always fill out subaddr_indices in get_transfers (moneromooo-monero)
113e4877 blockchain_stats: fix sign in formatting function (moneromooo-monero)
adaea3ea various: remove unused variables (moneromooo-monero)
631ef00e blockchain: some debug info when adding txes-from-block fails (moneromooo-monero)
2e578b82 Enabling daemon-rpc SSL now requires non-system CA verification (Lee Clagett)
d58f3682 Require manual override for user chain certificates. (Lee Clagett)
97cd1fa9 Only check top-level certificate against fingerprint list. (Lee Clagett)
7c388fb3 Call `use_certificate_chain_file` instead of `use_certificate_file` (Lee Clagett)
eca0fea4 Perform RFC 2818 hostname verification in client SSL handshakes (Lee Clagett)
0416764c Require server verification when SSL is enabled. (Lee Clagett)
96d602ac Add `verify_fail_if_no_cert` option for proper client authentication (Lee Clagett)
21eb1b07 Pass SSL arguments via one class and use shared_ptr instead of reference (Lee Clagett)
1f5ed328 Change default SSL to "enabled" if user specifies fingerprint/certificate (Lee Clagett)
f18a069f Do not require client certificate unless server has some whitelisted. (Lee Clagett)
a3b02848 Change SSL certificate file list to OpenSSL builtin load_verify_location (Lee Clagett)
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.
This allows "chain" certificates to be used with the fingerprint
whitelist option. A user can get a system-ca signature as backup while
clients explicitly whitelist the server certificate. The user specified
CA can also be combined with fingerprint whitelisting.
The former has the same behavior with single self signed certificates
while allowing the server to have separate short-term authentication
keys with long-term authorization keys.
If the verification mode is `system_ca`, clients will now do hostname
verification. Thus, only certificates from expected hostnames are
allowed when SSL is enabled. This can be overridden by forcible setting
the SSL mode to autodetect.
Clients will also send the hostname even when `system_ca` is not being
performed. This leaks possible metadata, but allows servers providing
multiple hostnames to respond with the correct certificate. One example
is cloudflare, which getmonero.org is currently using.
If SSL is "enabled" via command line without specifying a fingerprint or
certificate, the system CA list is checked for server verification and
_now_ fails the handshake if that check fails. This change was made to
remain consistent with standard SSL/TLS client behavior. This can still
be overridden by using the allow any certificate flag.
If the SSL behavior is autodetect, the system CA list is still checked
but a warning is logged if this fails. The stream is not rejected
because a re-connect will be attempted - its better to have an
unverified encrypted stream than an unverified + unencrypted stream.
Using `verify_peer` on server side requests a certificate from the
client. If no certificate is provided, the server silently accepts the
connection and rejects if the client sends an unexpected certificate.
Adding `verify_fail_if_no_cert` has no affect on client and for server
requires that the peer sends a certificate or fails the handshake. This
is the desired behavior when the user specifies a fingerprint or CA file.
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.
Currently a client must provide a certificate, even if the server is
configured to allow all certificates. This drops that requirement from
the client - unless the server is configured to use a CA file or
fingerprint(s) for verification - which is the standard behavior for SSL
servers.
The "system-wide" CA is not being used as a "fallback" to verify clients
before or after this patch.
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.
It allows one to connect to a running daemon or wallet, and use
its RPC API from python.
Usage: python -i console.py <port>
It will detect whether it's talking to a daemon or wallet and
initialize itself accordingly.
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.
- tests fixes for HF10, builder change, rct_config; fix_chain
- get_tx_key test
- proper testing after live refresh added
- live refresh synthetic test
- log available funds for easier test construction
- wallet::API tests with mocked daemon
- 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
Manually initialize the array_entry_t iterator to ensure it points
to the correct m_array, thereby preventing a potential use-after-free
situation.
Signed-off-by: Guido Vranken <guidovranken@gmail.com>
- 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).
This avoids the annoying case where the shell prints its prompt
after the last line from Monero output, causing line editing to
sometimes go wonky, for lack of a better term
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.
108c625b CryptonightR: define out i386/x86_64 specific code on other archs (moneromooo-monero)
1b8757dd slow-hash: fix build on arm (moneromooo-monero)
5057eb11 cmake: ARCH_ID fixes for cross compilation (TheCharlatan)
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)
a17da720 Print the reason why a notification spec failed to parse (moneromooo-monero)
356d8137 blockchain: include number of discarded blocks in --reorg-notify (moneromooo-monero)
4d598e3d core: add a few more block rate window sizes (moneromooo-monero)
d4fb9641 core: add --block-rate-notify (moneromooo-monero)
28b6dbf2 notify: fix tokenizing being too strict (moneromooo-monero)
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++.
Further speedups to icu compilation, it is faster to run the
pre-generated configure scripts.
Ensure that the native protobuf installation only generates the required
libraries and binaries.
Disable qt compilation when running travis on windows. Qt is used for
lrelease, the travis recipe instead usese the a local installation of
lrelease.
Remove various packages and options from the travis recipe.
Update Readline to version 8.0. The previously used url 404'd sometimes,
use the official gnu ftp server instead.
Remove unused cmake config.
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
tested on current FreeBSD 11.2-p4 , used master and release-v0.13 branchs of monero (w\o any patches)
`gmake` - success
`gmake release-static` - fail (-fPIC error, i think i need build dependencies from ports static instead install from pkg)
`gmake debug` - fail (wallet2.cpp.o - file not recognized: file format no recognized)
`gmake release-test` - success (100% passed)
- 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
cb3b4adb translations: update and sync all language files (erciccione)
dc0f618e utils: 'update-translations.sh' now removes obsolete strings (erciccione)
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 includes more fine grained configure options and skipping the
openssl and zlib dependencies when compiling qt. The zlib and libevent
packages are removed.
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.
Number matching semantics are slightly changed: since this is used
as a filter to check whether a number is signed and/or floating
point, we can speed this up further. strto* functions are called
afterwards and will error out where necessary. We now also accept
numbers like .4 which were not accepted before.
The strto* calls on a boost::string_ref will not access unallocated
memory since the parsers always stop at the first bad character,
and the original string is zero terminated.
in arbitrary time measurement units for some arbitrary test case:
match_number2: 235 -> 70
match_word2: 330 -> 108
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)
it occurred to me that someone discovering monero for the first time, through the code and actually reading the readme, would not have any indication of the design focuses of keeping monero decentralized, both in terms of the mining infrastructure and the low cost of node operation. I know the topic is sort of a ... wishy washy thing, but I tried to craft some language that gets the point across in general terms.
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)
`pacman -Syuu` can either upgrade or degrade the packages (depending upon the package lists), and should not be normally used. Instead of that, one should use `pacman -Syu` which only upgrades the packages.
6644b9b blockchain_db: remove a couple unused functions (moneromooo-monero)
ce594f5 blockchain_db: allocate known size vector only once (moneromooo-monero)
8332698 db_lmdb: inline check_open, it's trivial and called everywhere (moneromooo-monero)
5511563 db_lmdb: avoid pointless division (moneromooo-monero)
d1efe3d cryptonote: set tx hash on newly parsed txes when known (moneromooo-monero)
9cc68a2 tx_pool: add a few std::move where it can make a difference (moneromooo-monero)
While the lookups are faster, the zeroCommit calls have to be
done again when storing the new outputs in the db, which ends
up making the whole thing slower after all, and the ways this
can be cached aren't very nice code wise, so let's forget it
since the gains aren't very large anyway.
Help messages describe the commands usage. When users run the command
with wrong arguments, it usually helpfully offers the usage, too.
Unfortunately, these two usage messages were duplicated in the code and
started to get out of sync.
Fixing with constant strings.
- docker protobuf dependencies, cross-compilation
- device/trezor protobuf build fixes, try_compile
- libusb built under all platforms, used by trezor for direct connect
Depends still contained some leftovers, like the `wallet` target that
included bdb from bitcoin. This commit removes these unneeded targets,
the miniupnpc package and the berkeley db package. Reflect the changes
in the README as well.
ab783b17 easylogging++: ensure logger is initialized before main (moneromooo-monero)
9b69a0ae daemon: print monero version at startup when calling a detached daemon (moneromooo-monero)
4d71d463 mlocker: remove early page size log (moneromooo-monero)
a48f2dab blockchain_prune_known_spent_data: blackball file is now optional (moneromooo-monero)
17b45725 Outputs where all amounts are known spent can now be pruned (moneromooo-monero)
- checks if the device is in the correct usable state
- implements check for the v2.0.9 firmware which does not support payment IDs
- simple transacttion check, payment id fmt consistency
- minor fixes, refactoring, webusb session counting fix
When doing a first refresh on HW-token based wallet KI sync is required if money were received. Received money may indicate wallet was already used before the restore I.e., some transaction could have been already sent from the wallet. The spent UTXO would not be detected as spent which could lead to double spending errors on submitting a new transaction.
Thus if the wallet is HW-token based with the cold signing protocol and the first refresh detected received money the user is asked to perform the key image sync.
- adds a new option `--hw-device-deriv-path` to the simple wallet. Enables to specify wallet derivation path / wallet code (path avoided so it can be misinterpreted as a file path).
- devices can use different derivation mechanisms. Trezor uses standard SLIP-10 mechanism with fixed SLIP-44 prefix for Monero
- Trezor: when empty, the default derivation mechanism is used with 44'/128'/0'. When entered the derivation path is 44'/128'/PATH.
- Trezor: the path is always taken as elements are hardened (1<<31 bit turned on)
aee7a4e3 wallet_rpc_server: do not use RPC data if the call failed (moneromooo-monero)
1a0733e5 windows_service: fix memory leak (moneromooo-monero)
0dac3c64 unit_tests: do not rethrow a copy of an exception (moneromooo-monero)
5d9915ab cryptonote: fix get_unit for non default settings (moneromooo-monero)
d4f50cb1 remove some unused code (moneromooo-monero)
61163971 a few minor (but easy) performance tweaks (moneromooo-monero)
30023074 tests: slow_memmem now returns size_t (moneromooo-monero)
b36353e2 unit_tests: add some hex parsing test for non hex input (xiphon)
6671110c unit_tests: add a test for parse_hexstr_to_binbuff (moneromooo-monero)
f6187cd8 epee: speed up parse_hexstr_to_binbuff a little (Howard Chu)
It comes before the logger is initialized, so gets displayed
even though it should not be by default, and apparenly comes
too early for (some versions of) Android, where it crashes.
This avoids the miner erroring out trying to submit blocks
to a core that's already shut down (and avoids pegging
the CPU while we're busy shutting down).
- simple device callback object added. Device can request passphrase/PIN entry via the callback or notify user some action is required
- callback is routed to wallet2, which routes the callback to i_wallet_callback so CLI or GUI wallets can support passphrase entry for HW tokens
- wallet: device open needs wallet callback first - passphrase protected device needs wallet callback so user can enter passphrase
Only for pre rct for obvious reasons.
Note: DO NOT use a known spent list which includes outputs
which are not known spent. If the list includes any output
that's just strongly thought to be spent, but not provably
so, you risk finding yourself unable to sync past the point
where that output is spent.
I estimate only 200 MB saved on current mainnet though,
unless the new blackballing rule unearths a good amount of
large-amount-set extra spent outs.
Some of the inputs for block in a span will be from other earlier
blocks in that span. Keep track of those outputs so we don't have
to look them up again after those early blocks are added to the
blockchain.
Turns out getting the global shared_ptr hits the profile,
and passing it around still keeps it at close to ~1% CPU,
which is too much for mostly silent logging.
Leak the object instead, which is even safer for late logging.
- webusb transport based on libusb added. Provides direct access to Trezor via USB, no need for Trezor bridge.
- trezor protocol message handler improved, no recursion used. Ready for upcoming integration tests.
- libusb (for docker) bumped from v1.0.9 to v1.0.22, newer version required for webusb transport, for device enumeration.
- cmake improvements and fixes. Cmake Trezor checks are moved to a dedicated CheckTrezor.cmake file. In case of a problem Trezor is excluded from build.
- ifdefs made consistent to Ledger.
- UDP Transport enumeration disabled by default in release mode
Motivated by https://monero.stackexchange.com/questions/10483
Some exchanges appear to have customized the wallet software
in an inappropriate way, making the tx extra field partially
unreadable. PR #3716 changed the wallet behavior disallowing
such partially valid tx extra.
An example tx reported by the user is
e87c675a85f34ecac58a8846613d25062f1813e1023c552b705afad32b972c38
where the normal tx pubkey appears again with the aditional
tx pubkeys tag `04` which is inappropriate.
This prevents exceptions from showing up in various awkward
places such as dtors, since the only exception that can be
thrown is a lock failure, and nothing handles a lock failure
anyway.
03fc731b p2p: less frequent incoming connections check (moneromooo-monero)
14a5c206 p2p: tone down "no incoming connections" warning to info if in peers is 0 (moneromooo-monero)
This can go out of sync with m_core's nettype if you run in fakechain
mode since entering fakechain mode is done through code not the command
line and core_rpc_server only looks at the command line to figure out
the nettype.
5808530f blockchain: remove unused output_scan_worker parameter (moneromooo-monero)
1426209a blockchain: don't run threads if we have just one function to run (moneromooo-monero)
6f7a5fd4 db_lmdb: slight speedup getting array data from the blockchain (moneromooo-monero)
99fbe100 db_lmdb: save some string copies for readonly db keys/values (moneromooo-monero)
bf31447e tx_pool: speed up take_tx for transactions from blocks (moneromooo-monero)
4f005a77 tx_pool: remove unnecessary get_transaction_hash (moneromooo-monero)
593ef598 perf_timer: call reserve on new timer array (moneromooo-monero)
6ecc99ad core: avoid unnecessary tx/blob conversions (moneromooo-monero)
00cc1a16 unit_tests: notify test special case for the usual weirdo (moneromooo-monero)
6d3311ac libwallet_api_tests: add missing dependency on Boost Locale and ICU (stoffu)
f0459abb cmake: move Boost_LOCALE_LIBRARY out of ICU_LIBRARIES (stoffu)
The version prefix 'v' should just be set constantly.
Reflect this change in the README as well.
This should allow building commits as well, if a commit
is passed in instead of a tag.
73e504c1 rpc: adjust ring size error message now that too high is also possible (moneromooo-monero)
a5ca7f4f core: fix unmixable special case allowing ring size below 11 (moneromooo-monero)
To help protect one's privacy from traffic volume analysis
for people using Tor or I2P. This will really fly once we
relay txes on a timer rather than on demand, though.
Off by default for now since it's wasteful and doesn't bring
anything until I2P's in.
5f614ba9 simplewallet: print the number of show/all transfers (moneromooo-monero)
8d71b2b1 wallet2: only export necessary outputs and key images (moneromooo-monero)
769ae42a wallet2: faster output and key image import/export (moneromooo-monero)
Undefined symbols for architecture x86_64:
"cryptonote::core::get_output_distribution(unsigned long long, unsigned long long, unsigned long long, unsigned long long&, std::__1::vector<unsigned long long, std::__1::allocator<unsigned long long> >&, unsigned long long&) const", referenced from:
cryptonote::rpc::RpcHandler::get_output_distribution(cryptonote::core&, unsigned long long, unsigned long long, unsigned long long, bool) in rpc_handler.cpp.o
74fb3d88 multiexp: some minor speedups (moneromooo-monero)
a6d2e246 bulletproofs: only enable profiling on request (moneromooo-monero)
a110e6aa multiexp: tune which variants to use for which number of points (moneromooo-monero)
8b476722 bulletproofs: speedup prover (moneromooo-monero)
6f9ae5b6 multiexp: handle pippenger multiexps with part precalc (moneromooo-monero)
10e5a927 bulletproofs: maintain -z4, -z5, and -y0 to avoid subtractions (moneromooo-monero)
8629a42c bulletproofs: rework flow to use sarang's fast batch inversion code (moneromooo-monero)
fc9f7d9c bulletproofs: merge multiexps as per sarang's new python code (moneromooo-monero)
4061960a multiexp: pack the digits table when STRAUS_C is 4 (moneromooo-monero)
bf8e4b98 bulletproofs: some more minor speedup (moneromooo-monero)
c415df97 performance_tests: sc_check and ge_dsm_precomp (moneromooo-monero)
a281b950 bulletproofs: remove single value prover (moneromooo-monero)
484155d0 bulletproofs: some more speedup (moneromooo-monero)
a621d6c8 bulletproofs: random minor speedups (moneromooo-monero)
a49a1761 bulletproofs: shave off a lot of scalar muls from the g/h construction (moneromooo-monero)
4564a5d1 bulletproofs: speedup PROVE (moneromooo-monero)
15:43 < hahsun> Im on stagenet and I suddenly get this exception: 2018-11-04 14:42:52.416 [RPC0] ERROR wallet.wallet2 src/wallet/wallet2.cpp:2070 !m_blockchain.is_in_bounds(current_index). THROW EXCEPTION: error::out_of_hashchain_bounds_error
16:01 <+moneromooo> OK, possibly because the blckchain is always seeded with the genesis block hash...
16:02 <+moneromooo> So that case should be allowed, assuming it doesn't break the code around it.
16:05 <+moneromooo> OK if stop_height == size || (size==1 && stop_heigt ==0)
16:05 <+moneromooo> Throw if not that.
16:06 < hahsun> k
This happens for every historical tx when syncing, and the
unnecessary parsing is actually showing up on profile.
Since these are kept cached for just one block, this does
not increase memory usage after syncing.
It seems the more prudent thing to do here. It will not catch
attempts to use that value before it is initialized when using
ASAN or valgrind, but in a case where it does, it will have
smaller repercussions.
So it seems appropriate in this particular case.
Coverity 182498
Even if it is never relayed, it ensures a daemon supplying
fake outs on demand will never be asked for a set with the
real input being the only intersecting member (only a problem
with people who trust their privacy to some stranger's node,
but it seems to be a massively common thing, even in Monero)
3ffbec15 rpc: init m_rpc_version in Message ctor (moneromooo-monero)
bfa2dce1 rpc: remove unused ctors (moneromooo-monero)
7cc39845 account: init creation timestamp to 0 (moneromooo-monero)
32123789 wallet2: initialize some scalar fields in ctor where appropriate (moneromooo-monero)
4eca42b2 blockchain_db: initialize m_hardfork in ctor just in case (moneromooo-monero)
539debc4 Finish all contexts but simple_wallet, translate 23% of simple_wallet (sanecito)
ee71ba98 Add translations for Monero::PendingTransactionImpl, command_line Contexts (sanecito)
5c4fe3d4 Create Japanese file, add translations for "Monero::AddressBookImpl" and "Wallet" Contexts (sanecito)
- These functions are declared twice in slow-hash.c. Remove one of the copies.
- The declarations have the wrong return type, should be void, not int.
Function definitions here: 1e74586ee9/src/crypto/aesb.c (L151-L180)
Test plan: make release-test
0 is placeholder for whole chain, so we should compare chain
height changes rather than chain-height-or-zero. Even this isn't
totally foolproof if a blocks are popped and the same number
added again, but it is much better as it prevents the data from
slowly going out of sync.
Depends can now be compiled with `make depends target=$triple`, where
$triple is one of the supported build targets.
Adapt the Makefile for this change, remove not needed windows deps from
depends setup description.
00901e9c epee: initialize a few data members where it seems to be appropriate (moneromooo-monero)
144a6c32 abstract_tcp_server2: move m_period to subclass (moneromooo-monero)
758d7684 connection_basic: remove unused floating time start time (moneromooo-monero)
e5108a29 Catch more exceptions in dtors (moneromooo-monero)
c3b8328c daemon: do not run complex code in a signal handler (moneromooo-monero)
e736964a Remove epee header dependency on cryptonote_core (moneromooo-monero)
Windows is built with a seperate descriptor to handle additional changes
that need to be done to the end binary. Consolidate the gitian-build
script for this change.
The signature prepare tool and the gitian-builder git repo should be
checked for their content. For this purpose, checkout the gitian-builder
repo at a specific commit and take the sha256sum of the osslsigncode
tool.
This adds a build script to run gitian builds for linux.
The build script was copied from bitcoin and then adapted for monero.
Build step documentation is outlined in the README in the contrib/gitian
directory.
9acf42d3 Multisig M/N functionality core tests added (naughtyfox)
9f3963e8 Arbitrary M/N multisig schemes: * support in wallet2 * support in monero-wallet-cli * support in monero-wallet-rpc * support in wallet api * support in monero-gen-trusted-multisig * unit tests for multisig wallets creation (naughtyfox)
This removes some small amount of fingerprinting entropy.
There is no consensus rule to require this since this field
is technically free form, and a transaction is free to have
custom data in it.
2fbf38ee Fix 32bit depends builds (TheCharlatan)
17142ec9 malloc scratchpad for all supported android archs (m2049r)
6a781408 Make depends use self built clang for darwin (TheCharlatan)
69da14e1 fixes make debug compilation on OSX (Dusan Klinec)
fe125647 Fixup RENAME_DB() macro (Howard Chu)
b2972927 osx compilation fix: missing boost libs added (Dusan Klinec)
174f31bf simplewallet: don't complain about payment id on pool mined blocks (moneromooo-monero)
89288863 README: mention ASAN usage alongside valgrind (moneromooo-monero)
83debef9 wallet_rpc_server: remove verbose field in incoming_transfers query (moneromooo-monero)
a69271fa Fixed a typo (Piotr Kąkol)
92d1da28 unit_tests: fix build with GCC 5.4.0 on ubuntu (moneromooo-monero)
a21da905 Wallet: use unique_ptr for WalletImpl members (oneiric)
7a056f44 WalletAPI: multisigSignData bug fixed (naughtyfox)
43a06350 ringdb: use cursors to be a bit faster (moneromooo-monero)
7964d4f8 wallet2: handle corner case in picking fake outputs (moneromooo-monero)
6f5360b3 bump version to 0.13.0.1 (Riccardo Spagni)
cf470bf3 switch from master to rc (Riccardo Spagni)
* support in wallet2
* support in monero-wallet-cli
* support in monero-wallet-rpc
* support in wallet api
* support in monero-gen-trusted-multisig
* unit tests for multisig wallets creation
bcf3f6af fuzz_tests: catch unhandled exceptions (moneromooo-monero)
3ebd05d4 miner: restore stream flags after changing them (moneromooo-monero)
a093092e levin_protocol_handler_async: do not propagate exception through dtor (moneromooo-monero)
1eebb82b net_helper: do not propagate exceptions through dtor (moneromooo-monero)
fb6a3630 miner: do not propagate exceptions through dtor (moneromooo-monero)
2e2139ff epee: do not propagate exception through dtor (moneromooo-monero)
0749a8bd db_lmdb: do not propagate exceptions in dtor (moneromooo-monero)
1b0afeeb wallet_rpc_server: exit cleanly on unhandled exceptions (moneromooo-monero)
418a9936 unit_tests: catch unhandled exceptions (moneromooo-monero)
ea7f9543 threadpool: do not propagate exceptions through the dtor (moneromooo-monero)
6e855422 gen_multisig: nice exit on unhandled exception (moneromooo-monero)
53df2deb db_lmdb: catch error in mdb_stat calls during migration (moneromooo-monero)
e67016dd blockchain_blackball: catch failure to commit db transaction (moneromooo-monero)
661439f4 mlog: don't remove old logs if we failed to rename the current file (moneromooo-monero)
5fdcda50 easylogging++: test for NULL before dereference (moneromooo-monero)
7ece1550 performance_test: fix bad last argument calling add_arg (moneromooo-monero)
a085da32 unit_tests: add check for page size > 0 before dividing (moneromooo-monero)
d8b1ec8b unit_tests: use std::shared_ptr to shut coverity up about leaks (moneromooo-monero)
02563bf4 simplewallet: top level exception catcher to print nicer messages (moneromooo-monero)
c57a65b2 blockchain_blackball: fix shift range for 32 bit archs (moneromooo-monero)
- if [ -n "$OSX_SDK" -a ! -f contrib/depends/sdk-sources/MacOSX${OSX_SDK}.sdk.tar.gz ]; then curl --location --fail $SDK_URL/MacOSX${OSX_SDK}.sdk.tar.gz -o contrib/depends/sdk-sources/MacOSX${OSX_SDK}.sdk.tar.gz; fi
- if [ -n "$OSX_SDK" -a -f contrib/depends/sdk-sources/MacOSX${OSX_SDK}.sdk.tar.gz ]; then tar -C contrib/depends/SDKs -xf contrib/depends/sdk-sources/MacOSX${OSX_SDK}.sdk.tar.gz; fi
- if [[ $HOST = *-mingw32 ]]; then $DOCKER_EXEC bash -c "update-alternatives --set $HOST-g++ \$(which $HOST-g++-posix)"; fi
- if [[ $HOST = *-mingw32 ]]; then $DOCKER_EXEC bash -c "update-alternatives --set $HOST-gcc \$(which $HOST-gcc-posix)"; fi
- if [ -z "$NO_DEPENDS" ]; then $DOCKER_EXEC bash -c "CONFIG_SHELL= make $MAKEJOBS -C contrib/depends HOST=$HOST $DEP_OPTS"; fi
message(STATUS"Submodule '${relative_path}' is up-to-date")
else()
message(FATAL_ERROR"Submodule '${relative_path}' is not up-to-date. Please update with\ngit submodule update --init --force ${relative_path}\nor run cmake with -DMANUAL_SUBMODULES=1")
message(FATAL_ERROR"Boost ${Boost_VERSION} (older than 1.62) is too old to link with OpenSSL ${OPENSSL_VERSION} (1.1 or newer) found at ${OPENSSL_INCLUDE_DIR} and ${OPENSSL_LIBRARIES}. "
"Update Boost or install OpenSSL 1.0 and set path to it when running cmake: "
@@ -19,7 +19,8 @@ posted to #monero-dev on irc.freenode.net).
Patches should be self contained. A good rule of thumb is to have
one patch per separate issue, feature, or logical change. Also, no
other changes, such as random whitespace changes or reindentation.
other changes, such as random whitespace changes, reindentation,
or fixing typoes, spelling, or wording, unless user visible.
Following the code style of the particular chunk of code you're
modifying is encouraged. Proper squashing should be done (eg, if
you're making a buggy patch, then a later patch to fix the bug,
@@ -87,26 +88,26 @@ C4 is meant to provide a reusable optimal collaboration model for open source so
### Preliminaries
- The project SHALL use the git distributed revision control system.
- The project SHALL be hosted on github.com or equivalent, herein called the "Platform".
- The project SHALL use the Platform issue tracker.
- The project MUST use the git distributed revision control system.
- The project MUST be hosted on github.com or equivalent, herein called the "Platform".
- The project MUST use the Platform issue tracker.
- Non-GitHub example:
- "Platform" could be a vanilla git repo and Trac hosted on the same machine/network.
- The Platform issue tracker would be Trac.
- The project SHOULD have clearly documented guidelines for code style.
- A "Contributor" is a person who wishes to provide a patch, being a set of commits that solve some clearly identified problem.
- A "Maintainer" is a person who merges patches to the project. Maintainers are not developers; their job is to enforce process.
- Contributors SHALL NOT have commit access to the repository unless they are also Maintainers.
- Maintainers SHALL have commit access to the repository.
- Everyone, without distinction or discrimination, SHALL have an equal right to become a Contributor under the terms of this contract.
- Contributors MUST NOT have commit access to the repository unless they are also Maintainers.
- Maintainers MUST have commit access to the repository.
- Everyone, without distinction or discrimination, MUST have an equal right to become a Contributor under the terms of this contract.
### Licensing and ownership
- The project SHALL use a share-alike license, such as BSD-3, the GPLv3 or a variant thereof (LGPL, AGPL), or the MPLv2.
- All contributions to the project source code ("patches") SHALL use the same license as the project.
- All patches are owned by their authors. There SHALL NOT be any copyright assignment process.
- The copyrights in the project SHALL be owned collectively by all its Contributors.
- Each Contributor SHALL be responsible for identifying themselves in the project Contributor list.
- The project MUST use a share-alike license, such as BSD-3, the GPLv3 or a variant thereof (LGPL, AGPL), or the MPLv2.
- All contributions to the project source code ("patches") MUST use the same license as the project.
- All patches are owned by their authors. There MUST NOT be any copyright assignment process.
- The copyrights in the project MUST be owned collectively by all its Contributors.
- Each Contributor MUST be responsible for identifying themselves in the project Contributor list.
### Patch requirements
@@ -115,27 +116,27 @@ C4 is meant to provide a reusable optimal collaboration model for open source so
- A patch SHOULD be a minimal and accurate answer to exactly one identified and agreed problem.
- A patch MUST adhere to the code style guidelines of the project if these are defined.
- A patch MUST adhere to the "Evolution of Public Contracts" guidelines defined below.
- A patch SHALL NOT include non-trivial code from other projects unless the Contributor is the original author of that code.
- A patch MUST NOT include non-trivial code from other projects unless the Contributor is the original author of that code.
- A patch MUST compile cleanly and pass project self-tests on at least the principle target platform.
- A patch commit message SHOULD consist of a single short (less than 50 character) line summarizing the change, optionally followed by a blank line and then a more thorough description.
- A "Correct Patch" is one that satisfies the above requirements.
### Development process
- Change on the project SHALL be governed by the pattern of accurately identifying problems and applying minimal, accurate solutions to these problems.
- Change on the project MUST be governed by the pattern of accurately identifying problems and applying minimal, accurate solutions to these problems.
- To request changes, a user SHOULD log an issue on the project Platform issue tracker.
- The user or Contributor SHOULD write the issue by describing the problem they face or observe.
- The user or Contributor SHOULD seek consensus on the accuracy of their observation, and the value of solving the problem.
- Users SHALL NOT log feature requests, ideas, or suggestions unrelated to Monero code or Monero's dependency code or Monero's potential/future dependency code or research which successfully implements Monero.
- Users SHALL NOT log any solutions to problems (verifiable or hypothetical) of which are not explicitly documented and/or not provable and/or cannot be reasonably proven.
- Thus, the release history of the project SHALL be a list of meaningful issues logged and solved.
- To work on an issue, a Contributor SHALL fork the project repository and then work on their forked repository.
- To submit a patch, a Contributor SHALL create a Platform pull request back to the project.
- A Contributor SHALL NOT commit changes directly to the project.
- Users MUST NOT log feature requests, ideas, or suggestions unrelated to Monero code or Monero's dependency code or Monero's potential/future dependency code or research which successfully implements Monero.
- Users MUST NOT log any solutions to problems (verifiable or hypothetical) of which are not explicitly documented and/or not provable and/or cannot be reasonably proven.
- Thus, the release history of the project MUST be a list of meaningful issues logged and solved.
- To work on an issue, a Contributor MUST fork the project repository and then work on their forked repository.
- To submit a patch, a Contributor MUST create a Platform pull request back to the project.
- A Contributor MUST NOT commit changes directly to the project.
- To discuss a patch, people MAY comment on the Platform pull request, on the commit, or elsewhere.
- To accept or reject a patch, a Maintainer SHALL use the Platform interface.
- To accept or reject a patch, a Maintainer MUST use the Platform interface.
- Maintainers SHOULD NOT merge their own patches except in exceptional cases, such as non-responsiveness from other Maintainers for an extended period (more than 30 days) or unless urgent as defined by the Monero Maintainers Team.
- Maintainers SHALL NOT make value judgments on correct patches unless the Maintainer (as may happen in rare circumstances) is a core code developer.
- Maintainers MUST NOT make value judgments on correct patches unless the Maintainer (as may happen in rare circumstances) is a core code developer.
- Maintainers MUST NOT merge pull requests in less than 168 hours (1 week) unless deemed urgent by at least 2 people from the Monero Maintainer Team.
- The Contributor MAY tag an issue as "Ready" after making a pull request for the issue.
- The user who created an issue SHOULD close the issue after checking the patch is successful.
@@ -145,27 +146,27 @@ C4 is meant to provide a reusable optimal collaboration model for open source so
### Creating stable releases
- The project SHALL have one branch ("master") that always holds the latest in-progress version and SHOULD always build.
- The project SHALL NOT use topic branches for any reason. Personal forks MAY use topic branches.
- To make a stable release someone SHALL fork the repository by copying it and thus become maintainer of this repository.
- The project MUST have one branch ("master") that always holds the latest in-progress version and SHOULD always build.
- The project MUST NOT use topic branches for any reason. Personal forks MAY use topic branches.
- To make a stable release someone MUST fork the repository by copying it and thus become maintainer of this repository.
- Forking a project for stabilization MAY be done unilaterally and without agreement of project maintainers.
- A patch to a stabilization project declared "stable" SHALL be accompanied by a reproducible test case.
- A patch to a stabilization project declared "stable" MUST be accompanied by a reproducible test case.
### Evolution of public contracts
- All Public Contracts (APIs or protocols) SHALL be documented.
- All Public Contracts (APIs or protocols) MUST be documented.
- All Public Contracts SHOULD have space for extensibility and experimentation.
- A patch that modifies a stable Public Contract SHOULD not break existing applications unless there is overriding consensus on the value of doing this.
- A patch that introduces new features to a Public Contract SHOULD do so using new names.
- Old names SHOULD be deprecated in a systematic fashion by marking new names as "experimental" until they are stable, then marking the old names as "deprecated".
- When sufficient time has passed, old deprecated names SHOULD be marked "legacy" and eventually removed.
- Old names SHALL NOT be reused by new features.
- Old names MUST NOT be reused by new features.
- When old names are removed, their implementations MUST provoke an exception (assertion) if used by applications.
### Project administration
- The project founders SHALL act as Administrators to manage the set of project Maintainers.
- The Administrators SHALL ensure their own succession over time by promoting the most effective Maintainers.
- A new Contributor who makes a correct patch SHALL be invited to become a Maintainer.
- The project founders MUST act as Administrators to manage the set of project Maintainers.
- The Administrators MUST ensure their own succession over time by promoting the most effective Maintainers.
- A new Contributor who makes a correct patch MUST be invited to become a Maintainer.
- Administrators MAY remove Maintainers who are inactive for an extended period of time, or who repeatedly fail to apply this process accurately.
- Administrators SHOULD block or ban "bad actors" who cause stress and pain to others in the project. This should be done after public discussion, with a chance for all parties to speak. A bad actor is someone who repeatedly ignores the rules and culture of the project, who is needlessly argumentative or hostile, or who is offensive, and who is unable to self-correct their behavior when asked to do so by others.
@@ -29,3 +29,13 @@ OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
Parts of the project are originally copyright (c) 2012-2013 The Cryptonote
developers
Parts of the project are originally copyright (c) 2014 The Boolberry
developers, distributed under the MIT licence:
Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:
The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
The Monero command line tools can be translated in various languages. If you wish to contribute and need help/support, contact the [Monero Localization Workgroup on Taiga](https://taiga.getmonero.org/project/erciccione-monero-localization/) or come chat on `#monero-translations` (Freenode/IRC, riot/matrix, MatterMost)
In order to use the same translation workflow as the [Monero Core GUI](https://github.com/monero-project/monero-core), they use Qt Linguist translation files. However, to avoid the dependencies on Qt this normally implies, they use a custom loader to read those files at runtime.
In order to use the same translation workflow as the [Monero Core GUI](https://github.com/monero-project/monero-gui), they use Qt Linguist translation files. However, to avoid the dependencies on Qt this normally implies, they use a custom loader to read those files at runtime.
### Tools for translators
@@ -15,23 +15,33 @@ You do not need anything from Qt in order to use the final translations.
- We are also available via [HackerOne](https://hackerone.com/monero)
## Research
The [Monero Research Lab](https://src.getmonero.org/resources/research-lab/) is an open forum where the community coordinates research into Monero cryptography, protocols, fungibility, analysis, and more. We welcome collaboration and contributions from outside researchers! Because not all Lab work and publications are distributed as traditional preprints or articles, they may be easy to miss if you are conducting literature reviews for your own Monero research. You are encouraged to get in touch with our researchers if you have questions, wish to collaborate, or would like guidance to help avoid unnecessarily duplicating earlier or known work.
Our researchers are available on IRC in [#monero-research-lab on Freenode](https://webchat.freenode.net/?randomnick=1&channels=%23monero-research-lab&prompt=1&uio=d4) or by email:
- Sarang Noether, Ph.D.: [sarang@getmonero.org](mailto:sarang@getmonero.org) or [sarang.noether@protonmail.com](mailto:sarang.noether@protonmail.com); [research repository](https://github.com/SarangNoether/research-lab)
- You can subscribe to an [announcement listserv](https://lists.getmonero.org) to get critical announcements from the Monero core team. The announcement list can be very helpful for knowing when software updates are needed.
## Translations
The CLI wallet is available in different languages. If you want to help translate it, see our self-hosted localization platform, Pootle, on [translate.getmonero.org](https://translate.getmonero.org/projects/CLI/). Every translation *must* be uploaded on the platform, pull requests directly editing the code in this repository will be closed. If you need help with Pootle, you can find a guide with screenshots [here](https://github.com/monero-ecosystem/monero-translations/blob/master/pootle.md).
If you need help/support/info about translations, contact the localization workgroup. You can find the complete list of contacts on the repository of the workgroup: [monero-translations](https://github.com/monero-ecosystem/monero-translations#contacts).
## Build
### IMPORTANT
### IMPORTANT
These builds are of the master branch, which is used for active development and can be either unstable or incompatible with release software. Please compile release branches.
@@ -32,9 +67,9 @@ These builds are of the master branch, which is used for active development and
| Windows (MSYS2/MinGW) | i686 | [](https://build.getmonero.org/builders/monero-static-win32)
@@ -58,6 +93,8 @@ Monero is a private, secure, untraceable, decentralised digital currency. You ar
**Untraceability:** By taking advantage of ring signatures, a special property of a certain type of cryptography, Monero is able to ensure that transactions are not only untraceable, but have an optional measure of ambiguity that ensures that transactions cannot easily be tied back to an individual user or computer.
**Decentralization:** The utility of monero depends on its decentralised peer-to-peer consensus network - anyone should be able to run the monero software, validate the integrity of the blockchain, and participate in all aspects of the monero network using consumer-grade commodity hardware. Decentralization of the monero network is maintained by software development that minimizes the costs of running the monero software and inhibits the proliferation of specialized, non-commodity hardware.
## About this project
This is the core implementation of Monero. It is open source and completely free to use without restrictions, except for those specified in the license agreement below. There are no restrictions on anyone creating an alternative implementation of Monero that uses the protocol and network in a compatible manner.
@@ -97,10 +134,10 @@ If you want to help out, see [CONTRIBUTING](CONTRIBUTING.md) for a set of guidel
## Scheduled software upgrades
Monero uses a fixed-schedule software upgrade (hard fork) mechanism to implement new features. This means that users of Monero (end users and service providers) should run current versions and upgrade their software on a regular schedule. Software upgrades occur during the months of April and October. The required software for these upgrades will be available prior to the scheduled date. Please check the repository prior to this date for the proper Monero software version. Below is the historical schedule and the projected schedule for the next upgrade.
Dates are provided in the format YYYY-MM-DD.
Dates are provided in the format YYYY-MM-DD.
| Software upgrade block height | Date | Fork version | Minimum Monero version | Recommended Monero version | Details |
| Software upgrade block height | Date | Fork version | Minimum Monero version | Recommended Monero version | Details |
| 1788000 | 2019-03-09 | v10 | v0.14.0.0 | v0.14.1.1 | New PoW based on Cryptonight-R, new block weight algorithm, slightly more efficient RingCT format
| 1788720 | 2019-03-10 | v11 | v0.14.0.0 | v0.14.1.1 | forbid old RingCT transaction format
| XXXXXXX | 2019-10-XX | XX | XXXXXXXXX | XXXXXXXXX | X
X's indicate that these details have not been determined as of commit date.
## Release staging schedule and protocol
Approximately three months prior to a scheduled software upgrade, a branch from Master will be created with the new release version tag. Pull requests that address bugs should then be made to both Master and the new release branch. Pull requests that require extensive review and testing (generally, optimizations and new features) should *not* be made to the release branch.
Approximately three months prior to a scheduled software upgrade, a branch from Master will be created with the new release version tag. Pull requests that address bugs should then be made to both Master and the new release branch. Pull requests that require extensive review and testing (generally, optimizations and new features) should *not* be made to the release branch.
## Compiling Monero from source
@@ -140,6 +179,7 @@ library archives (`.a`).
| OpenSSL | basically any | NO | `libssl-dev` | `openssl` | `openssl-devel` | NO | sha256 sum |
| libzmq | 3.0.0 | NO | `libzmq3-dev` | `zeromq` | `cppzmq-devel` | NO | ZeroMQ library |
| OpenPGM | ? | NO | `libpgm-dev` | `libpgm` | `openpgm-devel` | NO | For ZeroMQ |
| libnorm[2] | ? | NO | `libnorm-dev` | | ` | YES | For ZeroMQ |
| libunbound | 1.4.16 | YES | `libunbound-dev` | `unbound` | `unbound-devel` | NO | DNS resolver |
| libsodium | ? | NO | `libsodium-dev` | `libsodium` | `libsodium-devel` | NO | cryptography |
| libunwind | any | NO | `libunwind8-dev` | `libunwind` | `libunwind-devel` | YES | Stack traces |
| expat | 1.1 | NO | `libexpat1-dev` | `expat` | `expat-devel` | YES | XML parsing |
| GTest | 1.5 | YES | `libgtest-dev`^ | `gtest` | `gtest-devel` | YES | Test suite |
| GTest | 1.5 | YES | `libgtest-dev`[1] | `gtest` | `gtest-devel` | YES | Test suite |
| Doxygen | any | NO | `doxygen` | `doxygen` | `doxygen` | YES | Documentation |
| Graphviz | any | NO | `graphviz` | `graphviz` | `graphviz` | YES | Documentation |
| pcsclite | ? | NO | `libpcsclite-dev` | ? | `pcsc-lite pcsc-lite-devel` | NO | Ledger |
[^] On Debian/Ubuntu `libgtest-dev` only includes sources and headers. You must
[1] On Debian/Ubuntu `libgtest-dev` only includes sources and headers. You must
build the library binary manually. This can be done with the following command ```sudo apt-get install libgtest-dev && cd /usr/src/gtest && sudo cmake . && sudo make && sudo mv libg* /usr/lib/ ```
[2] libnorm-dev is needed if your zmq library was built with libnorm, and not needed otherwise
@@ -174,28 +221,30 @@ If you already have a repo cloned, initialize and update:
Monero uses the CMake build system and a top-level [Makefile](Makefile) that
invokes cmake commands as needed.
#### On Linux and OS X
#### On Linux and macOS
* Install the dependencies
* Change to the root of the source code directory, change to the most recent release branch, and build:
cd monero
git checkout v0.13.0.0
make
```bash
cd monero
git checkout release-v0.14
make
```
*Optional*: If your machine has several cores and enough memory, enable
parallel build by running `make -j<number of threads>` instead of `make`. For
this to be worthwhile, the machine should have one core and about 2GB of RAM
available per thread.
*Note*: If cmake can not find zmq.hpp file on OS X, installing `zmq.hpp` from
*Note*: If cmake can not find zmq.hpp file on macOS, installing `zmq.hpp` from
https://github.com/zeromq/cppzmq to `/usr/local/include` should fix that error.
*Note*: The instructions above will compile the most stable release of the
Monero software. If you would like to use and test the most recent software,
use ```git checkout master```. The master branch may contain updates that are
both unstable and incompatible with release software, though testing is always
encouraged.
both unstable and incompatible with release software, though testing is always
encouraged.
* The resulting executables can be found in `build/release/bin`
@@ -205,49 +254,65 @@ invokes cmake commands as needed.
* **Optional**: build and run the test suite to verify the binaries:
make release-test
```bash
make release-test
```
*NOTE*: `core_tests` test may take a few hours to complete.
* **Optional**: to build binaries suitable for debugging:
make debug
```bash
make debug
```
* **Optional**: to build statically-linked binaries:
make release-static
```bash
make release-static
```
Dependencies need to be built with -fPIC. Static libraries usually aren't, so you may have to build them yourself with -fPIC. Refer to their documentation for how to build them.
* **Optional**: build documentation in `doc/html` (omit `HAVE_DOT=YES` if `graphviz` is not installed):
HAVE_DOT=YES doxygen Doxyfile
```bash
HAVE_DOT=YES doxygen Doxyfile
```
#### On the Raspberry Pi
Tested on a Raspberry Pi Zero with a clean install of minimal Raspbian Stretch (2017-09-07 or later) from https://www.raspberrypi.org/downloads/raspbian/. If you are using Raspian Jessie, [please see note in the following section](#note-for-raspbian-jessie-users).
Tested on a Raspberry Pi Zero with a clean install of minimal Raspbian Stretch (2017-09-07 or later) from https://www.raspberrypi.org/downloads/raspbian/. If you are using Raspian Jessie, [please see note in the following section](#note-for-raspbian-jessie-users).
* `apt-get update && apt-get upgrade` to install all of the latest software
* Install the dependencies for Monero from the 'Debian' column in the table above.
* Increase the system swap size:
```
sudo /etc/init.d/dphys-swapfile stop
sudo nano /etc/dphys-swapfile
CONF_SWAPSIZE=1024
sudo /etc/init.d/dphys-swapfile start
```
* Clone monero and checkout most recent release version:
* If using an external hard disk without an external power supply, ensure it gets enough power to avoid hardware issues when syncing, by adding the line "max_usb_current=1" to /boot/config.txt
* Clone monero and checkout the most recent release version:
* The resulting executables can be found in `build/release/bin`
@@ -264,28 +329,33 @@ If you are using the older Raspbian Jessie image, compiling Monero is a bit more
* As before, `apt-get update && apt-get upgrade` to install all of the latest software, and increase the system swap size
```
sudo /etc/init.d/dphys-swapfile stop
sudo nano /etc/dphys-swapfile
CONF_SWAPSIZE=1024
sudo /etc/init.d/dphys-swapfile start
```
```bash
sudo /etc/init.d/dphys-swapfile stop
sudo nano /etc/dphys-swapfile
CONF_SWAPSIZE=2048
sudo /etc/init.d/dphys-swapfile start
```
* Then, install the dependencies for Monero except `libunwind` and `libboost-all-dev`
* Install the latest version of boost (this may first require invoking `apt-get remove --purge libboost*` to remove a previous version if you're not using a clean install):
sudo ./bjam cxxflags=-fPIC cflags=-fPIC -a install
```
```bash
sudo ./bjam cxxflags=-fPIC cflags=-fPIC -a install
```
* Wait ~4 hours
* From here, follow the [general Raspberry Pi instructions](#on-the-raspberry-pi) from the "Clone monero and checkout most recent release version" step.
@@ -304,24 +374,32 @@ application.
* Open the MSYS shell via the `MSYS2 Shell` shortcut
* Update packages using pacman:
pacman -Syuu
```bash
pacman -Syu
```
* Exit the MSYS shell using Alt+F4
* Edit the properties for the `MSYS2 Shell` shortcut changing "msys2_shell.bat" to "msys2_shell.cmd -mingw64" for 64-bit builds or "msys2_shell.cmd -mingw32" for 32-bit builds
* Restart MSYS shell via modified shortcut and update packages again using pacman:
pacman -Syuu
```bash
pacman -Syu
```
* Install dependencies:
To build for 64-bit Windows:
pacman -S mingw-w64-x86_64-toolchain make mingw-w64-x86_64-cmake mingw-w64-x86_64-boost mingw-w64-x86_64-openssl mingw-w64-x86_64-zeromq mingw-w64-x86_64-libsodium
```bash
pacman -S mingw-w64-x86_64-toolchain make mingw-w64-x86_64-cmake mingw-w64-x86_64-boost mingw-w64-x86_64-openssl mingw-w64-x86_64-zeromq mingw-w64-x86_64-libsodium mingw-w64-x86_64-hidapi
```
To build for 32-bit Windows:
pacman -S mingw-w64-i686-toolchain make mingw-w64-i686-cmake mingw-w64-i686-boost mingw-w64-i686-openssl mingw-w64-i686-zeromq mingw-w64-i686-libsodium
```bash
pacman -S mingw-w64-i686-toolchain make mingw-w64-i686-cmake mingw-w64-i686-boost mingw-w64-i686-openssl mingw-w64-i686-zeromq mingw-w64-i686-libsodium mingw-w64-i686-hidapi
```
* Open the MingW shell via `MinGW-w64-Win64 Shell` shortcut on 64-bit Windows
or `MinGW-w64-Win64 Shell` shortcut on 32-bit Windows. Note that if you are
* If you would like a specific [version/tag](https://github.com/monero-project/monero/tags), do a git checkout for that version. eg. 'v0.13.0.0'. If you dont care about the version and just want binaries from master, skip this step:
```bash
cd monero
```
* If you would like a specific [version/tag](https://github.com/monero-project/monero/tags), do a git checkout for that version. eg. 'v0.14.1.1'. If you don't care about the version and just want binaries from master, skip this step:
git checkout v0.13.0.0
```bash
git checkout v0.14.1.1
```
* If you are on a 64-bit system, run:
make release-static-win64
```bash
make release-static-win64
```
* If you are on a 32-bit system, run:
make release-static-win32
```bash
make release-static-win32
```
* The resulting executables can be found in `build/release/bin`
* **Optional**: to build Windows binaries suitable for debugging on a 64-bit system, run:
make debug-static-win64
```bash
make debug-static-win64
```
* **Optional**: to build Windows binaries suitable for debugging on a 32-bit system, run:
make debug-static-win32
```bash
make debug-static-win32
```
* The resulting executables can be found in `build/debug/bin`
### On FreeBSD:
The project can be built from scratch by following instructions for Linux above. If you are running monero in a jail you need to add the flag: `allow.sysvipc=1` to your jail configuration, otherwise lmdb will throw the error message: `Failed to open lmdb environment: Function not implemented`.
The project can be built from scratch by following instructions for Linux above(but use `gmake` instead of `make`). If you are running monero in a jail you need to add the flag: `allow.sysvipc=1` to your jail configuration, otherwise lmdb will throw the error message: `Failed to open lmdb environment: Function not implemented`.
We expect to add Monero into the ports tree in the near future, which will aid in managing installations using ports or packages.
@@ -386,7 +478,7 @@ You will have to add the serialization, date_time, and regex modules to Boost wh
To build: `env CC=egcc CXX=eg++ CPP=ecpp DEVELOPER_LOCAL_TOOLS=1 BOOST_ROOT=/path/to/the/boost/you/built make release-static-64`
#### OpenBSD >= 6.2
#### OpenBSD 6.2 and 6.3
You will need to add a few packages to your system. `pkg_add cmake zeromq libiconv`.
@@ -399,13 +491,13 @@ We assume you are compiling with a non-root user and you have `doas` enabled.
Note: do not use the boost package provided by OpenBSD, as we are installing boost to `/usr/local`.
### Building portable statically linked binaries (Cross Compiling)
### Building portable statically linked binaries
By default, in either dynamically or statically linked builds, binaries target the specific host processor on which the build happens and are not portable to other processors. Portable binaries can be built using the following targets:
@@ -491,6 +607,30 @@ By default, in either dynamically or statically linked builds, binaries target t
* ```make release-static-win64``` builds binaries on 64-bit Windows portable across 64-bit Windows systems
* ```make release-static-win32``` builds binaries on 64-bit or 32-bit Windows portable across 32-bit Windows systems
### Cross Compiling
You can also cross-compile static binaries on Linux for Windows and macOS with the `depends` system.
* ```make depends target=x86_64-linux-gnu``` for 64-bit linux binaries.
* ```make depends target=x86_64-w64-mingw32``` for 64-bit windows binaries.
* ```make depends target=i686-linux-gnu``` for 32-bit linux binaries.
* Requires: `g++-multilib bc`
* ```make depends target=i686-w64-mingw32``` for 32-bit windows binaries.
* Requires: `python3 g++-mingw-w64-i686`
* ```make depends target=arm-linux-gnueabihf``` for armv7 binaries.
* Requires: `g++-arm-linux-gnueabihf`
* ```make depends target=aarch64-linux-gnu``` for armv8 binaries.
* Requires: `g++-aarch64-linux-gnu`
The required packages are the names for each toolchain on apt. Depending on your distro, they may have different names.
Using `depends` might also be easier to compile Monero on Windows than using MSYS. Activate Windows Subsystem for Linux (WSL) with a distro (for example Ubuntu), install the apt build-essentials and follow the `depends` steps as depicted above.
The produced binaries still link libc dynamically. If the binary is compiled on a current distribution, it might not run on an older distribution with an older installation of libc. Passing `-DBACKCOMPAT=ON` to cmake will make sure that the binary will run on systems having at least libc version 2.17.
## Installing Monero from a package
**DISCLAIMER: These packages are not part of this repository or maintained by this project's contributors, and as such, do not go through the same review process to ensure their trustworthiness and security.**
@@ -499,7 +639,9 @@ Packages are available for
* Ubuntu and [snap supported](https://snapcraft.io/docs/core/install) systems, via a community contributed build.
snap install monero --beta
```bash
snap install monero --beta
```
Installing a snap is very quick. Snaps are secure. They are isolated with all of their dependencies. Snaps also auto update when a new version is released.
@@ -509,54 +651,46 @@ Installing a snap is very quick. Snaps are secure. They are isolated with all of
* Void Linux:
xbps-install -S monero
```bash
xbps-install -S monero
```
* GuixSD
guix package -i monero
```bash
guix package -i monero
```
* Docker
# Build using all available cores
docker build -t monero .
# or build using a specific number of cores (reduce RAM requirement)
docker build --build-arg NPROC=1 -t monero .
# either run in foreground
docker run -it -v /monero/chain:/root/.bitmonero -v /monero/wallet:/wallet -p 18080:18080 monero
Using depends might also be easier to compile monero on windows than using msys. Activate windows subsystem for linux (for example ubuntu) install the apt build-essentials and follow the depends steps as depicted above.
## Running monerod
The build places the binary in `bin/` sub-directory within the build directory
from which cmake was invoked (repository root by default). To run in
foreground:
./bin/monerod
```bash
./bin/monerod
```
To list all available options, run `./bin/monerod --help`. Options can be
specified either on the command line or in a configuration file passed by the
@@ -566,7 +700,9 @@ of the argument without the leading dashes, for example `log-level=1`.
To run in background:
./bin/monerod --log-file monerod.log --detach
```bash
./bin/monerod --log-file monerod.log --detach
```
To run as a systemd service, copy
[monerod.service](utils/systemd/monerod.service) to `/etc/systemd/system/` and
@@ -584,6 +720,12 @@ See [README.i18n.md](README.i18n.md).
## Using Tor
> There is a new, still experimental, [integration with Tor](ANONYMITY_NETWORKS.md). The
> feature allows connecting over IPv4 and Tor simulatenously - IPv4 is used for
> relaying blocks and relaying transactions received by peers whereas Tor is
> used solely for relaying transactions received over local RPC. This provides
> privacy and better protection against surrounding node (sybil) attacks.
While Monero isn't made to integrate with Tor, it can be used wrapped with torsocks, by
setting the following configuration parameters and environment variables:
@@ -608,7 +750,9 @@ setting the following configuration parameters and environment variables:
Example command line to start monerod through Tor:
This section contains general instructions for debugging failed installs or problems encountered with Monero. First ensure you are running the latest version built from the Github repo.
This section contains general instructions for debugging failed installs or problems encountered with Monero. First, ensure you are running the latest version built from the Github repo.
### Obtaining stack traces and core dumps on Unix systems
We generally use the tool `gdb` (GNU debugger) to provide stack trace functionality, and `ulimit` to provide core dumps in builds which crash or segfault.
* To use gdb in order to obtain a stack trace for a build that has stalled:
* To use `gdb` in order to obtain a stack trace for a build that has stalled:
Run the build.
Once it stalls, enter the following command:
```
gdb /path/to/monerod `pidof monerod`
```bash
gdb /path/to/monerod `pidof monerod`
```
Type `thread apply all bt` within gdb in order to obtain the stack trace
@@ -652,11 +798,13 @@ When it terminates with an output along the lines of "Segmentation fault (core d
You can now analyse this core dump with `gdb` as follows:
`gdb /path/to/monerod /path/to/dumpfile`
```bash
gdb /path/to/monerod /path/to/dumpfile`
```
Print the stack trace with `bt`
* To run monero within gdb:
#### To run monero within gdb:
Type `gdb /path/to/monerod`
@@ -668,15 +816,17 @@ Type `run` to run monerod
There are two tools available:
* ASAN
#### ASAN
Configure Monero with the -D SANITIZE=ON cmake flag, eg:
cd build/debug && cmake -D SANITIZE=ON -D CMAKE_BUILD_TYPE=Debug ../..
```bash
cd build/debug && cmake -D SANITIZE=ON -D CMAKE_BUILD_TYPE=Debug ../..
```
You can then run the monero tools normally. Performance will typically halve.
* valgrind
#### valgrind
Install valgrind and run as `valgrind /path/to/monerod`. It will be very slow.
@@ -686,7 +836,9 @@ Instructions for debugging suspected blockchain corruption as per @HYC
There is an `mdb_stat` command in the LMDB source that can print statistics about the database but it's not routinely built. This can be built with the following command:
`cd ~/monero/external/db_drivers/liblmdb && make`
```bash
cd ~/monero/external/db_drivers/liblmdb && make
```
The output of `mdb_stat -ea <path to blockchain dir>` will indicate inconsistencies in the blocks, block_heights and block_info table.
voiderase(size_tsz){NET_BUFFER_LOG("erasing "<<sz<<"/"<<size());CHECK_AND_ASSERT_THROW_MES(offset+sz<=storage.size(),"erase: sz too large");offset+=sz;if(offset==storage.size()){storage.resize(0);offset=0;}}
epee::span<constuint8_t>span(size_tsz)const{CHECK_AND_ASSERT_THROW_MES(sz<=size(),"span is too large");returnepee::span<constuint8_t>(storage.data()+offset,sz);}
// carve must keep the data in scope till next call, other API calls (such as append, erase) can invalidate the carved buffer
epee::span<constuint8_t>carve(size_tsz){CHECK_AND_ASSERT_THROW_MES(sz<=size(),"span is too large");offset+=sz;returnepee::span<constuint8_t>(storage.data()+offset-sz,sz);}
// ! (how ever if in some wonderful juristdictions that is not the case, then why not make another sub-class withat that members and licence it as epee part)
// ! Working on above premise, IF this is valid in your juristdictions, then consider this code as released as:
LOG_ERROR("Failed to read signature in levin message, at load_struct_from_levin_message");
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
