i saw monero exist in debian rep however i am yet to reproduce build

is anyone here?

at all

ArticMine: ?

...

alot are asleep right now, give it several hours

Yesterday moneromooo cooked up a small C++ standalone program using Monero code like stuff from epee and crypto-ops.h: paste.debian.net/hidden/e0f00deb

What's the simplest way to compile, link and run something like that?

I checked how MoneroExamples was doing it back in 2017, and collecting the .a files and the .h files seems quite complicated: moneroexamples.github.io/access-blockchain-in-cpp

I am sure there must be a much easier way for such trivial programs, right?

g++ -I src/ -I contrib//epee/include/ test-mul.c build/Linux/cc/release/src/ringct/libringct_basic.a build/Linux/cc/release/src/crypto/libcncrypto.a build/Linux/cc/release/contrib/epee/src/libepee.a build/Linux/cc/release/external/easylogging++/libeasylogging.a -lsodium

And then just ./a.out, it doesn't take any parameters.

Thanks. Surprising.

What is ?

And with slightly more complex programs just adding -I and .a until the linker complains no more.

Yes.

For complex ones, I usually put the command line at the top in a comment :)

It's suprising on how primitive a level you do this, at least for me.

But well, this is new for me, maybe that's my problem.

As in... brute force ?

So the MoneroExamples approach to collect *all* .h and .a in some directories or directory structures to access them easily actually is not that dumb

Other than probably constantly produce errors by forgetting to update the copies after compiling Monero :)

On testnet, binaries DL'ed from p2pool v0.18, in CLI, I can't use `set` command:

[wallet 9uYsHx]: set ask-password 0

Wallet password: Error: failed to read wallet password

[wallet 9uYsHx]: viewkey

Wallet password: Error: failed to read wallet password

When the inactivity timeout hits, I get never ending :

Locked due to inactivity. The wallet password is required to unlock the console.... (full message at libera.ems.host/_matrix/media/r0/do…38ae2739dea7f16d7a40250ef8b3e7054e9)

When not launched in a screen session, it works.

and v0.17.3.2 doesn't have this problem?

I'd be worried given the password is read in raw mode IIRC.

NO, v0.17 release don't have this problem.

A wallet created before v18, opened in v18 don't have the problem.

so the problem is password input doesn't work in screen session?

how did you even open the wallet in the first place?

it requires entering the password

--password 'password'

that's not safe, everyone can see it in htop or other tools

If used in screen (and it works), the password is bound to end up left over somewhere in memory...

I know, but I'm only on stagenet and testnet.

so it shouldn't work in screen and it's for safety. v0.17 was broken then and v0.18 is correct?

Well, I can open the wallet, halt the the output with ctrl-s, enter the password, resume ctrl-q. This is the inactivity-timeout thing.

the set commands complain the password can't be read: `Wallet password: Error: failed to read wallet password`

So a password in a config-file is considered secure?

In the same way as a bundle of notes in your home is secure. Do you leave the bundle on the table with an unlocked door ? Or hide it somewhere in a locked safe ?

Same here. If someone else has root on that machine or the hypervisor, or if you set read rights to group/others, it's not very safe.

"If someone else has root on that machine " in that case I would be in trouble. I'm the only user on the host/hypervisor and all guests/vps.

moneromooo: any ideas why make is failing on debian when compiling cli wallet?

now its day time in europe

can someone address a question lol

why its some fucking complex?

should just compile

*so

If you're polite, maybe I could look at a paste.

all it does is

fatal: path 'external/miniupnp' does not exist in 'HEAD'CMake Error at CMakeLists.txt:273 (message): Submodule 'external/miniupnp' is not up-to-date. Please update all

resynching does not work

Try:

git submodule sync; git submodule init; git submodule update

Then make again.

If it complains about external/miniupnp being not up to date, dirty, being unable to pull, etc, then:

cd external/miniupnp; git reset --hard; cd -

