< fanquake> Probably easiest of the release-notes.md in master links to the wiki (as that is quicker and easier to make changes too).
< fanquake> Then the release notes can just be merged back into branches pre a tag/release. Or something like that.
< sipa> i'd actually prefer merging them now
< sipa> there isn't all that much activity on the wiki
< fanquake> Fair enough. I can PR that later today if you'd like.
< fanquake> sipa #14157
< gribble> https://github.com/bitcoin/bitcoin/issues/14157 | [0.17] doc: merge upstream release-notes from bitcoin-core/bitcoin-devwiki by fanquake · Pull Request #14157 · bitcoin/bitcoin · GitHub
< sipa> thanks!
< fanquake> Is download.qt.io down for anyone else?
< fanquake> nvm, must have been an intermittent issue.
< ken2812221> Both #10102 and #13937 are down
< gribble> https://github.com/bitcoin/bitcoin/issues/10102 | HTTP Error 500: Internal Server Error
< gribble> https://github.com/bitcoin/bitcoin/issues/13937 | HTTP Error 500: Internal Server Error
< wumpus> sipa_: before final
< wumpus> sipa: editing release notes should *not* happen in the branch right now, who is doing this?
< wumpus> editing the release notes should happen on the wiki
< wumpus> if anyone is doing something else, point them there
< wumpus> FWIW the wiki is also the 'preliminary release notes' link sent in the rc announcements
< sipa_> wumpus: ok
< wumpus> ok, https://github.com/bitcoin/bitcoin/milestone/33 has only release notes TODOs left, let's tag 0.17.0rc3 ?
< ken2812221> ACK
< wumpus> * [new tag] v0.17.0rc3 -> v0.17.0rc3
< achow101> yay
< provoostenator> ken2812221 they're down for me too. I sent an email to Github yesterday about another one; they're looking into it.
< wumpus> same problem here
< jamesob> anyone know if we have an easy way of testing zeromq PUBs?
< jamesob> i.e. triggering publications for the purpose of testing a client
< wumpus> regtest + zmq block notifications?
< wumpus> (e.g. the same way as the functional test does it)
< jamesob> yeah, that's probably easiest. thanks wumpus
< Chris_Stewart_5> Was there a bug in master recently related to -datadir?
< wumpus> Chris_Stewart_5: not that I know o, what kind of bug?
< Chris_Stewart_5> Ooh, nvm. Seems it might have been related to a systemd config
< wumpus> right
< jonasschnelli> sipa_: a) is the master key fingerprint optional?
< sipa_> jonasschnelli: where?
< jonasschnelli> sipa: in the descriptor. :)
< jonasschnelli> would ... pkh(d34db33f/44'/0'/0':xpub6ERApfZwUNrhLCkDtcHTcxd75RbzS1ed54G1LkBUHQVHQKqhMkhgbmJbZRkrgZw4koxb5JaHWkY4ALHY2grBGRjaDMzQLcgJvLJuZZvRcEL/1/*)
< sipa> that's valid
< jonasschnelli> also work as pkh(xpub6ERApfZwUNrhLCkDtcHTcxd75RbzS1ed54G1LkBUHQVHQKqhMkhgbmJbZRkrgZw4koxb5JaHWkY4ALHY2grBGRjaDMzQLcgJvLJuZZvRcEL/1/*)
< sipa> yes of course
< jonasschnelli> Oh... NM, that is already implemented..
< sipa> it just doesn't have key origin info if you don't specify it
< jonasschnelli> Is a key origin always fingerprint & path or can it just be the fingerprint?
< sipa> it can just be fingerprint
< sipa> in case the path is empty
< jonasschnelli> okay... but that wouldn't not imply that the fingerprint must be the related xpubs fingerprint?
< sipa> uh, i guess it would be
< sipa> yeah, there isn't much sense in that case, i guess
< jonasschnelli> I'm asking because the fingerprint could also be a hint to the signing device without revealing the path
< sipa> or at least it should be enforced
< jonasschnelli> sipa: would it make sense to always support 'h' as hardened key indicator...
< achow101> jonasschnelli: IMO yes. that's part of one my import things PRs
< jonasschnelli> And I just looked up, ... there is no "clear" standard for derivation path (BIP32 doesn't mention it specific)
< achow101> the BIP uses h/H too
< jonasschnelli> achow101: is there a spec how to specify a derivation path? I think this is something that is vaguely defined.
< sipa> jonasschnelli: the parser should always support h wherever ' is supported
< jonasschnelli> agree
< sipa> there are even tests for that
< achow101> jonasschnelli: doesn't bip 32 say>?
< sipa> jonasschnelli: that's not used by the descriptor code
< wumpus> #startmeeting
< lightningbot> Meeting started Thu Sep 6 19:00:30 2018 UTC. The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
< lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
< gmaxwell> Hi
< achow101> hi
< jonasschnelli> hi
< wumpus> #bitcoin-core-dev Meeting: wumpus sipa gmaxwell jonasschnelli morcos luke-jr btcdrak sdaftuar jtimon cfields petertodd kanzure bluematt instagibbs phantomcircu
< wumpus> it codeshark michagogo marcofalke paveljanik NicolasDorier jl2012 achow101 meshcollider jnewbery maaku fanquake promag provoostenator
< wumpus> PSA: v0.17.0rc3 has been tagged
< wumpus> topics?
< sipa> \o/
< meshcollider> hi
< gmaxwell> Seems things have been kind of quiet.
< wumpus> yes, quiet week
< provoostenator> hi
< jnewbery> hi
< gmaxwell> phantomcircuit (your ping got cut, perhaps you'd like to talk about your poll() work, if you're around)
< Chris_Stewart_5> Thoughts on merging #12775 ? Do we want it enabled in .travis.yml by default?
< gribble> https://github.com/bitcoin/bitcoin/issues/12775 | Integration of property based testing into Bitcoin Core by Christewart · Pull Request #12775 · bitcoin/bitcoin · GitHub
< wumpus> Chris_Stewart_5: yeah that one should be merged...
< phantomcircuit> Hello
< Chris_Stewart_5> sorry, RAPIDCHECK=1 in DEP_OPTS
< 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
< 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
< wumpus> oh topic
< wumpus> #topic poll() (phantoncircuit)
< Chris_Stewart_5> wumpus: I'll try to take care of that in the next 2 days
< phantomcircuit> i've started that in #14147 (which is as far as im going to go in that particular pr)
< gribble> https://github.com/bitcoin/bitcoin/issues/14147 | net: Refactor ThreadSocketHandler by pstratem · Pull Request #14147 · bitcoin/bitcoin · GitHub
< 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
< wumpus> Chris_Stewart_5: just be clear :)
< phantomcircuit> next step after that is going to be to separate the socket handling logic from the select() logic
< wumpus> phantomcircuit: good
< 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?
< phantomcircuit> gmaxwell, right
< 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? :)
< sipa> it seems we're pretty close on track for the 0.17 release schedule
< gmaxwell> he's doing it more properly.
< gmaxwell> ISTM at least the current PR is a perfectly fine change even considered independantly of poll().
< 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
< phantomcircuit> which is O(n^2) worst case for n = vNodes.size()
< phantomcircuit> so probably dont want to do that
< wumpus> ok, yes, that would be good to avoid, we don't want to worsen performance
< wumpus> right, thanks for the explanation, it's common for people to underestimate how much work something is anyhow :)
< 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
< phantomcircuit> and indeed the current patchset is specifically selected to make sense even without poll() (but that's certainly why im doing it)
< wumpus> should we add 14147 to high priority for review? I suppose it's blocking further work for you
< 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
< phantomcircuit> i believe matts patchset just iterated which is trivial but certainly not what we want to do
< wumpus> indeed
< wumpus> it was just aproof of concept then
< sipa> makes sense
< phantomcircuit> wumpus, im building off that pr for the rest of the poll() logic assuming it'll eventually be fine
< phantomcircuit> there's 7 commits to that pr and 100 loc changed but mostly that's just moving things
< BlueMatt> I mean iterating is essentially fine, really
< gmaxwell> It's a nearly trivial review in any case. It's just moving things around.
< BlueMatt> its not like we're handling 10k connections
< gmaxwell> ?w=1 eliminates 90% of the diff. :)
< BlueMatt> (and less error-prone than tracking things with CNodes)
< BlueMatt> cause we've had errors in the past with CNode deletion ordering....
< BlueMatt> or, if not errors, shitloads of complication that made review hard
< 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.
< wumpus> anyhow, let's review phantomcircuit 's work
< BlueMatt> wumpus: yea, fair
< wumpus> I don't see the point of discussing this now
< BlueMatt> yep
< 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
< wumpus> any other topics?
< gmaxwell> +1
< gmaxwell> sipa: wumpus: Where did we ever land in replacing the openssl RNG?
< wumpus> #topic replacing the openssl RNG
< wumpus> good question, I think that kind of stranded at some point
< sipa> gmaxwell: i don't feel like spending much work on it
< gmaxwell> It would be nice if we could finally be rid of the dependency in 0.18.
< sipa> but we should probably write some requirements for what it needs to be replaced with
< wumpus> ok so someone would need to pick up sipa 's old work probably
< 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. :)
< sipa> yes
< meshcollider> Is there an old PR or something
< wumpus> I don't care about that part anymore
< meshcollider> Or a gist
< moneyball> suggested topic: Tokyo CoreDev topic ideas
< 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)
< wumpus> just put it in its own subdirectory under src, someone that wants it as library can do the work for that
< wumpus> if not, there's no need to do build system work etc
< provoostenator> meshcollider: #10299
< gribble> https://github.com/bitcoin/bitcoin/issues/10299 | Remove OpenSSL by sipa · Pull Request #10299 · bitcoin/bitcoin · GitHub
< meshcollider> provoostenator: thanks
< 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)
< wumpus> I know all too well how frustrating making libraries for c++ is
< luke-jr> why would it be C++?
< wumpus> lol...
< provoostenator> CoreDev topic ideas: hardware wallet support, faster wallet bootstrap (i.e. sync in background)
< wumpus> yesl et's start piling up other requirements as well
< wumpus> ok, another topic?
< 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.
< provoostenator> Probably continue the coin selection fun?
< wumpus> let's rewrite it in rust !
< moneyball> wumpus suggested topic: Tokyo CoreDev topic ideas
< kanzure> hi.
< wumpus> #topic Tokyo CoreDev topic ideas (provoostenator)
< sipa> CoreDev topics: descriptors and extensions to them
< kanzure> already on there
< jtimon> rust all your problems
< kanzure> what would you guys like to hjear from other people, and/or from yourselves
< 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 :)
< wumpus> jtimon: I have C/C++ burnout
< kanzure> oh no that's terminal
< jtimon> wumpus: well, you write python too :p
< wumpus> jtimon: python is still somewhat cute
< * jonasschnelli> can't be in Tokyo :/
< achow101> kanzure: moneyball: what are the current topics, if any?
< gmaxwell> I'd like to see kallewoof's progress on input grouping get done.
< sipa> wumpus: thankfully carbon doesn't rust
< wumpus> sipa: heh!
< 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
< gribble> https://github.com/bitcoin/bitcoin/issues/13869 | Filename and command line encoding issue on Windows · Issue #13869 · bitcoin/bitcoin · GitHub
< gmaxwell> Maybe people could think about rhavar's bustapay... I think it might be reasonable to support it in the bitcoin core wallet.
< gmaxwell> lattice-based digital signatures?!?!
< kanzure> who would be a good candidate to fly the flag of bustapay
< kanzure> gmaxwell: it's a meshcollider thing
< moneyball> here is what kanzure has collected so far, from about 10 people:
< moneyball> * partially signed bitcoin transactions
< moneyball> * hardware wallet support
< moneyball> * script validation
< moneyball> * input grouping
< moneyball> * output descriptors
< moneyball> * Schnorr signatures BIP
< moneyball> * k-of-n threshold signatures using Schnorr
< moneyball> * forward blocks
< moneyball> * hardware wallet support in Bitcoin Core
< moneyball> * status of client-side filtering and neutrino
< moneyball> * client side filtering
< sipa> please don't paste long lists in IRC
< meshcollider> Heh I don't think it's worth discussing lattice sigs at CoreDev
< moneyball> oh, sorry
< meshcollider> That's just what I'm working on
< achow101> kanzure: re bustapay, me? I was part of the meeting that came up with the basis for that
< kanzure> okay it is you
< kanzure> done
< jnewbery> maybe offtopic for now, but how is bustapay different from p2ep?
< wumpus> nah pasting 12 lines which are relevant topics isn't that bad, but yes, never do that with error messages / logs pelase :)
< BlueMatt> "forward blocks"
< BlueMatt> ?
< instagibbs> BlueMatt, maaku's thing
< instagibbs> IIRC
< kanzure> BlueMatt: time travel exploit
< achow101> jnewbery: it's basically the same thing, but actually implemented
< gmaxwell> jnewbery: actually implementable and not woo.
< kanzure> moneyball and i will be heckling each of you for more topic suggestions soon, thanks for the input
< achow101> it cuts out some of the complexity as a tradeoff for a possible and very small (IMO) privacy risk
< 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
< wumpus> do you need even more topics? seems a decent list
< kanzure> this list is tiny compared to last few times; it'll grow.
< BlueMatt> dandelion, depending on who's there, should be discussed
< wumpus> none trivial
< 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
< instagibbs> BlueMatt, ACK
< sipa> agree with BlueMatt as well
< kanzure> jtimon: added
< kanzure> BlueMatt: added
< gmaxwell> agree with BlueMatt as well
< BlueMatt> agree with BlueMatt as well
< BlueMatt> wait, hmmm
< kanzure> don't do that you'll break the universe
< sipa> try typing 'google' into google
< michagogo> Or ‘recursion’
< BlueMatt> Did you mean recursion?
< sipa> BlueMatt: it was an it crowd joke
< 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.
< * BlueMatt> emailed support and got back a "we're looking into it, its visible on a few projects"
< achow101> do we have so many PRs and issues that we broke github?
< wumpus> github is falling apart, so soon after ms took it over
< sipa> nah, it was falling apart before
< wumpus> I think they switched the server hosting to windows 95
< sipa> haha
< wumpus> if it helps I'll send a mail too
< luke-jr> at least not ME
< wumpus> haah then it would alrady be gone
< kanzure> other topics?
< gmaxwell> WinCE.
< michagogo> How did everyone get a bionic gitian environment working?
< meshcollider> MS haven't actually taken over yet have they
< luke-jr> michagogo: I ended up installing from the iso by hand
< wumpus> deep magic voodoo rituals
< luke-jr> michagogo: and patching gitian to work with it
< wumpus> #topic gitian build on bionic
< meshcollider> sipa: lol
< provoostenator> Works
< wumpus> with LXC it's easy, just the standard steps
< achow101> both lxc and docker work
< achow101> but according to luke-jr kvm is broken again as apparently the new vmbuilder doesn't work?
< achow101> (I haven't tried yet)
< michagogo> wumpus: make-base-vm —lxc —suite bionic seemed to work for me (finished without error), but the result seems broken
< jonasschnelli> define "broken"?
< luke-jr> michagogo: latest gitian?
< michagogo> Yep
< michagogo> (On a xenial host)
< 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
< wumpus> (e.g. I needed a new lxc version, as well as a new version of debootstrap as it was lacking the bionic script)
< 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
< wumpus> I don't remember what the minimum version is that works, jonasschnelli might
< * jonasschnelli> looking
< jonasschnelli> stable-2.1
< wumpus> yea 2.1.5 or something?
< * luke-jr> wonders why bionic needs special LXC support
< jonasschnelli> I think its 2.1.1
< jonasschnelli> jup. 2.1.1. is min
< wumpus> thanks!
< achow101> you need at least 2.1.x
< wumpus> michagogo: which lxc version did you try with?
< michagogo> wumpus: whatever’s in xenial-updates
< achow101> michagogo: do `lxc-start --version`
< promag> hi :|
< wumpus> Package: lxc1 (2.0.8-0ubuntu1~16.04.2)
< wumpus> so, too old.
< wumpus> promag: hi
< wumpus> other topics?
< wumpus> #endmeeting
< lightningbot> Meeting ended Thu Sep 6 19:52:31 2018 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
< sipa> seems not
< meshcollider> 7:25 am <gmaxwell> I'd like to see kallewoof's progress on input grouping get done.
< meshcollider> What's this referring to?
< luke-jr> #12257 probably?
< gribble> https://github.com/bitcoin/bitcoin/issues/12257 | [wallet] Use destination groups instead of coins in coin select by kallewoof · Pull Request #12257 · bitcoin/bitcoin · GitHubAsset 1Asset 1
< gmaxwell> especially the "group for everyone, if it doesn't make your fees higher" part that got dropped at the last minute.
< luke-jr> but it's already merged, so.. dunno
< luke-jr> ah
< gmaxwell> it got gimped before being merged. :P
< meshcollider> oh
< michagogo> Yep, 2.0.8
< michagogo> “lxc-init: missing container name, use —name option”
< michagogo> Maybe I’ll upgrade my VM to 18.04
< MarcoFalke> We should put the minimum version into https://github.com/bitcoin-core/docs
< michagogo> sudo do-release-upgrade
< michagogo> er
< wumpus> MarcoFalke: yes, would make sense
< sipa> jonasschnelli: to be clear, if you have an xpub without key origin in a descriptor, it'll still report a fpr/path in its expansion; just one with fpr = xpub's short id, and empty path
< jonasschnelli> ok
< sipa> i think i'll add a test that if you supply a key origin with empty path, its hash matches the xpub's short id
< michagogo> Okay, I'm now running bionic
< michagogo> And yep, looks like now the build's working
< michagogo> So, hey, looks like my new i7-8750H is quite a bit faster than my i7-3610QM :D