< bitcoin-git>
[bitcoin] fanquake opened pull request #18371: test: use fs namespace in dbwrapper unicodepath test (master...dbwrapper_use_fs_namespace) https://github.com/bitcoin/bitcoin/pull/18371
< vasild>
fanquake: so, its not the .md changes that broke it ;D
< vasild>
any idea how did this sneak into master?
< fanquake>
vasild: no, I haven't investigated yet
< vasild>
maybe one of 1. it is undeterministic failure and the PR that introduced it was lucky to get green. or 2. somebody merged a red/broken PR or 3. changes in the travis environment that revealed an existent problem.
< aj>
vasild: or it only comes about because of two changes that were independently okay
< vasild>
now, if we can explain why travis was green on the PR that introduced the issue I will sleep well tonight
< bitcoin-git>
[bitcoin] brakmic opened pull request #18377: build: fix libevent linking errors for bench-only builds (master...bench-compilation) https://github.com/bitcoin/bitcoin/pull/18377
< willcl_ark>
Is it worth me opening an issue for this project related to with a specific clang version segfaulting during tests, if the solution is to simply upgrade clang?
< fanquake>
willcl_ark: what version of Clang?
< willcl_ark>
fanquake: 11.0.0 (bundled with commandlinetools). Upgrading to 11.0.3 fixed.
< fanquake>
So Apple Clang?
< willcl_ark>
Indeed
< fanquake>
Was the issue related to stack checking?
< fanquake>
Possibly libsecp related?
< willcl_ark>
yes libsecp test segfaulted too. wait I'll just recall the error
< willcl_ark>
ah great, I just wanted to make sure it was documented within this project in some way :)
< fanquake>
willcl_ark: no worries, thanks for asking
< stevenroose>
I'd like to get a clear summary of the peering strategy for Core nodes. Especially regarding limits (incoming and outgoing) and how the limit applies to `connect=`. Is that written up somewhere?
< stevenroose>
Personally I assumed that `connect=` configs would have no limit as they are a clear order "make sure you connect to this peer always". But it seems that they might fall under the 8- (or 12?) peer outgoing connection limit?
< stevenroose>
These policies are quite hard to find in the code, tbh. Hence my Q here :)
< harding>
stevenroose: the -help documentation for connect= says "Connect only to the specified node"
< harding>
Oh, your question is how many times you can specify -connect?
< stevenroose>
Yeah..
< stevenroose>
No mostly it is "if I specify 30, will it connect to all 30 or will it stop at the 8 (or 12?) limit?"
< sipa>
i think 8 times
< stevenroose>
IMO "Connect only to the specified node" should be "Connect to the specified node"
< sipa>
no
< stevenroose>
Hmm no
< sipa>
-connect disables the normal automatic connection mechanism
< stevenroose>
Indeed, because that doesn't rule out that it doesn't connect to others.
< stevenroose>
sipa: so your understanding is as well that with 9 `connect=`'s, it will just pick 8 of them to connect to? And probably pick the 9th if one of the 9 goes down?
< sipa>
stevenroose: i believe it's something like that
< stevenroose>
Is there a way to make a node connect to *all* `connect=`'s? By upping the limit? By config? Or can that only be done through a code change?
< sipa>
no
< sipa>
and yes, intentionally
< stevenroose>
The docs don't mention the limit, though: "This option can be specified multiple times to connect to multiple nodes."
< sipa>
(because a while ago there was a flurry of people who believed that more connections means better, faster, safer, ...; and were causing the network to run out of connectable ports)
< stevenroose>
Hmm. Well I understand that having a `-outgoinglimit` flag is exploitable.
< stevenroose>
But letting `-connect=` go over the limit is way harder to exploit.
< yevaud>
if you think you need more outgoing connections, you almost certainly don't.
< stevenroose>
These people would have to keep adding nodes to their config files.
< sipa>
yeah, generally there is no point
< stevenroose>
yevaud: special-case situation
< yevaud>
there's no special cases that justify it, honestly. manually pinning certain peers causes a bunch of issues.
< yevaud>
for running nodes behind a network of external gateways, sure, but that's a very specific use case which doesn't need a large number of them.
< stevenroose>
yevaud: briefly explained we're trying to bridge a bunch of internla nodes that only interconnect with the public network through 2 bridges. And we want to ensure the bridges connect to the internal nodes but also at least a few public connections
< sipa>
stevenroose: you can use -addnode instead
< yevaud>
you want addnode, which has a different connection pool to outgoing connections.
< sipa>
which works like -connect, but doesn't disable the normal random peer mechanism
< yevaud>
and you have that backwards anyway.
< yevaud>
internal nodes want to be connecting to the bridges, not the other way around.
< yevaud>
just from a management perspective it's a lot less painful.
< stevenroose>
yeah so somehow we've been trying to make the bridge not accept incoming connections to prevent them from being DoS'ed (I think), but I'm starting to quesiton that requirement
< stevenroose>
AFAIU if some public nodes we have and all the internal ones just -addnode the bridges, it should all work
< yevaud>
read about whitebind, and the docs in general.
< sipa>
stevenroose: all these nodes (bridges, internal ones) connect over the public internet, right? no VPN or so
< stevenroose>
sipa: all tor
< sipa>
so if the onion addresses are kept secret, there is no risk for incoming DOS to the bridge nodes
< sipa>
whitebind won't help in this case
< yevaud>
for bridges you definitely want whitebind for the transaction relay logic.
< stevenroose>
hmm yeah I think I'm getting the gist of what we should do. Thanks.
< yevaud>
don't listen on bridges, whitebind on them, and use connect on the "hidden" peers.
< bitcoin-git>
[bitcoin] MarcoFalke merged pull request #18300: fuzz: Add option to merge input dir to test runner (master...Mf1902-fuzzMerge) https://github.com/bitcoin/bitcoin/pull/18300
< bitcoin-git>
[bitcoin] MarcoFalke opened pull request #18380: doc: Remove html comment in PULL_REQUEST_TEMPLATE (master...2003-docGitHubTemplateNoComment) https://github.com/bitcoin/bitcoin/pull/18380
< bitcoin-git>
[bitcoin] practicalswift closed pull request #18308: depends: Make it possible to build Boost dependency using a clang toolset (./b2 toolset=clang) (master...b2-toolset-clang) https://github.com/bitcoin/bitcoin/pull/18308