19:02:35 <wumpus> #startmeeting
19:02:35 <lightningbot> Meeting started Thu Oct  8 19:02:35 2020 UTC.  The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:02:35 <lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
19:02:37 <jnewbery> hi
19:02:40 <hebasto> hi
19:02:52 <aj> hiiii
19:02:55 <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 ariard digi_james
19:02:57 <wumpus> amiti fjahr jeremyrubin lightlike emilengler jonatack hebasto jb55 elichai2
19:03:04 <meshcollider> hi
19:03:13 <jonatack> ciao
19:03:27 <luke-jr> hi
19:04:15 <wumpus> FWIW: the 0.21 feature freeze is in a week, it probably makes more sense to discuss what is tagged for the 0.21 milestone as high priority for review at this point
19:04:25 <wumpus> this is https://github.com/bitcoin/bitcoin/milestone/45
19:06:05 <sipa> that's a long list
19:06:12 <wumpus> it looks like no other topics have been proposed for this week
19:06:15 <jonasschnelli> How is the merge back of the GUI repository handled? MarcoFalke?
19:06:19 <wumpus> yes, it's also likely outdated
19:06:22 <jonasschnelli> (Regarding freeze)
19:06:37 <wumpus> which makes it good to go over it I suppose
19:06:55 <vasild> hi
19:07:30 <wumpus> and at least two of the issues are simply 'follow release process'
19:07:38 <sipa> i think #19954 is pretty much done
19:07:41 <gribble> https://github.com/bitcoin/bitcoin/issues/19954 | tor: complete the TORv3 implementation by vasild · Pull Request #19954 · bitcoin/bitcoin · GitHub
19:07:56 <wumpus> yes
19:08:08 <hebasto> #18077 and #18710 could be moved to 0.22
19:08:10 <gribble> https://github.com/bitcoin/bitcoin/issues/18077 | net: Add NAT-PMP port forwarding support by hebasto · Pull Request #18077 · bitcoin/bitcoin · GitHub
19:08:13 <gribble> https://github.com/bitcoin/bitcoin/issues/18710 | Add local thread pool to CCheckQueue by hebasto · Pull Request #18710 · bitcoin/bitcoin · GitHub
19:08:28 <wumpus> hebasto: ok, thanks
19:08:38 <aj> #19543 doesn't have an associated PR yet?
19:08:40 <gribble> https://github.com/bitcoin/bitcoin/issues/19543 | Normalize fee units for RPC ("BTC/kB" and "sat/B) · Issue #19543 · bitcoin/bitcoin · GitHub
19:08:42 <nehan> 5
19:09:00 <nehan> (typo)
19:09:04 <jonatack> i've been focusing on #19953 the past day or so as it seems to be the highest priority along with tor v3
19:09:07 <gribble> https://github.com/bitcoin/bitcoin/issues/19953 | Implement BIP 340-342 validation (Schnorr/taproot/tapscript) by sipa · Pull Request #19953 · bitcoin/bitcoin · GitHub
19:09:39 <jonatack> aj: i planned to do #19543 after FF as it's a bugfix
19:09:40 <gribble> https://github.com/bitcoin/bitcoin/issues/19543 | Normalize fee units for RPC ("BTC/kB" and "sat/B) · Issue #19543 · bitcoin/bitcoin · GitHub
19:09:51 <hebasto> two drafts also could be moved?
19:09:53 <sipa> all todos are done for taproot, including the json tests in the qa-assets repo
19:09:59 <wumpus> jonatack: so that one needs 0.21 milestone?
19:10:16 <wumpus> aj: seems like it, but also seems not urgent for 0.21?
19:11:04 <wumpus> aj: oh "This needs to happen before the next major release. Otherwise, it will be a breaking change."
19:11:09 <aj> wumpus: yeah
19:11:12 <wumpus> ping MarcoFalke
19:11:28 <sipa> wumpus: i'd very much like to get taproot in 0.21, as the alternative (i expect) is that we'll want it early in 0.22 anyway, which will just complicate backports
19:11:51 <sipa> (the code, not activation obviously)
19:12:03 <wumpus> hebasto: done
19:12:14 <wumpus> sipa: agree!
19:12:48 <jonatack> +1
19:13:59 <meshcollider> I feel like we should really push for #19077 if possible just to have it in the same version as descriptor wallets like we discussed
19:14:02 <gribble> https://github.com/bitcoin/bitcoin/issues/19077 | wallet: Add sqlite as an alternative wallet database and use it for new descriptor wallets by achow101 · Pull Request #19077 · bitcoin/bitcoin · GitHub
19:14:09 <meshcollider> But it's a big PR
19:14:28 <sipa> i haven't paid attention to the PR itself, but it seems it's been making lots of progress lately, including review
19:14:45 <meshcollider> Yeah it's had a decent amount of review already so it's not infeasible
19:15:05 <sipa> i know wumpus had reservations about having it in 0.21
19:15:24 <wumpus> looks like we're starting to run into issues building bdb 4.8 on some platforms at least: #19411
19:15:26 <gribble> https://github.com/bitcoin/bitcoin/issues/19411 | Unable to build BDB 4.8 on macOS Big Sur beta or Xcode 12.0 · Issue #19411 · bitcoin/bitcoin · GitHub
19:16:01 <wumpus> sipa: yes, it seems fairly risky to introduce a new wallet database format (which is used by default) in something last minute
19:16:03 <sipa> --with-incompatible-bdb lalala
19:16:23 <achow101> wumpus: it's only used by descriptor wallets which we already have marked as "experimental"
19:16:35 <wumpus> achow101: they're not created by default for new users?
19:16:39 <achow101> no
19:16:41 <wumpus> in that case I"m oay with it
19:17:02 <sipa> ah, descriptor wallets are not default for new wallets?
19:17:07 <achow101> not yet
19:17:25 <sipa> that's perhaps the best of both worlds... get descriptor wallets and sqlite in 0.21, but neither is default
19:17:37 <wumpus> if it's opt-in I see no problem
19:18:27 <achow101> if descriptor wallets were the default, a lot of tests would be failing :p
19:20:46 <wumpus> wrt #20005 I'm not convinced we should do anything for it, the particular issue doesn't affect anything in our project and clearly in the longer run it's better left solved upstream
19:20:47 <gribble> https://github.com/bitcoin/bitcoin/issues/20005 | memcmp with constants that contain zero bytes are broken in GCC · Issue #20005 · bitcoin/bitcoin · GitHub
19:21:54 <sipa> agree
19:22:11 <sipa> it's good to continue discussing the options, but i don't think there is urgency
19:22:22 <wumpus> sure, but removing the milestone then
19:22:22 <sipa> we're not using gcc 9 or gcc 10 for releases either, i believe?
19:23:17 <wumpus> no, 8 at most
19:23:41 <hebasto> 7.4 for linux x86_64
19:25:24 <wumpus> yes, correct
19:25:42 <wumpus> otherwise there's agreement what is on the milestone right now?
19:26:48 <sipa> not everything will make it, but sure
19:27:11 <sipa> i'm also hoping for 19988
19:27:23 <sipa> given the amount of review it's had the past days
19:27:58 <jnewbery> I think 19988 is ready. It has three or four recent ACKs now
19:28:22 <meshcollider> #19988
19:28:25 <gribble> https://github.com/bitcoin/bitcoin/issues/19988 | Overhaul transaction request logic by sipa · Pull Request #19988 · bitcoin/bitcoin · GitHub
19:29:03 <sipa> 50% test code :)
19:29:20 <wumpus> added to milestone anyway
19:29:25 <sipa> thanks!
19:30:44 <sipa> unrelated: i've noticed that sometimes clicking "show resolved" on github expands everything, and sometimes not
19:30:57 <sipa> does anyone else have this, or know how it's caused?
19:30:58 <achow101> #16463 could be removed from the milestone I guess
19:31:01 <gribble> https://github.com/bitcoin/bitcoin/issues/16463 | [BIP 174] Implement serialization support for GLOBAL_XPUB field. by achow101 · Pull Request #16463 · bitcoin/bitcoin · GitHub
19:31:31 <wumpus> ok done
19:32:41 <wumpus> any other topics for today?
19:33:03 <jnewbery> I have a question about c++17
19:33:42 <aj> wumpus: you pinged about moving https://github.com/users/ajtowns/projects/1 under bitcoin/ ; happy to, might be nice to move the automation into drahtbot at the same time
19:34:04 <jnewbery> we're planning to move to c++17 (remove c++11 compat) in v0.21: https://github.com/bitcoin/bitcoin/issues/16684
19:34:18 <wumpus> no, in 0.22 right?
19:34:33 <wumpus> 0.21 introduces c++17 compilation by default
19:34:36 <jnewbery> oops sorry, yes v0.22
19:34:47 <wumpus> 0.22 is c++17 only
19:34:49 <wumpus> okay
19:35:04 <jnewbery> so after v0.21 branch we're theoretically free to use c++17 features throughout the codebase
19:35:11 <wumpus> yes
19:35:29 <jnewbery> My question was whether it makes sense to try to keep c++11 compatability for consensus code for longer
19:35:40 <wumpus> for new code definitely, as for c++11, please don't file PRs to convert all old code at once
19:35:49 <wumpus> for the sake of doing so
19:36:09 <wumpus> there's no *need* for any compatibility with c++11 anymore
19:36:12 <jnewbery> ie use c++17 features in net processing/wallet/etc, but try to keep consensus code on c++11 for longer
19:36:59 <jnewbery> given that apparently compilers have bugs it might make sense to be more conservative with upgrading to the latest features in consensus
19:37:06 <wumpus> I think that will make things really complicated, even defining what is 'consensus code' is pretty hard right now
19:37:12 <jnewbery> but it's just a half-baked thought
19:37:41 <jnewbery> wumpus: right. It'd be nice if that separation were clearer
19:37:46 <wumpus> or do you only mean 'what is part of libconsensus'
19:38:01 <wumpus> dongcarl's libbitcoinkernel is a nice idea but it's only an idea right now
19:38:50 <aj> libbitcoinkernel? no hits on google
19:38:51 <wumpus> yes, it'd be nice but definitely not around the corner, I don't think it's in any shape to make C++ version depend on it
19:39:12 <wumpus> agree with regard to bugs though
19:39:16 <sipa> almost all of C++17 is in GCC 7, and all of it is in GCC 8
19:39:18 <wumpus> everything is broken let' go shopping
19:39:50 <sipa> so i'd agree as far as being conservative w.r.t. C++ features in consensus-critical code, but i don't think that's necessarily a new idea
19:39:56 <sipa> we always want to be conservative there
19:40:15 <sipa> i don't think we need a "this subset of the code must remain c++11 compatible" rule
19:40:29 <sipa> whether enforced or not
19:40:44 <wumpus> I really thin kwe should make one decision for the entire codebase
19:40:53 <sipa> agree
19:41:07 <wumpus> if the recent discovery means that new versions of C++ are unsafe, that means, let's just give up on C++17 for now
19:41:17 <sipa> i don't think so
19:41:24 <wumpus> I don't particularly want the P2P code to be unsafe either
19:41:31 <sipa> it's a bug in a C89 feature FFS
19:41:34 <jnewbery> sipa: does it make sense to codify what you mean by 'conservative w.r.t c++ features in consensus-critical code'?
19:42:00 <wumpus> we don't have suffiient separateion of consensus-critical code from anything
19:42:03 <wumpus> we need to have that, sure
19:42:32 <wumpus> but it's more than you'd expect if you include util and compat and other indirect dependencies
19:42:58 <sipa> jnewbery: yeah, i'm trying to think what that would mean
19:43:01 <sipa> it's just a thought
19:43:26 <wumpus> honestly I think this is completely seperate from the c++17 question
19:43:32 <sipa> yes, agree
19:43:36 <wumpus> yes, it would be good to isolate the consensus code
19:43:54 <wumpus> then again this was a project since, 2012 or so...
19:44:25 <wumpus> also: leveldb is part of consensus
19:44:29 <sipa> i think the question for C++17 or not just depends on whether we expect build environments that people will want to use for 0.22 support it sufficiently or not
19:45:00 <wumpus> it's not like you can build the consensus code separately anyway
19:45:16 <sipa> indeed
19:45:38 <sipa> we *could* say that libconsensus needs to remain C++11 buildable - but i don't think there is much of a reason for that
19:46:05 <wumpus> I don't think so either
19:46:33 <wumpus> c++17 is already three years old anyway and most c++ compilers implemented it, or features from it, before that
19:46:46 <wumpus> it's not that we're super fast in adopting new c++ standards
19:46:48 <sipa> so let's discuss this after 0.21 branch off, whether we think requiring a C++17 build environment will be a problem by the time 0.22 gets released
19:47:07 <sipa> indeed
19:47:08 <jnewbery> sipa: +1
19:47:32 <jonatack> to summarize, if I may: before feature freeze in one week, please review 19953 (BIPs 340-342), 19954 (tor v3), 19988 (tx relay logic), and 19077 (sqlite wallet)
19:47:40 <wumpus> seems deviating from our plan here on last minute does need a very good reason though
19:47:52 <jnewbery> I am interested in how we judge 'conservative w.r.t c++ features', but not necessarily now
19:48:33 <sipa> wumpus: yeah
19:48:34 <wumpus> I think we need to be conservative in making changes to the consensus code, not so much specifically regarding c++ features
19:48:39 <aj> jnewbery: i think that was just a subset of "conservative in general"
19:48:54 <wumpus> right
19:49:15 <wumpus> which was also my first reply, don't change code for c++17 for the sake of using c++17
19:49:21 <sipa> and perhaps avoid features that reviewers may not be very familiar with - which is correlated but not the same as recently-introduced language features
19:49:49 <wumpus> any other topics?
19:50:51 <sipa> jonatack: +1
19:52:11 <wumpus> honestly I'd feel a lot better if we had focused on isolating the consensus-critical code a long time ago, seems like something people like to talk about but it never really panned out yet
19:52:30 <sipa> wumpus: it's... hard
19:52:52 <wumpus> sipa: yes :/
19:52:56 <wumpus> jonatack: agree!
19:54:09 <jnewbery> wumpus: we're moving in that direction ... slowly. #20049 and #20050 are next
19:54:09 <wumpus> sipa: it's hard but maybe one of the things remaining that's really worth doing
19:54:10 <gribble> https://github.com/bitcoin/bitcoin/issues/20049 | De-globalizing ChainstateManager · Issue #20049 · bitcoin/bitcoin · GitHub
19:54:12 <gribble> https://github.com/bitcoin/bitcoin/issues/20050 | validation: Prune (in)direct g_chainman usage related to ::LookupBlockIndex (bundle 1) by dongcarl · Pull Request #20050 · bitcoin/bitcoin · GitHub
19:54:50 <wumpus> jnewbery: I guess the main problem is that isolating the consensus code means changes to the consensus code which is a risk in itself so hard to do
19:55:44 <wumpus> jnewbery: but good to know!
19:55:48 <aj> wumpus: also that we want to switch between non-consensus and consensus code efficiently in lots of places
19:56:34 <sipa> yes, and given previous attempts at refactoring out consensus code ended us more than once is a worse half-baked state, it's harder to get reviewer enthousiasm for such changes
19:56:50 <wumpus> aj: yes defining an interface that makes sens in itself but doesn't make things a lot slower is another thing
19:57:03 <dongcarl> Definitely non-zero risks, which is why the focus should be on doing it incrementally, and testing it continuously :-)
19:57:36 <wumpus> definitely more interestedi n it than discussions about the icon color though :-)
19:57:45 <dongcarl> Hehe
19:57:47 <sipa> haha
19:57:50 <jonatack> hehe
19:57:54 <sipa> it is as BIP42 predicted
19:58:09 <sipa> "Prominent among them is the discussion on what to call 1 billion Bitcoin, which symbol color to use for it, and when wallet clients should switch to it by default. "
19:58:33 <wumpus> heh!
19:59:20 <wumpus> #endmeeting