< BlueMatt>
sipa: the sipa.be ns servers dont have v6 entries
< BlueMatt>
ie the ulyssis.org ones
< BlueMatt>
you want dig -6 +trace seed.bitcoin.sipa.be aaaa
< sipa>
ah
< sipa>
yup
< achow101>
provoostenator: After actually attempting to make all of the commits in #16341 compile with the whole move instead of copy thing, I don't think it will make it any easier to review, actually probably harder. IMO Having to introduce temporary functions and changes everywhere only to remove them a few commits later makes it way harder to review as some commits basically have no effect on the final product
< gribble>
https://github.com/bitcoin/bitcoin/issues/16341 | Introduce ScriptPubKeyMan interface and use it for key and script management (aka wallet boxes) by achow101 · Pull Request #16341 · bitcoin/bitcoin · GitHub
< achow101>
I ended up having to introduce several temp functions to expose some internals of LegacyScriptPubKeyMan which resulted in a bunch of changes to CWallet that were basically then removed in the subsequent commit. Having to keep track of all of these temp things and then removing them and restoring the correct behavior is far more work than it's worth IMO
< achow101>
so I'm not going to continue doing that
< provoostenator>
That sounds painful indeed
< provoostenator>
Can you push a temp branch somewhere though?
< provoostenator>
Either way, it was worth watching the stream the Wednesday just to see you try :-)
< gleb>
Public bitcoin nodes use about 1200 ASNs. 20 of those ASNs represent 50% of the nodes, and just 3 ASNs represent 25%. This means that suggested ASN-based bucketing bias would make more (potentially, mission-critical) connections to those tiny unpopular ASNs than it is today. Is this well-understood? Is this the effect we want? I'm not sure.
< provoostenator>
BlueMatt: the good news is, this works now: dig -6 -t AAAA seed.bitcoin.sprovoost.nl
< provoostenator>
The bad news is that I probably messed up the DNS for my entire domain in the process, so will clean that up now :-(
< gleb>
The benefit from ASN bucketing is clear from the standpoint of a single node, but for the network overall I dunno. Should we additionally enforce everybody connecting to a random node from top-3 ASNs?
< sipa>
gleb: i'm not sure, but maybe it helps to look at it from the other direction: it's expected that a huge number of nodes right now are on large providers (AWS, large VPS providers, ...); biasing by ASN would significantly reduce the number of connections to those in favor of others, but I think that's desirable
< sipa>
having 100s of nodes on AWS doesn't actually add much partition resistance from the perspective of someone connecting to it
< BlueMatt>
gleb: indeed, what sipa said...last I looked the vast majority of nodes were on a few providers - aws, digitalocean, hertzner and such
< BlueMatt>
connecting only to those is, thus, likely not an uncommon case
< BlueMatt>
and is clearly useless
< sipa>
an orthogonal idea may be to have 1 or 2 additional connections within your local network/ASN
< BlueMatt>
I dont know how much "few nodes on an asn" correlates with "small isp in the middle of nowhere which doesn't want to serve a lot of traffic", it probably correlates a bit but I'd presume it correlates more with "residential isp with few hosted nodes"
< BlueMatt>
right, likely want that, too
< BlueMatt>
maybe a third and fourth blocks-only connection or so to local asn
< gleb>
Now it's very possible to connect to only those, which is obviously bad. I'm just saying that ASN bucketing might result in connecting to ONLY pocket vulnerable ISPs
< gleb>
So if the cost of partition is bribing, I think having 7 pocket ISPs + AWS is in this case better than 8 pocket ISPs :)
< sipa>
what is a pocket ISP?
< gleb>
something unpopular and easy to influence
< gleb>
I might be missing the threat model here
< sipa>
actually, the rule "at most one outgoing connection per ASN" isn't quite the same as "connections are uniformly sampled over all ASNs"; larger networks are still more likely to reason connections - just not more than one per outgoing peer
< sipa>
s/reason/receive/ no idea how i made that typo
< * sipa>
drinks coffee
< gleb>
Well, that's partially what i'm asking about. I thought the current idea is uniformly random sample over all ASNs, and I questioned this idea.
< sipa>
no, clearly an ASN with no known peers won't get any connections :)
< sipa>
the outgoing connection logic just randomly picks a known peer (with some biases already, like favoring port 8333), and then there is a rejection sampling which throws away results within a "group" we already have an outgoing connection to
< gleb>
I just thought of it this way: take all ASNs you know peers from, sample 8 unique ones, connect to peers from those 8
< gleb>
But I guess we will sample peers first, which would result in connecting to AWS at least once anyways.
< sipa>
right
< gleb>
Okay, I'll see if there's a good place in the code or PR I can document this observation, because for me it took a while to understand it.
< sipa>
the suggestion is to change the definition of groups to be ASNs
< sipa>
that's the outgoing connection peer selection logic
< sipa>
it's fairly well documented
< gleb>
I was more worried that if this code is changed we might end up with uniform distribution across all asns due to this new bucket logic
< gleb>
"If changing bucketing code again, don't shoot in your leg"
< sipa>
if we feel the bias towards small asns is too strong as a result of this, the policy could also be permitting two connections to large asns
< sipa>
or to treat large asns as multiple groups
< gleb>
Now that you mitigated my misunderstanding I think it's fine since we'll very likely to have one connection to large asns and I don't see a huge benefit in having 2 instead of 1
< provoostenator>
sipa petertodd, cdecker, luke-jr: to make my seed visible to IPv6-only nodes, I had to do two things:
< provoostenator>
1. add an AAAA record from seed.bitcoin.sprovoost.nl. to the IPv6 address of the seed
< provoostenator>
2. make sure all DNS providers starting from my domain registrar can actually handle IPv6 (I had to move stuff for that reason)
< provoostenator>
"dig -6 -t AAAA +trace seed.bitcoin.sprovoost.nl" can be helpful seeing where the buck stops, ht BlueMatt
< provoostenator>
Where -6 forces going over IPv6
< bitcoin-git>
[bitcoin] LarryRuane opened pull request #16577: util: CBufferedFile fixes and unit test (master...CBufferedFile-fixes) https://github.com/bitcoin/bitcoin/pull/16577
< bitcoin-git>
[bitcoin] achow101 opened pull request #16578: Do not pass in command line arguments to QApplication (master...no-qapp-args) https://github.com/bitcoin/bitcoin/pull/16578
< roasbeef>
does everyone use the same software to operate their DNS seed? do they need to be manually updated to respond to queries for "new" service bits? for example, of the seeds i'm aware of, only seed.bitnodes.io responds to queries for teh x49 subdomain (full node, segwit, bip 158)
< emzy>
I think most using sipas dnsseed software, ecexpt one.
< sipa>
my seeder can be configured to support any subset of service bit combinations
< emzy>
I run the default.
< emzy>
any recomendation which service bit combinations to enable on the dnsseed?