I was directed here to find a full stack developers who have Monero integration experience. We have a project which can stop this authoritarian great reset takeover and it's not an understatement. One of the goals is it incentivize businesses and the masses to adopt Monero which is how I got directed here. We have a crucial window to get this launched before the USD is hyperinflates and CBDC is presented to the public to get adopted.

I'm not the best marketer but if you are qualified and you prefer not to eat cricket sandwiches please reach out

I was directed here to find full stack developers who have Monero integration experience. We have a project which can stop this authoritarian great reset takeover and it's not an understatement. One of the goals is it incentivize businesses and the masses to adopt Monero which is how I got directed here. We have a crucial window to get this launched before they hyperinflate the USD and present CBDC to the public to get adopted. I'm not

the best marketer but if you are qualified and you prefer not to eat cricket sandwiches please reach out

I was directed here to find a full stack developers who have Monero integration experience. We have a project which can stop this authoritarian great reset takeover. One of the goals is it incentivize businesses and the masses to adopt Monero which is how I got directed here. We have a crucial window to get this launched before the USD is hyperinflates and CBDC is presented to the public to get adopted. I'm not the best marketer but if

you are qualified and you prefer not to eat cricket sandwiches please reach out

// create offline wallet... (full message at libera.ems.host/_matrix/media/r0/do…7991da2ba4aba8ce45bd7c59a27fa0bc655)

I used this snippet of code to generate key images offline. However the last line `const keyImages = await offlineWallet.exportKeyImages(true);` throws an error: TypeError: (intermediate value) is not iterable.

Anybody knows what possibly causes this error?

It seems this line throws the error.

`let that = this`

Ah, js.

walraven[m]: I am bit skeptical that you will get much attention here with alluding to cricked sandwiches and great resets. I think people here are pretty fact-oriented, and some hard facts about an attractive project would make more waves IMHO.

*Cricket sandwiches of course, silly me :)

<willshu[m]> "Screen Shot 2022-07-22 at 12.33...." <- woodser: this should probably handle null values before calling .keyImages, but will.shu are you sure you're generating the wallet correctly? Do other full wallet methods work as normal?

cryptogrampy[m]: / create offline wallet... (full message at libera.ems.host/_matrix/media/r0/do…3ef74152803311ee58e15c95b92c63ea7a1)

I use this method to generate a wallet. What does it have to do with this error? Sort of confused right now.

It works until recently. Just wonder what the cause of this error is, and why the error has anything to do with the way I set up the wallet.

<cryptogrampy[m]> "woodser: this should probably..." <- Besides, the outputsHex should give two keyImages, why would there be null values. I cannot reproduce the error on my own machine. Do you know how to reproduce the error?

It is happening 100% on the remote machine. So it is not a random bug. But I cannot reproduce this error on my own machine. Does anybody know how to reproduce this error?

#monero-dev,,

I was wondering, when view-only wallet calculates and exports outputsHex, does time matter? because our machine with view-only wallet on it may not have the correct time because it does not sync with the internet very often.

* the internet time very often.

It does not.

moneromooo: then do you know how to reproduce the error on my local machine - `TypeError: (intermediate value) is not iterable`. I tried to modify a character in the outputsHex or make privateKey `null` but cannot reproduce the error.

With a pair of private key on my local machine and outputsHex from a view-only wallet based on this private view key, I cannot reproduce this error by modifying a character in the outputsHex or modify the private key. On the remote machine, the error is 100% reproducable, but since I do not have the private spend key of that machine, I cannot predict what causes the error.

* With a pair of private spend and view keys on my local machine and outputsHex from a view-only wallet based on this private view key, I have the correct outputsHex and cannot reproduce this error by modifying a character in the outputsHex or modify the private key. On the remote machine, the error is 100% reproducable, but since I do not have the private spend key of that machine, I cannot determine what causes the error.

<r4v3r23[m]> "i got a bunch of sendto: Operati..." <- pastebin.com/m0LX5Saw

That looks like a javascript error, not a monero one.

moneromooo: I suppose so, but we specifically try catch this error, and it is thrown from a monero-javascript line of code.

Well, I don't know javascript much at all, so find someone who does. Or I suggest peppering prints of typeof(var) (or js equiv) to see if they're really the types you expect.

The error is: `exportKeyImages Error: TypeError: (intermediate value) is not iterable`.

I'd also check versions of js interpreters and dependent libs used on both machines, and compare.

E status == CORE_RPC_STATUS_BUSY. THROW EXCEPTION: tools::error::daemon_busy . What causes this problem? I've checked ports and seems ok

daemon status: Height: 1140979/1140979 (100.0%) on stagenet, not mining, net hash 3.80 kH/s, v14 (next fork in 13.9 days), 1(out)+0(in) connections

Did you have a peer at the time ?

Oh hey moneromooo, what do you mean with peer? Last daemon messages: [47.4.62.89:38080 OUT] Sync data returned a new top block candidate: 1140979 -> 1141143 [Your node is 164 blocks (2.7 hours) behind] and There were 102 blocks in the last 90 minutes, there might be large hash rate changes, or we might be partitioned, cut off from the Monero network or under attack, or your computer's time is off. Or it could be just sheer bad luck.

