12:21:22 <kovri-slack> <woodser> daemon rpc `get_info` returns a string `version` e.g. “0.15.0.1-release”, and daemon rpc `get_version` returns a number `version` e.g. 196608 and boolean `release`.  perhaps get_version should also return the version number as a string and the release name like “Carbon Chamaeleon” to make it a complete call?  is there a way to convert from the numeric `version` to the string like “0.15.0.1”?
12:24:40 <moneromooo> get_info returns the human version (if not restricted), get_version returns the RPC version.
12:31:19 <hyc> we probably should update unbound now https://mobile.twitter.com/NLnetLabs/status/1205099167061827586
12:43:20 <moneromooo> I can look at that later today.
13:10:02 <Guest78835> @woodser any way to pm you which is not slack?
13:12:36 <kovri-slack> <woodser> keybase, same username
13:14:26 <Guest78835> i haven't a set up account there. I'm PMing you on reddit (assuming it's the same nick there too)
13:17:27 <kovri-slack> <woodser> XmrApiDev on reddit
13:21:46 <Guest78835> thanks
13:23:22 <Guest78835> @woodser just sent you a PM there
14:07:11 <Guest78835> rbrunner PM me when you are around pls
15:04:45 <moneromooo> I've recently added defered tx verification to take advantage of batching. However, I'm wondering about the side effects of txes propagating more slowly as a result, since txes are only sent on their way after they're verified.
15:05:07 <moneromooo> (Otherwise you can send bad data and get that amplified by the p2p network)
15:05:25 <moneromooo> Any opinions on this ? Good, bad, any middle ground you can think of ?
15:06:19 <omartijn> How is it implemented? Maximum time a transaction may be queued?
15:06:20 <moneromooo> Txes are sent at most 10 seconds after they're received.
15:06:43 <moneromooo> It's implemented by keeping them and verifying them later. Either on a timer or when a block is received.
15:06:50 <omartijn> Ah, so you receive tx 1, then two seconds later you receive tx 2, then 8 seconds later they are both verified?
15:06:57 <moneromooo> Or after 4 of them are received.
15:07:18 <moneromooo> 10 seconds later at most.
15:07:45 <omartijn> 10 seconds after the first unconfirmed is received or 10 seconds of no new transactions?
15:08:45 <moneromooo> At most 10 seconds after a standalone (ie, not in a block) tx is received.
15:17:27 <luigi1111w> I'm not a big fan of it
15:19:32 <luigi1111w> it makes sense to save electricity or cpu busy time, but is detrimental for pretty much every other metric
15:20:56 <omartijn> How detrimental it is would depend on the longest path between two nodes. The maximum added delay is basically 10 * maximum path
15:22:06 <moneromooo> What metric other than latency ?
15:22:41 <omartijn> On the network topology, assuming each node is connected to 8 other nodes, what would the longest path between node a and z be
15:23:23 <luigi1111w> latency probably encapsulates most of it
15:23:57 <luigi1111w> "network health"
15:24:16 <moneromooo> When you put it like that, it does sound like a bad idea :)
15:24:56 <moneromooo> OTOH, if you receive a packet with >= 4 txes, you'll end up sending them at once since it meets the >= 4 threshold.
15:25:54 <moneromooo> s/packet/message/
15:26:01 <luigi1111w> I think the cpu gains are basically irrelevant for most nodes
15:26:43 <luigi1111w> if traffic picks up a lot that wouldn't no longer be true though
15:26:56 * moneromooo counts negations
15:28:12 <moneromooo> I think you might well be right. I'll wait for others to comment and maybe close it. So don't merge 5968 yet then.
15:29:04 <omartijn> Perhaps it could be an option with a configurable delay? When traffic picks up it can be enabled easily
15:29:50 <moneromooo> I thought of this, but the sender always wants "send it asap" and the receiver always wants "wait a bit", so a flag would not help much here, whether as monerod command line or flag in relay message.
15:30:31 <moneromooo> Well, not always, but the incentives are opposed.
15:32:37 <omartijn> The sender only cares about "send it asap" if it's their own transaction, right?
15:33:08 <omartijn> The majority of transactions a node sees will be relayed transactions, where the node doesn't care
15:34:20 <moneromooo> True.
15:48:38 <luigi1111w> wouldn't no longer
16:04:44 <moneromooo> Anyone knows if we purposefully removed auth_zone_reload/auth_zone_transfer from the unbound-in-monero-tree repo, or if it's just a missed patch ?
16:05:11 <moneromooo> I'll add it again if noone says it's been removed on purpose, since it removes diffs from upstream.
16:05:16 <moneromooo> anonimal: ^
16:09:13 <moneromooo> Or maybe I'm diffing with the wrong place. Commits hashes don't match. I'll assume it's not intended for now.
19:46:10 <moneromooo> I updated libunbound to 1.9.7. The git tree was all different (I think due to it being on svn before) so I'm now using the upstream git tree, which makes it a lot easier to update next time (and shows our changes are now minimal, after cleanup).
19:46:56 <moneromooo> However, I can't PR this to the monero unbound repo as the trees don't have a common commit. I'm not sure what to do here. I think it will need someone with push access to replace the tree.
19:48:06 <moneromooo> The new tree is https://github.com/moneromooo-monero/unbound/commit/d0fcb9206dca9d8964d4e38bebad71ae29ebb4f6
19:48:25 <moneromooo> There is a PR in monero that updates the submodule to this.
19:48:49 <moneromooo> fluffypony: luigi1111w: I think one of you will have to reset the tree to this.
19:54:28 <luigi1111w> I don't have access to that repo without using the monero account, so will defer to fluffypony for now
20:19:46 <hyc> gingeropolous: are you still running with those debug settings to check for DB corruption? I take it it hasn't happened again so far?
20:21:18 <hyc> Snipa same question ^
20:23:06 <Snipa> I haven't noticed anything weird on my nodes after purging them.
20:23:30 <hyc> ok
20:23:46 <hyc> would be nice to catch this sucker
20:24:21 <hyc> or know for sure that updating libunbound fixed it
20:24:42 <moneromooo> (or made it worse)
20:25:00 <moneromooo> (you can tell I work with computers)
20:25:03 <hyc> heh
21:17:05 <selsta> hyc: also still running with patch in lldb no corruption yet
21:21:29 <luigi1111w> it will either make it better, worse, or do nothing
21:22:50 <hyc> at this point, after an audit by X41, I wouldn't expect it to be worse
21:23:08 <hyc> but sure, ya never know. one of their fixes may be buggy itself.
21:28:46 <gingeropolous> i have it running, i think im using the built in unbound though
21:28:48 <gingeropolous> i honestly forget
21:29:02 <gingeropolous> im super helpful
21:32:15 <moneromooo> You should be able to tell by looking at maps in /proc/$PID/maps