19:02:17 #startmeeting 19:02:17 Meeting started Thu Oct 12 19:02:17 2017 UTC. The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot. 19:02:17 Useful Commands: #action #agreed #help #info #idea #link #topic. 19:02:22 before we officially start, does anyone mind if I collapse the fixups in #11383 ? 19:02:24 https://github.com/bitcoin/bitcoin/issues/11383 | Basic Multiwallet GUI support by luke-jr · Pull Request #11383 · bitcoin/bitcoin · GitHub 19:02:40 #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 19:02:47 hi. 19:03:02 hi 19:03:26 luke-jr: probably best to do that just before merge 19:03:34 suggested topics: backdating segwit/p2sh 19:03:37 suggested topics: segwit wallet 19:03:51 suggested topics: pre-2x release (possibly with no segwit wallet)? 19:04:05 #topic Backdating segwit/p2sh (BlueMatt) 19:04:15 * BlueMatt nominates sdaftuar/sipa/jl2012 to talk 19:04:15 i guess matt wants me to talk about this one 19:04:24 * sipa listens 19:04:32 hi 19:04:55 Hello 19:05:17 I am pro backdating but wasn't sure how we should handle the rollback and replay. Rolling back the whole chain would be unfortunate. :P 19:05:20 in thinking about p2sh and segwit, they both have the property that it doesn't make sense to ever accept blocks that violate those rules 19:05:41 in the case of p2sh, there was only one historical block that violated SCRIPT_VERIFY_P2SH 19:05:47 I think backdating segwit is not trivial because the inclusion of witness commitment pre-fork 19:05:56 in the case of segwit, no blocks have ever violated the segwit scritp flag SCRIPT_VERIFY_WITNESS 19:06:13 jl2012: I thought all the prefork ones were valid. 19:06:15 but of course, the witness commitment validation rules don't really work for backdating 19:06:27 backdating to when? to the beginning of the chain? 19:06:27 gmaxwell: i don't think that is true, though i didn't verify myself 19:06:30 wumpus: yes 19:06:42 interesting 19:06:42 jl2012: i checked the pre-activation commitments on mainnet and found them to all be valid 19:06:48 gmaxwell: somehow i thought many of them were invalid 19:06:51 oh! 19:06:52 gmaxwell: not exactly, because of lack of the 0000.....0000 coinbase witness 19:06:53 cfields: oh! 19:06:54 isn't segwit only backdateable to p2sh activation at earliest? 19:07:02 I think in general its cleanest when we can backdate softforks to the start. 19:07:09 achow101: we're talking about backdating p2sh as well (with one exception) 19:07:15 yes it would take some work to manufacture the witness nonces as jl2012 points out 19:07:27 what is the advantage over just hardcoding a height for segwit and p2sh start? 19:07:30 but if it is really true that none were invalid, that might change the way i look at it 19:07:45 sipa: no need to handle the non-segwit case for initial validation anymore ,I guess 19:07:49 sipa: it is a very nice property (imo) that you will *never* accept any chain with invalid segwit/p2sh spends 19:07:57 irrespective of reorgs 19:08:03 sdaftuar: and for some blocks that was very close to 1MB, adding the coinbase witness will make it over 4M weight 19:08:23 BlueMatt: sure, but i'm not sure that weighs up against the complication of adding exceptions, make-pretending to have coinbase witnesses nonces, ... 19:08:28 it also simplifies reasoning about further changes, e.g. what happens if someone forks early during IBD and feeds us a chain with things we assumed were impossible. 19:08:43 in any case, I believe sdaftuar's suggestion was to backdate SCRIPT_VERIFY_WITNESS/P2SH, but dissallow witnesses in blocks pre-activation, effectively disabling segwit 19:08:47 gmaxwell: yeah that's basically the reason i started thinking abotu this 19:08:51 BlueMatt: ugh 19:08:52 but i don't feel strongly either way 19:08:57 sipa: you can skip the witness nonce part 19:09:15 jl2012: are any of those blocks *also* with the commitment? 19:09:21 that's effectively splitting the segwit logic into 2 deployments, with one always active? 19:09:23 I don't feel strongly about it except the general principle that it's better to backdate wheverever possible. 19:09:35 sipa: well I would call that splitting it into one deployment and one consensus rule 19:09:36 but ok 19:09:40 well an always active deployment is kind of not a deployment 19:09:42 right 19:09:45 sipa: the branch i have splits the witness commitment rule from the script verification rule, basically 19:09:53 BlueMatt: so you're not getting rid of the deployment overhead 19:09:56 i was not sure it was an improvement 19:10:15 sipa: indeed, it does not significantly simplify, it (mostly) just adds a very nice property 19:10:28 (and, as gmaxwell points out, may simplify future fork logic) 19:10:36 i understand the advantage of making a consensus rule always active, allowing you to get rid of some logic 19:10:42 luke-jr: I guess so, especially from f2pool. They mine exactly 1MB block quite frequently 19:10:43 jl2012: that weight issue is a good point 19:10:47 but it doesn't seem that's really possible here without further complication 19:11:00 I dont think its adding significant new complication 19:11:01 Not just simplfy but reduce the incidence where the community makes design errors due to reasoning from current rules without realizing they don't apply in IBD. 19:11:28 but what sipa says, I don't think backdating is worth non-trivial extra complexity. 19:11:32 what's the downside to allowing witness in pre-activation blocks? 19:11:47 luke-jr: makes my head hurt 19:12:07 luke-jr: that we'll make changes in the future based on an assumption that they're never there. 19:12:27 sipa: I'm looking at https://github.com/sdaftuar/bitcoin/compare/2649d1690ce9458aa344a8ccfb1fa8548b2ac57c...2017-09-p2sh-segwit-from-genesis 19:12:52 We also don't have to decide this forever now, we could e.g. set it to activate at the real height now, and then later adjust it further back. 19:12:53 sipa: i just really hate the attack scenarios that involve feeding alternate chains that eventually get reorged out but possibly with poor consequences... perhaps this is not a problem with segwit, but perhaps it is... say your wallet loses money in an unexpected way or something? 19:13:14 BlueMatt: that doesn't look too bad, i guess 19:13:25 but i need to think about it 19:13:39 sipa: yes, sorry, should have shared the code since we're arguing based on different understandings...anyway, something to think about, I dont think I feel *that* strongly, but I am vaguely in favor 19:13:40 if this is worth discussion, i can open a PR 19:13:49 i wasn't sure whether to move this forward 19:14:07 but in regards to the next topic, do we want all that in 0.15.1? 19:14:20 no, i don't 19:14:24 i don't think this so either 19:14:25 i dont think so? 19:14:29 okay 19:14:32 would be kind of hurried IMO 19:14:37 very 19:14:39 It would be really nice if 0.15.1 were out before the B2X split, but we're on the thin edge of that now I think. 19:14:42 also let's not increase the scope of 0.15.1 19:14:46 ok, so #action sdaftuar opens pr? next topic? 19:14:46 so this is unrelated to #11389 19:14:48 https://github.com/bitcoin/bitcoin/issues/11389 | Support having SegWit always active in regtest by sipa · Pull Request #11389 · bitcoin/bitcoin · GitHub 19:14:52 #topic segwit wallet 19:15:20 if we want 0.15.1 out before B2X, it probably needs to go into rc's within the next week 19:15:27 For the GUI, I'm working on a Bech32 error pointer (red underlines where errors appear) 19:15:29 achow101: seems unreasonable 19:15:34 i first want to get 11389 in, but there seems to be some discussion about the right approach 19:15:35 (which probably means no segwit wallet) 19:15:51 0.15.0.2? :p 19:15:55 yea, that 19:16:03 or 0.15.1 without segwit wallet, 0.15.2 with 19:16:13 we'll just do minor-minor releases until we have the damn segwit wallet :) 19:16:18 yea, numbers...isnt someone in charge of those so I dont have to think about them? 19:16:18 haha 19:16:23 I think #11389 is related to Suhas's suggested change, no? 19:16:25 https://github.com/bitcoin/bitcoin/issues/11389 | Support having SegWit always active in regtest by sipa · Pull Request #11389 · bitcoin/bitcoin · GitHub 19:16:38 well, RC by then at least would be good if not out... 19:16:53 sipa: wait, so you want to have segwit always active in regtest for segwit wallet, or what am I misunderstanding about the need for segwit-regtest for 0.15.1? 19:16:58 BlueMatt: yes 19:17:16 adapting the tests to deal with segwit activation halfway through them is a giant pain 19:17:23 so if we'd do 0.15.1 without segwit wallet, is there anything that still needs to go in? or can we tag rc1 after the meeting? 19:17:27 test_framework().activate_segwit() ? 19:17:31 as much as i really want to concentrate on segwit wallet 19:17:38 jnewbery: i was starting to respond to you, but to the last point "We already have control to make a BIP9 deployment active at a certain height in regtest using -vbparams. What advantages do you see for making a deployment buried instead of just activated at a height?" -> -vbparams doesn't permit having segwit active before block 432 19:17:50 what's the point of doing 0.15.1 without segwit wallet? 19:17:51 i think practically speaking we should focus on what would be good to have before 2X 19:17:56 I'm not sure what is the rationale for doing 0.15.1, are there important bugfixes that we need to get out? 19:17:56 and we should do that withotu segwit wallet 19:18:13 wumpus: mostly I want https://github.com/bitcoin/bitcoin/pull/11487/commits/09cf35122a219217f841e4e4f7847386eb0b0b8a pre-b2x 19:18:18 what needs to be done before 2X then? 19:18:20 but dunno if thats a realistic goal (it probably isnt) 19:18:20 wumpus: there are a few edge cases with invalid chains that might cause for annoying behavior 19:18:54 I mean MarcoFalke backported a lot of things, that's nice to have in #11447 19:18:56 https://github.com/bitcoin/bitcoin/issues/11447 | 0.15.1: Backports by MarcoFalke · Pull Request #11447 · bitcoin/bitcoin · GitHub 19:19:46 BlueMatt: so 11487 should get 0.15.1 tag? 19:19:57 its not critical, but having edge cases that you may see if you're offline during the fork and suddenly you accept blocks that are on the 2x chain (if they're <4m weight and more work and within our pruning window) thats kinda annoying 19:19:59 or really just that commit? 19:20:02 Just for the record I think it is terrible that we're effectively being forced to delay segwit wallet due to this nonsense. 19:20:11 if so, please open a separate PR for that 19:20:14 wumpus: the rest of that pr is just test changes and other tiny things 19:20:29 gmaxwell: yes, me to, I'd personally prefer not to change our plans for them 19:20:30 (even if we don't bump around the versions for it, the fact that people are spending time on these other things creates delays) 19:21:00 but if we need robustness changes now, better to do it 19:21:04 And add to high priority for review? 19:21:13 yes, and remove the rest probably 19:21:16 In any case, so far I haven't seen PRs that we need in advance merged yet, if there were some in, I would support doing a release with them. 19:21:40 It's hard to anticipate what we'll need a month in advance... 19:22:05 wumpus: again, I dont think its a "need", but its open for discussion 19:22:07 if we want to do rc1 start of next week we'll really need to hurry 19:22:10 esp because B2X has already changed their behavior to undermine our protections in the past... :-/ 19:22:18 its really gross that we may accept/store blocks on a chain we know is invalid 19:22:25 but its not gonna do anything but use a bit more disk 19:22:31 Yes, okay, that is a concern. 19:22:59 #11446 probably won't make it either will it 19:23:01 https://github.com/bitcoin/bitcoin/issues/11446 | [WIP] Bad block interrogation by achow101 · Pull Request #11446 · bitcoin/bitcoin · GitHub 19:23:01 yes that's kind of gross 19:23:28 meshcollider: well thats the sort of thing we're talking about right now. 19:23:49 I think 11446 would be necessary for a pre-B2X release so that we kick all peers that give us invalid blocks, not just the first 19:23:57 basically to do these things we'll need to more or less drop working on SW wallet for a moment, get those things, and RC them. ASAP. 19:24:17 and/or maybe #10593 19:24:19 https://github.com/bitcoin/bitcoin/issues/10593 | Relax punishment for peers relaying invalid blocks and headers by luke-jr · Pull Request #10593 · bitcoin/bitcoin · GitHub 19:24:22 Yeah a release including both of those would be worth it if they're ready for merge in time 19:24:50 misleading PR title. :P 19:25:03 ok tagged both of them for 0.15.1 19:25:48 will move the rest that's tagged with 0.15.1 and unmerged to 0.15.2 when we actually decide to do the release 19:25:50 fyi i have one more pr that is along these same lines that i will be opening shortly... basically trying to implement some of the outbound peer protection we talked abotu last week's meeting 19:26:20 sdaftuar: I'll put some time into helping review that. (though I'll be in the air much of the weekend...) 19:26:26 awesome, thanks 19:26:27 sorry, i had to run out for a min.... Lots of people are expecting 0.15.1 as the release that enables more segwit wallet functionality. Releasing without that will be very confusing to lots of people. Is there any reason not to call it 0.15.0.2 ? 19:26:52 no opinion on versioning 19:26:57 gmaxwell: how is it misleading? 19:26:58 agree with cfields 19:27:06 +1 for 0.15.0.2 19:27:07 It's just that they've been told over and ove to wait for 0.15.1... 19:27:08 Agree with cfields as well 19:27:08 ack 0.15.0.2 19:27:19 no opinion on how to call it either, 0.15.0.2 was really a joke though, usually we do minor-mimor versions only for tiny changes 19:27:31 I'd prefer to call 0.15.1 the one with segwit wallet just due to comms reasons. 19:27:40 personally, I'd prefer to move segwitwallet to 0.16, but it's numbers so who cares 19:27:55 anyhow if everyone wants 0.15.0.2 , we'll have 0.15.0.2 19:27:55 comms reasons probably outweigh any reason to move it 19:27:57 Or look at #9653 now and throw everyone into confusion ;) 19:27:58 https://github.com/bitcoin/bitcoin/issues/9653 | Versioning convention for Bitcoin Core · Issue #9653 · bitcoin/bitcoin · GitHub 19:28:04 yes, agree with that 19:28:07 (comms reasons is that there are a billionity messages on the internet saying 0.15.1 has segwit wallet) 19:28:10 we've kind of promised segwit wallet in 0.15.1 19:28:16 right 19:28:28 what if we did segwit wallet this weekend? *ducks* 19:28:35 let's go with 0.15.½ :P 19:28:44 achow101: if we did that, we'ld not get around to the ultra-high-priority ones that warrant releasing now 19:28:45 Lol 19:28:49 so obviously we release 0.15.3 ... and then 0.15.1 after it... 19:28:56 luke-jr: hehe floating point version numbers 19:29:15 luke-jr: eh I mean fractions 19:29:22 0.15.0.../.1 19:29:36 gmaxwell: starting to sound like gcc. Obviously gcc 8.0 is the beta :p 19:30:02 0.15.A 19:30:18 ok, so 0.15.0.2 it is, will create a milestone and change the tags 19:30:24 in any case, lets worry about that when we're actually ready to release; I think we understand the tradeoffs. 19:30:34 sounds good to me 19:30:41 sorry for the late chime-in 19:32:18 yeah no problem, I guess we covered both "segwit wallet" and "pre-2x release" - any other topics? 19:32:37 So not clear to me if we've decided 19:32:50 Are we doing a pre-2X release or trying to at least 19:33:10 my impression is that we're going to try 19:33:14 It would be helpful to note if we're clearly prioritizing that and putting them on high-priority-for-review 19:33:20 https://github.com/bitcoin/bitcoin/milestone/32 19:33:39 yes, they should be (and anything else should go for nwo) 19:33:49 it sounds like we're going to try... 19:34:24 also keep in mind that there is value in having protections in master, even if they're not in a release... a small percentage of nodes in the network being protected can help improve stability for everyone. 19:35:10 achow101: can you please update title and description for #11446 19:35:12 https://github.com/bitcoin/bitcoin/issues/11446 | [WIP] Bad block interrogation by achow101 · Pull Request #11446 · bitcoin/bitcoin · GitHub 19:35:17 morcos: hehe sure 19:35:50 And do you think we don't need #10593 if we have 11446? 19:35:51 https://github.com/bitcoin/bitcoin/issues/10593 | Relax punishment for peers relaying invalid blocks and headers by luke-jr · Pull Request #10593 · bitcoin/bitcoin · GitHub 19:35:56 in any case, based on CST prices, I think we should focus on protections that help in the case that we have disguised B2X peers and they're getting no blocks at all (Because they've rejected the bitcoin chain). 19:36:19 morcos: #10953 does something mostly different 19:36:20 https://github.com/bitcoin/bitcoin/issues/10953 | [Refactor] Combine scriptPubKey and amount as CTxOut in CScriptCheck by jl2012 · Pull Request #10953 · bitcoin/bitcoin · GitHub 19:36:34 wrong pr number? 19:36:44 593, see above 19:36:45 oops 10593 19:36:52 #10593 19:36:54 https://github.com/bitcoin/bitcoin/issues/10593 | Relax punishment for peers relaying invalid blocks and headers by luke-jr · Pull Request #10593 · bitcoin/bitcoin · GitHub 19:36:59 in 593 you say it does the same as 11446 19:37:00 https://github.com/bitcoin/bitcoin/projects/8 updated 19:37:24 I suggested it because luke-jr that it would do about the same thing plus some more, but I noticed that it doesn't really 19:37:24 basically i'm just trying to get concept acks here on what we're going for 19:37:31 ok 19:37:44 see https://github.com/bitcoin/bitcoin/pull/10593#issuecomment-334946691 19:38:05 I thought luke-jr might change it to include what 11446 does 19:38:38 gmaxwell: yes, regarding b2x peers that have less hashpower and are disguised, I believe thats what sdaftuar is working on 19:38:50 BlueMatt: great, okay! 19:38:59 OK Can someone motivate 10593 for me 19:39:19 I mean not really motivate, but explain why it is important before 2X 19:39:36 It's more important before the next softfork, not so much before 2X, AFAIK 19:39:48 ok, that was my reading... 19:39:56 (if 2X would accept a reorg, it'd be useful, but 2X doesn't) 19:40:16 oh, if 2X users want to switch to Bitcoin, it might be useful for them 19:40:16 I thought it also added disconnects on invalids that we currently don't have? 19:40:33 luke-jr: because it turns some bans into disconnects? 19:40:37 gmaxwell: right 19:40:37 can we perhaps remove that from high priority and concentrate on the pre-2X things... (hmm, good point i suppose) 19:40:46 gmaxwell: IIRC, the disconnect-on-merely-invalid is achow101's PR 19:41:38 gmaxwell: it turns bans into disconnects, which includes the ban on the first time we see an invalid block 19:43:26 I think that in and of itself is less critical. 19:43:48 so I guess 10593 is a nice-to-have before 2X, but not a must-have 19:43:50 ? 19:43:57 luke-jr: agreed 19:44:24 that sounds right to me 19:44:37 sounds reasonable to me. 19:45:09 so 10593 is less-than-higher-priority-for-review? :p 19:45:22 slightly-higher-priority-for-review 19:45:25 elevated-priority 19:45:48 or as we used to do it in Core: 14275131000 19:46:09 $ date --date "@14275131000" 19:46:09 Thu May 12 03:10:00 PDT 2422 19:46:14 * sdaftuar laughs after alex explained the joke 19:46:31 ??? 19:46:40 heh, i made up the number b/c i was lazy, but there were number ranges.. one was for medium-high priority 19:46:55 lol, ok, so did we ever discuss segwit wallet? 19:47:01 sorry, I kinda derailed things :( 19:47:07 apparently we discussed it being less priority 19:47:11 or something 19:47:12 TIL that date command line can convert unix timestamps, thanks sipa 19:47:24 noooooo :( 19:47:25 wumpus: also, date "+%s" 19:47:31 how did you do that otherwise? 19:47:33 57599999 19:47:46 thanks gmax 19:47:46 wumpus: oh, another hint, when reading git logs, it is useful to have a vim keybinding to call that command so you can see when it happened :p 19:47:57 morcos: time.ctime(n) or time.localtime(n) in python 19:48:01 morcos: python is pretty useful for date math. 19:48:11 BlueMatt: i will work on describing the alternatives for segwit wallet support, and some thoughts on wallet/ismine in 0.16 19:48:19 BlueMatt: but blocker is the always-segwit-active 19:48:26 e.g. script I use for IBD benchmarking uses python to difference bitcoin log dates. 19:48:26 gmaxwell: exactly 19:48:31 so review/discussion can focus on that for now, i think 19:49:03 sipa: well, at least personally, I'm also fine with taking the always-active-segwit pr and then reverting it if we decide we want something more like jl2012's on master, isnt a big changeset either way 19:49:10 so I'm not sure I'd call it a "blocker" in that sense..... 19:49:16 fair 19:50:05 * luke-jr needs to move his bitcoin git to a SSD 19:51:08 any other topics? 19:51:44 #action activate segwit 19:51:53 luke-jr: well at least your entire SSD won't be full with one git checkout, as with the linux kernel :-) 19:52:01 * sipa fetches his DeLorean 19:52:12 activate segwit in 1970 19:52:13 wumpus: git-show of a tag is taking me a full minute here :/ 19:52:27 luke-jr: is that on a 10-year-old sd card?! 19:52:31 $ git grep -i delorean | wc -l 19:52:31 1 19:52:36 BlueMatt: it's on core memory 19:52:38 luke-jr: git show? that just retrieves an object, that's slow even for a mechanical hd 19:52:38 BlueMatt: pretty sure we did that in a previous meeting. Though we could do it again and make it 2x activations... 19:52:39 BlueMatt: fairly newish 5400 RPM magnetic drive 19:52:52 wumpus: it does many many MB of reading for some reason 19:53:01 git log can be kind of slow here, especially when showing branches (as I have about 800 local branches), but show is super quick 19:53:03 5400 RPM? eww 19:53:07 :-) 19:53:19 wumpus: I suspect part of the cause is that I never prune my git repo 19:53:42 luke-jr: can you prune a git repo? 19:53:47 (or do you mean gc?) 19:53:47 git gc 19:53:59 I interpreted that literally, like converting it to a shallow repo 19:54:09 git prune also exists, just removes unreachable objects 19:54:19 gc does that + compacting storage 19:54:25 wumpus: gc 19:54:34 shallow repo is something else 19:54:38 git gc --aggresive --force --prune=all 19:54:41 my gc is configured to only compress :P 19:54:45 why? 19:55:01 so I can git-show any object hash from any point in time, even if it's long-dead 19:55:21 luke-jr I do 2 ssds in raid 0 + rsync backup to disk and it works great 19:55:22 .git is only 1.1 GB, surprisingly 19:55:27 perhaps you can split up your repo in an archive version + working version 19:55:47 sipa: well, I'm hoping simply moving it to SSD will be good enough XD 19:55:51 #topic optimal git workflows for Core memory users 19:55:51 seems this meeting is out of topics? 19:56:02 #link https://en.wikipedia.org/wiki/Magnetic-core_memory 19:56:47 wumpus: you suggested waiting to squash fixups into multiwallet until it's about to be merged; but jnewbery is asking for a rebase.. :x 19:57:08 when I started using worktrees I've moved everything to work from a single .git tree (with seaprate checkouts for some branches), but a seperate archive and working copy sounds pretty good 19:57:10 if you need a rebase anyway, i generally don't care about squashing fixups 19:57:27 mercury delay line memory ftw 19:57:47 luke-jr: yes in that case feel free to squash 19:58:10 k, *done* 19:58:39 #endmeeting