Then:

git submodule sync; git submodule init; git submodule update

Then make again.

will try now

This assumes you have made no modifications to external/miniupnp: if you have thy'll be lost, so save them first.

also all deps including vendored are built from source right? i did check deps makefile seems so

Depends. Some are fallback IIRC.

what do you mean by fallback?

To be used if one is not found on your system already.

yes of course

those fall back ones are all compiled from source?

From hte monero repo, yes. IIRC on Mac they use some binary SDK from apple.

well i am using monero repo

also have you tried cake wallet? i did sent a bit of btc here, connecting via tor exchange is yet to work

No.

I believe it uses wallet2, so it'd log if you set logs up, in case it's an error from our code.

okk

maybe exchanges have min amount to swap?

i will check later on soon

If they don't have a setting for logs, you can run with hte MONERO_LOGS=2 env var.

cool

github.com/monero-project/monero/tree/master/src is this a code for all deps?

in depends make file SOURCES_PATH ?= $(BASEDIR)/sources

no such dir

cake wallet no logs setting

moneromooo: can you suggest any btc xmr exchange that does not use js

then i dont need cake wallet :)

No. Ask in #monero. I thikn theres also a #monero-markets for this.

Hi. Wanted to know if running monero daemon on "my own VPS server" and connecting to it remotely on a port, will have any advantages in speed & reliability than running monerod on my local machine?

I wanted the block sync to be on 24x7 and my local machine isn't on all the time.

The VPS is likely always online, so never has to catch up when you need it.

Your advantage is in the "on all the time"...

Of course a lan/local node will be faster

In terms of sending/receiving transactions from my wallet (on host machine), would there be visible delays, with above approach e.g. if I use VPS for daemon.

Syncing your wallet, yes

Send/receive, no

The VPS's owner will be able to see which transactions you send.

if app did require some libs where would it store them after make is done?

user85: xyproblem.info

moneromooo: That's a good point. Thanks.

Are you asking "where does the monero build system put its files ?" If so, in build, where you ran cmake.

Which doens't have to be even called build, but I guess you know that if it's your case.

i did run a search for libunbound

afungible: "my local machine isnt on all the time"

Spare Android devices work

there is on in ./external nothing in built

build

Are you sure you have no libunbound on your system already ?

Oh, I also remember it got removed recently, in favour of always using the system version.

i am using later version 17

latest

find . -name "libunbound" only shows one file in monero ./externak

./external

You want \*unbound\* to be sure.

<user85> "fatal: path 'external/miniupnp..." <- im getting same issue. i had to copy miniupnp from prev build but now its says cant find libunbound

i also get this error: `make: *** [Makefile:139: release-static-android-armv8-wallet_api] Error 1`

Did the issue survive submodule sync/init/update ? If you did not try it, do so.

<moneromooo> "git submodule sync; git submodul..." <- doing this give me empty miniupnp folder

cd external/miniupnp ; git checkout master; cd -; git submodule update

(and check you're not out of disk space)

ok i have found what I wanted to find

github.com/monero-project/monero/bl…contrib/depends/packages/unbound.mk :)

is was there all along

moneromooo: miniupno/randomx/rapidjson/supercop are all empty folders

Even after checkout ?

yes

ls -a external/miniupnp

Does this show a .git directory ?

you need the --recurse flag on the submodle init IIRC

moneromooo: "external/miniupnp": No such file or directory (os error 2)

Did you make a typo in "miniupno/randomx/rapidjson/supercop" ? ie, s/o/p/ ?

If the directory is here and seemingly empty but ls -a causes that error, your filesystem is likely FUBAR.

How did you check the directory was empty ? Not ls ?

filesystems fine, works fine on 0.17.3.2 branch

ok miniupnp folder lists a load of files now

`CMake Error at CMakeLists.txt:113 (message):

Could not find libunbound`

gettng same error as user85

not same

:)))

