19:00:53 #startmeeting 19:00:53 Meeting started Thu Jun 16 19:00:53 2016 UTC. The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot. 19:00:53 Useful Commands: #action #agreed #help #info #idea #link #topic. 19:00:59 Okay 19:01:14 hi 19:01:16 topic suggestion: merge compactblocks for 0.13 19:01:21 ack 19:01:29 I like topics. 19:02:04 replacements (RBF/bumpfee) in 0.13 19:02:30 segwit status 19:02:32 ack for compactblocks topic 19:02:35 topic: i propose pushing the feature freeze one week further for CB and segwit to stabilize 19:02:42 sipa: morcos: sdaftuar: jonasschnelli: btcdrak: phantomcircuit: paveljanik: 19:02:48 I really don't like that\ 19:02:53 we already pushed it back a month 19:02:56 sipa: hm. so feature freeze doesn't mean the software is done. 19:03:04 I really want to feature freeze this week 19:03:06 it's not like we're waiting for new features for these things. 19:03:20 Is the issue just that we're worred about destablizing master a bit? 19:03:28 note that it's okay to merge something that still needs some work given that it can be done before rc1 19:03:35 CB is mergeable. any bug fixes woudl be minor and can be merged afterwards. 19:03:36 but we really want to merge things now 19:03:43 CB is not mergeable imo 19:03:52 well CB and segwit cannot be merged both 19:03:55 of course it shouldn't leave master in broken state 19:03:56 also true 19:04:04 not right now 19:04:27 sdaftuar: do you think it's mergable with the outstanding raised issues resolved? 19:04:36 we can merge segwit+CB+CPFP and let them stabilise in master? 19:04:43 sdaftuar: you realize that means it misses the merge window for 0.13? 19:04:44 i haven't finished my review, but i raised some issues last night that i think need to be addressed 19:04:45 luke-jr: CPFP is merged now. 19:04:49 luke-jr: CPFP merged 19:04:51 oh, missed that, k 19:05:13 actually 19:05:25 bluematt hasn't updated yet to remove the work limit 19:05:26 that has to go 19:05:54 i hadn't bothered commenting because i was under the impression he's working on it 19:05:54 the criteria for merging isn't bugfree, its free of major architectural flaws or so full of issues we're not confident that it can be believed bugfree by rc1. 19:06:04 what about merging it and putting it behind an experimental option? 19:06:23 sdaftuar: agreed, but it can be removed post merge in a separate PR. 19:06:29 sdaftuar: I presume he'll remove it as soon as he's back on. 19:06:36 which topic are we on now? CB? 19:06:42 yes CB 19:06:43 luke-jr: yes 19:06:45 #topic Compact block relay 19:07:06 (thats why I asked if you'd think it would be mergable if the outstanding identified issues were resolved) 19:07:39 CB is clearly working as it's being live tested in the wild by major pools. 19:07:49 there's DoS risk that has not been analyzed at all 19:07:55 btcdrak: that doesn't mean that there aren't outstanding issues. 19:08:05 what about merging it experimentally for 0.13.0 19:08:06 btcdrak: well, so is X-thin.. working in practice doesn't mean reliable 19:08:08 gmaxwell: present 19:08:15 wumpus: that sounds fine to me 19:08:25 put itbehind an option, then when the outstanding issues are fixed, remove that in 0.13.1 or so 19:08:27 and we can use the time between now and the release candidates to make it more stable/reliable? 19:08:35 here as well 19:08:37 I'd like to see more limit options to address sdaftuar's concerns 19:08:46 the point of the feature freeze is that the main bulk of the master branch enters a stabalisation phase. 19:08:50 wumpus: i can live with that 19:09:10 the other option is to move compactblocks to 0.14 19:09:11 wumpus: 0.13.1 shouldn't remove features IMO, but maybe changing the default would make sense 19:09:20 I don't think CB can wait for 0.14, unfortunately 19:09:24 I would also like to see more analysis on how CB would affect miner's txn selection 19:09:34 luke-jr: this would be adding features, not removing them, and yes it's cheating of a sort 19:09:38 jeremyrubin: I don't think that's a barrier to merging though 19:09:53 jeremyrubin: without work limit, there shouldn't be any 19:10:05 sipa, sorry what's the "work limit" here? 19:10:05 seems there are still a lot of concerns for CB. why so last minute? 19:10:09 why didn't this come up weeks ago? 19:10:19 instagibbs: not checking the entire mempool 19:10:22 oh ok 19:10:29 i've been reviewing segwit :P 19:10:45 sdaftuar, why aren't you doing both simultaneously? 19:10:49 wumpus: these are implementation details and people have been reviewing other things, some are driven out of last minute opimizations matt added that he didn't need to add. 19:10:59 wasns't talking about you specifically sdaftuar :) 19:11:06 we could delay 0.13 once again. There are no urgent features and the release due date is artificial. Right? 19:11:08 I know you focused on segwit, that's good 19:11:18 I don't want to delay 0.13 again 19:11:18 sipa: without work limit there is also DOS concern (although limited by needing to re-connect) 19:11:31 jeremyrubin: thats not true. 19:11:37 too much slip and we can just forget 0.14 19:11:39 jeremyrubin: please, this isn't helpful. 19:12:00 0.13 is good enough for a release right now 19:12:29 release 0.13 without segwit+CB then, and merge those immediately for 0.14? 19:12:32 I agree with wumpus: CB 0.13 as experimental (for our own protection) and non-exp in 0.13.1 19:12:35 it would be nice to merge CB, and i think we should, but it's not a requiremnt 19:12:37 lets take a step back there are two categories of remaining issue on CB, one if the work limit stuff matt added recently. This was driven purely out of his unrelated UDP forwarding that is based on CB, which sent him into microsecond shaving mode. 19:12:42 i don't want (1) keep rebasing segwit (2) wait until february 2017 for CB 19:12:59 sipa: me neither 19:13:12 I think that segwit should take priority in merging. 19:13:14 wumpus: 1 MB blocks is already killing; segwit without CB is likely to be a disaster 19:13:20 i am fine with making CB experimental in 0.13 19:13:28 sipa: ack 19:13:31 if there are a few days to work out the kinks 19:13:31 sipa: experimental sounds fine 19:13:39 We cannot have SW deployed with no prospect of CB live nad in use. 19:13:44 gmaxwell: also ack 19:13:45 sipa: there's still until july 7 for the planned rc1 19:13:57 wumpus: that should be plenty 19:14:14 but the point is we want to merge feaatures *now*, exactly so that the next weeks can be fixing the remaining issues 19:14:18 guys, please dont delay segwit, whole community is watching you and we need capacity increase soon :-( 19:14:24 yes, the concerns there appear small. And indeed, we SW activation not set we don't need to have CB requesting enabled. 19:14:37 BakSAj: this has no effect on segwit's activation time 19:14:57 must we merge CB now though? i feel like the bug fixes are more likely to happen in the initial PR, than trying to clean up post merge to meet the feature freeze deadline 19:15:04 oh ok then 19:15:12 oh, we're leaving SW undefined on mainnet? 19:15:17 luke-jr: yes 19:15:24 luke-jr: until a backport to 0.12 is ready 19:15:30 sdaftuar: if we don't merge CB this week it misses the merge window for 0.13, and will be merged for 0.14 19:15:32 ok 19:15:49 sdaftuar: I assumed the outstanding issues raised last night will be fixed before its merged. 19:15:52 sdaftuar: bug fixes do not need to be done before the feature freeze 19:16:01 it's a feature freeze, not a bug fix freeze, that would be silly 19:16:23 sdaftuar: it alows master to stabalise. Then we know there wont be hugely disruptive things getting merged post freeze. 19:16:26 sipa: how hard is it to backport segwit to 0.12.2 ? 19:16:30 integration testing 19:16:40 wumpus: can we keep the feature freeze date and alloc an addtl week for bug fix now? 19:16:53 BakSAj: after the meeting? 19:16:57 jeremyrubin: we have until july 7th for that. 19:16:58 jeremyrubin: bug fix time isn't "allocated" 19:17:04 jeremyrubin: do you need an additional week for bug fixing? rc1 is planned for july 7, according to sipa that was good 19:17:19 the whole reason for feature freeze ahead of rc1 is to allow time for fixing and testing. :) 19:17:23 i think 3 weeks to work out the problems in CB is sufficient 19:17:27 they are details 19:17:36 phantomcircuit: yeah, sure 19:17:40 sipa: ack 19:17:41 my concern with merging is that the code has been in flux the past days 19:17:43 and that's only rc1, I'm sure there will be bugs in rc1, and we'll need rc2 rc3 19:17:50 i think so too, but it seems silly that we're merging a PR that we otherwise wouldn't merge to get around a self-imposed deadline 19:18:13 sdaftuar: I know it seems stupid, but long time expirence with creep shows that deadlines have value. 19:18:15 sdaftuar: you don't think the release schedule is important? 19:18:40 Or another way to look at it, it's fine that some well known important features get fixes and evolution, but we need a bar against other creep. 19:18:41 wumpus: probably no point in arguing further. i'll be happy to help work the bugs out... 19:18:54 sdaftuar: no, there is really no point in arguing this 19:18:56 (you don't want me submitting the n-th fold relay improvement or whatnot in the next couple weeks) 19:19:04 sdaftuar: well, I think gmaxwell has a good point that CB is very important to get in to be ready for segwit 19:19:04 and I'm kind of tired having to argue the value of having deadlines for every release 19:20:05 With a big team, bright lines are helpful. Even if they're sometimes objectively dumb. 19:20:15 wumpus: well I for one appreciate the scheduling. It's more productive. 19:20:31 ^^^ 19:20:50 scheduled releases IMO are great; the only problem I think we're hitting is outside pressure to get specific things in sooner 19:20:57 I do agree CB is still a lot in flux 19:21:21 which is why I brought up this topic in the first place instead of just merging it 19:22:03 so, ok, let's decide that CB still gets a week to be ready 19:22:15 Thank you. 19:22:24 sounds good to me. 19:22:25 great. 19:22:37 wumpus: can you clarify "gets a week" meaning 19:22:42 wumpus: ack 19:22:50 i think I am interpreting it as 1 more week till merge 19:22:55 jeremyrubin: it get's merged next week. 19:22:55 jeremyrubin: can you clarify what is unclear about it? 19:23:11 is segwit ready for merging? 19:23:44 segwit is ready for merging, though i'd like to get review on the changes made the past few days 19:23:58 I think it should increase the pkh length limit to 75 bytes, but not important 19:24:01 segwit is also still very much in flux 19:24:03 wumpus: not too much... just a little unclear what the week is for etc 19:24:08 the changes were just related to merging it without an activation date, right? 19:24:14 Because the last night, there are 40K+ unconfirmed transaction 19:24:15 jeremyrubin: to finish up the pull request so that it can be merged 19:24:18 they're mostly making segwit p2p deal correctly with having no activation date 19:24:27 wumpus: but all ok now (I think you missed my second msg) 19:24:29 and tests/nots 19:24:32 Frederic94500: #bitcoin 19:24:33 *nits 19:25:00 and ticks 19:25:02 Okay can we move to the next topic? 19:25:07 #topic segwit 19:25:09 luke-jr, noted, but I think that ship has sailed 19:25:30 i don't think there will be any further changes to segwit necessary, apart from potentially making it cooperate with CB 19:26:21 we may find some edge cases in the transition between activation date unset and set, which i plan to actively help testing he next few days 19:26:38 that is, assuming people find the review and testing it has had so far sufficient 19:26:54 so it would be better to merge segwit *before* CB? 19:27:03 i don't care 19:27:15 i'll help rebase either one on top of the other 19:27:33 sdaftuar: opinion? 19:27:34 sdaftuar, any outstanding concerns re testing? 19:27:40 at the least we need to make sure one of them is merged asap 19:27:44 so the other one can be integrated into it 19:27:46 wumpus, ACK 19:27:51 sipa: if you were to do the rebase which do you think would be less work? I have a pref for merging segwit first due to review things. (though I believe we can't set an activation for it without CB) 19:28:10 instagibbs: i'm doing testing now for the activation date unset -> set scenario 19:28:19 i'd like more eyes on that issue, as it only just came up 19:28:20 'activation' is wrt BIP9 right? 19:28:22 otherwise we'll keep this 'we need to rebase it over X' problem, and integration (and fixing bugs in integration) always causes unexpected issues 19:28:28 basically CB is less to review, and fewer have reviewed it, disrupting review with a rebase there is less of an issue. 19:28:33 merging CB first makes it potentially easier to backport if people want to 19:28:43 Chris_St1: yes, the parameters for activation on mainnet (starttime, timeout, bit) 19:28:44 Chris_St1: BIP9 starting date, yes. 19:28:55 but if CB needs a week of revisions, merging segwit first might just make more sense 19:28:57 the thing is though: CB is bound by the feature freeze, segwit is not 19:29:03 especially since segwit needs backports anyway 19:29:03 luke-jr: a backport of CB without segwit wouldn't be very interesting in any case. 19:29:17 good point wumpus 19:29:35 wumpus: it's less important so long as segwit has no mainnet activation params set 19:29:40 IMO 19:30:09 luke-jr: just need to get the code into master, it's been reviewed and tested so extensively 19:30:45 yes the merge there is about code maintance. 19:30:49 wumpus: fyi the issue that came up this week about merging with no mainnet activation was a surprise to all of us 19:30:52 isnt segwit the most reviewed btc code ever? 19:30:53 sdaftuar, I can take a look too. 19:30:54 Actually, there are 13K+ unconfirmed transaction and we need segwit 19:30:57 wumpus: i think that particular issue should be thought abou tmore 19:31:01 to make sure we haven't missed anything 19:31:02 Frederic94500: #bitcoin 19:31:15 #bitcoin 19:31:22 sipa: but to answer your question about my opinion, i think i agree it should be fine to merge 19:31:43 Frederic94500: it means move your conversation to that channel as it is off topic here. 19:31:58 i will finish my testing/review of the latest changes, and then hopefully ack this week 19:32:02 ie today/tomorrow 19:32:26 sdaftuar: So BIP9 parameters need to be set in the pull request before being merged into master correct? 19:32:39 Chris_St1: no, it can be merged with no starting date set. 19:32:40 wumpus: segwit is merged this week or not at all, CB thursday or not at all. 19:32:51 no. they will bet set later in a seprate pull 19:32:52 wumpus: is that acceptable? 19:32:56 Which is what will happen for master. 19:33:01 sipa: next thursday* 19:33:08 sipa: CB needs to be merged before (or on) next week thursday 19:33:14 sipa: segwit doesn't really have a constraint 19:33:23 wumpus: ok 19:33:45 I just thought merging it first was preferable, so that maintenance and testing of it can happen on master 19:33:55 yes, i agree 19:34:04 I'm really tired of not being able to work on some things due to avoiding disrupting segwit, it'll be good to have it merged. 19:34:07 :) 19:34:11 Yes. Merging it before 0.13 would make things more testable/tested 19:34:12 right 19:34:13 Only a few ACKs so far, start cracking the whip! 19:34:39 all my focus is on things that were freeze gated. 19:34:42 instagibbs: this meeting is one huge ACK :-p 19:34:47 (in the last week) 19:34:49 I have reviewed SW for serval hours but I don't feel myself in a position to give a it a utACK (or more) 19:34:58 i would also like to point to #8149 for review, where i've reorganized the commits per BIP 19:35:19 it may make sense for people to just ack certain sections of it, as it touches many relatively unrelated things 19:35:23 sipa: is #8149 the version to merge? 19:35:39 (testing, wallet, p2p, consensus, script) 19:35:44 btcdrak: yes 19:35:52 #link https://github.com/bitcoin/bitcoin/pull/8149 for review with reorganized commits per BIP 19:35:56 I really like the ordering of 8149, FWIW. 19:36:06 jonasschnelli, just pick a part you can review comfortably 19:36:28 and don't look at the commit by github; there is a summary comment with a list of all commits organized per section 19:36:32 which i keep up to date 19:36:46 sipa: thank you it's much easier to review 19:37:41 ok, any other topics? 19:37:52 yes 19:38:02 jonasschnelli had one 19:38:06 I'd like to briefly call for more review on cory's cconman 19:38:08 refctor 19:38:17 jeremyrubin: i will, but after 0.13 19:38:18 I think we should have a replacement option for the wallet in 0.13 19:38:21 #topic replacements (RBF/bumpfee) in 0.13 19:38:29 ack topic 19:38:34 jeremyrubin: when Cory is back 19:38:54 cory is answering pr stuff now, but I think he's not supposed to be :) 19:38:56 Also,... what happens if users start up a node and immediately send a tx? 19:39:01 am I missing something in thinking thats post 0.13 work now? 19:39:04 oh, more review, yes that's always good, although peopel are very busy with pre-0.13 issues now 19:39:06 cfields_: 19:39:08 (the conman stuff) 19:39:10 gmaxwell: yes 19:39:21 gmaxwell: I mena, no, you're not missing anything 19:39:25 Thanks. whew. 19:39:34 i'd to see conman go in right after 0.13 branch off 19:39:42 jonasschnelli: are you talking about how fee estimation should work in that case? 19:39:46 *conmann 19:39:47 jeremyrubin: thats why there isn't attention on it right at this second (also because cory is out) 19:39:47 Review of https://github.com/bitcoin/bitcoin/pull/8182 would be nice. Its a bumpfee command for GUI only. 19:39:51 sipa: +1 19:39:54 sdaftuar: yes 19:39:57 gmaxwell: he's been responsive 19:40:09 gmaxwell: but maybe let him relax a bit 19:40:11 jonasschnelli: yeah, my apologies for not having already looked at that! 19:40:14 doesn't matter, there is no benefit in merging conman before the branch 19:40:16 jeremyrubin: I want that too. Well, I really want the sequence setting parts and fee even on the bump parts. 19:40:27 jonasschnelli: I don't think "signals replaceability" is very useful 19:40:46 "Enable fee bumping" would make more sense 19:40:52 er s/fee even/feel 50/50 on the bump parts/ 19:40:59 I brought it up not for the 0.13 but because it seemed like we were out of topics so I raised it, no need to address further. 19:41:06 ok 19:41:12 luke-jr: you mean the text comment in the transaction details? Whats wrong with it. IMO we agreed on that term in a recent meeting. 19:41:17 right 19:41:31 thats nits, can be worked out on the PR or out of meeting. 19:41:42 please don't go into field naming details here. :) 19:41:42 k 19:41:48 jonasschnelli, maybe this is just me, but i generally much prefer that things be added to the cli before the gui 19:41:50 nits shouldn't be a reason to hold up the feature merge 19:41:52 Agree. The question is do we want a feebump option in 0.13... 19:41:58 if so,.. its extermly late. :) 19:42:01 makes the initial review much easier for the feature itself 19:42:18 So I think we really should have the sequence setting stuff, I kept trying to ack the prior PRs but they've been closed for new prs several times. 19:42:20 phantomcircuit: there is also a CLI PR. :) 19:42:26 jonasschnelli: especially for the GUI isn't [retty much too late 19:42:33 jonasschnelli: as it adds new translation strings 19:42:45 translation for 0.13 already started a few weeks ago 19:42:57 that's sad, but understandable 19:42:58 Yes. I agree. But I just think option to increase fees for 0.14 is to late.. 19:43:01 I think the fee bump stuff should definitely be in 0.13 19:43:03 having the CLI option would make sense though 19:43:06 jonasschnelli: where did we land with bumping interacting with the changs outputs already having been spent? 19:43:20 achow101: I want a pony. 19:43:36 achow101: 'should', but there's preactical issues with timing and planning we're trying to cope with here 19:43:36 * btcdrak gives gmaxwell a pony 19:43:38 jonasschnelli, 0.13.1 ? 19:43:38 achow101: i think we all like that, but we can't bypass safe practices for review and testing because we want it 19:43:42 it's a minor feature 19:43:56 Not sure if we want BP a bumpfeature... 19:44:14 BP? 19:44:17 backport 19:44:22 to be honest I think getting CB and segwit is enough worry for next week 19:44:36 yes... agree. 19:44:58 Although it's a triangle. CB <-> SW <-> RBF 19:45:16 so, I'd strongly suggest we at least get in my global optin setting, so that people who need RBF can easily use external scripts to do so: https://github.com/bitcoin/bitcoin/pull/7132 19:45:18 it's unfortunate that your PRs with feebump got little attention, but it's kind of late now, we can't just cram everything in last minute 19:45:32 wumpus: Agree. 19:45:48 in any case: RPC functionality must be in before the GUI 19:45:50 Did we figure the ordering for those merges? 19:45:50 My feeling is that it is too late for 0.13 and I just wanted to make this clear. :) 19:45:55 petertodd, I agree with this 19:45:56 i will focus on reviewing RPC bumpfee 19:45:56 that's always how we work 19:46:00 wumpus: could we split the sequence setting parts and do those? I think they're simple and not risky and have been reviewed under several PRs. 19:46:08 segwit -> CB or CB -> segwit? 19:46:13 The issue for them is that those PRs kept getting closed with changing scope. 19:46:19 gmaxwell: sounds good to me 19:47:01 Chris_Stewart_5: we'll see how it goes with the actual timing of the changes. 19:47:02 suggested topic: how should GBT react to pre-segwit miners, once segwit activates? 19:47:04 make sure the API is extensible enough to add the other things so we don't need to deprecate it already next version 19:47:07 Chris_Stewart_5: we don't need to decide that now. 19:47:15 but that's arguably a minor concern 19:47:37 luke-jr: what does it do in the current implementation? 19:47:44 gmaxwell: Also, these are BOTH to be included before the feature freeze, correct? Or is that tbd 19:47:50 to be determined* 19:48:02 Chris_Stewart_5: no, CB needs to be in before the feature freeze, softforks can in principle go in any time 19:48:17 Chris_Stewart_5: SW is freeze unrelated, CB has another week to mature. 19:48:17 gmaxwell: just errors 19:48:30 luke-jr: what is the alternative? 19:48:32 gmaxwell: the RPC call errors, that is. so the miner will failover or stop 19:48:42 sipa: mine blocks without any witness transactions 19:49:02 Chris_Stewart_5: question might suggest a misunderstanding, SW merge for master is not tightly coupled to deployment; it's mostly a discussion of code management. 19:49:18 luke-jr: that means mining on top of a chain they have not fully validated 19:49:23 oh, no, they have 19:49:24 sorry 19:49:28 sipa: no, the bitcoind is updated, just not the miner 19:49:30 i'm confusing client and server 19:49:48 luke-jr: might be better to return an empty block, if the implementation would be simple. 19:50:08 the failover might just cause it to fail over to something even stupider. 19:50:16 Chris_Stewart_5: the lifecycle page got updated to clarify some of this https://bitcoincore.org/en/lifecycle/ 19:50:17 presumably this is not a feature that there can possibly be a lot of demand for. is it relaly worth the trouble? 19:50:17 I guess that's another option, but empty block is :< 19:50:23 consensus changes are not on bitcoin core's major release schedule, the first release introducing segwit would ideally be 0.12.x 19:50:44 gmaxwell: I guess it seems CB from my understanding isn't tightly coupled to deployment either since I'm assuming old block relay code will still be in core? I'll ask more questions after meeting.. 19:50:46 but that doesn't mean segwit code can't be merged (just not activated) in 0.13 19:50:59 gmaxwell: concern with non-witness template being code complexity, I guess? 19:51:20 i prefer empty block 19:51:21 I suppose empty blocks are also more likely to get noticed and upgraded 19:51:30 luke-jr: just more features to test when hopefully thats just an emergency fallback. 19:51:34 throwing an error should get noticed very fast 19:51:42 Chris_Stewart_5: the old relay code will still be used in most cases, like with peers that don't support CB 19:51:54 sdaftuar: error will result in failover to another daemon, perhaps without segwit support, which is somewhat less desirable. :) 19:51:58 btcdrak: Thanks 19:52:15 little known fact: those blocks will be orphaned, that should also get noticed! 19:52:17 ack empty blocks - that's a reasonable failsafe in a lot of conditions in general 19:52:23 sdaftuar: they won't, though 19:52:26 I think error and empty are both acceptable, with a small preference for empty that would be overridden if i find out the implementation is more than about 4 lines of code. 19:52:28 they won't relay 19:52:32 sdaftuar: they're valid 19:52:34 yes 19:52:36 but they won't relay 19:52:38 … 19:52:41 why not? 19:52:41 hence, little known fact 19:52:57 ah, well if they won't realy, okay, well no reason to not error then. 19:53:03 why would they not relay? 19:53:05 segwit nodes will try to download blocks from WITNESS peers 19:53:13 after activation 19:53:14 so, this is a witness peer 19:53:17 ^ 19:53:19 not if it fails over 19:53:19 just not a witness miner 19:53:24 hm 19:53:38 oh, i see what you're saying 19:53:39 sorry i was responding to gmaxwell's failover to an old daemon 19:53:44 so, failover seems sufficient 19:53:45 sdaftuar: this is a witness node, but asking what happens when a non-sw hasher connects. 19:53:52 sdaftuar: OH! 19:54:00 well okay, that would get noticed too. 19:54:08 yeah, I think this makes error the better behaviour 19:54:18 still, the crap blocks produced would be noise to non-upgraded nodes. 19:54:19 wait, did or didn't we remove the code that used to push new blocks to peers? 19:54:42 technically, mining a non-witness block on an upgraded peer would relay, as per sipa's suggestion to mine an empty block 19:54:48 i just don't think it's worth the trouble to code that up 19:55:03 oh 19:55:20 code up/test/review 19:55:21 etc 19:55:31 BFGMiner at least WILL submit blocks to local bitcoind regardless of what pool mined them, BUT it can only do that with GBT pools, and frankly nobody uses that 19:55:48 so probably not worth considering IMO 19:55:58 i think we're good 19:56:06 K 19:56:08 unless miners complain about the behaviour 19:56:13 then wr can reconsider 19:56:16 sounds good 19:56:43