I mean another monero server to which you could sync.

NakedKing: do you see blocked peer messages?

yes selsta ; 2022-07-22 00:48:09.634 I Host 47.4.62.89 blocked. and more of this

moneromooo, I'm running daemon and wallet on localhost

where is your blockchain stored?

at my harddisk

external / internal? did you have a power loss?

seems like corrupted stagenet blockchain to me

nope, it was working yesterday. no conditions has been changed in this time

if it stops verifying blocks and blocks all peers

can a network problem cause this problem?

no

did you ever get higher than 1140979?

Thanks. I've weird problems on my network. First thing gonna try at another one. If wont work i will re-syncs whole blockchain :(

Last sync message: Sync data returned a new top block candidate: 1140982 -> 1141147 [Your node is 165 blocks (2.8 hours) behind

If it stays stuck on 1140979 it's a corrupted blockchain, if it slowly gets higher than 1140979 than maybe network issue.

then*

It seems if `keyImagesStr = {"keyImages": null}` then it will throw an error: `TypeError: (intermediate value) is not iterable.` Anybody knows under what circumstances the offline wallet will return `{"keyImages": null}` instead of `{"keyImages": []}`?

Just check it for null on javascript side

Maybe if it returns an error. Check the (level 2) logs.

(assuming this uses wallet2)

Is there a painless way of disabling easylogging++ in monero's build? (Trying to include/link wallet functionality via monero-cpp, but getting build errors due to already using a system-wide installed easylogging++ that has a different version.)

<moneromooo> "Maybe if it returns an error..." <- We use the monero-javascript library to export the images.... (full message at libera.ems.host/_matrix/media/r0/do…9c2bc8c0bc558621075a9d3479f793bfa05)

<sech1> "Just check it for null on..." <- This is from the standard library so I cannot simply modify it. Besides, the function is supposed to return at least two keyImages, why would it return null?

jozsef[m]: you could try removing it from the link lines, then defining all the stuff in misc_log_ex.h to ((void)0).

In what way is it interfering with a system one though ? This implies it's not setting include/link paths correctly.

monero-cpp's include (which I am including) includes `utils/misc_log_ex.h` which picks up monero's `easylogging++.h` but that's already downstream of my system's `easylogging++.h`. It looks like:... (full message at libera.ems.host/_matrix/media/r0/do…c9ee2879d0051223d251b33223ee37dad77)

* monero-cpp's include (which I am including) includes `utils/misc_log_ex.h` which picks up monero's `easylogging++.h` but that's already downstream of my system's `easylogging++.h`. It looks like:... (full message at libera.ems.host/_matrix/media/r0/do…70c9ca8218d1a0cbb95a715860e824690f6)

At least this is my suspicion.

OK, we have nohting in utils. Does it also happen with monero of just monero-cpp ?

If I'm correct, one way would be to allow monero to detect and pick up the system's easylogging++.h if installed.

Not compatible. I've changed it to have sane categories.

Ah, it is a patched one, that's what I was afraid of. ;-)

Beware the programmer with a keybaord...

Of course first I just tried to use that, but attempting to configure easylogging++ following their docs just wasn't producing the correct behavior. Now I think I know why. 😀

does the cli wallet restore the payment id when deleting the wallet cache? monero-project/monero #8378

hyc: please open 8379 against release-v0.18 branch

It can't, as it doesn't have the secret key for it.

selsta: done, monero-project/monero #8454

ty

how about monero-project/monero #8381 ? It would be nice to have it in the next point release

381?? the wallet files are already encrypted\

doh, somehow that msg mis-rendered here

8381

I'll prepare the PR anyway

PR'd in monero-project/monero #8455

sech1: will add 8381/8455 to the merge queue, can you approve monero-project/monero #8415 ?

Right, I forgot to approve it when I checked it

👋

Hello

<willshu[m]> "It seems if `keyImagesStr = {"..." <- please let me know if you can recreate the issue. I don't know how keyImagesStr would return {'keyImages': null}, since the key_images vector is always initialized in monero_wallet_full.cpp::export_key_images, but if there's an expected path for that, we can easily add a check in the js library

Apprentice lol

Trying to build Monero v0.18.0.0 on my local and I'm getting to 98% but I'm getting this error - pastebin.com/31QcXgAv - can anyone please help me? I'm sure I'm just missing a dependency?

Looks like your distribution's libnorm links against something we've not seen before. Find which lib those Proto* symbols are from.

protobuf most likely

sudo apt install libprotobuf-dev protobuf-compiler

sech1 - they're already installed

Then it needs adding in CMakeLists.txt, look for set(ZMQ_LIB "${ZMQ_LIB};${NORM_LIBRARY}")

and do something similar.

NORM_LIBRARY is defined a half sozen lines above. Duplicate it too.

Lost connection there for a second

I just found this issue from 2020 - monero-project/monero #6821 - I'll take a look and see

cpt_pi30: easiest way would be to build using depends, but you need x86_64 host for that and ubuntu 18.04 / 20.04

I've gotten it working with build depends, but I'm trying to do a multi-arch build and the aarch64 build takes ±6 hours - which causes github actions to kill it

Let me correct that: I've gotten build depends working for x86_64

aarch64 ran for ±6 hours and got kicked by github

aarch64 build takes so long because it's docker on qemu on a x86_64 vm - virtualization inception

Tried to build Monero with mkdir -p build/release; cd build/release; cmake -D ARCH=native -D BUILD_TESTS=OFF -D CMAKE_BUILD_TYPE=Release ../..; make -j4. I get a flood of undefined reference CryptonightR_instruction213, and a few from RandomX too.

<rbrunner> "walraven: I am bit skeptical..." <- Making light of the situation. But yes the great reset involves controlling the currency with the CBDC they plan on implementing, control the food by controlling points in the supply chain for fertilizer and owning the farmland, controlling the housing (they already own 1 in 7). Then when people are starving from the controlled collapse they'll dangle central bank digital currency, a

universal basic income, and an esg social credit score to eat. Then you'll have to get the 8th sterilization booster and have the correct views on abortion else your esg score goes down and you're subjected to exclusionary measures like not being able to travel, or can't have certain jobs, or they turn your cbdc off after 5pm or you're only allowed to purchase 1 cricket sandwich a week with it. Total control. I'm just repeating what

they're publicly stating. And to call it a conspiracy is to call your mom a conspiracy because it's already 95% here and implemented

I also can't find this discussed anywhere else, so seems to be some stupid quirk. Anyone have ideas?

walraven[m]: If you are building something really interesting and innovative you will probably get interest here, and you may find a Monero dev ready to work with you or for you.

So, are you? If yes you may tell.

By the way, this is the channel to discuss dev-related topics, world view discussion might better go to #monero, if anything Monero of course ...

kayabaNerve: do you have local changes?

No

we didn't touch CryptNightR in years

what OS?

what hardware? did you build monero before on that system?

Arch. AFAICT this works on Ubuntu, as I was trying to get a CI build up. The CI build works. Now my local system doesn't

It's my dev laptop I just had Monero on using the standard `make`

the command you posted looks correct

I just had to split the commands up so I could pass `-D ARCH=default` for CI and... now my laptop doesn't like me :

*:/

Yeah. I'm not expecting help, just more suffering lol. Just had to ask in case there was help

i would try a fresh clone

Did that

VERBOSE=1 make

check if there is anything obvious

Try to find the exact cmake command line during the regular build

... it may be as stupid as `-D ARCH="native"` vs `-D ARCH=native`.

That change, which I never would've assumed to matter, managed to trigger a rebuild.

No idea if it'll work though. I'm just hopeful given how stupid this is

... wow. That was it, at least on my fresh copy.

I hate C++ .-.

Thanks for being helpful as always, selsta

oh, didn't look close enough at the missing quotes lol

fun error

It wasn't the missing quotes. It was the additional quotes

Apparently, that'll bork something on Arch

Tbc, I don't believe this is legitimately C++ eco. It may be some zsh/bash quirk (I'd have to double check if these commands even went through my shell). I'm just frustrated C++ build tools couldn't identify this and let it propagate into extremely obscure errors D:

It's not obscure errors. It just tried to use x64 code because it didn't know about "ARCH=native"

CryptonightR_instruction213 and others exist only when compiling for x64

walraven: Better to make your pitch in #monero-community-dev:monero.social

selsta moneromooo, got the build to succeed with Debian 10 rather than 11 🤔

.merges

.merge+ 8415 8451 8454 8379 8444 8442 8419

Added

<rbrunner> "By the way, this is the channel..." <- Trying to give background on the purpose. If anyone is interested in helping please reach out to me privately

fluffypony: thanks for checking the DNS stuff, did you get to the bottom of it?

binaryFate: I can't see any issue on the setup on our side, so no

is it broadly an issue or just for some?

not sure. selsta: you reported issues for ages, do you know?

it happens on various ISPs so not sure if it's an ISP issue

I get "16 valid signed result(s) for updates.moneropulse.org" here. So it looks like some downstream problem.

<sech1> "It's not obscure errors. It just..." <- 1) ARCH="native", in case that makes a difference

2) This is a x64 laptop. If it's compiling all of Monero, not as native, but as x64, it should've successfully compiled. My guess is half of it compiled as x64 and half as native or so :/

Am I supposed to be able to click on that link? Should something load in my browser?

.merge+ 8323

Added

if I set my max out_peers to 24, how long should it take for the out connections to go up to 24?

my node was at 10 outs and suddenly 6 minutes later it jumped up to 24 out peers

Ill increase right now and see what I get.

24 original 36 new

2:35 to go from 24-26

to me it seems like my node only tries to connect to out peers every X minutes

don't know if that's intended behavior

There's no particular intended rate of increase.

fluffypony: binaryFate: regarding DNS, I get the warning on Hetzner and Linode, but with my home ISP I don't get the DNSSEC warning

I get the DNSSEC warning right now, from ISP "Bell Canada". I'm traveling so I don't know if it's always the case with this one