also you can compile libunb

nlnetlabs.nl/downloads/unbound choose latest and make

haha

Or install from your OS repo, it likely has it.

(the devel version)

moneromooo: which exchange do you use?

moneromooo: yeah i already have unbound installed

user85: #monero exchange

Monero will want the headers, some distros dump headers and require instlaling a -dev/-devel package on top to have a non kneecapped version.

<moneromooo> "No. Ask in #monero. I thikn..." <- Stop asking questions already answered

ofrnxmr[m]: no one replies there

* user85:

Try #monerotopia:monero.social

IF you do have the headers and they're still not found, try removing any CMakeCache.txt in the build tree. cmake can be a pita with that cache.

moneromooo: how do i check if i have headers? i dont see any CMakeCache.txt files

Run the full node and wait until it syncs up with the network (may take up to a few days - can I connect to some extrernal server instead? how many gb is chain?

here's the error output after fixing miniupnp: pastebin.com/pscKKGZX

submodule update/sync doesnt grab unbound

r4v3r23[m]: check for /usr/include/unbound.h

user85: IIRC abot 130 GB, very roughly. More like 45 if pruned.

moneromooo: not too bad

currenly using torsocks cli random node :)

r4v3r23[m]: unbound was removed from the monero tree recently.

moneromooo: yep i got it

how many transfers from 1 address to another is enough to make funds untraceable?

so what am i missing here

i will be sending monero from exchange to local monero running here

user85: wrong room

r4v3r23[m]: wrong answer

good luck with such attitude Xd

You too.

manners

;)

Good luck with such ignorance, this room is for dev related matters, not a tech support

Ask in #monero

there are diff ways to say it

lol

It has been said by 5 different people.

Wrong room. Ask in #monero

WE might answer you there. We also might not.

How can i contact operations manager of montero?

s/montero/monero/

u gotta call corporate

Hey, any idea when we release v18.0.0? Were 1 month out

Huobi etc planned to close withdrawals today due to confusion

we have binaries already, i have to write release notes and then bF has to upload them to the website

bf?

binar yFate, someone from core team who can update the website

aha

Bf = my bestfriend....

selsta: yea, my build took 17 hours :) lolol. Also did master-beta for android

Awesome, so possible today?

Possibly*

what's new in 18.0?

Larger rings. 16 members instead of 11.

- View Tags (decrease wallet scan/restore time by up to 30%)... (full message at libera.ems.host/_matrix/media/r0/do…a69352874b05e6e6a49e1d567186a340d5b)

bulletproofs+, and most important one, the Monero GUI now displays wallets that have a "." in their name (and finally has scan_tx feature added 🦄)

ofrnxmr

"time to build a transaction decreased by 80-90%" - this is that DNS thing right

Yup

That is dishonest since it just cuts a timeout if your DNS was borked.

Wait, that's what it was, right ?

No, no dns anymore at all

Previously 9c with dns (first request) second would not ping dns and would he 1-2seconds

Are you suggesting it was very slow even if your DNS was working properly ?

Over tor, 1-5minutes of constantly trying to connect to dns, is now simply skipping dns entirely and connecting to your node, downloading the 1.5mb which is under 9sec seconds which includes onion latency etc

Oh, tor.

moneromooo: With dns working correctly, yes, 10-20seconds

Ah, yes, I remember the discussion.

With no dns 3sec

Still dishonest, tor use is so dependent on your circiots.

20s to 3s is 80-90%

I mean, it's like putting your chain on a floppy and saying monero's slow to read from the db, right ?

People will read this and think we somehow optimized stuff madly, and we didn't.

Nono. Over clearnet is slowed immensely too

Hmm. OK. Why ?

No idea. Makes like 15 connections before trying to get the data from the node

So nobody tried to fix it, just removed and claimed a speedup ?

I mean, I didn't try to fix it either, but I'm not trying to put lipstick on a pig.

