19:01:03 #startmeeting 19:01:03 Meeting started Thu Jul 28 19:01:03 2016 UTC. The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot. 19:01:03 Useful Commands: #action #agreed #help #info #idea #link #topic. 19:01:05 greetings 19:01:42 topc suggestions? 19:01:49 proposed topic eliminate ISM (NicolasDorier's #8391) 19:02:10 about to board flight.. 19:02:15 rc2 is very near being tagged, https://github.com/bitcoin/bitcoin/milestone/20, could use some extra review for https://github.com/bitcoin/bitcoin/pull/8408 19:02:40 but that's the only remaining pull tagged 0.13 left 19:02:48 wumpus: releadse notes still need to not recommend/opressure bad policy 19:03:08 luke-jr: ok 19:03:19 tag applicable pr pls 19:03:20 wumpus: shouldn't #8412 be in 0.13? 19:03:25 but I guess people don't agree on what 'bad policy' is 19:03:38 also about to board a flight in a bit 19:03:41 wumpus: … 19:03:50 luke-jr: don't elipises wumpus. 19:03:51 I think it should 19:03:57 (8412) 19:04:19 I'll tag it 19:04:20 in fact, I think it should go in 0.12.2 if there's going to be one 19:04:27 I'm fine with 8412, hadn't heard of it before 19:04:40 wumpus: yeah, just created it yesterday 19:04:47 8412 seems harmless and silly not to include 19:04:53 It's a inconsequence with no risk attached to it (IMO) 19:05:00 seems we agree 19:05:08 great 19:05:18 the current release nites recommends and undisputably bad policy. if there is controversy it shouldnt recommend anything 19:05:32 luke-jr: do you have a proposed update to the release notes? 19:05:37 RE 8412: why are we adding flags for long locked in network features? 19:05:59 sdaftuar: any clues where to poke at #8096? Do you still think that's a blocker for release, or calling it a fluke? 19:06:22 wumpus: yes, the pr is open for a week now 19:06:33 err.. sorry for topic drift. we can pick that up later. 19:06:36 what is the "bad policy"? what am I missing? 19:06:43 okay never mind, I didn't look at the patch initially, I thought it was GBT rather than libconsensus. 19:06:52 luke-jr: the only PR I know of also changes quite some code 19:06:55 https://github.com/bitcoin/bitcoin/pull/8388/ 19:07:05 Yes. Its not an release not only PR 19:07:12 luke-jr: i don't understand why we need to change anything now. segwit is not released. using blockmaxcost is fine for 0.13 19:07:17 s/not/note/ 19:07:26 jtimon: blockmaxweight rsther than blockmaxsize 19:07:27 uh, or weight 19:07:44 gmaxwell: thanks. :) 19:07:58 wumpus: because people were insisting the code had to change to remove the recommencaation 19:08:14 I think it's foolish that we're still releasing with settings that don't reflect the near ubiquitious network usage. 19:08:32 luke-jr: we shouldn't be relying on miners picking safe policy that only harms themselves 19:08:37 gmaxwell: on that note, agree with sipa that we should decouple the consensus flags bit poisitions from the script flags', but that's only for master 19:08:48 luke-jr: if we're not fine with larger blocks, we shouldn't do segwit as-is 19:09:02 sipa: agreed 19:09:15 where we is the big we 19:09:16 in practice, nearly every miner will set the max block size and weight to the maximum allowed value 19:09:22 morcos: yes! 19:09:40 sipa: we cannot stop segwit for better or worse 19:09:46 Asking miners to produce blocks smaller than the network technically allows is a failed policy, in nay case, as we've seen. The default has been 750k-- but go look at the chain, no 750k blocks to be seen. :P 19:09:48 and hopefully in some monthhs larger blocks WILL vbe fine 19:10:00 sipa: prqactice is tbd 19:10:01 luke-jr: 'fine' is not a boolean 19:10:27 i need to board… 19:10:41 gmaxwell: on the other hand, miners not dumbly using the default settings is great, it's exactly what should be happening 19:10:44 luke-jr: well nothing special will happen because you aren't here. :P go board, we can talk later. 19:10:45 i think it would be fine to include an explanation of the difference in the release notes without making a judgement about whether or not you should want to have blocks with size smaller than what might be created if you only limited by weight 19:10:54 bbl 19:11:49 the way I see it, the default is stupid to kind of force miners not to use the default (and to avoid being changing some defaults all the time) 19:11:57 if we don't recommend using size but explain why the option exists, then i also see no reason to cache size, if some people want to use it, its ok if its calc'ed on the fly (as current code does)_ 19:12:06 so the issue is that weight has a bigger default than size had? 19:12:10 jtimon: yes, I thought that was the point 19:12:30 jtimon: otherwise it's back to 'devs decide the values' 19:12:46 sorry I am late. #8412 should be included. 19:12:52 yeah, and people asking to increase op_return size and shit 19:13:20 IMO we should just make the defaults the maximums. Doing otherwise is thereatics, we know that users will immediately set them to the largest allowed values. And the few that wouldn't will happily manually reduce them. 19:13:52 re #8412 should I open the PR to 0.13 then? 19:13:54 this argument specifically applies to the 'max weight/size' things because we have expirence there with how they will be set in practice. 19:14:20 jtimon: 8412 will backport trivially, no need for backport PR 19:14:35 (also, FWIW, the income difference between 750k size and maximum is non-trivial). 19:15:29 no strong opinion, it seems natural to take the oportunity of moving from size to weight to change the default to something more used, but I will complain when somebody asks to change it later 19:15:34 I really don't like to go back to discussing what defaults to use, e.g. we've had tons of pull requests to change the default block size and we've always used the reasoning explained by jtimon to hold them off 19:15:40 but indeed, no strong opinion either 19:16:10 if we want to set a lower default to "force people" not to use defaults there, that's fine with me as well 19:16:31 the current 0.13 code does not change any defaults 19:16:36 wumpus: i suppose the confusion is that now that we have 2 options, its totally non-intuitive how to se tthem given they have non max defaults 19:16:46 sipa: then what's the problem again? 19:16:49 and the release notes explain the difference, and that only using weight is faster 19:16:54 yes, what is the problem then? 19:16:58 i think the code and notes in 0.13 are fine 19:17:46 The notes don't seem to inform me how to set it to the maximum. 19:18:07 which is what 99% of the users are going to want to do, as it's what they currently do. 19:18:21 ok, let's fix that in the --help message? 19:18:47 They won't read that. They'll read the release notes with greater odds than --help. 19:18:55 if it's what they currently do ,then why would the default even matter? they override it already. 19:18:57 (otherwise they wouldn't know of the maxweight option at all) 19:18:58 i assume they'll read neither 19:19:13 (Note that for mainnet, in this release, the equivalent parameter for -blockmaxweight would be four times the desired -blockmaxsize. See BIP 141 for additional details.) 19:19:16 you need to know how to set the limits to max, and also not have the code to unnecessary extra serialization 19:19:28 The default doesn't matter, except it forces people to override, which they'll likely get wrong now that it's been made more complicated. 19:19:59 in any case the help message and release notes should be clear, if they are missing information that needs to be added 19:20:22 E.g. you'll read that release note and then change your maxsize to maxweight, and then be surprised when their blocks are 250k. :P 19:20:43 why not just set it to the max? I can't see any reason why users would complain about that given that that is what they are going to do anyways 19:21:13 achow101: that was the argument I was making before. wumpus correctly notes that going and debating defaults again isn't great. 19:21:17 gmaxwell: ok, so you want to just clarify how to select the max block size in the --help because now it's more complicated than before and add something to the release notes? 19:21:30 In particular luke will go on a public attack campaign, and some are trying to avoid it. 19:21:42 because we should not be in the business of determining what values miners should use, we've always tried to avoid that, for good reason 19:21:47 (because he sees a kind of principled position arising from setting a more correct default which no one uses) 19:22:34 wumpus: not at question of should, it's a question of 'does', and forcing people to set settings which are now somewhat complex due to the new option is a bit unfortunate. 19:22:38 if you want to inform people how to set the maximum, then adding how to do so in the release notes makes sense 19:22:52 yes, I can make a PR that explains how to do that. 19:22:53 gmaxwell: we've been there; this really feels like deja vu 19:23:34 so to be clear: the current 0.13 defaults will cause miners to do something else than create 750kb blocks, as was the case for 0.12? 19:23:56 No, the defaults are functionally equal to 0.12's. 19:23:59 wumpus: no, that is not the case. 19:24:07 ok, good then 19:24:17 i think the release notes are accurate and relatively comprehensive enough right now. unfortunately, i think the logic that exists is complicated enough that miners will make mistakes and either create smaller blocks than they meant to or slow down their mining computation 19:24:32 the default maxweight is 3 million, which, with no witness txn is exactly equal to 750k maxsize. 19:24:43 I really don't understand luke-jr's issue if the defaults are untouched 19:25:03 i'm not sure what the solution to that is other than explaining exactly what you should do if you want to mine max size blocks, which might be seen as a recommendation 19:25:25 explaining in the release notes and documentation is exactly the right thing to do 19:25:29 jtimon: because a maxweight of 3m allows for a 3mb block in future versions with segwit activated and he doesn't want miners being instructed to use maxweight. 19:25:31 jtimon, theoretical size max would be 3MB I think 19:25:35 so people understand what is being done 19:25:50 instead of saying 'this is too complicated for you, just follow the defaults' 19:26:10 wumpus: 'just follow the defaults' was never my position. 19:26:31 gmaxwell: why do miners need to be instructed about maxweight before activation? (not that I'm against informing people beforehand) 19:26:43 Rather, we have defaults that match AFAICT what _no one_ wants, meaning that there is no one who can go "oh what the defaults want is already what I want, so I don't have to screw with anything." 19:26:50 gmaxwell: I know, but that's what would effectively happen if the defaults are just the maximum which everyone uses 19:26:52 gmaxwell: exactly 19:27:42 gmaxwell: people will start using the defaults, and be recommended using the defaults, which makes us in charge of determining the values. Next release there will be 20 pulls again of people that want to change the default to their favourite value, to lead others into using it 19:27:47 jtimon: they need to be informed because we kept blockmaxsize as an option, but it is slower to calculate (by unknown amount) 19:27:59 jtimon: because he believes its establishing a bad set of practices which will hold over. I think he's right that it will hold over.. but only slightly, people are also going to immediately crank to maximum. I think luke realizes this too, but is adopting a principled position of not supporting something he thinks is bad even if it is inevitable. 19:28:00 ok, so imagining what most are doing and assuming they don't touch their configuration for now and don't do anything about weigh (ie use the default), everything will be fine, right? 19:28:16 And he think it is bad until compactblock deployment has proven that miners producing larger blocks is okay. 19:28:16 morcos: I see 19:28:18 hence, I really think defaults discussion is a waste of time, it just creates more of the same 19:29:08 instead we get worse discussions because we have setting which actively trip up users. 19:29:08 i think we can just leave defaults as they are now 19:29:21 Sorry, wumpus, the software doesn't exist to save us from discussion, it exists to serve its users. 19:29:28 that's what we've learned from previous messing around with defaults, I don't understand why you've certainly changed your mind about this 19:29:28 I agree that we can leave them. 19:29:31 ack for leaving as-is 19:29:45 mhmm, if they were creating bigger blocks, they will keep doing so, and if they were using the default, they will keep doing so 19:29:57 But we need instructions for setting them to maximum, because as is people will screw it up and produce 250k blocks (and if you care about complaining: they'll accuse us of being sneaky) 19:30:08 gmaxwell: where did I claim that the software exists to save us from discussion!?? 19:30:14 gmaxwell: wtf is this 19:30:16 if they move to weigh because it's cheaper but still use the default, the size is the same 19:30:19 I think the lesson to be learned here is we make the code too complicated by trying to be all things to all people. For policy (not consensus) related decisions, i don't think we need to be able to support every possible thing. We waste so much time trying to shoehorn in things like priority and maxsize, while simultaneously trying to make the code more efficient 19:30:31 agree 19:31:33 wumpus: I'm sorry, thats what I'm reading out of your position on the defaults. I feel like you're basically arguing that we should have setting we know are bad and don't match usage, because it allows to refuse to discuss the defaults. 19:31:52 Well, you could always just make the mining part refuse to function unless the user manually sets the required config values :P 19:31:55 I think thats an argument that we should make the software objectively worse in order to avoid debates over what is better. 19:32:04 I apologize for reading so much into it. 19:32:06 as in, no dfaults 19:32:17 anyway, it seems this is mostly an issue for luke-jr, so I don't see the point in keeping discussing it while he is on a plane 19:32:25 Eliel_: it's not very user friendly though 19:32:30 how about we leave things as is, and in the future (whenever that may be) we find a way to simplify the options (back to one argument, for example) 19:32:40 ACK simplifying in the future 19:32:45 sipa: i think thats the best we're going to get at this point 19:32:47 that can 1) solve the problem of inadvisable defaults 19:32:49 But we really do need to have instructions on doing what people will do. And when we write those luke will complain because it will be arguable that we are endorsing those settings. Cannot escape the drama. :) 19:33:07 Eliel_: yes, that has been suggested before 19:33:19 and 2) by changing things at the same time as simplifying the logic, it is not necessarily a recommendation 19:33:21 gmaxwell: just tell him to suck it up and deal with it 19:33:22 achow101: that depends... if the error message comes with a link to a good instructional document, it might actually be a pretty good result. 19:33:36 luke only insisted we have the size option because compactblocks is not yet deployed, and if relay network isn't working, orphaning is highly related to size. 19:33:46 It didn't seem like it was worth debating. 19:33:52 gmaxwell: i'd argue we can leave the release notes as is (which luke might still object to) and then just use other channels to explain to people very simply how they can create max blocks if they want. simple. set -blockmaxweight=4000000 and dont' set blockmaxsize at all 19:33:57 Eliel_: it may be better than setting silly defaults, but there was never agreement to do it 19:34:09 morcos: I can agree with that too. 19:34:24 gmaxwell: maybe overkill instructions with all the options (keep using the default in a more efficient way (ie not using maxsize) and do what most poeple do) is enough for luke-jr? 19:34:26 wumpus: that's pretty much my reasoning behind the suggestion. 19:34:41 if you can't set defaults the way most people want them, don't set any. 19:34:51 I'm also fine with that suggestion 19:35:04 luke argued for that for years. 19:35:11 and about user friendliness... do you really want to allow people to mine without understanding what they're doing? 19:35:15 Eliel_: the thing is that people disagree deeply over these setings 19:35:26 other topics? 19:36:02 #topic eliminate ISM (NicolasDorier's #8391) 19:36:11 Eliel_: absolutely. 19:36:51 Eliel_: participants in the network should be avoiding judgement, they're not in charge of the system because they participate.. and not because they have some theoretical technical ability to censor varrious behaviors. 19:37:04 i need to leave. i would like to request that folks send me topic suggestions for my wishlist for the upcoming gathering. not end of the world if it doesn't happen, but having a few thoughts prepared is worthwhile. 19:37:37 ping jtimon 19:37:43 this is quite important for other libconsensus refactors, the sooner it is merged the easy it will be to PR other changes, I would really appreciate fast review, test and merge of #8391 19:38:18 I would say it's the most important libconsensus' PR opened right now 19:38:32 I think we already agreed removing ISM was a good thing lastm eeting, is there more to discuss about it? 19:39:03 wumpus: well, I hope not, but that's why I bring it up (apart from asking for review) 19:39:21 yes it does need more review/testing 19:39:27 #action review https://github.com/bitcoin/bitcoin/pull/8391 19:39:40 thanks 19:39:42 next topic suggestion: boost threads/sync replacement for master 19:40:01 #topic boost threads/sync replacement for master 19:40:11 and of course nacks and nits always the sooner the better 19:40:16 https://github.com/bitcoin/bitcoin/pull/8023 19:40:27 is nowish a good time to start pushing for that? 19:40:37 sounds good to me 19:41:18 neat. 19:41:20 ok. it's a drop-in replacement for interruptible boost threads/condvars. preferred to switch chunks at a time, or all in one go? 19:41:26 cfields: since it's disruptive, the "refactor window" seems like the perfect time for it, no? 19:41:31 what about your network refactor? seems we should start merging for that as well? 19:42:11 cfields: what would 'chunks at a time' mean, using two potentially conflicting thread libraries? 19:42:11 wumpus: yea, review/acks of 2 outstanding PRs would be a big help... 19:42:17 oh, #8023 is not disruptive at all 19:42:23 sec for numbers 19:42:29 cfields: can you post the links? ok 19:42:58 I'm back. 19:43:03 for removing ISM 19:43:04 welcome back 19:43:10 I synched nodes successfully 19:43:20 so basically, it needs some review from other people, but should be good 19:43:27 #8128 and #8085 19:43:51 NicolasDorier: ok I'll run a full sync this weekend 19:43:52 #action review+test https://github.com/bitcoin/bitcoin/pull/8128 Net: Turn net structures into dumb storage classes 19:44:03 #8085 is a beast to rebase. I have it done locally, but I'm waiting for #8128 to go in before rebasing again and pushing 19:44:10 i tried switching some subset of the code to std::thread before, and it was impossible... you need to change it everywhere at once 19:44:24 #action review+test https://github.com/bitcoin/bitcoin/pull/8085 p2p: Begin encapsulation 19:44:54 ok, I'll approach it as one big change then 19:45:11 yes it probably makes most sense to do it all as once, it's painful but at least it should be a one time pain then 19:46:24 question: what you call "refactor windows" what is it ? 19:46:31 ok. iirc there are 1/2 pre-reqs left for boost-specific usage, then basically a search/replace. I'll go back through my notes and do pulls for the pre-reqs. 19:47:52 NicolasDorier: well the best time for larger changes in 0.14 is now, as there's still some months to go before the release and there is enough time to address problems that come up 19:48:16 e.g. you wouldn't want to switch the thread library a few days before release 19:48:25 ok nice to know, as I'm working around libconsensus... will go a bit quicker so 19:48:49 oh 19:49:29 about https://github.com/bitcoin/bitcoin/pull/8259 when will it be merged for 0.13 ? 19:49:47 re ISM (sorry for not saying it earlier), thoughts on https://github.com/jtimon/bitcoin/commit/273e27bd0c086f5ba20cebc2f5ec9e24f9d79015 ? independently on adding it to the PR or leave it for later 19:49:51 NicolasDorier: we'll need to backport that to 0.13 before segwit 19:50:03 ok 19:51:01 NicolasDorier: it's not even merged for master yet, after it is it can be backported 19:51:37 I'll add a "needs backport" label 19:51:50 ok no prob 19:52:03 NicolasDorier: thanks for the reminder on that btw 19:52:13 seems to need some more review too 19:52:29 jtimon: I'd like to see it go personally, but I don't know the reason why bip34Hash was here in the first place 19:52:50 jtimon: i vaguely remember there were ugly interactions between the cache code that avoids some database operation, bip30 and bip34... but i don't remember the details 19:52:53 #action review https://github.com/bitcoin/bitcoin/pull/8259 Hash Cache 19:53:14 uff, #8259 is ultra disruptive to consensus branch, should review... 19:53:46 jtimon: yes, I was asking because as part of our work on libconsensus, we'll need to be fixed on that 19:54:21 yep, you agreed on #8346 first, right? 19:54:46 jtimon: 8259 will need backport to 0.13 19:55:03 yes 19:56:07 ok, any final topics? 19:57:01 sipa: damm, and #8346 cannot be backported because it's a refactor, "refactor winwow interlocking", before a release it's really the worse time to make refactors, but I repeated this many times... 19:57:18 no, refactors will not be backported, that is too risky 19:58:02 wumpus: then having the "refactor window" precisely when we're backporting more stuff is a bad idea 19:58:03 it's fine, we'll find a solution for that 19:58:05 well wait until after the release then jtimon 19:58:19 hopefully rc2 will be the last 19:58:34 that'd mean the release can be next week or so 19:58:48 wumpus: if that still counts as "refactor window" I'm happy, I know when they start but I don't have a clear idea on when they finish 19:58:59 wumpus: the issue is that 8346 won't be backported to 0.13, but 8259 will be, thus 8259 can't be based on that refactor 19:59:31 but i don't think it's a big issue 19:59:32 sipa: yes, moving the refactor window to after the 0.13.0 release won't help for that 19:59:53 sometimes code needs non-trivial backports 19:59:55 so be it 19:59:58 yes 20:00:08 it's still trivial compared to backporting to 0.12 20:00:23 DOING 20:00:26 #endmeeting