19:00:03 #startmeeting 19:00:03 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 Useful Commands: #action #agreed #help #info #idea #link #topic. 19:00:10 hi 19:00:22 #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 hi. 19:00:51 Hi 19:00:53 hi 19:00:54 hi 19:01:10 very quick topic suggestion: meeting time poll 19:01:20 hi first time to the meeting 19:01:28 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 Welcome ken2812221 :) 19:01:37 howdy 19:01:56 #topic meeting time poll (cfields) 19:01:59 ken2812221: good to see you here :) 19:02:06 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 19:02:18 * sipa has voted 19:02:21 * jonasschnelli has voted 19:02:23 yo vote 19:02:23 when does the poll close? 19:02:24 cfields: your poll made me realise the current time is among the worst possible times for me :P 19:02:35 achow101: after the meeting today IIRC 19:02:40 achow101: this time next week 19:02:46 ah, next meeting 19:03:10 #topic Move feature freeze date? (wumpus) 19:03:11 luke-jr: I wanted to give enough time for people to realize they didn't receive a mail to vote 19:03:14 cfield: Can I get an email for voting? 19:03:23 wumpus: + how many days/weeks? 19:03:29 so the current future freeze is july 16th, which is in a few days 19:03:35 hi 19:03:42 also, sorry about not using the more convenient doodle. I figured Cornell would be more polite with everyone's email addresses. 19:03:42 i would be in favor of delaying slightly, let's say a week 19:03:49 I'm in favor of moving since i'd like to get scantxout and disableprivatekey in 19:03:53 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 it would be nice to get psbt (#13557) in for 0.17 19:03:58 we have many relative big but important improvements that are almost ready 19:03:58 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 so my question is, should we delay it, are there important things that would otherwise miss but are *almost* ready? 19:04:04 https://github.com/bitcoin/bitcoin/issues/13557 | BIP 174 PSBT Serializations and RPCs by achow101 · Pull Request #13557 · bitcoin/bitcoin · GitHub 19:04:08 ken2812221: pm me your email? 19:04:09 the poll as-is will heavily bias current times :) 19:04:28 oh sorry, new topic 19:04:31 achow101: isn't the BIP still in discussion? Or have we finalized it? 19:04:36 instagibbs: i posted to the mailing list as well. but no further outreach. 19:04:43 jonasschnelli: it was marked as proposed 19:04:44 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 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 jonasschnelli: so not material changes 19:04:59 jonasschnelli: spec part is finalized. some wording for clarifications may change, but its basically final 19:05:07 ack... have plans to review #13557 19:05:16 https://github.com/bitcoin/bitcoin/issues/13557 | BIP 174 PSBT Serializations and RPCs by achow101 · Pull Request #13557 · bitcoin/bitcoin · GitHub 19:05:23 jonasschnelli: beware of unicorns when attempting to review it though 19:05:42 achow101: private browsing help while reviewing. :) 19:05:47 kanzure: sorry :( 19:05:51 yes, but doesn't let you comment 19:06:03 kanzure: drag and drop worked best IMO 19:06:09 oh 19:06:51 wumpus: would it make sense to put the feature freeze date on or shortly after a weekly meeting? 19:07:11 sipa: you can still log in to GitHub when on private browsing 19:07:13 sipa: possibly, though I don't want to keep moving it forward 19:07:17 wumpus: fair 19:07:54 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 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 how about moving it to next thursday and try to review things this week? 19:08:30 ack 19:08:41 that's a 3 day delay; ok 19:08:42 let's just move it by a week then 19:08:49 I think it helps anyway, don't ask me why lol 19:09:06 wumpus: ack 19:09:07 so july 23 19:09:08 Ack for move 19:09:23 will update #12624 19:09:24 https://github.com/bitcoin/bitcoin/issues/12624 | Release schedule for 0.17.0 · Issue #12624 · bitcoin/bitcoin · GitHub 19:10:18 #topic 0.16.2 (wumpus) 19:10:42 it'd make sense to do a 0.16.2 release soon 19:10:54 yeah 19:10:57 so it's not too little before 0.17 19:11:08 too short* 19:11:36 anything that really needs to make it in, besides what is already backported in #13644? 19:11:36 there is already a backports pr for the rest, I think at #13644 19:11:38 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 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 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 ok 19:12:05 (well, right before RC1 anyway) 19:12:21 luke-jr: but that way if a backport goes bad, potentially both new versions end up busted :\ 19:12:31 since we're up against rc1 anyway, this timing seems good 19:12:38 I'd rather stagger a bit, generally speaking 19:12:59 cfields: true, but hopefully we're more careful than that :x 19:13:39 what is 0.16.2 timeline like? 19:14:18 instagibbs: once 13644 gets merged, essentially, I think 19:14:27 hence the "anyone have anything else to shove in?" 19:14:38 Yeah. timeline: Backports, merge+test, release 19:14:39 yes, as no one mentioned anything else it's just 13644 19:14:41 make sure you review that 19:14:53 well, we need a rc1 at least I think? 19:14:57 sure 19:15:00 yes, as always 19:16:39 rc1 then if no significant bug reports, tag final 19:16:45 usually a week 19:17:27 #topic gitian build to 18.04 ubuntu bionic 19:17:37 what are the current issues? 19:17:47 (with upgrading to 18.04) 19:17:48 I merged #13177 today, wondering what the remaining issues are 19:17:50 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 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 did vmbuilder get fixed for 18.04? 19:18:17 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 IIRC vmbuilder doesn't work with 18.04. or maybe it was vmbuilder doesn't work on 18.04. 19:18:50 achow101: I tried it on Gentoo and it couldn't build :/ 19:18:57 so would need to find another way to build 18.04 VMs? 19:19:10 yes 19:19:11 or get vmbuilder fixed ideally 19:19:21 I think vmbuilder is a dead project though 19:19:24 :/ 19:19:29 wumpus: hence my docker thing 19:19:55 is it not possible to just use a static, pre-prepared rootfs? 19:19:57 well, switching to another container shouldn't be necessary 19:20:03 cfields: need a bootloader 19:20:04 it's just a matter of building a rootfs 19:20:14 cfields: and who to trust with a rootfs anyway? 19:20:27 luke-jr: well... ubuntu. currently. 19:20:28 you can download pre-made cloud rootfses from ubuntu 19:20:32 oh 19:20:45 (I was just suggesting we use one of their docker images as a rootfs for gitian) 19:20:47 dongcarl: present? you were looking into minimal linux images to bootstrap from? 19:20:49 do they have bootloaders somehow too? 19:21:26 #link https://cloud-images.ubuntu.com/bionic/current/ 19:21:44 is vmbuilder used for both lxc and kvm? 19:21:51 luke-jr: tbh I have no idea how bootloaders work for kvm/lxc 19:21:52 (in gitian) 19:22:10 cfields: for KVM, like real hardware 19:22:11 to convert the img to qcow2 for qemu: qemu-img convert -O qcow2 ${IMAGE} ${VMDIR}/os.img 19:22:14 wumpus: daily builds? do we retain determinism if people use different builds? 19:22:14 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 cfields: KVM just virtualized/emulates a real machine 19:22:52 sipa: well it does already do an apt-get upgrade before buildling so I don't know if that matters 19:23:24 but yes maybe uncertain... 19:23:42 cfields: LXC even skips init afaik 19:23:55 cfields: you just run processes in a namespace that doesn't see the rest of your system 19:23:57 I guess the .img files would have a bootloader probably 19:24:01 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 right - LXC certainly doesn't need a bootloader 19:24:11 okay 19:24:12 sipa: init is a userspace process; you can't skip it :P 19:24:13 I can investigate all this and report back next week 19:24:31 luke-jr: ...? 19:24:35 as I understand it, basically you just launch *any* exceutable in the container 19:24:52 wumpus: yes, that's my understanding 19:24:53 sipa: init is what handles all the startup daemons etc 19:25:02 this an be init, but it can also be just a shell (fairly sure gitian does the latter) 19:25:10 luke-jr: there are no startup daemons in gitian 19:25:14 O.o 19:25:17 wumpus: I always assumed init was just a thin launcher for whatever binary you're telling it to run 19:25:18 luke-jr: it simply calls the build script 19:25:22 there are with KVM ofc 19:25:30 yes, I mean with LXC 19:25:47 cfields: thanks! 19:26:14 I have a related subtopic, if nothing's queued up next 19:27:20 I don't have any more topics 19:27:29 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 that doesn't get us anywhere for 0.17... 19:27:43 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 it uses debootstrap 19:28:30 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 ah yes debootstrap, that's a good way to build debian rootfs'es 19:29:09 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 cfields: so what would that entail for 0.17? 19:29:11 thoughts? 19:30:29 cfields: i'm not sure what you're suggesting 19:30:45 achow101: vmbuilder also uses debootstrap internally 19:31:11 cfields: is there a way to make this work for non-x86_64? 19:32:47 cfields: adding an extra gitian descriptor for what? 19:32:59 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 cfields: seems fine to me, but it seems independent of release schedule 19:33:41 luke-jr: yes, I've just focused on x86_64 as a start 19:33:53 cfields: x86_64 isn't native for me ;) 19:34:02 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 ah, fair 19:34:45 * sipa is reminded to try a gitian build again 19:35:03 cfields: ie, I'm not looking at the target platforms, but the build platform 19:35:06 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 ok! thanks in advance 19:36:11 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 Ubuntu has ppc64el images; so there's no native x86_64 needed is my point 19:38:40 luke-jr: ok 19:38:47 19:39:02 cool 19:39:03 topic proposals? 19:39:57 I guess kallewoof isn't here (timezome) but I wondered what was the status of 12257. 19:40:05 It seems to just be in a rebase rebase cycle. 19:40:29 #12257 19:40:33 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 it has only one "light utack" 19:41:20 i held off on it, expecting other more invesive changes to coin selection to go in first 19:41:34 sipa: well, they did! 19:41:35 but if that isn't happening for 0.17, maybe we can do destination groups first 19:41:39 and a "code review ack" but with comments 19:41:45 (I mean things like BNB got done since that was open) 19:42:12 gmaxwell: sipa srd fallback is more invasive and probably won't make 0.17 19:42:23 yeah 19:43:06 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 gmaxwell: perhaps. I can try a siulation of srd on top of 12257 19:44:21 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 achow101: that would be useful 19:44:49 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 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 I also agree that it's a (privacy) fix. 19:46:18 it's an obvious improvement for sure 19:46:35 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 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 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 also the behavioural changes can be made a no-op pretty trivially 19:49:01 ie, we could merge it before the freeze, and trivially revert the behaviour if a problem is found 19:49:44 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 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 but getting to that future requires getting the basic functionality in. :) 19:50:46 FWIW, I have read through the code at least once; just not in enough detail I'd felt comfortable ACKing 19:51:23 Okay, I think this topic is done... Consider yourselves reminded. I'm glad to know there wasn't some other blocker. 19:51:59 any other topics? 19:52:11 [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 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 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 yea, I meant that as a long term thing. 19:53:29 right, I agree then 19:55:29 #endmeeting