The moneropulse dns ping is a privacy leak

Irrelevant.

My point is about the misdirection.

It's not honest.

But, if you're saying it was slow in the normal course of things, with working DNS, then OK, I think you're right on second thought.

Feather wallet has had their dns calls removed for a year, which isbwhybfeatherbusers dont see the UX speed issue

I didn't realize that, and it is what should be fixed. So I changed my mind, sorry, speedup's OK in that case.

Sorry, I get a bit twitchy with disingenuous claims. I rememver someone claiming N% tx verification speedup, but that was on a cherry picked case that's uncommon.

No problem :)

Yes, over clearnet was slow as well. I believe Seth was timing 23 seconds over clear with dns enabled, 3 seconds with --no-dns

why those DNS calls where in there in the first place is beyond me

On the node too..

--check-updates

Calls moneropulse

So I was like what tha fack

I disable dns checkpoints, disable dns blocklist, run over tor

Check logs and my node is making internet connections over dns to moneropulse.

'Ile STOP THIS BS

My node supposed to connect to other nodes.

Tldr. 🚮 that shit dont fly in my monero

huh, never seen this before: paste.debian.net/hidden/a277105f

this is v0.18 binary

Cool.

sech1: fwiw no issues on my end

That will be the size of the blockchain in the year 3000.

my node keeps running fine

sech1: sounds like an invalid tx?

The last line is from 5 seconds later, it's probably unrelated

15:49 <r4v3r23[m]> "time to build a transaction decreased by 80-90%" - this is that DNS thing right <-- that was just the case with some weird DNS setups

i never had any delay with DNS enabled

sech1: ok, i did see similar portable storage messages months ago, it's likely someone playing around with source code. should be harmless.

selstawas v0.18 build tested on arch? im getting an error with unbound even tho i have it installed

error with release binaries? or custom installed?

im using master branch to update monerujo and it fails here: pastebin.com/pscKKGZX

we removed the unbound submodule because it was outdated and full of security issues (they had an audit). this will be annoying once for those who depend on it but then it shouldn't be an issue anymore in the future.

how do you build monerujo? do you have unbound in ${PREFIX}/lib ?

selsta: i do. headers as well in usr/include

i applied m2049r's monerujo diffs to the v0.18 code, linked that to monerujo external-libs, and then run make there

UNBOUND_LIBRARIES UNBOUND_INCLUDE_DIR exist as cmake options

you can also try to set `UNBOUND_ROOT=${PREFIX}/include` env var like you do with `CMAKE_INCLUDE_PATH`

but not sure if that's enough

hm, my i2pd keeps dying

<selsta> "you can also try to set `UNBOUND..." <- in `monero/CMakeLists.txt`?

r4v3r23[m]: try the env var as a first step

The DNS calls for monerod were a safety measure for forks from bugs. Never got used in practice. For monero-wallet-cli, defence against some asshats who forked the chain to a scam and tried to get people to spend their coins twice with different rings (unless that was just a side effect of the scam).

The latter is not needed anymore. The former... well... never needed so far :)

The latter got added in a hurry to protect people who tried to use the scam as it was were not one, since them spending twice with different rings would weaken everyone else's rings that used their coins.

Sordid shit. But obsolete now. I wouldn't mind seeing this code gone. It's too complex.

wondering if there's a way we can leave the code in, disabled, and only activate it near a hardfork

That'd keep the complexity. And we need it when some asshat reuses the chain, not when we fork. Less likely now I guess, with a 130 GB chain :)

I just assume it's most common for "classic" chains to spring up right after a hardfork

On mainnet zmq_pub I got this:

