19:00:37 #startmeeting 19:00:37 Meeting started Thu Mar 17 19:00:37 2016 UTC. The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot. 19:00:37 Useful Commands: #action #agreed #help #info #idea #link #topic. 19:00:47 ohai 19:01:17 ok, that will be first morcos, anyone else with topic suggestions? 19:02:12 we had an action item last time to review the backports for r BIP68 and 112 19:02:36 #topic c: Scheduling the first BIP 9 sort fork for BIPs 68, 112, 113 19:02:44 that wasn't the whole topic 19:02:57 i think merging is an action item, not a topic :) 19:03:19 how happy is everyone with 7575? 19:03:25 * sipa happy 19:03:28 +1 19:03:29 well if you want to discuss 7575 that's fine with me too 19:03:32 * btcdrak happy 19:04:00 wumpus: well its the blocker on the schedule 19:04:04 #action merge #7575 19:04:06 i'm happy with it as well 19:04:47 ok so then we just need to adequately review the backports, and we can discuss release? 19:04:57 what is the start date? is april 1st too soon? 19:05:00 I see it got a lot of new acks last day 19:05:24 thanks to all of sdaftuar's tests :) 19:05:31 i had suggested that the backports be put all together in 1 PR, but i'm not sure thats actually what you guys would prefer. although i think thats the safest way to test them. 19:05:43 (well 1 pr for 0.11 and 1 for 0.12) 19:05:52 +1 19:05:58 the moment miners uograde to a release with 7575 in it, the warning.logic will trigger on old nodes 19:06:01 Assuming 7575 is merged, the softfork deployment code is in #7648. morcos and I have backported the mempool stuff 19:06:04 morcos: I think it makes sense - you can always separate out commits 19:06:21 even if it only has softforks with a start time in the guture 19:06:25 future 19:06:42 so we shouldn't put it too far in the future 19:06:52 btcdrak: so will you create a pull that backports it all together for 0.12 (including 7575) and i'll do for 0.11 19:06:55 wumpus: the mempool backports are all done, they only need verification that the cherry-picks are correct 19:07:07 okay, good 19:07:08 morcos: ok 19:07:58 who has reviewed https://github.com/bitcoin/bitcoin/pull/7648? 19:08:40 no one yet, I think 19:08:42 this is built on #7575 and has additional RPC tests that exercise the BIP9 softfork process and the BIP enforcements for 68,112 and 113 19:08:44 i think we should announce the start date and bit number on the -dev list as soon as we've agreed on it, so that Classic and other implementations can implement it as well 19:09:22 btcdrak: It probably better reviewable after 7575 is merged 19:09:39 +1 19:09:39 #action review #7648 after #7575 is merged 19:09:39 the final version of the versionbits BIP should similarly be announced i think? 19:09:39 I'll rebase 7648 after 7575 is merged 19:10:03 I think we don't need to announce the merge,.. but the release/deployment. 19:10:07 back in 3 mins 19:11:28 yes the start date and bit number certainly needs to be announced 19:11:48 wumpus: and we need to plan the release date to be able to set the start date. 19:12:35 wumpus: morcos and I will have the backport PRs ready to go for 0.12 and 0.11. We've done most of the work already. 19:12:49 great! 19:13:08 release date is not entirely predictable, we do want a RC cycle 19:13:16 really, the only holdup is review of #7648. Once that's merged final, the backports are as good as done. They'd only need to be verified for correctness. 19:13:24 maybe set the date to may 1st? 19:13:27 I'd suggest moving the start date to April 15th 19:13:28 oh 19:13:29 ok 19:13:38 may 1st sounds good to me 19:14:12 is that the start date for BIP9? 19:14:17 better to leave some time for issues, which will always arise 19:14:33 so BIP 9 itself is up to date in the BIP repo, I guess that's what matters most for other implementations, not our code readiness 19:14:46 others may not be aware of that though 19:14:57 as it's been in flux until recently 19:15:24 I'm happy to send the follow up to my original email with these announcements. Perhaps we should update BIP's 68,112,113 with the soft fork info 19:15:34 we want to announce out intention to go ahead with a deployment based on bip9, for 68/112/113, with a given start date 19:15:34 morcos: BIP9 text is uptodate with the implementation 19:15:52 good point about updating BIP68/112/113 19:16:02 yes 19:16:03 OK I'll do that 19:16:25 so is the BIP9 start date May 1st? 19:16:47 btcdrak: that language is confusing. the date for the first BIP9 soft fork is May 1st 19:16:49 May 1st is the startdate for the CSV deployment 19:16:53 yep 19:16:56 (or whatever we're calling it) 19:17:20 once we have code running anywhere in production with a given start date, that date cannot be postponed anymore 19:17:27 or there is a fork risk 19:17:31 CSV deployment makes sense to me, it captures most of it, perhaps it would be helpful to add a comment next to the deployment, which BIPS it implements 19:17:37 moving the start time back is possible 19:17:45 yeah, it's already called CSV deployment in the code. 19:18:39 ok, so aim is may 1st 19:18:41 ok so action point is update BIP68/112/113 deployment section 19:18:58 let's make sure to review everything necessary as soon as possible so that it can be merged as soon as possible and we can do the release as soon as possible 19:18:58 I think it makes sense to include that we Bitcoin Core will have a release well in advance of the start date implementing the fork 19:19:36 regarding choosing the bit, I guess bit 0 makes sense. 19:19:53 just please don't choose bit 28 19:20:09 or 13 :) 19:20:19 The Chinese like 8 19:20:20 ha 19:20:44 but yes it makes sense just to allocate 0 19:21:09 easier to keep track if they're simply dealt out in order 19:21:22 what is the block number classic uses? 19:21:57 BIP109 uses one of the top 3 ::sigh:: 19:22:19 https://github.com/bitcoinclassic/bitcoinclassic/blob/develop/src/primitives/block.h#L13 19:22:32 top bit 010, so it's not actually part of the BIP9 spec 19:23:23 btcdrak: huh, it looks like they use 001 and then use bit 28 to signal their hard fork 19:23:37 yup 19:23:41 TESTDUMMY! 19:23:42 er 19:23:49 ;-) 19:23:51 so that works out fine then? 19:23:51 bwahahaha 19:23:55 hehehe 19:23:55 yes 19:23:58 sdaftuar: thats what i'm hoping you'll answer 19:24:20 it should, i think 19:24:24 i think so too 19:25:09 TESTDUMMY is a past deployment, in 2008 so no problem. 19:25:13 ok, let's try to be sure about that before committing to one 19:25:37 jonasschnelli: so we'd like to get that listunspent abandon flag in for 0.12.1 too (but not the gui changes)... 19:25:42 wumpus: it's fine. TESTDUMMY timeout is December 31, 2008 19:25:48 morcos: opening PR in 30secs. 19:25:50 topic: anything else needed for 0.12.1 ? 19:26:08 What about the GUI warning capabilities for 0.12.1? 19:26:15 https://github.com/bitcoin/bitcoin/pull/7579 19:26:18 if it's going to be a softfork release, there shouldn't be much else in 0.12.1 19:26:28 yeah let's keep it small 19:26:31 I'm not entierly happy with 7579,... but could be a small step. 19:26:47 postpone 7579 19:26:57 2008? well, let's get into our deloreans 19:27:11 sorry, late, reading, super happy with bip9 19:27:36 jonasschnelli: oh, i'm glad you pointed me to that PR, i didn't know about it, and was separately going to rework warnings. we should fix them for rpc and gui at the same time. so yeah not for 0.12.1 19:27:57 7579 aims for a simple change that is BP compatibile. 19:28:01 let's leave that to 0.12.2 19:28:07 It does not prevent the whole rework. 19:28:11 focus on the softfork 19:28:16 +1 19:28:20 wumpus: +1 19:28:40 anything that is also required will unpredictably affect the release date 19:28:42 The internal warning system was always bad. So no hurry. :) 19:28:47 yea... 19:29:17 jonasschnelli: I do like 7579 btw 19:29:34 wumpus: right, so lets review 7706 and jonasschnelli's pull that is now 2 mins overdue as well, b/c i think we need those 19:31:06 which one? 19:31:21 (the flag for abandontransaction in listunspent) 19:31:29 we probably need a new #topic, we've strayed off the original topic 19:31:41 well its all related to getting 0.12.1 released 19:31:47 oh that makes sense, probably a few line change with no impoact outside listunspent 19:31:56 https://github.com/bitcoin/bitcoin/pull/7707 (not 7706!) 19:31:58 [13bitcoin] 15jonasschnelli opened pull request #7707: [RPC][QT] UI support for abandoned transactions (06master...062016/03/abandon_ui) 02https://github.com/bitcoin/bitcoin/pull/7707 19:32:07 jonasschnelli: yeah, mine is 7706, we need both 19:32:08 morcos: but the topic was "Scheduling the first BIP 9 sort fork for BIPs 68, 112, 113" 19:32:20 i think we should get dgenr8's partition detection improvement reviewed for 0.12.1 19:32:28 morcos: Ah. Right. 19:32:45 ok, now everyone wants their favorite thing in 0.12.1 19:32:46 sipa: PR URL? 19:32:46 sipa: oh, i like that idea. thats the most effective way to fix the poor situation with the warnings 19:32:47 I was trying to avoid this 19:32:52 and focus on the softfork 19:33:11 wumpus: well lets see if the list we come up wiht in the next 5 mins is reasonable 19:33:21 we don't have to keep adding stuff for the next week 19:33:58 improving the partition warnings would be a great help, because it's currently a _disaster_ 19:34:00 dgenr8 partition check PR: https://github.com/bitcoin/bitcoin/pull/7568/files 19:34:14 minimum risk would be to release 0.12.0 + only softfork backports 19:34:48 but I agree if there are critical bugfixes they should be in too 19:34:57 I agree. 0.13 Release is 2016-07-01 19:35:04 yes 19:35:06 wumpus: i think the conflict detection issue is potentially large. i'm kind of surprised we haven't seen more complaints about it. i guess people might not rely on unconfirmed balance too much 19:35:06 (so not so far away) 19:35:08 if we don't fix the partition warnings, we should disable them. maintaining the system longer in the current state will just make people ignore them 19:35:21 sipa: +1 19:35:33 I agree sipa and morcos 19:35:37 sipa: have you reviewed the partition PR 19:35:38 so let's fix those 19:35:39 no more 19:36:47 but the softfork is still priority #1 19:37:46 ok 19:38:28 #action for 0.12.1, apart from softfork: fix partition warnings (review #7568), conflict detection issue (#7706) 19:39:06 morcos: only the concept; i'll review the code too 19:39:45 jonasschnelli: we probably want a RPC-only #7707 for 0.12.1 19:40:01 yep, its one line of code. : ) 19:40:06 heh 19:40:09 wumpus: Agree. You could cherry pick or tell me if i should open a RPC-only PR against 0.12 19:40:37 jonasschnelli: oh it's one line, I'll manage :) 19:40:46 +1 19:41:10 Is a independent commit: 42e945d79fd54ab11ad48978910b42d10c1c7cf8 19:41:24 i marked 7706 as WIP, but i just want to flesh out the tests. but wouldn't mind somoene else to think about whether its doing the right thing 19:41:25 #action for 0.12.1, #7707 (: 42e945d79fd54ab11ad48978910b42d10c1c7cf8 only) 19:41:55 wumpus: ACK on just using bits in order 19:44:13 that concludes the topic, I think 19:44:20 topic prop.: state of SW 19:44:35 #topic state of SW 19:45:00 * jonasschnelli thinks is rude to look at sipa now... 19:45:01 i'm working on the post-fork upgrade problem in the current segnet code 19:45:19 morcos: the right bit to signal hardforks is the one that helps old nodes declare the first hardfork block invalid. see outdated https://github.com/bitcoin/bitcoin/pull/7566/commits/990dda87b258c1e8d4d35b1fcbae4106303664f0 19:45:21 next thing after that is rebase on top of versionbitd and do a new segnet 19:45:49 sipa: new segnet or testnet? 19:45:59 samesame? 19:46:14 new segnet 19:46:29 though we can independently test on testnet too, of course 19:47:20 Are we aiming SW for 0.13.1? 19:47:52 i'm aiming for SW in 0.11.something, 0.12.something, 0 19:47:55 0.13 19:48:14 it's a softfork, we'll need to backport 19:48:20 btcdrak: btw, you should make the start date for CSV deployment earlier on testnet. we didn't talk about that. but any reason not to make the start date march 1st? 19:48:34 sipa: Agree. Just on the "timeline". 19:48:45 jonasschnelli: "soon" 19:48:57 I love that "soon". :) 19:50:10 I'm just asking because some Core Devs did agree a timeline for SW on a a miners/devs/etc. meeting. 19:50:19 *agree on a timeline 19:50:31 morcos: ok 19:51:04 jonasschnelli: i don't care what some people think; a timeline is something you can't promise 19:51:12 but we can do our best 19:51:18 good to watch that timeline but most important is that we don't deploy before it's ready, quality shouldn't suffer under time pressure 19:51:19 sipa: fully agree. 19:51:36 sipa: that's fine, so long as we communicate how things are going, that's good enough. 19:51:42 worst outcome would be to be scared into delivering something that breaks 19:51:48 btcdrak: yes. We just need to communicate. 19:51:50 yes 19:52:21 Lets just say "soon". :) 19:52:39 i'm glad bip9 seems final 19:52:45 me too 19:52:59 Yes. Finally. 19:53:07 sipa: party at your house. we'll bring the beers. 19:53:13 I think that concludes the meeting? 19:53:44 btcdrak finally de-anonymizes at the party. 19:53:48 #endmeeting