profile
viewpoint

monero-project/monero 4655

Monero: the secure, private, untraceable cryptocurrency

moneromooo-monero/monero-wallet-generator 229

Self contained offline javacsript Monero wallet generator

moneromooo-monero/bitmonero 19

Monero: the secure, private, untraceable cryptocurrency

moneromooo-monero/monero-update 5

A secure updater/installer for Monero

moneromooo-monero/kovri 1

The Kovri I2P Router Project

moneromooo-monero/easyloggingpp 0

Single header only C++ logging library. It is extremely light-weight, robust, fast performing, thread and type safe and consists of many built-in features. It provides ability to write logs in your own customized format. It also provide support for logging your classes, third-party libraries, STL and third-party containers etc.

moneromooo-monero/lmdb 0

Read-only mirror of official repo on openldap.org. Issues and pull requests here are ignored. Use OpenLDAP ITS for issues.

moneromooo-monero/meta 0

A Meta Repository for General Monero Project Matters

pull request commentmonero-project/monero

Split epee/string_tools.h and extracted boost_lexical_cast

Resolved merge conflict.

mj-xmr

comment created time in 15 minutes

issue openedmonero-project/monero

[Design] Cyclical dependency between libdevice and libcryptonote_basic

In this issue, I have noticed the following cyclical dependency:

The libdevice depends on libcryptonote_basic through cryptonote::get_transaction_prefix_hash(cryptonote::transaction_prefix const&, crypto::hash&), used in device_default.cpp, while libcryptonote_basic depends on libdevice, via the file crypronote_basic.h, where the device.hpp is included and used.

The remedy would be to feed the libcryptonote_basic with the class (or rather interface) device from libdevice, but extracting any implementations (i.e. device_default) outside of libdevice into, say, libdeviceImpl.

This is not high on my prio list currently, but I would be capable of resolving this one.

created time in 2 hours

pull request commentmonero-project/monero

