01:43:56 <jeffro256[m]> thanks!
03:16:28 <moonag[m]> 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
03:16:28 <moonag[m]> if there is something well documented/with good reasons for making certain decisions that would be incredibly helpful
03:17:52 <moonag[m]> (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)
03:19:27 <cryptogrampy[m]> I'd take a look at MoneroPay: https://github.com/moneropay/moneropay 
03:21:04 <cryptogrampy[m]> I also invited you to the monero community dev chat- you should repost your question there.
03:22:13 <moonag[m]> awesome! thanks for the resources.
13:47:24 <rogu157[m]> Hello again! I still got issues with a problem that described before. I repeat a question. Maybe someone help me.... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/df6df8f48d7fca267962848f72c32de1365e3a72)
14:16:27 <moneromooo> set_log 1 will show why connecyions are getting dropped. Grep for "[dD]rop".
14:16:57 <moneromooo> It's likely a random drop to make space for another connection if they were connected just fine.
14:17:34 <moneromooo> This happens to escape being hemmed in by sybils, always trying to look for another node which might have a longer chain.
14:17:49 <moneromooo> There is no way to tell monerod "always keep a connection to that particular node".
14:18:24 <moneromooo> 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).
14:18:35 <moneromooo> --exclusive-node can be used more than once though IIRC.
14:27:20 <rogu157[m]> moneromooo: thank you, I will try to collect errors.
14:46:31 <gingeropolous> i thought --add-priority-node tried to keep a connection
14:47:30 <rogu157[m]> me too 😀
14:48:21 <gingeropolous> "Specify list of peers to connect to and attempt to keep the connection open"
14:49:44 <gingeropolous> brb, making PR to add "jk" to the help info line :)
14:55:48 <moneromooo> Maybe it does. I did not know.
15:05:49 <moneromooo> The new peer searcher will not care about a peer is priority or not before dropping. That should be changed, then.
18:17:31 <selsta> woodser[m]: is there still something to do with the output export patch? or is everything fixed now?
18:24:32 <woodser[m]> it’s working. my tests are stable with no segfaults or hanging
18:28:00 <selsta> ok ty, jberman[m] anything remaining now? i think there were some compatibility concerns
18:28:42 <jberman[m]> Don't think so. Going to give a final review today
20:11:42 <mrako-grub> 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
20:12:54 <selsta> can you join #monero ? and do you have a transaction id?
20:17:51 <mrako-grub> thank you
20:31:23 <selsta> 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
20:31:58 <selsta> i was able to do 5 full wallet scans from height 0, previously it would crash after a couple seconds
21:05:47 <Guest5443> why official repo on github not hosted on monero  owned domain?
21:10:06 <selsta> read https://github.com/monero-project/meta/issues/236
21:15:19 <Guest5443> I have seen that, not sure how it is an answer rather then another question.
21:16:30 <Guest5443> If you can host the code on half the contributors PCs as a GOGs instance, your already decentralised beyond github
21:23:42 <selsta> most devs have a copy of the repository on their pc, we also have mirrors see e.g. https://git.wownero.com/monero-project/monero
21:34:25 <sech1> 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
21:36:18 <sech1> I guess it's to make checking for "unset" values easier. Still feels a bit weird.
21:36:48 <jberman[m]> array with direct indexing does seem like a nicer pattern here. agree
21:37:08 <sech1> yes, you could've used 0xFF for unset values
21:37:23 <sech1> but you'll also need to check if zone is in range
21:37:38 <sech1> if you get it from some external source (network packets for example)
21:39:21 <sech1> 8435 would not be needed then, plus F(x)=x is a bad hash function :P
21:39:52 <sech1> F(x)=x as a hash function is what triggered me :D
21:40:43 <jberman[m]> ya reasonable :)
21:41:17 <sech1> current code is correct though, but over complicated
21:44:50 <selsta> it can still be changed if it greatly simplifies the code