does wallet2 API have something to save current state of synchronized chain?

Monero::WalletListener::newBlock() is giving current height

but i need to save current state

monerod release on mainnet ignoring stop_daemon command.

screen -S "${SNAME}-${NETTYPE}" -X stuff "stop_daemon\n"

7fc2ce7fc700 INFO msgwriter src/common/scoped_message_writer.h:102 Stop signal sent

A kill -TERM $(pidof seceensession) had to be used, to force a shutdown. Attaching the session issuing "stop_daemon", "exit" or CTRL-C had no effect.

This is what a scripted shutdown should look like:

7f89e4aea700 INFO msgwriter src/common/scoped_message_writer.h:102 Stop signal sent... (full message at libera.ems.host/_matrix/media/r0/do…6e5bca1dd117dcb11b2a3a69cbce8b9ad81)

hiiiiiiiiii

virtual bool store(const std::string &path) = 0;

i think thissssssssss

If you can repro it, a thread dump would be useful (gdb /path/to/monerod ${pid-of-the-waiting-monerod} then: thread apply all bt).

I also think the net patch by wfaressuissia on github fixes it.

(one such bug anyway)

It's currently working as expected. It's not something I can provoke. The daemon is launched every 30 minutes, and shut down when synced. I will try if it hangs again.

Monero::Wallet::store() doesn't store blocks

isn't there anything to save blocks in wallet2???????????

It saves block hashes. Is that enough ?

it is enough to synchronize right??

Yes.

but how does it save hashes??

By... writing to disk...

ohhhh

i mean what should i do to make it save?

Call store, which you found. It's done automatically when you exit the wallet normally.

just tried

^C is deemed normal for the purposes of this.

but it doesn't save blocks

when i restart the app

ohhhhh

waitt

wallet->setRefreshFromBlockHeight()

maybe about this?

im doing store() buttt it doesn't save or still getting blocks from node

As I said, it never saves blocks. Only block hashes. If you want it to save blocks for some reason, you'll have to add that code. And your wallet won't be compatible with monero-wallet-cli.

i mean saving "current state"

im doing wallet->store("monero-wallet");

it saves monero-wallet.keys

Hmm. Maybe I'm confusing things. Lemme check the code...

i mean should this save current state and supposed to not retrieve blocks from node when i restart the app???

OK, if can write the keys file if you store as another name, but if not, it'll save the cache file only.

store will save the current state to the wallet cache file, and is not supposed to retrieve blocks fom the node.

When you restart the wallet program, it will typically try to sync to the node.

That depends on the program. And if you've disabled auto refresh.

But usually, it'll try to.

it is doing refresh

"refreshed" callback is being called

you mean doing wallet->store() is enough to save current state?

It should be.

really confusing

What do you think might be a less confusing API to save it ?

im doing wallet->store() but when i restart the app, it is getting blocks from node

You can disable auto refresh if you want.

Or do you mean it's downloading *all* blocks from the genesis block again ?

no not from genesis block the block that i specify with wallet->setRefreshFromBlockHeight()

Is your wallet setup to trust the daemon ?

you mean if i disable auto refresh it will store current state and start from current state when i restart?

If your daemon is on 127.0.0.1, it'll be a yes.

wm->setDaemonAddress("xmr.moneromerch.com:18089");

im doing this

wallet->init("xmr.moneromerch.com:18089", 0, "", "", true, false, "");

and this

That call doesn't quite match the prototype I have here, but I'll assume the daemon is untrusted since it's not on localhost.

In that case, the wallet will quantize its current height and start asking the daemon from blocks a bit earlier than needed, for privacy reasons.

It's to remove some bits of fingerprinting ability. Though there's probably a lot more left.

IIRC the quantum is about 1000 blocks. So when you've synced at most ~1k more blocks, it'll start asking from blocks from a later starting point.

Use your own node on 127.0.0.1 and it won't do tha.

interestinggg

the app has to use a remote node

it will use our node

and start synchronizing from wallet creation time

is there a way to make wallet2 to trust node??

Then it'll get a bit more traffic at start. No biggie, the wallet won't actually rescan those txes IIRC.

Which in itself can be an info leak, since the faster it goes htrough txes, the faster it can ask for more, so the node can try to make a guess, but hey.

Yes. See wallet2.h.

It's also a param in init.

Here, it'll mean that the user of the wallet trusts you. Not that you trust yourself.

virtual bool init(const std::string &daemon_address, uint64_t upper_transaction_size_limit = 0, const std::string &daemon_username = "", const std::string &daemon_password = "", bool use_ssl = false, bool lightWallet = false, const std::string &proxy_address = "") = 0;

you mean this init()?

Yes. Thought it was a parameter here, I misremembered.

Hrm. My copy has it. Must be a recent change then.

Still in master. What class is that init function you're quoting in ?

Ah, found it. wallet2_api. Makes sense.

I was looking at wallet2.

meowwwwww

damnnn

i merged my C++ static library and all wallet2 libraries with ar now build time is better

i wrote a Makefile