[DON'T MERGE yet] Use shared build for int. libs when non-static set on release

There appears to be a mis-match between description and behavior. (...)

Yes, this is true. It's a change of the default behavior, and this can be achieved with the flag BUILD_SHARED_LIBS you mentioned. The problem is, that there are no Makefile targets in the root directory, that would trigger switch this flag on for release targets. Other than that, maybe it would be better if I just document somewhere how to change this flag via cmake.

mj-xmr

comment created time in 2 hours

issue commentmonero-project/monero

Error: Error mining to daemon: Found nonce, but daemon errored out with error -18: Stale payment, continuing

Updated wallet to Monero Oxygen Orion v0.17.1.5 and the error is showing up with the --log-level 2.

error

lh1008

comment created time in 3 hours

issue commentmonero-project/monero

Exception: std::runtime_error

Hello, not mining, just running a full node.

Running on an old nuc. I now realize it is running an hdd.

  • Intel(R) Celeron(R) CPU N2820 @ 2.13GHz
  • 4GB RAM
D4nte

comment created time in 13 hours

pull request commentmonero-project/monero

Do not use peer_id tracking method over i2p/tor

How to test this specifically?

vtnerd

comment created time in 19 hours

issue commentmonero-project/monero

Exception: std::runtime_error

Are you mining? What hardware are you using?

D4nte

comment created time in 20 hours

issue openedmonero-project/monero

Exception: std::runtime_error

Hi,

I keep getting this error every 2 minutes.

version: 3942a1cd043bb103ca05184057aea5c86e3137e5, 3942a1cd043bb103ca05184057aea5c86e3137e5

Is it expected?

2020-12-01 22:23:03.290     7f5f898d6700        INFO    stacktrace      src/common/stack_trace.cpp:172  
2020-12-01 22:25:55.608     7f5f898d6700        INFO    stacktrace      src/common/stack_trace.cpp:133  Exception: std::runtime_error
2020-12-01 22:25:55.609     7f5f898d6700        INFO    stacktrace      src/common/stack_trace.cpp:134  Unwound call stack:
2020-12-01 22:25:55.623     7f5f898d6700        INFO    stacktrace      src/common/stack_trace.cpp:172      [1]  0x112) [0x5579dac4f23d]:__cxa_throw+0x112) [0x5579dac4f23d]
2020-12-01 22:25:55.623     7f5f898d6700        INFO    stacktrace      src/common/stack_trace.cpp:172      [2] /usr/local/bin/monerod(+0x34df6a) [0x5579dac8ef6a] 
2020-12-01 22:25:55.623     7f5f898d6700        INFO    stacktrace      src/common/stack_trace.cpp:172      [3]  0x1f) [0x5579db3074ff]:_ZN7randomx6VmBaseINS_18LargePageAllocatorELb1EE8allocateEv+0x1f) [0x5579db3074ff]
2020-12-01 22:25:55.623     7f5f898d6700        INFO    stacktrace      src/common/stack_trace.cpp:172      [4]  0xde) [0x5579db3047ae]:_create_vm+0xde) [0x5579db3047ae]
2020-12-01 22:25:55.623     7f5f898d6700        INFO    stacktrace      src/common/stack_trace.cpp:172      [5]  0x4cc) [0x5579db0f284c]:_slow_hash+0x4cc) [0x5579db0f284c]
2020-12-01 22:25:55.623     7f5f898d6700        INFO    stacktrace      src/common/stack_trace.cpp:172      [6]  0x132) [0x5579db0db992]:_ZN10cryptonote18get_block_longhashEPKNS_10BlockchainERKNS_5blockERN6crypto4hashEmPKS7_i+0x132) [0x5579db0db992]
2020-12-01 22:25:55.623     7f5f898d6700        INFO    stacktrace      src/common/stack_trace.cpp:172      [7]  0x28) [0x5579db0dbae8]:_ZN10cryptonote18get_block_longhashEPKNS_10BlockchainERKNS_5blockEmi+0x28) [0x5579db0dbae8]
2020-12-01 22:25:55.623     7f5f898d6700        INFO    stacktrace      src/common/stack_trace.cpp:172      [8]  0xb6) [0x5579db07be26]:_ZNK10cryptonote10Blockchain21block_longhash_workerEmRKN4epee4spanIKNS_5blockEEERSt13unordered_mapIN6crypto4hashESA_St4hashISA_ESt8equal_toISA_ESaISt4pairIKSA_SA_EEE+0xb6) [0x5579db07be26]
2020-12-01 22:25:55.623     7f5f898d6700        INFO    stacktrace      src/common/stack_trace.cpp:172      [9]  0x481) [0x5579db132361]:_ZN5tools10threadpool3runEb+0x481) [0x5579db132361]
2020-12-01 22:25:55.623     7f5f898d6700        INFO    stacktrace      src/common/stack_trace.cpp:172      [10]  0x1143b) [0x7f79748d243b]:_64-linux-gnu/libboost_thread.so.1.71.0(+0x1143b) [0x7f79748d243b]
2020-12-01 22:25:55.623     7f5f898d6700        INFO    stacktrace      src/common/stack_trace.cpp:172      [11]  0x9609) [0x7f7974516609]:_64-linux-gnu/libpthread.so.0(+0x9609) [0x7f7974516609]
2020-12-01 22:25:55.623     7f5f898d6700        INFO    stacktrace      src/common/stack_trace.cpp:172      [12]  0x43) [0x7f797443d293]:_64-linux-gnu/libc.so.6(clone+0x43) [0x7f797443d293]
2020-12-01 22:25:55.623     7f5f898d6700        INFO    stacktrace      src/common/stack_trace.cpp:172

created time in 20 hours

PR merged monero-project/monero

Change Dandelion++ fluff probability to 20%, and embargo timeout to 39s

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.


Not mentioned in commit message : transactions should be "blackholed" less frequently due to the shorter expected stem length. This is also the highest fluff probability recommended in the Dandelion++ paper.

+4 -4

0 comment

2 changed files

vtnerd

pr closed time in 20 hours

push eventmonero-project/monero

Lee Clagett

commit sha b10878f1087aec914560781bde9e0e36bc682dfe

Change Dandelion++ fluff probability to 20%, and embargo timeout to 39s 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.

view details

Alexander Blair

commit sha 4f401f6fca64a8ef6c9325d4c737c89bbb4c8091

Merge pull request #7025 b10878f10 Change Dandelion++ fluff probability to 20%, and embargo timeout to 39s (Lee Clagett)

view details

push time in 20 hours

push eventmonero-project/monero

xiphon

commit sha aaf837cf5f5bc469591399f869467170133f1109

rpc: skip non-synced bootstrap daemons in --no-sync mode too

view details

Alexander Blair

commit sha 976fcb59859cc0ac0e965953974603dfd037c969

Merge pull request #7024 aaf837cf5 rpc: skip non-synced bootstrap daemons in --no-sync mode too (xiphon)

view details

push time in 20 hours

PR merged monero-project/monero

Add rpc-restricted-bind-ip option [release]

Fixes #6369

+55 -4

0 comment

4 changed files

hyc

pr closed time in 20 hours

push eventmonero-project/monero

Howard Chu

commit sha a8cd073fcc504de51b8f56766757f0295b68e066

Add rpc-restricted-bind-ip option Fixes #6369

view details

