<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”?

get_info returns the human version (if not restricted), get_version returns the RPC version.

we probably should update unbound now mobile.twitter.com/NLnetLabs/status/1205099167061827586

I can look at that later today.

@woodser any way to pm you which is not slack?

<woodser> keybase, same username

i haven't a set up account there. I'm PMing you on reddit (assuming it's the same nick there too)

<woodser> XmrApiDev on reddit

thanks

@woodser just sent you a PM there

rbrunner PM me when you are around pls

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.

(Otherwise you can send bad data and get that amplified by the p2p network)

Any opinions on this ? Good, bad, any middle ground you can think of ?

How is it implemented? Maximum time a transaction may be queued?

Txes are sent at most 10 seconds after they're received.

It's implemented by keeping them and verifying them later. Either on a timer or when a block is received.

Ah, so you receive tx 1, then two seconds later you receive tx 2, then 8 seconds later they are both verified?

Or after 4 of them are received.

10 seconds later at most.

10 seconds after the first unconfirmed is received or 10 seconds of no new transactions?

At most 10 seconds after a standalone (ie, not in a block) tx is received.

I'm not a big fan of it

it makes sense to save electricity or cpu busy time, but is detrimental for pretty much every other metric

How detrimental it is would depend on the longest path between two nodes. The maximum added delay is basically 10 * maximum path

What metric other than latency ?

On the network topology, assuming each node is connected to 8 other nodes, what would the longest path between node a and z be

latency probably encapsulates most of it

"network health"

When you put it like that, it does sound like a bad idea :)

OTOH, if you receive a packet with >= 4 txes, you'll end up sending them at once since it meets the >= 4 threshold.

s/packet/message/

I think the cpu gains are basically irrelevant for most nodes

if traffic picks up a lot that wouldn't no longer be true though

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.

Perhaps it could be an option with a configurable delay? When traffic picks up it can be enabled easily

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.

Well, not always, but the incentives are opposed.

The sender only cares about "send it asap" if it's their own transaction, right?

The majority of transactions a node sees will be relayed transactions, where the node doesn't care

True.

wouldn't no longer

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 ?

I'll add it again if noone says it's been removed on purpose, since it removes diffs from upstream.

anonimal: ^

Or maybe I'm diffing with the wrong place. Commits hashes don't match. I'll assume it's not intended for now.

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).

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.

The new tree is moneromooo-monero/unbound d0fcb92

There is a PR in monero that updates the submodule to this.

fluffypony: luigi1111w: I think one of you will have to reset the tree to this.

I don't have access to that repo without using the monero account, so will defer to fluffypony for now

gingeropolous: are you still running with those debug settings to check for DB corruption? I take it it hasn't happened again so far?

Snipa same question ^

I haven't noticed anything weird on my nodes after purging them.

ok

would be nice to catch this sucker

or know for sure that updating libunbound fixed it

(or made it worse)

(you can tell I work with computers)

heh

hyc: also still running with patch in lldb no corruption yet

it will either make it better, worse, or do nothing

at this point, after an audit by X41, I wouldn't expect it to be worse

but sure, ya never know. one of their fixes may be buggy itself.

i have it running, i think im using the built in unbound though

i honestly forget

im super helpful

You should be able to tell by looking at maps in /proc/$PID/maps