< tryphe> gmaxwell, thanks. my hunch was that the feeler count was incorporated into maxconnections, in order to reserve the feeler, ie default maxconnections=125, so you get 116 inbound, 8 outbound, and 1 feeler (see https://github.com/bitcoin/bitcoin/blob/master/src/net.cpp#L895)
< tryphe> gmaxwell, just figured i'd double check to make sure.
< fanquake> sipa / wumpus can you block piilanismith from the GH. tagging & asking off-topic Qs.
< sipa> can't right now
< luke-jr> MarcoFalke:
< jonasschnelli> <sipa>jonasschnelli: now that you have benchmarks for your poly1305/chacha20 implementation... would it be much work to also implement the "standard" openssh-like construction?
< jonasschnelli> Sure... it's easy. I'll do that
< wumpus> fanquake:done
< fanquake> wumpus: cheers
< jonasschnelli> sipa: here are some numbers with the OpenSSH version of the AEAD: https://github.com/bitcoin/bitcoin/pull/15649#issuecomment-491512397
< gmaxwell> gleb: sdaftuar: uh, is random fetch ordering putting more stress on orphan handling? The INVs we get from peers are usually in dependency order. That makes us fetch in dependency order, and thus the results we get back end up being mostly in dependency order.
< gmaxwell> With the random ordering I think we're breaking that.
< sdaftuar> gmaxwell: i asked you that question! :P
< sdaftuar> but yeah, i dunno, i wonder the same
< gmaxwell> oh. you did? damn
< gmaxwell> sorry, fishbrain here.
< gmaxwell> Well, I noticed more use of the orphanmap in my logs which is what caused me to ask the question, so I so I believe the answer is yes.
< gmaxwell> :-/
< gmaxwell> this is annoying
< sdaftuar> i think it at least seems we gave this insufficient thought before merging #14897, so if you have reason to believe it's making things worse, i certainly believe it
< gribble> https://github.com/bitcoin/bitcoin/issues/14897 | randomize GETDATA(tx) request order and introduce bias toward outbound by naumenkogs · Pull Request #14897 · bitcoin/bitcoin · GitHub
< gmaxwell> it's not so much a problem but the orphan map is limited in size and its expiration process is random, so you really don't want to be using it 'by default'
< gmaxwell> one answer to this would be to just improve the orphan map behavior.
< bitcoin-git> [bitcoin] kristapsk opened pull request #16010: Correct description of blocksdir default value (master...blocksdir) https://github.com/bitcoin/bitcoin/pull/16010
< warren> ... after many weeks of waiting on their sysadmins LF asked if we're ready to proceed yesterday. I think it'd be best to wait until everyone is no longer traveling after "blockchain week" before the list migration. Opinions?
< gmaxwell> sipa: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-May/016918.html in this message Sjors recommends listing alternatives in the BIP, I strongly recommend against doing that-- it would be confusing due to distracting from what the BIP also does. BIPs should give rationale where they help add clarity on whats being done, but comparisons with untaken alternatives should generally
< gmaxwell> be elsewhere.
< gmaxwell> sipa: also someone might want to point out to ZmnSCPxj that his scheme for getting a NUMS point is insecure (it must also commit to G because we don't know how G was generated)