RefreshOptimizeCoinbase was an optimization to speed up scanning of coinbase transactions before RingCT (tx version 2) where they split miner reward into multiple denominations, all to the same wallet.
When RingCT was introduced, all coinbase transactions became 1 output only, so this optimization does nothing now.
With p2pool, this optimization will skip scanning p2pool payouts because they use more than 1 output in coinbase transaction.
Fix it by applying this optimization only to pre-RingCT transactions (version < 2).
- matches the paper by Miller et al to apply the gamma from chain tip, rather than after unlock time
- if the gamma produces an output more recent than the unlock time, the algo packs that output into one of the first 50 spendable blocks, respecting the block density factor
boosted_tcp_server: check condition before sleep too
cryptonote_protocol_handler: each instance of BlockchainLMDB requires separate thread due to private thread local fields
dedcd63 wallet_api: import / export output function (tobtoht)
6e22710 expose set_offline to wallet api (benevanoff)
02e9a41 wallet_api: add isDeterministic() (tobtoht)
def5819 wallet_api: add seed_offset param to seed() (tobtoht)
73959c6 wallet_api: store fee for incoming txs in history (Ben Evanoff)
712f362 wallet api: allow wallet to fetch all key images via api (benevanoff)
153d08d Allow tx note edits via TransactionHistory object in wallet/api (dsc)
2abd7b1 wallet_api: TransactionHistory - fill unconfirmed out payments dests (xiphon)
9a50bef Extend TransactionInfo with coinbase and description attributes in wallet/api (dsc)
22bb6a6 Allow AddressBook description edits via wallet/api interface (dsc)
- rolling_median: tried to free uninitialized pointer in a constructor
- net_node.inl: erase-remove idiom was used incorrectly. remove_if doesn't actually remove elements, see http://cpp.sh/6fcjv
- bulletproofs.cc: call to sizeof() instead of vector.size(), luckily it only impacts performance and not code logic there
On Mac, size_t is a distinct type from uint64_t, and some
types (in wallet cache as well as cold/hot wallet transfer
data) use pairs/containers with size_t as fields. Mac would
save those as full size, while other platforms would save
them as varints. Might apply to other platforms where the
types are distinct.
There's a nasty hack for backward compatibility, which can
go after a couple forks.
42ee30929 protocol: reject claimed block hashes that already are in the chain (moneromooo-monero)
a436c3625 protocol: drop peers we can't download anything from in sync mode (moneromooo-monero)
do not include blocked hosts in peer lists or public node lists by default,
warn about no https on clearnet and about untrusted peers likely being spies
If enabled, pulls IPs to block on blocklist.moneropulse.*, and
blocks then for 8 days (so IPs dropping from the list will
eventually get unblocked, and DNS failures don't result in
instant clearing of the blocklist).
Enable with --enable-dns-blocklist
ce26c5b protocol: drop peers that don't reply to queries (moneromooo)
9427b5a keep only the last seen node on a given host in the white list (moneromooo)
fa79148 protocol: drop peers that decrease claimed height (moneromooo)
1382b17 protocol: add scoring system to drop peers that don't behave (moneromooo)
IPv6 addresses include a range that can map IPv4 addresses,
which allowed those mapped addresses to bypass filtering.
This filter should be replaced by AS filtering at some point.
A 20% fluff probability increases the precision of a spy connected to
every node by 10% on average, compared to a network using 0% fluff
probability. The current value (10% fluff) should increase precision by
~5% compared to baseline.
This decreases the expected stem length from 10 to 5. The embargo
timeout was therefore lowered to 39s; the fifth node in a stem is
expected to have a 90% chance of being the first to timeout, which is
the same probability we currently have with an expected stem length of
10 nodes.
Miners with MLSAG txes which they'd already verified included
a couple in that block, but the consensus rules had changed
in the meantime, so that block is technically invalid and any
node which did not already have those two txes in their txpool
could not sync. Grandfather them in, since it has no effect in
practice.
d20ff4f64 functional_tests: add a large (many randomx epochs) p2p reorg test (moneromooo-monero)
6a0b3b1f8 functional_tests: add randomx tests (moneromooo-monero)
9d42649d5 core: fix mining from a block that's not the current top (moneromooo-monero)
975ae22 Fix send scalar z in plaintext (grydz)
333ae55 Update minimal Ledger Monero app version (grydz)
0a3c5a6 Update protocol version with Ledger's HW (grydz)
fa06c39 Bind signature to full address and signing mode (SarangNoether)
743608e wallet: allow signing a message with spend or view key (moneromooo-monero)
85899230d simplewallet: allow setting tx keys when sending to a subaddress (moneromooo-monero)
e916201f1 wallet2: fix setting tx keys when another is already set (moneromooo-monero)
This reduces the attack surface for data that can come from
malicious sources (exported output and key images, multisig
transactions...) since the monero serialization is already
exposed to the outside, and the boost lib we were using had
a few known crashers.
For interoperability, a new load-deprecated-formats wallet
setting is added (off by default). This allows loading boost
format data if there is no alternative. It will likely go
at some point, along with the ability to load those.
Notably, the peer lists file still uses the boost serialization
code, as the data it stores is define in epee, while the new
serialization code is in monero, and migrating it was fairly
hairy. Since this file is local and not obtained from anyone
else, the marginal risk is minimal, but it could be migrated
later if needed.
Some tests and tools also do, this will stay as is for now.
6bfcd3101 Updates InProofV1, OutProofV1, and ReserveProofV1 to new V2 variants that include all public proof parameters in Schnorr challenges, along with hash function domain separators. Includes new randomized unit tests. (Sarang Noether)
There are a few Borromean proofs txes in the v8 era, and these
aren't supported by get_pruned_transaction_weight. Moreover, only
only the most recent variant of bulletproofs is currently supported.
The sort predicate is a boolean ordered-before value, but these are
returning the memcmp value directly, and thus returns true whenever the
pubkeys aren't equal. This means:
- it isn't actually sorting.
- it can (and does) segfault for some inputs.
The cache is discarded when a block is popped, but then gets
rebuilt when the difficulty for next block is requested.
While this is all properly locked, it does not take into account
the delay caused by a database transaction being only committed
(and thus its effects made visible to other threads) later on,
which means another thread could request difficulty between
the pop and the commit, which would end up using stale database
view to build the cache, but that cache would not be invalidated
again when the transaction gets committed, which would cause the
cache to not match the new database data.
To fix this, we now keep track of when the cache is invalidated
so we can invalidate it again upon database transaction commit
to ensure it gets calculated again with fresh data next time it
is nedeed.
bde7f1c fuzz_tests: fix init check in oss-fuzz mode (moneromooo-monero)
c4b7420 Do not use PIE with OSS-Fuzz (moneromooo-monero)
c4df8b1 fix leaks in fuzz tests (moneromooo-monero)
38ca1bb fuzz_tests: add a tx extra fuzz test (moneromooo-monero)
On startup, it checks against the difficulty checkpoints, and if any mismatch is found, recalculates all the blocks with wrong difficulties. Additionally, once a week it recalculates difficulties of blocks after the last difficulty checkpoint.
bb5c5df cryptonote_protocol: reject requests/notifications before handshake (moneromooo-monero)
f1d0457 cryptonote_protocol: stricter limit to number of objects requested (moneromooo-monero)
The Bug:
1. Construct `byte_slice.portion_` with `epee::span(buffer)` which copies a pointer to the SSO buffer to `byte_slice.portion_`
2. It constructs `byte_slice.storage_` with `std::move(buffer)` (normally this swap pointers, but SSO means a memcpy and clear on the original SSO buffer)
3. `slice.data()` returns a pointer from `slice.portion_` that points to the original SSO cleared buffer, `slice.storage_` has the actual string.
This can now happen if:
- we have a pruned db
- we have not connected to the monero network for a while
- we connect to a node
- that node asks us for history
- we only have a pruned version of the most recent common block
In that case, it's better to not reply but keep the connection alive,
so we can sync off it.
Some tools report the alignment check as UB, which seems a bit
dubious, but since the performance difference between the two
versions is minimal, I'll go with the safe version
The default monero.conf file depends on the existence of the folders `/var/log/monero/` and `/var/lib/monero/`.
This change makes sure systemd will create them, together with the proper permissions, if they don't exist.
`StateDirectory` can be considered an extra safety in case the user `monero` happens to have been created with specifying `/var/lib/monero/` as a home folder but without actually creating it.
@@ -72,11 +73,11 @@ Monero is a private, secure, untraceable, decentralised digital currency. You ar
**Privacy:** Monero uses a cryptographically sound system to allow you to send and receive funds without your transactions being easily revealed on the blockchain (the ledger of transactions that everyone has). This ensures that your purchases, receipts, and all transfers remain absolutely private by default.
**Security:** Using the power of a distributed peer-to-peer consensus network, every transaction on the network is cryptographically secured. Individual wallets have a 25word mnemonic seed that is only displayed once, and can be written down to backup the wallet. Wallet files are encrypted with a passphrase to ensure they are useless if stolen.
**Security:** Using the power of a distributed peer-to-peer consensus network, every transaction on the network is cryptographically secured. Individual wallets have a 25-word mnemonic seed that is only displayed once and can be written down to backup the wallet. Wallet files are encrypted with a passphrase to ensure they are useless if stolen.
**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.
**Untraceability:** By taking advantage of ring signatures, a special property of a certain type of cryptography, Monero is able to ensure that transactions are not only untraceable but have an optional measure of ambiguity that ensures that transactions cannot easily be tied back to an individual user or computer.
**Decentralization:** The utility of monero depends on its decentralised peer-to-peer consensus network - anyone should be able to run the monero software, validate the integrity of the blockchain, and participate in all aspects of the monero network using consumer-grade commodity hardware. Decentralization of the monero network is maintained by software development that minimizes the costs of running the monero software and inhibits the proliferation of specialized, non-commodity hardware.
**Decentralization:** The utility of Monero depends on its decentralised peer-to-peer consensus network - anyone should be able to run the monero software, validate the integrity of the blockchain, and participate in all aspects of the monero network using consumer-grade commodity hardware. Decentralization of the monero network is maintained by software development that minimizes the costs of running the monero software and inhibits the proliferation of specialized, non-commodity hardware.
## About this project
@@ -84,13 +85,13 @@ This is the core implementation of Monero. It is open source and completely free
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 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.
**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
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).
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 Monero donation address is: `888tNkZrPN6JsEgekjMnABU4TBzc2Dt29EPAvkRxbANsAnjyPbb3iQ1YBRk1UXcdRsiKc9dhwMVgN5S9cQUiyoogDavup3H` (viewkey: `f359631075708155cc3d92a32b75a7d02a5dcf27756707b47a2b31b21c389501`)
The Bitcoin donation address is: `1KTexdemPdxSBcG55heUuTjDRYqbC5ZL8H`
@@ -132,7 +133,9 @@ Dates are provided in the format YYYY-MM-DD.
| 1788000 | 2019-03-09 | v10 | v0.14.0.0 | v0.14.1.2 | New PoW based on Cryptonight-R, new block weight algorithm, slightly more efficient RingCT format
| 1788720 | 2019-03-10 | v11 | v0.14.0.0 | v0.14.1.2 | forbid old RingCT transaction format
| 1978433 | 2019-11-30* | v12 | v0.15.0.0 | v0.15.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
| 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.2.3 | New CLSAG transaction format
| 2210720 | 2020-10-18 | v14 | v0.17.1.1 | v0.17.2.3 | 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 && sudo mv libg* /usr/lib/ ```
@@ -189,13 +192,13 @@ build the library binary manually. This can be done with the following command `
Install all dependencies at once on Debian/Ubuntu:
@@ -219,7 +222,7 @@ invokes cmake commands as needed.
```bash
cd monero
git checkout release-v0.15
git checkout release-v0.17
make
```
@@ -287,12 +290,12 @@ Tested on a Raspberry Pi Zero with a clean install of minimal Raspbian Stretch (
* If using an external hard disk without an external power supply, ensure it gets enough power to avoid hardware issues when syncing, by adding the line "max_usb_current=1" to /boot/config.txt
* Clone monero and checkout the most recent release version:
* Clone Monero and checkout the most recent release version:
@@ -313,7 +316,7 @@ Tested on a Raspberry Pi Zero with a clean install of minimal Raspbian Stretch (
#### *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.
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
@@ -325,7 +328,7 @@ If you are using the older Raspbian Jessie image, compiling Monero is a bit more
```
* Then, install the dependencies for Monero except `libunwind` and `libboost-all-dev`
* 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):
@@ -346,7 +349,7 @@ If you are using the older Raspbian Jessie image, compiling Monero is a bit more
* 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.
* 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:
@@ -409,10 +412,10 @@ 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.15.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.17.2.3'. If you don't care about the version and just want binaries from master, skip this step:
```bash
git checkout v0.15.0.0
git checkout v0.17.2.3
```
* If you are on a 64-bit system, run:
@@ -446,7 +449,7 @@ application.
### On FreeBSD:
The project can be built from scratch by following instructions for Linux above(but use `gmake` instead of `make`).
If you are running monero in a jail, you need to add `sysvsem="new"` to your jail configuration, otherwise lmdb will throw the error message: `Failed to open lmdb environment: Function not implemented`.
If you are running Monero in a jail, you need to add `sysvsem="new"` to your jail configuration, otherwise lmdb will throw the error message: `Failed to open lmdb environment: Function not implemented`.
Monero is also available as a port or package as 'monero-cli`.
@@ -459,7 +462,7 @@ Running the test suite also requires `py-requests` package.
Then you need to increase the data ulimit size to 2GB and try again: `ulimit -d 2000000`
### On NetBSD:
Check that the dependencies are present: `pkg_info -c libexecinfo boost-headers boost-libs protobuf readline libusb1 zeromq git-base pkgconf gmake cmake | more`, and install any that are reported missing, using `pkg_add` or from your pkgsrc tree. Readline is optional but worth having.
Third-party dependencies are usually under `/usr/pkg/`, but if you have a custom setup, adjust the "/usr/pkg" (below) accordingly.
Clone the monero repository recursively and checkout the most recent release as described above. Then build monero: `gmake BOOST_ROOT=/usr/pkg LDFLAGS="-Wl,-R/usr/pkg/lib" release`. The resulting executables can be found in `build/NetBSD/[Release version]/Release/bin/`.
### On Solaris:
The default Solaris linker can't be used, you have to install GNU ld, then run cmake manually with the path to your copy of GNU ld:
@@ -543,6 +554,10 @@ 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
```bash
@@ -550,9 +565,8 @@ Packages are available for
```
More info and versions in the [Debian package tracker](https://tracker.debian.org/pkg/monero).
* Arch Linux (via [AUR](https://aur.archlinux.org/)):
As of May 2020, the full Monero blockchain file is about 80 GB. One can store a pruned blockchain, which is about 28 GB.
A pruned blockchain can only serve part of the historical chain data to other peers, but is otherwise identical in
functionality to the full blockchain.
To use a pruned blockchain, it is best to start the initial sync with --prune-blockchain. However, it is also possible
to prune an existing blockchain using the monero-blockchain-prune tool or using the --prune-blockchain monerod option
with an existing chain. If an existing chain exists, pruning will temporarily require disk space to store both the full
and pruned blockchains.
## 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.
@@ -715,7 +754,7 @@ Print the stack trace with `bt`
// ! (how ever if in some wonderful juristdictions that is not the case, then why not make another sub-class withat that members and licence it as epee part)
// ! Working on above premise, IF this is valid in your juristdictions, then consider this code as released as:
// Copyright (c) 2014-2019, The Monero Project
// Copyright (c) 2014-2020, The Monero Project
//
// All rights reserved.
//
@@ -132,10 +132,10 @@ class connection_basic { // not-templated base class for rapid developmet of som
MDEBUG(m_connection_context<<"LEVIN_PACKET partial msg received. len="<<cb<<", current total "<<m_cache_in_buffer.size()<<"/"<<m_current_head.m_cb<<" ("<<(100.0f*m_cache_in_buffer.size()/(m_current_head.m_cb?m_current_head.m_cb:1))<<"%)");
CHECK_AND_ASSERT_THROW_MES(se.first.size()<std::numeric_limits<uint8_t>::max(),"storage_entry_name is too long: "<<se.first.size()<<", val: "<<se.first);
CHECK_AND_ASSERT_THROW_MES(!se.first.empty(),"storage_entry_name is empty");
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.