Deferencing the result of `std::max_element()` when `res.connections` has 0 elements leads to UB, and segfaults in practice.
Co-authored-by: iamamyth <user@example.com>
Bug was introduced in c069c04ede, before this txpool additions were not notified on block addition
When receiving blocks with previously unknown conditions, miner data was sent first, but txpool add events for already-added transactions in previous block were sent afterward. Miners would then include already-mined transactions in their new templates due to receiving the mistimed txpool add event.
The fix is to send miner notifications AFTER txpool events are sent, and before normal block notifications are sent (for mining switch speed purposes)
Fixes c069c04ede / #9135
Fixes dfee15eee1 / #7891
A reorg can end up causing an output's position in the chain to
move. Since the wallet doesn't update the RingDB on reorg, it
may refer to the output's stale position in the chain.
This seems a reasonable solution rather than introducing complex
logic to update the stale ring member's value on rerog, since
RingDB can be deprecated with FCMP++.
- Make sure to mark identified spends in the pool as spends. The
wallet might not know these have been spent if it wasn't the wallet
that relayed the tx to the daemon, or the wallet was cleared via
rescan_bc.
- Make sure to add spends to m_unconfirmed_txs if not present.
- Make sure to process the entire pool again if refreshing for
the first time. The wallet fetches pool and blocks at the same
time. The wallet scans blocks first, then pool. If the wallet
identifies received outputs in the chain, then it may have spent
those received outputs in the pool. So we make sure to re-process
the entire pool again after scanning the chain for the first time.
- Multisig wallets that know about spent key images can now detect
spend txs in the pool. Update tests for that.
Fix four issues with wallet_keys_unlocker:
1. It won't decrypt if there are unlockers open simulataneously on multiple `wallet2` instances
2. It won't decrypt if the first unlocker was disabled (i.e. `locked=false`), even with a second non-disabled unlocker
3. If a destructor of an earlier unlocker is triggered before the destructor of a later unlocker, it will re-encrypt too early, while the second unlocker is still in scope
4. Calling the 3-parameter constructor with `locked=true` after an unlocker already exists will "double-encrypt" the spend key after its destructor since the local variable is `locked=false` and the field member is `locked=true`
Also, replace `wallet2::decrypt_account_for_multisig` with `wallet_keys_unlocker`.
The `while` loop condition was incorrect, which could lead to incomplete imports.
Also, setting `start` to an *undone* output speeds up the test by 16s on my machine.
fpaste.org has been seized by someone else and now links to a spam website, replaced it w/ a stable and reputable alternative (gnu.cat)
CONTRIBUTING.md: replace paste service
removed gnu.cat
added paste.debian.org
based on community usage and familiarity with the debian paste service
When building on Ubuntu 22.04 with GCC 11.4.0 and Boost 1.89.0.beta1,
the build failed with:
```
error: ‘floor’ was not declared in this scope
41 | num_char = (int)floor((float)num_char / (float)radix);
| ^~~~~
```
Signed-off-by: Michael Cho <michael@michaelcho.dev>
Since current behavior on release is to ban clients with too
high a height included in the request, it seems reasonably
justified to modify that behavior to instead return a successful
response that includes the chain height and top block hash.
Adds documentation that outlines the OSS-Fuzz integration of Monero. The
goal is to make it more accessible to build/test/expand the existing
fuzz suite, and also to make it more visible that this integration
exists.
Signed-off-by: David Korczynski <david@adalogics.com>
Rings for outgoing transactions are stored within the scanning code since the last hardfork,
so this code is largely unneccessary now.
Co-authored-by: j-berman <justinberman@protonmail.com>
If `crypto::cn_slow_hash()` is called with `variant=1` and an input length of less thab 43 bytes, it triggers a program exit.
This checks first and throws an exception instead.
Thank you to ADA Logics and the MAGIC Monero Fund for reporting this!
Because of the missing `return` statement, the status is set to "OK" later on in the method when it shouldn't be.
Thank you to ADA Logics and the MAGIC Monero Fund for reporting this!
4c341da BlockchainLMDB: remove `virtual` qualifers from overriden methods and mark `final` (jeffro256)
deb1ec9 BlockchainLMDB: mark overridden methods with `override` (jeffro256)
69345db wallet2: use nearest checkpoint to allow fast_refresh on old accounts (Oscar Mira)
edc447e checkpoints: support nearest lower checkpoint lookup (Oscar Mira)
The commit kills support for deprecated ephemeral Boost messages: signed/unsigned transaction sets, pending transactions, reserve proofs, MMS messages, etc.
It does NOT kill support for loading very old wallets in Boost format, that should be supported indefinitely. These messages were deprecated 5 years ago. Since
then, we have had a hard fork to enable a new non-compatible transaction type (w/ view tags), and disable the old transaction type. This renders basically all
of the aforementioned messages before that HF useless, with the possible exception of reserve proofs.
This commit also cleans up dead inclusions of boost serialization headers.
This commit is part of upstreaming Carrot/FCMP++. Killing support for Boost messages now means less boilerplate Boost serialization review for Carrot/FCMP++.
`libringct` was linking against `libcryptonote_basic` for a single, one-line convenience function: `cryptonote::get_blob_hash`.
Since `cryptonote_basic.h` includes `rctTypes.h`, this one function effectively made an explicit circular dependency between
the two libraries. `cryptonote_format_utils.cpp` was including header `rctSigs.h` from `libringct`, when only `rctOps.h` from
`libringct_basic` needed to be included. `libcryptonote_basic` wasn't explictly linking against `libringct_basic` nor
`libringct` like it should have. And `libblockchain_db` wasn't linking against `libcryptonote_basic` like it should have. We
can also downgrade `libblockchain_db`'s dependency on `libringct` to `libringct_basic`.
a. `critical_section` is functionally identical to a `boost::recursive_mutex`
b. `critical_region_t` is functionally identical to a `boost::unique_lock`
c. remove some vestigial definitons `g_test_dbg_lock_sleep` as a variable
Use a fixed, 240s deadline for the daemons to reach agreement and poll
with a suitable frequency (.25s), rather than polling up to 100 times at
roughly 10s intervals.
Assume the terminal supports color codes if TERM ends with `-color` or
`-256color`, rather than special-casing a handful of such terminals.
Add tests for terminal color detection.
Co-authored-by: laanwj <126646+laanwj@users.noreply.github.com>
Changes the `operator[]` method so we can get mutable
references to elements even if the span is `const`.
The operator is now also `constexpr`.
This behavior matches `std::span`.
C++ standard reference: https://en.cppreference.com/w/cpp/container/span/operator_at
I can't see how this would trigger in the current codebase, so it's not a *current* safety issue,
but I can very well see it becoming on in the future if downstream code doesn't handle the passing
of pruned transactions correctly. I think the safe/good choice would be to remove this skip now
that all transactions that pass into the mempool are supposed to be unpruned. And for all in-block
txs, `check_tx_inputs()` isn't called for checkpointed blocks, and we sync pruned blocks only if
syncing checkpointed blocks.
The upstream version of el::base::TypedConfigurations::unsafeGetConfigByRef
accesses uninitialized memory if a key doesn't exist.
Commit b2c59af84d patched the library to
throw in this case, avoiding the invalid access, but the more suitable
pattern, both logically, and as evidenced by the behavior of
unsafeGetConfigByVal, would be to return a const reference to a
default-initialized value with static storage duration.
Reduce the likelihood of false positive failures in the p2p
transaction propagation functional test by waiting up to a
maximum timeout for a transaction to propagate, rather than using a
fixed timeout, to reflect the random delay of Dandelion++ transaction
propagation. This strategy also speeds test execution in cases where
propagation occurs faster than the previously expected fixed delay.
* Use a global startup timeout, and apply it to each socket's connect
call, rather than repeating connection attempts with short timeouts.
* Avoid leaking sockets by closing them.
Reduce bloat in the python RPC Response class by making better use of
superclass methods and recursion. As part of this change, add tests for
the Response class.
Correct the unit tests for tools::is_hdd to avoid making assumptions
about the configuration of a particular device based solely on the
value of the __GLIBC__ preprocessor flag. Instead, rely on the
test invoker to provide paths for devices of specific types via
the process environment, thereby avoiding faulty assumptions and
improving the specificity of test assertions. To ensure appropriate
devices exist, add a script, tests/create_test_disks.sh, which
configures loopback devices mirroring relevant configurations.
Dynamically determine an appropriate number of make jobs for the GitHub
runner container, based upon the number of available CPU cores and RAM,
using the rule that each job requires a dedicated core and 2.25GiB of RAM.
Replace all calls to epee::file_io::get_file_size with
boost::filesystem::file_size in order to avoid lossy conversions from
paths to strings, which tend to break filename resolution. This commit
fixes a bug on Windows where the get_info RPC call reported a zero
database size because BlockchainLMBD::get_database_size returned zero.
Get height of the RingCT fork to start the output distributuon programmatically, instead of using a hardcoded index.
If using a hardcoded index, when the hardfork tables are modified, this can cause segmentation faults or horrific privacy issues: https://codeberg.org/wownero/wownero/issues/488#issuecomment-2514880.
The RSA-MD licensed implementation that originated from RFC 1321 and got
into epee via Cyrus SASL and libEtPan! is not a good fit for epee, which
also links to the GPL licensed readline. RSA-MD has an advertisement
clause that is known to be incompatible with GPL.
@SyntheticBird45 reported that the OpenBSD compiler gives warnings about string functions used in `oaes_sprintf`,
as well as use of `rand()` in `oaes_key_gen`. Neither of these functions are used in the codebase. Removing the
unused OAES functions silences these warnings.
1. Use `std::is_standard_layout` and `std::is_trivially_copyable` instead of `std::is_pod` for KV byte-wise serialization, which fixes compile issue for Boost UUIDs
2. Use `std::has_unique_object_representations` instead of `alignof(T) == 1` for epee byte spans and epee hex functions
3. Removed reimplementation of `std::hash` for `boost::uuids::uuid
4. Removed `<<` operator overload for `crypto::secret_key`
5. Removed instances in code where private view key was dumped to the log in plaintext
This PR is upstreaming changes in the Seraphis lib here: https://github.com/UkoeHB/monero/pull/39. The changes to the serialization header allow clean passing
of extra arguments to field serialization in the DSL. This is used mainly to pass implied sizes of containers during deserialization to make the format more
compact. For example, if my object has two containers A & B which must be the same size, I can serialize only the size of container A. Then, during
deserialization, when I deserialize A, I can then use A's size to deserialize B.
Depends on #9286.
This PR is upstreaming changes in the Seraphis lib here: https://github.com/UkoeHB/monero/pull/39. This header adds a macro `VA_ARGS_COMMAPREFIX`
which, when passed `__VA_ARGS__`, expands to `, __VA_ARGS__` unless the length of `__VA_ARGS__` is 0, in which case it expands to nothing. This
macro is useful for passing/declaring optional function arguments.
When using a relative path for the log filename,
since the iteration on files adds "./" to the beginning of the filename
monero-wallet-rpc and monero-wallet-cli cannot find already written
log files and therefore rotate indefinitely.
Behavior before: when start_height > chain tip, response fails
Behavior after: when req.high_height_ok is true && req.start_height
> chain tip, server rerturns a successful response that includes
chain height
On Linux Mint 21.3, g++ Ubuntu 11.4.0-1ubuntu1~22.04, I get linking error for an undefined reference to `epee::string_tools::trim_right`. This PR reverts the changes
to epee_readline.cpp in commit c56ee140, which turns a `boost::trim_right` callsite into an `epee::string_tools::trim_right` callsite.
- When background syncing, the wallet wipes the spend key
from memory and processes all new transactions. The wallet saves
all receives, spends, and "plausible" spends of receives the
wallet does not know key images for.
- When background sync disabled, the wallet processes all
background synced txs and then clears the background sync cache.
- Adding "plausible" spends to the background sync cache ensures
that the wallet does not need to query the daemon to see if any
received outputs were spent while background sync was enabled.
This would harm privacy especially for users of 3rd party daemons.
- To enable the feature in the CLI wallet, the user can set
background-sync to reuse-wallet-password or
custom-background-password and the wallet automatically syncs in
the background when the wallet locks, then processes all
background synced txs when the wallet is unlocked.
- The custom-background-password option enables the user to
open a distinct background wallet that only has a view key saved
and can be opened/closed/synced separately from the main wallet.
When the main wallet opens, it processes the background wallet's
cache.
- To enable the feature in the RPC wallet, there is a new
`/setup_background_sync` endpoint.
- HW, multsig and view-only wallets cannot background sync.
c56ee14 Cleanup string_tools. 1. Use boost::filesystem for already available operations. 2. Use boost::string for already available operations. (0xFFFC0000)
a46b6ba contrib: add more valgrind suppressions for spurious issues (moneromooo-monero)
7f3e31d unit_tests: fix accessing invalid memory in tree_hash test (moneromooo-monero)
Instead of hard-coding all missing key images into the code and inserting if missing,
we simply pop all blocks after height 202611. This makes the `monerod` binary about
0.35% smaller.
This PR is upstreaming changes in the Seraphis lib here: https://github.com/UkoeHB/monero/pull/39. This header adds a macro `VA_ARGS_COMMAPREFIX`
which, when passed `__VA_ARGS__`, expands to `, __VA_ARGS__` unless the length of `__VA_ARGS__` is 0, in which case it expands to nothing. This
macro is useful for passing/declaring optional function arguments.
Looks like the logic from #8882 was accidentally removed in #8861
(regressing to the behavior noted in the #8882 description).
This commit brings that logic back.
Test:
1. Can't login to RPC server with --rpc-login enabled, but no auth provided
2. Can access RPC server with correct login
3. Can use internal HTTP client to access RPC server with correct login
With commit 0ae5c91e50 not reverted, we fail test 3.
There is currently no compiler protection when someone tries to
do (for example) `BLOB_SERIALIZER(std::vector<int>)`. You just
get runtime allocation errors. This has already eaten up dev time
before, so this PR adds a static assertion that the type must be
trivially copyable, as defined by the C++ standard. Types can
override this if applicable if they use `BLOB_SERIALIZER_FORCED`.
- Removed `localhost:8080` default value to address string in wallet rpc
- Added an error response in case string is empty
fixed indentation
removed if and errors, default to localhost and port based on nettype
Forgot ":"
forgot ; and m_
removed wallet_rpc_server_error_codes.h
- Fixed undefined behavior after a call to `remove_tx_from_transient_lists` (it used an invalid iterator)
- Fixed `txCompare` (it wasn't strictly weak ordered)
std::sort is unstable, so it can return random sets of transactions when mempool has many transactions with the same fee/byte. It can result in p2pool mining empty blocks sometimes because it doesn't pick up "new" transactions immediately.
Related to https://github.com/monero-project/research-lab/issues/78
Added a relay rule that enforces the `unlock_time` field is equal to 0 for non-coinbase transactions.
UIs changed:
* Removed `locked_transfer` and `locked_sweep_all` commands from `monero-wallet-cli`
APIs changed:
* Removed `unlock_time` parameters from `wallet2` transfer methods
* Wallet RPC transfer endpoints send error codes when requested unlock time is not 0
* Removed `unlock_time` parameters from `construct_tx*` cryptonote core functions
Example usage for Seraphis types (in global or `sp` namespace):
```
BEGIN_SERIALIZE_OBJECT_FN(sp::SpCoinbaseEnoteCore)
FIELD_F(onetime_address)
VARINT_FIELD_F(amount)
END_SERIALIZE()
BEGIN_SERIALIZE_OBJECT_FN(sp::SpEnoteCore)
FIELD_F(onetime_address)
FIELD_F(amount_commitment)
END_SERIALIZE()
```
To transfer ~5 XMR to an address such that your balance drops by exactly 5 XMR, provide a `subtractfeefrom` flag to the `transfer` command. For example:
transfer 76bDHojqFYiFCCYYtzTveJ8oFtmpNp3X1TgV2oKP7rHmZyFK1RvyE4r8vsJzf7SyNohMnbKT9wbcD3XUTgsZLX8LU5JBCfm 5 subtractfeefrom=all
If my walet balance was exactly 30 XMR before this transaction, it will be exactly 25 XMR afterwards and the destination address will receive slightly
less than 5 XMR. You can manually select which destinations fund the transaction fee and which ones do not by providing the destination index.
For example:
transfer 75sr8AAr... 3 74M7W4eg... 4 7AbWqDZ6... 5 subtractfeefrom=0,2
This will drop your balance by exactly 12 XMR including fees and will spread the fee cost proportionally (3:5 ratio) over destinations with addresses
`75sr8AAr...` and `7AbWqDZ6...`, respectively.
Disclaimer: This feature was paid for by @LocalMonero.
1. Daemon-specific proxy is exclusive with global proxy (--proxy).
2. If you set global proxy (--proxy) you cannot set daemon-specific proxy.
3. If you don't set global proxy, you can set proxy (or not set) proxy for
each daemon connection with the proxy field in jsonrpc to the wallet-rpc.
430b102 Cleanup scoped_ptr in src/common/dns_utils.cpp and header include: * No need for entire new class (Fix#8732). * Fix stdint.h header include in contrib/epee/include/net/http_base.h. (0xFFFC0000)
The files are exact copies from the original repository (git://git.savannah.gnu.org/config.git),
in commit 28ea239c53a2d5d8800c472bc2452eaa16e37af2. The main reason for the update is because
loongarch was mentioned in PR #9114 and new the latest config files handle loongarch,
as well as WASM64, since the old files only cover WASM32. Tandem NSX and IA16, are also handled
in the newest config files, which covers the changes TheCharlatan made in 2018.
The test node_server.bind_same_p2p_port fails by default on OpenBSD
for at least the debug build. Using the same ifconfig command as
described for MacOS results in the test passing.
Some downstream code (most notably PR https://github.com/UkoeHB/monero/pull/25) wants to use the src/serialization lib
for storing information persistently. When one builds classes/machines wishing to serialize containers, they must use
the `serializable_*` container classes. In this case, this makes the Seraphis library code unnecessarily tightly coupled
with the src/serialization code since one cannot swap out their type of storage format without major refactoring of class
field types. By serializing STL containers directly, we can abstract the serialization details away, making for much
cleaner design. Also small bonus side effect of this change is that STL containers with custom Comparators, Allocators,
and Hashers are serializable. `std::multimap` is added to the list of serializable containers.
Depends upon https://github.com/monero-project/monero/pull/9069.
b4491c1 cmake: set -fno-aligned-allocation on macOS ARM (selsta)
df9f380 cmake: set BOOST_NO_AUTO_PTR to fix c++17 compilation (selsta)
5136974 device: boost -> std locks to fix c++17 compilation (selsta)
5965b02 cmake: set cpp17 standard (selsta)
Multisig keys per-transfer were being wiped, but not erased, which lead to a ginormous
quadratic bloat the more transfers and exports you performed with the wallet.
Since we are required to check for uniqueness of decoy picks within any given
ring, and since some decoy picks may fail due to unlock time or malformed EC points,
the wallet2 decoy selection code was building up a larger than needed *unique* set of
decoys for each ring according to a certain distribution *without replacement*. After
filtering out the outputs that it couldn't use, it chooses from the remaining decoys
uniformly random *without replacement*.
The problem with this is that the picks later in the picking process are not independent
from the picks earlier in the picking process, and the later picks do not follow the
intended decoy distribution as closely as the earlier picks. To understand this
intuitively, imagine that you have 1023 marbles. You label 512 marbles with the letter A,
label 256 with the letter B, so on and so forth, finally labelling one marble with the
letter J. You put them all into a bag, shake it well, and pick 8 marbles from the bag,
but everytime you pick a marble of a certain letter, you remove all the other marbles
from that bag with the same letter. That very first pick, the odds of picking a certain
marble are exactly how you would expect: you are twice as likely to pick A as you are B,
twice as likely to pick B as you are C, etc. However, on the second pick, the odds of
getting the first pick are 0%, and the chances for everything else is higher. As you go
down the line, your picked marbles will have letters that are increasingly more unlikely
to pick if you hadn't remove the other marbles. In other words, the distribution of the
later marbles will be more "skewed" in comparison to your original distribution of marbles.
In Monero's decoy selection, this same statistical effect applies. It is not as dramatic
since the distribution is not so steep, and we have more unique values to choose from,
but the effect *is* measureable. Because of the protocol rules, we cannot have duplicate
ring members, so unless that restriction is removed, we will never have perfectly
independent picking. However, since the earlier picks are less affected by this
statistical effect, the workaround that this commit offers is to store the order that
the outputs were picked and commit to this order after fetching output information over RPC.
bb33daa add a test for the long term weight cache (Boog900)
65839b5 Fix: long term block weight cache The long term block weight cache was doing a wrong calculation when adding a new block to the cache. (Boog900)
- passphrase logic: remove backward compatibility for 2.4.3, code cleanup.
- fix LibUSB cmake for static builds on OSX
- tests: all tests now work with passphrase logic enabled. Passphrase test added with different passphrase. no_passphrase test added, Trezor pin test added. Testing wallet opening with correct and incorrect passphrase. Trezor test chain revamp, cleanup. Smaller chain, chain file versioning added.
- tests: Trezor tests support TEST_MINING_ENABLED, TEST_MINING_TIMEOUT env vars to change mining-related tests behaviour.
- requires protobuf@21 on osx for now (c++14), building with unlinked protobuf: `CMAKE_PREFIX_PATH=$(find /opt/homebrew/Cellar/protobuf@21 -maxdepth 1 -type d -name "21.*" -print -quit) \
make debug-test-trezor -j8`
- fix tx create from sources, input locking. Originally, creating a synthetic transactions with chaingen could create a transaction with outputs that are still locked in the current block, thus failing chain validation by the daemon. Simple unlock check was added. Some buggy tests were fixed as well as new unlock-checking version of tx creation rejected those, fixes are simple - mostly using correct block after a rewind to construct a transaction
The Monero GUI code was calling `Monero::wallet::setPassword()` on every open/close for some reason,
and the old `store_to()` code called `store_keys()` with `watch_only=false`, even for watch-only wallets.
This caused a bug where the watch-only keys file got saved with with the JSON field `watch_only` set to 0,
and after saving a watch-only wallet once, a user could never open it back up against because `load()` errored out.
This never got brought up before this because you would have to change the file location of the watch-only
wallet to see this bug, and I guess that didn't happen often, but calling the new `store_to()` function with the
new `force_rewrite` parameter set to `true` triggers key restoring and the bug appeared.
Resolves#8932 and:
2. Not storing cache when new path is different from old in `store_to()` and
3. Detecting same path when new path contains entire string of old path in `store_to()` and
4. Changing your password / decrypting your keys (in this method or others) and providing a bad original password and getting no error and
5. Changing your password and storing to a new file
ffbf9f4 blockchain_and_pool: move to crytonote_core and enforce its usage (jeffro256)
d6f86e5 Avoid nullptr dereference when constructing Blockchain and tx_memory_pool (lukas)
Read more about k-anonymity [here](https://en.wikipedia.org/wiki/K-anonymity). We implement this feature in the monero daemon for transactions
by providing a "Txid Template", which is simply a txid with all but `num_matching_bits` bits zeroed out, and the number `num_matching_bits`. We add an operation to `BlockchainLMDB` called
`get_txids_loose` which takes a txid template and returns all txids in the database (chain and mempool) that satisfy that template. Thus, a client can
ask about a specific transaction from a daemon without revealing the exact transaction they are inquiring about. The client can control the statistical
chance that other TXIDs (besides the one in question) match the txid template sent to the daemon up to a power of 2. For example, if a client sets their `num_matching_bits`
to 5, then statistically any txid has a 1/(2^5) chance to match. With `num_matching_bits`=10, there is a 1/(2^10) chance, so on and so forth.
Co-authored-by: ACK-J <60232273+ACK-J@users.noreply.github.com>
Removed version 2 onion addresses as they're deprecated from TOR and updated I2P/Tor Stream Used Twice section to reference tweets relevant to section.
Fixed grammatical errors and changed the wording within the Wallet RPC section to better explain the differences between a I2P hidden service and a TOR hidden service.
ea053b6 Update tests/hash/main.cpp (0xFFFC0000)
6bae913 Tests: Add blake2b Test Cases for hash testing. * Adding blake2b test function to src/tests/hash * New files for testvector. * Adding the test to CMakeLists.txt * Adding brief documentation for the test. (0xFFFC0000)
All the files in src/platform are currently unused and unnecessary. See below:
* `mingw/alloca.h`: unused throughout project
* `msc/sys/param.h`:
1. In `fix_darwin.patch`, `sys/param.h` is well-defined to be used only in OpenBSD environment
2. `int-util.h` already handles when `sys/param.h` is not present and injects its own values
3. `db_drivers/liblmdb/mdb.c` is a similar situation: already explicity handles different platforms
4. `src/crypto/chacha.h` uses `int-util.h` for endianness context
* `msc/alloca.h`: unused
* `msc/inline_c.h`: not needed. the `inline` keyword is supported for C99 I believe, and certainly for C11, C14+
* `msc/stdbool.h`: `stdbool.h` is standard since C99, and MSVC has supported it for a long time (~10 years)
eeda4a8 wallet2: do not lose exception in current thread on refresh (Crypto City
f868768 wallet2: fix missing exceptions from failing wallet refresh (Crypto City)
- Detach & re-process txs >= lowest scan height
- ensures that if a user calls scan_tx(tx1) after scanning tx2,
the wallet correctly processes tx1 and tx2
- if a user provides a tx with a height higher than the wallet's
last scanned height, the wallet will scan starting from that tx's
height
- scan_tx requires trusted daemon iff need to re-process existing
txs: in addition to querying a daemon for txids, if a user
provides a txid of a tx with height *lower* than any *already*
scanned txs in the wallet, then the wallet will also query the
daemon for all the *higher* txs as well. This is likely
unexpected behavior to a caller, and so to protect a caller from
revealing txid's to an untrusted daemon in an unexpected way,
require the daemon be trusted.
Before this change, if a multisig peer asked you to sign a transaction with a frozen enote, the wallet will do it without any error or warning. This change makes it
so that wallets will refuse to sign multisig transactions with frozen enotes.
Disclaimer: This PR was generously funded by @LocalMonero.
* Adding blake2b test function to src/tests/hash
* New files for testvector.
* Adding the test to CMakeLists.txt
* Adding brief documentation for the test.
All Monero binaries have 1 second startup delay because of this code. This is especially noticeable and affects UX in Monero GUI wallet with local node where it often starts another monerod instance to run commands and query node status.
Ensures both transfers and sweeps use a fee that's calculated
from the tx's weight. Using different logic could theoretically
enable distinguishability between the two types of txs. We don't
want that.
The gamma picker and the caller code did not quite agree on the
number of rct outputs available for use - by one block - which
caused an infinite loop if the picker could never pick outputs
from that block but already had picked all other outputs from
previous blocks.
Also change the range to select from using code from UkoeHB.
It's not allowed to use WaitForSingleObject with _beginthread, because the thread closes its own handle before exiting.
So the wait function will either wait on an invalid handle, or on a different handle used by something else.
Or, if it starts waiting before the thread exits, the behavior is undefined according to MS: "If this handle is closed while the wait is still pending, the function's behavior is undefined."
In my test sync I observed threads getting stuck infinitely on WaitForSingleObject, and then rx_set_main_seedhash spamming new threads when RandomX seed changes again. Eventually the system ran out of resources, and monerod aborted with "Couldn't start RandomX seed thread" message.
This PR fixes it by using `_beginthreadex` instead and explicitly closing the handle when it's safe.
d7a81cc p2p: do not log to global when re-blocking a subnet (moneromooo-monero)
d84a0d7 p2p: avoid spam blocking ipv4 addresses in a blocked subnet (moneromooo-monero)
c4af33e Enforce restricted # pool txs served via RPC + optimize chunked reqs (j-berman)
9752116 wallet2, RPC: Optimize RPC calls for periodic refresh from 3 down to 1 call (rbrunner7)
- `/getblocks.bin` respects the `RESTRICTED_TX_COUNT` (=100) when
returning pool txs via a restricted RPC daemon.
- A restricted RPC daemon includes a max of `RESTRICTED_TX_COUNT` txs
in the `added_pool_txs` field, and returns any remaining pool hashes
in the `remaining_added_pool_txids` field. The client then requests
the remaining txs via `/gettransactions` in chunks.
- `/gettransactions` no longer does expensive no-ops for ALL pool txs
if the client requests a subset of pool txs. Instead it searches for
the txs the client explicitly requests.
- Reset `m_pool_info_query_time` when a user:
(1) rescans the chain (so the wallet re-requests the whole pool)
(2) changes the daemon their wallets points to (a new daemon would
have a different view of the pool)
- `/getblocks.bin` respects the `req.prune` field when returning
pool txs.
- Pool extension fields in response to `/getblocks.bin` are optional
with default 0'd values.
- Straight-forward call interface: `void rx_slow_hash(const char *seedhash, const void *data, size_t length, char *result_hash)`
- Consensus chain seed hash is now updated by calling `rx_set_main_seedhash` whenever a block is added/removed or a reorg happens
- `rx_slow_hash` will compute correct hash no matter if `rx_set_main_seedhash` was called or not (the only difference is performance)
- New environment variable `MONERO_RANDOMX_FULL_MEM` to force use the full dataset for PoW verification (faster block verification)
- When dataset is used for PoW verification, dataset updates don't stall other threads (verification is done in light mode then)
- When mining is running, PoW checks now also use dataset for faster verification
For privacy reasons, time functions use GMT, to avoid logs leaking
timezones. It'd make more sense to use localtime for wallet output
(which are not logged by default), but that adds inconsistencies
which can also be confusing. So add a Z suffix for now to make it
clear these are not local time.
Unrelated, but similar code-wise to #8643. There is a check in `DNSResolver` which automatically fails to resolve hostnames which do not contain the `.` character. This PR removes that check.
Fixes#8633. The function `append_net_address` did not parse hostname + port addresses (e.g. `bar:29080`) correctly if the hostname did not contain a `'.'` character.
@vtnerd comments 1
clear up 2nd conditional statement
- fix integrated address test, it was not testing integrated address suport
- fix trezor test build as dependent classes were changed
- add a friend test class for Monero::WalletImpl to support wallet api tests
When using wallet_api in tests, synthetic chain is used. Without being able to set `allow_mismatched_daemon_version` in the underlying wallet, we are not able to use a synthetic chain with the tests
23fde15 wallet_rpc_server: chunk refresh to keep responding to RPC while refreshing (moneromooo-monero) 5bb2369 wallet_rpc_server: add --no-initial-sync flag for quicker network binding (moneromooo-monero)
update_checkpoints() makes a few DNS requests and can take up to 20-30 seconds to complete (3-6 seconds on average). It is currently called from core::handle_incoming_block() which holds m_incoming_tx_lock, so it blocks all incoming transactions and blocks processing while update_checkpoints() is running. This PR moves it to until after a new block has been processed and relayed, to avoid full monerod locking.
959a3e6 wallet2: ensure imported outputs subaddresses are created (moneromooo-monero)
a098504 wallet2: better test on whether to allow output import (moneromooo-monero)
c5579ac allow exporting outputs in chunks (moneromooo-monero)
1e912ec wallet2: fixes for export/import output flow (j-berman)
692f1d4 wallet2: do not assume imported outputs must be non empty (moneromooo-monero)
67b6d6a wallet2: prevent importing outputs in a hot wallet (moneromooo-monero)
d9fc666 wallet2: fix missing subaddress indices in 'light' exported outputs (moneromooo-monero)
- spend secret key is no longer the sum of multisig key shares;
no need to check that is the case upon restore.
- restoring a multisig wallet from multisig info means that the
wallet must have already completed all setup rounds. Upon restore,
set the number of rounds completed accordingly.
600de07 wallet_rpc_server: longer timeout for stop_mining (moneromooo-monero)
ac6db92 functional_tests: silence the cpu power test program (moneromooo-monero)
ef1924a Bump to v0.18.1.0 (Seth For Privacy)
89a2df6 Migrate VERSION variable to non-export (Seth For Privacy)
b83874e Set version in ENV var (Seth For Privacy)
bb955d1 Bump Gitian build instructions to v0.18.0.0 (Seth For Privacy)
Being offline is not a good enough heuristic, so we keep track
of whether the wallet ever refreshed from a daemon, which is a
lot better, and probably the best we can do without manual user
designation (which would break existing cold wallet setups till
the user designates those wallets)
Before the fix, it processed all transactions in the mempool which could be very slow when mempool grows to several MBs in size. I observed `get_block_template_backlog` taking up to 15 seconds of CPU time under high mempool load.
After the fix, only transactions that can potentially be mined in the next block will be processed (a bit more than the current block median weight).
@jtgrassie pointed out that the example I provided was colored incorrectly. He also made the good point that the image wasn't easy to review/correct. I reworked the example so that it's text-only. It's easier to review and edit, and reveals the structure better in my opinion. Also this is easier for people who can't distinguish colors as easily.
Make sure to double-check this work because there's a decent chance I screwed up the comments. The actual byte data was generated and should be solid.
That RPC will wait for mining to actually stop, which can be a while
if randomx has just started on randomx_init_dataset.
This fixes occasional failures in the mining functional test
Right now Doxygen is documenting everything in the repo including submodules, everything in contrib,
util, tests, etc. This bogs down the documentation to the point where it is very hard to navigate. I think
it would be a good move to focus on documenting only the main C++ code which is specific to this repo.
Right now this means documenting `src/` (without SUPERCOP), `contrib/epee/`, `external/easylogging++`. After this commit,
Doxygen went from running >6000 graphs to about 2200 graphs.
hash_extra: don't test for success in `jh_hash` and `skein_hash` since its guaranteed
device_ledger: move anonymous global variable apdu_verbose into .cpp file
Add comments to `refreshed` method variable in wallet2
If we were to call it with 100, it would cause rsiz to be 0,
leading to an infinite loop.
This is really a pedantic patch, but since there's already a
range test, might as well make it better.
quick patch which fixes the issue where if you use some macros from `http_server_handlers_map2.h` you have to be in the `epee` namespace or it doesn't compile. Now can remove `using namespace epee;` from header file `core_rpc_server.h`, which caused a couple of name qualifying mistakes
message(FATAL_ERROR"Boost ${Boost_VERSION} (older than 1.62) is too old to link with OpenSSL ${OPENSSL_VERSION} (1.1 or newer) found at ${OPENSSL_INCLUDE_DIR} and ${OPENSSL_LIBRARIES}. "
"Update Boost or install OpenSSL 1.0 and set path to it when running cmake: "
- IRC: [#monero-dev on Libera](https://web.libera.chat/#monero-dev)
@@ -102,9 +102,7 @@ The Bitcoin donation address is:
Core development funding and/or some supporting services are also graciously provided by [sponsors](https://www.getmonero.org/community/sponsorships/):
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).
@@ -117,10 +115,11 @@ See [LICENSE](LICENSE).
If you want to help out, see [CONTRIBUTING](docs/CONTRIBUTING.md) for a set of guidelines.
## Scheduled software upgrades
## Scheduled software/network 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.
Monero uses a scheduled software/network upgrade (hard fork) mechanism to implement new features into the Monero software and network. This means that users of Monero (end users and service providers) should run current versions and upgrade their software when new releases are available. Software upgrades occur when new features are developed and implemented in the codebase. Network upgrades occur in tandem with software upgrades that modify the consensus rules of the Monero network. The required software for network upgrades will be available prior to the scheduled network upgrade 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. The "Minimum" is the software version that follows the new consensus rules. The "Recommended" version may include bug fixes and other new features that do not affect the consensus rules.
| Software upgrade block height | Date | Fork version | Minimum Monero version | Recommended Monero version | Details |
@@ -138,8 +137,8 @@ Dates are provided in the format YYYY-MM-DD.
| 1978433 | 2019-11-30 | v12 | v0.15.0.0 | v0.16.0.0 | New PoW based on RandomX, only allow >= 2 outputs, change to the block median used to calculate penalty, v1 coinbases are forbidden, rct sigs in coinbase forbidden, 10 block lock time for incoming outputs
| 2210000 | 2020-10-17 | v13 | v0.17.0.0 | v0.17.3.2 | New CLSAG transaction format
| 2210720 | 2020-10-18 | v14 | v0.17.1.1 | v0.17.3.2 | forbid old MLSAG transaction format
[1] On Debian/Ubuntu `libgtest-dev` only includes sources and headers. You must
build the library binary manually. This can be done with the following command `sudo apt-get install libgtest-dev && cd /usr/src/gtest && sudo cmake . && sudo make`
then:
* on Debian:
`sudo mv libg* /usr/lib/`
* on Ubuntu:
`sudo mv lib/libg* /usr/lib/`
[2] libnorm-dev is needed if your zmq library was built with libnorm, and not needed otherwise
Install all dependencies at once on Debian/Ubuntu:
Install all dependencies at once on macOS with the provided Brewfile:
@@ -301,14 +286,6 @@ invokes cmake commands as needed.
make debug
```
* **Optional**: to build statically-linked binaries:
```bash
make release-static
```
Dependencies need to be built with -fPIC. Static libraries usually aren't, so you may have to build them yourself with -fPIC. Refer to their documentation for how to build them.
* **Optional**: build documentation in `doc/html` (omit `HAVE_DOT=YES` if `graphviz` is not installed):
```bash
@@ -323,13 +300,13 @@ Dependencies need to be built with -fPIC. Static libraries usually aren't, so yo
#### On the Raspberry Pi
Tested on a Raspberry Pi Zero with a clean install of minimal Raspbian Stretch (2017-09-07 or later) from https://www.raspberrypi.org/downloads/raspbian/. If you are using Raspian Jessie, [please see note in the following section](#note-for-raspbian-jessie-users).
Tested on a Raspberry Pi 5B with a clean installation of Raspberry Pi OS (64-bit) with Debian 12 from https://www.raspberrypi.com/software/operating-systems/.
* `apt-get update && apt-get upgrade` to install all of the latest software
* `apt-get update && apt-get upgrade` to install the latest software
* Install the dependencies for Monero from the 'Debian' column in the table above.
* Increase the system swap size:
* **Optional**: increase the system swap size:
```bash
sudo /etc/init.d/dphys-swapfile stop
@@ -343,9 +320,9 @@ Tested on a Raspberry Pi Zero with a clean install of minimal Raspbian Stretch (
* Clone Monero and checkout the most recent release version:
@@ -354,7 +331,7 @@ Tested on a Raspberry Pi Zero with a clean install of minimal Raspbian Stretch (
USE_SINGLE_BUILDDIR=1 make release
```
* Wait 4-6 hours
* Wait a few hours
* The resulting executables can be found in `build/release/bin`
@@ -366,46 +343,9 @@ Tested on a Raspberry Pi Zero with a clean install of minimal Raspbian Stretch (
* 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
```bash
sudo /etc/init.d/dphys-swapfile stop
sudo nano /etc/dphys-swapfile
CONF_SWAPSIZE=2048
sudo /etc/init.d/dphys-swapfile start
```
* Then, install the dependencies for Monero except for `libunwind` and `libboost-all-dev`
* Install the latest version of boost (this may first require invoking `apt-get remove --purge libboost*-dev` 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
Binaries for Windows can be built on Windows using the MinGW toolchain within
[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
@@ -413,40 +353,21 @@ application.
**Preparing the build environment**
* 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
* Download and install the [MSYS2 installer](https://www.msys2.org). Installing MSYS2 requires 64-bit Windows 10 or newer.
* Open the MSYS shell via the `MSYS2 MSYS` shortcut
* Update packages using pacman:
```bash
pacman -Syu
```
* Exit the MSYS shell using Alt+F4
* Edit the properties for the `MSYS2 Shell` shortcut changing "msys2_shell.bat" to "msys2_shell.cmd -mingw64" for 64-bit builds or "msys2_shell.cmd -mingw32" for 32-bit builds
* Restart MSYS shell via modified shortcut and update packages again using pacman:
* 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.
* Open the MingW shell via `MSYS2 MINGW64` shortcut.
**Cloning**
@@ -464,39 +385,28 @@ application.
cd monero
```
* If you would like a specific [version/tag](https://github.com/monero-project/monero/tags), do a git checkout for that version. eg. 'v0.18.0.0'. If you don't care about the version and just want binaries from master, skip this step:
* If you would like a specific [version/tag](https://github.com/monero-project/monero/tags), do a git checkout for that version. eg. 'v0.18.4.1'. If you don't care about the version and just want binaries from master, skip this step:
```bash
git checkout v0.18.0.0
git checkout v0.18.4.1
```
* If you are on a 64-bit system, run:
* To build Monero, run:
```bash
make release-static-win64
make release-static -j $(nproc)
```
* If you are on a 32-bit system, run:
The resulting executables can be found in `build/release/bin`
* **Optional**: to build Windows binaries suitable for debugging, run:
```bash
make release-static-win32
make debug -j $(nproc)
```
* The resulting executables can be found in `build/release/bin`
* **Optional**: to build Windows binaries suitable for debugging on a 64-bit system, run:
```bash
make debug-static-win64
```
* **Optional**: to build Windows binaries suitable for debugging on a 32-bit system, run:
```bash
make debug-static-win32
```
* The resulting executables can be found in `build/debug/bin`
The resulting executables can be found in `build/debug/bin`
### On FreeBSD:
@@ -507,12 +417,12 @@ Monero is also available as a port or package as `monero-cli`.
### On OpenBSD:
You will need to add a few packages to your system. `pkg_add cmake gmake zeromq libiconv boost`.
You will need to add a few packages to your system. `pkg_add cmake gmake zeromq libiconv boost libunbound`.
The `doxygen` and `graphviz` packages are optional and require the xbase set.
Running the test suite also requires `py-requests` package.
Running the test suite also requires `py3-requests` package.
Note: you may encounter the following error when compiling the latest version of Monero as a normal user:
@@ -544,27 +454,26 @@ cd ../..
Then you can run make as usual.
### Building portable statically linked binaries
By default, in either dynamically or statically linked builds, binaries target the specific host processor on which the build happens and are not portable to other processors. Portable binaries can be built using the following targets:
* ```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
### Cross Compiling
You can also cross-compile static binaries on Linux for Windows and macOS with the `depends` system.
* ```make depends target=x86_64-linux-gnu``` for 64-bit linux binaries.
* ```make depends target=x86_64-w64-mingw32``` for 64-bit windows binaries.
* ```make depends target=x86_64-apple-darwin``` for Intel macOS binaries.
* Requires: `clang-18 lld-18`
* ```make depends target=arm64-apple-darwin``` for Apple Silicon macOS binaries.
* Requires: `clang-18 lld-18`
* You also need to run:
```shell
export PATH="/usr/lib/llvm-18/bin/:$PATH"
```
* ```make depends target=i686-linux-gnu``` for 32-bit linux binaries.
* Requires: `g++-multilib bc`
* ```make depends target=i686-w64-mingw32``` for 32-bit windows binaries.
@@ -585,7 +494,21 @@ The required packages are the names for each toolchain on apt. Depending on your
Using `depends` might also be easier to compile Monero on Windows than using MSYS. Activate Windows Subsystem for Linux (WSL) with a distro (for example Ubuntu), install the apt build-essentials and follow the `depends` steps as depicted above.
The produced binaries still link libc dynamically. If the binary is compiled on a current distribution, it might not run on an older distribution with an older installation of libc. Passing `-DBACKCOMPAT=ON` to cmake will make sure that the binary will run on systems having at least libc version 2.17.
The produced binaries still link libc dynamically. If the binary is compiled on a current distribution, it might not run on an older distribution with an older installation of libc.
### Trezor hardware wallet support
If you have an issue with building Monero with Trezor support, you can disable it by setting `USE_DEVICE_TREZOR=OFF`, e.g.,
```bash
USE_DEVICE_TREZOR=OFF make release
```
For more information, please check out Trezor [src/device_trezor/README.md](src/device_trezor/README.md).
### Guix builds
See [contrib/guix/README.md](contrib/guix/README.md).
## Installing Monero from a package
@@ -593,30 +516,27 @@ The produced binaries still link libc dynamically. If the binary is compiled on
Packages are available for
* Debian Buster
See the [instructions in the whonix/monero-gui repository](https://gitlab.com/whonix/monero-gui#how-to-install-monero-using-apt-get)
* Debian Bullseye and Sid
* Debian 12 (Bookworm) or later
```bash
sudo apt install monero
```
More info and versions in the [Debian package tracker](https://tracker.debian.org/pkg/monero).
More info and versions in the [Debian package tracker](https://tracker.debian.org/pkg/monero).
* Arch Linux [(via Community packages)](https://www.archlinux.org/packages/community/x86_64/monero/):
* Arch Linux:
```bash
sudo pacman -S monero
```
* Void Linux:
* NixOS:
```bash
xbps-install -S monero
nix-shell -p monero-cli
```
* GuixSD
* Guix:
```bash
guix package -i monero
@@ -632,6 +552,12 @@ More info and versions in the [Debian package tracker](https://tracker.debian.or
emerge net-p2p/monero
```
* Alpine Linux:
```bash
apk add monero
```
* macOS [(homebrew)](https://brew.sh/)
```bash
brew install monero
@@ -653,8 +579,8 @@ More info and versions in the [Debian package tracker](https://tracker.debian.or
+# error getrandom() is currently disabled on Linux to support glibc < 2.25
+#endif
+
unsigned char buf;
(void) getrandom((void *) &buf, 1U, 0U);
]])],
@@ -825,6 +829,9 @@ unsigned char buf;
# include <sys/random.h>
#endif
]], [[
+#ifdef __linux__
+# error getentropy() is currently disabled on Linux to support glibc < 2.25
+#endif
#ifdef __APPLE__
# error getentropy() is currently disabled on Apple operating systems
#endif
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.
