< MarcoFalke>
returns "bitcoincorewallet org" as third result
< MarcoFalke>
obviously malware
< moneyball>
MarcoFalke not sure but perhaps https://twitter.com/duckduckgo? although I think you said you quit Twitter. I can report it. Do we have evidence of malware? Or should I just say it looks suspicious?
< MarcoFalke>
Download any of the .exe or .zip and compare the hash
< MarcoFalke>
Even if the hash matched, it is not our website and not the official download location
< bitcoin-git>
[bitcoin] MarcoFalke closed pull request #16192: Wallet: Catches situations where capping on maxtxfee drops the fee too low (master...issue-10122) https://github.com/bitcoin/bitcoin/pull/16192
< bitcoin-git>
[bitcoin] MarcoFalke reopened pull request #16192: Wallet: Catches situations where capping on maxtxfee drops the fee too low (master...issue-10122) https://github.com/bitcoin/bitcoin/pull/16192
< MarcoFalke>
moneyball: thx
< BlueMatt>
lol 3 dnsseeds have broken ipv6 resolvers.......
< moneyball>
fyi i also emailed abuse@ and cc'd MarcoFalke
< BlueMatt>
thanks moneyball!
< bitcoin-git>
[bitcoin] hebasto opened pull request #16254: qt: Set AA_EnableHighDpiScaling attribute early (master...20190620-EnableHighDpiScaling-warning) https://github.com/bitcoin/bitcoin/pull/16254
< BlueMatt>
sipa: maybe your seeder is broken for resolving over v6?
< jonasschnelli>
I do iptables -t nat -A PREROUTING -p udp --dport 53 -j REDIRECT --to-port 5353
< BlueMatt>
ah, should be able to do that for v6 too
< BlueMatt>
"IPv6 support available starting Linux kernels >= 3.7." (for REDIRECT)
< jonasschnelli>
I guess I need ip6tables
< BlueMatt>
indeed
< jonasschnelli>
instead of the stupid NAT, why don't allow the dnsseed user to use UDP 53 directly?
< jonasschnelli>
(should also work without root)
< luke-jr>
?
< luke-jr>
Linux doesn't allow non-root to listen below 1024
< jonasschnelli>
luke-jr: we do the NAT to avoid running the seeder as root
< jonasschnelli>
setcap?
< BlueMatt>
bind + drop
< luke-jr>
dunno why Linux doesn't add a way to assign ports to specific users :/
< luke-jr>
that would also be nice to block other users from binding the Bitcoin JSON-RPC port
< BlueMatt>
you could use inetd, no?
< jonasschnelli>
solved....
< jonasschnelli>
dig -p 53 @2604:a880:2:d0::469c:c001 AAAA seed.bitcoin.jonasschnelli.ch <--- works now
< jonasschnelli>
(testnet seed as well)
< phantomcircuit>
luke-jr, you can with the power of selinux
< * phantomcircuit>
runs
< gertjaap>
are there any docs on how to run the linters and checks that travis does locally before committing? i hate to bother reviewers with stuff that i should've caught before committing.
< gertjaap>
if i run test/lint/lint-all.sh it does catch the whitespace errors from my PR, but also a whole bunch of other stuff like unused functions and spelling errors.
< jnewbery>
We've got a solid group of attendees every week, and some of them are commenting on and reviewing PRs in github, so I think it's been reasonably successful so far.
< jnewbery>
If anyone wants to get involved, we have IRC meetings at 17:00 UTC on Wednesdays. Appearances from established contributors are always appreciated.
< jonasschnelli>
thanks for doing this jnewbery!
< jnewbery>
If you have any friends who are less experienced and want to get into Bitcoin Core development, you should send them along
< wumpus>
yes, great!
< jnewbery>
I'm away for the next couple of weeks and I'm looking for one or two volunteer hosts, so please message me if you're interested
< meshcollider>
Very cool, I would definitely come if it wasn't at 5am haha
< jnewbery>
oh, and finally, if you have any suggested PRs for us to cover, please message me also. We're looking for stuff that doesn't require too much esoteric knowledge and is a reasonable size (perhaps ~100 LOC)
< jnewbery>
that's all. Thanks!
< BlueMatt>
can we do asns? I want to take a nap
< wumpus>
thanks jnewbery
< BlueMatt>
also, +1 thanks jnewbery
< wumpus>
#topic ASN blobs (BlueMatt)
< BlueMatt>
well maybe sipa can introduce
< BlueMatt>
but the idea is, basically, why are we bucketing by /16s
< BlueMatt>
its an easy hack, but there's lots of isps with way more than /16s and lots with way less
< sipa>
to give some context
< BlueMatt>
our goal, really, is to capture diversity of isps/hosting providers
< BlueMatt>
we also have seen several groups of spy nodes/large-connection-farms from several different places, but, all together, they originate from < 10 isps
< BlueMatt>
despite being a *ton* of ips
< sipa>
we're currently "grouping" certain IP ranges into groups, to make decisions such as whether to make multiple connections to the same range or not, prioritize incoming connections from distinct groups, and control which addrman buckets IPs go into (under the theory that an attacker has a hard time controlling many groups, sybil resistance is improved)
< sipa>
right now, those are just /16 groups
< sipa>
for most things
< sipa>
but /16 is a really naive choice; some ISPs control very large ranges, some very small ones
< sipa>
an obvious improvement is to have a map built-in to bitcoin core that tells what the actual independent network ranges are
< wumpus>
so the practical problem would be how to include enough of this data to be useful, but without adding too much data to the executable size
< luke-jr>
BlueMatt: don't ASNs change?
< sipa>
so i've been working on seeing how large such a map for real internet data would be, and it turns out we can pack it in around 1 MB, and still efficiently look things up in it
< BlueMatt>
luke-jr: sure, but not a *lot*
< wumpus>
yes, they change, it'd be at most an approximation at the time of release
< luke-jr>
and even if the same ISP owns a big range, that range may be very diverse?
< wumpus>
but that's good enough
< BlueMatt>
diverse how? against any practical attacks that grouping helps prevent, not diverse at all (mitms, sybils, etc)
< wumpus>
we don't really want to include all the data in our github repo though
< luke-jr>
BlueMatt: depends on the attack I guess
< wumpus>
so I guess this is some kind of challenge for the deterministic builds
< BlueMatt>
well we could incoporate a text file dump of a routing table into the build process
< BlueMatt>
thats not too hard
< sipa>
so i've used a dump from BGP (which is... a gigabyte or so) to extract a mapping from prefixes to ASNs, and then developed a custom packed format to store just the mapping
< wumpus>
yes, but it should be determinstic per version, without including it into the repo itself
< luke-jr>
we don't actually need the ASNs though, right? just some logic to decide whether to group by /16, /24, /8, etc
< BlueMatt>
indeed, we'd have to agree on a source (we could use my dumps, or get them from one of several others who provide dumps, or get output from anyone's bird router)
< sipa>
luke-jr: correct; though consistency matters for things like addrman
< wumpus>
that does add some requirements, maybe it's not hard, but it's also not something we've done before
< sipa>
as we don't want to change what number each range maps to too frequently
< luke-jr>
although maybe some ISPs have multiple subnets
< sipa>
and ASN numbers are small
< sipa>
(most are below 2^16, all are below 350000 or so)
< wumpus>
luke-jr:yes, quite a few ISPs have non-consecutive subnets
< sipa>
luke-jr: indeed, and that's actually by design
< sipa>
this would give most of AWS one number
< BlueMatt>
hmm, is there some attack whereby someone just flips their asn every 6 months per release and gets into several buckets? I mean at most you'd get one per six months
< sipa>
yeah, it's not terrible
< sipa>
just better to be consistent when possible
< BlueMatt>
which i guess is also plenty of time to register a new asn, buy some ips, and sell the old ones
< sipa>
so i think a question for here is, what binary size increase is acceptable and/or is it a separate file with the map that can be replaced?
< BlueMatt>
separate file seems ideal to me, but that has deployment concerns
< BlueMatt>
I dont think we could realistically say "take this file that shipped with bitcoin core and copy it to your datadir on first run"
< sipa>
and what kind of auditing is necessary for it... not everyone is able to extract a BGP dump and compare the result (and it wouldn't be consistent across dumps anyway)
< BlueMatt>
we could get my dump, and a few other dumps and have a tool to compare them?
< BlueMatt>
there's several providers, so it should be doable
< sipa>
just a text list of prefix -> ASN mappings is just a few MB
< luke-jr>
maybe we should only do it for 4 of the 8 peers?
< BlueMatt>
well I guess two hard proposals, pick one:
< BlueMatt>
a) build it into the binary
< luke-jr>
in case ther'es a way to game it
< BlueMatt>
b) ship a file and (1) look in datadir, (2) if not there, look in the folder where bitcoind is being run from.
< BlueMatt>
b) (3) if not, print warning and fall back to /16s
< achow101>
is it possible to do both? i.e. build it in and have a separate file in datador
< sipa>
yeah
< jnewbery>
I'd say not (a). We don't want to add a MB of data to the repo
< achow101>
so datadir file overrides built in
< jnewbery>
do we want people to be able to override?
< BlueMatt>
right, but its mostly a binary size question
< sipa>
jnewbery: but the distribution should still include it
< wumpus>
well the build could fetch it somewhere else, it doesn't need to be in the repo
< jb55>
why does it have to be in-tree? couldn't it be a dependency?
< jnewbery>
yes, i think the distribution should include it
< jb55>
yeah
< wumpus>
it definitely shouldn't be *
< BlueMatt>
jnewbery: doesnt *technically* have to be in the repo
< luke-jr>
BlueMatt: data files shouldn't be in bin/
< BlueMatt>
it could be in the binary without that, as a separate input to gitian
< BlueMatt>
luke-jr: if you're using a distribution, it should install it appropriately, if you're downloading the targz, then it can be wherever
< luke-jr>
BlueMatt: datadir is per-user, so can't install there
< BlueMatt>
further opinions?
< jnewbery>
Do we want people to be able to supply their own. I think no
< BlueMatt>
luke-jr: sure, that doesnt mean its not allowed to be there? there's also a copy of the chain there, which is not per-user :p
< sipa>
jnewbery: i see no reason not to allow that
< luke-jr>
BlueMatt: it means the distro can't install it there
< sipa>
we'd have the scripts to build the blob from a list of mappings in contrib/ i guess
< wumpus>
could have an argument to point to where it is
< BlueMatt>
yes, definitely have to make it possible to generate your own, given the input is otherwise hard to audit
< BlueMatt>
luke-jr: yes, hence an option like -look-in-var
< wumpus>
datadir would only be the default, like it is for other things too unless overridden
< luke-jr>
so force distros to patch it?
< wumpus>
but I think we're very much getting into specific implementation details now
< jnewbery>
because then bad people might supply a bogus network.dat (or whatever) file and tell people to use it
< wumpus>
well that's true for any file, like peers.dat too
< gwillen>
I think you could limit the damage a bad network.dat could do by putting sanity checks on it
< wumpus>
or like a malicious wallet
< gwillen>
e.g. no aggregating the entire internet into a single "ASN", that sort of thing
< sipa>
wumpus: are you talking about having it always as a separate file (which may be sourced from several locations), or having it built into the binary (with the option to source it from elsewhere)
< wumpus>
if you get people to install bogus files into their datadir it's kind of bad
< BlueMatt>
(hopefully, many of these classes of attacks can be further limited by better peer eviction logic, so hopefully thats not *that* easy)
< wumpus>
sipa: the latter, I think
< harding>
Perhaps it should start as a separate file and then, later, if it's working well it can be considered for direct inclusion in the binary.
< wumpus>
sipa: I'm ok with including the data in the distributed binary, I just don't want it in the repository
< sipa>
ok fair
< wumpus>
harding: good point too
< wumpus>
first add support for this
< wumpus>
then the rest later
< sipa>
yeah
< wumpus>
#topic Requiring 2FA for bitcoin orgs on GH (fanquake)
< jonasschnelli>
I guess I we should disable sms 2fa recovery...
< luke-jr>
eh, maybe for people with push? it doesn't really matter for most of us
< luke-jr>
GH doesn't even check 2FA all that often either
< BlueMatt>
i mean push is pgp-signed (at least in theory)
< BlueMatt>
matters most for acks
< wumpus>
jonasschnelli: so is that possible on an organization?
< BlueMatt>
but, yea, I think I've not had to re-login to github in...years?
< jonasschnelli>
no... I think need to be done on an individual level
< luke-jr>
BlueMatt: GitHub being trusted with ACKs is a problem in itself :x
< BlueMatt>
indeed
< * jeremyrubin>
acks on the blockchain
< luke-jr>
(why nobody sees it)
< * BlueMatt>
-> nap
< wumpus>
I don't think there's actually much to discuss here: in any case, if you read this and haven't enabled 2FA please do so if possible
< jonasschnelli>
Yes. And disable phone 2fa recovery
< jonasschnelli>
(probably use FIDO key and recovery code for backup)
< wumpus>
ok, any other topics? I think we're through
< phantomcircuit>
jonasschnelli, at an organization level you can only enforce that some form of 2fa is enabled, not which type
< achow101>
meshcollider: sipa: I've been working on implementing the scriptpubkeymanager and I noticed a bunch of things related to key generation rely on the wallet version and wallet flags. Thoughts on how to handle those without introducing a circular dependency?
< sipa>
achow101: expose some options in the LegacySPKMAnager (or whatever you call the instance of it that encapsulated the current ismine/keypool/...), as constructor arguments, and at wallet creation pass the flags down as options to it?
< achow101>
there happen to be some things that can happen after a wallet is loaded that can change the flags though. also the flags aren't necessarily loaded when legacyspkmanager is created
< achow101>
I supposed a pointer would work?
< sipa>
maybe, but be careful about locking
< sipa>
spkmamagers won't have access to a wallet's locks probably
< achow101>
right
< achow101>
also a minor problem with wallet.h defining the flags but including it in any of the spkmanager files results in a circular dependency
< sipa>
if the only way to change a wallet's property is through a setter method, that method can just delegate to calling the legacyspkmanager's corresponding setter