< bitcoin-git> [bitcoin] NicolasDorier opened pull request #16246: MSVC: Fix error in debug mode (Fix #16245) (master...fix/bigobj) https://github.com/bitcoin/bitcoin/pull/16246
< bitcoin-git> [bitcoin] NicolasDorier opened pull request #16248: [WIP] Make whitebind/whitelist permissions more flexible (master...feature/permissions) https://github.com/bitcoin/bitcoin/pull/16248
< bitcoin-git> [bitcoin] NicolasDorier closed pull request #16176: Allow NODE_BLOOM services for whitelisted peers (master...feature/node-bloom-whitelisted) https://github.com/bitcoin/bitcoin/pull/16176
< bitcoin-git> [bitcoin] ajtowns opened pull request #16250: signrawtransactionwithkey: report error when missing redeemScript/witnessScript (master...201906-signrawerror-regression) https://github.com/bitcoin/bitcoin/pull/16250
< bitcoin-git> [bitcoin] ajtowns opened pull request #16251: Improve signrawtransaction error reporting (master...201906-signrawerror) https://github.com/bitcoin/bitcoin/pull/16251
< fanquake> I’m quite unwell, so won’t be up at the meeting. +1 for 2FA. Ideally not text message based.
< fanquake> #proposedmeetingtopic ASN blob discussion that was missed at the end of last meeting. Assuming sipa and bluematt are available.
< bitcoin-git> [bitcoin] MarcoFalke opened pull request #16252: test: Log to debug.log in all unit tests (master...1905-bufferLog) https://github.com/bitcoin/bitcoin/pull/16252
< MarcoFalke> Anyone knows how to report scams to duckduckgo? https://duckduckgo.com/?q=bitcoin+core+release+notes
< 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?
< bitcoin-git> [bitcoin] MarcoFalke opened pull request #16255: util: Remove code to cache datadir (master...1906-utilNoPath) https://github.com/bitcoin/bitcoin/pull/16255
< sipa> BlueMatt: it seems the vps it's running on doesn't have a v6 ip address :s
< BlueMatt> sipa: no, I mean the software
< BlueMatt> sipa: cause it seems several others have v6 issues and theirs does
< sipa> BlueMatt: my seeder has v6 addresses, but they're all marked "bad"
< sipa> so i suspect that's why it's not reporting any over dns
< BlueMatt> sipa: nonono, I mean the seeder software responding to dns queries over v6
< sipa> it's responding for me, just with an empty result
< sipa> $ dig -t AAAA @bitcoin.sipa.be seed.bitcoin.sipa.be
< BlueMatt> sipa: noooo
< BlueMatt> I mean $ dig @(bitcoin.sipa.be's ipv6 address) seed.bitcoin.sipa.be
< luke-jr> in my case, I don't want to run the seeder as root, so I have a NAT from port 53 to 1053, but my server doesn't support NAT for IPV6
< luke-jr> removed the AAAA record for the NS for now
< sipa> BlueMatt: ... my server has no IPv6 address
< BlueMatt> yea, you're different, mostly I see that (at least) emzy's and jonasschnelli's servers dont respond
< BlueMatt> sipa: yes...I'm asking about the software (which other seeders run)
< sipa> ah ok, it seems there are two distinct problems
< luke-jr> BlueMatt: the software is listening to IPv6 1053 for me
< BlueMatt> luke-jr: can you try to resolve via that?
< phantomcircuit> BlueMatt, hi
< BlueMatt> you rang?
< luke-jr> dig -p 1053 @2001:470:88ff:2e::1 AAAA dnsseed.bitcoin.dashjr.org
< luke-jr> seems to work
< BlueMatt> ah weird, maybe something specific about the version/setup on emzy and jonasschnelli's ends :/
< hebasto> MarcoFalke: in #16254 should we follow qt docs: "Supported platforms are X11, Windows and Android."? I mean no mention of macOS.
< gribble> https://github.com/bitcoin/bitcoin/issues/16254 | qt: Set AA_EnableHighDpiScaling attribute early by hebasto · Pull Request #16254 · bitcoin/bitcoin · GitHub
< bitcoin-git> [bitcoin] MarcoFalke closed pull request #16255: util: Remove code to cache datadir (master...1906-utilNoPath) https://github.com/bitcoin/bitcoin/pull/16255
< jonasschnelli> Yeah. It's the NAT
< jonasschnelli> dig -p 5353 @2604:a880:2:d0::469c:c001 AAAA seed.bitcoin.jonasschnelli.ch
< jonasschnelli> works as well
< 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.
< luke-jr> check the exit code
< sipa> BlueMatt: ok, i have an IPv6 address!
< sipa> (i had it all along, but apparantly i had to configure it as a static ip on the system)
< luke-jr> ISPs are supposed to give you a /48 subnet :P
< BlueMatt> sipa: lol nice
< sipa> BlueMatt: does it work now?
< sipa> i expect not
< BlueMatt> sipa: I'm on a plane....things r slow....
< sipa> ha
< BlueMatt> sipa: I dont get a response from 2607:5300:201:3100::3b74
< sipa> bleh
< sipa> ok, now my seeder is actually returning ipv6 addresses when requested
< sipa> still not available over ipv6 itself
< jonasschnelli> sipa: do you do port forwarding to avoid running it as root?
< sipa> yes
< jonasschnelli> so you either need ip6tables forwarding or switch back to port 53
< sipa> yes
< jonasschnelli> sudo setcap 'cap_net_bind_service=+ep' /path/to/dnsseeder
< jonasschnelli> would allow to occupy port 53 without root
< sipa> i use ip6tables, but apparently not correctly :)
< wumpus> #startmeeting
< lightningbot> Meeting started Thu Jun 20 19:01:09 2019 UTC. The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
< lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
< sipa> hello
< jeremyrubin> hi
< jonasschnelli> hi
< wumpus> #bitcoin-core-dev Meeting: wumpus sipa gmaxwell jonasschnelli morcos luke-jr sdaftuar jtimon cfields petertodd kanzure bluematt instagibbs phantomcircuit codeshark michagogo marcofalke paveljanik NicolasDorier jl2012 achow101 meshcollider jnewbery maaku fanquake promag provoostenator aj Chris_Stewart_5 dongcarl gwillen jamesob ken281221 ryanofsky gleb moneyball kvaciral
< achow101> hi
< meshcollider> hi
< wumpus> two topics proposed in https://gist.github.com/moneyball/071d608fdae217c2a6d7c35955881d8a : Bitcoin core PR review club, ASN blob discussion
< kanzure> hi
< wumpus> also maybe we want to discuss the travis issue again
< meshcollider> Also 2FA discussion from fanquake
< moneyball> hi
< wumpus> #topic High priority for review
< wumpus> https://github.com/bitcoin/bitcoin/projects/8 5 blockers, 2 bugfixes and 6(!) things chasing concept ack
< wumpus> anything to add/remove this week ?
< jnewbery> hi
< wumpus> ok, apparently nothing to discuss in regard to that
< wumpus> #topic Bitcoin Core PR review club (jnewbery)
< jnewbery> Thanks wumpus
< jnewbery> I just wanted to give an update on the Bitcoin Core Review Club (https://bitcoin-core-review-club.github.io/) that we've been doing for the last couple of months.
< 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
< sipa> when gzipped
< BlueMatt> eg you could get a bunch of dumps from https://rt-bgp.he.net/
< BlueMatt> (including mine, indirectly)
< sipa> so opinions?
< 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
< sipa> oh also short reminder we're going to meet with github tomorrow, if there are any things we should bring up, see https://github.com/bitcoin/bitcoin/issues/15847
< wumpus> good to know sipa
< wumpus> thanks everyone
< wumpus> #endmeeting
< lightningbot> Meeting ended Thu Jun 20 19:44:21 2019 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
< bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/413e438ea976...9c95515ba034
< bitcoin-git> bitcoin/master fa00326 MarcoFalke: ci: Run extended tests
< bitcoin-git> bitcoin/master 9c95515 MarcoFalke: Merge #15520: cirrus: Run extended test feature_pruning
< bitcoin-git> [bitcoin] MarcoFalke merged pull request #15520: cirrus: Run extended test feature_pruning (master...1903-ciExt) https://github.com/bitcoin/bitcoin/pull/15520
< 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
< bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/9c95515ba034...ea45967e856d
< bitcoin-git> bitcoin/master fa7dd88 MarcoFalke: test: Add test for unknown args
< bitcoin-git> bitcoin/master ea45967 MarcoFalke: Merge #16234: test: Add test for unknown args
< bitcoin-git> [bitcoin] MarcoFalke merged pull request #16234: test: Add test for unknown args (master...1906-unknownArgs) https://github.com/bitcoin/bitcoin/pull/16234
< bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/ea45967e856d...b4ad4c0de30f
< bitcoin-git> bitcoin/master 9218ce8 Aseem Sood: Failing functional tests stop lcov
< bitcoin-git> bitcoin/master b4ad4c0 MarcoFalke: Merge #16207: test: stop generating lcov coverage when functional tests fa...
< bitcoin-git> [bitcoin] MarcoFalke merged pull request #16207: test: stop generating lcov coverage when functional tests fail (master...patch-15648) https://github.com/bitcoin/bitcoin/pull/16207
< bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/b4ad4c0de30f...23815ee74dfd
< bitcoin-git> bitcoin/master eb832cd nicolas.dorier: MSVC: Fix error in debug mode (Fix #16245)
< bitcoin-git> bitcoin/master 23815ee MarcoFalke: Merge #16246: MSVC: Fix error in debug mode (Fix #16245)
< bitcoin-git> [bitcoin] MarcoFalke merged pull request #16246: MSVC: Fix error in debug mode (Fix #16245) (master...fix/bigobj) https://github.com/bitcoin/bitcoin/pull/16246
< bitcoin-git> [bitcoin] jonatack opened pull request #16256: doc: remove orphaned header in developer notes (master...remove-orphaned-header-link-in-developer-notes) https://github.com/bitcoin/bitcoin/pull/16256