19:02:03 <wumpus> #startmeeting
19:02:03 <lightningbot> Meeting started Thu Oct 25 19:02:03 2018 UTC.  The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:02:03 <lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
19:02:09 <promag> howdy
19:02:15 <achow101> hi
19:02:34 <gleb> hi
19:02:49 <wumpus> hey
19:03:33 <jonasschnelli> Hi
19:03:33 <wumpus> #bitcoin-core-dev Meeting: wumpus sipa gmaxwell jonasschnelli morcos luke-jr btcdrak sdaftuar jtimon cfields petertodd kanzure bluematt instagibbs phantomcircuit codeshark michagogo marcofalke paveljanik NicolasDorier jl2012 achow101 meshcollider jnewbery maaku fanquake promag provoostenator
19:03:34 <sipa> hi
19:03:48 <luke-jr> ..
19:03:59 <midnightmagic> \o
19:05:04 <wumpus> topics?\
19:05:37 <jonasschnelli> topic proposal: 0.17.0.1 or 0.17.1
19:05:39 <sipa> what is the status with the linter issues on travis?
19:06:07 <phantomcircuit> hello
19:06:59 <wumpus> #topic 0.17.0.1 or 0.17.1
19:07:34 <jonasschnelli> I think we should release 0.17.0.1 (osx only) to mitigate the non opening DMG issue with 0.17 (https://github.com/bitcoin/bitcoin/pull/14416)
19:08:47 <jonasschnelli> We could release just 0.17.0 + 14416 as 0.17.0.1 macOS only (not release the current 0.17 branch)
19:09:04 <luke-jr> #14416
19:09:06 <gribble> https://github.com/bitcoin/bitcoin/issues/14416 | Fix OSX dmg issue (10.12 to 10.14) by jonasschnelli · Pull Request #14416 · bitcoin/bitcoin · GitHub
19:09:33 <jonasschnelli> The current DMG provided in bitcoincore.org/bin does not open on macOS
19:09:34 <wumpus> agree, would make sense to make a 0.17.0.1 for macosx only
19:09:43 <luke-jr> jonasschnelli: the only other fix currently in the branch is so minor, it wouldn't make sense to make a new branch for 0.17.0.1
19:10:18 <jonasschnelli> We can also directly move to 0.17.1,...
19:10:23 <sipa> that seems in line with versioning we've used before, using the 4th number for platform specific fixes
19:10:25 <luke-jr> doesn't MarcoFalke have a bunch of fixes backported to 0.17 though? might make more sense to just move on 0.17.1
19:10:41 <luke-jr> sipa: sure, I'm just saying we can tag it on 0.17 branch
19:11:02 <sipa> some of those may be nontrivial; i saw some issue with his backports PR having a merge conflict?
19:11:03 <cfields> luke-jr: that would mean that Mac users couldn't drop back to 0.17 if 0.17.1 was buggy.
19:11:09 <cfields> +1 for 0.17.0.1
19:11:16 <luke-jr> cfields: 0.17.1 should only be fixes on top of 0.17.0 anyway
19:11:39 <wumpus> sipa: yep
19:12:52 <promag> we could pick the simple backport fixes (including macos fix) and let the remaining for 0.17.2?
19:12:59 <wumpus> I dont' think we have enough for 0.17.1 yet
19:13:13 <wumpus> if a lot of people are experiencing issues with 0.17.0 on MacOSX we should do 0.17.0.1 soon
19:13:16 <wumpus> like, tomorrow
19:13:36 <sipa> agree
19:13:41 <jonasschnelli> ack
19:13:50 <cfields> sgtm
19:13:57 <jonasschnelli> I think it's not an urgent thing,.. but it may fraighten off users since it can cause a finder crash
19:13:57 * luke-jr shrugs
19:14:23 <cfields> jonasschnelli: now this is interesting!
19:14:40 <jonasschnelli> Someone told me Apple is aware...
19:14:53 <cfields> heh, ok
19:15:51 <jonasschnelli> A finder crash smells just really bad and AFAIK there has been some exploitable bugs in that area in the past.
19:16:23 <wumpus> it was funny hwo this is caused by a python unicode versus bytes issue
19:16:51 <jonasschnelli> Indeed!
19:17:15 <jonasschnelli> I just don't get why it was a non-issue when compiling with trusty.. I though we had the same python version.
19:17:19 <jonasschnelli> *thought
19:17:41 <jonasschnelli> however,.. lets just do a 0.17.0.1 macOS asap
19:18:27 <wumpus> it's great that you managed to isolate it
19:18:39 <jonasschnelli> Took me around 30 gitian builds. :)
19:19:35 <cfields> yes, thanks for that. I always check that dmgs open before tagging the detached sigs, but I've stayed on 10.11 to catch back-compat issues, so I guess I avoided it :\
19:20:25 <jonasschnelli> Yes. I also take it on me,... I haven't done that. But non of us somehow did test the DMG during all the RCs...
19:20:27 <jonasschnelli> which is a bit strange
19:20:52 <sipa> that's a bad sign
19:21:44 <wumpus> not many people testing on macosx?
19:21:48 <cfields> indeed. Maybe we could start adding "Tested ACKs" for the gitian sigs PRs
19:22:03 <cfields> to at least verify that someone has started up the release
19:22:26 <wumpus> I can only test the linux release myself
19:22:46 <wumpus> (and I test compiles on FreeBSD and OpenBSD! but that's irrelevant to gitian)
19:22:51 <jonasschnelli> At least fanquake, sjors and other gitian builders use macOS regularly... including myself. But meh,.. I don't know why I haven't detected it
19:23:03 <luke-jr> testing RCs is IMO the job of users, not builders or coders
19:23:13 <jonasschnelli> Both I'd say
19:23:13 <booyah> I can get you mac os X (old macbook) or bsd  test (install+run) if you want
19:23:56 <cfields> I'll at least start ACKing the platforms that I've verified startup for the sake of posterity.
19:24:02 <sipa> luke-jr: agree, but no reason why someone can't be both - and regardless of what you call them, not enough people testing rcs is concerning
19:24:38 <luke-jr> sipa: right, my point is that PRs isn't a good place for it
19:24:47 <luke-jr> users don't make PRs
19:25:07 <sipa> that's reasonable... though how else do you get feedback?
19:26:37 <luke-jr> short of writing a website that collects it, and asking with the RC announcement to post there.. coming up blank
19:26:53 <wumpus> usually we ask people to open issues on github for problems
19:26:54 <luke-jr> maybe bitcointalk can offer a forum specifically for testing reports or something
19:26:58 <wumpus> I'm nto sure a different website is needed
19:27:02 <luke-jr> true
19:27:09 <luke-jr> what's missing is *positive* feedback
19:27:10 <wumpus> reddit etc have too much noise
19:27:15 <wumpus> yes, true
19:27:47 <luke-jr> and apparently the users testing to give it
19:29:38 <luke-jr> maybe the -core-dev ML needs to get more attention from users so they learn about and try RCs?
19:30:30 <wumpus> I.. dont' think you can really get users into a ML these days
19:30:39 <sipa> haha
19:30:45 <luke-jr> how do users learn about stuff now?
19:30:53 <sipa> maybe we need a facebook group  *ducks*
19:30:56 <luke-jr> >_<
19:31:16 <wumpus> :-)
19:31:17 <cfields> luke-jr: real answer: software force-updates itself.
19:31:28 <cfields> :(
19:31:29 <wumpus> twitter is really popular yes
19:31:42 <luke-jr> how about I make a Twitter account for posting experimental releases of Core, Knots, and other reputable Bitcoin projects? (Electrum, etc?)
19:32:21 <luke-jr> or is there some kind of shared Twitter account thing so more than just I can post?
19:33:02 <luke-jr> cfields: not to testing versions..
19:33:03 <sipa> we can tweet from the bitcoincoreorg account
19:33:17 <luke-jr> sipa: not everyone wants to see experimental releases
19:34:54 <aj> luke-jr: could have a flag to say "auto update to current release version" and another to say "follow experimental release candidate stream"
19:35:47 <achow101> no auto update pls
19:35:50 <warren> luke-jr: have a different twitter account for those interested in following RC's
19:36:06 <luke-jr> warren: that's what I said :P
19:36:07 <wumpus> right, at least at the moemnt we don't tweet experimental releases from bitcoincore twitter
19:36:16 <sipa> yeah
19:36:24 <wumpus> I don't even post them to my personal account ,maybe I should
19:36:42 <luke-jr> wumpus: that might be enough
19:36:51 <warren> Thought you migrated permanently from Twitter. =)
19:37:20 <luke-jr> XD
19:37:32 <sipa> remind me, i can tweet from my personal account too
19:38:15 <wumpus> warren: well I'm more comfortable posting development-related stuff on mastodon, but for noticifcations to reach as many people as possible I'd certainly use twitter
19:38:25 <warren> (What is the protocol for topic proposals? wait until this topic is done?)
19:38:33 <wumpus> warren: no, just propose
19:38:57 <wumpus> ideally you propose topic subjects at the beginning of the meeting
19:39:06 <wumpus> then we can cycle through them
19:39:12 <wumpus> but it's fine we're done with this now
19:39:36 <sipa> i wanted to bring up the linter issues
19:40:37 <warren> topic proposal: Interested in opinions regarding the risk of bringing back Fortuna. Along with deprecation of BIP70, we are on the path toward eventual removal of the openssl dependency.
19:41:23 <sipa> we really don't need fortuna or a high-performance built-in randomness pool - we don't need randomness frequently
19:41:38 <sipa> what we do need is a good way to seed entropy from the environment
19:41:43 <rex4539> I think it is quite unlikely that "normal" people will ever run an RC because they are afraid of losing funds because of bugs. Others like me, on the other hand, only run beta software. If something is "stable" I don't want it. I want experimental, unstable software full of bugs. More fun. I believe the reason for missing the DMG bug is that everyone here is building from master and doesn't actually run the public builds.
19:41:43 <rex4539> Perhaps there should be a pre-release QA checklist for basic functionality on all supported platforms.
19:42:00 <wumpus> #topic Fortuna
19:42:18 <wumpus> —or other randomness
19:42:20 <warren> well, Fortuna or the lesser goal of seeding entropy from the environment
19:42:20 <sipa> and seeding entropy from the environment is annoying as it's a platform specific business
19:42:39 <sipa> but we have a built-in randomness pool now - it's not fast, but it's more than good enough for what we need
19:42:50 <sipa> it's just seeding through OpenSSL mostly
19:43:07 <warren> I am encouraged that #14451 happened, deprecating BIP70 (huge attack surface, nobody uses it etc.) This means we will eventually be able to remove the openssl dependency. Except for that part.
19:43:09 <gribble> https://github.com/bitcoin/bitcoin/issues/14451 | Add BIP70 deprecation warning and allow building GUI without BIP70 support by jameshilliard · Pull Request #14451 · bitcoin/bitcoin · GitHub
19:43:38 <sipa> and whenever we need "strong randomness" we mix data from openssl and our own pool
19:44:50 <sipa> i think it's sufficient to have a c++ file with a bunch of entropy gathering things in it, without turning it into a C API or whatever
19:45:39 <jonasschnelli> #10299
19:45:41 <gribble> https://github.com/bitcoin/bitcoin/issues/10299 | Remove OpenSSL by sipa · Pull Request #10299 · bitcoin/bitcoin · GitHub
19:45:48 <cfields> sipa: you mean something that is essentially a standalone lib, but with no effort made to actually give it an external api?
19:46:17 <warren> #5885 had a previous attempt to replace the openssl PRNG. Reading those old comments remains interesting today.
19:46:20 <gribble> https://github.com/bitcoin/bitcoin/issues/5885 | [WIP] Replace OpenSSL PRNG with built-in Fortuna implementation by sipa · Pull Request #5885 · bitcoin/bitcoin · GitHub
19:46:32 <sipa> warren: nah, i think that's total overkill now
19:47:18 <jonasschnelli> Just read /dev/urandom? *duck*
19:47:23 <warren> external API is risky as you need to worry about about fork safety and conditions you can't predict
19:47:40 <gmaxwell> jonasschnelli: and then not get randomness when FD exhaustion means you can't open it.
19:47:43 <sipa> jonasschnelli: we already do that
19:48:00 <sipa> warren: not if it just gathers some entropy from the environment (and not a full RNG library)
19:48:19 <warren> Do we already use the newer syscall that blocks if the kernel prng is not seeded?
19:48:24 <sipa> yes
19:48:40 <kanzure> how do the proofs of randomness/entropy incorporation work
19:48:40 <jonasschnelli> gmaxwell: don't we just need a single seed during startup then ChaCha20 PRNG from. there? But i'm not familiar with the details..
19:48:43 <wumpus> yes we use the syscall where available
19:48:46 <warren> I know a lot less about the other Unixes.
19:48:50 <wumpus> on Linux and various BSDs
19:48:59 <sipa> jonasschnelli: no, that's FastRandomContext
19:49:14 <sipa> and it's only used to generate randomness that doesn't need independently seeding
19:49:22 <jonasschnelli> I see
19:49:36 <gmaxwell> jonasschnelli: only if everything works right, users never use virtual machines with snapshooting, and we don't care about being totally broken in the face of OS bugs like netbsd and freebsd had in the last couple years.
19:49:41 <sipa> for generating private keys etc, we gather new entropy every time
19:50:05 <warren> ----> <sipa> i think it's sufficient to have a c++ file with a bunch of entropy gathering things in it, without turning it into a C API or whatever <--- This would be good enough and people would feel it is worth the risk of change to be able to eventually remove the openssl dependency?
19:50:10 <gmaxwell> (and don't mind a later process memory leak potentially revealing the keys we previously generated, etc)
19:51:23 <gmaxwell> Until BIP70 is gone we're stuck with openssl regardless. we lost urgency on discontinuing using openssl as a randomness input after bitpay started requiring BIP70 to make payments.
19:51:40 <gmaxwell> So long as we have openssl for other things it's a harmless addition to random inputs.
19:52:10 <cfields> gmaxwell: IIRC that's only supported in -qt
19:52:45 <sipa> ah, for "non-strong" randomness (GetRandBytes, as opposed to GetStrongRandBytes) we use just OpenSSL, would people be ok with switching that to our own randomness pool?
19:53:04 <gmaxwell> we do? well that should be switched.
19:53:10 <jonasschnelli> Agree
19:53:43 <sipa> GetStrongRand uses all sources available, and mixes them into our own pool
19:53:47 <sipa> including OpenSSL
19:55:55 <wumpus> yes
19:56:45 <wumpus> switching over non-strong randomness is a no-brainer
19:57:15 <jarthur> topic proposal: Unix socket support for RPC API
19:57:48 <wumpus> eh <3 minutes left
19:57:57 <jarthur> No prob. Next time.
19:58:06 <wumpus> I agree though
19:58:09 <wumpus> FWIW
19:58:38 <wumpus> need that yesterday!
19:58:51 <aj> missed out on the linter stuff?
19:59:16 <sipa> guess we'll do that another time
19:59:22 <sipa> or hope it resolves itself
19:59:36 <wumpus> linters are great fun for the whole family, you can watch them fail in real time in so many different ways
20:00:27 <wumpus> #endmeeting