Always send TX public key when generating output destination keys: it may be an additional TX public key in case of subaddress; before we always use R.
Fix the commitment mask generation: It must be delegated to device as it implies the amount key.
Send MONERO_VERSION string in reset command to allow version compatibility check.
Some enhancement of debug log.
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.
0ec360b4 CryptonightR: define out i386/x86_64 specific code on other archs (moneromooo-monero)
773509dd slow-hash: fix build on arm (moneromooo-monero)
0cb6a763 cmake: ARCH_ID fixes for cross compilation (TheCharlatan)
If two create_block_template are called at nearly the same time,
and a block is added at nearly the same time, this could happen:
- the blockchain top block is B0
- thread 1 enters create_block_template, takes blockchain lock
- thread 1 creates a fresh block referencing prev block B0
- thread 1 releases blockchain lock
- thread 0 adds a new block
- thread 0 enters create_block_template
- thread 0 updates block template
- thread 1 takes txpool lock and continues creating block template
- thread 1 overwrites block template with previous data
993a1994 tests: add a CNv4 JIT test (moneromooo-monero)
736f2579 crypto: plug CNv4 JIT into cn_slow_hash (moneromooo-monero)
2e9b988a crypto: clear cache after generating random program (moneromooo-monero)
683c3d13 performance_tests: add tests for new Cryptonight variants (moneromooo-monero)
32ebc95d CMakeLists.txt: detect and use -pthread compiler flag (moneromooo-monero)
be2d061b miner: fix build with boost 1.69 (moneromooo-monero)
1de62cb1 mlocker: fix access to global lock map after dtor on exit (moneromooo-monero)
5544bb83 mlocker: fix dtor ordering problem (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
0b0fb709 Build fixes for some platforms (moneromooo-monero)
3ac3366a blockchain: add v10 fork heights (moneromooo-monero)
c2b8037a Adding cnv4-2 tweaks (Lee Clagett)
1b77e80a Cryptonight variant 4 aka CryptonightR (SChernykh)
b980fec4 slow-hash: some more big endian fixes (xiphon)
cd22a02d slow-hash: fix for big endian (moneromooo-monero)
96f53815 Small function declaration cleanup in slow-hash.c (Pol Mauri)
612ecb13 Add support for V10 protocol with BulletProofV2 and short amount. (cslashm)
823b38bc Fix dummy decryption in debug mode (cslashm)
377de050 fix log namespace (cslashm)
ff9853b4 New scheme key destination contrfol (cslashm)
041af954 cryptonote: Fix enum check in expand_transaction_2 (Tom Smeding)
1767c817 simplewallet: tell the user to complain to the recipient (moneromooo-monero)
c2d0e9a1 ringct: fix v1 ecdhInfo serialization (moneromooo-monero)
0b18fa54 ringct: the commitment mask is now deterministic (moneromooo-monero)
6ba3a116 ringct: encode 8 byte amount, saving 24 bytes per output (moneromooo-monero)
77f8f454 ringct: save 3 bytes on bulletproof size (moneromooo-monero)
f7f67600 add a bulletproof version, new bulletproof type, and rct config (moneromooo-monero)
5b07e0c9 core: include a dummy encrypted payment id when no payment is used (moneromooo-monero)
2eff9b12 core, wallet: remember original text version of destination address (moneromooo-monero)
e10d12b6 simplewallet: disable long payment ids by default (moneromooo-monero)
b84b350f blockchain: fix wrong hf version when popping multiple blocks (moneromooo-monero)
1c7650f4 simplewallet: remove ability to transfer with detached short payment ids (moneromooo-monero)
4a7917ef blockchain: fix block rate check for empty blockchains (moneromooo-monero)
34d2850f ignore child process when exec (Jethro Grassie)
5f89caea wallet2: fix ring reuse breaking when using histogram (moneromooo-monero)
db1e0a53 core: fix unmixable special case allowing ring size below 11 (moneromooo-monero)
66772f12 blockchain: include number of discarded blocks in --reorg-notify (moneromooo-monero)
af1ade4e core: add a few more block rate window sizes (moneromooo-monero)
fb0dbab9 notify: fix tokenizing being too strict (moneromooo-monero)
0ac22d0e core: add --block-rate-notify (moneromooo-monero)
7d2f817f blockchain: add --reorg-notify (moneromooo-monero)
1168e8d5 cryptonote_core: warn when the block rate deviates from expectations (moneromooo-monero)
842a5d8b notify: handle arbitrary tags (moneromooo-monero)
ebc60a09 ArticMine's new block weight algorithm (moneromooo-monero)
- 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
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.
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 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
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.
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.
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)
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)
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)
Those take a command line of the form "A [B]", with A being the
name (and optional path, if not in the caller's CWD, but fully
qualified path is recommended, avoids possible security issues)
to a program, and optional arguments. Any occurence of the two
character string "%s" will be replaced by the hash of the block
or transaction which triggered the notification.
Tokenization is barebones. If you want things like pipes, calls
to paths with spaces, etc, then use a script (though exec time
will suffer).
block-notify is called when a new block is added onto the chain.
tx-notify is called when a new transaction happens with the
wallet as source and/or destination.
It is the notification program's responsibility to determine what
to do in those cases.
Note that this is asynchronous, so it is very possible that:
- the notification programs will be run out of order
- several events happen before the notification for the first one
A Windows port would be nice if someone wants to make one.
The key image (which was only supplied if verbose was true) is
readily available, not a secret key, and it was only modelled
after the CLI command because it's a bit spammy for the CLI.
The configure script in hidapi and libsodium tried to find clang in /usr/bin,
even though the correct prefix was passed in. This sets the correct CC flag.
This was previously undetected, because clang and the sdk where
installed in the global environment.
This also fixes a subsequent error, where IOKIT and CoreFoundation are
not found, again for the reason stated above.
Clang needs to get its cctools path passed directly for the hid build to
succeed.
Make gperf a permanent external dependency.
Remove pcsc from depends.
If we originally think we have enough outputs on the blockchain
to pick random fake outputs, we might end up with not enough of
them if enough are actually blackballed.
Add a Travis build script for Monero. This was blatantly copied from
Bitcoin. It spawns jobs in docker containers running an ubuntu bionic
image.
This commit also a fixes a problem where librt was still linked, even
when compiling statically.
b2bb9312 blockchain: simplify output distribution code (moneromooo-monero)
befdcbf4 db_lmdb: do not use base for cumulative distribution (moneromooo-monero)
26a42fe5 Added features to epee::span<T> : - Support for classes - Added `remove_prefix` function - Added `to_mut_span` and `as_mut_byte_span` (Lee Clagett)
56b50faa wallet: use wipeable_string in more places where a secret is used (moneromooo-monero)
07ec748c wipeable_string: add hex_to_pod function (moneromooo-monero)
42397359 Fixup 32bit arm build (TheCharlatan)
a06d2581 Fix Windows build (TheCharlatan)
ecaf5b3f Add libsodium to the packages, the arm build was complaining about it. (TheCharlatan)
cbbf4d24 Adapt translations to upstream changes (TheCharlatan)
db571546 Updated pcsc url (TheCharlatan)
f0ba19fd Add lrelease to the depends (TheCharlatan)
cfb30462 Add Miniupnp submodule (TheCharlatan)
5f7da005 Unbound is now a submodule. Adapt depends for this. (TheCharlatan)
d6b9bdd3 Update readmes to reflect the usage of depends (TheCharlatan)
56b6e41e Add support for apple and arm building (TheCharlatan)
29311fd1 Disable stack unwinding for mingw32 depends build. (TheCharlatan)
8db3d573 Modify depends for monero's dependencies (TheCharlatan)
0806a23a Initial depends addition (TheCharlatan)
Implemented strategy splits total amount into N equal parts,
where N is a specified number of outputs. If N > 1, dummy
change output is NOT created.
rebased by moneromooo
'outputs' option allows to specify the number of
separate outputs of smaller denomination that will
be created by sweep operation.
rebased by moneromooo
This makes it easier to avoid bugs on the caller side if errors are
represented by non empty strings.
This fixes the refresh height setting in new wallets when no daemon
is running.
4cb1d879 blockchain_blackball: s/return false;/return 0;/ (moneromooo-monero)
9bdc9109 blockchain_blackball: use %zu for size_t (moneromooo-monero)
db3db093 blockchain_blackball: use mdb_size_t where appropriate (moneromooo-monero)
b1f05f58 blockchain_blackball: error out on fgets error (moneromooo-monero)
- device name is a new wallet property
- full device name is now a bit more structured so we can address particular device vendor + device path. Example: 'Ledger', 'Trezor:udp', 'Trezor:udp:127.0.0.1:21324', 'Trezor:bridge:usb01'. The part before ':' identifies HW device implementation, the optional part after ':' is device path to look for.
- new --hw-device parameter added to the wallet, can name the hardware device
- device reconnect added
4469b0c4 abstract_tcp_server2: fix binding to the wrong IP (moneromooo-monero)
8eab6147 epee: use the socket::bind variant which does not throw (moneromooo-monero)
a54dbaee blockchain_blackball: add --force-chain-reaction-pass flag (moneromooo-monero)
44439c32 record blackballs as amount/offset, and add export ability (moneromooo-monero)
4bce935b blockchain_blackball: more optimizations (moneromooo-monero)
b66ba783 blockchain_blackball: do not process duplicate blockchains parts (moneromooo-monero)
639a3c01 blockchain_blackball: make it clear secondary passes are not incremental (moneromooo-monero)
eb8a51be blockchain_blackball: detect spent outputs by partial ring reuse (moneromooo-monero)
d6d276c6 blockchain_blackball: fix chain reaction phase in incremental mode (moneromooo-monero)
2b2a681b blockchain_blackball: avoid false positives for different amounts (moneromooo-monero)
80e4fef3 blockchain_blackball: set transaction looping txn to read only (moneromooo-monero)
4801d6b5 blockchain_blackball: add stats (moneromooo-monero)
846190fd blockchain_blackball: support pre-v2 databases (moneromooo-monero)
daa6cc7d blockchain_blackball: use LMDB for the cache (moneromooo-monero)
50cb370d ringdb: allow blackballing many outputs at once (moneromooo-monero)
62511df6 wallet2: fix refresh retry when a block/tx fails to parse (moneromooo-monero)
b219c24c wallet2: trim hash chain after fast refresh of hashes (moneromooo-monero)
5b6bcca3 wallet2: fix checking the wrong vector when adding hashes (moneromooo-monero)
5019852a cn_deserialize: extract payment ids from extra nonce (moneromooo-monero)
2af1ec3a cn_deserialize: support pruned transactions (moneromooo-monero)
a4d2d842 blockchain_depth: add average min depth (moneromooo-monero)
289880d8 blockchain_depth: get the average min depth of a set of txes (moneromooo-monero)
628428a0 blockchain_ancestry: faster and uses less memory (moneromooo-monero)
2382484d blockchain_ancestry: add an incremental mode (moneromooo-monero)
888324fa blockchain_ancestry: finds all ancestors of a tx, block, or chain (moneromooo-monero)
This proposal allows to perform multiple compilation from different branch/arch in
separate directories.
Example:
build
├── GNU_Linux
│ ├── multi-compilation
│ │ └── release
│ └── NanoS-USBHID
│ └── release
└── Msys
└── NanoS-USBHID
└── release
Edit 1:
Try to handle special char as : / \ .
--data-dir in unit test not yet tested
Edit 2:
donot use param for uname. -o is not supported by MacOS.
9137ad2c blockchain: add a testnet v9 a day after v8 (moneromooo-monero)
ac4f71c2 wallet2: bump testnet rollback to account for coming reorg (moneromooo-monero)
8f418a6d bulletproofs: #include <openssl/bn.h> (moneromooo-monero)
2bf63650 bulletproofs: speed up the latest changes a bit (moneromooo-monero)
044dff5a bulletproofs: scale points by 8 to ensure subgroup validity (moneromooo-monero)
c83012c4 bulletproofs: match aggregated verification to sarang's latest prototype (moneromooo-monero)
ce0c7432 performance_tests: add padded bulletproof construction (moneromooo-monero)
1224e53b core_tests: add a test for 4-aggregated BP verification (moneromooo-monero)
0e6ed559 fuzz_tests: add a bulletproof fuzz test (moneromooo-monero)
463434d1 more comprehensive test for ge_p3 comparison to identity/point at infinity (moneromooo-monero)
d0a0565f unit_tests: add a few more multiexp unit tests (moneromooo-monero)
6526d87f core_tests: add a test for a tx with empty bulletproof (moneromooo-monero)
a129bbd9 multiexp: fix maxscalar off by one (moneromooo-monero)
7ed496cc ringct: error out when hashToPoint* returns the point at infinity (moneromooo-monero)
d1591853 cryptonote_basic: check output type before using it (moneromooo-monero)
61632dc1 ringct: prevent a potential very large allocation (moneromooo-monero)
a4317e61 crypto: some paranoid checks in generate_signature/check_signature (moneromooo-monero)
7434df1c crypto: never return zero in random32_unbiased (moneromooo-monero)
0825e974 multiexp: fix wrong Bos-Coster result for 1 non trivial input (moneromooo-monero)
a1359ad4 Check inputs to addKeys are in range (moneromooo-monero)
fe0fa3b9 bulletproofs: reject x, y, z, or w[i] being zero (moneromooo-monero)
5ffb2ff9 v8: per byte fee, pad bulletproofs, fixed 11 ring size (moneromooo-monero)
869b3bf8 bulletproofs: a few fixes from the Kudelski review (moneromooo-monero)
c4291762 bulletproofs: reject points not in the main subgroup (moneromooo-monero)
15697177 bulletproofs: speed up a few multiplies using existing Hi cache (moneromooo-monero)
0b05a0fa Add Pippenger cache and limit Straus cache size (moneromooo-monero)
51eb3bdc add pippenger unit tests (moneromooo-monero)
b17b8db3 performance_tests: add stats and loop count multiplier options (moneromooo-monero)
7314d919 perf_timer: split timer class into a base one and a logging one (moneromooo-monero)
d126a02b performance_tests: add aggregated bulletproof tx verification (moneromooo-monero)
263431c4 Pippenger multiexp (moneromooo-monero)
1ed0ed4d multiexp: cut down on memory allocations (moneromooo-monero)
1b867e7f precalc the ge_p3 representation of H (moneromooo-monero)
ef56529f performance_tests: document the tested bulletproof layouts (moneromooo-monero)
30111780 unit_tests: a couple more bulletproof unit tests for gamma (moneromooo-monero)
c444b1b2 require canonical multi output bulletproof layout (moneromooo-monero)
7e67c52f Add a define for the max number of bulletproof multi-outputs (moneromooo-monero)
2a8fcb42 Bulletproof aggregated verification and tests (moneromooo-monero)
126196b0 multiexp: some speedups (moneromooo-monero)
71d67bda aligned: aligned memory alloc/realloc/free (moneromooo-monero)
cb9ecab1 performance_tests: add signature generation/verification (moneromooo-monero)
bacf0a1e bulletproofs: add aggregated verification (moneromooo-monero)
e895c3de make straus cached mode thread safe, and add tests for it (moneromooo-monero)
7f48bf05 multiexp: bos coster now works for just one point (moneromooo-monero)
9ce9f8ca bulletproofs: add multi output bulletproofs to rct (moneromooo-monero)
f34e2e20 performance_tests: add tx checking tests with more than 2 outputs (moneromooo-monero)
0793184b performance_tests: add a --verbose flag, and default to terse (moneromooo-monero)
939bc223 add Straus multiexp (moneromooo-monero)
9ff6e6a0 ringct: add bos coster multiexp (moneromooo-monero)
e9164bb3 bulletproofs: misc optimizations (moneromooo-monero)
112f32f0 performance_tests: add crypto ops (moneromooo-monero)
f5d7b993 performance_tests: add bulletproofs (moneromooo-monero)
8f4ce989 performance_tests: add RingCT MLSAG gen/ver tests (moneromooo-monero)
1aa10c43 performance_tests: add (Borromean) range proofs (moneromooo-monero)
aacfd6e3 bulletproofs: multi-output bulletproofs (moneromooo-monero)
cb1cc757 performance_tests: don't override log level to 0 (moneromooo-monero)
- fix integer overflow in n_bulletproof_amounts
- check input scalars are in range
- remove use of environment variable to tweak straus performance
- do not use implementation defined signed shift for signum
Drop miniupnp and unbound depends builds. Make sure that build variables are propageted properly to unbound and miniupnp.
Rebase to after the v0.12 release
Add pcsc-lite to linux builds
Fixup windows icu4c linking with depends, the static libraries have an 's' appended to them
Compiling depends arm-linux-gnueabihf will allow you to compile armv6zk monero binaries
Add readline, ldns, graphviz, unbound to depends packages
Add a cmake toolchain file to depends that is uniquely created for every build and placed in triple/share/toolchain.cmake
This file is then passed to cmake with -DCMAKE_TOOLCHAIN_FILE=/path/to/triple/share/toolchain.cmake
Add the boost locale package to depends
In the depends cmake toolchain file, a DEPENDS flag is added
to exclude, or change cmake checks done that are required for depends
Link miniupnpc and unwind from depends and not external
Add libiconv and icu4c to depends, required for mingw32 builds.
Headers (winsock) need to be lower case in order to compile on unix systems.
This should not affect building on windows.
Depends cross compiles project dependencies for linux, mac and windows and multiple architectures.
Depends is original work by Cory Fields and used in bitcoin and a wide range of bitcoin related projects.
Contains two modifications to improve ASIC resistance: shuffle and integer math.
Shuffle makes use of the whole 64-byte cache line instead of 16 bytes only, making Cryptonight 4 times more demanding for memory bandwidth.
Integer math adds 64:32 bit integer division followed by 64 bit integer square root, adding large and unavoidable computational latency to the main loop.
More details and performance numbers: https://github.com/SChernykh/xmr-stak-cpu/blob/master/README.md
This uses less memory and makes it faster to load/save, though
makes it slower to run (which is actually faster since it would
previously start swapping anyway).
Let it be autodiscovered instead to avoid cmake thinking it's crosscompiling builds where host = target. This resolves a cmake configure error in MSYS2 caused by CMAKE_CROSSCOMPILING checks in #4294.
29dea03 epee: resize vectors where possible in serialization (moneromooo-monero)
76affd9 epee: some speedup in parsing (moneromooo-monero)
dc6c069 db_lmdb: speedup the get_output_distribution common case (moneromooo-monero)
76ac5a8 wallet2: ask for a binary output distribution, for speed (moneromooo-monero)
ea37614 wallet: wipe seed from memory where appropriate (moneromooo-monero)
e9ffa91 store secret keys encrypted where possible (moneromooo-monero)
70271fa common: add a class to safely wrap mlock/munlock (moneromooo-monero)
ab74dc2 crypto: make secret_key automatically mlock (moneromooo-monero)
This avoids constant rechecking of the same things each time
a miner asks for the block template. The tx pool maintains
a cookie to allow users to detect when the pool state changed,
which means the block template needs rebuilding.
This class will allow mlocking small objects, of which there
may be several per page. It adds refcounting so pages are only
munlocked when the last object on that page munlocks.
The secret spend key is kept encrypted in memory, and
decrypted on the fly when needed.
Both spend and view secret keys are kept encrypted in a JSON
field in the keys file. This avoids leaving the keys in
memory due to being manipulated by the JSON I/O API.
7f8bdeb easylogging++: make the logger handle early/late logging (moneromooo-monero)
bc8cbdb stack_trace: print stack traces on stdout if the logger isn't live (moneromooo-monero)
63e342b crypto: move null_pkey/null_skey to the cpp file (moneromooo-monero)
0496c7c crypto: do not use boost::value_initialized to init null skey/pkey (moneromooo-monero)
Many people are using this as a "let's see what this does" command
when something doesn't work as they thought it should, and thus
destroying info that they might still need.
Fixes failing test during Arch package build (due to attempt to write to
~/.bitmonero/...).
Prefix temp dir path with "monero-" because we are not putting it on the
system, so good to identify ourselves in case the dir gets left over due
to crash, etc.
149da42 db_lmdb: enable batch transactions by default (stoffu)
34cb6b4 add --regtest and --fixed-difficulty for regression testing (vicsn)
9e1403e update get_info RPC and bump RPC version (vicsn)
207b66e first new functional tests (vicsn)
This gets rid of the temporary precalc cache.
Also make the RPC able to send data back in binary or JSON,
since there can be a lot of data
This bumps the LMDB database format to v3, with migration.
34de7bc2 device_ledger: fix buffer underflow on bad data from device (moneromooo-monero)
41e9cab4 device: misc cleanup (moneromooo-monero)
3b4dec2d device_ledger: fix potential buffer overflow from bad size calc (moneromooo-monero)
Also added notes to WalletManager::verifyWalletPassword (which afaik seems unused
by anyone at the moment) regarding the need to unlock the keys file beforehand.
on_generateblocks RPC call combines functionality from the on_getblocktemplate and on_submitblock RPC calls to allow rapid block creation. Difficulty is set permanently to 1 for regtest.
Makes use of FAKECHAIN network type, but takes hard fork heights from mainchain
Default reserve_size in generate_blocks RPC call is now 1. If it is 0, the following error occurs 'Failed to calculate offset for'.
Queries hard fork heights info of other network types
1d17647 epee.string_tools: add conversion between UTF-8 and UTF-16 (stoffu)
59de6f8 util: add file_locker class (stoffu)
3d623a8 wallet: prevent the same wallet file from being opened by multiple processes (stoffu)
This is based on how much an attacking miner stands to lose in block
rewardy by mining a private chain which double spends a payment.
This is not foolproof, since mining is based on luck, and breaks
down as the attacking miner nears 50% of the network hash rate,
and the estimation is based on a constant block reward.
key derivation and checking for incoming outputs are threaded
in batch before adding blocks to the local blockchain. Other
minor bits and bobs are also cached.
8fc0cdb wallet2: lower default for subaddress lookahead when restoring with hardware (stoffu)
248310d Move parse_subaddress_lookahead() from simplewallet.cpp to util.cpp (stoffu)
46e90b7 Wallet API: add support for wallet creation from hardware device (stoffu)
use snprintf "just in case" where appropriate
consistently use unsigned for temp values
pass std::string by const ref rather than by value
add length check (which can't happen in practice) for memcpy
8962f00 simplewallet: add optional trusted/untrusted argument to set_daemon (moneromooo-monero)
941a608 util: consider Tor/I2P addresses to be non local (moneromooo-monero)
2b3357e README: mention --untrusted-daemon (moneromooo-monero)
f8dd433 epee: fix detection of 172.16.0.0/172.31.255.255 local IP range (moneromooo-monero)
5db9e3c unit_tests: add tests for local IP range detection (moneromooo-monero)
db55263 threadpool: allow constructing an object, and misc tweaks (moneromooo-monero)
ce173cb core: remove threadpool dependency from header (moneromooo-monero)
3147468 unit_tests: add threadpool unit test (moneromooo-monero)
9cc0d42 connection_context: remove state_ prefix from state names (moneromooo-monero)
d9d002c daemon: print peer state in sync_info (moneromooo-monero)
for privacy reasons, so an untrusted node can't easily track
wallets from IP address to IP address, etc. The granularity
is 1024 blocks, which is about a day and a half.
a connection's timeout is halved for every extra connection
from the same host.
Also keep track of when we don't need to use a connection
anymore, so we can close it and free the resource for another
connection.
Also use the longer timeout for non routable local addresses.
b26cd26 blockchain_utilities: do not link against unneeded p2p lib (moneromooo-monero)
66f4700 blockchain_blackball: add incremental mode (moneromooo-monero)
e09710f blockchain_blackball: also blackball N N-sized duplicate rings (moneromooo-monero)
Update readme to explain and warn about building master, and encourage (via example) to build release branches.
Also updated instance where example build instructions had 0.11.0 as the most recent release.
47fdb74 WalletApi: getMultisigInfo entry for gui wallets... (naughtyfox)
47fdb74 Refactored: work with wallet api statuses to make setting and getting operations atomic along with error strings (naughtyfox)
740da1b core: fix automatic safe db sync mode switching (moneromooo-monero)
e942d34 protocol: do not switch to unsafe sync mode for just a few blocks (moneromooo-monero)
These are unlikely to happen at random, but Wijaya et al made
a paper about it, so people might try it on purpose now (and it
turns out it's easy to add anyway)
use unsigned int to avoid having to range check negative numbers,
use const where possible, don't needlessly create empty objects,
use std::move where possible
This can happen if a peer tries to obtain the next span from other
peers if that span is needed for not downloaded yet. Also if the
peer maliciously requests a non existent block hash.
3880bf39 cryptonote_protocol_handler.inl: remove span read just now that failed to pass some basic tests (stoffu)
da249fd5 cryptonote_protocol_handler.inl: fix return type mismatches (int vs bool) (stoffu)
Those were added to the seed nodes list even when they had already
been added. Moreover, the current index was not reset after they
were added, typically causing previous seeds to be used, and some
of those fallback seeds to not be tried.
ffeeefde speedup get_output_histogram for all amounts when min_count > 0 (moneromooo-monero)
2dae0f20 wallet2: add missing parameters to get_output_histogram (moneromooo-monero)
f21df05 was never supposed to be merged into the master branch.
fluffypony merged #3670 before #3668 was rebased and resolved.
Note: the cherry-picked commit hashes are now invalid because #3670
was merged before #3668 was rebased with the updated repo location.
875c1cab wallet2: increase rpc timeout for get_output_distribution (moneromooo-monero)
70f23217 add top height to get_output_distribution, and cache it for rct (moneromooo-monero)
8c7363fb rpc: add missing perf timer for get_output_distribution (moneromooo-monero)
Though we only need miniupnpc, rebasing and maintaining a miniupnpc-only
repo is unrealistic.
(cherry picked from commit 3c40eb768c292a4dec79d7dffd6685fd37940a2a)
In file included from src/cryptonote_basic/hardfork.cpp:33:
In file included from src/blockchain_db/blockchain_db.h:42:
In file included from src/cryptonote_basic/hardfork.h:31:
contrib/epee/include/syncobj.h:37:10: fatal error: 'boost/thread/v2/thread.hpp' file not found
#include <boost/thread/v2/thread.hpp>
^~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from src/rpc/daemon_handler.cpp:29:
In file included from src/rpc/daemon_handler.h:36:
In file included from src/p2p/net_node.h:41:
In file included from contrib/epee/include/net/levin_server_cp2.h:32:
In file included from contrib/epee/include/net/abstract_tcp_server2.h:324:
contrib/epee/include/net/abstract_tcp_server2.inl:44:10: fatal error: 'boost/thread/v2/thread.hpp' file not found
#include <boost/thread/v2/thread.hpp> // TODO
^~~~~~~~~~~~~~~~~~~~~~~~~~~~
contrib/epee/include/math_helper.h: In member function 'bool epee::math_helper::average<val, default_base>::set_base()':
contrib/epee/include/syncobj.h:227:56: error: 'sleep_for' is not a member of 'boost::this_thread'
#define CRITICAL_REGION_LOCAL(x) {boost::this_thread::sleep_for(boost::chrono::milliseconds(epee::debug::g_test_dbg_lock_sleep()));} epee::critical_region_t<decltype(x)> critical_region_var(x)
^
contrib/epee/include/syncobj.h:227:56: note: in definition of macro 'CRITICAL_REGION_LOCAL'
#define CRITICAL_REGION_LOCAL(x) {boost::this_thread::sleep_for(boost::chrono::milliseconds(epee::debug::g_test_dbg_lock_sleep()));} epee::critical_region_t<decltype(x)> critical_region_var(x)
^~~~~~~~~
contrib/epee/include/syncobj.h:227:56: note: suggested alternative: 'sleep'
#define CRITICAL_REGION_LOCAL(x) {boost::this_thread::sleep_for(boost::chrono::milliseconds(epee::debug::g_test_dbg_lock_sleep()));} epee::critical_region_t<decltype(x)> critical_region_var(x)
^
contrib/epee/include/syncobj.h:227:56: note: in definition of macro 'CRITICAL_REGION_LOCAL'
#define CRITICAL_REGION_LOCAL(x) {boost::this_thread::sleep_for(boost::chrono::milliseconds(epee::debug::g_test_dbg_lock_sleep()));} epee::critical_region_t<decltype(x)> critical_region_var(x)
^~~~~~~~~
When additional keys was needed, the TX scan failed because the
derivation data was always recomputed with the main tx_key and not
the corresponding additional one.
Moreover this patch avoid perf decreasing when not using HW device.
73951cbd wallet2: request transactions in slices when scanning for known rings (moneromooo-monero)
25fe67e4 rpc: allow getting pruned blocks from gettransactions (moneromooo-monero)
c77d2bfa Add the possibility to export private view key for fast scan. (cslashm)
100b7bc1 Change mutex lock model to avoid dead lock and ensure locks are always released. (cslashm)
641dfc99 Automatic height setup when creating/restoring hw device. (cslashm)
eaa8bfe7 wallet2: set from_height of GET_OUTPUT_DISTRIBUTION correctly The previous expression (stoffu)
0a619f78 wallet2: enable the mitigation only after the fork height (stoffu)
A key image may be present more than once if all but one of the
txes spending that key image are coming from blocks. When loading
a txpool from storage, we must load the one that's not from a
block first to avoid rejection
and get them pruned in find_and_save_rings, since it does not need
the pruned data in the first place.
Also set decode_to_json to false where missing, we don't need this
either.
On client startup the device asks for authorization to export the private view key.
If user agree, the client hold the private view key allowing a fast blockchain scan.
If the user does not agree, the blockchain scan is fully done via the device.
When creating/restoring wallet, if --restore-height option is not used the current estimate
height is used for starting the scan. In other words it is assume we are creating a new account.
WalletApi: makeMultisig call introduced
WalletApi: finalizeMultisig call introduced
WalletApi: new calls exportMultisigImages and importMultisigImages
WalletApi: method to return multisig wallet creation state
WalletApi: create multisig transaction, sign multisig transaction, commit transaction and get multisig data are added
WalletApi: identation and style fixes
changed wording in hard fork section because reasons. Added prospective slot of next hardfork to communicate that more are coming because it never stops.
its everywhere and all at the same time.
Takes about 10 ms, which takes pretty much all of the get_info
RPC, which is called pretty often from wallets.
Also add a new lock so we don't need to lock the blockchain lock,
which will avoid blocking for a long time when calling the getinfo
RPC while syncing. Users of get_difficulty_for_next_block who need
the lock will have locked it already.
b86f1e5d Add command line option allowing to restrict the default sub-address lookahead in order to avoid so looooong time of set-up when creating a HW based wallet. (stoffu)
eac3a11e wallet: more user friendly print_ring (moneromooo-monero)
79853514 wallet2_api: add key reuse mitigations API (moneromooo-monero)
b057a21d wallet2_api: add ring api (moneromooo-monero)
d32ef7b0 ringdb: factor ring addition code (moneromooo-monero)
a7da8208 wallet2_api: add blackball api (moneromooo-monero)
2ab66ff1 liblmdb: install lmdb library for wallet2_api usage (stoffu)
504428ab ringdb: use the genesis block as a db name (moneromooo-monero)
b09e5181 wallet: add a set_ring command (moneromooo-monero)
0590f62a new blockchain_usage tool, reports on output usage (moneromooo-monero)
db10dd6d wallet: make ringdb an object with database state (moneromooo-monero)
df6fad4c blockchain_utilities: new blockchain_blackball tool (moneromooo-monero)
d29ea045 wallet: add an output blackball list to avoid using those in rings (moneromooo-monero)
18eaf194 wallet: key reuse mitigation options (moneromooo-monero)
5f146873 wallet: add shared ring database (moneromooo-monero)
41f727ce add RPC to get a histogram of outputs of a given amount (moneromooo-monero)
This will avoid careless forkers polluting the shared database
even if they make their own chain. They'll then automatically
start using another subdb, and any key-reusing fork of those
forks will reuse their subdbs.
It scans for known spent outputs and stores their public keys
in a database which can then be read by the wallet, which can
then avoid using those as fake outs in new transactions.
Usage: monero-blockchain-blackball db1 db2...
This uses the shared database in ~/.shared-ringdb
If a pre-fork output is spent on both Monero and attack chain,
any post-fork output can be deduced to be a fake output, thereby
decreasing the effective ring size.
The segregate-per-fork-outputs option, on by default, allows
selecting only pre-fork outputs in this case, so that the same
ring can be used when spending it on the other side, which does
not decrease the effective ring size.
This is intended to be SET when intending to spend Monero on the
attack fork, and to be UNSET if not intending to spend Monero
on the attack fork (since it leaks the fact that the output being
spent is pre-fork).
If the user is not certain yet whether they will spend pre-fork
outputs on a key reusing fork, the key-reuse-mitigation2 option
should be SET instead.
If you use this option and intend to spend Monero on both forks,
then spend real Monero first.
This maps key images to rings, so that different forks can reuse
the rings by key image. This avoids revealing the real inputs like
would happen if two forks spent the same outputs with different
rings. This database is meant to be shared with all Monero forks
which don't bother making a new chain, putting users' privacy at
risk in the process. It is placed in a shared data directory by
default ($HOME/.shared-ringdb on UNIX like systems). You may
use --shared-ringdb-dir to override this location, and should
then do so for all Monero forks for them to share the database.
a7266d6d wallet2+cli+rpc: eliminate redundant m_http_client from cli/rpc and delegate calls to wallet2 (stoffu)
71d18656 replace invoke_http_json("/json_rpc",...) with invoke_http_json_rpc("/json_rpc",methodname,...) to reduce boilerplate (stoffu)
4405e4fc wallet2: check_tx_key() shouldn't require hardware encryption (stoffu)
7dfa5e9e chacha: call prehashed version explicitly as generate_chacha_key_prehashed hash: add prehashed version cn_slow_hash_prehashed slow-hash: let cn_slow_hash take 4th parameter for deciding prehashed or not slow-hash: add support for prehashed version for the other 3 platforms (stoffu)
b2d23b18 crypto: revert odd namespace changes made in #3303 (stoffu)
8705beaf keypair::generate: always require hw::device to avoid possible mistake (stoffu)
27a196b1 device: untangle cyclic depenency (stoffu)
c9b38b47 device: made function prototypes consistent with pre-#3303 codebase (stoffu)
hash: add prehashed version cn_slow_hash_prehashed
slow-hash: let cn_slow_hash take 4th parameter for deciding prehashed or not
slow-hash: add support for prehashed version for the other 3 platforms
When #3303 was merged, a cyclic dependency chain was generated:
libdevice <- libcncrypto <- libringct <- libdevice
This was because libdevice needs access to a set of basic crypto operations
implemented in libringct such as scalarmultBase(), while libringct also needs
access to abstracted crypto operations implemented in libdevice such as
ecdhEncode(). To untangle this cyclic dependency chain, this patch splits libringct
into libringct_basic and libringct, where the basic crypto ops previously in
libringct are moved into libringct_basic. The cyclic dependency is now resolved
thanks to this separation:
libcncrypto <- libringct_basic <- libdevice <- libcryptonote_basic <- libringct
This eliminates the need for crypto_device.cpp and rctOps_device.cpp.
Also, many abstracted interfaces of hw::device such as encrypt_payment_id() and
get_subaddress_secret_key() were previously implemented in libcryptonote_basic
(cryptonote_format_utils.cpp) and were then called from hw::core::device_default,
which is odd because libdevice is supposed to be independent of libcryptonote_basic.
Therefore, those functions were moved to device_default.cpp.
91d97dd4 fuzz_tests: set small subaddress lookahead for speed (moneromooo-monero)
5f85cc7e wallet2: guard against overflowing of subaddress indices (moneromooo-monero)
* Removed the db package, as it is not required
* Added the libiconv package
* Updated the boost build instructions (added locale)
* Updated cppzmq to version 4.2.3 which does not require the symlink hack anymore
added missing hashes for boost patches
Fix the way the REAL mode is handle:
Let create_transactions_2 and create_transactions_from construct the vector of transactions.
Then iterate on it and resign.
We just need to add 'outs' list in the TX struct for that.
Fix default secret keys value when DEBUG_HWDEVICE mode is off
The magic value (00...00 for view key and FF..FF for spend key) was not correctly set
when DEBUG_HWDEVICE was off. Both was set to 00...00.
Add sub-address info in ABP map in order to correctly display destination sub-address on device
Fix DEBUG_HWDEVICE mode:
- Fix compilation errors.
- Fix control device init in ledger device.
- Add more log.
Fix sub addr control
Fix debug Info
Previously, a file containing the unencrypted Monero address was
created by default in the wallet's directory. This file might pose
as a privacy risk. The creation of this file is now opt-in and can
be enabled by providing
--create-address-file
In package mingw-w64-x86_64-icu, version 58.2-3, the names of static
library files were changed, which leads to changes in CMakeLists.txt as
needed for compiling for Windows.
- save the new keys file as FOO-watchonly.keys, not FOO.keys-watchonly
- catch any exception (eg, I/O errors) and error out
- print the new keys filename in simplewallet
e136bc6b tweaks to the monerov1 cryptonight algorithm (Lee Clagett)
d58c9ec9 slow-hash: optimized version (SChernykh)
608fd6f1 Monero Cryptonight variants, and add one for v7 (moneromooo-monero)
0e7ad2e2 Wallet API: generalize 'bool testnet' to 'NetworkType nettype' (stoffu)
af773211 Stagenet (stoffu)
cc9a0bee command_line: allow args to depend on more than one args (stoffu)
55f8d917 command_line::get_arg: remove 'required' for dependent args as they're always optional (stoffu)
450306a0 command line: allow has_arg to handle arg_descriptor<bool,false,true> #3318 (stoffu)
9f9e095a Use `genesis_tx` parameter in `generate_genesis_block`. #3261 (Jean Pierre Dudey)
* src/cryptnote_config.h: The constant `config::testnet::GENESIS_TX` was
changed to be the same as `config::GENESIS_TX` (the mainnet's transaction)
because the mainnet's transaction was being used for both networks.
* src/cryptonote_core/cryptonote_tx_utils.cpp: The `generate_genesis_block` function
was ignoring the `genesis_tx` parameter, and instead it was using the `config::GENESIS_TX`
constant. That's why the testnet genesis transaction was changed. Also five lines of unused
code were removed.
Signed-off-by: Jean Pierre Dudey <jeandudey@hotmail.com>
The basic approach it to delegate all sensitive data (master key, secret
ephemeral key, key derivation, ....) and related operations to the device.
As device has low memory, it does not keep itself the values
(except for view/spend keys) but once computed there are encrypted (with AES
are equivalent) and return back to monero-wallet-cli. When they need to be
manipulated by the device, they are decrypted on receive.
Moreover, using the client for storing the value in encrypted form limits
the modification in the client code. Those values are transfered from one
C-structure to another one as previously.
The code modification has been done with the wishes to be open to any
other hardware wallet. To achieve that a C++ class hw::Device has been
introduced. Two initial implementations are provided: the "default", which
remaps all calls to initial Monero code, and the "Ledger", which delegates
all calls to Ledger device.
Boost does not use Sourceforge anymore. Instead, their download links
point to dl.bintray.com.
Earlier today Sourceforge was down, and later the Boost downloaded file
checksum did not match, which further reinforces the need to change
the URL.
The logging to /tmp/bitmonero.daemon.stdout.stderr caused segfaults
if the /tmp mount was full (#2851).
Now the daemon is only logging to /tmp/bitmonero.daemon.stdout.stderr
in the debug builds.
When a block is added as part of a chunk (when syncing historical
blocks), a block may end up already in the blockchain if it was
added to the queue before being added to the chain (though it's
not clear how that could happen, but it's an implementation detail)
and thus may not be added to the chain when add_block is called.
This would cause m_blocks_txs_check to not be cleared, causing it
to get out of sync at next call, and thus wrongfully reject the
next block.
Since commit b0426d4c refresh height for a newly created wallet
connected to a sync'd daemon was off by a month. Now we only use
the 1 month safety margin if we're unable to talk to a daemon.
e4646379 keccak: fix mdlen bounds sanity checking (moneromooo-monero)
2e3e90ac pass large parameters by const ref, not value (moneromooo-monero)
61defd89 blockchain: sanity check number of precomputed hash of hash blocks (moneromooo-monero)
9af6b2d1 ringct: fix infinite loop in unused h2b function (moneromooo-monero)
8cea8d0c simplewallet: double check a new multisig wallet is multisig (moneromooo-monero)
9b98a6ac threadpool: catch exceptions in dtor, to avoid terminate (moneromooo-monero)
24803ed9 blockchain_export: fix buffer overflow in exporter (moneromooo-monero)
f3f7da62 perf_timer: rewrite to make it clear there is no division by zero (moneromooo-monero)
c6ea3df0 performance_tests: remove add_arg call stray extra param (moneromooo-monero)
fa6b4566 fuzz_tests: fix an uninitialized var in setup (moneromooo-monero)
03887f11 keccak: fix sanity check bounds test (moneromooo-monero)
ad11db91 blockchain_db: initialize m_open in base class ctor (moneromooo-monero)
bece67f9 miner: restore std::cout precision after modification (moneromooo-monero)
1aabd14c db_lmdb: check hard fork info drop succeeded (moneromooo-monero)
a99ef176 wallet-rpc: take subaddress account as arg for get_transfer_by_txid (stoffu)
77125096 wallet-rpc: rename *_INDEX_OUTOFBOUND into *_INDEX_OUT_OF_BOUNDS (stoffu)
bc61ae69 tx_pool: add a max pool size, settable with --max-txpool-size (moneromooo-monero)
3b4e6b35 txpool: increase unmined tx expiry to three days (moneromooo-monero)
f90c76be Return appropriate error code when there's no connection to daemon (Michał Sałaban)
3cb65b3f Return appropriate error code when not enough money for tx (Michał Sałaban)
628b78ae Fix in_peers/out_peers RPC operations (Erik de Castro Lopo)
ece9bcf5 rpc_client: Fix error handling (Erik de Castro Lopo)
8f30350d Fix method name in invoke_http_json_rpc (Erik de Castro Lopo)
32c0f908 Allow the number of incoming connections to be limited (Erik de Castro Lopo)
d609a2c1 Rename delete_connections to delete_out_connections (Erik de Castro Lopo)
b927c0fc Rename connections_count to max_out_connection_count (Erik de Castro Lopo)
* src/cryptnote_config.h: The constant `config::testnet::GENESIS_TX` was
changed to be the same as `config::GENESIS_TX` (the mainnet's transaction)
because the mainnet's transaction was being used for both networks.
* src/cryptonote_core/cryptonote_tx_utils.cpp: The `generate_genesis_block` function
was ignoring the `genesis_tx` parameter, and instead it was using the `config::GENESIS_TX`
constant. That's why the testnet genesis transaction was changed. Also five lines of unused
code were removed.
Signed-off-by: Jean Pierre Dudey <jeandudey@hotmail.com>
If an exception is thrown, it is ignored. While this may hide
a bug, this should only be system exceptions in boost, which
is pretty unlikely. Morever, wait should be called manually
before the dtor anyway. Add an error message if the dtor has
to wait in case some such cases creep in so they get fixed.
Coverity 182538
Previously, when outputs_amount == inputs_amount, the "m_overspend" property
was set, whereas "m_fee_too_low" would have been the correct property to set.
This is unlikely to ever occur and just something I've noticed while reading
through the code.
30c44bce wallet: automatically use low priority if safe (no backlog & recent blocks not full) (stoffu)
c903df5e simplewallet: bug fix for backlog estimate (stoffu)
2f5a9b6b wallet2: split estimate_backlog to allow for raw fee levels (moneromooo-monero)
fd1dfac5 p2p: don't lookup seed IPs if using an exclusive peer (moneromooo-monero)
b50182ae p2p: don't connect to seeds if using an exclusive peer (moneromooo-monero)
3160a930 wallet2: remove {set|get}_default_decimal_point and use the same funcs under cryptonote:: instead (stoffu)
7d1088d3 wallet2: make scan_output const and omit keys arg (stoffu)
bc1ee2c2 wallet2: make member functions const when possible (stoffu)
5ae617d5 simplewallet: single out 0 amount destinations as dummy ones (moneromooo-monero)
c1d19f3c wallet2: fix sweep_all sending an atomic unit (moneromooo-monero)
ge_scalarmult_p3
ge_double_scalarmult_precomp_vartime2_p3
ge_double_scalarmult_base_vartime_p3
This makes it possible to reuse the result without having to
convert back to unsigned char[32] and back to ge types.
9996d5e9 wallet2: guard against the dameon sending blocks before last checkpoint (moneromooo-monero)
eadaa6aa wallet_rpc_server: fix wallet leak on error exit (moneromooo-monero)
6d8b29ef fix some link errors in debug mode for macos (stoffu)
fdd4c5e5 move memwipe to epee to avoid common<->crypto circular dependencies (moneromooo-monero)
40ab12a7 epee: remove dependency on common (moneromooo-monero)
On some systems, there is a /usr/bin/lrelease wrapper even if the real
lrelease program is not installed. So let's try to execute lrelease
after it has been found by find_program to see if it is really working.
Define generate_translations_header as an external project to be able
to use the compilation toolchain for the host instead of the toolchain
for the target.
Reset thread-local info if it doesn't match the current env.
Only happens when a process opens/closes env multiple times in the
same process, doesn't affect monerod.
da0fd71d only include the easylogging++ stack trace code when needed (moneromooo-monero)
81b04cfa easlogging++: omit some unneded macros (moneromooo-monero)
Wallet caches and keys files are loaded with chacha8 as needed,
but only saved with chacha20. Other data (eg, cold wallet data
files, etc) will be incompatible.
cb9aa23c levin_protocol_handler_async: another attempt at fixing at exception (moneromooo-monero)
64d23ce3 Revert "epee: keep a ref to a connection we're deleting" (moneromooo-monero)
bd5cce07 network_throttle: fix ineffective locking (moneromooo-monero)
e0a61299 network_throttle: remove unused xxx static member (moneromooo-monero)
24f584d9 cryptonote_core: remove unused functions with off by one bugs (moneromooo-monero)
b1634aa3 blockchain: don't leave dangling pointers in this (moneromooo-monero)
8e60b81c cryptonote_core: fix db leak on error (moneromooo-monero)
213e326c abstract_tcp_server2: log init_server errors as fatal (moneromooo-monero)
b51dc566 use const refs in for loops for non tiny types (moneromooo-monero)
f0568ca6 net_parse_helpers: fix regex error checking (moneromooo-monero)
b49ddc76 check accessing an element past the end of a container (moneromooo-monero)
2305bf26 check return value for generate_key_derivation and derive_public_key (moneromooo-monero)
a4240d9f catch const exceptions (moneromooo-monero)
45a1c4c0 add empty container sanity checks when using front() and back() (moneromooo-monero)
56fa6ce1 tests: fix a buffer overread in a unit test (moneromooo-monero)
b4524892 rpc: guard against json parsing a non object (moneromooo-monero)
c2ed8618 easylogging++: avoid buffer underflow (moneromooo-monero)
187a6ab2 epee: trap failure to parse URI from request (moneromooo-monero)
061789b5 checkpoints: trap failure to load JSON checkpoints (moneromooo-monero)
ba2fefb9 checkpoints: pass std::string by const ref, not const value (moneromooo-monero)
38c8f4e0 mlog: terminate a string at last char, just in case (moneromooo-monero)
d753d716 fix a few leaks by throwing objects, not newed pointers to objects (moneromooo-monero)
fe568db8 p2p: use size_t for arbitrary counters instead of uint8_t (moneromooo-monero)
46d6fa35 cryptonote_protocol: sanity check chain hashes from peer (moneromooo-monero)
25584f86 cryptonote_protocol: print peer versions when unexpected (moneromooo-monero)
490a5d41 rpc: do not try to use an invalid txid in relay_tx (moneromooo-monero)
ca18ff64 wallet2: detect spends in txes without a valid public tx key (moneromooo-monero)
6afcd8e3 cn_deserialize: print tx extra fields in partly decoded tx extra (moneromooo-monero)
Fixes the unit test failure about SHA1 being unavailable,
and hopefully the monerod complaints about not being able
to verify DNSSEC.
Thanks to iDunk for the remote Windows testing.
If a queued job uses a waiter, then we want to run that waiter's
jobs in the current thread if all threads are busy, even if the
queue is empty, since there is no guarantee that any thread will
free up to take care of that new job, since all the threads might
be running a job which spawns such a recursive job and will block
till that recursive job is done, which it will never be since it
relies on the queue being polled by one of those blocked threads.
6c94516f wipeable_string: move a wipe from reserve to grow (moneromooo-monero)
5f801b6a wipeable_string: ignore reserve size less than actual size (moneromooo-monero)
9ec44a2b wipeable_string: fix clear and push_back (moneromooo-monero)
Scheme by luigi1111:
Multisig for RingCT on Monero
2 of 2
User A (coordinator):
Spendkey b,B
Viewkey a,A (shared)
User B:
Spendkey c,C
Viewkey a,A (shared)
Public Address: C+B, A
Both have their own watch only wallet via C+B, a
A will coordinate spending process (though B could easily as well, coordinator is more needed for more participants)
A and B watch for incoming outputs
B creates "half" key images for discovered output D:
I2_D = (Hs(aR)+c) * Hp(D)
B also creates 1.5 random keypairs (one scalar and 2 pubkeys; one on base G and one on base Hp(D)) for each output, storing the scalar(k) (linked to D),
and sending the pubkeys with I2_D.
A also creates "half" key images:
I1_D = (Hs(aR)+b) * Hp(D)
Then I_D = I1_D + I2_D
Having I_D allows A to check spent status of course, but more importantly allows A to actually build a transaction prefix (and thus transaction).
A builds the transaction until most of the way through MLSAG_Gen, adding the 2 pubkeys (per input) provided with I2_D
to his own generated ones where they are needed (secret row L, R).
At this point, A has a mostly completed transaction (but with an invalid/incomplete signature). A sends over the tx and includes r,
which allows B (with the recipient's address) to verify the destination and amount (by reconstructing the stealth address and decoding ecdhInfo).
B then finishes the signature by computing ss[secret_index][0] = ss[secret_index][0] + k - cc[secret_index]*c (secret indices need to be passed as well).
B can then broadcast the tx, or send it back to A for broadcasting. Once B has completed the signing (and verified the tx to be valid), he can add the full I_D
to his cache, allowing him to verify spent status as well.
NOTE:
A and B *must* present key A and B to each other with a valid signature proving they know a and b respectively.
Otherwise, trickery like the following becomes possible:
A creates viewkey a,A, spendkey b,B, and sends a,A,B to B.
B creates a fake key C = zG - B. B sends C back to A.
The combined spendkey C+B then equals zG, allowing B to spend funds at any time!
The signature fixes this, because B does not know a c corresponding to C (and thus can't produce a signature).
2 of 3
User A (coordinator)
Shared viewkey a,A
"spendkey" j,J
User B
"spendkey" k,K
User C
"spendkey" m,M
A collects K and M from B and C
B collects J and M from A and C
C collects J and K from A and B
A computes N = nG, n = Hs(jK)
A computes O = oG, o = Hs(jM)
B anc C compute P = pG, p = Hs(kM) || Hs(mK)
B and C can also compute N and O respectively if they wish to be able to coordinate
Address: N+O+P, A
The rest follows as above. The coordinator possesses 2 of 3 needed keys; he can get the other
needed part of the signature/key images from either of the other two.
Alternatively, if secure communication exists between parties:
A gives j to B
B gives k to C
C gives m to A
Address: J+K+M, A
3 of 3
Identical to 2 of 2, except the coordinator must collect the key images from both of the others.
The transaction must also be passed an additional hop: A -> B -> C (or A -> C -> B), who can then broadcast it
or send it back to A.
N-1 of N
Generally the same as 2 of 3, except participants need to be arranged in a ring to pass their keys around
(using either the secure or insecure method).
For example (ignoring viewkey so letters line up):
[4 of 5]
User: spendkey
A: a
B: b
C: c
D: d
E: e
a -> B, b -> C, c -> D, d -> E, e -> A
Order of signing does not matter, it just must reach n-1 users. A "remaining keys" list must be passed around with
the transaction so the signers know if they should use 1 or both keys.
Collecting key image parts becomes a little messy, but basically every wallet sends over both of their parts with a tag for each.
Thia way the coordinating wallet can keep track of which images have been added and which wallet they come from. Reasoning:
1. The key images must be added only once (coordinator will get key images for key a from both A and B, he must add only one to get the proper key actual key image)
2. The coordinator must keep track of which helper pubkeys came from which wallet (discussed in 2 of 2 section). The coordinator
must choose only one set to use, then include his choice in the "remaining keys" list so the other wallets know which of their keys to use.
You can generalize it further to N-2 of N or even M of N, but I'm not sure there's legitimate demand to justify the complexity. It might
also be straightforward enough to support with minimal changes from N-1 format.
You basically just give each user additional keys for each additional "-1" you desire. N-2 would be 3 keys per user, N-3 4 keys, etc.
The process is somewhat cumbersome:
To create a N/N multisig wallet:
- each participant creates a normal wallet
- each participant runs "prepare_multisig", and sends the resulting string to every other participant
- each participant runs "make_multisig N A B C D...", with N being the threshold and A B C D... being the strings received from other participants (the threshold must currently equal N)
As txes are received, participants' wallets will need to synchronize so that those new outputs may be spent:
- each participant runs "export_multisig FILENAME", and sends the FILENAME file to every other participant
- each participant runs "import_multisig A B C D...", with A B C D... being the filenames received from other participants
Then, a transaction may be initiated:
- one of the participants runs "transfer ADDRESS AMOUNT"
- this partly signed transaction will be written to the "multisig_monero_tx" file
- the initiator sends this file to another participant
- that other participant runs "sign_multisig multisig_monero_tx"
- the resulting transaction is written to the "multisig_monero_tx" file again
- if the threshold was not reached, the file must be sent to another participant, until enough have signed
- the last participant to sign runs "submit_multisig multisig_monero_tx" to relay the transaction to the Monero network
43f5269f Wallets now do not depend on the daemon rpc lib (moneromooo-monero)
bb89ae8b move connection_basic and network_throttle from src/p2p to epee (moneromooo-monero)
4abf25f3 cryptonote_core does not depend on p2p anymore (moneromooo-monero)
Partially implements #74.
Securely erases keys from memory after they are no longer needed. Might have a
performance impact, which I haven't measured (perf measurements aren't
generally reliable on laptops).
Thanks to @stoffu for the suggestion to specialize the pod_to_hex/hex_to_pod
functions. Using overloads + SFINAE instead generalizes it so other types can
be marked as scrubbed without adding more boilerplate.
41fc11fa Scheduled mandatory software upgrades (xmr-eric)
3b5382fe Keep VRP a proper noun (xmr-eric)
7160cbd6 CONTRIBUTING.md capitalization (xmr-eric)
f36ffc07 Shorten a title, remove a section, small edits (xmr-eric)
00179917 Capitalization on first word only (xmr-eric)
6ffae079 Readme.md: Normalize heading capitalization (xmr-eric)
3dffe71b new wipeable_string class to replace std::string passphrases (moneromooo-monero)
7a2a5741 utils: initialize easylogging++ in on_startup (moneromooo-monero)
54950829 use memwipe in a few relevant places (moneromooo-monero)
000666ff add a memwipe function (moneromooo-monero)
If a translation file exists in a "translations" directory located in
the same directory as the binary, it is used in priority (this can be
useful when working on translations as you don't have to recompile the
whole program all the time), and if no such file is found the embedded
translation file is used (if it exists).
This fixes a hang on exit due to race where a connection adds
itself to the server after the starting connections are closed,
but before the net server marks itself as stopped.
Binding RPC to 127.0.0.1 makes no sense. Despite the fact port 18081 is
exposed, no one will be able to connect to the daemon.
RPC should be listening at all interfaces when running inside a Docker
container.
27aa8ce9 net_utils_base: fix peer list parsing (moneromooo-monero)
fe5ab2c4 epee: fix kv_unserialize return value when a field is not found (moneromooo-monero)
Those are not serialized, but are restored from the outPk masks,
so depending on what tries to validate the tx, those commitments
may or may not be filled with valid data at the time. The outPk
masks are already hashed as part of the rctSigBase field.
c83d0b3e add bulletproofs from v7 on testnet (moneromooo-monero)
8620ef0a bulletproofs: switch H/G in Pedersen commitments to match rct (moneromooo-monero)
d58835b2 integrate bulletproofs into monero (moneromooo-monero)
90b8d9f2 add bulletproofs to the build, with basic unit tests (moneromooo-monero)
fe120264 perf_timer: add non scoped start/stop timer defines (moneromooo-monero)
ada42914 add a version of ge_double_scalarmult_precomp_vartime with A precomp (moneromooo-monero)
d43eef6d ringct: add a version of addKeys which returns the result (moneromooo-monero)
7ff07928 sc_mul and sc_muladd (luigi1111)
3d0b54bd epee: add do while(0) around brace statement in a macro (moneromooo-monero)
Deleted 3 out of 4 calls to method connection_basic::sleep_before_packet
that were erroneous / superfluous, which enabled the elimination of a
"fudge" factor of 2.1 in connection_basic::set_rate_up_limit;
also ended the multiplying of limit values and numbers of bytes
transferred by 1024 before handing them over to the global throttle
objects
9739da1e wallet_rpc_server: new relay_tx command (moneromooo-monero)
01dc8297 wallet: transfer RPC can now return tx metadata (pending_tx) (moneromooo-monero)
83fa9047 serialization: add std::set and std::unordered_set serialization (moneromooo-monero)
998777ec Tx proof (revised): - refactoring: proof generation/checking code was moved from simplewallet.cpp to wallet2.cpp - allow an arbitrary message to be signed together with txid - introduce two types (outbound & inbound) of tx proofs; with the same syntax, inbound is selected when <address> belongs to this wallet, outbound otherwise. see GitHub thread for more discussion - wallet RPC: added get_tx_key, check_tx_key, get_tx_proof, check_tx_proof - wallet API: moved WalletManagerImpl::checkPayment to Wallet::checkTxKey, added Wallet::getTxProof/checkTxProof - get_tx_key/check_tx_key: handle additional tx keys by concatenating them into a single string (stoffu)
- refactoring: proof generation/checking code was moved from simplewallet.cpp to wallet2.cpp
- allow an arbitrary message to be signed together with txid
- introduce two types (outbound & inbound) of tx proofs; with the same syntax, inbound is selected when <address> belongs to this wallet, outbound otherwise. see GitHub thread for more discussion
- wallet RPC: added get_tx_key, check_tx_key, get_tx_proof, check_tx_proof
- wallet API: moved WalletManagerImpl::checkPayment to Wallet::checkTxKey, added Wallet::getTxProof/checkTxProof
- get_tx_key/check_tx_key: handle additional tx keys by concatenating them into a single string
0d9c0db9 Do not build against epee_readline if it was not built (Howard Chu)
178014c9 split off readline code into epee_readline (moneromooo-monero)
a9e14a19 link against readline only for monerod and wallet-wallet-{rpc,cli} (moneromooo-monero)
437421ce wallet: move some scoped_message_writer calls from the libs (moneromooo-monero)
e89994e9 wallet: rejig to avoid prompting in wallet2 (moneromooo-monero)
ec5135e5 move input_line from command_line to simplewallet (moneromooo-monero)
082db75f move cryptonote command line options to cryptonote_core (moneromooo-monero)
wallet2 is a library, and should not prompt for stdin. Instead,
pass a function so simplewallet can prompt on stdin, and a GUI
might display a window, etc.
ec48e8d8 core: do not forbid txes without destination (moneromooo-monero)
523084bc core: don't add empty additional pub keys field to extra (moneromooo-monero)
cryptonote::miner::get_system_times(): Fetch the system's total and
idle time using sysctl kern.cp_time.
cryptonote::miner::get_process_time(): Use the same implementation as
Linux and OSX, the times(3) function conforms to POSIX.1 and is
available on FreeBSD.
cryptonote::miner::on_battery_power(): Try to fetch the battery status
using sysctl hw.acpi.acline. If that fails (if ACPI is not enabled on
the system), then try querying /dev/apm.
f3e09f36 hooked a dependency on libatomic on 32 bit machines if Clang is
used because compilation failed with:
`std::__atomic_base<unsigned long long>::load(std::memory_order) const':
/usr/bin/../lib/gcc/i686-pc-linux-gnu/6.1.1/../../../../include/c++/6.1.1/bits/atomic_base.h:396:
undefined reference to `__atomic_load_8'
But that does not happen on FreeBSD. The problem is likely that on Linux
Clang tries to use GCC-provided C++11 library. Further,
__atomic_load_8() (for 8-byte integers) is not readily available on 32
bit machines. From https://gcc.gnu.org/wiki/Atomic/GCCMM: "When lock
free instructions are not available (either through hardware or OS
support) atomic operations are left as function calls to be resolved by
a library."
This patch allows to filter out sensitive information for queries that rely on the pool state, when running in restricted mode.
This filtering is only applied to data sent back to RPC queries. Results of inline commands typed locally in the daemon are not affected.
In practice, when running with `--restricted-rpc`:
* get_transaction_pool will list relayed transactions with the fields "last relayed time" and "received time" set to zero.
* get_transaction_pool will not list transaction that have do_not_relay set to true, and will not list key images that are used only for such transactions
* get_transaction_pool_hashes.bin will not list such transaction
* get_transaction_pool_stats will not count such transactions in any of the aggregated values that are computed
The implementation does not make filtering the default, so developers should be mindful of this if they add new RPC functionality.
Fixes#2590.
Transactions in the txpool are marked when another transaction
is seen double spending one or more of its inputs.
This is then exposed wherever appropriate.
Note that being marked with this "double spend seen" flag does
NOT mean this transaction IS a double spend and will never be
mined: it just means that the network has seen at least another
transaction spending at least one of the same inputs, so care
should be taken to wait for a few confirmations before acting
upon that transaction (ie, mostly of use for merchants wanting
to accept unconfirmed transactions).
ff7745bb Edited test readme for accuracy and depth (Cole Lightfighter)
c300ae56 Added test documentation & Keccak unit test (Cole Lightfighter)
f6119a8e Added test documentation & Keccak unit test (Cole Lightfighter)
d0463312 fix libwallet api test after api change (Jaquee)
a46c1eed Wallet2: Don't throw when subaddress label doesn't exist (Jaquee)
086b7db2 Wallet API: default values for account and subaddr index (Jaquee)
It is safe in those cases, though might return slightly out of date
information if another thread is busy modifying the blockchain,
but it avoids potentially lengthy delays just to get things like
the current blockchain height.
Issue: #2575
Build instructions for OpenBSD 6.2:
* boost (built with clang)
* cppzmq
Fixed a issue, where cmake was not able to find and link against libressl in unbound.
restored OpenBSD 5.8 build instructions
Tests for checking proper error throwing for out-of-bounds subaddress
indexes, and proper addition of subaddresses.
Signed-off-by: Cole Lightfighter <cole@onicsla.bz>
They are actually wrong if the wallet is setup in a different
denomination, and it's incursion of extrinsic lingo where monero
fits perfectly in the first place.
This fixes linking when path to openssl
is defined manually:
cmake -DOPENSSL_ROOT_DIR='/usr/include/openssl-1.0;/usr/lib/openssl-1.0' ...
This is useful for building with OpenSSL v1.0
when default system installation is v1.1.
The linking error is undefined SSL_load_error_strings symbol.
This is due to -L /usr/lib/openssl-1.0 not making it onto
the linkline (so -lssl pulls in the default system openssl).
Fixes compile error when building with OpenSSL v1.1:
contrib/epee/include/net/net_helper.h: In member function ‘void epee::net_utils::blocked_mode_client::shutdown_ssl()’:
contrib/epee/include/net/net_helper.h:579:106: error: ‘SSL_R_SHORT_READ’ was not declared in this scope
if (ec.category() == boost::asio::error::get_ssl_category() && ec.value() != ERR_PACK(ERR_LIB_SSL, 0, SSL_R_SHORT_READ))
^
contrib/epee/include/net/net_helper.h:579:106: note: suggested alternative: ‘SSL_F_SSL_READ’
See boost/asio/ssl/error.hpp.
Boost handles differences between OpenSSL versions.
cmake: fail if Boost is too old for OpenSSL v1.1
default install targets
Binaries available to download on https://getmonero.org/downloads/ as
embedding monerod, monero-wallet-{cli,rpc} and
monero-blockchain-{ex,im}port.
This change synchronise download results with a manual build from
source
22b51e06 db_lmdb: include chain height when failing to find an output key (moneromooo-monero)
5db433b3 blockchain: avoid exceptions in output verification (moneromooo-monero)
dc19659d Remove network_address_base which has been merged with ipv4_network_address in 8b006877 (Michał Sałaban)
2183ade0 Don't try to create wallet-dir when it's not given, don't crash if wallet-dir already exists. (Michał Sałaban)
In practice, this seems to cause monero-wallet-rpc to exit
when ^C quits whatever its output is piped into (such as tee),
but it saves, while it did not before.
The commands handler must not be destroyed before the config
object, or we'll be accessing freed memory.
An earlier attempt at using boost::shared_ptr to control object
lifetime turned out to be very invasive, though would be a
better solution in theory.
This is safer, as we don't risk break expectations (eg, requesting
block hashes and then receiving a late set of blocks). Dropping a
connection means another will be attempted in a fresh state.
Also bump the kick timeout to 5 minutes, to ensure we only kick
really idle peers.
15e62581 connection_context: initialize m_callback_request_count to 0 (moneromooo-monero)
5fa199c6 copyable_atomic: add a ctor with initial value (moneromooo-monero)
8b006877 Upgrades to epee::net_utils::network_address - internal nullptr checks - prevent modifications to network_address (shallow copy issues) - automagically works with any type containing interface functions - removed fnv1a hashing - ipv4_network_address now flattened with no base class (Lee Clagett)
- internal nullptr checks
- prevent modifications to network_address (shallow copy issues)
- automagically works with any type containing interface functions
- removed fnv1a hashing
- ipv4_network_address now flattened with no base class
792ba4f0 Log categories can now be added to and removed from (moneromooo-monero)
48f92eb6 easylogging++: add categories getter (moneromooo-monero)
f35afe62 epee: factor log level/categories setting (moneromooo-monero)
Lack of it results in `m_refresh_from_block_height` being < 0 (18446744...) on low heights, which blocks `process_new_blockchain_entry` and never process coins on heights less than blocks_per_month.
Follow-up to #2258
36c3465b wallet2: do not keep block hashes below last checkpoint (moneromooo-monero)
cdbbe99c checkpoints: add a token checkpoint on testnet (the genesis block) (moneromooo-monero)
493fad80 serialization: add deque serialization (moneromooo-monero)
fa54b205 fix typo in basic and core CMakeLists.txt (moneromooo-monero)
5d65a75b move checkpoints in a separate library (moneromooo-monero)
06a681cf performance_tests: add a test for is_out_to_acc_precomp (moneromooo-monero)
2ec928ba wallet2: simplify tx processing a bit (moneromooo-monero)
740e6533 wallet2: factor some of the tx scanning code (moneromooo-monero)
0aaaca29 tx_pool: set the "invalid input" bit when check_tx_inputs fails (moneromooo-monero)
9236823b simplewallet: print tx rejection reason where it was missing (moneromooo-monero)
3dee3301 core_rpc_server: print tx rejection reason at L0 too (moneromooo-monero)
6137a0b9 blockchain: reject unsorted ins and outs from v7 (moneromooo-monero)
16afab90 core: sort ins and outs key key image and public key, respectively (moneromooo-monero)
0c36b9f9 common: add apply_permutation file and function (moneromooo-monero)
It was always returning true, and could not be foreseen to
usefully return errors in the future. This silences CID 162652
as well as saves some checking code in a few places.
a15e8583 wallet2: guard against daemon sending txes in the wrong order (moneromooo-monero)
8fe5f609 rpc: order transactions in the order they were requested (moneromooo-monero)
Warning issued on older boost and/or OS:
In file included from /usr/include/boost/asio/detail/socket_types.hpp:61:0,
from /usr/include/boost/asio/detail/epoll_reactor.hpp:30,
from /usr/include/boost/asio/detail/reactor.hpp:21,
from /usr/include/boost/asio/detail/impl/task_io_service.ipp:24,
from /usr/include/boost/asio/detail/task_io_service.hpp:198,
from /usr/include/boost/asio/impl/io_service.hpp:71,
from /usr/include/boost/asio/io_service.hpp:767,
from /usr/include/boost/asio/basic_io_object.hpp:19,
from /usr/include/boost/asio/basic_socket.hpp:20,
from /usr/include/boost/asio/basic_datagram_socket.hpp:20,
from /usr/include/boost/asio.hpp:21,
from /home/vagrant/slave/monero-static-alpine-3_5-x86_64/build/src/common/download.cpp:32:
/usr/include/sys/poll.h:1:2: warning: #warning redirecting incorrect #include <sys/poll.h> to <poll.h> [-Wcpp]
#warning redirecting incorrect #include <sys/poll.h> to <poll.h>
Setting COMPILE_FLAGS (or COMPILE_OPTIONS) property directly does not
end up on the command line (even though it should because
add_compile_options does just that).
Also, set -Werror for tests as well, because no warnings now.
Not set for 'external' only because simply moving add_compile_options
above add_subdirectory(external) doesn't do it, and moving add_usbdirectory
down is too big of a change (it will pick up new flags).
-Werror set only for GCC on Linux, since warnings not yet
cleared for other compilers/systems.
ef005f5e p2p: add a couple early outs when the stop signal is received (moneromooo-monero)
80d361c7 abstract_tcp_server2: improve tracking/cancelling of early connections (moneromooo-monero)
9cad4981 readme.me again, fixed v2 fork info on table (Gingeropolous)
8f68291d README.md - update info for first fork (Gingeropolous)
43813327 README.md - update fork table with fork height (Gingeropolous)
0e7e307c update hardfork table with height and version info (Gingeropolous)
close might end up dropping a ref, ending up removing the
connection from m_connects, as the lock is recursive. This'd
cause an out of bounds exception and kill the idle connection
maker thread
87f58974 Docs: C4 revisions as discussed in #2174 (anonimal)
84d25d25 Docs: C4 development process addendum (anonimal)
e022c4e9 Docs: add C4 to contributing guide (anonimal)
0299cb77 Fix various oversights/bugs in ZMQ RPC server code (Thomas Winget)
77986023 json serialization for rpc-relevant monero types (Thomas Winget)
5c1e08fe Refactor some things into more composable (smaller) functions (Thomas Winget)
9ac2ad07 DRY refactoring (Thomas Winget)
And optimize import startup:
Remember start_height position during initial count_blocks pass
to avoid having to reread entire file again to arrive at start_height
The last known hash was calculated incorrectly, causing
further chain hash downloads to restart from the current
chain. When the block queue has close to 10k blocks waiting,
this causes frequent downloads of 10k more hashes, but
with only the last few hashes actually being useful.
It is unused, as it was apparently a future optimization,
and it leaks some information (though since pools publish
thei blocks they find, that amount seems small).
- Add some RPC commands (and touch up a couple others)
- some bounds checking
- some better pointer management
- const correctness and error handling
-- Thanks @vtnerd for type help with serialization and CMake changes
Structured {de-,}serialization methods for (many new) types
which are used for requests or responses in the RPC.
New types include RPC requests and responses, and structs which compose
types within those.
# Conflicts:
# src/cryptonote_core/blockchain.cpp
This commit refactors some of the rpc-related functions in the
Blockchain class to be more composable. This change was made
in order to make implementing the new zmq rpc easier without
trampling on the old rpc.
New functions:
Blockchain::get_num_mature_outputs
Blockchain::get_random_outputs
Blockchain::get_output_key
Blockchain::get_output_key_mask_unlocked
Blockchain::find_blockchain_supplement (overload)
functions which previously had this functionality inline now call these
functions as necessary.
This might prevent some calls to terminate when the LockedTXN
dtor is called as part of stack unwinding caused by another
exception in the first place.
4e0e4e99 blockchain_import: warn for chunks over 500000, not 100000 (moneromooo-monero)
5b29e87f blockchain_import: properly cleanup core/db on exit (moneromooo-monero)
e167c4d9 blockchain_import: do not error out on truncated files (moneromooo-monero)
c867357a cryptonote_protocol: error handling on cleanup_handle_incoming_blocks (moneromooo-monero)
ce901fcb Fix blockchain_import wedge on exception in cleanup_handle_incoming_blocks (moneromooo-monero)
84fa015e core: guard against exceptions in handle_incoming_{block,tx} (moneromooo-monero)
3d19ab70 Revert "Cleanup test impact of moving blockchain_db_types()" (Howard Chu)
a95e460c move db specific options to BlockchainDB (moneromooo-monero)
d58700e0 WalletAPI: only allow trusted daemon when importing key images (Jaquee)
8a9bbd26 WalletAPI: copy wallet data when creating a view only wallet (Jaquee)
d27fe32e wallet2: export/import wallet data functions (Jaquee)
225a25f3 import_key_images - allow importing without being connected to daemon (Jaquee)
5807529e blockchain: cap memory size of retrieved blocks (moneromooo-monero)
c1b10381 rpc: decrease memory usage a bit in getblocks.bin (moneromooo-monero)
3dd34a49 Cleanup test impact of moving blockchain_db_types() (Howard Chu)
80344740 More DB support cleanup (Howard Chu)
4c7f8ac0 DB cleanup (Howard Chu)
f906d87e wallet: new option to check/confirm txpool backlog when sending (moneromooo-monero)
55bec1f0 rpc: add a new RPC to get current txpool backlog (sizes and fees) (moneromooo-monero)
df0cffed cryptonote_protocol: warn if we see a higher top version we expect (moneromooo-monero)
317ab21a cryptonote_protocol: less strict check on top version on connect (moneromooo-monero)
cc81a371 cryptonote_protocol: update target height when syncing too (moneromooo-monero)
e2ad372b cryptonote_protocol: simplify and remove unnecessary casts (moneromooo-monero)
727e67ca cryptonote_protocol: print peer top height along with its version (moneromooo-monero)
b5345ef4 crypto: use malloc instead of alloca (moneromooo-monero)
80794b31 thread_group: set thread size to THREAD_STACK_SIZE (moneromooo-monero)
5524bc31 print peer id in 0 padded hex for consistency (moneromooo-monero)
8f8cc09b contrib: add sync_info to rlwrap command set (moneromooo-monero)
70b8c6d7 cryptonote_protocol: misc fixes to the new sync algorithm (moneromooo-monero)
64ab8844 rpc_client: print destination host/port when failing to connect (moneromooo-monero)
333f7012 http_client: add getters for host and port (moneromooo-monero)
Fix sync wedge corner case:
It could happen if a connection went into standby mode, while
it was the one which had requested the next span, and that span
was still waiting for the data, and that peer is not on the
main chain. Other peers can then start asking for that data
again and again, but never get it as only that forked peer does.
And various other fixes
If monerod is started with default sync mode, set it to SAFE after
synchronization completes. Set it back to FAST if synchronization
restarts (e.g. because another peer has a longer blockchain).
If monerod is started with an explicit sync mode, none of this
automation takes effect.
Hide DB types from db_types.h - no reason to recompile dependencies
when DB types change.
Also remove lingering in-memory DB references, they've been
obsolete since 9e82b694da
We don't actually need to keep them past the call to start, as this
adds them to the config object list, and so they'll then be cancelled
already when the stop signal arrives. This allows removing the periodic
call to cleanup connections.
e499ff33 simplewallet: factor out message_writer (moneromooo-monero)
7ed5ab47 scoped_message_writer: pause readline to match simplewallet (moneromooo-monero)
359517c7 wallet_rpc_server: fix possible privacy leak in on_import_key_images() (Jaquee)
20495b27 simplewallet: fix possible privacy leak in import_key_images() (Jaquee)
71e28760 debug_utilities: only build for debug builds (moneromooo-monero)
55e150ff debug_utilities: new object-sizes debug tool (moneromooo-monero)
fbaf5375 cn_deserialize: move to new debug_utilities subdirectory (moneromooo-monero)
b7d6ec83 simplewallet: add (out of sync) or (no daemon) markers in the prompt (moneromooo-monero)
fa23a500 wallet2: add a is_synced function (moneromooo-monero)
f1307bbd node_rpc_proxy: add a proxy for target height (moneromooo-monero)
5d4ef719 core: speed up output index unique set calculation (moneromooo-monero)
19d7f568 perf_timer: allow profiling more granular than millisecond (moneromooo-monero)
bda8c598 epee: add nanosecond timer and pause/restart profiling macros (moneromooo-monero)
35e01a6e cryptonote_protocol: fix "holes" in block download schedule (moneromooo-monero)
3da1edfd cryptonote_protocol: fix out of order addition (moneromooo-monero)
6edb1b3e block_queue: do not add empty spans (moneromooo-monero)
This was broken by the reorg fix, since we now have to add blocks
regardless of their starting height. We now check whether we know
the parent for the first block in the next span, or whether it was
requested. If neither, it's an orphan. If it is not known, but was
requested, we wait to get that block.
Add get_fork_version and add_ideal_fork_version to core so
cryptonote_protocol does not have to need the Blockchain
class directly, as it's not in its dependencies, and add
those to the fake core classes in tests too.
When a node is dropped, we stop considering its claimed blockchain
height as a factor in the target height calculation. This prevents
a runaway chain from being still thought to be the target even if
the nodes carrying it are dropped.
635929ea protocol: add checks for top block hard fork version (moneromooo-monero)
7482253a epee: fixup KV_SERIALIZE_OPT to work in more cases (moneromooo-monero)
We won't even talk to a peer which claims a wrong version
for its top block. This will avoid syncing to known bad
peers in the first place.
Also add IP fails when failing to verify a block.
With the new sync algorithm, the network overhead will be masked
as the thread adding blocks isn't interrupted by network calls
anymore. This should reduce memory usage a lot during sync.
c93b7692 blockchain_import: much faster when verifying with cryptonote::core (moneromooo-monero)
38756d00 core: new API to disable DNS checkpoint lookups (moneromooo-monero)
Quick test with the first 56569 blocks from mainnet
version verify batch time
old 0 200 1:16
new 0 200 0:57
old 0 5000 0:53
new 0 5000 0:51
old 1 200 est > 1h
new 1 200 10:21
old 1 5000 est > 1h
new 1 5000 8:27
dc0b312f wallet_rpc_server: optionally return tx blobs on transfer calls (moneromooo-monero)
5eb79983 epee: add a KV_SERIALIZE variant for optional parameters (moneromooo-monero)
Connections can be dropped by the net_node layer,
unbeknownst to cryptonote_protocol, which would then
not flush any spans scheduled to that connection,
which would cause it to be only downloaded again
once it becomes the next span (possibly after a small
delay if it had been requested less than 5 seconds
ago).
A block queue is now placed between block download and
block processing. Blocks are now requested only from one
peer (unless starved).
Includes a new sync_info coommand.
When scanning the txpool without having first updated the
blockchain, the tx would be seen as neither in the txpool
nor the chain, and removed, so it'd only reappear once the
chain is refreshed, and the tx seen in a block.
A sort+uniq step was done for every tx in a 200 block chunk,
causing a lot of repeated scanning as the size of the offset
map got larger with every added tx. We now do the step only
once at the end of the loop.
Doing it this way potentially uses more memory, but testing
shows that it's currently only about 2% more.
Nanosecond timer precision won't work on Windows, but we don't
care since I'm using that just for profiling incremental code
paths, but a Windows coder is welcome to add it if there's a way.
The version of miniupnpc in external/ uses API version 16, but the
code also seems to work for API version 10. Also remove detection
of older unsupported versions.
Asks user for all the data required to merge secret keys from multisig wallets into one master wallet, which then gets full control of the multisig wallet. The resulting wallet will be the same as any other regular wallet.
If the number of blocks to check was not a multiple of the
number of preparation threads, the last few blocks would
not be included in the threaded long hash calculation.
Those would still get calculated when the block gets added
to the chain, however, so this was only a tiny performance
hit, rather than a security bug.
This avoids having to include p2p_protocol_defs.h in util.h,
as util.h is used a lot, and p2p_protocol_defs.h includes
a lot of other things that most users don't need.
Library code should definitely not ask for console input unless
it's clearly an input function. Delegating the user interaction
part to the caller means it can now be used by a GUI, or have a
decision algorithm better adapted to a particular caller.
They used to be sorted by amount, which was fine before rct,
but is now suboptimal, since amounts are not known anymore.
In particular, it would give a recipient knowledge of whether
change was higher or lower than the amount received.
This was the case for monero-wallet-cli already, but not for
monerod, which was making it pretty spammy as it was duplicating
intended output. Since my original intent was to ensure logs
included command output for debugging, this achieves both.
02d66db4 tx_pool: initialize padding in txpool meta structure (moneromooo-monero)
0722aea3 cryptonote_core: initialize checkpoint flag (moneromooo-monero)
3b599d2b wallet2: get current height from the daemon on creation (moneromooo-monero)
d3bb72ff wallet2: fix infinite loop on future refresh height (moneromooo-monero)
32754784 wallet: fix refresh_from_height setting on new wallet (moneromooo-monero)
76043b17 monero-wallet-cli: hang on exit in readline code (#2117) (moneromooo-monero)
a73a42a6 monero-wallet-cli: hang on exit in readline code (#2117) (moneromooo-monero)
be9d4f04 Fix multiline wallet cli output with readline (Jethro Grassie)
readline_buffer: fix start/stop threads being starved by process
process could run for quite some time re-acquiring the process
lock, leaving start/stop starving. Yielding after unlock in
process is much better but doesn't seem to be enough to reliably
yield, so we sleep for a millisecond, which should be transparent
for user input anyway.
Signed-off-by: Jethro Grassie <jtg@xtrabass.com>
If the refresh height is in the future, the current code will
loop till the actual height reaches this. Fix it by bailing out
if we receive only three hashes, which is what we set in the
call parameters.
The previous patch was based on a wrong premise (that the
daemon height was 0 because the daemon calling code wasn't
yet initialized). In fact, current height approximation
was not setup for testnet. Fix this.
monero-wallet-cli commands which have multine output sometimes causes
issues with the readline support. This patch fixes show_transfers,
payments and incoming_transfers.
Existing tests: block, transaction, signature, cold outputs,
cold transaction.
Data for these is in tests/data/fuzz.
A convenience shell script is in contrib/fuzz_testing/fuzz.sh, eg:
contrib/fuzz_testing/fuzz.sh signature
The fuzzer will run indefinitely, ^C to stop.
Fuzzing is currently supported for GCC only. I can't get CLANG
to build Monero here as it dies on some system headers, so if
someone wants to make it work on both, that'd be great.
In particular, the __AFL_LOOP construct should be made to work
so that a given run can fuzz multiple inputs, as the C++ load
time is substantial.
07c4276c Don't issue a new timedsync while one is already in progress (Howard Chu)
cf3a376c Don't timeout a slow operation that's making progress (Howard Chu)
340830de Fix PR#2039 (Howard Chu)
d5f1cef7 simplewallet: removed unneeded LOCK_IDLE_SCOPE() from check_tx_key() (stoffu)
8df918f8 simplewallet: replace assert(m_wallet) with error out (stoffu)
8da82256 crypto: moved boost::lock_guard into a smaller scope (stoffu)
c9e0e944 Signature proving payment to destination by only revealing key derivation, not the actual tx secret key (stoffu)
It'd eat up a core constantly, due to spending its time jumping
back and forth between userland and kernel. We now wait for up
to a millisecond in kernel, which will be transparent to the user
and drop to idle most of the time.
This PR adds readline support to the daemon and monero-wallet-cli. Only
GNU readline is supported (e.g. not libedit) and there are cmake checks
to ensure this.
There is a cmake variable, Readline_ROOT_DIR that can specify a
directory to find readline, otherwise some default paths are searched.
There is also a cmake option, USE_READLINE, that defaults to ON. If set
to ON, if readline is not found, the build continues but without
readline support.
One negative side effect of using readline is that the color prompt in
the wallet-cli now has no color and just uses terminal default. I know
how to fix this but it's quite a big change so will tackle another time.
These files were pulled from the 1.6.3 release tarball.
This new version builds against OpenSSL version 1.1 which will be
the default in the new Debian Stable which is due to be released
RealSoonNow (tm).
A timedsync is issued every minute on a connection, but the input
tineout is 2 minutes. This means a new sync request could be issued
while a slow sync request was already in progress. The additional
request will further clog the network on a slow connection, and
cause a premature timeout.
Add fail-fast paths that reduce frustration around the misuse of
--wallet-file combined with --restore-deterministic-wallet. Flow now
gives more descriptive errors and avoids having users type in their
whole seed before the failure condition is noticed.
e2529347 Correct spelling of 'get_upper_transaction_size_limit' (Nano Akron)
3029d0ef Remove the 1.25x multiplier in max transaction size in just the wallet (Nano Akron)
With the recent change to wallet creation code, the code was
calling to the daemon before the wallet's daemon address was
initialized, and thus failing. This was causing all new wallets
to refresh from 0 instead of just fetching early block hashes.
All code which was using ip and port now uses a new IPv4 object,
subclass of a new network_address class. This will allow easy
addition of I2P addresses later (and also IPv6, etc).
Both old style and new style peer lists are now sent in the P2P
protocol, which is inefficient but allows peers using both
codebases to talk to each other. This will be removed in the
future. No other subclasses than IPv4 exist yet.
12fff108 Change Old_English to English_Old - 'Old English' is actually a language (Nano Akron)
533187f0 Change all wallet language names into native names (and scripts) (Nano Akron)
It sweeps all outputs below the given threshold
This is available via the existing sweep_all RPC, by setting
amount_threshold the desired amount (in atomic units)
a6d5bb75 wallet2: refer to triangular distribution for recent zone in comment (moneromooo-monero)
ac1aba90 wallet2: bias fake outs more towards recent outputs (moneromooo-monero)
aa02ff7f mv "Contributing" above install, compile, etc (Mike C)
a55bb375 Add link to CONTRIBUTING to README.md (Mike C)
09bbf96d Grouping CONTRIBUTING into digestable sections (Mike C)
dc35c736 Rename CONTRIBUTING to CONTRIBUTING.md (Mike C)
This avoids error spews from easylogging++ when we try to log
something before easylogging is initialized, which can happen
when errors happen at command line parsing time
It was wrongly refering to equiprobable distribution, which I think
I'd originally done, but forgot to update the comment after changing
to triangular
Reported by smooth on IRC
Two recent papers quantified the real usage bias for the
real output in a ring being the true one, and shows that
the current biasing is much too weak.
While we wait for a better solution, we increase the ratio
of recent-to-total fake outputs, as well as decrease the
time window for recent outputs, so that half the fake outs
are selected within the last 1.8 day. Value plucked from
figure 10, page 11 of An Empirical Analysis of Linkability
in the Monero Blockchain, 2017, Miller et al.
This is also arbitrary, of course, but serves as a stopgap
till a better selection algorithm is chosen.
EVP_dss1() was deprecated and EVP_sha1() is the direct replacement.
Upstream libunbound already has this patch. Note that I haven't
added a test for HAVE_EVP_DSS1 since that was deprecated quite a
long time ago in OpenSSL, there's really no reason to support it.
- Performance improvements
- Added `span` for zero-copy pointer+length arguments
- Added `std::ostream` overload for direct writing to output buffers
- Removal of unused `string_tools::buff_to_hex`
eb20f720 daemon: print average fee per byte in print_pool_stats (moneromooo-monero)
37be70bb daemon: add fee/byte when print pool transaction info (moneromooo-monero)
893f5a30 tx_pool: add blob size and fee/byte when logging a new tx (moneromooo-monero)
0ee018b4 wallet2: do not go over the target tx size if many destinations (moneromooo-monero)
9ae566d0 simplewallet: fix cold signing of split transactions (moneromooo-monero)
aae14a10 simplewallet: allow setting confirm-missing-payment-id in watch wallets (moneromooo-monero)
a28950da setThreadName moved in new version of easylogging++ (moneromooo-monero)
ea359b50 Fixup choice of easylogging++ vs libunwind stack trace code (moneromooo-monero)
1e6d8757 easylogging++: do not disable DEBUG level based on _DEBUG/NDEBUG (moneromooo-monero)
7a56fd6c easylogging++: detect DragonFly BSD as a UNIX (moneromooo-monero)
2c8b23e3 easylogging++: fix logging with static const header only data members (moneromooo-monero)
72663f4b easylogging++: allow clipping a common filename prefix (moneromooo-monero)
5bab0449 easylogging++: add file-only logs (moneromooo-monero)
db9dc7c2 eayslogging++: Fix bad memory access before opening any files (moneromooo-monero)
14620ca0 easylogging++: avoid creating directory/filename for the builtin default log file (moneromooo-monero)
0c1ad0ff easylogging++: Print thread ID in a nicer way (moneromooo-monero)
e7fabbd4 easylogging++: add categories (moneromooo-monero)
a8ac4f0a update easylogging++ to latest upstream (moneromooo-monero)
The section on contributing to the Monero project is buried deep below lots of other information in the main README. This PR moves that section (which is very small since it links to a different document) up to an easier to locate place just below License information.
If using a large input and many destinations, the code would
generate as many outputs as it could using that input, even if
it would bring the resulting tx above the max tx size.
They'd be rejected as suspicious as the change goes to more
than one destination. However, split transactions will most
likely include fake zero amount change to random addresses,
so we only consider change with non zero amount for this.
Because some people just won't even try to read what is written
and freak out because the word FATAL is in here, despite the
context making it clear it's not an error.
- 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 [ -z "$NO_DEPENDS" ]; then $DOCKER_EXEC bash -c "CONFIG_SHELL= make $MAKEJOBS -C contrib/depends HOST=$HOST $DEP_OPTS"; fi
message(FATAL_ERROR"Submodules not up to date. Please update with git submodule init && git submodule update, or run cmake with -DMANUAL_SUBMODULES=1")
A good way to help is to test, and report bugs. See
[How to Report Bugs Effectively (by Simon Tatham)](https://www.chiark.greenend.org.uk/~sgtatham/bugs.html)
if you want to help that way. Testing is invaluable in making a piece
of software solid and usable.
## General guidelines
* Comments are encouraged.
* If modifying code for which Doxygen headers exist, that header must be modified to match.
* Tests would be nice to have if you're adding functionality.
Patches are preferably to be sent via a Github pull request. If that
can't be done, patches in "git format-patch" format can be sent
(eg, posted to fpaste.org with a long enough timeout and a link
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.
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,
both patches should be merged).
If you've made random unrelated changes (either because your editor
is annoying or you made them for other reasons), you can select
what changes go into the coming commit using git add -p, which
walks you through all the changes and asks whether or not to
include this particular change. This helps create clean patches
without any irrelevant changes. git diff will show you the changes
in your tree. git diff --cached will show what is currently staged
for commit. As you add hunks with git add -p, those hunks will
"move" from the git diff output to the git diff --cached output,
so you can see clearly what your commit is going to look like.
## Commits and pull requests
Commit messages should be sensible. That means a subject line that
describes the patch, with an optional longer body that gives details,
documentation, etc.
When submitting a pull request on Github, make sure your branch is
rebased. No merge commits nor stray commits from other people in
your submitted branch, please. You may be asked to rebase if there
are conflicts (even trivially resolvable ones).
PGP signing commits is strongly encouraged. That should explain why
the previous paragraph is here.
# [Code of Conduct (22/C4.1)](http://rfc.zeromq.org/spec:22)
## License
Copyright (c) 2009-2015 Pieter Hintjens.
Copyright (c) 2017-2018 The Monero Project.
This Specification is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 3 of the License, or (at your option) any later version.
This Specification is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.
You should have received a copy of the GNU General Public License along with this program; if not, see <http://www.gnu.org/licenses>.
## Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.
The "Monero Maintainer Team" is defined in this document as the following users:
- fluffypony
- moneromooo
- hyc
## Goals
C4 is meant to provide a reusable optimal collaboration model for open source software projects. It has these specific goals:
- To maximize the scale and diversity of the community around a project, by reducing the friction for new Contributors and creating a scaled participation model with strong positive feedbacks;
- To relieve dependencies on key individuals by separating different skill sets so that there is a larger pool of competence in any required domain;
- To allow the project to develop faster and more accurately, by increasing the diversity of the decision making process;
- To support the natural life cycle of project versions from experimental through to stable, by allowing safe experimentation, rapid failure, and isolation of stable code;
- To reduce the internal complexity of project repositories, thus making it easier for Contributors to participate and reducing the scope for error;
- To enforce collective ownership of the project, which increases economic incentive to Contributors and reduces the risk of hijack by hostile entities.
## Design
### 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.
- 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.
### 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.
### Patch requirements
- Maintainers MUST have a Platform account and SHOULD use their real names or a well-known alias.
- Contributors SHOULD have a Platform account and MAY use their real names or a well-known alias.
- 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 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.
- 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.
- 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.
- 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 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.
- Maintainers SHOULD ask for improvements to incorrect patches and SHOULD reject incorrect patches if the Contributor does not respond constructively.
- Any Contributor who has value judgments on a correct patch SHOULD express these via their own patches.
- Maintainers MAY commit changes to non-source documentation directly to the project.
### 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.
- 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.
### Evolution of public contracts
- All Public Contracts (APIs or protocols) SHALL 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.
- 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.
- 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.
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.
### Tools for translators
In order to create, update or build translations files, you need to have Qt tools installed. For translating, you need either the **Qt Linguist GUI** ([part of Qt Creator](https://www.qt.io/download) or a [3rd-party standalone version](https://github.com/lelegard/qtlinguist-installers/releases)), or another tool that supports Qt ts files, such as Transifex. The files are XML, so they can be edited in any plain text editor if needed.
### Creating / modifying translations
You do not need anything from Qt in order to use the final translations.
To add new translatable strings in the source code:
Use the `tr(string)` function if possible. If the code is in a class, and this class doesn't already have a `tr()` static function, add one, which uses a context named after what `lupdate` uses for the context, usually the fully qualified class name (eg, `cryptonote::simple_wallet`). If you need to use `tr()` in code that's not in a class, you can use the fully qualified version (eg, `simple_wallet::tr`) of the one matching the context you want. Use `QT_TRANSLATE_NOOP(string)` if you want to specify a context manually.
If you're getting messages of the form:
Class 'cryptonote::simple_wallet' lacks Q_OBJECT macro
- We are also available via [HackerOne](https://hackerone.com/monero)
## Announcements
- 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.
## Build
### 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.
@@ -44,35 +58,31 @@ 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.
## About this Project
## 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.
As with many development projects, the repository on Github is considered to be the "staging" area for the latest changes. Before changes are merged into that branch on the main repository, they are tested by individual developers in their own branches, submitted as a pull request, and then subsequently tested by contributors who focus on testing and code reviews. That having been said, the repository should be carefully considered before using it in a production environment, unless there is a patch in the repository for a particular show-stopping issue you are experiencing. It is generally a better idea to use a tagged release for stability.
**Anyone is welcome to contribute to Monero's codebase!** If you have a fix or code change, feel free to submit is as a pull request directly to the "master" branch. In cases where the change is relatively small or does not affect other parts of the codebase it may be merged in immediately by any one of the collaborators. On the other hand, if the change is particularly large or complex, it is expected that it will be discussed at length either well in advance of the pull request being submitted, or even directly on the pull request.
**Anyone is welcome to contribute to Monero's codebase!** If you have a fix or code change, feel free to submit it as a pull request directly to the "master" branch. In cases where the change is relatively small or does not affect other parts of the codebase it may be merged in immediately by any one of the collaborators. On the other hand, if the change is particularly large or complex, it is expected that it will be discussed at length either well in advance of the pull request being submitted, or even directly on the pull request.
## Supporting the Project
## Supporting the project
Monero development can be supported directly through donations.
Both Monero and Bitcoin donations can be made to donate.getmonero.org if using a client that supports the [OpenAlias](https://openalias.org) standard
Monero is a 100% community-sponsored endeavor. If you want to join our efforts, the easiest thing you can do is support the project financially. Both Monero and Bitcoin donations can be made to **donate.getmonero.org** if using a client that supports the [OpenAlias](https://openalias.org) standard. Alternatively you can send XMR to the Monero donation address via the `donate` command (type `help` in the command-line wallet for details).
The Monero donation address is: `44AFFq5kSiGBoZ4NMDwYtN18obc8AemS33DBLWs3H7otXft3XjrpDtQGv7SqSsaBYBb98uNbr2VBBEt7f2wfn3RVGQBEP3A` (viewkey: `f359631075708155cc3d92a32b75a7d02a5dcf27756707b47a2b31b21c389501`)
The Bitcoin donation address is: `1KTexdemPdxSBcG55heUuTjDRYqbC5ZL8H`
*Note: you can easily donate XMR to the Monero donation address by using the `donate` command. Type `help` in the command-line wallet for details.*
Core development funding and/or some supporting services are also graciously provided by sponsors:
There are also several mining pools that kindly donate a portion of their fees, [a list of them can be found on our Bitcointalk post](https://bitcointalk.org/index.php?topic=583449.0).
@@ -80,49 +90,40 @@ There are also several mining pools that kindly donate a portion of their fees,
Monero uses a fixed-schedule hard fork mechanism to implement new features. This means that users of Monero (end users and service providers) need to run current versions and update their software on a regular schedule. Here is the current schedule, versions, and compatibility.
If you want to help out, see [CONTRIBUTING](CONTRIBUTING.md) for a set of guidelines.
## 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.
| Fork Date | Consensus version | Minimum Monero Version | Recommended Monero Version | Details |
| 1788000 | 2019-03-09 | v10 | v0.14.0.0 | v0.14.0.0 | 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.0.0 | forbid old RingCT transaction format
## Installing Monero from a Package
X's indicate that these details have not been determined as of commit date.
Packages are available for
## Release staging schedule and protocol
* Arch Linux (via [AUR](https://aur.archlinux.org/)):
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.
* OS X via [Homebrew](http://brew.sh)
brew tap sammy007/cryptonight
brew install monero --build-from-source
* Docker
docker build -t monero .
# either run in foreground
docker run -it -v /monero/chain:/root/.bitmonero -v /monero/wallet:/wallet -p 18080:18080 monero
| expat | 1.1 | NO | `libexpat1-dev` | `expat` | `expat-devel` | YES | XML parsing |
| GTest | 1.5 | YES | `libgtest-dev`^ | `gtest` | `gtest-devel` | YES | Test suite |
| Doxygen | any | NO | `doxygen` | `doxygen` | `doxygen` | YES | Documentation |
| Graphviz | any | NO | `graphviz` | `graphviz` | `graphviz` | YES | Documentation |
[^] 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/ ```
Monero uses the CMake build system and a top-level [Makefile](Makefile) that
@@ -159,9 +177,10 @@ invokes cmake commands as needed.
#### On Linux and OS X
* Install the dependencies
* Change to the root of the source code directory and build:
* Change to the root of the source code directory, change to the most recent release branch, and build:
cd monero
git checkout v0.14.0.1
make
*Optional*: If your machine has several cores and enough memory, enable
@@ -169,6 +188,15 @@ invokes cmake commands as needed.
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
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.
* The resulting executables can be found in `build/release/bin`
* Add `PATH="$PATH:$HOME/monero/build/release/bin"` to `.profile`
@@ -179,7 +207,7 @@ invokes cmake commands as needed.
make release-test
*NOTE*: `coretests` test may take a few hours to complete.
*NOTE*: `core_tests` test may take a few hours to complete.
* **Optional**: to build binaries suitable for debugging:
@@ -189,17 +217,19 @@ invokes cmake commands as needed.
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
#### On the Raspberry Pi
Tested on a Raspberry Pi 2 with a clean install of minimal Debian Jessie from https://www.raspberrypi.org/downloads/raspbian/
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 except libunwind and libboost-all-dev
* Install the dependencies for Monero from the 'Debian' column in the table above.
* Increase the system swap size:
```
@@ -208,27 +238,17 @@ Tested on a Raspberry Pi 2 with a clean install of minimal Debian Jessie from ht
CONF_SWAPSIZE=1024
sudo /etc/init.d/dphys-swapfile start
```
* 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):
* Clone monero and checkout most recent release version:
* Change to the root of the source code directory and build:
cd monero
make release
* Wait ~4 hours
```
* Wait 4-6 hours
* The resulting executables can be found in `build/release/bin`
@@ -238,17 +258,49 @@ Tested on a Raspberry Pi 2 with a clean install of minimal Debian Jessie from ht
* You may wish to reduce the size of the swap file after the build has finished, and delete the boost directory from your home directory
#### *Note for Raspbian Jessie users:*
If you are using the older Raspbian Jessie image, compiling Monero is a bit more complicated. The version of Boost available in the Debian Jessie repositories is too old to use with Monero, and thus you must compile a newer version yourself. The following explains the extra steps, and has been tested on a Raspberry Pi 2 with a clean install of minimal Raspbian Jessie.
* 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
```
* 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
```
* 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.
#### On Windows:
Binaries for Windows are built on Windows using the MinGW toolchain within
[MSYS2 environment](http://msys2.github.io). The MSYS2 environment emulates a
[MSYS2 environment](https://www.msys2.org). The MSYS2 environment emulates a
POSIX system. The toolchain runs within the environment and *cross-compiles*
binaries that can run outside of the environment as a regular Windows
application.
**Preparing the Build Environment**
**Preparing the build environment**
* Download and install the [MSYS2 installer](http://msys2.github.io), either the 64-bit or the 32-bit package, depending on your system.
* Download and install the [MSYS2 installer](https://www.msys2.org), either the 64-bit or the 32-bit package, depending on your system.
* Open the MSYS shell via the `MSYS2 Shell` shortcut
* Update packages using pacman:
@@ -265,18 +317,32 @@ application.
To build for 64-bit Windows:
pacman -S mingw-w64-x86_64-toolchain make mingw-w64-x86_64-cmake mingw-w64-x86_64-boost
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
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
running 64-bit Windows, you will have both 64-bit and 32-bit MinGW shells.
* 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.0.1'. If you dont care about the version and just want binaries from master, skip this step:
git checkout v0.14.0.1
* If you are on a 64-bit system, run:
make release-static-win64
@@ -287,6 +353,16 @@ application.
* 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
* **Optional**: to build Windows binaries suitable for debugging on a 32-bit system, run:
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`.
@@ -295,9 +371,11 @@ We expect to add Monero into the ports tree in the near future, which will aid i
### On OpenBSD:
#### OpenBSD < 6.2
This has been tested on OpenBSD 5.8.
You will need to add a few packages to your system. `pkg_add db cmake gcc gcc-libs g++ miniupnpc gtest`.
You will need to add a few packages to your system. `pkg_add db cmake gcc gcc-libs g++ gtest`.
The doxygen and graphviz packages are optional and require the xbase set.
@@ -308,18 +386,172 @@ 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`
### Building Portable Statically Linked Binaries
#### OpenBSD >= 6.2
You will need to add a few packages to your system. `pkg_add cmake zeromq libiconv`.
The doxygen and graphviz packages are optional and require the xbase set.
Build the Boost library using clang. This guide is derived from: https://github.com/bitcoin/bitcoin/blob/master/doc/build-openbsd.md
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)
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:
* ```make release-static-64``` builds binaries on Linux on x86_64 portable across POSIX systems on x86_64 processors
* ```make release-static-32``` builds binaries on Linux on x86_64 or i686 portable across POSIX systems on i686 processors
* ```make release-static-armv8``` builds binaries on Linux portable across POSIX systems on armv8 processors
* ```make release-static-armv7``` builds binaries on Linux portable across POSIX systems on armv7 processors
* ```make release-static-armv6``` builds binaries on Linux portable across POSIX systems on armv6 processors
* ```make release-static-linux-x86_64``` builds binaries on Linux on x86_64 portable across POSIX systems on x86_64 processors
* ```make release-static-linux-i686``` builds binaries on Linux on x86_64 or i686 portable across POSIX systems on i686 processors
* ```make release-static-linux-armv8``` builds binaries on Linux portable across POSIX systems on armv8 processors
* ```make release-static-linux-armv7``` builds binaries on Linux portable across POSIX systems on armv7 processors
* ```make release-static-linux-armv6``` builds binaries on Linux portable across POSIX systems on armv6 processors
* ```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
## 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.**
Packages are available for
* Ubuntu and [snap supported](https://snapcraft.io/docs/core/install) systems, via a community contributed build.
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.
* Arch Linux (via [AUR](https://aur.archlinux.org/)):
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
@@ -350,43 +582,51 @@ monero-wallet-cli, and possibly monerod, if you get crashes refreshing.
## Internationalization
See README.i18n
See [README.i18n.md](README.i18n.md).
## Using Tor
While Monero isn't made to integrate with Tor, it can be used wrapped with torsocks, if you add --p2p-bind-ip 127.0.0.1 to the monerod command line. You also want to set DNS requests to go over TCP, so they'll be routed through Tor, by setting DNS_PUBLIC=tcp. You may also disable IGD (UPnP port forwarding negotiation), which is pointless with Tor. To allow local connections from the wallet, you might have to add TORSOCKS_ALLOW_INBOUND=1, some OSes need it and some don't. Example:
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:
TAILS ships with a very restrictive set of firewall rules. Therefore, you need to add a rule to allow this connection too, in addition to telling torsocks to allow inbound connections. Full example:
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.
While monerod and monero-wallet-cli do not use readline directly, most of the functionality can be obtained by running them via rlwrap. This allows command recall, edit capabilities, etc. It does not give autocompletion without an extra completion file, however. To use rlwrap, simply prepend `rlwrap` to the command line, eg:
Note: rlwrap will save things like your seed and private keys, if you supply them on prompt. You may want to not use rlwrap when you use simplewallet to restore from seed, etc.
# Contributing
If you want to help out, see CONTRIBUTING for a set of guidelines.
# Debugging
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
### 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.
@@ -406,9 +646,11 @@ Type `thread apply all bt` within gdb in order to obtain the stack trace
Enter `ulimit -c unlimited` on the command line to enable unlimited filesizes for core dumps
Enter `echo core | sudo tee /proc/sys/kernel/core_pattern` to stop cores from being hijacked by other tools
Run the build.
When it terminates with an output along the lines of "Segmentation fault (core dumped)", there should be a core dump file in the same directory as monerod.
When it terminates with an output along the lines of "Segmentation fault (core dumped)", there should be a core dump file in the same directory as monerod. It may be named just `core`, or `core.xxxx` with numbers appended.
You can now analyse this core dump with `gdb` as follows:
@@ -424,13 +666,23 @@ Pass command-line options with `--args` followed by the relevant arguments
Type `run` to run monerod
## Analysing Memory Corruption
### Analysing memory corruption
We use the tool `valgrind` for this.
There are two tools available:
Run with `valgrind /path/to/monerod`. It will be slow.
* ASAN
## LMDB
Configure Monero with the -D SANITIZE=ON cmake flag, eg:
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
Install valgrind and run as `valgrind /path/to/monerod`. It will be very slow.
### LMDB
Instructions for debugging suspected blockchain corruption as per @HYC
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.