[... (full message at libera.ems.host/_matrix/media/r0/do…8cfe894e905f250883b1c5faa335e2cea8a)

* \[... (full message at libera.ems.host/_matrix/media/r0/do…3a2eeb10a81a914a4e2641dcc7abf9eb3fd)

What am I looking at? Emty transactions?

i looked at one of them, they look like a regular tx on xmrchain, no idea why it says blob_size and weight 0

that's an old issue

Some transactions don't get proper zmq notifications. It's rare, p2pool just ignores them when it happens

Oof, that's inconvenient. I was gonna add zmq support to my payment gateway lib, but missing payments would be a big deal. Is that documented anywhere yet?

but it's not missing from what i can see? just some data seems missing (blob_size / weight)

Is the rest of the data correct even though the size and weight are wrong?

The rest is correct

IIRC blob size and weight just don't always get filled in

in the place where zmq takes data from

<selsta> "r4v3r23: try the env var as a..." <- having an issue setting it. looking into it

when the DNS discussion recently happened I tested with the -no dns flag, local node on same machine, all other settings were default

there was no change in transaction generation time

for each transaction I made sure nothing was cached

re: anonymizing networks and sybil attacks sciencedirect.com/science/article/abs/pii/S1389128615004168

in other words, to fix issues with a decentralized and trustless network, let's introduce trust and make it centralized

yeah maybe their solution isn't the best available, but the references to related work is useful

and trust doesn't mean centralized. PGP trust isn't centralized.

sech1 BusyBoredom[m] : there are missing txes? this shouldn't happen unless the tcp conn maxes out

my expectation was that this would only happen during syncing, its basically just blasting txes over zmq in that state

are you referring to zmq notifications with 0 tx blob size and weight reported?

no, I think it's just some bug with the source of zmq data, transactions themselves are not missing

I saw a comment about missing txes, but it wasn't clear that this was in reference to these empty txes or a larger set

the tx were not missing, data was missing

ah crap I don't even know how that would happen atm

blob_size and weight, fee and txid was correct

vtnerd__: no missing txs, I was just concerned that the data coming over zmq might me malformed enough that an application consuming it would end up missing txs.

the first two were missing*

yes, if the receiver cannot keep up there will be drops

the only way to detect this it to monitor the chain publications, and check hashes

the chain pubs will always have seqence number and prev_hash to keep track of state

yeah the missing data is the concern, I don't see how that would happen, unless it was a copy-constructor/copy-assignment error or something :/

vtnerd__: sample log libera.ems.host/_matrix/media/r0/do…8cfe894e905f250883b1c5faa335e2cea8a

only the last two tx have all data

ah thanks. its irritating that this was the truncated mode, so less info, but thanks

I just checked my p2pool logs (I keep everything) and it's a very rare occurrence, at least on my node: paste.debian.net/hidden/07b64b9d

So it didn't happen at all since October last year

But id does seem to happen when many transactions pop up at the same exact moment. Maybe after a reorg?

Okay, it looks like it happened around the same time I restarted my Monero node and "SYNCHRONIZED OK" message appeared in bitmonero.log

and I restarted it several times on Oct. 2 at that time, not sure what I was doing :D

IIRC I popped blocks to fix something with my node

yeah and whats interesting is that some in that array have dat

because that array chunk should be a single call into the zmq_pub code (the zmq_pub code doesn't do a wait+gather and instead handles each request indepdently)

ah, it was that time when someone did a lot of fat transactions and mempool was super full: libera.monerologs.net/monero-dev/20211002#c35201

so I restarted my node with mempool limitation to unstuck it

yeah worse case its a bug in the tx or pool code itself :/

maybe it didn't happen on my node anymore because I run it with --max-txpool-weight now

Not all pool-add events show up on zmq_pub, but do show on target `show_transfers in` almost instantly.

selsta jberman[m]: github.com/monero-project/monero/co…rd:monero:replace_p2p_serialization has been rebased

not all do? this might be related to tor and/or dandelion++

I recall (attempting) to make sure its not alerted externally if in the earlier phases

hmm or maybe not, its not mentioned in the documentation I wrote in `docs/

yeah I dunno if thats the correct behavior, but I could see why the change was proposed