vtnerd: for the input multisig builders? so I can do this github.com/UkoeHB/monero/blob/0c56c…66a03/src/seraphis/grootle.cpp#L617 then this github.com/UkoeHB/monero/blob/0c56c…src/seraphis/tx_validators.cpp#L404 then this github.com/UkoeHB/monero/blob/0c56c…eraphis/txtype_squashed_v1.cpp#L576

vtnerd: using a const singleton means it can't be initialized in a background thread

ukoehb: its identical to this: github.com/monero-project/monero/blob/master/src/net/error.cpp#L97

the members of the class get initialized in the constructor once.

and since the object is const, the members are const

the first thread (background thread) that access the singleton initializes

bulletproof+ should move to that style or call_once because both are a bit faster than the current version which always acquires a lock iirc

vtnerd: ah I see; yes I already moved BP+2 to use call_once (new proof to use the generator factory for batching with grootle proofs): github.com/UkoeHB/monero/blob/0c56c…eraphis/bulletproofs_plus2.cpp#L114

while my wallet are synchronizing,i create an address of recive and i send the xmr to the address.after it synchronizing the address disappear.and i didn't recive the xmr how do i do?

just synced 90k blocks in 4:15 min

ok

oh sorry wasnt talking to you, just dropping info

oh

this isnt dev related, could you maybe post it in GUI?

GUI?

#monero-gui:monero.social

i found the address

but the xmr not arrive

i send xmr to wallet

from binance

binance says it's success but not in monero wallet

Double check your refresh-from-block-height (also called restore height IIRC) is lower than the block height at which you got your tx. If it wasn't, set it so and rescan the chain.

And wasn't this bug fixed already ? It's happening a lot recently...

Oh. did you restore your wallet from seed or keys ?

moneromooo: yes

That's probably it then. Were you asked where to start it from ?

where's refresh-from-block-height

You're using the GUI ?

yes,i'm using the gui

One min...

Found it: < moneromooo> < woodser[m]> monero-wallet-gui > settings > info > Wallet restore height

Set this to a bit before when you originally created that wallet. 0 is safe but slow.

That also explains why your subaddress disappeared, if you nuked the data and recreated.

i find it, set a new restore height

mine is 2669025

the current hight is in the txhash?

No.

If your imssing tx is a few days old only, use 2660000.

If it's older, remove 750 for every day and you should be safe.

it's today

Then a rescan wiull find your monero.

i can use 2660000 too?

Yes. Safe for today.

A bit overkill but hey.

Oh wait.

Your refresh height is already low enough, looking at current blocks.

So maybe that is not your problem after all. Try it anyway, though.

i change it to 2660000

if it's not my problem then anyway to find the xmr back?

Next step, shuld have been first but... chek you're using monero 0.18.x.y.

If not, you need to. The network forked recently.

my monero version is0.17.2.3

should i download the newest version?

Yes.

The versoin you have cannot read new txes.

i see,maybe that's the problem

Your daemon should show not 100% synced, but 99.x% or so. After updating, it should go to 100%.

emm. I use the 0.18.1.0

have no new txes too

the same

Sigh. Debugging and fixing a bug, updating master to make a PR, and finding it's already fixed in master...

Is your daemon done synciung already ? Does it show 100% ?

(run "status" in monerod)

>>> status

[2022/8/19 16:28] 2022-08-19 08:28:32.299 I Monero 'Fluorine Fermi' (v0.18.1.0-release)

Height: 2688925/2688925 (100.0%) on mainnet, bootstrapping from 143.244.146.35:18089, local height: 1 (0.0%), not mining, net hash 2.63 GH/s, v14, 0(out)+0(in) connections

it's 100%

You have no peers (ie, you are not connected to the monero p2p network).

Wait some more. Current height is 2692xxx

do i need to restore the height?

Your height seems fine.

It is often the cause, so I went there, but I was wrong.

2688925, ..., v14 is definitely wrong

you're syncing off old node

you have to connect to a good working node and sync again

how to do in the gui