Alexander Blair

commit sha 065bb292dfa3c59251a4f54f2933f19c0741afd8

Merge pull request #7010 a8cd073fc Add rpc-restricted-bind-ip option (Howard Chu)

view details

push time in 20 hours

PR merged monero-project/monero

Fix tx flush callback queueing

Found this via audit. If an exception is thrown in the flush txes callback (txes are now randomly delayed per-connection based on Dandelion++ recommendations), the state was not reset possibly preventing another callback from being queued. This is related to catching all-exceptions and continuing. There was also a small possibility of multiple queued callbacks, thus the reference count (another thread queues the callback for dispatching while prepping another callback). Async is fun.

Unfortunately I do not believe this to be source of the reported issues, because the exceptions in the callback should be uncommon and the descriptions don't quite match.

+12 -23

2 comments

1 changed file

vtnerd

pr closed time in 20 hours

push eventmonero-project/monero

Lee Clagett

commit sha dff1d8067c38ecebce9b5d7a7a3d5edc54669b33

Fix tx flush callback queueing

view details

Alexander Blair

commit sha f41dce49acc89bd8672f3737e8e67f0efc8aacbd

Merge pull request #6954 dff1d8067 Fix tx flush callback queueing (Lee Clagett)

view details

push time in 20 hours

PR merged monero-project/monero

Add rpc-restricted-bind-ip option

Fixes #6369

+55 -4

0 comment

4 changed files

hyc

pr closed time in 20 hours

push eventmonero-project/monero

Howard Chu

commit sha 65903d2cfca6204af1a69259286178716e01e79f

Add rpc-restricted-bind-ip option Fixes #6369

view details

Alexander Blair

commit sha 7cd0c642102605c36b68c698e3fda4a1b969ac6e

Merge pull request #6948 65903d2cf Add rpc-restricted-bind-ip option (Howard Chu)

view details

push time in 20 hours

issue closedmonero-project/monero

Add rpc-restricted-bind-ip option

When running a node as a service (noninteractive) the only way to run commands against the daemon is through the unrestricted RPC port, a port that should not be publicly accessible.

Currently, monerod binds both restricted and unrestricted RPC ports to the rpc-bind-ip value. So a firewall must be used in order to block incoming connections to the unrestricted RPC port.

It would be nice to have a rpc-restricted-bind-ip option so that the unrestricted RPC port can be bound to localhost or a private IP, rather than a public IP.

This option would mainly be useful for nodes that are directly exposed to the internet (VPSs) since they can't simply choose not to port forward the unrestricted RPC port.

closed time in 20 hours

omurad

PR merged monero-project/monero

p2p: give all hosts the same chance of being picked for connecting

This has two stowaway patches necessary for the patch to apply. They were PRed separately.

+26 -1

1 comment

1 changed file

moneromooo-monero

pr closed time in 20 hours

push eventmonero-project/monero

moneromooo

commit sha 6c9980a55beabf8ad386156c91df13a997584fe9

p2p: give all hosts the same chance of being picked for connecting even if some run more than one node

view details

Alexander Blair

commit sha 431ec528bc7949f5eed05e58b7f44f69bab7062f

Merge pull request #6939 6c9980a55 p2p: give all hosts the same chance of being picked for connecting (moneromooo)

view details

push time in 20 hours

push eventmonero-project/monero

moneromooo-monero

commit sha cc034fe0c31f271275b9ab7f4048990519206018

util: fix escaping more than one ?* in glob_to_regex

view details

Alexander Blair

commit sha 003a06f030de7bf52b2617f2d24976ff22dd3d5e

Merge pull request #6923 cc034fe0c util: fix escaping more than one ?* in glob_to_regex (moneromooo-monero)

view details

push time in 20 hours

PR merged monero-project/monero

Allow setting start block on export

And make import honor the starting block# recorded in a bootstrap file. The fields have always been present in the bootstrap file header, but ignored until now.

+69 -34

0 comment

4 changed files

hyc

pr closed time in 20 hours

push eventmonero-project/monero

Howard Chu

commit sha b7dd8349f470633788f33e776480c66d19ecc8ba

Allow setting start block on export And make import honor the starting block# recorded in a bootstrap file

view details

Alexander Blair

commit sha d8f947235630db78e81f8dbdbec814fd620a2074

Merge pull request #6910 b7dd8349f Allow setting start block on export (Howard Chu)

view details

push time in 20 hours

push eventmonero-project/monero

xiphon

commit sha ec14e4b8cd5b78c8d3251bb205294810b29f880e

wallet2: skip reorgs exceeding max-reorg-depth wallet setting

view details

Alexander Blair

