selsta:could i test it,could i,couldi?plz.

.merges

IITC it can happen if a peer is very slow. monerod can then decide the peer isn't going to reply, and ask again (but this time, what's needed may be different). So if the peer really was slow, rather than didn't send, and sends later, the preivously requested block doesn't match the new request.

moneromooo: I don't think that's the reason for the error. The block hashes I'm getting do not exist in the main chain, e.g. b188d86adc0648692aa1ef28a40234de7cb6dc3a4667e352391387d1aca1adf9

Hello, Software Engineer here, always thought about contributing open-source projects and now I have some free time... can I talk to someone, I would love to join and contribute / help, I would just need some quick directions,.

Hi.

I usually tell people to use the software, find something that's a bit rough somewhere and improve it. It means it's usually a small/easy thing and you have a tangible benefit.

Otherwise, you can check the issues list on github to have ideas.

When posting a patch, please try to have "small" ones, within reason. That is, no random renaming/reindent, several patches if you awnt to do several things, etc.

If you have particular questions, just ask, and wait for someone who can answer to be around.

Okay I will do it this way then, thanks for the quick answer!

If unsure about whether we'll ok a patch, ask first. Rwriting for "I prefer it this way" is typically unwanted.

(and there are parts of the code which a lot of people would prefer another way :P)

Oh, one easy first patch:

a couple days ago, someone had trouble with something, and they ended up writing a sweep_all (IIRC) command with the wrong syntax (swapped parameters).

There was no error. Having an error there when the parameter order is wrong would be nice.

Seems an easy first issue if you like.

It sounds the best for starting, I will look into that.

Sounds good. In case you don't know, there is a testnet for monero (parallel network for testing). Always use that for testing, not the live network. monero tools take the --testnet command line parameter to use the test network.

How testnet deamon says it found block when starting mining to a wallet address even if there is not block chain database provided

Someone needs to learn to ask good questions...

moneromooo: should this predicate be negated? monero-project/monero 79e09fb#r80623901

I don't think so.

View wallets are no good reason to import outputs I thin.

have no

And AFACIT negating the predicate would break the existing flow.

.merges

monero-project/monero #8381 needs a last approval before we can merge it

I read and approved it.

8381 isn't going to the branch?

there is one but I'm not sure if I want to include it in v0.18.1.0

sech1: should I include 8381 in v0.18.1.0 or not? I don't want any mining related bugs shortly before the HF :D

luigi1111w: can you also merge the remaining things + gui? I'd prefer if master and release don't get out of sync

moneromooo: do you remember monero-project/monero #976 ?

currently on macOS beta I have to do the opposite, set e.g. max-concurrency 8 otherwise I get a crash

Yes, I kinda do.

Vaguely...

I never knew the reason, so...

are libcncrypto.a and libwallet-crypto.a alternatives for different platforms? is one better than the other? libwallet-crypto.a is not built on some platforms

AFAIK libwallet-crypto.a is x86_64 asm for some functions, which are used in the wallet.

The idea being that you want to avoid more experimental crypto code for consensus functions.

selsta it's better to include 8381. That function is only used by p2pool and 8381 fixes a few issues there (including check for duplicate key images)

.merge+ 8455 8381

Added

luigi1111w: if you could do cli + gui merges today then we can tag tomorrow

fork is in 4.8 days