1 2016-10-27 00:00:02	0|gmaxwell|Eligius 0.589615
  2 2016-10-27 00:00:04	0|gmaxwell|Telco 0.709605
  3 2016-10-27 00:01:19	0|TD-Linux|gmaxwell, well 0.246 btc loss is directly proportional to their block size
  4 2016-10-27 00:02:19	0|gmaxwell|Indeed.
  5 2016-10-27 00:02:30	0|Lightsword|gmaxwell, do you have stats on kano’s ckpool and ck’s solopool?
  6 2016-10-27 00:02:42	0|TD-Linux|also I don't think there's really enough samples there to draw a conclusion. would be neat to automate this though.
  7 2016-10-27 00:03:11	0|gmaxwell|they didn't fine a block in the union of my and btcdrak's observation windows. I have mempool data for 435976 to now.
  8 2016-10-27 00:03:15	0|gmaxwell|s/fine/find/
  9 2016-10-27 00:03:59	0|sipa|gmaxwell: over how many blocks is this data?
 10 2016-10-27 00:04:32	0|gmaxwell|67
 11 2016-10-27 00:05:12	0|gmaxwell|here is the max from that data, BitClub -0.00042054 HaoBTC 0.03818631 BitFury 0.05457683 BTC.com 0.07372295 SlushPool 0.09595818 BTCC 0.09886828 ViaBTC 0.11170776 F2Pool 0.12080682 Bitcoin.com 0.12846755 AntPool 0.14341536 Unknown 0.16687057 BW.COM 0.18705609 GBMiners 0.24633568 Telco 0.709605 Eligius 1.03414
 12 2016-10-27 00:05:43	0|gmaxwell|I can also estimate mining process latency from this. I'm saving the fees for my gbt every 10 seconds.
 13 2016-10-27 00:06:24	0|gmaxwell|e.g. "you mined fees consistent with forming your block 30 seconds ago"
 14 2016-10-27 01:14:16	0|jeremyrubin|gmaxwell: can you normalize by block size?
 15 2016-10-27 01:25:12	0|midnightmagic|I'm going to regen the entire build instead of modifying the .assert in place to be able to say I ran it plus gverify against the other two sigs in there, michagogo et al
 16 2016-10-27 01:25:27	0|midnightmagic|sorry for the mixup
 17 2016-10-27 01:32:27	0|gmaxwell|jeremyrubin: okay, I added two columns, one is my mempool fees sscaled to the actual block size, the next is the difference.
 18 2016-10-27 01:32:59	0|gmaxwell|which now shows the small blocks as slightly negative, which makes sense, since they took the highest fee txn.
 19 2016-10-27 01:42:02	0|luke-jr|gmaxwell: that looks like the fallback where Eloipool has to guess the template itself until GBT completes
 20 2016-10-27 01:42:18	0|luke-jr|it's supposed to be based on the previous valid template, not sure what's going wrong there
 21 2016-10-27 01:55:11	0|gmaxwell|luke-jr: fix.
 22 2016-10-27 03:51:04	0|luke-jr|gmaxwell: looks like it was in wizkid057's GBT proxy thing.. [03:34:24] <wizkid057> oh, I never commited that to the production server
 23 2016-10-27 03:51:05	0|luke-jr|>_<
 24 2016-10-27 05:34:21	0|whphhg|Sup blockstream
 25 2016-10-27 06:11:21	0|GitHub7|[13bitcoin] 15laanwj closed pull request #9022: Update release notes to mention dropping OS X 10.7 support (060.13...060-13-1-osx-notes) 02https://github.com/bitcoin/bitcoin/pull/9022
 26 2016-10-27 06:11:22	0|GitHub177|13bitcoin/060.13 141d12463 15Michael Ford: Update release notes for dropping osx 10.7 support
 27 2016-10-27 06:11:22	0|GitHub177|[13bitcoin] 15laanwj pushed 2 new commits to 060.13: 02https://github.com/bitcoin/bitcoin/compare/a32d7c23fc0e...03422e564b55
 28 2016-10-27 06:11:23	0|GitHub177|13bitcoin/060.13 1403422e5 15Wladimir J. van der Laan: Merge #9022: Update release notes to mention dropping OS X 10.7 support...
 29 2016-10-27 06:21:03	0|wumpus|would be interesting to check this against univalue http://seriot.ch/parsing_json.html
 30 2016-10-27 06:22:38	0|jonasschnelli|wumpus: heh. Yes. Someone should turn this into unit-tests.
 31 2016-10-27 06:22:44	0|jonasschnelli|Maybe open an easy-to-implement issue?
 32 2016-10-27 06:22:53	0|jonasschnelli|though not sure how easy it is.
 33 2016-10-27 06:23:37	0|wumpus|it seems pretty straightforward to run the tests, if the files + results are available. Fixing the discovered issues is proably far from easy-to-implement :)
 34 2016-10-27 06:24:19	0|jonasschnelli|Indeed...
 35 2016-10-27 06:24:58	0|wumpus|but even without that it'd be interesting to see how it compares
 36 2016-10-27 06:26:19	0|wumpus|hopefully there's nothing in the "parser crashed" category, we've done quite a lot of fuzzing
 37 2016-10-27 06:31:00	0|jonasschnelli|I'm glad all JSON operations are hidden behind the HTTP Auth...
 38 2016-10-27 06:31:12	0|jonasschnelli|With rest it gets a bit more risky...
 39 2016-10-27 06:31:42	0|wumpus|I've purposedly kept JSON parsing out of REST
 40 2016-10-27 06:31:50	0|wumpus|just simple query strings
 41 2016-10-27 06:32:34	0|jonasschnelli|Ah. Right. Only output.
 42 2016-10-27 06:33:23	0|wumpus|output far from as much of a risk as parsing
 43 2016-10-27 06:33:27	0|wumpus|+is
 44 2016-10-27 06:33:47	0|wumpus|still possible for there to be bugs there, but much less scope for trickery
 45 2016-10-27 06:36:28	0|btcdrak|btw this is the issue I found with Univalue https://github.com/jgarzik/univalue/pull/29 - wasted quite a few hours trying to work out why some tests were failing because of this.
 46 2016-10-27 06:38:01	0|btcdrak|oh, I see wumpus found the PR already :-)
 47 2016-10-27 06:38:38	0|wumpus|https://github.com/bitcoin/bitcoin/issues/9028
 48 2016-10-27 06:38:58	0|wumpus|btcdrak: if tests are failing due to a trailing space you're doing comparison in the wrong domain
 49 2016-10-27 06:39:21	0|wumpus|I agree with your pull request but not that it should cause (non-JSON-pedanticness) tests to fail :)
 50 2016-10-27 06:41:35	0|wumpus|but I'd say, to compare two json documents: parse them and compare the underlying data. Don't compare pretty-printed representations
 51 2016-10-27 06:45:31	0|btcdrak|wumpus: well we have tests that compare the json output of "./bitcoin-tx -json ..." with a json file. trailing white space can get trimmed by IDE/editor settings. Trailing white space has no place in a json file. If it wasnt for that nice "log errors as diff" patch to bitcoin-unit-test.py submitted yesterday I would have lost my mind.
 52 2016-10-27 06:46:27	0|wumpus|I understand, but there is no standard way to pretty-print JSON
 53 2016-10-27 06:46:48	0|wumpus|having the tests depend on how the jSON lib happens to do pretty printing is fragile
 54 2016-10-27 06:47:05	0|wumpus|ideally the tests should compare the data, not the text
 55 2016-10-27 06:48:36	0|btcdrak|yes, I agree.
 56 2016-10-27 06:49:59	0|wumpus|I think we have some similar problems in other places, which complicated switching JSON libraries last time
 57 2016-10-27 06:50:30	0|wumpus|not a huge proiority to change ofcourse
 58 2016-10-27 06:50:44	0|btcdrak|but while indentation may not have a standard, I think trailing whitespace has no place in any output.
 59 2016-10-27 06:51:49	0|luke-jr|but what if you want to embed a Whitespace program? :p
 60 2016-10-27 06:51:56	0|wumpus|as I said I agree with your PR, I don't think emitting trailing whitespace is desirable, but if it causes test failures that points at a deeper issue
 61 2016-10-27 06:52:21	0|btcdrak|yup
 62 2016-10-27 06:52:26	0|wumpus|next time the problem may be the other way around, someone accidentally adds trailing whitespace to the example and the test fails
 63 2016-10-27 06:52:45	0|wumpus|and spend hours debugging that problem instead of something that matters :)
 64 2016-10-27 06:53:12	0|wumpus|luke-jr: ah yes, white-space steganogrpaphy
 65 2016-10-27 06:53:29	0|btcdrak|haha yes.
 66 2016-10-27 06:53:29	0|btcdrak|well again, I found changing a 1 to a 2 isnt that straight forward....
 67 2016-10-27 06:53:50	0|btcdrak|wumpus: can you restart https://travis-ci.org/bitcoin/bitcoin/builds/170827031, dunno why Travis borked
 68 2016-10-27 06:54:20	0|luke-jr|wumpus: do you have any expectation of further merges before tagging?
 69 2016-10-27 06:54:38	0|wumpus|luke-jr: if there are further improvements to the release notes
 70 2016-10-27 06:55:41	0|wumpus|otherwise, no
 71 2016-10-27 07:06:17	0|jonasschnelli|Do we follow a code-convention for instance variables? I guess we don't want this->var? Also, the prefixes (mapX, fX, etc.) are also used for non instance vars. What about using _Var for instance variables? Acceptable?
 72 2016-10-27 07:06:33	0|jonasschnelli|s/_Var/_var
 73 2016-10-27 07:07:53	0|luke-jr|I'd rather 'var' than '_var' for public stuff at least
 74 2016-10-27 07:08:04	0|luke-jr|I don't see a problem with o->var or o->fVar
 75 2016-10-27 07:15:30	0|jonasschnelli|Luke-Jr: my problems is, that the code is really not easy readable if you don't highlight instance variable in some form.
 76 2016-10-27 07:15:53	0|jonasschnelli|this-> clusters to code to much IMO, ... using _var seems acceptable to me.
 77 2016-10-27 07:16:19	0|jonasschnelli|Using fVar, etc. will not increase readability because we are also using this for non-instance vars (function parameters, etc.)
 78 2016-10-27 07:16:24	0|luke-jr|we're already using _var for local variables to avoid shadowing :/
 79 2016-10-27 07:17:15	0|jonasschnelli|argh... I though we are using _var for instance vars to avoid shadowing... do we also use _var in local scope?!
 80 2016-10-27 07:17:45	0|luke-jr|I didn't look at all cases explicitly, but when I encountered merge conflicts due to the shadowing changes, _var was always the local scope
 81 2016-10-27 07:29:12	0|wumpus|no, we have no naming convention for instance variables, just use whatever makes sense in the context
 82 2016-10-27 07:29:58	0|jonasschnelli|I personally like this-> but I know most people don't like that
 83 2016-10-27 07:30:05	0|jonasschnelli|I'll try _
 84 2016-10-27 07:30:12	0|wumpus|at least the qt coding convention recommends against using m_ or _ or such
 85 2016-10-27 07:31:08	0|jonasschnelli|The m prefix would not allow to use the fVar, etc. prefix.
 86 2016-10-27 07:31:15	0|jonasschnelli|mfBool would look strange. :)
 87 2016-10-27 07:31:20	0|jonasschnelli|i'd prefere _fBool
 88 2016-10-27 07:31:23	0|wumpus|m_fBool that would be, then
 89 2016-10-27 07:31:31	0|jonasschnelli|m_ yes... why not
 90 2016-10-27 07:31:57	0|sipa|wumpus: what does the qt coding convention suggest?
 91 2016-10-27 07:32:14	0|wumpus|sipa: no specific one, just use this->name where necessary
 92 2016-10-27 07:32:34	0|wumpus|in many cases there's no need to name instance variables any differently from local variables
 93 2016-10-27 07:33:04	0|jonasschnelli|wumpus: readability?
 94 2016-10-27 07:33:06	0|sipa|luke-jr: where do we use _var for local variables?
 95 2016-10-27 07:33:08	0|wumpus|e.g. https://forum.qt.io/topic/150/member-variable-naming-convention-in-qt-and-the-qtdn-wiki
 96 2016-10-27 07:33:36	0|wumpus|jonasschnelli: I think usually it should be clear from the context what is a member variable and what is not, there's not much of a need to flag them
 97 2016-10-27 07:33:45	0|sipa|luke-jr: underscores are used in several places for formal parameters to avoid colliding with field variables
 98 2016-10-27 07:33:48	0|wumpus|but I don't know, I hate these kind of discussions
 99 2016-10-27 07:33:59	0|jonasschnelli|Reading through new code i often found myself checking if the variable is local or instance-wide
