03:45:59 <gingeropolous> are any of these ideas ready for the next fork? https://github.com/monero-project/monero/issues/6456
03:47:09 <gingeropolous> UkoeHB, knaccc
03:48:00 <gingeropolous> from what I can tell, the focus has been BP+ and a ringsize bump
03:49:16 <gingeropolous> though i might keep forgetting
04:15:02 <UkoeHB> not unless someone has been working to implement them
04:20:00 <gingeropolous> gotcha. But fundamentally, they are all sound?
04:37:54 <UkoeHB> yeah there are no outstanding objections I am aware of
13:07:07 <hyc> wfaressuissia[m]: netstat -tunp: p requires an argument.
13:07:25 <hyc> netstat -tun shows only unix domain sockets. not interesting for monerod.
13:07:31 <hyc> I use netstat -nt.
13:07:43 <sethsimmons> I cannot see wfaressuissia[m] messages in Matrix, looks like there is an issue with his account.
13:08:13 <sethsimmons> Maybe not voiced or something?
13:09:02 <hyc> this is after 2 days uptime https://paste.debian.net/1197339/
13:09:36 <hyc> all the TIME_WAITs are from xmrig polling the RPC
13:09:45 <hyc> nothing unusual looking at the moment
13:11:08 <hyc> er... all the 127.0.0.1:18081 TIME_WAITs are. there are one or two others from p2p
13:21:11 <wfaressuissia[m]> "netstat also showed hundreds of conns in CLOSE_WAIT" there must be some way to list active tcp sockets along with associated process pid
13:22:18 <wfaressuissia[m]> it's expected that dangling (without associated pid) socket can't be in CLOSE_WAIT state
13:23:31 <wfaressuissia[m]> in the worst case socket can be left unclosed until timeout  of connection timer which is about few minutes
13:23:41 <sethsimmons> Hey messages :D
13:23:51 <wfaressuissia[m]> if you have a lot of sockets in CLOSE_WAIT state for along period of time then it's a problem
13:24:13 <hyc> PID is not relevant here, there are no other active services on that machine. they are all due to monerod aside from my ssh session
13:24:34 <wfaressuissia[m]> otherwise it's expected that some of them will not be closed immediately
13:24:48 <hyc> anyway, the last time I mentioned it the monerod had been up for 4 days when it started running out of descriptors due to this problem
13:24:57 <hyc> this has now only been 2 days so far
13:25:53 <wfaressuissia[m]> PID will tell whether it's just non-terminated connection by monerod or some black magic problem in mac with CLOSE_WAIT state for dangling socket
13:27:14 <wfaressuissia[m]> sethsimmons: your messages aren't visible in #freenode_#monero-dev:matrix.org but visible in https://monerologs.net/monero-dev
13:27:55 <sethsimmons> I think it's due to the voice restrictions here.
13:27:58 <sethsimmons> On the IRC side
13:28:22 <asymptotically> sethsimmons: i can see his messages fine and he's got voice
13:28:41 <sethsimmons> I can see wfaressuissia[m] now, not sure what changed
13:34:04 <hyc> nothing changed. I was replying to his message from yesterday
13:35:26 <sethsimmons> oh
16:55:06 <DisBotXMR2> <CrimsonKing> test
16:55:33 <DisBotXMR2> <CrimsonKing> is the relay still working ? Matrix guys, anyone can read this ?
17:00:31 <sethsimmons> Yes, we can
19:39:07 <luigi1112> .merges
19:39:07 -xmr-pr- 7349 7665 7666 7667 7668 7670 7677 7678 7680 7681 7682 7685 7686 7687 7688 7689 7690 7691 7694 7695 7696 7697
19:40:47 <mj-xmr> I hope that 7777 is not going to be taken by a spammer.
19:41:08 <selsta> .merge- 7706 7689
19:41:08 <xmr-pr> Removed
19:41:20 <selsta> luigi1112: these two might get replaced
19:41:32 <selsta> by a more general fix so I removed them for now
19:41:37 <luigi1112> 7777 is very important agreed
19:41:52 <hyc> are these tests still going to be testing what they claim, with all these result caching patches?
19:42:11 <selsta> which one exactly?
19:42:17 <selsta> we don't cache anything yet
19:42:20 <selsta> regarding tests
19:42:42 <selsta> ah you mean not merged ones yet
19:45:04 <hyc> yeah
19:45:27 <selsta> I will be careful with cache patches regarding tests (I won't be the one reviewing them)
19:47:52 <selsta> this is the last place we want to add a bug and not notice broken tests
19:55:20 <hyc> indeed
19:59:19 <selsta> If a change is deemed safe, does not make things significantly more complicated and also has a noticeable speedup it should be fine to merge.
20:52:28 <selsta> .merges
20:52:28 -xmr-pr- 7349 7670 7677 7678 7686 7687 7688 7690 7691 7694 7695 7696 7697
21:57:20 <mj-xmr> hyc, selsta, me and moneromooo have agreed, that the caching shall be disabled by default, and remain a developers' tool for local runs.
21:58:12 <mj-xmr> And this is the current state of the caching PR (7469)
21:58:29 <mj-xmr> Good night
21:59:08 <selsta> mj-xmr: I think this was related to 7717
22:24:48 <selsta> .merge+ 7689
22:24:48 <xmr-pr> Added
22:29:53 <selsta> luigi1112: please ^ and then also gui today
22:30:15 <selsta> and gui tag
23:25:19 <ed23> guys can you help me out with something. Where exactly in the code is if 10 blocks have past since an input of a transaction was created using a prior output?
23:25:38 <selsta> do you want to remove it?
23:25:43 <ed23> it seems to me that there is no such check, only a check against the unlock time (which is different )
23:25:54 <ed23> and set by the user
23:26:05 <ed23> No I want to understand the code
23:26:24 <selsta> moneromooo: probably knows
23:28:35 <ed23> seems like there is no rule like that
23:28:49 <ed23> Not at the blockchain level, only the wallet level
23:30:29 <ed23> (besides the user defined unlock time that is bundled with the tx)
23:36:26 <moneromooo> git show a444f06
23:57:52 <ed23> thanks a lot moneromooo