Just wait. Unless your db is borked or you're hemmed in by sybils, monerod should eventually find a good peer.

Or you can exit monerod, rm ~/.bitmonero/p2pstate.bin, and restart.

wait until monero sync success?

Yes.

What does "Couldn't allocate RandomX cache" erro mean in monerod? Forces exit and terminal then doesn't respond

*error

Mac? Os version? What block?

Yes, Mac. 10.11.6 (old laptop). I am trying to sync from 2676794. Says I am 16202 blocks behind.

How old is the laptop? Does it support max os 10.15

ofrnxmr[m]: 2010, so no. It's on the latest OS it supports. It's a dual core Intel. Is 10.15 a minimum OS requirement for CLI since the recent upgrade?

is trezor ready yet?

midipoet: I believe so hyc: can you confirm?

Another user had the same issue. Im not sure if it was resolved

Trezor is ready, but iirc is a staged release (perhaps not pushed out to everyone)

testing #8513, I start monero-wallet-rpc with `--daemon-address=""` or no parameter at all, but monero-wallet-rpc initializes a default daemon connection if none is provided at startup, so there's no way to keep it an offline wallet unless a dummy daemon value is provided? github.com/woodser/monero/blob/727b…dc685c8/src/wallet/wallet2.cpp#L393

--offline doesn't work ?

ah didn't try that

yes that works

Hello! How can I increase the number of peers to my node? Now I have 20 incoming and 12 outgoing connections.

What max peers I will get if I do not specify "--out-peers" and "--in-peers" node launch parameters (default value of this parameters =-1)?

--out-peers defaults to 12, --in-peers defaults to unlimited IIRC.

What values of these parameters should I set for the mining pool node?

alshippd[m]: follow the steps in this comment: monero-project/monero-gui #3989#issuecomment-1214412781

midipoet: can you check out if this works? monero-project/monero #8504#issuecomment-1216186718

Is it possible to prevent rescan blockchain again when monero-wallet-rpc is starting?

>2022-08-19 19:48:30.309 7f8fa6e567c0 WARNING wallet.wallet2 src/wallet/wallet2.cpp:2210 Received money: 5.080102295000, with tx: ....

Yes, --offline

> <@rogu157:matrix.org> Is it possible to prevent rescan blockchain again when monero-wallet-rpc is starting?

>

> >2022-08-19 19:48:30.309 7f8fa6e567c0 WARNING wallet.wallet2 src/wallet/wallet2.cpp:2210 Received money: 5.080102295000, with tx: ....

You shouldn't need to if you shut it down with Ctrl+c or normal terminate signal

I think

"store" saves the wallet state (close_wallet will also store before closing)

RTFM getmonero.org/resources/developer-guides/wallet-rpc.html

I'm using systemd to control monero-wallet-rpc. Source: paste.debian.net/hidden/eff126ff

After restarting monerow.service: `systemctl restart monerow`, monero-wallet-rpc start scanning blockchain again, but it did and finished it before restarting service.

selsta: excuse my ignorance, but to start monerod with the environment variable, is the command just "./monerod MONERO_RANDOMX_UMASK=8"?

other way around

MONERO_RANDOMX_UMASK=8 ./monerod

Will try now

seems stable so far, will let run and see if I can catch up without the error appearing.

I have a stagenet .keys file here from a multisig wallet created in a haveno trade, which I cannot for the life of me get to recognize the transactions sent to it. if I manually create a view-only wallet with the view key and address, it scans and finds the transactions no problem. but if I open a wallet with the .keys file, it correctly reports the address and view key, but no transactions. I've tried deleting the cache, opening with a

low restore height, calling rescan_spent, and rescan_blockchain, but no transactions. I don't see anything wrong when the wallet was created, but seems corrupted?

possibly it's because my binaries had #8513 and my peer's did not, but I don't know if the .keys file would be affected

vtnerd: ok I'm satisfied with this solution github.com/UkoeHB/monero/blob/db980…aphis/sp_generator_factory.cpp#L100 you are right that centralizing the bounds check is better