19:00:03 <wumpus> #startmeeting
19:00:03 <lightningbot> Meeting started Thu Jul 12 19:00:03 2018 UTC.  The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:00:03 <lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
19:00:10 <achow101> hi
19:00:22 <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:00:45 <kanzure> hi.
19:00:51 <meshcollider_> Hi
19:00:53 <jonasschnelli> hi
19:00:54 <nmnkgl> hi
19:01:10 <cfields> very quick topic suggestion: meeting time poll
19:01:20 <ken2812221> hi first time to the meeting
19:01:28 <wumpus> so quite some things to discuss today, at least: - Move feature freeze date? (currently july 16th) - 0.16.2 - gitian build to 18.04: what is left to do
19:01:32 <meshcollider> Welcome ken2812221 :)
19:01:37 <jamesob> howdy
19:01:56 <wumpus> #topic meeting time poll (cfields)
19:01:59 <cfields> ken2812221: good to see you here :)
19:02:06 <cfields> remember to vote on meeting time. If you didn't get a mail about it, now's the time to tell me!
19:02:13 * wumpus has voted
19:02:13 <cfields> </topic>
19:02:18 * sipa has voted
19:02:21 * jonasschnelli has voted
19:02:23 <instagibbs> yo vote
19:02:23 <achow101> when does the poll close?
19:02:24 <luke-jr> cfields: your poll made me realise the current time is among the worst possible times for me :P
19:02:35 <luke-jr> achow101: after the meeting today IIRC
19:02:40 <cfields> achow101: this time next week
19:02:46 <luke-jr> ah, next meeting
19:03:10 <wumpus> #topic Move feature freeze date? (wumpus)
19:03:11 <cfields> luke-jr: I wanted to give enough time for people to realize they didn't receive a mail to vote
19:03:14 <ken2812221> cfield: Can I get an email for voting?
19:03:23 <jonasschnelli> wumpus: + how many days/weeks?
19:03:29 <wumpus> so the current future freeze is july 16th, which is in a few days
19:03:35 <jnewbery> hi
19:03:42 <cfields> also, sorry about not using the more convenient doodle. I figured Cornell would be more polite with everyone's email addresses.
19:03:42 <sipa> i would be in favor of delaying slightly, let's say a week
19:03:49 <jonasschnelli> I'm in favor of moving since i'd like to get scantxout and disableprivatekey in
19:03:53 <luke-jr> rwconf is not ready for review yet; I can prioritise it, but unless there's hope for sufficient review before the freeze, I won't
19:03:54 <achow101> it would be nice to get psbt (#13557) in for 0.17
19:03:58 <sipa> we have many relative big but important improvements that are almost ready
19:03:58 <instagibbs> cfields, what effort was made to reach out to folks who don't attend already, yet contribute in either review or PR?
19:04:03 <wumpus> so my question is, should we delay it, are there important things that would otherwise miss but are *almost* ready?
19:04:04 <gribble> https://github.com/bitcoin/bitcoin/issues/13557 | BIP 174 PSBT Serializations and RPCs by achow101 · Pull Request #13557 · bitcoin/bitcoin · GitHub
19:04:08 <cfields> ken2812221: pm me your email?
19:04:09 <instagibbs> the poll as-is will heavily bias current times :)
19:04:28 <instagibbs> oh sorry, new topic
19:04:31 <jonasschnelli> achow101: isn't the BIP still in discussion? Or have we finalized it?
19:04:36 <cfields> instagibbs: i posted to the mailing list as well. but no further outreach.
19:04:43 <sipa> jonasschnelli: it was marked as proposed
19:04:44 <luke-jr> wumpus: things can always go into 0.18; my only concern is that the GUI pruning was merged in advance of rwconf
19:04:45 <kanzure> i've answered the poll but i also want to complain about its setup (it's like 500 button clicks to answer the full thing)
19:04:53 <sipa> jonasschnelli: so not material changes
19:04:59 <achow101> jonasschnelli: spec part is finalized. some wording for clarifications may change, but its basically final
19:05:07 <jonasschnelli> ack... have plans to review #13557
19:05:16 <gribble> https://github.com/bitcoin/bitcoin/issues/13557 | BIP 174 PSBT Serializations and RPCs by achow101 · Pull Request #13557 · bitcoin/bitcoin · GitHub
19:05:23 <achow101> jonasschnelli: beware of unicorns when attempting to review it though
19:05:42 <jonasschnelli> achow101: private browsing help while reviewing. :)
19:05:47 <cfields> kanzure: sorry :(
19:05:51 <sipa> yes, but doesn't let you comment
19:06:03 <luke-jr> kanzure: drag and drop worked best IMO
19:06:09 <kanzure> oh
19:06:51 <sipa> wumpus: would it make sense to put the feature freeze date on or shortly after a weekly meeting?
19:07:11 <meshcollider> sipa: you can still log in to GitHub when on private browsing
19:07:13 <wumpus> sipa: possibly, though I don't want to keep moving it forward
19:07:17 <sipa> wumpus: fair
19:07:54 <sipa> meshcollider: heh, i assumed the unicorn was due to being logged in or not; does private browsing itself (regardless of login status) help?
19:08:11 <wumpus> we have time-based releases for a good reason, the idea is not to switch to "let's decide in the meeting when it's ready"
19:08:16 <achow101> how about moving it to next thursday and try to review things this week?
19:08:30 <jonasschnelli> ack
19:08:41 <sipa> that's a 3 day delay; ok
19:08:42 <wumpus> let's just move it by a week then
19:08:49 <meshcollider> I think it helps anyway, don't ask me why lol
19:09:06 <achow101> wumpus: ack
19:09:07 <wumpus> so july 23
19:09:08 <meshcollider> Ack for move
19:09:23 <wumpus> will update #12624
19:09:24 <gribble> https://github.com/bitcoin/bitcoin/issues/12624 | Release schedule for 0.17.0 · Issue #12624 · bitcoin/bitcoin · GitHub
19:10:18 <wumpus> #topic 0.16.2 (wumpus)
19:10:42 <wumpus> it'd make sense to do a 0.16.2 release soon
19:10:54 <sipa> yeah
19:10:57 <wumpus> so it's not too little before 0.17
19:11:08 <wumpus> too short*
19:11:36 <wumpus> anything that really needs to make it in, besides what is already backported in #13644?
19:11:36 <BlueMatt> there is already a backports pr for the rest, I think at #13644
19:11:38 <gribble> https://github.com/bitcoin/bitcoin/issues/13644 | 0.16: Remaining backports for 0.16.2 by MarcoFalke · Pull Request #13644 · bitcoin/bitcoin · GitHub
19:11:40 <gribble> https://github.com/bitcoin/bitcoin/issues/13644 | 0.16: Remaining backports for 0.16.2 by MarcoFalke · Pull Request #13644 · bitcoin/bitcoin · GitHub
19:11:43 <luke-jr> tbh, I'd almost think it's preferable to do a bugfix right before the next major release; but no objections either way
19:12:00 <wumpus> ok
19:12:05 <luke-jr> (well, right before RC1 anyway)
19:12:21 <cfields> luke-jr: but that way if a backport goes bad, potentially both new versions end up busted :\
19:12:31 <luke-jr> since we're up against rc1 anyway, this timing seems good
19:12:38 <cfields> I'd rather stagger a bit, generally speaking
19:12:59 <luke-jr> cfields: true, but hopefully we're more careful than that :x
19:13:39 <instagibbs> what is 0.16.2 timeline like?
19:14:18 <BlueMatt> instagibbs: once 13644 gets merged, essentially, I think
19:14:27 <BlueMatt> hence the "anyone have anything else to shove in?"
19:14:38 <MarcoFalke> Yeah. timeline: Backports, merge+test, release
19:14:39 <wumpus> yes, as no one mentioned anything else it's just 13644
19:14:41 <wumpus> make sure you review that
19:14:53 <luke-jr> well, we need a rc1 at least I think?
19:14:57 <MarcoFalke> sure
19:15:00 <wumpus> yes, as always
19:16:39 <wumpus> rc1 then if no significant bug reports, tag final
19:16:45 <wumpus> usually a week
19:17:27 <wumpus> #topic gitian build to 18.04 ubuntu bionic
19:17:37 <sipa> what are the current issues?
19:17:47 <sipa> (with upgrading to 18.04)
19:17:48 <wumpus> I merged #13177 today, wondering what the remaining issues are
19:17:50 <gribble> https://github.com/bitcoin/bitcoin/issues/13177 | GCC-7 and glibc-2.27 back compat code by ken2812221 · Pull Request #13177 · bitcoin/bitcoin · GitHub
19:18:14 <wumpus> note that we *must* upgrade, otherwise the qt build will fail (or would have to downgrade qt again, which is a mess)
19:18:17 <luke-jr> did vmbuilder get fixed for 18.04?
19:18:17 <cfields> I was in denial that I would have toolchain stuff done in time for 0.17. Sadly it's not happening. Just started having a look at the current PRs.
19:18:30 <achow101> IIRC vmbuilder doesn't work with 18.04. or maybe it was vmbuilder doesn't work on 18.04.
19:18:50 <luke-jr> achow101: I tried it on Gentoo and it couldn't build :/
19:18:57 <wumpus> so would need to find another way to build 18.04 VMs?
19:19:10 <achow101> yes
19:19:11 <luke-jr> or get vmbuilder fixed ideally
19:19:21 <achow101> I think vmbuilder is a dead project though
19:19:24 <luke-jr> :/
19:19:29 <achow101> wumpus: hence my docker thing
19:19:55 <cfields> is it not possible to just use a static, pre-prepared rootfs?
19:19:57 <wumpus> well, switching to another container shouldn't be necessary
19:20:03 <luke-jr> cfields: need a bootloader
19:20:04 <wumpus> it's just a matter of building a rootfs
19:20:14 <luke-jr> cfields: and who to trust with a rootfs anyway?
19:20:27 <cfields> luke-jr: well... ubuntu. currently.
19:20:28 <wumpus> you can download pre-made cloud rootfses from ubuntu
19:20:32 <luke-jr> oh
19:20:45 <cfields> (I was just suggesting we use one of their docker images as a rootfs for gitian)
19:20:47 <sipa> dongcarl: present? you were looking into minimal linux images to bootstrap from?
19:20:49 <luke-jr> do they have bootloaders somehow too?
19:21:26 <wumpus> #link https://cloud-images.ubuntu.com/bionic/current/
19:21:44 <achow101> is vmbuilder used for both lxc and kvm?
19:21:51 <cfields> luke-jr: tbh I have no idea how bootloaders work for kvm/lxc
19:21:52 <achow101> (in gitian)
19:22:10 <luke-jr> cfields: for KVM, like real hardware
19:22:11 <wumpus> to convert the img to qcow2 for qemu:   qemu-img convert -O qcow2  ${IMAGE} ${VMDIR}/os.img
19:22:14 <sipa> wumpus: daily builds? do we retain determinism if people use different builds?
19:22:14 <cfields> I always assumed they just jumped straight into init
19:22:28 * luke-jr wonders if these ppc64el rootfs would build identical binaries :D
19:22:50 <luke-jr> cfields: KVM just virtualized/emulates a real machine
19:22:52 <wumpus> sipa: well it does already do an apt-get upgrade before buildling so I don't know if that matters
19:23:24 <wumpus> but yes maybe uncertain...
19:23:42 <sipa> cfields: LXC even skips init afaik
19:23:55 <sipa> cfields: you just run processes in a namespace that doesn't see the rest of your system
19:23:57 <luke-jr> I guess the .img files would have a bootloader probably
19:24:01 <achow101> sipa: at least with docker, the base ubuntu image changes fairly frequently (within the same version though) and that has produced deterministic binaries for me with different base images
19:24:10 <wumpus> right - LXC certainly doesn't need a bootloader
19:24:11 <sipa> okay
19:24:12 <luke-jr> sipa: init is a userspace process; you can't skip it :P
19:24:13 <cfields> I can investigate all this and report back next week
19:24:31 <sipa> luke-jr: ...?
19:24:35 <wumpus> as I understand it, basically you just launch *any* exceutable in the container
19:24:52 <sipa> wumpus: yes, that's my understanding
19:24:53 <luke-jr> sipa: init is what handles all the startup daemons etc
19:25:02 <wumpus> this an be init, but it can also be just a shell (fairly sure gitian does the latter)
19:25:10 <wumpus> luke-jr: there are no startup daemons in gitian
19:25:14 <luke-jr> O.o
19:25:17 <cfields> wumpus: I always assumed init was just a thin launcher for whatever binary you're telling it to run
19:25:18 <wumpus> luke-jr: it simply calls the build script
19:25:22 <luke-jr> there are with KVM ofc
19:25:30 <wumpus> yes, I mean with LXC
19:25:47 <wumpus> cfields: thanks!
19:26:14 <cfields> I have a related subtopic, if nothing's queued up next
19:27:20 <wumpus> I don't have any more topics
19:27:29 <cfields> So, I didn't get the toolchain work done in time for 0.17, but I am nearly finished with the first part: A deterministic, fully static, native x86_64 toolchain capable of rebuilding another native toolchain...
19:27:35 <cfields> that doesn't get us anywhere for 0.17...
19:27:43 <achow101> for lxc, we don't use vmbuilder, but I'm pretty sure what it does use is not the way to use lxc
19:27:49 <achow101> it uses debootstrap
19:28:30 <cfields> but it might be helpful to have at least that much built as part of the 0.17 release process. As with that done deterministically, we wouldn't have to rely on a distro toolchain at all for 0.18.
19:28:39 <wumpus> ah yes debootstrap, that's a good way to build debian rootfs'es
19:29:09 <cfields> so, I'd like to propose possibly adding an extra (optional) gitian descriptor that builders can run as part of the 0.17 release.
19:29:10 <sipa> cfields: so what would that entail for 0.17?
19:29:11 <cfields> thoughts?
19:30:29 <sipa> cfields: i'm not sure what you're suggesting
19:30:45 <luke-jr> achow101: vmbuilder also uses debootstrap internally
19:31:11 <luke-jr> cfields: is there a way to make this work for non-x86_64?
19:32:47 <sipa> cfields: adding an extra gitian descriptor for what?
19:32:59 <cfields> sipa: at some point we're going to have to use gitian (or similar) to build all deterministic toolchains. The work isn't done for all toolchains yet, but I do have something working that gets us a native one. I'm proposing that we go ahead and build that one, so that it can later be used to build the rest.
19:33:31 <sipa> cfields: seems fine to me, but it seems independent of release schedule
19:33:41 <cfields> luke-jr: yes, I've just focused on x86_64 as a start
19:33:53 <luke-jr> cfields: x86_64 isn't native for me ;)
19:34:02 <cfields> sipa: indeed, mostly. I just doubt I'll be able to convince a bunch of people to run a gitian build at any other time :p
19:34:17 <sipa> ah, fair
19:34:45 * sipa is reminded to try a gitian build again
19:35:03 <luke-jr> cfields: ie, I'm not looking at the target platforms, but the build platform
19:35:06 <cfields> ok, it's probably not at all clear what I'm getting at. I'll try to get enough together to PR something.
19:36:08 <wumpus> ok! thanks in advance
19:36:11 <cfields> luke-jr: understood. native x86_64 is capable of building a cross-compiler for a new host. We just need one as a start.
19:37:21 <luke-jr> Ubuntu has ppc64el images; so there's no native x86_64 needed is my point
19:38:40 <cfields> luke-jr: ok
19:38:47 <cfields> </topic>
19:39:02 <gmaxwell> cool
19:39:03 <wumpus> topic proposals?
19:39:57 <gmaxwell> I guess kallewoof isn't here (timezome) but I wondered what was the status of 12257.
19:40:05 <gmaxwell> It seems to just be in a rebase rebase cycle.
19:40:29 <jonasschnelli> #12257
19:40:33 <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 · GitHub
19:40:57 <wumpus> it has only one "light utack"
19:41:20 <sipa> i held off on it, expecting other more invesive changes to coin selection to go in first
19:41:34 <gmaxwell> sipa: well, they did!
19:41:35 <sipa> but if that isn't happening for 0.17, maybe we can do destination groups first
19:41:39 <wumpus> and a "code review ack" but with comments
19:41:45 <gmaxwell> (I mean things like BNB got done since that was open)
19:42:12 <achow101> gmaxwell: sipa srd fallback is more invasive and probably won't make 0.17
19:42:23 <sipa> yeah
19:43:06 <gmaxwell> one of my thougts is that this kind of behavior might makes things like SRD easier to do, from a "impact on the UTXO set" perspective, as it'll cause more utxo consolidation at least for users tha reused.
19:44:14 <achow101> gmaxwell: perhaps. I can try a siulation of srd on top of 12257
19:44:21 <gmaxwell> In any case, I just wondered where it was standing, I guess its state is "people need to be nagged to review it". I'm not sure if it's a candidate to go in before the freeze.
19:44:22 <sipa> achow101: that would be useful
19:44:49 <gmaxwell> achow101: would be interesting, but I expect the benefit to be highly usage-pattern dependant. (e.g. this does nothing if you never reuse)
19:45:23 <wumpus> no opinion of whether it should go into 0.17, but I think it could just as well be called a fix as a feature
19:45:56 <gmaxwell> I also agree that it's a (privacy) fix.
19:46:18 <sipa> it's an obvious improvement for sure
19:46:35 <gmaxwell> in any case, I hit the PR accidentally, I'd forgotten about it, sounds like some of the rest of us did to. I'll give it a review. (or try, wallet stuff isn't my strongest point :) )
19:46:37 <luke-jr> I don't agree it's a fix, since it only affects people doing things with undefined behaviour; but it seems harmless enough
19:48:26 <gmaxwell> luke-jr: https://bitcointalk.org/index.php?action=profile;u=3318  I see an address there, and it's been paid mannny times. :P so seems like it might help you personally.
19:48:31 <luke-jr> also the behavioural changes can be made a no-op pretty trivially
19:49:01 <luke-jr> ie, we could merge it before the freeze, and trivially revert the behaviour if a problem is found
19:49:44 <gmaxwell> Right, it's also very unagressive by default. E.g. won't pay extra fees to achieve its end.. which sounded reasonable to me for an initial deployment.
19:50:21 <gmaxwell> I'd hope in the future we'd let it pay more in fees, esp if we have a mechnism to estimate if fees are historically high or low.
19:50:39 <gmaxwell> but getting to that future requires getting the basic functionality in. :)
19:50:46 <luke-jr> FWIW, I have read through the code at least once; just not in enough detail I'd felt comfortable ACKing
19:51:23 <gmaxwell> Okay, I think this topic is done... Consider yourselves reminded. I'm glad to know there wasn't some other blocker.
19:51:59 <wumpus> any other topics?
19:52:11 <gmaxwell> [META] Perhaps we should have a standing item to load up the PR list for regular contribtors who aren't at the meeting to make sure we're not forgetting their PRs.
19:52:39 <gmaxwell> I see also that there are some jl2012 PRs languishing that I'll probably talk to pieter about outside of the meeting.
19:53:10 <wumpus> well I've intentially skipped high priority for review this time, seems it's pretty clear, just need to get the features for 0.17 in asap
19:53:23 <gmaxwell> yea, I meant that as a long term thing.
19:53:29 <wumpus> right, I agree then
19:55:29 <wumpus> #endmeeting