100 2016-10-27 07:34:00	0|sipa|haha
101 2016-10-27 07:34:04	0|jonasschnelli|heh
102 2016-10-27 07:34:36	0|sipa|jonasschnelli: if the function body is not too long, it's usually pretty easy to see if there is a local variable with that name
103 2016-10-27 07:34:48	0|jonasschnelli|sipa: yes. If. now open main.cpp. :)
104 2016-10-27 07:34:55	0|wumpus|jonasschnelli: that probably means the code itself is badly commented / structured
105 2016-10-27 07:35:15	0|wumpus|a shallow 'fix' like renaming instance variables won't help much in that case except check a checkbox
106 2016-10-27 07:36:31	0|sipa|jonasschnelli: so help refactoring those functions to be morw readable :)
107 2016-10-27 07:36:33	0|wumpus|the superlative of adding metadata into variable names is something crazy like Hungarian notation, and I don't think that makes code anything easier to read
108 2016-10-27 07:37:02	0|wumpus|it's the typical pointy-haired boss solution to
109 2016-10-27 07:37:07	0|wumpus|"code is unreadable"
110 2016-10-27 07:37:10	0|wumpus|FORCE a coding style!
111 2016-10-27 07:37:57	0|wumpus|now you have nicely formatted ununderstandable code :)
112 2016-10-27 07:38:19	0|sipa|i realize that i know what pointy-haired-boss means in the context of dilbert, but not in real life. Do posses have pointy hair stereotypically?
113 2016-10-27 07:38:32	0|gmaxwell|if style differences are making code much less readable for you, sounds like an oppturnity to refine your reading skills. :)  -- there are obviously extreme examples, codebases that mangle everything with macros and other insanity. :P  But really, a casual approach is best.
114 2016-10-27 07:39:17	0|wumpus|sipa: I don't think so, it's just the dilbert stereotype, it doesn't have anything to do with hair :-)
115 2016-10-27 07:41:02	0|dcousens|gmaxwell: certainly syntax can get in the way,  but,  majority of the time,  readability is more about a reduction in complexity than consistently spacing things.
116 2016-10-27 07:41:17	0|dcousens|improving readability*
117 2016-10-27 07:41:52	0|wumpus|sipa: I think the gist is doing something for the sake of it being easy to enforce/check something, because the boss feels more in control that way and it superficiously looks like progress
118 2016-10-27 07:42:15	0|gmaxwell|I wondered if perhaps PHB predated dilbert and dilbert was riffing off it, ... but I'd forgotten how old dilber is .. (1980-04)
119 2016-10-27 07:44:26	0|wumpus|now we've done it, we're slacking off and discussing dilbert, we should come up with a business metric for IRC messages and employees should be rated on the number of on-topic IRC messages </s>
120 2016-10-27 07:47:26	0|wumpus|time to tag 0.13.1 final?
121 2016-10-27 07:47:49	0|sipa|i'm about to fall asleep
122 2016-10-27 07:48:04	0|wumpus|I'll wait until you're asleep then
123 2016-10-27 07:48:08	0|dcousens|ha
124 2016-10-27 07:48:38	0|wumpus|NN
125 2016-10-27 07:59:57	0|gmaxwell|wumpus: all we need to is train some machine learning to read IRC and correlate that with commits, assigning score to IRC messages that come shortly before more commits.
126 2016-10-27 08:00:34	0|gmaxwell|After we make the high scoreholder, Github151, in charge of the project I'm sure things will run much better.
127 2016-10-27 08:00:50	0|gmaxwell|FWIW, my testing with RC3 all looks fine.
128 2016-10-27 08:01:29	0|wumpus|hahahaa yes Github151 for president
129 2016-10-27 08:05:07	0|gmaxwell|many states require a write in candidate register with them before being eligible to be counted. :(
130 2016-10-27 08:05:40	0|luke-jr|I was joking anyway :p
131 2016-10-27 08:05:51	0|gmaxwell|I think this is intended to help avoid "Which John Smith did we just elect?"
132 2016-10-27 08:06:31	0|luke-jr|heh
133 2016-10-27 08:09:23	0|luke-jr|of course, that wouldn't explain why real candidates are not allowed to register for write-in in some States (IIRC mainly NY and CA), but we're getting a bit too far off-topic I think
134 2016-10-27 08:11:21	0|wumpus|maybe they should use a blockchain for registering candidates *ducks*
135 2016-10-27 08:11:40	0|luke-jr|sadly, some people think that makes sense
136 2016-10-27 08:13:40	0|gmaxwell|wumpus: so, final?
137 2016-10-27 08:22:44	0|wumpus|yes, let's do it
138 2016-10-27 08:22:47	0|wumpus|sipa's asleep
139 2016-10-27 08:25:07	0|wumpus|* [new tag]         v0.13.1 -> v0.13.1
140 2016-10-27 08:25:16	0|gmaxwell|\O/
141 2016-10-27 08:25:49	0|luke-jr|oh wow, rc3 just deleted my entire home directory …………….. jk :P
142 2016-10-27 08:26:55	0|gmaxwell|cool "0.13.1 addresses user's concerns with excessive disk space consumption."
143 2016-10-27 08:28:08	0|wumpus|hehe, always the positive side
144 2016-10-27 08:28:15	0|luke-jr|lol
145 2016-10-27 08:28:28	0|jonasschnelli|heh
146 2016-10-27 08:28:31	0|warren|that sounds like one particular user had concerns
147 2016-10-27 08:32:34	0|jonasschnelli|huh! Why can this happen: http://paste.ubuntu.com/23387379/
148 2016-10-27 08:34:10	0|wumpus|huh, that looks like a bug in assertlockheld
149 2016-10-27 08:34:12	0|jonasschnelli|maybe a different wallet instance...
150 2016-10-27 08:34:19	0|wumpus|ah yes ofcourse
151 2016-10-27 08:34:49	0|wumpus|maybe the lock naming should include instance pointer
152 2016-10-27 08:35:02	0|jonasschnelli|Yes. My fault... different instances
153 2016-10-27 08:36:51	0|luke-jr|hm, I didn't encounter such issues with multiwallet? O.o
154 2016-10-27 08:40:45	0|wumpus|did you run with lock debugging on?
155 2016-10-27 08:41:26	0|wumpus|(--enable-debug will do)
156 2016-10-27 08:44:04	0|luke-jr|no
157 2016-10-27 08:44:16	0|luke-jr|does the assertlockheld only work with that?
158 2016-10-27 08:44:33	0|wumpus|yes
159 2016-10-27 08:51:42	0|wumpus|it uses the same data structures as the lock order checks, there's a fair amount of overhead in tracking locks at run-time so it is not enabled in release builds
160 2016-10-27 09:08:00	0|michagogo|🎉🎊
161 2016-10-27 09:09:41	0|wumpus|wake-over-IRC?
162 2016-10-27 09:37:28	0|michagogo|wumpus: wake-over-iMessage
163 2016-10-27 09:37:41	0|michagogo|(Poweron, really)
164 2016-10-27 09:37:56	0|michagogo|Anyway, build running now
165 2016-10-27 09:38:11	0|michagogo|As usual, sigs will auto-PR
166 2016-10-27 09:40:59	0|michagogo|I wonder how quickly we'll get sigs
167 2016-10-27 09:41:09	0|michagogo|Think release will come today?
168 2016-10-27 10:13:30	0|GitHub161|[13bitcoin] 15s-matthew-english opened pull request #9029: instance of 'mem pool' to 'mempool' (06master...06patch-7) 02https://github.com/bitcoin/bitcoin/pull/9029
169 2016-10-27 10:19:56	0|michagogo|Ooh, just got my hacktoberfest email
170 2016-10-27 10:24:04	0|gmaxwell|https://blockchain.info/charts/utxo-count?timespan=60days  and fees are back down to ~0.5 btc/block...
171 2016-10-27 10:39:30	0|GitHub174|[13bitcoin] 15rebroad opened pull request #9030: Don't process blocktxns when we have the block already. (06master...06BlocktxnExits) 02https://github.com/bitcoin/bitcoin/pull/9030
172 2016-10-27 10:46:17	0|gmaxwell|andytoshi: wumpus: http://seriot.ch/parsing_json.html  < json test vectors.
173 2016-10-27 10:48:29	0|wumpus|gmaxwell: yeah came up earlier today already there's even an issue :) https://github.com/bitcoin/bitcoin/issues/9028
174 2016-10-27 11:18:02	0|jonasschnelli|Just got a report that prioritisetransaction does not work on 0.12?
175 2016-10-27 11:18:38	0|wumpus|on 0.12? or 0.13?
176 2016-10-27 11:19:10	0|jonasschnelli|The reporter reported its working on 0.13 but not on 0.12
177 2016-10-27 11:20:55	0|luke-jr|do we care then?
178 2016-10-27 11:22:43	0|wumpus|I don't
179 2016-10-27 11:22:54	0|wumpus|was briefly in shock because of 0.13.1 :)
180 2016-10-27 11:25:31	0|luke-jr|jonasschnelli: the reporter is a miner? why aren't they on 0.13.0?
181 2016-10-27 11:25:49	0|luke-jr|sounds suspiciously like BU
182 2016-10-27 11:26:02	0|wumpus|yea
183 2016-10-27 11:31:45	0|jonasschnelli|i don't care as well
184 2016-10-27 11:32:18	0|jonasschnelli|but good to know >if< 0.12 is not working and if so, why 0.13 is working
185 2016-10-27 11:34:48	0|Victorsueca|0.12 is supposed to be still supported, should we backport a fix for this?
186 2016-10-27 11:35:11	0|wumpus|if someone writes a fix I'm happy to merge it
187 2016-10-27 11:36:23	0|luke-jr|Eligius didn't use 0.12 for long, but I am pretty certain prioritise worked
188 2016-10-27 11:37:47	0|luke-jr|(and I do check GBT returns the txid when I prioritise stuff)
189 2016-10-27 11:38:02	0|luke-jr|so IMO it's probably either BU nonsense or PEBKAC
190 2016-10-27 11:52:19	0|jonasschnelli|first we would need to double-check if its not working on 0.12. It was just a report.
191 2016-10-27 11:52:50	0|jonasschnelli|There are some RPC tests.. although not sure when we have added those.
192 2016-10-27 12:05:14	0|wumpus|I'm surprised if it really doesn't work and we only hear about it now
193 2016-10-27 12:10:31	0|GitHub57|[13bitcoin] 15laanwj opened pull request #9032: test: Add format-dependent comparison to bctest (06master...062016_10_bctest_smart_compare) 02https://github.com/bitcoin/bitcoin/pull/9032
194 2016-10-27 12:11:33	0|wumpus|btcdrak: https://github.com/bitcoin/bitcoin/pull/9032
195 2016-10-27 12:14:05	0|btcdrak|wumpus: interesting
196 2016-10-27 12:14:25	0|wumpus|I'm not even sure the second step should be a fatal error or just a warning
197 2016-10-27 12:14:47	0|wumpus|a_meteorite: please fix your IRC client, you're generating too many join/part messages
198 2016-10-27 12:14:52	0|btcdrak|wumpus: this was really helpful
199 2016-10-27 12:14:53	0|btcdrak|https://github.com/bitcoin/bitcoin/pull/9023
200 2016-10-27 12:15:43	0|wumpus|yes, but I think it makes the test too noisy in the pass case
201 2016-10-27 12:15:59	0|wumpus|printing a diff when the test fails makes sense though
202 2016-10-27 12:16:39	0|btcdrak|maybe should shield the pass stuff with a -verbose flag? or ditch the pass logs entirely?
203 2016-10-27 12:17:09	0|wumpus|yes I'd say ditch the pass logs, ideally tests are silent if nothing is wrong
204 2016-10-27 12:17:12	0|wumpus|(esp in travis)
205 2016-10-27 12:19:47	0|wumpus|btcdrak: this may be already what it does, I was confused by all the logging stuff
206 2016-10-27 12:20:30	0|luke-jr|poor a_meteorite is going to fall to Earth
207 2016-10-27 12:20:35	0|btcdrak|iirc it prints pass and fail. lemme rerun quickly
208 2016-10-27 12:21:00	0|wumpus|luke-jr: hah
209 2016-10-27 12:21:06	0|wumpus|btcdrak: but also in non-verbose mode?
210 2016-10-27 12:21:33	0|btcdrak|ok just checked, by default passes are silent
211 2016-10-27 12:21:43	0|btcdrak|if you add -v then you get full output
212 2016-10-27 12:21:50	0|wumpus|ok, and diffs are printed on failure?
213 2016-10-27 12:21:58	0|btcdrak|https://www.irccloud.com/pastebin/fuxIut4y/
214 2016-10-27 12:22:28	0|wumpus|even in non-verbose mode?
215 2016-10-27 12:24:12	0|btcdrak|oh wait, my cherry-pick failed and I didnt notice :-p
216 2016-10-27 12:24:25	0|wumpus|gah
217 2016-10-27 12:24:33	0|btcdrak|so it is noisy without -v
218 2016-10-27 12:24:39	0|btcdrak|https://www.irccloud.com/pastebin/hd69OPZ4/
219 2016-10-27 12:24:41	0|wumpus|sigh
220 2016-10-27 12:25:50	0|GitHub48|[13bitcoin] 15MarcoFalke reopened pull request #9011: 0.13.2 backports (060.13...062016_10_backports_conditional_rc3) 02https://github.com/bitcoin/bitcoin/pull/9011
221 2016-10-27 12:26:46	0|btcdrak|wumpus: I commented too
222 2016-10-27 12:28:05	0|btcdrak|wumpus: otherwise the errors are great e.g.
223 2016-10-27 12:28:07	0|btcdrak|https://www.irccloud.com/pastebin/xL5cqNGo/
224 2016-10-27 12:29:37	0|achow101|oh hey, a tag!
225 2016-10-27 12:29:42	0|wumpus|yes that seems useful
226 2016-10-27 12:31:26	0|GitHub163|[13bitcoin] 15MarcoFalke opened pull request #9033: Update build notes for dropping osx 10.7 support (fanquake) (06master...06Mf1610-docFanquake) 02https://github.com/bitcoin/bitcoin/pull/9033
227 2016-10-27 12:38:50	0|wumpus|btcdrak: does -v actually work for you?
228 2016-10-27 12:39:11	0|btcdrak|wumpus: it doesnt do anything different under his patch
229 2016-10-27 12:39:13	0|wumpus|I moved the PASSED messages to the debug level, but now I can't get them to output at all
230 2016-10-27 12:41:30	0|btcdrak|same here, hmm
231 2016-10-27 12:42:24	0|wumpus|figured it out
232 2016-10-27 12:56:25	0|GitHub49|13bitcoin/060.13 142e2388a 15Wladimir J. van der Laan: Move release notes to release-notes/release-notes-0.13.1.md...
233 2016-10-27 12:56:25	0|GitHub49|[13bitcoin] 15laanwj pushed 1 new commit to 060.13: 02https://github.com/bitcoin/bitcoin/commit/2e2388a5cbb9a6e101b36e4501698fec538a5738
234 2016-10-27 12:58:50	0|GitHub138|13bitcoin/06master 14a49b4a7 15Wladimir J. van der Laan: doc: Add release notes for 0.13.1 release
235 2016-10-27 12:58:50	0|GitHub138|[13bitcoin] 15laanwj pushed 1 new commit to 06master: 02https://github.com/bitcoin/bitcoin/commit/a49b4a75a1b671492e65eed17d6894d85ea5ebfd
236 2016-10-27 12:59:35	0|timothy|does 0.13.1 requires new or different libraries?
237 2016-10-27 12:59:40	0|timothy|to built
238 2016-10-27 12:59:41	0|GitHub66|13bitcoin/06master 14ba26d41 15Michael Ford: Update build notes for dropping osx 10.7 support...
239 2016-10-27 12:59:41	0|GitHub66|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/a49b4a75a1b6...83234d4d1723
240 2016-10-27 12:59:42	0|GitHub66|13bitcoin/06master 1483234d4 15Wladimir J. van der Laan: Merge #9033: Update build notes for dropping osx 10.7 support (fanquake)...
241 2016-10-27 12:59:49	0|wumpus|compared to what?
242 2016-10-27 12:59:50	0|GitHub134|[13bitcoin] 15laanwj closed pull request #9033: Update build notes for dropping osx 10.7 support (fanquake) (06master...06Mf1610-docFanquake) 02https://github.com/bitcoin/bitcoin/pull/9033
243 2016-10-27 12:59:52	0|timothy|0.13.0
244 2016-10-27 13:00:08	0|wumpus|yes there was at least a patch to boost
245 2016-10-27 13:00:20	0|timothy|so can't I use vanilla boost?
246 2016-10-27 13:00:33	0|wumpus|sure, you always can
247 2016-10-27 13:00:58	0|wumpus|I thought you were talking about the gitian build, if you build using your OS' libraries there no need to do anything special
248 2016-10-27 13:19:37	0|whphhg|Hej, is there a Bitcoin Unlimited channel on freenode?
249 2016-10-27 13:23:17	0|timothy|lol
250 2016-10-27 13:23:30	0|rabidus_|lol
251 2016-10-27 13:23:39	0|timothy|it's like entering on FBI channel and ask for drug
252 2016-10-27 13:26:45	0|PatBoy|hahahah
253 2016-10-27 13:29:25	0|wumpus|rofl
254 2016-10-27 13:33:22	0|whphhg|Lol, I wasn't aware it was that bad. :o
255 2016-10-27 13:39:41	0|BlueMatt|wumpus: so do i wait to update the ppa or just do it today?
256 2016-10-27 13:41:28	0|wumpus|BlueMatt: let me see, how many gitian sigs do we have now
257 2016-10-27 13:42:19	0|wumpus|three matching ones
258 2016-10-27 13:42:44	0|BlueMatt|i said today, not now....still eating breakfast :p
259 2016-10-27 13:42:46	0|wumpus|but no code-signed ones yet. I guess it's somewhat strange to have the ppa built before the binaries available
260 2016-10-27 13:43:15	0|btcdrak|Better not do it until the release actual announcement when we have everything done.
261 2016-10-27 13:48:02	0|BlueMatt|btcdrak: meh, i often do it early...otherwise i forget
262 2016-10-27 13:51:58	0|Lauda|BlueMatt please ppa as soon as possible 0.13.0 took forever. :)
263 2016-10-27 13:57:47	0|btcdrak|Lauda: good point :-p
264 2016-10-27 14:03:53	0|michagogo|BlueMatt: is it all ready in terms of packaging, i.e. just a matter of pushing the button?
265 2016-10-27 14:04:35	0|michagogo|(Also, how long on average does it take from the time you push the build up until the server farm actually builds and publishes it?)
266 2016-10-27 14:06:18	0|michagogo|If it's done with a command, you could avoid forgetting by setting a cronjob (or just a screen/tmux with a `sleep &&`) to do it in 24 hours
267 2016-10-27 14:06:21	0|michagogo|Or 48 or something
268 2016-10-27 14:07:11	0|michagogo|(Also, it's unfortunate that only cfields_ can produce the detached sigs…)
269 2016-10-27 14:10:55	0|btcdrak|wumpus: I uploaded my gitian sigs
270 2016-10-27 14:11:24	0|BlueMatt|michagogo: naa, need to do a few things first, then its like within 20-30 minutes after upload that they're all built and available
271 2016-10-27 14:16:51	0|michagogo|wumpus: re: #9028 (and in general), have you considered tagging some issues for Hacktoberfest?
272 2016-10-27 14:17:04	0|BlueMatt|'tf is hacktoberfest?
273 2016-10-27 14:17:14	0|michagogo|;;Google hacktoberfest
274 2016-10-27 14:17:15	0|gribble|Hacktoberfest 2016 - DigitalOcean: <https://hacktoberfest.digitalocean.com/>; Hacktoberfest is back · GitHub: <https://github.com/blog/2260-hacktoberfest-is-back>; # hacktoberfest hashtag on Twitter: <https://twitter.com/hashtag/hacktoberfest>
275 2016-10-27 14:17:24	0|BlueMatt|also, isnt october over?
276 2016-10-27 14:17:43	0|michagogo|Well, almost
277 2016-10-27 14:41:06	0|wumpus|would be a bit too late I guess
278 2016-10-27 14:42:33	0|wumpus|(for hacktoberfest)
279 2016-10-27 14:42:49	0|wumpus|woohoo, 6 sigs all match
280 2016-10-27 14:43:10	0|wumpus|ping cfields_
281 2016-10-27 14:47:36	0|GitHub55|13bitcoin/06master 141c3ecc7 15S. Matthew English: instance of 'mem pool' to 'mempool'...
282 2016-10-27 14:47:36	0|GitHub55|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/83234d4d1723...fea5e05a6380
283 2016-10-27 14:47:37	0|GitHub55|13bitcoin/06master 14fea5e05 15Wladimir J. van der Laan: Merge #9029: instance of 'mem pool' to 'mempool'...
284 2016-10-27 14:47:46	0|GitHub196|[13bitcoin] 15laanwj closed pull request #9029: instance of 'mem pool' to 'mempool' (06master...06patch-7) 02https://github.com/bitcoin/bitcoin/pull/9029
285 2016-10-27 14:56:24	0|sipa|BlueMatt: Oktoberfest is also mostly not in october :)
286 2016-10-27 14:56:48	0|BlueMatt|heh, true
287 2016-10-27 15:04:40	0|andytoshi|thanks gmaxwell (re json test vectors)
288 2016-10-27 15:12:59	0|kanzure|andytoshi: trying to save yourself some work on mimblewimble?
289 2016-10-27 16:10:56	0|btcdrak|seems like the binaries will be ready today?
290 2016-10-27 18:45:03	0|NicolasDorier|mmh... well, I'll wait I reach later block mayb it's not the case
291 2016-10-27 19:00:37	0|jtimon|meeting...
292 2016-10-27 19:01:17	0|wumpus|congrats on 0.13.1 everyone!
293 2016-10-27 19:01:23	0|wumpus|#startmeeting
294 2016-10-27 19:01:24	0|lightningbot|Meeting started Thu Oct 27 19:01:23 2016 UTC.  The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
295 2016-10-27 19:01:24	0|lightningbot|Useful Commands: #action #agreed #help #info #idea #link #topic.
296 2016-10-27 19:01:27	0|jtimon|0.13.1 is out 18 mins ago! yay
297 2016-10-27 19:01:41	0|CodeShark|binaries?
298 2016-10-27 19:01:42	0|kanzure|btcdrak: looks like faq menu entry is working now https://bitcoincore.org/en/2016/10/27/segwit-upgrade-guide/
299 2016-10-27 19:01:59	0|jeremyrubin|here
300 2016-10-27 19:02:27	0|wumpus|CodeShark: https://bitcoin.org/bin/bitcoin-core-0.13.1/
301 2016-10-27 19:02:46	0|CodeShark|Nice!
302 2016-10-27 19:02:49	0|gmaxwell|https://www.reddit.com/r/Bitcoin/comments/59pt66/bitcoin_core_0131_released/
303 2016-10-27 19:03:04	0|wumpus|or magnet:?xt=urn:btih:dbe48c446b1113890644bbef03e361269f69c49a&dn=bitcoin-core-0.13.1&tr=udp%3A%2F%2Ftracker.openbittorrent.com%3A80%2Fannounce&tr=udp%3A%2F%2Ftracker.publicbt.com%3A80%2Fannounce&tr=udp%3A%2F%2Ftracker.ccc.de%3A80%2Fannounce&tr=udp%3A%2F%2Ftracker.coppersurfer.tk%3A6969&tr=udp%3A%2F%2Ftracker.leechers-paradise.org%3A6969&ws=https%3A%2F%2Fbitcoin.org%2Fbin%2F
304 2016-10-27 19:03:52	0|wumpus|bitcoin.org should be updated after travis passes on https://github.com/bitcoin-dot-org/bitcoin.org/pull/1400
305 2016-10-27 19:04:25	0|morcos|congrats everyone!
306 2016-10-27 19:04:31	0|sipa|indeed!
307 2016-10-27 19:04:53	0|wumpus|woohoo!
308 2016-10-27 19:05:04	0|sipa|and thanks everyone for getting us this far
309 2016-10-27 19:05:37	0|luke-jr|wumpus: did we get the gitian builds already? is that a record? :o
310 2016-10-27 19:05:54	0|wumpus|luke-jr: yes, four signed builders IIRC
311 2016-10-27 19:06:25	0|luke-jr|or maybe it just feels like a record since it was the middle of the night for me
312 2016-10-27 19:06:30	0|jtimon|I'm trying the gitian builder script for the first time
313 2016-10-27 19:06:34	0|wumpus|it may be a record
314 2016-10-27 19:06:43	0|wumpus|very fast at least
315 2016-10-27 19:07:09	0|jtimon|btcdrak reminded me I have no good excuse for not doing gitian builds
316 2016-10-27 19:07:33	0|sipa|i haven't even started :(
317 2016-10-27 19:08:20	0|jtimon|well, I have never done it so it may take some time, but the sooner I learn...
318 2016-10-27 19:08:22	0|btcdrak|wumpus: I dont see a signed message from you with the binary hashes
319 2016-10-27 19:08:44	0|wumpus|BlueMatt: you can release your PPA now (if you didn't yet)
320 2016-10-27 19:09:03	0|wumpus|btcdrak: https://bitcoin.org/bin/bitcoin-core-0.13.1/SHA256SUMS.asc
321 2016-10-27 19:09:05	0|BlueMatt|wumpus: i have not yet, will try to get that out
322 2016-10-27 19:09:24	0|jonasschnelli|BlueMatt: don't forget to add libzmq
323 2016-10-27 19:09:35	0|harding|btcdrak: https://lists.linuxfoundation.org/pipermail/bitcoin-core-dev/2016-October/000023.html
324 2016-10-27 19:09:37	0|jonasschnelli|Some uses have complained about the missing ZMQ support
325 2016-10-27 19:10:13	0|BlueMatt|jonasschnelli: yup
326 2016-10-27 19:11:30	0|wumpus|ok, any other topics today than 0.13.1?
327 2016-10-27 19:11:51	0|kanzure|i was going to ask sipa or jtimon about libconsensus follow-up stuff
328 2016-10-27 19:12:04	0|sipa|i'm the wrong person to ask
329 2016-10-27 19:12:16	0|wumpus|I'm kind of tired so I wouldn't mind ending early :p
330 2016-10-27 19:12:59	0|jtimon|kanzure: nothing to report, nobody suggested anything to me or gave me any feedback since last week
331 2016-10-27 19:13:05	0|gmaxwell|#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
332 2016-10-27 19:13:24	0|BlueMatt|few minutes late there, gmaxwell
333 2016-10-27 19:13:27	0|jtimon|been focusing on the signedblocks patch
334 2016-10-27 19:13:32	0|gmaxwell|Just noticed wumpus hadn't done it. :)
335 2016-10-27 19:13:44	0|sipa|maybe we can discuss signed blocks a bit
336 2016-10-27 19:13:51	0|gmaxwell|So there are a number of things we want to do in a 0.13.2; so those should get in soon.
337 2016-10-27 19:14:06	0|morcos|i'm interested in discussing that, because i want to understand whether this is meant to replace the existing testnet or just be another option
338 2016-10-27 19:14:10	0|morcos|(signed blocks)
339 2016-10-27 19:14:12	0|gmaxwell|(I guess some are in and just need to backport to 0.13 branch.
340 2016-10-27 19:14:21	0|wumpus|no, it's not meant to replace the current testnet
341 2016-10-27 19:14:24	0|kanzure|re: testnet i also saw the suggestion of loading testnet params from json file
342 2016-10-27 19:14:31	0|jtimon|fine with me, I still extremely dsilike having to use a global, but don't see other way around it if we want to use the union
343 2016-10-27 19:14:51	0|gmaxwell|morcos: my expectation was that it would just be another option. Obviously it would be useless for testing much of anything mining related.
344 2016-10-27 19:15:11	0|jtimon|what I have implemented is from .conf file, not .json file
345 2016-10-27 19:15:12	0|wumpus|indeed there should at least be a PoW testnet
346 2016-10-27 19:15:28	0|morcos|ok, i think its still important that we have a well used testnet that uses PoW as similarly to mainnet as possible..  i worry that there is kind of only going to be one "testnet" that people use for most purposes though
347 2016-10-27 19:15:47	0|morcos|perhaps it would be possible for transactions to easily end up on both?
348 2016-10-27 19:15:49	0|kanzure|jtimon: didn't mean to recommend a specific file format; i was just pulling a thing from memory.
349 2016-10-27 19:16:05	0|morcos|but maybe thats askign for trouble
350 2016-10-27 19:16:06	0|wumpus|yes the file format is completely not important
351 2016-10-27 19:16:14	0|jtimon|I'm still trying to test the blocksigning stuff, but the "custom chain" code that preceeds it is pretty much ready I think (feel free to test it and give suggestions), see https://github.com/bitcoin/bitcoin/pull/8994
352 2016-10-27 19:16:16	0|sipa|morcos: i think the issue is that 'testnet' can mean "a place where we test new network features, and subject it to huge reorgs, and other edge cases" or "a place where we expect companies to build a parallel infrastructure"
353 2016-10-27 19:16:28	0|cfields_|adding to that, see the faux-mining mode added in the #9000 PR. That was crucial for me for real-world mining testing of segwit.
354 2016-10-27 19:16:31	0|sipa|and those aren't reconcilable, i think
355 2016-10-27 19:16:57	0|jtimon|that alone should be helpful for rapidly creating a new segwitnet (for the next thing) or whatever
356 2016-10-27 19:17:03	0|btcdrak|Blog post is up https://bitcoincore.org/en/2016/10/27/release-0.13.1/
357 2016-10-27 19:17:13	0|wumpus|one testnet is simply not enough for all testing scenarios
358 2016-10-27 19:17:16	0|gmaxwell|morcos: alas, I don't think htats really possible. Right now the consensus insability of testnet causes some people to just not test on it.
359 2016-10-27 19:17:20	0|wumpus|btcdrak: awesome
360 2016-10-27 19:17:32	0|kanzure|re: company testing, i have been (lightly) planning to use regtest for those purposes. e.g. company-to-company regtest instances.   testnet is still important for testing of course.
361 2016-10-27 19:18:07	0|wumpus|kanzure: right - within a trusted group using a regtest is just as useful as signed blocks
362 2016-10-27 19:18:25	0|kanzure|oh is that what the proposal is-- i'll have to go look. sorry.
363 2016-10-27 19:18:45	0|wumpus|it's only when exposing publicly that signing is necessary so people can't grief by generating e.g. tons of blocks
364 2016-10-27 19:19:30	0|gmaxwell|morcos: the issue is that while not ideal, on mainnet a reasonable way of handling very large reorgs is to shut your site down and wait for the operator to manually do something about it. If you try that strategy on testnet, your service will just be down all the time.
365 2016-10-27 19:19:38	0|kanzure|so for the company-to-company testing scenario, my assumption was you simply limit the number of participants to one other group, and then you know who is causing problems (either you or the other guys). still, i can see some advantages to public regtesting. sure.
366 2016-10-27 19:19:57	0|JackH|when will ubuntu ppa's be updated?
367 2016-10-27 19:20:17	0|BlueMatt|JackH: when i get to it (today)
368 2016-10-27 19:20:30	0|JackH|ah sweet, you are fast this time then
369 2016-10-27 19:20:31	0|sipa|btcdrak: nice, the timeline is cool
370 2016-10-27 19:21:26	0|luke-jr|BlueMatt: btw, is it possible/easy to do a PPA with Knots as well? (is it something I can do reasonably myself perhaps?)
371 2016-10-27 19:21:56	0|wumpus|I think everyone can sign up to make PPAs
372 2016-10-27 19:22:52	0|BlueMatt|luke-jr: its not bad
373 2016-10-27 19:22:55	0|kanzure|without signedblocks, if you had three companies trying to test an integration, you would need multiple different regtest links and to relay blocks from one network to the other with a different signature. i could see how that would be annoying to write. yeah..
374 2016-10-27 19:23:03	0|luke-jr|wumpus: yes, it's just not very clear how one would actually make them, especially someone who doesn't use Ubuntu :p
375 2016-10-27 19:25:07	0|Frederic94500|#bitcoin If segwit doesn't activate, he will be activate to the next 2016 blocks?
376 2016-10-27 19:25:29	0|sipa|parse error
377 2016-10-27 19:25:31	0|jtimon|one thing about #8994 related to wumpus' point about regtest among trusted peers... one can select -chain=custom -chainpetname=mysharedsecret and people without access to mysharedsecret  won't be able to create the genesis block locally
378 2016-10-27 19:25:44	0|BlueMatt|Frederic94500: we're in the middle of a meeting, please go to #bitcoin
379 2016-10-27 19:26:01	0|jtimon|for the hash of the genesis block depends on -chainpetname
380 2016-10-27 19:26:06	0|wumpus|luke-jr: in a way it's similar to travis, you have to configure the environment and the building happens on their build servers
381 2016-10-27 19:26:17	0|wumpus|luke-jr: no need to run ubuntu yourself
382 2016-10-27 19:26:36	0|jonasschnelli|Luke-Jr: there are also meta-generator that auto-generated deb/PPA and fedora, etc. out of one script/conf
383 2016-10-27 19:26:48	0|BlueMatt|wumpus: only in theory....the upload tool stuff is really a bitch to get installed on non-debian systems
384 2016-10-27 19:26:55	0|luke-jr|:x
385 2016-10-27 19:27:25	0|wumpus|BlueMatt: haha that's sad, I didn't know
386 2016-10-27 19:27:35	0|petertodd|jtimon: I like the idea of a shared secret vs. pubkey based testnet, as it makes it clear that it's only for testing, not doing some kind of "bankchain" sillyness
387 2016-10-27 19:28:05	0|jtimon|well, signed blocks have other advantages for testing, but it's definitely more dsiruptive
388 2016-10-27 19:28:16	0|wumpus|bitcoin.org change is merged
389 2016-10-27 19:29:08	0|petertodd|jtimon: also, a hmac based thing may be easier to implement it - can be done by just changing the most-work chain test to require XOR key == 0; doesn't require any datastructures to change
390 2016-10-27 19:29:42	0|jtimon|you can just share a chainparams.conf file and when if someone decides to load your testnet with too much work, s/mychainname/mychainname2/ and you start again I guess
391 2016-10-27 19:29:47	0|wumpus|right, changing the block header structure is what makes it scary
392 2016-10-27 19:30:54	0|petertodd|wumpus: s/scary/a lot of work/ :)
393 2016-10-27 19:31:12	0|gmaxwell|topic: suggestion final alert stuff.
394 2016-10-27 19:31:13	0|jtimon|petertodd: not hmac, the chainpetname is simply used for the genesis block timestamp (ie replacing "The Times 03/Jan/2009 Chancellor on brink of second bailout for banks"), see https://github.com/bitcoin/bitcoin/pull/8994/commits/ee3a9e4ed986a3aef84b0e081a31d91237d53294
395 2016-10-27 19:31:21	0|wumpus|I mean more s/scary/high risk/
396 2016-10-27 19:31:31	0|sipa|petertodd: it's surprisingly little work, but it's hard to do in a way that is 1) clean 2) runtime selectable 3) reviewable
397 2016-10-27 19:31:35	0|wumpus|the implementation work is not so bad, review, sure
398 2016-10-27 19:31:39	0|sipa|petertodd: pick 2
399 2016-10-27 19:31:51	0|petertodd|fwiw, I use this same kind of hmac auth trick in open timestamps so calendar servers can use clients as a last-ditch backup, without having the servers actually sign anything in a non-repudiatable way
400 2016-10-27 19:31:52	0|jtimon|we could make other chainparams count for the genesis block hash
401 2016-10-27 19:33:11	0|wumpus|I mean introducing some union into CBlockHeader would mean there'd be a risk of regression even in the non-testing case
402 2016-10-27 19:33:26	0|petertodd|wumpus: ah, yes, good point
403 2016-10-27 19:33:28	0|jtimon|petertodd: well, I find it more scary than painful too, at least the way I'm doing it with the union (there's also a less scary way that uses more memory in mainnet and another one that is simply way way way too disruptive)
404 2016-10-27 19:33:46	0|petertodd|wumpus: I'm wrong - that is scary
405 2016-10-27 19:33:52	0|btcdrak|sipa: you have to thank harding! he wrote it all.
406 2016-10-27 19:35:15	0|kanzure|what is remaining re: final alert things?
407 2016-10-27 19:35:25	0|kanzure|was the page on one of the .org sites merged
408 2016-10-27 19:35:55	0|gmaxwell|kanzure: we're not on that toopic now.
409 2016-10-27 19:35:55	0|jtimon|topic suggestion: are we removing the use of checkpoints for progress estimation?
410 2016-10-27 19:36:24	0|gmaxwell|topic suggestion: My work removing checkpoints _completely_.
411 2016-10-27 19:36:45	0|wumpus|#topic removing checkpoints
412 2016-10-27 19:37:24	0|gmaxwell|I have a branch that is removing checkpoints. Haven't totally taken them out yet because I need to replace progress estimation.
413 2016-10-27 19:37:46	0|gmaxwell|It's not hard to do that, just takes a little twiddling.
414 2016-10-27 19:37:51	0|wumpus|that's good news - progress estimation is probably the least interesting use of them
415 2016-10-27 19:38:00	0|gmaxwell|https://github.com/gmaxwell/bitcoin/tree/remove_checkpoints
416 2016-10-27 19:38:01	0|wumpus|yea
417 2016-10-27 19:38:11	0|wumpus|#link https://github.com/gmaxwell/bitcoin/tree/remove_checkpoints
418 2016-10-27 19:38:47	0|gmaxwell|There are three main components:  Removal of checkpoints for IBD test.  This is a no brainer.  Removal of checkpoints for script checking-- this depends on benchmark results, as we discussed perhaps 4 meethings ago. and the third:
419 2016-10-27 19:38:50	0|wumpus|did you run into something difficult / uncertain?
420 2016-10-27 19:39:43	0|gmaxwell|The last use is avoiding header flooding.  I came up with a tidy way to do this, I think, but it requires an implicit consensus change but I think it is very trivial and obviously fine. But likely to delay things.
421 2016-10-27 19:39:44	0|wumpus|what about the DoS protection?
422 2016-10-27 19:40:07	0|wumpus|consensus change, as in a softfork?
423 2016-10-27 19:40:14	0|morcos|do tell
424 2016-10-27 19:40:20	0|gmaxwell|not a softfork. I'm telling.
425 2016-10-27 19:40:38	0|gmaxwell|My changes introduce a constant in chain params which is the known amount of work in the best chain at ~release time.  The IBD check uses this, we've talked about using that before for some checkpoint like things.
426 2016-10-27 19:41:34	0|gmaxwell|So I propose that once we have any header chain that has at least that much work in it, we do not accept any more blocks with difficulty under 16 million-- which is roughly equal to about 10 commercially available mining devices.
427 2016-10-27 19:41:35	0|petertodd|note that from the point of view of consensus this is technically speaking no different than making bitcoin core come with a set of blockchain data
428 2016-10-27 19:41:49	0|jtimon|isn't the minimum difficulty check a softfork?
429 2016-10-27 19:42:07	0|gmaxwell|This is a consenus change because the chain could never fall below difficulty 16 million in the future, but an unobservable one... as observing it would require the difficulty fall below 16 million. :)
430 2016-10-27 19:42:10	0|petertodd|er, gregs #2 thing makes my statement invalid :)
431 2016-10-27 19:42:10	0|wumpus|petertodd: well it wouldn't lock in specific blocks as the checkpoints do
432 2016-10-27 19:42:40	0|jtimon|gmaxwell: yeah, it's a softfork in the pedantic sense
433 2016-10-27 19:42:42	0|petertodd|wumpus: right, I mean, w/o the minimum diff thing, the effect would be no different than ensuring bitcoin core shipped with blockchain data
434 2016-10-27 19:42:45	0|gmaxwell|jtimon: in a sense, but an unobservable one. Yes.
435 2016-10-27 19:42:45	0|jeremyrubin|I don't think that's great...
436 2016-10-27 19:43:04	0|jeremyrubin|Can't difficulty fall that low under a soft fork to a different PoW?
437 2016-10-27 19:43:16	0|jeremyrubin|(not that that should happen)
438 2016-10-27 19:43:19	0|petertodd|jeremyrubin: yes, and at that point your idea of what bitcoin is is so insecure as to be useless
439 2016-10-27 19:43:22	0|gmaxwell|jeremyrubin: then you take out the rule.
440 2016-10-27 19:43:30	0|jtimon|like really imposing the 21 M limit, that was a softfork too, but no need to use bip9 to deploy I guess
441 2016-10-27 19:43:40	0|petertodd|jtimon: +1
442 2016-10-27 19:43:43	0|Chris_Stewart_5|wouldn't that be a hard fork to remove it if it was enforced?
443 2016-10-27 19:43:54	0|gmaxwell|the 16 million number was just a result of a tidy amount with bitmasking that also is really infeasable to attack but also trivial to mine... 10 devices.
444 2016-10-27 19:44:11	0|petertodd|Chris_Stewart_5: yes, removiing is a hard fork, but remember we're talking about a situation where bitcoin as you know it is useless, so tha'ts irrelevant IMO
445 2016-10-27 19:44:24	0|gmaxwell|If someone worried that 16 million were too high, there is a pretty broad range that the number could reasonable be set in.
446 2016-10-27 19:44:55	0|petertodd|gmaxwell: honestly, I'd be inclined to go even higher - 10 machines is absolutely nothing
447 2016-10-27 19:45:18	0|gmaxwell|Anything over 100k would pretty much halt any real risk headerflooding, with current hardware. 16M adds a good amount of headroom.
448 2016-10-27 19:45:24	0|Chris_Stewart_5|but in jeremyrubin example if we are soft forkign to a different PoW that doesn't necessarily hold true, does it? Perhaps I don't understand circumstances of forking to another PoW though..
449 2016-10-27 19:45:37	0|jeremyrubin|petertodd: I disagree, but that's more of a wizards topic
450 2016-10-27 19:45:50	0|jtimon|gmaxwell: are you sure you want to change CheckBlockHeader instead of CheckProofOfWork ?
451 2016-10-27 19:45:53	0|morcos|gmaxwell: i'm not so sure about that.. isn't the abilitity to soft fork to a different PoW something we might want to preserve?
452 2016-10-27 19:45:57	0|petertodd|Chris_Stewart_5: a "soft-fork" to a different PoW isn't really a soft-fork, because the old clients are now horribly insecure
453 2016-10-27 19:46:10	0|jeremyrubin|petertodd: e.g., something like tadge's proof of idle
454 2016-10-27 19:46:11	0|gmaxwell|Chris_Stewart_5: softforking to a new pow is not really a softfork.  In any case: keeping it at least that high would require only 10 devices, and ... any old nodes in that world could have their chain redone by those same 10 devices.
455 2016-10-27 19:46:23	0|petertodd|morcos: there is no such thing as a soft-fork to a different proof-of-work - doing that doesn't have the security characteristics of a soft-fork
456 2016-10-27 19:46:25	0|gmaxwell|morcos: it is preserved.
457 2016-10-27 19:46:33	0|gmaxwell|to the extent that it exists.
458 2016-10-27 19:46:35	0|morcos|give how hard hard forks are.. imagine there was a contentious HF that took majority hash power..  might the minority not want to be able to softfork away without having to agree on a HF
459 2016-10-27 19:46:46	0|jtimon|Chris_Stewart_5: yeah if you want a different pow just hardfork
460 2016-10-27 19:46:58	0|gmaxwell|Imagine the diff floor is 1. okay, then the diff goes down to 1. okay.. now I start up a 2011 asic miner and immediately break all those un upgraded nodes.
461 2016-10-27 19:47:01	0|morcos|ok, i need to think about it more.. but i think we should analyze all those scenarios
462 2016-10-27 19:47:21	0|gmaxwell|morcos: but thats also why my figure is ~10 devices and not 10,000 devices. :)
463 2016-10-27 19:47:43	0|gmaxwell|In any case. I think it's fairly easy to understand. And I think the solution basically has all the properties that we want.
464 2016-10-27 19:47:48	0|petertodd|morcos: again, this is a scenario where bitcoin as you know it is horribly insecure - anyone with >10 machines could attack your min-diff chain. I had a high enough credit limit as a student to buy more machines than that. :)
465 2016-10-27 19:47:51	0|gmaxwell|But I expected thought and discussion on it.
466 2016-10-27 19:48:13	0|BlueMatt|gmaxwell: ideally we would like to add the property that someone cant flood you during IBD, but to be fair we also suffer from DoS issues there now
467 2016-10-27 19:48:25	0|petertodd|gmaxwell: if hardware improves, do we up the min diff again? IMO that'd be reasonable
468 2016-10-27 19:48:31	0|morcos|petertodd: not if you've softforked in other PoW requirements that the attackers don't have the hashing or whateve rto produce
469 2016-10-27 19:48:42	0|gmaxwell|BlueMatt: So hold up there.
470 2016-10-27 19:49:01	0|gmaxwell|BlueMatt: I think what I propos has _exactly_ as good protection for that as we currently have, if not somewhat better.
471 2016-10-27 19:49:09	0|Chris_Stewart_5|And this solves header flooding because it requires the attacker to provide headers with ATLEAST that much difficulty, correct?
472 2016-10-27 19:49:18	0|BlueMatt|gmaxwell: didnt disagree, only suggested that ideally we'd fix the issues we have now
473 2016-10-27 19:49:18	0|petertodd|morcos: but again, because that's not really a soft-fork, might as well do a small hardfork at that point to drop the requirement for SHA2 PoW at some point wel before just 10 machines are needed
474 2016-10-27 19:49:20	0|gmaxwell|BlueMatt: right now we won't accept lower difficulty blocks after we've validated up to a paritcular checkpoint.
475 2016-10-27 19:49:31	0|gmaxwell|(okay I'll still explain as other people might miss this)
476 2016-10-27 19:49:51	0|gmaxwell|So you can consider two cases: one where the first peer you fetch from is an attacker, and one where the first peer is honest.
477 2016-10-27 19:50:10	0|morcos|petertodd: i need to think about that.. but i imagine it might always be easier to soft fork, even under adverse scenario like that
478 2016-10-27 19:50:11	0|gmaxwell|If the first peer is an attacker, you'll get header flooded now or under my proposal. (but at least it's just a one time initial install exposure)
479 2016-10-27 19:50:34	0|BlueMatt|gmaxwell: well, not sure its better since the "frst checkpoint" is "known amount of work in the best chain at ~release time" instead of a few along the way to 300k
480 2016-10-27 19:50:51	0|gmaxwell|If the first peer is not an attacker, in my propoal you'll quickly have all the headers and blocked from any attacks. Also no less good than now.
481 2016-10-27 19:50:54	0|BlueMatt|(under first-peer-is-evil attacks, but ok)
482 2016-10-27 19:51:00	0|gmaxwell|BlueMatt: but my proposal needs only headers.
483 2016-10-27 19:51:16	0|gmaxwell|oh under first peer is attacker
484 2016-10-27 19:51:17	0|petertodd|morcos: anyway, good to do up some deployment scenarios regardless to explain how that'd work
485 2016-10-27 19:51:18	0|BlueMatt|nvm
486 2016-10-27 19:51:18	0|BlueMatt|oh, i thought we applied checkpoints against headers now
487 2016-10-27 19:51:49	0|sipa|BlueMatt: we do; after passing a certain checkpoint, we don't accept headers that fork off before that checkpoint
488 2016-10-27 19:52:07	0|BlueMatt|ok, lets take this offline
489 2016-10-27 19:52:11	0|BlueMatt|suggested additional topics?
490 2016-10-27 19:52:13	0|gmaxwell|Okay, thats the overview.
491 2016-10-27 19:52:42	0|gmaxwell|I suggested the final alert. I suppose I should coordinate with achow and cobra to get the thing up and alert out. Any reasons to hold off?
492 2016-10-27 19:53:38	0|jtimon|mhmm, pindexBestHeader->nChainWork < UintToArith256(consensusParams.nMinimumChainWork) ? consensusParams.powLimit : consensusParams.powLimitLater
493 2016-10-27 19:53:38	0|jtimon|what about instead... block.nHeight < consensusParams.highPowLimitHeight ? consensusParams.powLimit : consensusParams.powLimitLater
494 2016-10-27 19:53:39	0|wumpus|#topic the final alert
495 2016-10-27 19:53:53	0|wumpus|no reason IMO
496 2016-10-27 19:53:55	0|btcdrak|gmaxwell: please get it over with.
497 2016-10-27 19:54:39	0|gmaxwell|Okay. will coordinate.
498 2016-10-27 19:55:14	0|gmaxwell|jtimon: that would make it trivial for an attacker to capture you on a fake chain.
499 2016-10-27 19:55:38	0|gmaxwell|jtimon: just feed you a chain of diff 1 blocks of that height.. and now you won't accept the low diff blocks on the real chain anymore.
500 2016-10-27 19:56:48	0|jtimon|gmaxwell: how am I prevented from handling reorgs in the same way as you?
501 2016-10-27 19:57:14	0|sipa|jtimon: creating many blocks is easy. creating much work is hard
502 2016-10-27 19:57:43	0|gmaxwell|anyting left in the meeting (I'll continue this convo after)
503 2016-10-27 19:57:49	0|jtimon|what I think it's add less risk since  consensusParams.highPowLimitHeight is fixed but nMinimumChainWork is expected to chain with each release, no?
504 2016-10-27 19:58:25	0|jtimon|I must be missing something, I don't see the vulnerability that my proposed change introduces
505 2016-10-27 19:58:27	0|wumpus|ok, that concludes the meeting I think
506 2016-10-27 19:58:34	0|wumpus|#endmeeting
507 2016-10-27 19:58:35	0|lightningbot|Log:            http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-10-27-19.01.log.html
508 2016-10-27 19:58:35	0|lightningbot|Meeting ended Thu Oct 27 19:58:34 2016 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
509 2016-10-27 19:58:35	0|lightningbot|Minutes:        http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-10-27-19.01.html
510 2016-10-27 19:58:35	0|lightningbot|Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-10-27-19.01.txt
511 2016-10-27 19:59:07	0|btcdrak|party time?
512 2016-10-27 19:59:11	0|BlueMatt|gmaxwell: wait, so how is it better? the only practical difference i see is that you need to get a headers chain up to today before getting protection, instead of only up to checkpoints
513 2016-10-27 19:59:16	0|BlueMatt|but that shouldnt matter much
514 2016-10-27 19:59:27	0|gmaxwell|jtimon: if you start a node and connect to an evil node. The evil node can feed you 500000 blocks at diff 1 and then you will not reorg onto the mainchain anymore.
515 2016-10-27 19:59:56	0|jtimon|yes, how my proposed change makes your branch more vulnerable to that attack is what I don't see
516 2016-10-27 20:00:17	0|jtimon|why wouldn't I reorg to the most work change?
517 2016-10-27 20:00:32	0|gmaxwell|Because you won't even process the first block in that chain.
518 2016-10-27 20:00:39	0|sipa|jtimon: because you'll reject the low-difficulty headers from the real chain you get later
519 2016-10-27 20:00:42	0|jtimon|just like your branch without my proposed change, I think
520 2016-10-27 20:01:08	0|jtimon|mhmm, no, say highPowLimitHeight is the current height whatever it is
521 2016-10-27 20:01:16	0|gmaxwell|No. My branch does not activate until you have enough work to be the real chain at the time of the release.
522 2016-10-27 20:01:51	0|gmaxwell|jtimon: yes, 436182.  Say it's that.
523 2016-10-27 20:02:04	0|gmaxwell|Attacker computes 500000 diff 1 headers, and gives you that.
524 2016-10-27 20:02:08	0|jtimon|right, and mine activates at a fixed height, say 436182
525 2016-10-27 20:02:16	0|gmaxwell|Under my code you would sitll reorg to the best chain.
526 2016-10-27 20:02:20	0|jtimon|ok, I accept that chain
527 2016-10-27 20:02:30	0|gmaxwell|Under your code you would not reorg to the best chain.
528 2016-10-27 20:02:30	0|jtimon|then when I see the real one I reorg, no?
529 2016-10-27 20:02:33	0|gmaxwell|No.
530 2016-10-27 20:02:42	0|jtimon|why not?
531 2016-10-27 20:02:45	0|sipa|jtimon: no, you'll reject the low-difficulty headers once you pass the watermark
532 2016-10-27 20:02:56	0|gmaxwell|You will reach 500,000 and now you will reject blocks with low difficulty. So when an honest node sends you block 1 of the real chain you will reject it.
533 2016-10-27 20:03:01	0|sipa|jtimon: because this is a fix to the otherwise existing DoS of being able to feed someone low-difficulty headers
534 2016-10-27 20:03:11	0|jtimon|oh, we have limits on reorg, right, sorry, I get it, thanks
535 2016-10-27 20:03:19	0|sipa|no, we don't have limits on reorg
536 2016-10-27 20:03:20	0|gmaxwell|We don't have limits on reorg.
537 2016-10-27 20:03:29	0|jtimon|mhm, let me read again
538 2016-10-27 20:03:34	0|sipa|we just reject headers that are too low difficulty once we know we're past that stafe
539 2016-10-27 20:03:38	0|sipa|*stage
540 2016-10-27 20:04:08	0|jtimon|" So when an honest node sends you block 1 of the real chain you will reject it." not if the block is height < 436182
541 2016-10-27 20:04:30	0|gmaxwell|if you don't reject low diff headers someone can exaust your memory/disk with header flooding.
542 2016-10-27 20:05:00	0|gmaxwell|which the code you were quoting protect against but wouldn't if it were a height check.
543 2016-10-27 20:06:42	0|jtimon|don't I reject them more than you? ie in your first version nMinimumChainWork will be total work at 436182, then in the next release, total work at a higher height, etc. I always reject low diff after 436182
544 2016-10-27 20:06:56	0|jtimon|I don't get it but let's move on I will think more about it
545 2016-10-27 20:07:50	0|sipa|an attacker can veriy easily create such a long chain
546 2016-10-27 20:07:50	0|sipa|jtimon: being past 436182 does not mean you're on the right chain
547 2016-10-27 20:08:15	0|sipa|creating as much work of the real 43612 chain is nearly impossible
548 2016-10-27 20:08:18	0|jtimon|sipa: right it means the min diff is higher from now on
549 2016-10-27 20:08:27	0|jtimon|right
550 2016-10-27 20:08:44	0|sipa|jtimon: if yhe min difficulty is more than 1 you will reject the early part of the real chain!!!
551 2016-10-27 20:09:05	0|jtimon|and "my code" will always prefer the real chain because it's more work
552 2016-10-27 20:09:05	0|sipa|because the real chain has diff 1 in the beginning
553 2016-10-27 20:09:06	0|Chris_Stewart_5|Not sure if this this is a good question or not, but is this something deployed with BIP9?
554 2016-10-27 20:09:24	0|jtimon|sipa: no, the early part of the real chain is height < 436182 !
555 2016-10-27 20:10:02	0|sipa|jtimon: we DO NOT want to accept just any header below height 436182
556 2016-10-27 20:10:18	0|sipa|jtimon: that is exactly the DoS attack this change is intended to fix
557 2016-10-27 20:11:08	0|sipa|jtimon: maybe you're missing this: once you have *ANY* chain with chainwork above the limit, you reject *every* header below the new difficulty
558 2016-10-27 20:11:16	0|sipa|even in an entirely unrelated chain
559 2016-10-27 20:11:31	0|BlueMatt|oh, damn, something i should've brought up in the meeting - ProcessNewBlock's CValidationState& argument - its really fucking strange. So its used to communicate either a) Errors (ie out of disk, block pruned, etc) or b) AcceptBlock (ie CheckBlock, ContextualCheckBlock, etc) Invalids()...it is NOT used to return success for the current (or any) block, and even if ActivateBestChain finds an invalid block, it will not set the
560 2016-10-27 20:11:32	0|BlueMatt|CValidationState argument as such. 1) a few places in the code get this wrong and 2) this means you have to duplicate logic between the call-site as well as to CValidationInterface's BlockChecked()
561 2016-10-27 20:11:46	0|BlueMatt|does anyone object to me making it call BlockChecked for AcceptBlock failures?
562 2016-10-27 20:11:56	0|jtimon|I don't seee how pindexBestHeader->nChainWork < UintToArith256(consensusParams.nMinimumChainWork) ? consensusParams.powLimit : consensusParams.powLimitLater) saves us from the attacker sending us 500k diff 1 blocks just like with my change, that line only saves you from accepting mindiff blocks afterwards
563 2016-10-27 20:12:20	0|BlueMatt|so then ProcessNewBlock would only use its CValidationState argument (which would then just be optional) in case of failures, not invalid blocks
564 2016-10-27 20:12:34	0|sipa|jtimon: it only protects us once we see the real chain
565 2016-10-27 20:12:57	0|sipa|jtimon: your proposal can trigger even if we don't have the real chain
566 2016-10-27 20:14:50	0|jtimon|right, and with my chain it only protects us for blocks that have height > 436182, the change is not "globally activated forever" in this case, if a shorter chain with more work appears, you may go back below height 436182 and the min diff blocks would be accepted again
567 2016-10-27 20:15:25	0|sipa|so you haven't solved the issue
568 2016-10-27 20:15:58	0|jtimon|note I didn't say pindexBestHeader->nHeight but block.nHeight (that is, the header you are checking now)
569 2016-10-27 20:16:38	0|sipa|you're really doing somwthing completely different
570 2016-10-27 20:16:58	0|jtimon|well, that line is supposed to save us from min diff blocks in the future, no?
571 2016-10-27 20:18:03	0|sipa|your change does not prevent that
572 2016-10-27 20:18:20	0|sipa|someone can keep spamming low-height headers in your proposal
573 2016-10-27 20:19:02	0|jtimon|oh, and you won't ignore them if they're < 436182, sorry, I finally get it
574 2016-10-27 20:19:05	0|jtimon|thanks
575 2016-10-27 20:20:04	0|instagibbs|Congrats! Managed to sleep exactly through meeting time.
576 2016-10-27 20:20:39	0|BlueMatt|ok, I'm removing CValidationState from ProcessNewBlock
577 2016-10-27 20:21:38	0|jtimon|sorry BlueMatt wasn't listening
578 2016-10-27 20:22:21	0|btcdrak|sipa: remember to update your http://bitcoin.sipa.be/ver9-2k.png graphs :)
579 2016-10-27 20:22:27	0|sipa|instagibbs: and through the release
580 2016-10-27 20:22:31	0|sipa|btcdrak: indeed!
581 2016-10-27 20:23:32	0|instagibbs|Yeah missed all the action.
582 2016-10-27 20:25:36	0|sipa|BlueMatt: iirc the only reason for CVS in PNB is to return system failure conditions
583 2016-10-27 20:26:09	0|BlueMatt|sipa: nope, its also used to return AcceptBlock errors
584 2016-10-27 20:26:10	0|BlueMatt|sipa: also, its never checked for system failure conditions
585 2016-10-27 20:27:02	0|jtimon|BlueMatt: not sure what you propose to do CValidationState is usually to return error details from functions that already return false when they fail most of the time (if we returned 0 for success and anything else for error codes we wouldn't need it)
586 2016-10-27 20:33:20	0|BlueMatt|jtimon: https://github.com/bitcoin/bitcoin/commit/a4f82de1bdde644e9bad4c524b638dd5bd4d69f7
587 2016-10-27 20:33:44	0|BlueMatt|also, the fact that you can access commits via that url when they arent in the bitcoin/bitcoin repo is freaky
588 2016-10-27 20:35:25	0|jtimon|yeah, seems it makes sense to move it down to ProcessNewBlock it is certainly the higher level function where I have ever used it
589 2016-10-27 20:38:27	0|BlueMatt|anyway, I'll pr it after https://github.com/bitcoin/bitcoin/pull/8969, I know suhas was waiting on it
590 2016-10-27 20:38:29	0|jtimon|BlueMatt: yeah, I definitely like that commit
591 2016-10-27 20:39:19	0|jtimon|yeah I only briefly looked at that one, sorry
592 2016-10-27 20:40:06	0|murch|quick question: Does 0.13.1 already include functions for creation of SegWit transactions?
593 2016-10-27 20:40:22	0|BlueMatt|yes
594 2016-10-27 20:40:30	0|BlueMatt|so did 0.13.0
595 2016-10-27 20:40:46	0|BlueMatt|(its all gated on segwit being activated, so it works on testnet)
596 2016-10-27 20:41:31	0|murch|ah okay, thanks
597 2016-10-27 21:20:35	0|BlueMatt|wait, did we un-support qt5?
598 2016-10-27 21:20:42	0|BlueMatt|wasnt there talk of deprecating it?
599 2016-10-27 21:45:58	0|cfields_|BlueMatt: you mean qt4?
600 2016-10-27 21:48:26	0|BlueMatt|uhh, yes
601 2016-10-27 21:49:45	0|cfields_|BlueMatt: i'd say it's pretty well deprecated already. iirc the discussion was about completely dropping support
602 2016-10-27 21:52:46	0|BlueMatt|mmm, nvm, realized it only breaks precise, which was broken by c++11
603 2016-10-27 21:56:20	0|michagogo|Ack, missed another meeting :-/
604 2016-10-27 21:56:34	0|michagogo|Did it start late, or just late ping?
605 2016-10-27 21:57:49	0|luke-jr|I think at this point, once Qt4 becomes a burden we can probably drop it?
606 2016-10-27 21:57:53	0|luke-jr|BlueMatt: what breaks precise?
607 2016-10-27 21:58:07	0|BlueMatt|there is no qt4 on precise
608 2016-10-27 21:58:19	0|BlueMatt|also, the boost in precise doesnt compile in c++11 mode
609 2016-10-27 21:58:56	0|luke-jr|so don't build qt4?
610 2016-10-27 21:59:14	0|luke-jr|I thought we didn't use any boost that had ABI changes for C++11
611 2016-10-27 21:59:41	0|BlueMatt|luke-jr: https://svn.boost.org/trac/boost/ticket/6198
612 2016-10-27 22:00:20	0|luke-jr|compile with GCC?
613 2016-10-27 22:00:42	0|BlueMatt|the gcc in precise does not support c++11
614 2016-10-27 22:00:46	0|luke-jr|ugh
615 2016-10-27 22:01:34	0|BlueMatt|the ppa currently has an empty dummy package for precise
616 2016-10-27 22:01:38	0|BlueMatt|because fuck precise
617 2016-10-27 22:01:45	0|luke-jr|uh
618 2016-10-27 22:01:49	0|luke-jr|at least leave the old version?
619 2016-10-27 22:02:03	0|BlueMatt|no
620 2016-10-27 22:02:06	0|luke-jr|…
621 2016-10-27 22:02:26	0|luke-jr|patch the code to #define size size_arg? >_<
622 2016-10-27 22:02:34	0|BlueMatt|no
623 2016-10-27 22:02:45	0|BlueMatt|feel free to create the debian/ folder and send it to me and I'll upload
624 2016-10-27 22:02:52	0|BlueMatt|I'm not fighting with it to make precise work
625 2016-10-27 22:02:54	0|luke-jr|XD
626 2016-10-27 22:03:11	0|luke-jr|wait, to do the PPA you just upload the debian folder?
627 2016-10-27 22:03:20	0|BlueMatt|and the original source archive
628 2016-10-27 22:03:25	0|BlueMatt|(ie git archive)
629 2016-10-27 22:04:01	0|BlueMatt|and two other strange metadata files
630 2016-10-27 22:09:22	0|luke-jr|any reason we can't get gitian to produce the files needing to upload? <.<
631 2016-10-27 22:09:42	0|BlueMatt|gitian? they're all in the source tree
632 2016-10-27 22:09:47	0|BlueMatt|except signed by my pgp key
633 2016-10-27 22:10:12	0|BlueMatt|git archive + contrib/debian (though i have some mods i make to contrib/debian....i keep forgetting to re-upstream those, i used to keep it synced)
634 2016-10-27 22:10:14	0|luke-jr|so we don't need to do https://help.launchpad.net/Packaging/PPA/BuildingASourcePackage ?
635 2016-10-27 22:11:55	0|BlueMatt|yes, we do do that, but building a source package results in a) the git archive tar itself b) a tar of the debian/ folder and c) two files which pretty much just list some metadata extracted from the debian folder and hashes of the other files, which is signed by my pgp key
636 2016-10-27 22:12:21	0|BlueMatt|so, no, its really entirely useless to do anything in gitian for this
637 2016-10-27 22:36:23	0|gmaxwell|when did we back off the checkblocks check? was that in 0.13.0 or 0.13.1?
638 2016-10-27 22:59:51	0|BlueMatt|heh, 66/130 connections segwit (with 52/8 blocked)
639 2016-10-27 22:59:55	0|BlueMatt|guess preferential peering works =D
640 2016-10-27 23:15:32	0|sipa|gmaxwell: 0
641 2016-10-27 23:15:38	0|sipa|gmaxwell: 0.13.1
642 2016-10-27 23:16:11	0|gmaxwell|sipa: explaines people saying it stats so much faster.
643 2016-10-27 23:16:26	0|sipa|ha
644 2016-10-27 23:16:31	0|gmaxwell|sipa: how many connections does your node have?
645 2016-10-27 23:17:06	0|gmaxwell|I am 124/124.
646 2016-10-27 23:26:45	0|sipa|compiling 0.13.1 now
647 2016-10-27 23:27:11	0|sipa|i was on 0.13.0 i think
648 2016-10-27 23:29:49	0|BlueMatt|ok, all ppas are built and published
649 2016-10-27 23:38:31	0|gmaxwell|BlueMatt: if the ppas are downloadable, go post on reddit?
650 2016-10-27 23:51:51	0|luke-jr|Why does bitcoincore announcements ML include tracking?
651 2016-10-27 23:57:24	0|sipa|?
652 2016-10-27 23:57:55	0|luke-jr|there's an invisible <img> with a tracking id at the bottom
653 2016-10-27 23:58:23	0|luke-jr|it attempts to load the image from the internet, thus informing the webserver it was read