19:02:24 <wumpus> #startmeeting
19:02:24 <lightningbot> Meeting started Thu Sep 20 19:02:24 2018 UTC.  The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:02:24 <lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
19:02:24 <MarcoFalke> I think anyone can be the host that knows the commands for the meeting bot?
19:02:29 <MarcoFalke> ah
19:02:46 <wumpus> #topic 0.17.0
19:02:50 <meshcollider> Hi
19:03:29 <MarcoFalke> I think two of the issues in the milestone are just release-notes related
19:03:39 <wumpus> anything specific you want to discuss about it?
19:03:57 <wumpus> correct, the only real still-open issue is achow101 's PR
19:04:01 <gmaxwell> I think we should probably just get 0.17 out soon, and even slip the PSBT fix to 0.17.1 to be done soon after.
19:04:09 <wumpus> yes,agree
19:04:44 <gmaxwell> it's unfortunately that PSBT is hobbled in 0.17, but considering bugfix upgrades we'll be better off not delaying due to a new feature that is kinda expiremental in any case... and probably has other bugs.
19:04:49 <promag> hi
19:05:49 <sipa> i'm not sure it's a very common workflow that triggers (importing a p2sh-segwit address without known pubkey, and then trying to sign on an offline system)
19:05:59 <sipa> it just happened to be the first thing i tried
19:06:14 <gmaxwell> I think it's like _the_ obvious workflow... if you happen to be using embedded segwit. :P
19:06:36 <wumpus> so, all in all it depends on why people want to upgrade to 0.17.0
19:06:40 <gmaxwell> Can we provide workaround instructions that have people import the redeemscript?
19:06:40 <luke-jr> we just released 0.16.3; is there a reason to rush 0.17 now?
19:06:49 <wumpus> if a properly working PSBT is very important, we should delay the release for it
19:06:52 <luke-jr> people who really want it can always use a rc
19:06:55 <sipa> gmaxwell: or another roundtrip; i'll write up a workaround
19:07:00 <gmaxwell> luke-jr: It's 0.1 higher.
19:07:09 <wumpus> if PSBT is seen as an curious experimental feature, then not so much
19:07:16 <gmaxwell> Since PSBT is new I don't think it's important if it works at all.
19:07:18 <wumpus> I don't have a clear perspective on that
19:07:19 <sipa> gmaxwell: it's 0.7 higher :)
19:07:24 <sdaftuar> gmaxwell: i agree with that
19:08:08 <morcos> i also would rather document the shortcomings of PSBT and proceed with the release.
19:08:09 <achow101> I think it is fine to release as is and do the fix for .1 later
19:08:15 <wumpus> don't really want complaints like 'so you released 0.17.0 but it's useless as the PSBT we've been waiting for is useless'
19:08:17 <gmaxwell> I think cosmically PSBT is important, but it's fine if we get it after another month delay or what not.. and it's not broken completely, there is a workaround, and that issue only applies to p2sh-segwit.
19:08:36 <achow101> this is fairly edge case imo
19:08:44 <MarcoFalke> so action: Merge release notes?
19:09:06 <wumpus> but that's not the gut feeling I have about it, and I'm okay with tagging 0.17.0 final next week when no new problems come up
19:09:22 <gmaxwell> It's also not the only shortcoming of PSBT as is... e.g. the txou-scan + spend workflow is kind of a mess for non-segwit outputs as I was lamenting in here a few weeks ago. (not as easily fixed)
19:09:36 <promag> make it experimental like scantxoutset?
19:09:45 <wumpus> right, PSBT is bound to have more problems that will come up when other users start using it
19:09:52 <gmaxwell> I don't think it needs to be marked more expiremental.
19:09:54 <wumpus> there will likely need to be a 0.17.1 for other reasons
19:10:01 <sipa> i don't think we should be waving 'experimental' as a label as a way to avoid responsibility in creating decent interfaces
19:10:12 <wumpus> we could disable it completely.
19:10:13 <sipa> it's there to indicate that changes are possible in the future
19:10:13 <gmaxwell> scantxoutset is marked expiremental in particular because the interface isn't stable.
19:10:32 <wumpus> just disable the methods, make PSBT entirely miss 0.17.0
19:10:35 <promag> rpc cycle experimental -> stable -> deprecated :P
19:10:56 <sipa> i think it's fine to release 0.17.0 as-is now
19:11:00 <wumpus> but only if you think releasing as-is is "avoiding responsibility"
19:11:08 <gmaxwell> wumpus: I don't see how doing that, in this case, would make anyone better off. I would agree if it was like "PSBT could surprise crash, or eat your coins" or whatnot.
19:11:26 <wumpus> gmaxwell: it was because of sipa's working
19:11:28 <wumpus> wording*
19:11:32 <luke-jr> [19:10:32] <wumpus> just disable the methods, make PSBT entirely miss 0.17.0 <-- IMO better to just delay 0.17 a bit
19:11:37 <gmaxwell> But in this case, it's just "this very specific sequence of actions in this specific use case just doesn't work"
19:11:46 <sipa> wumpus: no, i'm just a bit annoyed with the "we could always mark things experimental!" response to things that don't work - not specific to this issue
19:11:47 <achow101> I think 0.17 is fine to release as is
19:11:50 <sipa> this is minor enough
19:12:03 <wumpus> sipa: well it's quite common for software to have 'known issues' with releases
19:12:07 <morcos> we have a precedent of release notes with a Known Bugs section
19:12:11 <promag> luke-jr: remove features in RC?
19:12:13 <sipa> wumpus: right, that's far more honest :)
19:12:13 <morcos> damn i type too slow
19:12:19 <gmaxwell> yea, for this it's fine.
19:12:19 <wumpus> at some point ,a release needs to be cut, in spite of everything
19:12:41 <luke-jr> promag: not necessarily in general, but in this specific case
19:12:55 <gmaxwell> Sometimes a known issue is severe enough you need to disable the functionality, but not here. And expiremental isn't the right concept: it's not that PSBT is going to change its interface in an incompatible way, it just has some bugs.
19:12:57 <luke-jr> promag: no reason to rush 0.17, and fixing it shouldn't delay long
19:13:01 <wumpus> but I agree removing features should be left for when something is dangerously broken
19:13:35 <wumpus> but the fact that this discussion keeps coming back indicates to me that most people just want 0.17.0 out, for other reasons than PSBT
19:13:38 <promag> we want people to try it+, but in a responsible way, so experimental sounds fine to me
19:13:47 <gmaxwell> For use we're using expiremental to get functionality out when the remaining issue is some debate (or incompleteness) in the interface, and where we figure people are better off having it, even if the interface isn't stable yet.
19:14:20 <sipa> psbt is not experimental; its workflows or interfaces aren't changing, nor is there a security issue
19:14:22 <gmaxwell> because we found that we were delaying good features because "interfaces-are-forever".
19:14:36 <wumpus> right
19:14:40 <sipa> there's just a bug that prevents it from working in an edge case that can be worked around, which will be fixed soon
19:15:06 <gmaxwell> and 0.17 has a lot of fantastic improvements that people should get their hands on.
19:15:08 <earlz> What's the best way to privately report a security problem in bitcoin core?
19:15:10 <promag> sipa: experimental can also mean incomplete, or not entirely tested or finished?
19:15:28 <sipa> earlz: security@bitcoincore.org
19:15:29 <wumpus> earlz: gpg-signed mail to maintainers
19:15:40 <luke-jr> gpg encrypted, not signed.
19:15:44 <sipa> i care more about gpg-encrypted than signed :)
19:15:46 <earlz> Thanks
19:15:48 <wumpus> eh yes, sorry , encrypted
19:16:05 <gmaxwell> earlz: https://bitcoincore.org/en/contact/  has the info.
19:16:43 * luke-jr wonders if earlz's question should be considered in the context of the meeting topic
19:17:04 <gmaxwell> please don't discuss security issues on irc.
19:17:04 <wumpus> #topic Delete 0.10.* executables from bitcoincore.org
19:17:13 <MarcoFalke> Similar to how the branches were deleted from the GitHub git mirror (https://bitcoincore.org/en/meetings/2018/05/03/#delete-08-09-and-010-git-branches), we should delete executables that are long EOL.
19:17:17 <luke-jr> rather move than delete
19:17:18 <MarcoFalke> bitcoincore.org is mostly concerned about distributing working, tested and non-vulnerable software versions of Bitcoin Core. The site should not serve as an archive of binary blobs. Note that releases before 0.10.0 are already not offered as download on https://bitcoincore.org/bin/.
19:17:40 <wumpus> yes, would rather move to an "old_dont_use" directory
19:17:40 <gmaxwell> wumpus: it's really useful to have old executable archived somewhere. It's often hard to _build_ old versions because of @#$@ dependency changes.
19:17:57 <wumpus> gmaxwell: I agree
19:18:03 <wumpus> deleting isn't necssary, I think
19:18:11 <jonasschnelli> Agree
19:18:32 <MarcoFalke> Then, we should also put up the 0.8 and earlier versions?
19:18:46 <wumpus> we do!
19:18:52 <MarcoFalke> Oh I din't know
19:19:01 <luke-jr> https://bitcoincore.org/bin/insecure/ has back to 0.8.6
19:19:19 <luke-jr> …and copies of 0.10 it seems
19:19:26 <gmaxwell> probably anything that doesn't enforce all current consensus rules should be in a old_dont_use directory.
19:19:47 <sipa> so 0.13.1 ?
19:19:53 <wumpus> when bitcoincore.org started hosting executables I think I copied everything from bitcoin.org
19:20:28 <gmaxwell> sipa: has it been that long, ... I guess so.
19:20:41 <wumpus> ok with me
19:20:41 <sipa> nearly 2 years.
19:21:16 <MarcoFalke> Hmm https://bitcoincore.org/bin/bitcoin-core-0.10.4/ seems empty
19:21:35 <wumpus> MarcoFalke: yes, that version was never released
19:21:39 <MarcoFalke> But yeah, moving is fine if developers still use the binaries
19:21:52 <MarcoFalke> Oh I remember we had this chat
19:21:58 <luke-jr> FWIW, I do have various old versions archived on https://luke.dashjr.org/programs/bitcoin/files/bitcoind/
19:22:19 <wumpus> there was an rc for 0.10.4 at some point AFAIK that's why the directory exists
19:22:28 <MarcoFalke> Ah
19:22:32 <gmaxwell> in any case action is to move but don't delete old versions? and at least anything that isn't current with the current consensus rules?
19:22:40 <sdaftuar> 0.13 is past end-of-life, so i think it should be considered "old_dont_use" as well
19:22:55 <wumpus> gmaxwell: yes I think so
19:23:28 <wumpus> MarcoFalke: rcs for old releases used to be deleted because of disk space constraints on bitcoin.org, don't know if bitcoincore.org has the same problem
19:24:13 <gmaxwell> sdaftuar: also old don't use due to not having the crash fix.
19:25:13 <wumpus> isn't 0.14 the first release with the crash bug?
19:25:29 <sdaftuar> wumpus: yes
19:25:59 <wumpus> #topic Add GitHub pull request template (MarcoFalke)
19:26:12 <MarcoFalke> There are sometimes pull requests that do simple stylistic refactoring without obvious advantages to either users or developers. The GitHub pull request template would remind contributors that they need to provide clear rationale for these refactoring changes
19:26:26 <wumpus> yes please
19:26:32 <jnewbery> ACK
19:26:34 <sdaftuar> +1
19:26:37 <jamesob> +1. thoughts on test coverage requirements?
19:26:44 <cfields> and a benchmark if it's intended to be an optimization
19:26:47 <MarcoFalke> I'd just wanted to ask people to look at https://github.com/bitcoin/bitcoin/pull/14217
19:26:50 <MarcoFalke> and leave feedback
19:27:01 <sdaftuar> jamesob: i think it's always good to encourage PR openers and reviewers to ensure there's test coverage!
19:27:06 <gmaxwell> 12:26:44 < cfields> and a benchmark if it's intended to be an optimization
19:27:08 <MarcoFalke> jamesob: In the future, a bot could automatically close refactoring pull requests without rationale or missing test coverage.
19:27:11 <wumpus> cfields: right
19:27:20 <gmaxwell> I also worry about things that are intended to be 'cleanup' that make things slower.
19:27:34 <wumpus> #action review https://github.com/bitcoin/bitcoin/pull/14217
19:27:54 <MarcoFalke> At least we have some monitoring to detect obvious slowdowns after merge
19:28:02 <gmaxwell> See for example arvid's removal of INLINE that sipa commented on-- which actually seems to be okay, but its the sort of thing that could result in massive performance regressions.
19:28:05 <MarcoFalke> Though, would be good to get the signal before merge
19:28:19 <wumpus> gmaxwell: yes...
19:28:27 <gmaxwell> MarcoFalke: yes, but it looks like it wasn't running very frequently which also makes it hard to tell which commit(s) did it.
19:28:43 <gmaxwell> so perhaps my concern is best fixed by just improving the monitoring.
19:28:48 <MarcoFalke> It runs about once a day, but we had some downtime last month
19:28:54 <wumpus> that's another cleanup I really don't care for, for what it's worth
19:29:02 <jamesob> gmaxwell: bitcoinperf shouldn't be down that long again
19:29:05 <gmaxwell> OKAY
19:29:22 <gmaxwell> Would it be possible to get it to run on each PR merge even if it falls behind?
19:29:43 <MarcoFalke> The basic stuff for sure
19:29:43 <jamesob> that's a lotta compute, but it's something I'm thinking about - and will have time to work on after the next month or so
19:29:50 <MarcoFalke> IBD is the hardest
19:30:11 <wumpus> could at least check whether cpp/h files were changed !
19:30:33 <gmaxwell> I think it's silly for us to be bound on compute.
19:30:36 <wumpus> it seems completely unnecessary to run it after a documentation change
19:30:40 <sdaftuar> gmaxwell: agreed
19:30:58 <gmaxwell> indeed, skipping pointless changes is good... but ultimately if we need a rack of computers to keep up with it, we should be able to get that.
19:31:15 <wumpus> no one is stopping anyone from doing that, no :)
19:31:55 <sipa> consistent performance numbers do need identical hardware etc
19:31:58 <wumpus> could even run it on PRs
19:32:00 <sipa> if you want to parallellize
19:32:09 <wumpus> yes
19:32:21 <gmaxwell> In absence of someone doing it we probably shouldn't just keep a commit flux that we can't adequately test though, and checking for perf regressions is part of it.
19:32:24 <wumpus> it's kind of more expensive than what travis does, VMs would be useless for this
19:32:35 <gmaxwell> indeed.
19:33:42 <wumpus> in any case, I'm all for discouraging useless refactoring changes
19:33:52 <wumpus> it sometimes feels like I'm the only person pushing back against them
19:34:08 <jonasschnelli> no.. i'm with you
19:35:49 <wumpus> any other topics?
19:37:11 <wumpus> if not, I'm going to close the meeting and go to bed, need to get up very early tomorrow for my flight
19:37:12 <cfields> I'm back full-time, still catching up. Please ping me if you have anything that was waiting for me or that I should get to quickly.
19:37:19 <sipa> wumpus: safe travels
19:37:29 <wumpus> cfields: welcome back !
19:37:41 <jonasschnelli> cfields: great to hear!
19:37:47 <wumpus> sipa: thank you
19:38:00 <promag> cheers
19:38:12 <MarcoFalke> safe travels!
19:38:15 <luke-jr> cfields: I think I have at least one PR wumpus wanted you to look at, but no rush
19:39:05 <MarcoFalke> proposed action: end meeting
19:39:24 <promag> regarding practicalswift (are you here?), I think he should build something like bitcoinacks.com
19:39:24 <sipa> ack
19:39:35 <wumpus> #endmeeting