19:02:24 #startmeeting 19:02:24 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 Useful Commands: #action #agreed #help #info #idea #link #topic. 19:02:24 I think anyone can be the host that knows the commands for the meeting bot? 19:02:29 ah 19:02:46 #topic 0.17.0 19:02:50 Hi 19:03:29 I think two of the issues in the milestone are just release-notes related 19:03:39 anything specific you want to discuss about it? 19:03:57 correct, the only real still-open issue is achow101 's PR 19:04:01 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 yes,agree 19:04:44 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 hi 19:05:49 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 it just happened to be the first thing i tried 19:06:14 I think it's like _the_ obvious workflow... if you happen to be using embedded segwit. :P 19:06:36 so, all in all it depends on why people want to upgrade to 0.17.0 19:06:40 Can we provide workaround instructions that have people import the redeemscript? 19:06:40 we just released 0.16.3; is there a reason to rush 0.17 now? 19:06:49 if a properly working PSBT is very important, we should delay the release for it 19:06:52 people who really want it can always use a rc 19:06:55 gmaxwell: or another roundtrip; i'll write up a workaround 19:07:00 luke-jr: It's 0.1 higher. 19:07:09 if PSBT is seen as an curious experimental feature, then not so much 19:07:16 Since PSBT is new I don't think it's important if it works at all. 19:07:18 I don't have a clear perspective on that 19:07:19 gmaxwell: it's 0.7 higher :) 19:07:24 gmaxwell: i agree with that 19:08:08 i also would rather document the shortcomings of PSBT and proceed with the release. 19:08:09 I think it is fine to release as is and do the fix for .1 later 19:08:15 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 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 this is fairly edge case imo 19:08:44 so action: Merge release notes? 19:09:06 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 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 make it experimental like scantxoutset? 19:09:45 right, PSBT is bound to have more problems that will come up when other users start using it 19:09:52 I don't think it needs to be marked more expiremental. 19:09:54 there will likely need to be a 0.17.1 for other reasons 19:10:01 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 we could disable it completely. 19:10:13 it's there to indicate that changes are possible in the future 19:10:13 scantxoutset is marked expiremental in particular because the interface isn't stable. 19:10:32 just disable the methods, make PSBT entirely miss 0.17.0 19:10:35 rpc cycle experimental -> stable -> deprecated :P 19:10:56 i think it's fine to release 0.17.0 as-is now 19:11:00 but only if you think releasing as-is is "avoiding responsibility" 19:11:08 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 gmaxwell: it was because of sipa's working 19:11:28 wording* 19:11:32 [19:10:32] just disable the methods, make PSBT entirely miss 0.17.0 <-- IMO better to just delay 0.17 a bit 19:11:37 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 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 I think 0.17 is fine to release as is 19:11:50 this is minor enough 19:12:03 sipa: well it's quite common for software to have 'known issues' with releases 19:12:07 we have a precedent of release notes with a Known Bugs section 19:12:11 luke-jr: remove features in RC? 19:12:13 wumpus: right, that's far more honest :) 19:12:13 damn i type too slow 19:12:19 yea, for this it's fine. 19:12:19 at some point ,a release needs to be cut, in spite of everything 19:12:41 promag: not necessarily in general, but in this specific case 19:12:55 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 promag: no reason to rush 0.17, and fixing it shouldn't delay long 19:13:01 but I agree removing features should be left for when something is dangerously broken 19:13:35 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 we want people to try it+, but in a responsible way, so experimental sounds fine to me 19:13:47 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 psbt is not experimental; its workflows or interfaces aren't changing, nor is there a security issue 19:14:22 because we found that we were delaying good features because "interfaces-are-forever". 19:14:36 right 19:14:40 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 and 0.17 has a lot of fantastic improvements that people should get their hands on. 19:15:08 What's the best way to privately report a security problem in bitcoin core? 19:15:10 sipa: experimental can also mean incomplete, or not entirely tested or finished? 19:15:28 earlz: security@bitcoincore.org 19:15:29 earlz: gpg-signed mail to maintainers 19:15:40 gpg encrypted, not signed. 19:15:44 i care more about gpg-encrypted than signed :) 19:15:46 Thanks 19:15:48 eh yes, sorry , encrypted 19:16:05 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 please don't discuss security issues on irc. 19:17:04 #topic Delete 0.10.* executables from bitcoincore.org 19:17:13 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 rather move than delete 19:17:18 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 yes, would rather move to an "old_dont_use" directory 19:17:40 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 gmaxwell: I agree 19:18:03 deleting isn't necssary, I think 19:18:11 Agree 19:18:32 Then, we should also put up the 0.8 and earlier versions? 19:18:46 we do! 19:18:52 Oh I din't know 19:19:01 https://bitcoincore.org/bin/insecure/ has back to 0.8.6 19:19:19 …and copies of 0.10 it seems 19:19:26 probably anything that doesn't enforce all current consensus rules should be in a old_dont_use directory. 19:19:47 so 0.13.1 ? 19:19:53 when bitcoincore.org started hosting executables I think I copied everything from bitcoin.org 19:20:28 sipa: has it been that long, ... I guess so. 19:20:41 ok with me 19:20:41 nearly 2 years. 19:21:16 Hmm https://bitcoincore.org/bin/bitcoin-core-0.10.4/ seems empty 19:21:35 MarcoFalke: yes, that version was never released 19:21:39 But yeah, moving is fine if developers still use the binaries 19:21:52 Oh I remember we had this chat 19:21:58 FWIW, I do have various old versions archived on https://luke.dashjr.org/programs/bitcoin/files/bitcoind/ 19:22:19 there was an rc for 0.10.4 at some point AFAIK that's why the directory exists 19:22:28 Ah 19:22:32 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 0.13 is past end-of-life, so i think it should be considered "old_dont_use" as well 19:22:55 gmaxwell: yes I think so 19:23:28 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 sdaftuar: also old don't use due to not having the crash fix. 19:25:13 isn't 0.14 the first release with the crash bug? 19:25:29 wumpus: yes 19:25:59 #topic Add GitHub pull request template (MarcoFalke) 19:26:12 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 yes please 19:26:32 ACK 19:26:34 +1 19:26:37 +1. thoughts on test coverage requirements? 19:26:44 and a benchmark if it's intended to be an optimization 19:26:47 I'd just wanted to ask people to look at https://github.com/bitcoin/bitcoin/pull/14217 19:26:50 and leave feedback 19:27:01 jamesob: i think it's always good to encourage PR openers and reviewers to ensure there's test coverage! 19:27:06 12:26:44 < cfields> and a benchmark if it's intended to be an optimization 19:27:08 jamesob: In the future, a bot could automatically close refactoring pull requests without rationale or missing test coverage. 19:27:11 cfields: right 19:27:20 I also worry about things that are intended to be 'cleanup' that make things slower. 19:27:34 #action review https://github.com/bitcoin/bitcoin/pull/14217 19:27:54 At least we have some monitoring to detect obvious slowdowns after merge 19:28:02 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 Though, would be good to get the signal before merge 19:28:19 gmaxwell: yes... 19:28:27 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 so perhaps my concern is best fixed by just improving the monitoring. 19:28:48 It runs about once a day, but we had some downtime last month 19:28:54 that's another cleanup I really don't care for, for what it's worth 19:29:02 gmaxwell: bitcoinperf shouldn't be down that long again 19:29:05 OKAY 19:29:22 Would it be possible to get it to run on each PR merge even if it falls behind? 19:29:43 The basic stuff for sure 19:29:43 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 IBD is the hardest 19:30:11 could at least check whether cpp/h files were changed ! 19:30:33 I think it's silly for us to be bound on compute. 19:30:36 it seems completely unnecessary to run it after a documentation change 19:30:40 gmaxwell: agreed 19:30:58 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 no one is stopping anyone from doing that, no :) 19:31:55 consistent performance numbers do need identical hardware etc 19:31:58 could even run it on PRs 19:32:00 if you want to parallellize 19:32:09 yes 19:32:21 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 it's kind of more expensive than what travis does, VMs would be useless for this 19:32:35 indeed. 19:33:42 in any case, I'm all for discouraging useless refactoring changes 19:33:52 it sometimes feels like I'm the only person pushing back against them 19:34:08 no.. i'm with you 19:35:49 any other topics? 19:37:11 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 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 wumpus: safe travels 19:37:29 cfields: welcome back ! 19:37:41 cfields: great to hear! 19:37:47 sipa: thank you 19:38:00 cheers 19:38:12 safe travels! 19:38:15 cfields: I think I have at least one PR wumpus wanted you to look at, but no rush 19:39:05 proposed action: end meeting 19:39:24 regarding practicalswift (are you here?), I think he should build something like bitcoinacks.com 19:39:24 ack 19:39:35 #endmeeting