commit sha 438442ace07d72a9c52c887a02335ea795fbd075

Merge pull request #6890 ec14e4b8c wallet2: skip reorgs exceeding max-reorg-depth wallet setting (xiphon)

view details

push time in 20 hours

pull request commentmonero-project/monero

[DON'T MERGE yet] Use shared build for int. libs when non-static set on release

There appears to be a mis-match between description and behavior. You can already compile non-static releases by setting -DBUILD_SHARED_LIBS=ON during the cmake configuration stage. Instead, this PR changes the default behavior to shared libraries for release builds. I don't see a compelling reason for this because a significant number of function calls become indirect lookups - each directory is its own shared library. The current behavior seems like what most expect currently, unless things are re-arranged for a libmonero, etc.

mj-xmr

comment created time in a day

issue commentmonero-project/monero

Syncing performance (discuss)

I am syncing on Qubes 4.0 and I am having performance issues too, especially at the last 2%. I have allocated the Qube 4 CPUs and 6GB ram but the CPU usage remains at a constant 25%. If I allocate 2 CPUs then the CPU usage remains at a constant 50%. These tests indicate that monerod is only using one of the CPUs for the sync.

I tried running it with --db-sync-mode fast:async:10000 and it made it run even slower. Without this option the estimated time for the last 35,000 blocks was 2.8 days. With this option the estimated time for the last 35,000 blocks was 19.8 days.

There is no issue with networking. I tried syncing using a Windows computer on my LAN as an exclusive node and the sync was still slow.

There may be an issue with disk speed. For the blockchain, I am using an external USB that has a read/write speed of about 100 MB/s. I am about to upgrade to an internal SSD with a read/write speed of about 500 MB/s.

I am using a quite old computer. It was selected purely for 100% Qubes compatibility. Building a new computer will give me faster performance for the single CPU that monerod uses but will not increase the used CPU count.

To speed up the sync, I exported the blockchain from my faster computer and imported it onto the USB. I couldn't export all of it because at around block 2,210,000 the export failed. I may try re-importing and re-syncing the blockchain on the Windows computer to see if it fixes the database. In this case I would be able to simply copy the database from the Windows computer to the Qubes computer.

throwawow581

comment created time in a day

issue closedmonero-project/monero

Always get stuck on the last 2 blocks - Monero Core win-x64-v0.17.1.5

hi,

apologies for reporting this again, but not sure it went to the right channel, this one should be it.

I synced my Monero Core a few times recently and it always get stuck on the last 2 blocks

When i load it the first time it finishes relatively quickly, says "Daemon Synchronized" and "all blocks synced" so both bars are orange, yet after a while it keeps going on and off between 1 block and 2 blocks, and stays on 2 blocks left for a while, it didn't happen to previous release as far as i can tell.

https://www.dropbox.com/s/ct6yf6t5kjly3ph/Mnr-stuck-2-blocks.png?dl=0

what's up? i have monero-gui-install-win-x64-v0.17.1.5

Edit: it finished, then back again to 1 block remaining and then 2 blocks again. so odd,

this is what i have in the log:

2020-12-01 11:43:42.160 [P2P9] INFO global src/cryptonote_protocol/cryptonote_protocol_handler.inl:368 [95.216.173.96:36630 INC] Sync data returned a new top block candidate: 2242596 -> 2242597 [Your node is 1 blocks (2.0 minutes) behind] 2020-12-01 11:43:42.160 [P2P9] INFO global src/cryptonote_protocol/cryptonote_protocol_handler.inl:368 SYNCHRONIZATION started 2020-12-01 11:44:18.745 [P2P9] INFO global src/cryptonote_protocol/cryptonote_protocol_handler.inl:1600 Synced 2242597/2242597 2020-12-01 11:44:18.746 [P2P9] INFO global src/cryptonote_protocol/cryptonote_protocol_handler.inl:2318 SYNCHRONIZED OK 2020-12-01 12:22:03.909 [P2P4] INFO global src/cryptonote_protocol/cryptonote_protocol_handler.inl:2318 SYNCHRONIZED OK 2020-12-01 12:23:20.281 [P2P6] INFO global src/cryptonote_protocol/cryptonote_protocol_handler.inl:2318 SYNCHRONIZED OK 2020-12-01 12:33:57.837 [P2P5] INFO global src/cryptonote_protocol/cryptonote_protocol_handler.inl:2318 SYNCHRONIZED OK 2020-12-01 12:40:20.779 [P2P2] INFO global src/cryptonote_protocol/cryptonote_protocol_handler.inl:2318 SYNCHRONIZED OK

and this is going over and over.. is that the intended behaviour?

many thanks

closed time in a day

gab81
more