19:02:03 #startmeeting 19:02:03 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 Useful Commands: #action #agreed #help #info #idea #link #topic. 19:02:09 howdy 19:02:15 hi 19:02:34 hi 19:02:49 hey 19:03:33 Hi 19:03:33 #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 hi 19:03:48 .. 19:03:59 \o 19:05:04 topics?\ 19:05:37 topic proposal: 0.17.0.1 or 0.17.1 19:05:39 what is the status with the linter issues on travis? 19:06:07 hello 19:06:59 #topic 0.17.0.1 or 0.17.1 19:07:34 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 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 #14416 19:09:06 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 The current DMG provided in bitcoincore.org/bin does not open on macOS 19:09:34 agree, would make sense to make a 0.17.0.1 for macosx only 19:09:43 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 We can also directly move to 0.17.1,... 19:10:23 that seems in line with versioning we've used before, using the 4th number for platform specific fixes 19:10:25 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 sipa: sure, I'm just saying we can tag it on 0.17 branch 19:11:02 some of those may be nontrivial; i saw some issue with his backports PR having a merge conflict? 19:11:03 luke-jr: that would mean that Mac users couldn't drop back to 0.17 if 0.17.1 was buggy. 19:11:09 +1 for 0.17.0.1 19:11:16 cfields: 0.17.1 should only be fixes on top of 0.17.0 anyway 19:11:39 sipa: yep 19:12:52 we could pick the simple backport fixes (including macos fix) and let the remaining for 0.17.2? 19:12:59 I dont' think we have enough for 0.17.1 yet 19:13:13 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 like, tomorrow 19:13:36 agree 19:13:41 ack 19:13:50 sgtm 19:13:57 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 jonasschnelli: now this is interesting! 19:14:40 Someone told me Apple is aware... 19:14:53 heh, ok 19:15:51 A finder crash smells just really bad and AFAIK there has been some exploitable bugs in that area in the past. 19:16:23 it was funny hwo this is caused by a python unicode versus bytes issue 19:16:51 Indeed! 19:17:15 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 *thought 19:17:41 however,.. lets just do a 0.17.0.1 macOS asap 19:18:27 it's great that you managed to isolate it 19:18:39 Took me around 30 gitian builds. :) 19:19:35 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 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 which is a bit strange 19:20:52 that's a bad sign 19:21:44 not many people testing on macosx? 19:21:48 indeed. Maybe we could start adding "Tested ACKs" for the gitian sigs PRs 19:22:03 to at least verify that someone has started up the release 19:22:26 I can only test the linux release myself 19:22:46 (and I test compiles on FreeBSD and OpenBSD! but that's irrelevant to gitian) 19:22:51 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 testing RCs is IMO the job of users, not builders or coders 19:23:13 Both I'd say 19:23:13 I can get you mac os X (old macbook) or bsd test (install+run) if you want 19:23:56 I'll at least start ACKing the platforms that I've verified startup for the sake of posterity. 19:24:02 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 sipa: right, my point is that PRs isn't a good place for it 19:24:47 users don't make PRs 19:25:07 that's reasonable... though how else do you get feedback? 19:26:37 short of writing a website that collects it, and asking with the RC announcement to post there.. coming up blank 19:26:53 usually we ask people to open issues on github for problems 19:26:54 maybe bitcointalk can offer a forum specifically for testing reports or something 19:26:58 I'm nto sure a different website is needed 19:27:02 true 19:27:09 what's missing is *positive* feedback 19:27:10 reddit etc have too much noise 19:27:15 yes, true 19:27:47 and apparently the users testing to give it 19:29:38 maybe the -core-dev ML needs to get more attention from users so they learn about and try RCs? 19:30:30 I.. dont' think you can really get users into a ML these days 19:30:39 haha 19:30:45 how do users learn about stuff now? 19:30:53 maybe we need a facebook group *ducks* 19:30:56 >_< 19:31:16 :-) 19:31:17 luke-jr: real answer: software force-updates itself. 19:31:28 :( 19:31:29 twitter is really popular yes 19:31:42 how about I make a Twitter account for posting experimental releases of Core, Knots, and other reputable Bitcoin projects? (Electrum, etc?) 19:32:21 or is there some kind of shared Twitter account thing so more than just I can post? 19:33:02 cfields: not to testing versions.. 19:33:03 we can tweet from the bitcoincoreorg account 19:33:17 sipa: not everyone wants to see experimental releases 19:34:54 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 no auto update pls 19:35:50 luke-jr: have a different twitter account for those interested in following RC's 19:36:06 warren: that's what I said :P 19:36:07 right, at least at the moemnt we don't tweet experimental releases from bitcoincore twitter 19:36:16 yeah 19:36:24 I don't even post them to my personal account ,maybe I should 19:36:42 wumpus: that might be enough 19:36:51 Thought you migrated permanently from Twitter. =) 19:37:20 XD 19:37:32 remind me, i can tweet from my personal account too 19:38:15 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 (What is the protocol for topic proposals? wait until this topic is done?) 19:38:33 warren: no, just propose 19:38:57 ideally you propose topic subjects at the beginning of the meeting 19:39:06 then we can cycle through them 19:39:12 but it's fine we're done with this now 19:39:36 i wanted to bring up the linter issues 19:40:37 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 we really don't need fortuna or a high-performance built-in randomness pool - we don't need randomness frequently 19:41:38 what we do need is a good way to seed entropy from the environment 19:41:43 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 Perhaps there should be a pre-release QA checklist for basic functionality on all supported platforms. 19:42:00 #topic Fortuna 19:42:18 —or other randomness 19:42:20 well, Fortuna or the lesser goal of seeding entropy from the environment 19:42:20 and seeding entropy from the environment is annoying as it's a platform specific business 19:42:39 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 it's just seeding through OpenSSL mostly 19:43:07 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 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 and whenever we need "strong randomness" we mix data from openssl and our own pool 19:44:50 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 #10299 19:45:41 https://github.com/bitcoin/bitcoin/issues/10299 | Remove OpenSSL by sipa · Pull Request #10299 · bitcoin/bitcoin · GitHub 19:45:48 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 #5885 had a previous attempt to replace the openssl PRNG. Reading those old comments remains interesting today. 19:46:20 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 warren: nah, i think that's total overkill now 19:47:18 Just read /dev/urandom? *duck* 19:47:23 external API is risky as you need to worry about about fork safety and conditions you can't predict 19:47:40 jonasschnelli: and then not get randomness when FD exhaustion means you can't open it. 19:47:43 jonasschnelli: we already do that 19:48:00 warren: not if it just gathers some entropy from the environment (and not a full RNG library) 19:48:19 Do we already use the newer syscall that blocks if the kernel prng is not seeded? 19:48:24 yes 19:48:40 how do the proofs of randomness/entropy incorporation work 19:48:40 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 yes we use the syscall where available 19:48:46 I know a lot less about the other Unixes. 19:48:50 on Linux and various BSDs 19:48:59 jonasschnelli: no, that's FastRandomContext 19:49:14 and it's only used to generate randomness that doesn't need independently seeding 19:49:22 I see 19:49:36 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 for generating private keys etc, we gather new entropy every time 19:50:05 ----> 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 (and don't mind a later process memory leak potentially revealing the keys we previously generated, etc) 19:51:23 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 So long as we have openssl for other things it's a harmless addition to random inputs. 19:52:10 gmaxwell: IIRC that's only supported in -qt 19:52:45 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 we do? well that should be switched. 19:53:10 Agree 19:53:43 GetStrongRand uses all sources available, and mixes them into our own pool 19:53:47 including OpenSSL 19:55:55 yes 19:56:45 switching over non-strong randomness is a no-brainer 19:57:15 topic proposal: Unix socket support for RPC API 19:57:48 eh <3 minutes left 19:57:57 No prob. Next time. 19:58:06 I agree though 19:58:09 FWIW 19:58:38 need that yesterday! 19:58:51 missed out on the linter stuff? 19:59:16 guess we'll do that another time 19:59:22 or hope it resolves itself 19:59:36 linters are great fun for the whole family, you can watch them fail in real time in so many different ways 20:00:27 #endmeeting