i love GNU Makeeeee

what could we do if MSYS2 was not exist

anyone doesn't care about building Windows

building on Windows*

using Bash commands and Linux things

Godot takes care about building on different platforms

You could... use Linux. In fact, one might even go as far as you could use Linux even if MSYS2 exists.

how big is the blockchain file right now?

at least 1

at [17:32:15] ➜ ls -lh ~/.bitmonero/lmdb/

total 276351632

-rw-r--r-- 1 ric waffles 132G Jun 11 03:59 data.mdb

thanks, im currently trying to get the blockchain data out of my docker node and into my pinode

Less than 50 GB if pruned.

can you prune -> move -> unprune?

You cannot unprune.

we could call it growing

:-P

fluffing

lol

I guess the real issue with a Pinode is HDD thrash when syncing / importing from .raw, so probably the best thing to do is just to move it whole

Good point.

It’s worth asking, at some point, if a Rasp pi has ever become fundamentally inadequate to be supported. Here’s an interesting thread: monero-ecosystem/PiNode-XMR #65

Well it’s more of a single post than a thread

While on the topic if pruned nodes... (full message at libera.ems.host/_matrix/media/r0/do…928ec72068ce610770d506adcc916d3564f)

Uh. Make that 1/2/3

moneromooo, i was a Linux catttttt

in past but now im a Windows cattt

im using WSL instead of Linux

im making TXs

i should do Monero::PendingTransaction::commit() right???

tx->txid() returns a std::vector but it is empty

as i understand TXIDs are being cleared after tx->commit()

but tx->txid() is still empty before tx->commit()

but whyyyy

ohh tx->status() is 1

my TradeOgre address starts with 8

shouldn't that start with 4?

Subaddresses all start with 8 (on mainnet). They must be using them.

where is subaddress index placed in the private seed?

or it is not placed in private seed

i should loook at my key derivation implementation

string pub_key = (int)Network + Convert.ToHexString(PublicSpendKey) + Convert.ToHexString(PublicViewKey);

The seed generates all subaddresses. That's a metric fuckton of them. You don't want indices for all of these in your seed.

but where should i specify subaddress indexes?

In account_index when calling transfer, typically.

Wherever the API has a parameter for one, really.

i mean i want to allow generating subaddresses tooo in my C# library

That API would take a subadress index. Pass it one.

Maybe I'm missing your point :)

ummmmm

i mean im deriving Monero keys includes public address tooo

but i want to derive subaddresses tooo

where is Monero's word list?

found

MeowingCat: github.com/WernerVasquez/gomonero/blob/master/address/subaddress.go

MeowingCat: github.com/WernerVasquez/gomonero/blob/master/wallet/wallet.go

wernervasquez[m], tyyy

MeowingCat: I tried to keep my code lightweight and readable. The wallet.go file has some of the logic like scanning. Please let me know if anything is not clear enough so I can update it to be more clear.

<sech1> "so probably some new or updated..." <- is it important ? there is a fix for it

sech1: will look into it

at least bisect the change that introduced this, might need help for the actual fix

our min glibc is at 2.26 paste.debian.net/hidden/7ca5dac4

some change in master branch increased it

yes, latest master branch makes Ubuntu 16.04 sad

Official v0.17.3.2 works fine though

nm -a "build/Linux/cc/release/bin/townforge" | grep @@GLIBC_ | tr @ \ | sort -k3,3V | tail

That gives you the symbols that uses the most recent glibc.

I see getrandom being new...

getentropy, explicit_bzero, __explicit_bzero_chk, reallocarray

that's the one i'm seeing for 2.25 and 2.26

What's your target ? .23 ?

we previously had 2.17

Is it normal to get a ton of repeated "connection refused" on the log when trying to connect to node.moneroworld.com

?

It's occassionally downloading some blocks

try a different node

Any one in particular recommended for connecting over Tor?

Ask in #monero:monero.social

Ill answer you there

There are patches on github that improve connection stability over tor. Use those.

Look for PRs From jberman[m].

thanks

moneromooo: these patches are for p2p tor, i think they were asking for rpc over tor

rpc over tor should be similar to normal rpc traffic

Ah, thanks.

but the patches are merged to master now so no one has to worry about it

.merge+ 7774

Added

sech1: monero-project/monero #7773 introduced the increased glibc dependency

not sure yet how to continue

Try older unbound versions?

i can try, but we updated it in the first place because unbound had an audit and was full of security issues

Drop support for Ubuntu 16? It's been more than a year since Ubuntu 16 end of life

will check tomorrow if going back with the unbound version helps, otherwise sometimes something like monero-project/monero #6397 is also possible

You could check unbound config to see if there's a backward compat option. Not super likely though.

they have some compatibility code

but have to look tomorrow

<selsta> ".merge+ 7774" <- it isn't clear from approval whether correctness of lmdb changes was verified or not.

monero-project/monero #8381, the same here both approvals before important change and after aren't clear enough to understand whether correctness of patch overall was verified, though this change is certainly more isolated than lmdb related one