19:00:30 <wumpus> #startmeeting
19:00:30 <lightningbot> Meeting started Thu Sep  6 19:00:30 2018 UTC.  The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:00:30 <lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
19:00:39 <gmaxwell> Hi
19:00:57 <achow101> hi
19:01:00 <jonasschnelli> hi
19:01:08 <wumpus> #bitcoin-core-dev Meeting: wumpus sipa gmaxwell jonasschnelli morcos luke-jr btcdrak sdaftuar jtimon cfields petertodd kanzure bluematt instagibbs phantomcircu
19:01:11 <wumpus> it codeshark michagogo marcofalke paveljanik NicolasDorier jl2012 achow101 meshcollider jnewbery maaku fanquake promag provoostenator
19:01:42 <wumpus> PSA: v0.17.0rc3 has been tagged
19:01:56 <wumpus> topics?
19:02:00 <sipa> \o/
19:02:44 <meshcollider> hi
19:03:03 <gmaxwell> Seems things have been kind of quiet.
19:03:21 <wumpus> yes, quiet week
19:03:55 <provoostenator> hi
19:04:00 <jnewbery> hi
19:04:08 <gmaxwell> phantomcircuit (your ping got cut, perhaps you'd like to talk about your poll() work, if you're around)
19:04:08 <Chris_Stewart_5> Thoughts on merging #12775 ? Do we want it enabled in .travis.yml by default?
19:04:11 <gribble> https://github.com/bitcoin/bitcoin/issues/12775 | Integration of property based testing into Bitcoin Core by Christewart · Pull Request #12775 · bitcoin/bitcoin · GitHub
19:04:29 <wumpus> Chris_Stewart_5: yeah that one should be merged...
19:04:40 <phantomcircuit> Hello
19:04:44 <Chris_Stewart_5> sorry, RAPIDCHECK=1 in DEP_OPTS
19:05:19 <wumpus> Chris_Stewart_5: and it makes sense to have it enabled for at least one travis build if it's merged, after all, otherwise it'll probably get under-tested
19:05:31 <phantomcircuit> i'm working on implementing poll on *nix systems, the first step is to cleanup ThreadSocketHandler to separate the select() logic from the rest of the logic
19:05:41 <wumpus> oh topic
19:05:50 <wumpus> #topic poll() (phantoncircuit)
19:06:02 <Chris_Stewart_5> wumpus: I'll try to take care of that in the next 2 days
19:06:18 <phantomcircuit> i've started that in #14147 (which is as far as im going to go in that particular pr)
19:06:19 <gribble> https://github.com/bitcoin/bitcoin/issues/14147 | net: Refactor ThreadSocketHandler by pstratem · Pull Request #14147 · bitcoin/bitcoin · GitHub
19:06:19 <wumpus> Chris_Stewart_5: I mean it'd be perfectly valid to say you don't want to hold up this PR for that, and do it later
19:06:25 <wumpus> Chris_Stewart_5: just be clear :)
19:07:00 <phantomcircuit> next step after that is going to be to separate the socket handling logic from the select() logic
19:07:03 <wumpus> phantomcircuit: good
19:07:11 <gmaxwell> phantomcircuit: my understanding is that your refactors are driven by a more complete set of commits that go all the way to actually enabling poll, you just haven't PRed the ret, right?
19:07:28 <phantomcircuit> gmaxwell, right
19:08:21 <wumpus> so enabling poll turns out to be more work than was expected, I was told at some point it'd basically be a five-line patch, or is this because you want to do it properly? :)
19:09:08 <sipa> it seems we're pretty close on track for the 0.17 release schedule
19:09:11 <gmaxwell> he's doing it more properly.
19:10:17 <gmaxwell> ISTM at least the current PR is a perfectly fine change even considered independantly of poll().
19:10:29 <phantomcircuit> doing it more property, there's a smaller patchset possible but that does things like iterate over every fd for every cnode looking for it's own fd
19:10:46 <phantomcircuit> which is O(n^2) worst case for n = vNodes.size()
19:10:53 <phantomcircuit> so probably dont want to do that
19:10:58 <wumpus> ok, yes, that would be good to avoid, we don't want to worsen performance
19:11:21 <wumpus> right, thanks for the explanation, it's common for people to underestimate how much work something is anyhow :)
19:11:52 <gmaxwell> I think I made the 5 line comment before, but it was based on an actual ~5 line patch that matt was previously using. :P
19:12:07 <phantomcircuit> and indeed the current patchset is specifically selected to make sense even without poll() (but that's certainly why im doing it)
19:13:37 <wumpus> should we add 14147 to high priority for review? I suppose it's blocking further work for you
19:13:42 <phantomcircuit> poll() works more like epoll than select, specifically there's no equivalent for FD_ISSET, so either you need to keep some sort of mapping or iterate over them
19:14:11 <phantomcircuit> i believe matts patchset just iterated which is trivial but certainly not what we want to do
19:14:25 <wumpus> indeed
19:14:35 <wumpus> it was just aproof of concept then
19:14:36 <sipa> makes sense
19:14:44 <phantomcircuit> wumpus, im building off that pr for the rest of the poll() logic assuming it'll eventually be fine
19:15:14 <phantomcircuit> there's 7 commits to that pr and 100 loc changed but mostly that's just moving things
19:15:18 <BlueMatt> I mean iterating is essentially fine, really
19:15:18 <gmaxwell> It's a nearly trivial review in any case. It's just moving things around.
19:15:27 <BlueMatt> its not like we're handling 10k connections
19:15:36 <gmaxwell> ?w=1 eliminates 90% of the diff. :)
19:15:40 <BlueMatt> (and less error-prone than tracking things with CNodes)
19:15:48 <BlueMatt> cause we've had errors in the past with CNode deletion ordering....
19:15:57 <BlueMatt> or, if not errors, shitloads of complication that made review hard
19:16:32 <gmaxwell> I agree that iterating is fine for a few hundred connections, but I think we'd prefer to avoid it unless we really do get mired in review.
19:16:38 <wumpus> anyhow, let's review phantomcircuit 's work
19:16:44 <BlueMatt> wumpus: yea, fair
19:16:47 <wumpus> I don't see the point of discussing this now
19:16:52 <BlueMatt> yep
19:17:39 <wumpus> if it's really so hard to review (there's nothing what people have said that would suggest that) then of course we can look for another solution
19:17:46 <wumpus> any other topics?
19:17:48 <gmaxwell> +1
19:18:23 <gmaxwell> sipa: wumpus: Where did we ever land in replacing the openssl RNG?
19:18:35 <wumpus> #topic replacing the openssl RNG
19:18:44 <wumpus> good question, I think that kind of stranded at some point
19:18:47 <sipa> gmaxwell: i don't feel like spending much work on it
19:18:54 <gmaxwell> It would be nice if we could finally be rid of the dependency in 0.18.
19:19:08 <sipa> but we should probably write some requirements for what it needs to be replaced with
19:19:10 <wumpus> ok so someone would need to pick up sipa 's old work probably
19:19:43 <gmaxwell> I think in part because we reasonably wanted to break some of it off into a library, and then that sounded like too much work. :)
19:19:56 <sipa> yes
19:20:00 <meshcollider> Is there an old PR or something
19:20:03 <wumpus> I don't care about that part anymore
19:20:21 <meshcollider> Or a gist
19:20:27 <moneyball> suggested topic: Tokyo CoreDev topic ideas
19:20:32 <gmaxwell> I'd be happy to do something, but I also really don't feel like making a library right now. (or rather, I'd prefer to spend that time working on something else)
19:20:36 <wumpus> just put it in its own subdirectory under src, someone that wants it as library can do the work for that
19:21:07 <wumpus> if not, there's no need to do build system work etc
19:21:09 <provoostenator> meshcollider: #10299
19:21:11 <gribble> https://github.com/bitcoin/bitcoin/issues/10299 | Remove OpenSSL by sipa · Pull Request #10299 · bitcoin/bitcoin · GitHub
19:21:21 <meshcollider> provoostenator: thanks
19:21:30 <gmaxwell> (in particular, librarizing it is hard because a library ought to be reentrant and probably C callable ... which are things that don't matter much for our own use)
19:21:38 <wumpus> I know all too well how frustrating making libraries for c++ is
19:21:57 <luke-jr> why would it be C++?
19:22:02 <wumpus> lol...
19:22:06 <provoostenator> CoreDev topic ideas: hardware wallet support, faster wallet bootstrap (i.e. sync in background)
19:22:17 <wumpus> yesl et's start piling up other requirements as well
19:22:20 <wumpus> ok, another topic?
19:22:28 <gmaxwell> luke-jr: So one of the things we could do for it would be rewrite in C, but thats something that people don't feel like doing.
19:22:29 <provoostenator> Probably continue the coin selection fun?
19:22:42 <wumpus> let's rewrite it in rust !
19:23:01 <moneyball> wumpus suggested topic: Tokyo CoreDev topic ideas
19:23:14 <kanzure> hi.
19:23:20 <wumpus> #topic Tokyo CoreDev topic ideas (provoostenator)
19:23:23 <sipa> CoreDev topics: descriptors and extensions to them
19:23:36 <kanzure> already on there
19:23:39 <jtimon> rust all your problems
19:23:47 <kanzure> what would you guys like to hjear from other people, and/or from yourselves
19:23:53 <moneyball> kanzure has reached out to some folks, and i plan to as well to solicit topic ideas. also feel free to share them here as you are already doing :)
19:23:55 <wumpus> jtimon: I have C/C++ burnout
19:24:22 <kanzure> oh no that's terminal
19:24:38 <jtimon> wumpus: well, you write python too :p
19:24:47 <wumpus> jtimon: python is still somewhat cute
19:25:01 * jonasschnelli can't be in Tokyo :/
19:25:11 <achow101> kanzure: moneyball: what are the current topics, if any?
19:25:21 <gmaxwell> I'd like to see kallewoof's progress on input grouping get done.
19:25:23 <sipa> wumpus: thankfully carbon doesn't rust
19:25:37 <wumpus> sipa: heh!
19:26:25 <kanzure> achow101: PSBT, hardware wallet stuff, output descriptors, input grouping, schnorr signatures BIP stuff, forward blocks, client-side filtering, lattice-based digital signatures, coin selection, #13869
19:26:26 <gribble> https://github.com/bitcoin/bitcoin/issues/13869 | Filename and command line encoding issue on Windows · Issue #13869 · bitcoin/bitcoin · GitHub
19:26:36 <gmaxwell> Maybe people could think about rhavar's bustapay... I think it might be reasonable to support it in the bitcoin core wallet.
19:26:52 <gmaxwell> lattice-based digital signatures?!?!
19:26:53 <kanzure> who would be a good candidate to fly the flag of bustapay
19:27:04 <kanzure> gmaxwell: it's a meshcollider thing
19:27:17 <moneyball> here is what kanzure has collected so far, from about 10 people:
19:27:17 <moneyball> * partially signed bitcoin transactions
19:27:17 <moneyball> * hardware wallet support
19:27:17 <moneyball> * script validation
19:27:17 <moneyball> * input grouping
19:27:17 <moneyball> * output descriptors
19:27:17 <moneyball> * Schnorr signatures BIP
19:27:18 <moneyball> * k-of-n threshold signatures using Schnorr
19:27:18 <moneyball> * forward blocks
19:27:19 <moneyball> * hardware wallet support in Bitcoin Core
19:27:19 <moneyball> * status of client-side filtering and neutrino
19:27:20 <moneyball> * client side filtering
19:27:40 <sipa> please don't paste long lists in IRC
19:27:50 <meshcollider> Heh I don't think it's worth discussing lattice sigs at CoreDev
19:27:50 <moneyball> oh, sorry
19:27:57 <meshcollider> That's just what I'm working on
19:28:00 <achow101> kanzure: re bustapay, me? I was part of the meeting that came up with the basis for that
19:28:04 <kanzure> okay it is you
19:28:21 <kanzure> done
19:29:00 <jnewbery> maybe offtopic for now, but how is bustapay different from p2ep?
19:29:02 <wumpus> nah pasting 12 lines which are relevant topics isn't that bad, but yes, never do that with error messages / logs pelase :)
19:29:13 <BlueMatt> "forward blocks"
19:29:15 <BlueMatt> ?
19:29:20 <instagibbs> BlueMatt, maaku's thing
19:29:22 <instagibbs> IIRC
19:29:30 <kanzure> BlueMatt: time travel exploit
19:29:46 <achow101> jnewbery: it's basically the same thing, but actually implemented
19:30:02 <gmaxwell> jnewbery: actually implementable and not woo.
19:30:26 <kanzure> moneyball and i will be heckling each of you for more topic suggestions soon, thanks for the input
19:30:28 <achow101> it cuts out some of the complexity as a tradeoff for a possible and very small (IMO) privacy risk
19:30:48 <BlueMatt> ah, right, the exploit-timeward-to-change-blocktime-and-fork-to-lock-it-in thing....I feel like thats something that needs more broad bitcoin-dev or whatever discussion, its not something to be discussed a technical planning meeting
19:30:50 <wumpus> do you need even more topics? seems a decent list
19:31:07 <kanzure> this list is tiny compared to last few times; it'll grow.
19:31:07 <BlueMatt> dandelion, depending on who's there, should be discussed
19:31:08 <wumpus> none trivial
19:31:13 <jtimon> kallewoof: has been working on a "signet" branch I'm currently reviewing and testing that allows the creation of signed blocks testchains ala elements, not sure if that could be a topic, but I would be very happy to see something like that get into master at some point
19:31:14 <instagibbs> BlueMatt, ACK
19:31:29 <sipa> agree with BlueMatt as well
19:31:50 <kanzure> jtimon: added
19:31:52 <kanzure> BlueMatt: added
19:31:55 <gmaxwell> agree with BlueMatt as well
19:32:03 <BlueMatt> agree with BlueMatt as well
19:32:06 <BlueMatt> wait, hmmm
19:32:15 <kanzure> don't do that you'll break the universe
19:32:42 <sipa> try typing 'google' into google
19:33:18 <michagogo> Or ‘recursion’
19:33:20 <BlueMatt> Did you mean recursion?
19:33:32 <sipa> BlueMatt: it was an it crowd joke
19:33:56 <provoostenator> Something that might be worth putting in the meeting minutes: multiple PR's are suffering from 500 server error for multiple days. Apparantly Github is aware of the problem.
19:34:15 * BlueMatt emailed support and got back a "we're looking into it, its visible on a few projects"
19:34:31 <achow101> do we have so many PRs and issues that we broke github?
19:34:39 <wumpus> github is falling apart, so soon after ms took it over
19:34:54 <sipa> nah, it was falling apart before
19:34:57 <wumpus> I think they switched the server hosting to windows 95
19:35:05 <sipa> haha
19:35:38 <wumpus> if it helps I'll send a mail too
19:35:38 <luke-jr> at least not ME
19:35:50 <wumpus> haah then it would alrady be gone
19:35:57 <kanzure> other topics?
19:36:10 <gmaxwell> WinCE.
19:36:20 <michagogo> How did everyone get a bionic gitian environment working?
19:36:28 <meshcollider> MS haven't actually taken over yet have they
19:36:32 <luke-jr> michagogo: I ended up installing from the iso by hand
19:36:36 <sipa> https://i.imgur.com/zh4F55R.png
19:36:40 <wumpus> deep magic voodoo rituals
19:36:44 <luke-jr> michagogo: and patching gitian to work with it
19:36:52 <wumpus> #topic gitian build on bionic
19:36:58 <meshcollider> sipa: lol
19:37:07 <provoostenator> Works
19:37:10 <wumpus> with LXC it's easy, just the standard steps
19:37:32 <achow101> both lxc and docker work
19:37:50 <achow101> but according to luke-jr kvm is broken again as apparently the new vmbuilder doesn't work?
19:37:58 <achow101> (I haven't tried yet)
19:38:02 <michagogo> wumpus: make-base-vm —lxc —suite bionic seemed to work for me (finished without error), but the result seems broken
19:38:17 <jonasschnelli> define "broken"?
19:38:30 <luke-jr> michagogo: latest gitian?
19:38:36 <michagogo> Yep
19:38:42 <michagogo> (On a xenial host)
19:39:21 <wumpus> these additional steps are what I had to do for gitian building on debian 9.5 with LXC: https://gist.github.com/laanwj/c62e101bfd68718f0686926dfd10666b
19:40:22 <wumpus> (e.g. I needed a new lxc version, as well as a new version of debootstrap as it was lacking the bionic script)
19:41:07 <wumpus> if it built the image then I think that part went right, but you might have an too-old version of LXC that cannot handle bionic
19:41:31 <wumpus> I don't remember what the minimum version is that works, jonasschnelli might
19:41:40 * jonasschnelli looking
19:42:04 <jonasschnelli> stable-2.1
19:42:19 <wumpus> yea 2.1.5 or something?
19:42:32 * luke-jr wonders why bionic needs special LXC support
19:43:02 <jonasschnelli> I think its 2.1.1
19:43:15 <jonasschnelli> jup. 2.1.1. is min
19:43:24 <wumpus> thanks!
19:44:21 <achow101> you need at least 2.1.x
19:44:47 <wumpus> michagogo: which lxc version did you try with?
19:46:22 <michagogo> wumpus: whatever’s in xenial-updates
19:46:42 <achow101> michagogo: do `lxc-start --version`
19:49:29 <promag> hi :|
19:50:44 <wumpus> Package: lxc1 (2.0.8-0ubuntu1~16.04.2)
19:50:48 <wumpus> so, too old.
19:50:56 <wumpus> promag: hi
19:51:28 <wumpus> other topics?
19:52:31 <wumpus> #endmeeting