thanks!

hey not sure if this is the right place to ask but I plan on integrating automatic monero payments into a service and want to know if there is anywhere where "best practices" are published for things like control flow? using subaddresses, should addresses be tied permanently to an account for payment? how to handle partial payments? and specifically accepting zero conf transactions. I know some of this just needs to be decided by me but

if there is something well documented/with good reasons for making certain decisions that would be incredibly helpful

(for instance is it a good practice to store transaction ID in my database of payments as a way to lookup and confirm someone made a payment, are there any risks, etc)

I'd take a look at MoneroPay: github.com/moneropay/moneropay

I also invited you to the monero community dev chat- you should repost your question there.

awesome! thanks for the resources.

Hello again! I still got issues with a problem that described before. I repeat a question. Maybe someone help me.... (full message at libera.ems.host/_matrix/media/r0/do…8f48d7fca267962848f72c32de1365e3a72)

set_log 1 will show why connecyions are getting dropped. Grep for "[dD]rop".

It's likely a random drop to make space for another connection if they were connected just fine.

This happens to escape being hemmed in by sybils, always trying to look for another node which might have a longer chain.

There is no way to tell monerod "always keep a connection to that particular node".

If you want to test things with that connection, you can use --exclusive-node, then it won't be dropped (but will also not make other connections).

--exclusive-node can be used more than once though IIRC.

moneromooo: thank you, I will try to collect errors.

i thought --add-priority-node tried to keep a connection

me too 😀

"Specify list of peers to connect to and attempt to keep the connection open"

brb, making PR to add "jk" to the help info line :)

Maybe it does. I did not know.

The new peer searcher will not care about a peer is priority or not before dropping. That should be changed, then.

woodser[m]: is there still something to do with the output export patch? or is everything fixed now?

it’s working. my tests are stable with no segfaults or hanging

ok ty, jberman[m] anything remaining now? i think there were some compatibility concerns

Don't think so. Going to give a final review today

Hey everyone I'm pretty new here using monero. How much time is needed for transaction. I've sent from exchange to my wallet like 2hours ago and still nothing came

can you join #monero ? and do you have a transaction id?

thank you

the wallet sync crash appears to be fixed on macOS beta 6... glad we didn't waste time on debugging this as it turned out to be an OS bug

i was able to do 5 full wallet scans from height 0, previously it would crash after a couple seconds

why official repo on github not hosted on monero  owned domain?

read monero-project/meta #236

I have seen that, not sure how it is an answer rather then another question.

If you can host the code on half the contributors PCs as a GOGs instance, your already decentralised beyond github

most devs have a copy of the repository on their pc, we also have mirrors see e.g. git.wownero.com/monero-project/monero

jberman[m] I've just noticed "std::unordered_map<epee::net_utils::zone, unsigned int>" (#8330 and #8435) in the code today. But why? "zone" is an enum of 4 elements, you could've just used direct indexing and std::array

I guess it's to make checking for "unset" values easier. Still feels a bit weird.

array with direct indexing does seem like a nicer pattern here. agree

yes, you could've used 0xFF for unset values

but you'll also need to check if zone is in range

if you get it from some external source (network packets for example)

8435 would not be needed then, plus F(x)=x is a bad hash function :P

F(x)=x as a hash function is what triggered me :D

ya reasonable :)

current code is correct though, but over complicated

it can still be changed if it greatly simplifies the code