1 2016-10-27T00:00:01  <gmaxwell> Eligius 0.589615
   2 2016-10-27T00:00:04  <gmaxwell> Telco 0.709605
   3 2016-10-27T00:01:18  <TD-Linux> gmaxwell, well 0.246 btc loss is directly proportional to their block size
   4 2016-10-27T00:02:05  *** Chris_Stewart_5 has quit IRC
   5 2016-10-27T00:02:19  <gmaxwell> Indeed.
   6 2016-10-27T00:02:30  <Lightsword> gmaxwell, do you have stats on kano’s ckpool and ck’s solopool?
   7 2016-10-27T00:02:41  <TD-Linux> also I don't think there's really enough samples there to draw a conclusion. would be neat to automate this though.
   8 2016-10-27T00:03:11  <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.
   9 2016-10-27T00:03:14  *** Chris_Stewart_5 has joined #bitcoin-core-dev
  10 2016-10-27T00:03:14  <gmaxwell> s/fine/find/
  11 2016-10-27T00:04:48  <sipa> gmaxwell: over how many blocks is this data?
  12 2016-10-27T00:04:48  <gmaxwell> 67
  13 2016-10-27T00:05:12  <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
  14 2016-10-27T00:05:43  <gmaxwell> I can also estimate mining process latency from this. I'm saving the fees for my gbt every 10 seconds.
  15 2016-10-27T00:06:24  <gmaxwell> e.g. "you mined fees consistent with forming your block 30 seconds ago"
  16 2016-10-27T00:18:48  *** PRab has quit IRC
  17 2016-10-27T00:19:19  *** a_meteorite has quit IRC
  18 2016-10-27T00:39:42  *** fengling has quit IRC
  19 2016-10-27T00:47:06  *** Ylbam_ has quit IRC
  20 2016-10-27T01:00:18  *** echonaut has quit IRC
  21 2016-10-27T01:00:43  *** echonaut has joined #bitcoin-core-dev
  22 2016-10-27T01:00:44  *** randy-waterhouse has quit IRC
  23 2016-10-27T01:04:21  *** randy-waterhouse has joined #bitcoin-core-dev
  24 2016-10-27T01:04:30  *** randy-waterhouse has joined #bitcoin-core-dev
  25 2016-10-27T01:14:16  <jeremyrubin> gmaxwell: can you normalize by block size?
  26 2016-10-27T01:25:12  <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
  27 2016-10-27T01:25:26  <midnightmagic> sorry for the mixup
  28 2016-10-27T01:32:27  <gmaxwell> jeremyrubin: okay, I added two columns, one is my mempool fees sscaled to the actual block size, the next is the difference.
  29 2016-10-27T01:32:59  <gmaxwell> which now shows the small blocks as slightly negative, which makes sense, since they took the highest fee txn.
  30 2016-10-27T01:33:13  *** randy-waterhouse has quit IRC
  31 2016-10-27T01:42:02  <luke-jr> gmaxwell: that looks like the fallback where Eloipool has to guess the template itself until GBT completes
  32 2016-10-27T01:42:18  <luke-jr> it's supposed to be based on the previous valid template, not sure what's going wrong there
  33 2016-10-27T01:45:51  *** DigiByteDev has joined #bitcoin-core-dev
  34 2016-10-27T01:46:17  *** randy-waterhouse has joined #bitcoin-core-dev
  35 2016-10-27T01:46:51  *** randy-waterhouse has joined #bitcoin-core-dev
  36 2016-10-27T01:55:10  <gmaxwell> luke-jr: fix.
  37 2016-10-27T02:07:50  *** fengling has joined #bitcoin-core-dev
  38 2016-10-27T02:19:35  *** Giszmo has quit IRC
  39 2016-10-27T02:20:44  *** randy-waterhouse has quit IRC
  40 2016-10-27T02:26:22  *** PRab has joined #bitcoin-core-dev
  41 2016-10-27T02:27:09  *** tulip has joined #bitcoin-core-dev
  42 2016-10-27T02:37:10  *** PRab has quit IRC
  43 2016-10-27T02:55:57  *** fengling has quit IRC
  44 2016-10-27T03:11:23  *** PRab has joined #bitcoin-core-dev
  45 2016-10-27T03:26:18  *** midnightmagic has quit IRC
  46 2016-10-27T03:28:23  *** Chris_Stewart_5 has quit IRC
  47 2016-10-27T03:34:33  *** jtimon has quit IRC
  48 2016-10-27T03:45:22  *** midnightmagic has joined #bitcoin-core-dev
  49 2016-10-27T03:51:04  <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
  50 2016-10-27T03:51:05  <luke-jr> >_<
  51 2016-10-27T04:18:09  *** a_meteorite has joined #bitcoin-core-dev
  52 2016-10-27T04:21:13  *** a_meteorite has quit IRC
  53 2016-10-27T04:21:40  *** a_meteorite has joined #bitcoin-core-dev
  54 2016-10-27T04:32:27  *** aalex has quit IRC
  55 2016-10-27T04:32:47  *** aalex has joined #bitcoin-core-dev
  56 2016-10-27T04:42:41  *** nickler has quit IRC
  57 2016-10-27T04:48:12  *** d_t has quit IRC
  58 2016-10-27T04:53:27  *** nickler has joined #bitcoin-core-dev
  59 2016-10-27T05:10:08  *** tulip has quit IRC
  60 2016-10-27T05:25:36  *** DigiByteDev has quit IRC
  61 2016-10-27T05:30:11  *** harrymm has quit IRC
  62 2016-10-27T05:34:21  <whphhg> Sup blockstream
  63 2016-10-27T05:35:08  *** fengling has joined #bitcoin-core-dev
  64 2016-10-27T05:44:10  *** harrymm has joined #bitcoin-core-dev
  65 2016-10-27T05:45:57  *** DigiByteDev has joined #bitcoin-core-dev
  66 2016-10-27T05:50:36  *** wasi has quit IRC
  67 2016-10-27T05:50:43  *** d_t has joined #bitcoin-core-dev
  68 2016-10-27T05:55:12  *** d_t has quit IRC
  69 2016-10-27T06:11:20  <GitHub7> [bitcoin] laanwj closed pull request #9022: Update release notes to mention dropping OS X 10.7 support (0.13...0-13-1-osx-notes) https://github.com/bitcoin/bitcoin/pull/9022
  70 2016-10-27T06:11:22  <GitHub177> [bitcoin] laanwj pushed 2 new commits to 0.13: https://github.com/bitcoin/bitcoin/compare/a32d7c23fc0e...03422e564b55
  71 2016-10-27T06:11:22  <GitHub177> bitcoin/0.13 1d12463 Michael Ford: Update release notes for dropping osx 10.7 support
  72 2016-10-27T06:11:23  <GitHub177> bitcoin/0.13 03422e5 Wladimir J. van der Laan: Merge #9022: Update release notes to mention dropping OS X 10.7 support...
  73 2016-10-27T06:15:31  *** a_meteorite has quit IRC
  74 2016-10-27T06:21:03  <wumpus> would be interesting to check this against univalue http://seriot.ch/parsing_json.html
  75 2016-10-27T06:22:38  <jonasschnelli> wumpus: heh. Yes. Someone should turn this into unit-tests.
  76 2016-10-27T06:22:44  <jonasschnelli> Maybe open an easy-to-implement issue?
  77 2016-10-27T06:22:53  <jonasschnelli> though not sure how easy it is.
  78 2016-10-27T06:23:36  <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 :)
  79 2016-10-27T06:24:18  <jonasschnelli> Indeed...
  80 2016-10-27T06:24:58  <wumpus> but even without that it'd be interesting to see how it compares
  81 2016-10-27T06:26:19  <wumpus> hopefully there's nothing in the "parser crashed" category, we've done quite a lot of fuzzing
  82 2016-10-27T06:29:04  *** a_meteorite has joined #bitcoin-core-dev
  83 2016-10-27T06:31:00  <jonasschnelli> I'm glad all JSON operations are hidden behind the HTTP Auth...
  84 2016-10-27T06:31:11  <jonasschnelli> With rest it gets a bit more risky...
  85 2016-10-27T06:31:42  <wumpus> I've purposedly kept JSON parsing out of REST
  86 2016-10-27T06:31:50  <wumpus> just simple query strings
  87 2016-10-27T06:32:33  <jonasschnelli> Ah. Right. Only output.
  88 2016-10-27T06:33:23  <wumpus> output far from as much of a risk as parsing
  89 2016-10-27T06:33:27  <wumpus> +is
  90 2016-10-27T06:33:46  <wumpus> still possible for there to be bugs there, but much less scope for trickery
  91 2016-10-27T06:35:54  *** DigiByteDev has quit IRC
  92 2016-10-27T06:36:18  *** DigiByteDev has joined #bitcoin-core-dev
  93 2016-10-27T06:36:27  <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.
  94 2016-10-27T06:38:00  <btcdrak> oh, I see wumpus found the PR already :-)
  95 2016-10-27T06:38:38  <wumpus> https://github.com/bitcoin/bitcoin/issues/9028
  96 2016-10-27T06:38:57  <wumpus> btcdrak: if tests are failing due to a trailing space you're doing comparison in the wrong domain
  97 2016-10-27T06:39:21  <wumpus> I agree with your pull request but not that it should cause (non-JSON-pedanticness) tests to fail :)
  98 2016-10-27T06:41:35  <wumpus> but I'd say, to compare two json documents: parse them and compare the underlying data. Don't compare pretty-printed representations
  99 2016-10-27T06:43:24  *** Ylbam_ has joined #bitcoin-core-dev
 100 2016-10-27T06:45:31  <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.
 101 2016-10-27T06:46:27  <wumpus> I understand, but there is no standard way to pretty-print JSON
 102 2016-10-27T06:46:48  <wumpus> having the tests depend on how the jSON lib happens to do pretty printing is fragile
 103 2016-10-27T06:47:05  <wumpus> ideally the tests should compare the data, not the text
 104 2016-10-27T06:48:36  <btcdrak> yes, I agree.
 105 2016-10-27T06:49:59  <wumpus> I think we have some similar problems in other places, which complicated switching JSON libraries last time
 106 2016-10-27T06:50:30  <wumpus> not a huge proiority to change ofcourse
 107 2016-10-27T06:50:44  <btcdrak> but while indentation may not have a standard, I think trailing whitespace has no place in any output.
 108 2016-10-27T06:50:57  *** DigiByteDev has quit IRC
 109 2016-10-27T06:51:48  <luke-jr> but what if you want to embed a Whitespace program? :p
 110 2016-10-27T06:51:55  <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
 111 2016-10-27T06:52:21  <btcdrak> yup
 112 2016-10-27T06:52:26  <wumpus> next time the problem may be the other way around, someone accidentally adds trailing whitespace to the example and the test fails
 113 2016-10-27T06:52:45  <wumpus> and spend hours debugging that problem instead of something that matters :)
 114 2016-10-27T06:53:12  <wumpus> luke-jr: ah yes, white-space steganogrpaphy
 115 2016-10-27T06:53:28  <btcdrak> haha yes.
 116 2016-10-27T06:53:29  <btcdrak> well again, I found changing a 1 to a 2 isnt that straight forward....
 117 2016-10-27T06:53:49  <btcdrak> wumpus: can you restart https://travis-ci.org/bitcoin/bitcoin/builds/170827031, dunno why Travis borked
 118 2016-10-27T06:53:57  *** BashCo has quit IRC
 119 2016-10-27T06:54:19  <luke-jr> wumpus: do you have any expectation of further merges before tagging?
 120 2016-10-27T06:54:38  <wumpus> luke-jr: if there are further improvements to the release notes
 121 2016-10-27T06:55:41  <wumpus> otherwise, no
 122 2016-10-27T07:04:03  *** dcousens has joined #bitcoin-core-dev
 123 2016-10-27T07:06:17  <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?
 124 2016-10-27T07:06:33  <jonasschnelli> s/_Var/_var
 125 2016-10-27T07:07:52  <luke-jr> I'd rather 'var' than '_var' for public stuff at least
 126 2016-10-27T07:08:04  <luke-jr> I don't see a problem with o->var or o->fVar
 127 2016-10-27T07:08:20  *** wasi has joined #bitcoin-core-dev
 128 2016-10-27T07:15:30  <jonasschnelli> Luke-Jr: my problems is, that the code is really not easy readable if you don't highlight instance variable in some form.
 129 2016-10-27T07:15:52  <jonasschnelli> this-> clusters to code to much IMO, ... using _var seems acceptable to me.
 130 2016-10-27T07:16:19  <jonasschnelli> Using fVar, etc. will not increase readability because we are also using this for non-instance vars (function parameters, etc.)
 131 2016-10-27T07:16:24  <luke-jr> we're already using _var for local variables to avoid shadowing :/
 132 2016-10-27T07:17:14  <jonasschnelli> argh... I though we are using _var for instance vars to avoid shadowing... do we also use _var in local scope?!
 133 2016-10-27T07:17:45  <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
 134 2016-10-27T07:20:00  *** Samdney has joined #bitcoin-core-dev
 135 2016-10-27T07:21:40  *** d_t has joined #bitcoin-core-dev
 136 2016-10-27T07:22:18  *** d_t has joined #bitcoin-core-dev
 137 2016-10-27T07:26:06  *** BashCo has joined #bitcoin-core-dev
 138 2016-10-27T07:29:11  <wumpus> no, we have no naming convention for instance variables, just use whatever makes sense in the context
 139 2016-10-27T07:29:58  <jonasschnelli> I personally like this-> but I know most people don't like that
 140 2016-10-27T07:30:05  <jonasschnelli> I'll try _
 141 2016-10-27T07:30:11  <wumpus> at least the qt coding convention recommends against using m_ or _ or such
 142 2016-10-27T07:31:08  <jonasschnelli> The m prefix would not allow to use the fVar, etc. prefix.
 143 2016-10-27T07:31:15  <jonasschnelli> mfBool would look strange. :)
 144 2016-10-27T07:31:19  <jonasschnelli> i'd prefere _fBool
 145 2016-10-27T07:31:23  <wumpus> m_fBool that would be, then
 146 2016-10-27T07:31:27  *** Samdney has quit IRC
 147 2016-10-27T07:31:31  <jonasschnelli> m_ yes... why not
 148 2016-10-27T07:31:57  <sipa> wumpus: what does the qt coding convention suggest?
 149 2016-10-27T07:32:13  <wumpus> sipa: no specific one, just use this->name where necessary
 150 2016-10-27T07:32:34  <wumpus> in many cases there's no need to name instance variables any differently from local variables
 151 2016-10-27T07:33:04  <jonasschnelli> wumpus: readability?
 152 2016-10-27T07:33:06  <sipa> luke-jr: where do we use _var for local variables?
 153 2016-10-27T07:33:08  <wumpus> e.g. https://forum.qt.io/topic/150/member-variable-naming-convention-in-qt-and-the-qtdn-wiki
 154 2016-10-27T07:33:36  <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
 155 2016-10-27T07:33:45  <sipa> luke-jr: underscores are used in several places for formal parameters to avoid colliding with field variables
 156 2016-10-27T07:33:48  <wumpus> but I don't know, I hate these kind of discussions
 157 2016-10-27T07:33:59  <jonasschnelli> Reading through new code i often found myself checking if the variable is local or instance-wide
 158 2016-10-27T07:34:00  <sipa> haha
 159 2016-10-27T07:34:04  <jonasschnelli> heh
 160 2016-10-27T07:34:36  <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
 161 2016-10-27T07:34:48  <jonasschnelli> sipa: yes. If. now open main.cpp. :)
 162 2016-10-27T07:34:55  <wumpus> jonasschnelli: that probably means the code itself is badly commented / structured
 163 2016-10-27T07:35:15  <wumpus> a shallow 'fix' like renaming instance variables won't help much in that case except check a checkbox
 164 2016-10-27T07:36:30  <sipa> jonasschnelli: so help refactoring those functions to be morw readable :)
 165 2016-10-27T07:36:33  <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
 166 2016-10-27T07:37:02  <wumpus> it's the typical pointy-haired boss solution to
 167 2016-10-27T07:37:06  <wumpus> "code is unreadable"
 168 2016-10-27T07:37:10  <wumpus> FORCE a coding style!
 169 2016-10-27T07:37:57  <wumpus> now you have nicely formatted ununderstandable code :)
 170 2016-10-27T07:38:18  <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?
 171 2016-10-27T07:38:22  *** nanotube has quit IRC
 172 2016-10-27T07:38:32  <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.
 173 2016-10-27T07:39:16  <wumpus> sipa: I don't think so, it's just the dilbert stereotype, it doesn't have anything to do with hair :-)
 174 2016-10-27T07:41:01  <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.
 175 2016-10-27T07:41:17  <dcousens> improving readability*
 176 2016-10-27T07:41:31  *** d_t has quit IRC
 177 2016-10-27T07:41:52  <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
 178 2016-10-27T07:42:15  <gmaxwell> I wondered if perhaps PHB predated dilbert and dilbert was riffing off it, ... but I'd forgotten how old dilber is .. (1980-04)
 179 2016-10-27T07:43:00  *** whphhg has left #bitcoin-core-dev
 180 2016-10-27T07:44:05  *** nanotube has joined #bitcoin-core-dev
 181 2016-10-27T07:44:26  <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>
 182 2016-10-27T07:46:08  *** wasi has quit IRC
 183 2016-10-27T07:47:26  <wumpus> time to tag 0.13.1 final?
 184 2016-10-27T07:47:49  <sipa> i'm about to fall asleep
 185 2016-10-27T07:48:04  <wumpus> I'll wait until you're asleep then
 186 2016-10-27T07:48:08  <dcousens> ha
 187 2016-10-27T07:48:33  * sipa goes into ACPI standby
 188 2016-10-27T07:48:38  <wumpus> NN
 189 2016-10-27T07:59:57  <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.
 190 2016-10-27T08:00:33  <gmaxwell> After we make the high scoreholder, Github151, in charge of the project I'm sure things will run much better.
 191 2016-10-27T08:00:49  <gmaxwell> FWIW, my testing with RC3 all looks fine.
 192 2016-10-27T08:01:28  <wumpus> hahahaa yes Github151 for president
 193 2016-10-27T08:03:11  * luke-jr ponders writing-in Github151 on his ballot
 194 2016-10-27T08:05:06  <gmaxwell> many states require a write in candidate register with them before being eligible to be counted. :(
 195 2016-10-27T08:05:27  *** moli has quit IRC
 196 2016-10-27T08:05:40  <luke-jr> I was joking anyway :p
 197 2016-10-27T08:05:51  <gmaxwell> I think this is intended to help avoid "Which John Smith did we just elect?"
 198 2016-10-27T08:06:30  <luke-jr> heh
 199 2016-10-27T08:09:22  <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
 200 2016-10-27T08:11:21  <wumpus> maybe they should use a blockchain for registering candidates *ducks*
 201 2016-10-27T08:11:40  <luke-jr> sadly, some people think that makes sense
 202 2016-10-27T08:13:40  <gmaxwell> wumpus: so, final?
 203 2016-10-27T08:21:58  *** laurentmt has joined #bitcoin-core-dev
 204 2016-10-27T08:22:36  *** laurentmt has quit IRC
 205 2016-10-27T08:22:43  <wumpus> yes, let's do it
 206 2016-10-27T08:22:47  <wumpus> sipa's asleep
 207 2016-10-27T08:25:07  <wumpus>  * [new tag]         v0.13.1 -> v0.13.1
 208 2016-10-27T08:25:15  <gmaxwell> \O/
 209 2016-10-27T08:25:49  <luke-jr> oh wow, rc3 just deleted my entire home directory …………….. jk :P
 210 2016-10-27T08:26:54  <gmaxwell> cool "0.13.1 addresses user's concerns with excessive disk space consumption."
 211 2016-10-27T08:28:08  <wumpus> hehe, always the positive side
 212 2016-10-27T08:28:14  <luke-jr> lol
 213 2016-10-27T08:28:27  <jonasschnelli> heh
 214 2016-10-27T08:28:31  <warren> that sounds like one particular user had concerns
 215 2016-10-27T08:30:09  *** Guyver2 has joined #bitcoin-core-dev
 216 2016-10-27T08:32:33  <jonasschnelli> huh! Why can this happen: http://paste.ubuntu.com/23387379/
 217 2016-10-27T08:34:10  <wumpus> huh, that looks like a bug in assertlockheld
 218 2016-10-27T08:34:12  <jonasschnelli> maybe a different wallet instance...
 219 2016-10-27T08:34:19  <wumpus> ah yes ofcourse
 220 2016-10-27T08:34:49  <wumpus> maybe the lock naming should include instance pointer
 221 2016-10-27T08:35:01  <jonasschnelli> Yes. My fault... different instances
 222 2016-10-27T08:35:29  * jonasschnelli curses pwalletMain
 223 2016-10-27T08:36:51  <luke-jr> hm, I didn't encounter such issues with multiwallet? O.o
 224 2016-10-27T08:40:44  <wumpus> did you run with lock debugging on?
 225 2016-10-27T08:41:26  <wumpus> (--enable-debug will do)
 226 2016-10-27T08:44:04  <luke-jr> no
 227 2016-10-27T08:44:16  <luke-jr> does the assertlockheld only work with that?
 228 2016-10-27T08:44:33  <wumpus> yes
 229 2016-10-27T08:51:42  <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
 230 2016-10-27T08:55:22  *** btcfanboi has joined #bitcoin-core-dev
 231 2016-10-27T09:02:38  *** JackH has joined #bitcoin-core-dev
 232 2016-10-27T09:07:59  <michagogo> 🎉🎊
 233 2016-10-27T09:09:00  * michagogo sends a message and requests that his computer be turned on
 234 2016-10-27T09:09:41  <wumpus> wake-over-IRC?
 235 2016-10-27T09:15:24  *** Yogh has joined #bitcoin-core-dev
 236 2016-10-27T09:15:43  *** Yogh has left #bitcoin-core-dev
 237 2016-10-27T09:19:22  *** Guyver2 has quit IRC
 238 2016-10-27T09:37:27  <michagogo> wumpus: wake-over-iMessage
 239 2016-10-27T09:37:40  <michagogo> (Poweron, really)
 240 2016-10-27T09:37:56  <michagogo> Anyway, build running now
 241 2016-10-27T09:38:11  <michagogo> As usual, sigs will auto-PR
 242 2016-10-27T09:40:59  <michagogo> I wonder how quickly we'll get sigs
 243 2016-10-27T09:41:08  <michagogo> Think release will come today?
 244 2016-10-27T09:43:15  *** cdecker has joined #bitcoin-core-dev
 245 2016-10-27T09:48:47  *** mkarrer_ has joined #bitcoin-core-dev
 246 2016-10-27T09:52:16  *** mkarrer has quit IRC
 247 2016-10-27T10:01:40  *** n1ce has quit IRC
 248 2016-10-27T10:04:27  *** n1ce has joined #bitcoin-core-dev
 249 2016-10-27T10:12:31  *** btcfanboi has quit IRC
 250 2016-10-27T10:13:29  *** cdecker has quit IRC
 251 2016-10-27T10:13:29  <GitHub161> [bitcoin] s-matthew-english opened pull request #9029: instance of 'mem pool' to 'mempool' (master...patch-7) https://github.com/bitcoin/bitcoin/pull/9029
 252 2016-10-27T10:14:21  *** harrymm has quit IRC
 253 2016-10-27T10:19:56  <michagogo> Ooh, just got my hacktoberfest email
 254 2016-10-27T10:24:04  <gmaxwell> https://blockchain.info/charts/utxo-count?timespan=60days  and fees are back down to ~0.5 btc/block...
 255 2016-10-27T10:24:57  *** Ylbam_ has quit IRC
 256 2016-10-27T10:26:33  *** jl2012 has quit IRC
 257 2016-10-27T10:27:19  *** jl2012 has joined #bitcoin-core-dev
 258 2016-10-27T10:27:37  *** cdecker has joined #bitcoin-core-dev
 259 2016-10-27T10:27:53  *** Ylbam_ has joined #bitcoin-core-dev
 260 2016-10-27T10:32:16  *** harrymm has joined #bitcoin-core-dev
 261 2016-10-27T10:39:29  <GitHub174> [bitcoin] rebroad opened pull request #9030: Don't process blocktxns when we have the block already. (master...BlocktxnExits) https://github.com/bitcoin/bitcoin/pull/9030
 262 2016-10-27T10:43:33  *** harrymm has quit IRC
 263 2016-10-27T10:46:17  <gmaxwell> andytoshi: wumpus: http://seriot.ch/parsing_json.html  < json test vectors.
 264 2016-10-27T10:48:28  <wumpus> gmaxwell: yeah came up earlier today already there's even an issue :) https://github.com/bitcoin/bitcoin/issues/9028
 265 2016-10-27T10:49:34  *** a_meteorite has quit IRC
 266 2016-10-27T10:49:55  *** a_meteorite has joined #bitcoin-core-dev
 267 2016-10-27T10:58:19  *** harrymm has joined #bitcoin-core-dev
 268 2016-10-27T11:06:14  *** fengling has quit IRC
 269 2016-10-27T11:11:56  *** n1ce has quit IRC
 270 2016-10-27T11:18:02  <jonasschnelli> Just got a report that prioritisetransaction does not work on 0.12?
 271 2016-10-27T11:18:38  <wumpus> on 0.12? or 0.13?
 272 2016-10-27T11:19:10  <jonasschnelli> The reporter reported its working on 0.13 but not on 0.12
 273 2016-10-27T11:20:55  <luke-jr> do we care then?
 274 2016-10-27T11:22:43  <wumpus> I don't
 275 2016-10-27T11:22:54  <wumpus> was briefly in shock because of 0.13.1 :)
 276 2016-10-27T11:25:31  <luke-jr> jonasschnelli: the reporter is a miner? why aren't they on 0.13.0?
 277 2016-10-27T11:25:49  <luke-jr> sounds suspiciously like BU
 278 2016-10-27T11:26:02  <wumpus> yea
 279 2016-10-27T11:28:40  *** n1ce has joined #bitcoin-core-dev
 280 2016-10-27T11:31:44  <jonasschnelli> i don't care as well
 281 2016-10-27T11:32:17  <jonasschnelli> but good to know >if< 0.12 is not working and if so, why 0.13 is working
 282 2016-10-27T11:33:42  *** rebroad has joined #bitcoin-core-dev
 283 2016-10-27T11:34:48  <Victorsueca> 0.12 is supposed to be still supported, should we backport a fix for this?
 284 2016-10-27T11:35:11  <wumpus> if someone writes a fix I'm happy to merge it
 285 2016-10-27T11:36:23  <luke-jr> Eligius didn't use 0.12 for long, but I am pretty certain prioritise worked
 286 2016-10-27T11:37:47  <luke-jr> (and I do check GBT returns the txid when I prioritise stuff)
 287 2016-10-27T11:38:01  <luke-jr> so IMO it's probably either BU nonsense or PEBKAC
 288 2016-10-27T11:38:21  *** cryptapus has joined #bitcoin-core-dev
 289 2016-10-27T11:38:22  *** cryptapus has joined #bitcoin-core-dev
 290 2016-10-27T11:52:19  <jonasschnelli> first we would need to double-check if its not working on 0.12. It was just a report.
 291 2016-10-27T11:52:50  <jonasschnelli> There are some RPC tests.. although not sure when we have added those.
 292 2016-10-27T12:00:13  *** moli has joined #bitcoin-core-dev
 293 2016-10-27T12:04:32  *** a_meteorite has quit IRC
 294 2016-10-27T12:04:43  *** a_meteor_ has joined #bitcoin-core-dev
 295 2016-10-27T12:05:14  <wumpus> I'm surprised if it really doesn't work and we only hear about it now
 296 2016-10-27T12:06:54  *** a_meteor_ has quit IRC
 297 2016-10-27T12:07:23  *** a_meteorite has joined #bitcoin-core-dev
 298 2016-10-27T12:07:56  *** n1ce has quit IRC
 299 2016-10-27T12:09:39  *** n1ce has joined #bitcoin-core-dev
 300 2016-10-27T12:10:31  <GitHub57> [bitcoin] laanwj opened pull request #9032: test: Add format-dependent comparison to bctest (master...2016_10_bctest_smart_compare) https://github.com/bitcoin/bitcoin/pull/9032
 301 2016-10-27T12:11:19  *** a_meteorite has quit IRC
 302 2016-10-27T12:11:32  <wumpus> btcdrak: https://github.com/bitcoin/bitcoin/pull/9032
 303 2016-10-27T12:12:35  *** a_meteorite has joined #bitcoin-core-dev
 304 2016-10-27T12:14:05  <btcdrak> wumpus: interesting
 305 2016-10-27T12:14:19  *** a_meteorite has joined #bitcoin-core-dev
 306 2016-10-27T12:14:25  <wumpus> I'm not even sure the second step should be a fatal error or just a warning
 307 2016-10-27T12:14:46  <wumpus> a_meteorite: please fix your IRC client, you're generating too many join/part messages
 308 2016-10-27T12:14:52  <btcdrak> wumpus: this was really helpful
 309 2016-10-27T12:14:53  <btcdrak> https://github.com/bitcoin/bitcoin/pull/9023
 310 2016-10-27T12:15:43  <wumpus> yes, but I think it makes the test too noisy in the pass case
 311 2016-10-27T12:15:59  <wumpus> printing a diff when the test fails makes sense though
 312 2016-10-27T12:16:11  *** Chris_Stewart_5 has joined #bitcoin-core-dev
 313 2016-10-27T12:16:39  <btcdrak> maybe should shield the pass stuff with a -verbose flag? or ditch the pass logs entirely?
 314 2016-10-27T12:17:08  <wumpus> yes I'd say ditch the pass logs, ideally tests are silent if nothing is wrong
 315 2016-10-27T12:17:11  <wumpus> (esp in travis)
 316 2016-10-27T12:17:31  *** jtimon has joined #bitcoin-core-dev
 317 2016-10-27T12:18:34  * luke-jr publishes Knots 0.13.1 and goes to bed :P
 318 2016-10-27T12:19:33  *** a_meteorite has quit IRC
 319 2016-10-27T12:19:47  <wumpus> btcdrak: this may be already what it does, I was confused by all the logging stuff
 320 2016-10-27T12:20:06  *** a_meteorite has joined #bitcoin-core-dev
 321 2016-10-27T12:20:15  *** ChanServ sets mode: +o wumpus
 322 2016-10-27T12:20:30  <luke-jr> poor a_meteorite is going to fall to Earth
 323 2016-10-27T12:20:34  <btcdrak> iirc it prints pass and fail. lemme rerun quickly
 324 2016-10-27T12:20:55  *** wumpus sets mode: +b *!*@unaffiliated/ameteorite/x-000000001
 325 2016-10-27T12:21:00  <wumpus> luke-jr: hah
 326 2016-10-27T12:21:06  <wumpus> btcdrak: but also in non-verbose mode?
 327 2016-10-27T12:21:18  *** Chris_Stewart_5 has quit IRC
 328 2016-10-27T12:21:32  <btcdrak> ok just checked, by default passes are silent
 329 2016-10-27T12:21:42  <btcdrak> if you add -v then you get full output
 330 2016-10-27T12:21:50  <wumpus> ok, and diffs are printed on failure?
 331 2016-10-27T12:21:58  <btcdrak> https://www.irccloud.com/pastebin/fuxIut4y/
 332 2016-10-27T12:22:28  <wumpus> even in non-verbose mode?
 333 2016-10-27T12:22:56  *** a_meteorite has quit IRC
 334 2016-10-27T12:23:23  *** Chris_Stewart_5 has joined #bitcoin-core-dev
 335 2016-10-27T12:24:11  <btcdrak> oh wait, my cherry-pick failed and I didnt notice :-p
 336 2016-10-27T12:24:25  <wumpus> gah
 337 2016-10-27T12:24:33  <btcdrak> so it is noisy without -v
 338 2016-10-27T12:24:39  <btcdrak> https://www.irccloud.com/pastebin/hd69OPZ4/
 339 2016-10-27T12:24:41  <wumpus> sigh
 340 2016-10-27T12:24:50  * wumpus re-edits his post again
 341 2016-10-27T12:25:49  <GitHub48> [bitcoin] MarcoFalke reopened pull request #9011: 0.13.2 backports (0.13...2016_10_backports_conditional_rc3) https://github.com/bitcoin/bitcoin/pull/9011
 342 2016-10-27T12:26:46  <btcdrak> wumpus: I commented too
 343 2016-10-27T12:27:15  *** MarcoFalke has joined #bitcoin-core-dev
 344 2016-10-27T12:28:04  <btcdrak> wumpus: otherwise the errors are great e.g.
 345 2016-10-27T12:28:07  <btcdrak> https://www.irccloud.com/pastebin/xL5cqNGo/
 346 2016-10-27T12:29:36  <achow101> oh hey, a tag!
 347 2016-10-27T12:29:42  <wumpus> yes that seems useful
 348 2016-10-27T12:30:56  *** wasi has joined #bitcoin-core-dev
 349 2016-10-27T12:31:25  <GitHub163> [bitcoin] MarcoFalke opened pull request #9033: Update build notes for dropping osx 10.7 support (fanquake) (master...Mf1610-docFanquake) https://github.com/bitcoin/bitcoin/pull/9033
 350 2016-10-27T12:36:42  *** Chris_Stewart_5 has quit IRC
 351 2016-10-27T12:38:50  <wumpus> btcdrak: does -v actually work for you?
 352 2016-10-27T12:39:10  <btcdrak> wumpus: it doesnt do anything different under his patch
 353 2016-10-27T12:39:13  <wumpus> I moved the PASSED messages to the debug level, but now I can't get them to output at all
 354 2016-10-27T12:41:30  <btcdrak> same here, hmm
 355 2016-10-27T12:42:24  <wumpus> figured it out
 356 2016-10-27T12:52:17  *** PaulCapestany has quit IRC
 357 2016-10-27T12:56:24  <GitHub49> [bitcoin] laanwj pushed 1 new commit to 0.13: https://github.com/bitcoin/bitcoin/commit/2e2388a5cbb9a6e101b36e4501698fec538a5738
 358 2016-10-27T12:56:25  <GitHub49> bitcoin/0.13 2e2388a Wladimir J. van der Laan: Move release notes to release-notes/release-notes-0.13.1.md...
 359 2016-10-27T12:58:49  <GitHub138> [bitcoin] laanwj pushed 1 new commit to master: https://github.com/bitcoin/bitcoin/commit/a49b4a75a1b671492e65eed17d6894d85ea5ebfd
 360 2016-10-27T12:58:50  <GitHub138> bitcoin/master a49b4a7 Wladimir J. van der Laan: doc: Add release notes for 0.13.1 release
 361 2016-10-27T12:59:35  <timothy> does 0.13.1 requires new or different libraries?
 362 2016-10-27T12:59:39  <timothy> to built
 363 2016-10-27T12:59:40  <GitHub66> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/a49b4a75a1b6...83234d4d1723
 364 2016-10-27T12:59:41  <GitHub66> bitcoin/master ba26d41 Michael Ford: Update build notes for dropping osx 10.7 support...
 365 2016-10-27T12:59:41  <GitHub66> bitcoin/master 83234d4 Wladimir J. van der Laan: Merge #9033: Update build notes for dropping osx 10.7 support (fanquake)...
 366 2016-10-27T12:59:48  <wumpus> compared to what?
 367 2016-10-27T12:59:49  <GitHub134> [bitcoin] laanwj closed pull request #9033: Update build notes for dropping osx 10.7 support (fanquake) (master...Mf1610-docFanquake) https://github.com/bitcoin/bitcoin/pull/9033
 368 2016-10-27T12:59:52  <timothy> 0.13.0
 369 2016-10-27T13:00:08  <wumpus> yes there was at least a patch to boost
 370 2016-10-27T13:00:19  <timothy> so can't I use vanilla boost?
 371 2016-10-27T13:00:32  <wumpus> sure, you always can
 372 2016-10-27T13:00:58  <wumpus> I thought you were talking about the gitian build, if you build using your OS' libraries there no need to do anything special
 373 2016-10-27T13:04:05  *** PaulCapestany has joined #bitcoin-core-dev
 374 2016-10-27T13:07:19  *** laurentmt has joined #bitcoin-core-dev
 375 2016-10-27T13:07:19  *** laurentmt has quit IRC
 376 2016-10-27T13:09:12  *** Chris_Stewart_5 has joined #bitcoin-core-dev
 377 2016-10-27T13:12:53  *** wasi has quit IRC
 378 2016-10-27T13:16:13  *** laurentmt has joined #bitcoin-core-dev
 379 2016-10-27T13:16:18  *** laurentmt has quit IRC
 380 2016-10-27T13:19:25  *** whphhg has joined #bitcoin-core-dev
 381 2016-10-27T13:19:36  <whphhg> Hej, is there a Bitcoin Unlimited channel on freenode?
 382 2016-10-27T13:23:16  <timothy> lol
 383 2016-10-27T13:23:30  <rabidus_> lol
 384 2016-10-27T13:23:39  <timothy> it's like entering on FBI channel and ask for drug
 385 2016-10-27T13:26:44  <PatBoy> hahahah
 386 2016-10-27T13:26:56  *** atroxes has quit IRC
 387 2016-10-27T13:29:25  <wumpus> rofl
 388 2016-10-27T13:31:25  *** wasi has joined #bitcoin-core-dev
 389 2016-10-27T13:32:28  *** Chris_Stewart_5 has quit IRC
 390 2016-10-27T13:33:21  <whphhg> Lol, I wasn't aware it was that bad. :o
 391 2016-10-27T13:33:22  *** atroxes has joined #bitcoin-core-dev
 392 2016-10-27T13:39:40  <BlueMatt> wumpus: so do i wait to update the ppa or just do it today?
 393 2016-10-27T13:41:27  <wumpus> BlueMatt: let me see, how many gitian sigs do we have now
 394 2016-10-27T13:42:19  <wumpus> three matching ones
 395 2016-10-27T13:42:43  <BlueMatt> i said today, not now....still eating breakfast :p
 396 2016-10-27T13:42:46  <wumpus> but no code-signed ones yet. I guess it's somewhat strange to have the ppa built before the binaries available
 397 2016-10-27T13:43:15  <btcdrak> Better not do it until the release actual announcement when we have everything done.
 398 2016-10-27T13:48:01  <BlueMatt> btcdrak: meh, i often do it early...otherwise i forget
 399 2016-10-27T13:48:19  *** Chris_Stewart_5 has joined #bitcoin-core-dev
 400 2016-10-27T13:49:19  *** fengling has joined #bitcoin-core-dev
 401 2016-10-27T13:51:57  <Lauda> BlueMatt please ppa as soon as possible 0.13.0 took forever. :)
 402 2016-10-27T13:53:57  *** Chris_Stewart_5 has quit IRC
 403 2016-10-27T13:57:47  <btcdrak> Lauda: good point :-p
 404 2016-10-27T14:03:28  *** jl2012 has quit IRC
 405 2016-10-27T14:03:53  <michagogo> BlueMatt: is it all ready in terms of packaging, i.e. just a matter of pushing the button?
 406 2016-10-27T14:04:16  *** Ylbam_ has quit IRC
 407 2016-10-27T14:04:35  <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?)
 408 2016-10-27T14:06:17  <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
 409 2016-10-27T14:06:21  <michagogo> Or 48 or something
 410 2016-10-27T14:07:11  <michagogo> (Also, it's unfortunate that only cfields_ can produce the detached sigs…)
 411 2016-10-27T14:10:55  <btcdrak> wumpus: I uploaded my gitian sigs
 412 2016-10-27T14:11:24  <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
 413 2016-10-27T14:11:41  *** Giszmo has joined #bitcoin-core-dev
 414 2016-10-27T14:16:51  <michagogo> wumpus: re: #9028 (and in general), have you considered tagging some issues for Hacktoberfest?
 415 2016-10-27T14:17:03  <BlueMatt> 'tf is hacktoberfest?
 416 2016-10-27T14:17:13  <michagogo> ;;Google hacktoberfest
 417 2016-10-27T14:17:14  <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>
 418 2016-10-27T14:17:23  <BlueMatt> also, isnt october over?
 419 2016-10-27T14:17:43  <michagogo> Well, almost
 420 2016-10-27T14:27:41  *** waxwing has quit IRC
 421 2016-10-27T14:28:33  *** waxwing has joined #bitcoin-core-dev
 422 2016-10-27T14:41:06  <wumpus> would be a bit too late I guess
 423 2016-10-27T14:42:33  <wumpus> (for hacktoberfest)
 424 2016-10-27T14:42:48  <wumpus> woohoo, 6 sigs all match
 425 2016-10-27T14:43:10  <wumpus> ping cfields_
 426 2016-10-27T14:44:00  *** whphhg has left #bitcoin-core-dev
 427 2016-10-27T14:47:35  <GitHub55> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/83234d4d1723...fea5e05a6380
 428 2016-10-27T14:47:36  <GitHub55> bitcoin/master 1c3ecc7 S. Matthew English: instance of 'mem pool' to 'mempool'...
 429 2016-10-27T14:47:36  <GitHub55> bitcoin/master fea5e05 Wladimir J. van der Laan: Merge #9029: instance of 'mem pool' to 'mempool'...
 430 2016-10-27T14:47:46  <GitHub196> [bitcoin] laanwj closed pull request #9029: instance of 'mem pool' to 'mempool' (master...patch-7) https://github.com/bitcoin/bitcoin/pull/9029
 431 2016-10-27T14:54:58  *** pedrobranco has joined #bitcoin-core-dev
 432 2016-10-27T14:56:13  *** luke-jr has quit IRC
 433 2016-10-27T14:56:16  *** AtashiCon has quit IRC
 434 2016-10-27T14:56:20  *** Arnavion3 has joined #bitcoin-core-dev
 435 2016-10-27T14:56:22  *** luke-jr has joined #bitcoin-core-dev
 436 2016-10-27T14:56:24  <sipa> BlueMatt: Oktoberfest is also mostly not in october :)
 437 2016-10-27T14:56:24  *** Arnavion3 is now known as AtashiCon
 438 2016-10-27T14:56:48  <BlueMatt> heh, true
 439 2016-10-27T15:04:40  <andytoshi> thanks gmaxwell (re json test vectors)
 440 2016-10-27T15:12:59  <kanzure> andytoshi: trying to save yourself some work on mimblewimble?
 441 2016-10-27T15:20:30  * michagogo waves at cfields_
 442 2016-10-27T15:27:53  * michagogo watches https://github.com/bitcoin-core/bitcoin-detached-sigs/tags
 443 2016-10-27T15:28:44  <achow101> michagogo: are we harassing cfields_ now to get the code signed sigs?
 444 2016-10-27T15:29:22  <michagogo> achow101: no need to harass, I think - he pushed his gitian sigs up
 445 2016-10-27T15:29:36  <michagogo> I assume the detached will be up shortly
 446 2016-10-27T15:30:02  <michagogo> BlueMatt: there are enough gitian builders around that it's probably safe to get the PPA ready
 447 2016-10-27T15:30:32  <BlueMatt> yea, busy fixing 8969 for now, will soon
 448 2016-10-27T15:30:40  <michagogo> BTW, has anyone here looked into Ubuntu's new "snap" packaging thing?
 449 2016-10-27T15:31:16  *** BCBot has quit IRC
 450 2016-10-27T15:34:29  *** fengling has quit IRC
 451 2016-10-27T15:35:10  *** BashCo has quit IRC
 452 2016-10-27T15:36:22  *** cryptapus has quit IRC
 453 2016-10-27T15:39:53  *** cryptapus has joined #bitcoin-core-dev
 454 2016-10-27T15:39:53  *** cryptapus has joined #bitcoin-core-dev
 455 2016-10-27T15:48:45  <michagogo> wumpus: I don't see the usual PR for the release notes on bitcoin.org
 456 2016-10-27T15:49:42  *** Chris_Stewart_5 has joined #bitcoin-core-dev
 457 2016-10-27T15:52:07  <achow101> are the release notes finalized yet?
 458 2016-10-27T15:56:34  <cfields_> hehe, i was working on the sigs while you guys were busy waving :)
 459 2016-10-27T15:56:49  <cfields_> gitian builders: v0.13.1 sigs are pushed
 460 2016-10-27T15:56:53  <michagogo> achow101: I think so, yeah
 461 2016-10-27T16:00:45  <michagogo> My sigs are pushed as well
 462 2016-10-27T16:01:31  <achow101> so are mine
 463 2016-10-27T16:01:54  <michagogo> wumpus: looks like the release is ready when you are
 464 2016-10-27T16:02:45  <btcdrak> segwit upgrading guide published today
 465 2016-10-27T16:02:46  <btcdrak> https://bitcoincore.org/en/2016/10/27/segwit-upgrade-guide/
 466 2016-10-27T16:04:30  <michagogo> https://github.com/bitcoin-core/bitcoincore.org/pull/241 needs updating
 467 2016-10-27T16:05:30  *** BashCo has joined #bitcoin-core-dev
 468 2016-10-27T16:06:31  <cfields_> btcdrak: you can add ckpool to the mining list. and the cgminer PR hasn't been merged yet.
 469 2016-10-27T16:07:12  <btcdrak> ok
 470 2016-10-27T16:08:49  *** rebroad has quit IRC
 471 2016-10-27T16:10:43  *** BCBot has joined #bitcoin-core-dev
 472 2016-10-27T16:10:55  <btcdrak> seems like the binaries will be ready today?
 473 2016-10-27T16:14:10  *** BCBot has quit IRC
 474 2016-10-27T16:16:32  <andytoshi> kanzure: no, i have a rust json parsing library for bitcoin purposes, a low-priority TODO is for me to aggressively compare its behaviour to that of univalue
 475 2016-10-27T16:17:32  <cfields_> btcdrak: technically just need 1 more match i think, which i'm sure will show up any minute
 476 2016-10-27T16:21:10  <michagogo> cfields_: that match is probably going to be wumpus
 477 2016-10-27T16:21:24  <michagogo> Who is the one that does the release anyway
 478 2016-10-27T16:23:27  *** laurentmt has joined #bitcoin-core-dev
 479 2016-10-27T16:26:57  *** laurentmt has quit IRC
 480 2016-10-27T16:35:37  <cfields_> btcdrak: thanks
 481 2016-10-27T16:36:43  <sipa> what does mf mean?
 482 2016-10-27T16:36:55  <sipa> "0.13.1 signed mf"
 483 2016-10-27T16:37:20  <MarcoFalke> my initials
 484 2016-10-27T16:37:26  <MarcoFalke> :P
 485 2016-10-27T16:37:36  <sipa> oh, of course
 486 2016-10-27T16:37:46  <cfields_> I read it as Samuel L. Jackson.
 487 2016-10-27T16:37:46  * sipa stupid
 488 2016-10-27T16:37:55  <sipa> ...?
 489 2016-10-27T16:39:13  <cfields_> as in: I've had it with these MarcoFalke snakes, on this MarcoFalke plane!
 490 2016-10-27T16:40:02  <sipa> i see.
 491 2016-10-27T16:45:51  *** cryptapus has quit IRC
 492 2016-10-27T16:47:18  *** cryptapus has joined #bitcoin-core-dev
 493 2016-10-27T16:59:19  <MarcoFalke> Heh, I should change it to m4r(0f41k3 as there will be 1337 commits in the repo after it is merged.
 494 2016-10-27T17:23:24  *** laurentmt has joined #bitcoin-core-dev
 495 2016-10-27T17:24:54  *** cryptapus has quit IRC
 496 2016-10-27T17:25:43  *** laurentmt has quit IRC
 497 2016-10-27T17:30:25  *** Ylbam_ has joined #bitcoin-core-dev
 498 2016-10-27T17:31:27  <wumpus> hahaha
 499 2016-10-27T17:35:51  *** cryptapus has joined #bitcoin-core-dev
 500 2016-10-27T17:41:15  *** belcher has quit IRC
 501 2016-10-27T17:43:44  *** jl2012 has joined #bitcoin-core-dev
 502 2016-10-27T17:54:34  *** dcousens has quit IRC
 503 2016-10-27T17:56:19  *** achow101_ has joined #bitcoin-core-dev
 504 2016-10-27T17:57:12  <achow101_> are we so lucky that the time from tag to release will be less than 12 hours this time>
 505 2016-10-27T17:57:13  <achow101_> ?
 506 2016-10-27T18:03:44  <btcdrak> achow101_: looks like everything has been done barring release notes and upload to bitcoin.org
 507 2016-10-27T18:04:01  <btcdrak> s/notes/announce/
 508 2016-10-27T18:04:23  <achow101_> :D
 509 2016-10-27T18:04:30  <btcdrak> meeting time? or is everyone down at the pub having a well deserved pint?
 510 2016-10-27T18:04:46  <achow101_> I think you're an hour early
 511 2016-10-27T18:05:00  <btcdrak> wait, did the clocks change?
 512 2016-10-27T18:05:17  <achow101_> idk, depends on your country
 513 2016-10-27T18:05:33  <btcdrak> automatic clock update so I would never know >_>
 514 2016-10-27T18:05:44  <btcdrak> this explains a lot...
 515 2016-10-27T18:06:26  <achow101_> dst ends for me next week
 516 2016-10-27T18:07:04  <sipa> it's one hour from now
 517 2016-10-27T18:07:24  <sipa> btcdrak: set it in your calendar as 7pm iceland time
 518 2016-10-27T18:10:52  *** frederic94500 has joined #bitcoin-core-dev
 519 2016-10-27T18:12:04  <morcos> jonasschnelli: i think apple gave us an idea.  you should move the fee slider to the touch bar.
 520 2016-10-27T18:12:23  <btcdrak> sipa: let's all just move to Iceland.
 521 2016-10-27T18:12:33  <sipa> morcos: 'touch bar' ?
 522 2016-10-27T18:12:49  <morcos> what they replaced function keys with on the new macbook pros
 523 2016-10-27T18:12:53  <jonasschnelli> sipa: new MacBook Pro physical UX element
 524 2016-10-27T18:13:05  <jonasschnelli> A screen replaces the F function keys
 525 2016-10-27T18:13:13  <sipa> i don't understand
 526 2016-10-27T18:13:15  <BlueMatt> wtf is a "physical UX element"
 527 2016-10-27T18:13:16  <jonasschnelli> morcos: I need to watch the presentation
 528 2016-10-27T18:13:23  <BlueMatt> sipa: they replace the top line of your keyboard with an ipad
 529 2016-10-27T18:13:42  <jonasschnelli> http://photos.reportinglive.com/p/2016-10-27/f1477589812.jpg
 530 2016-10-27T18:13:56  <btcdrak> o.O
 531 2016-10-27T18:14:11  <sipa> i still don't understand what it means to move the fee slider
 532 2016-10-27T18:14:21  <achow101_> looks stupid
 533 2016-10-27T18:14:29  <morcos> there was some PR discussion about the right way for the fee slider to work in QT
 534 2016-10-27T18:14:36  <jeremyrubin> Let's add touchid support at least...
 535 2016-10-27T18:15:45  <btcdrak> what is touchid?
 536 2016-10-27T18:15:53  <achow101_> the fingerprint sensor stuff
 537 2016-10-27T18:16:16  <jeremyrubin> fingerprint sensor + secure enclave
 538 2016-10-27T18:16:52  <jonasschnelli> finger print has no plausible deniability
 539 2016-10-27T18:17:01  <gmaxwell> the lenovo x1s have a touchscreen at the top of the keyboard instead of fkeys, it's awful.
 540 2016-10-27T18:17:28  <BlueMatt> jonasschnelli: and your machine is..uhhh...covered in your fingerprints
 541 2016-10-27T18:17:43  <btcdrak> Did anyone see that presentation where someone lifted a fingerprint off a photo of someone and reproduced the print on a 3D printer... and managed to open their phone with it? I think it was a German politician's phone.
 542 2016-10-27T18:17:52  <sipa> BlueMatt: i'm sure my keyboard is already covered with fingerprints :)
 543 2016-10-27T18:17:56  <jonasschnelli> Right... adhesive tape is sufficient to unlock
 544 2016-10-27T18:18:15  <btcdrak> seems like security theatre
 545 2016-10-27T18:18:32  <jonasschnelli> Probably state sponsored move.. :)
 546 2016-10-27T18:18:46  <jeremyrubin> gmaxwell: it's a different thing than that kind
 547 2016-10-27T18:18:47  <jonasschnelli> You can now force everyone to unlock your HDD/SDD
 548 2016-10-27T18:18:53  <achow101_> btcdrak: mythbusters did an episode about fingerprint spoofing
 549 2016-10-27T18:18:54  <jeremyrubin> is that one on X1 even a screen?
 550 2016-10-27T18:19:16  <btcdrak> This was it in 2014 http://www.bbc.com/news/technology-30623611
 551 2016-10-27T18:19:25  <jeremyrubin> Also touchid doesn't usually replace password
 552 2016-10-27T18:20:38  <jonasschnelli> jeremyrubin: Yeah. But if you login with touchid after a cold-start... I guess it replaces passwords.
 553 2016-10-27T18:20:45  <jonasschnelli> It's probably different then on iOS
 554 2016-10-27T18:20:46  <btcdrak> I prefer passwords + smartcards
 555 2016-10-27T18:20:55  <jonasschnelli> Yes. FIDO enabled hardware wallet
 556 2016-10-27T18:20:59  <jonasschnelli> Works since 10.11 on OSX
 557 2016-10-27T18:21:01  *** gabridome has joined #bitcoin-core-dev
 558 2016-10-27T18:21:03  <sipa> fingerprint unlocking is so annoyingly convenient :(
 559 2016-10-27T18:21:09  <jonasschnelli> heh
 560 2016-10-27T18:21:26  <jonasschnelli> What I want is fingerprint & passphrase
 561 2016-10-27T18:22:20  <btcdrak> I want to keep my fingers
 562 2016-10-27T18:25:10  *** pedrobranco has quit IRC
 563 2016-10-27T18:25:40  *** pedrobranco has joined #bitcoin-core-dev
 564 2016-10-27T18:26:21  <NicolasDorier> while playing doing my node in C#, I tried a way to speedup IBD by 50%: Basically I prefetch the UTXO and tx id's (for BIP30) of block N+1 while validating block N.  Still a bit early to call victory, but might be a piste to explore for core
 565 2016-10-27T18:26:54  *** d9b4bef9 has quit IRC
 566 2016-10-27T18:27:49  <sipa> NicolasDorier: interesting idea, though i'm not sure it's so useful - i expect we already have the majority of utxo entires cached
 567 2016-10-27T18:28:08  *** d9b4bef9 has joined #bitcoin-core-dev
 568 2016-10-27T18:28:15  <sipa> but i guess it could speed up looking for the ones that aren't
 569 2016-10-27T18:28:17  <NicolasDorier> sipa: the thing that slow down is BIP30
 570 2016-10-27T18:28:24  <NicolasDorier> because we are checking for a negative
 571 2016-10-27T18:28:29  <NicolasDorier> so it is not in the cache
 572 2016-10-27T18:28:42  <sipa> we don't do that anymore, afaik
 573 2016-10-27T18:29:12  <sipa> only before bip34 activation
 574 2016-10-27T18:29:23  <NicolasDorier> oh checking that
 575 2016-10-27T18:29:31  *** frederic94500 has quit IRC
 576 2016-10-27T18:30:16  *** pedrobranco has quit IRC
 577 2016-10-27T18:31:30  <NicolasDorier> ah yeah you are right. It's strange, I do'nt know why I get more speed on validation.... well I think I'll get a better idea once my node reach block above 400 000
 578 2016-10-27T18:31:41  *** Frederic94500 has joined #bitcoin-core-dev
 579 2016-10-27T18:32:18  <NicolasDorier> the commit on disk is in background on core right ?
 580 2016-10-27T18:32:36  <NicolasDorier> except TxUndo if I remember
 581 2016-10-27T18:41:03  *** nibor has joined #bitcoin-core-dev
 582 2016-10-27T18:44:17  *** BCBot has joined #bitcoin-core-dev
 583 2016-10-27T18:45:02  <NicolasDorier> mmh... well, I'll wait I reach later block mayb it's not the case
 584 2016-10-27T18:47:16  *** kangx has joined #bitcoin-core-dev
 585 2016-10-27T18:54:10  *** gabridome has quit IRC
 586 2016-10-27T19:00:25  *** whphhg has joined #bitcoin-core-dev
 587 2016-10-27T19:00:37  <jtimon> meeting...
 588 2016-10-27T19:01:16  <wumpus> congrats on 0.13.1 everyone!
 589 2016-10-27T19:01:21  * btcdrak rings the gong
 590 2016-10-27T19:01:23  <wumpus> #startmeeting
 591 2016-10-27T19:01:23  <lightningbot> Meeting started Thu Oct 27 19:01:23 2016 UTC.  The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
 592 2016-10-27T19:01:23  <lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
 593 2016-10-27T19:01:26  <jtimon> 0.13.1 is out 18 mins ago! yay
 594 2016-10-27T19:01:40  <CodeShark> binaries?
 595 2016-10-27T19:01:42  <kanzure> btcdrak: looks like faq menu entry is working now https://bitcoincore.org/en/2016/10/27/segwit-upgrade-guide/
 596 2016-10-27T19:01:59  <jeremyrubin> here
 597 2016-10-27T19:02:26  <wumpus> CodeShark: https://bitcoin.org/bin/bitcoin-core-0.13.1/
 598 2016-10-27T19:02:27  * luke-jr wakes up
 599 2016-10-27T19:02:44  *** dermoth has joined #bitcoin-core-dev
 600 2016-10-27T19:02:46  <CodeShark> Nice!
 601 2016-10-27T19:02:49  <gmaxwell> https://www.reddit.com/r/Bitcoin/comments/59pt66/bitcoin_core_0131_released/
 602 2016-10-27T19:03:04  <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
 603 2016-10-27T19:03:51  <wumpus> bitcoin.org should be updated after travis passes on https://github.com/bitcoin-dot-org/bitcoin.org/pull/1400
 604 2016-10-27T19:04:25  <morcos> congrats everyone!
 605 2016-10-27T19:04:31  <sipa> indeed!
 606 2016-10-27T19:04:53  <wumpus> woohoo!
 607 2016-10-27T19:05:03  <sipa> and thanks everyone for getting us this far
 608 2016-10-27T19:05:37  <luke-jr> wumpus: did we get the gitian builds already? is that a record? :o
 609 2016-10-27T19:05:54  <wumpus> luke-jr: yes, four signed builders IIRC
 610 2016-10-27T19:06:24  <luke-jr> or maybe it just feels like a record since it was the middle of the night for me
 611 2016-10-27T19:06:30  <jtimon> I'm trying the gitian builder script for the first time
 612 2016-10-27T19:06:33  <wumpus> it may be a record
 613 2016-10-27T19:06:43  <wumpus> very fast at least
 614 2016-10-27T19:07:09  <jtimon> btcdrak reminded me I have no good excuse for not doing gitian builds
 615 2016-10-27T19:07:33  <sipa> i haven't even started :(
 616 2016-10-27T19:08:20  <jtimon> well, I have never done it so it may take some time, but the sooner I learn...
 617 2016-10-27T19:08:22  <btcdrak> wumpus: I dont see a signed message from you with the binary hashes
 618 2016-10-27T19:08:44  <wumpus> BlueMatt: you can release your PPA now (if you didn't yet)
 619 2016-10-27T19:09:03  <wumpus> btcdrak: https://bitcoin.org/bin/bitcoin-core-0.13.1/SHA256SUMS.asc
 620 2016-10-27T19:09:04  <BlueMatt> wumpus: i have not yet, will try to get that out
 621 2016-10-27T19:09:23  <jonasschnelli> BlueMatt: don't forget to add libzmq
 622 2016-10-27T19:09:35  <harding> btcdrak: https://lists.linuxfoundation.org/pipermail/bitcoin-core-dev/2016-October/000023.html
 623 2016-10-27T19:09:37  <jonasschnelli> Some uses have complained about the missing ZMQ support
 624 2016-10-27T19:10:12  <BlueMatt> jonasschnelli: yup
 625 2016-10-27T19:11:30  <wumpus> ok, any other topics today than 0.13.1?
 626 2016-10-27T19:11:51  <kanzure> i was going to ask sipa or jtimon about libconsensus follow-up stuff
 627 2016-10-27T19:12:04  <sipa> i'm the wrong person to ask
 628 2016-10-27T19:12:16  <wumpus> I'm kind of tired so I wouldn't mind ending early :p
 629 2016-10-27T19:12:59  <jtimon> kanzure: nothing to report, nobody suggested anything to me or gave me any feedback since last week
 630 2016-10-27T19:13:05  <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
 631 2016-10-27T19:13:24  <BlueMatt> few minutes late there, gmaxwell
 632 2016-10-27T19:13:27  <jtimon> been focusing on the signedblocks patch
 633 2016-10-27T19:13:32  <gmaxwell> Just noticed wumpus hadn't done it. :)
 634 2016-10-27T19:13:43  <sipa> maybe we can discuss signed blocks a bit
 635 2016-10-27T19:13:51  <gmaxwell> So there are a number of things we want to do in a 0.13.2; so those should get in soon.
 636 2016-10-27T19:14:06  <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
 637 2016-10-27T19:14:10  <morcos> (signed blocks)
 638 2016-10-27T19:14:11  <gmaxwell> (I guess some are in and just need to backport to 0.13 branch.
 639 2016-10-27T19:14:21  <wumpus> no, it's not meant to replace the current testnet
 640 2016-10-27T19:14:24  <kanzure> re: testnet i also saw the suggestion of loading testnet params from json file
 641 2016-10-27T19:14:31  <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
 642 2016-10-27T19:14:51  <gmaxwell> morcos: my expectation was that it would just be another option. Obviously it would be useless for testing much of anything mining related.
 643 2016-10-27T19:15:11  <jtimon> what I have implemented is from .conf file, not .json file
 644 2016-10-27T19:15:11  <wumpus> indeed there should at least be a PoW testnet
 645 2016-10-27T19:15:27  <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
 646 2016-10-27T19:15:47  <morcos> perhaps it would be possible for transactions to easily end up on both?
 647 2016-10-27T19:15:49  <kanzure> jtimon: didn't mean to recommend a specific file format; i was just pulling a thing from memory.
 648 2016-10-27T19:15:55  *** gabridome has joined #bitcoin-core-dev
 649 2016-10-27T19:16:05  <morcos> but maybe thats askign for trouble
 650 2016-10-27T19:16:06  <wumpus> yes the file format is completely not important
 651 2016-10-27T19:16:13  <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
 652 2016-10-27T19:16:16  <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"
 653 2016-10-27T19:16:28  <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.
 654 2016-10-27T19:16:31  <sipa> and those aren't reconcilable, i think
 655 2016-10-27T19:16:56  <jtimon> that alone should be helpful for rapidly creating a new segwitnet (for the next thing) or whatever
 656 2016-10-27T19:17:03  <btcdrak> Blog post is up https://bitcoincore.org/en/2016/10/27/release-0.13.1/
 657 2016-10-27T19:17:13  <wumpus> one testnet is simply not enough for all testing scenarios
 658 2016-10-27T19:17:16  <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.
 659 2016-10-27T19:17:19  <wumpus> btcdrak: awesome
 660 2016-10-27T19:17:32  <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.
 661 2016-10-27T19:18:07  <wumpus> kanzure: right - within a trusted group using a regtest is just as useful as signed blocks
 662 2016-10-27T19:18:25  <kanzure> oh is that what the proposal is-- i'll have to go look. sorry.
 663 2016-10-27T19:18:45  <wumpus> it's only when exposing publicly that signing is necessary so people can't grief by generating e.g. tons of blocks
 664 2016-10-27T19:19:30  <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.
 665 2016-10-27T19:19:38  <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.
 666 2016-10-27T19:19:57  <JackH> when will ubuntu ppa's be updated?
 667 2016-10-27T19:20:17  <BlueMatt> JackH: when i get to it (today)
 668 2016-10-27T19:20:29  <JackH> ah sweet, you are fast this time then
 669 2016-10-27T19:20:30  <sipa> btcdrak: nice, the timeline is cool
 670 2016-10-27T19:21:25  <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?)
 671 2016-10-27T19:21:56  <wumpus> I think everyone can sign up to make PPAs
 672 2016-10-27T19:22:11  * btcdrak is reading scrollback
 673 2016-10-27T19:22:52  <BlueMatt> luke-jr: its not bad
 674 2016-10-27T19:22:55  <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..
 675 2016-10-27T19:23:03  <luke-jr> wumpus: yes, it's just not very clear how one would actually make them, especially someone who doesn't use Ubuntu :p
 676 2016-10-27T19:23:48  *** pedrobranco has joined #bitcoin-core-dev
 677 2016-10-27T19:25:07  <Frederic94500> #bitcoin If segwit doesn't activate, he will be activate to the next 2016 blocks?
 678 2016-10-27T19:25:29  <sipa> parse error
 679 2016-10-27T19:25:30  <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
 680 2016-10-27T19:25:43  <BlueMatt> Frederic94500: we're in the middle of a meeting, please go to #bitcoin
 681 2016-10-27T19:26:01  <jtimon> for the hash of the genesis block depends on -chainpetname
 682 2016-10-27T19:26:06  <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
 683 2016-10-27T19:26:16  <wumpus> luke-jr: no need to run ubuntu yourself
 684 2016-10-27T19:26:36  <jonasschnelli> Luke-Jr: there are also meta-generator that auto-generated deb/PPA and fedora, etc. out of one script/conf
 685 2016-10-27T19:26:47  <BlueMatt> wumpus: only in theory....the upload tool stuff is really a bitch to get installed on non-debian systems
 686 2016-10-27T19:26:55  <luke-jr> :x
 687 2016-10-27T19:27:17  *** Frederic94500 has quit IRC
 688 2016-10-27T19:27:24  <wumpus> BlueMatt: haha that's sad, I didn't know
 689 2016-10-27T19:27:34  <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
 690 2016-10-27T19:27:58  *** pedrobranco has quit IRC
 691 2016-10-27T19:28:05  <jtimon> well, signed blocks have other advantages for testing, but it's definitely more dsiruptive
 692 2016-10-27T19:28:07  *** gabridome has quit IRC
 693 2016-10-27T19:28:16  <wumpus> bitcoin.org change is merged
 694 2016-10-27T19:29:08  <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
 695 2016-10-27T19:29:41  <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
 696 2016-10-27T19:29:47  <wumpus> right, changing the block header structure is what makes it scary
 697 2016-10-27T19:30:53  <petertodd> wumpus: s/scary/a lot of work/ :)
 698 2016-10-27T19:31:12  <gmaxwell> topic: suggestion final alert stuff.
 699 2016-10-27T19:31:12  <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
 700 2016-10-27T19:31:21  <wumpus> I mean more s/scary/high risk/
 701 2016-10-27T19:31:31  <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
 702 2016-10-27T19:31:35  <wumpus> the implementation work is not so bad, review, sure
 703 2016-10-27T19:31:38  <sipa> petertodd: pick 2
 704 2016-10-27T19:31:50  <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
 705 2016-10-27T19:31:51  <jtimon> we could make other chainparams count for the genesis block hash
 706 2016-10-27T19:32:04  *** cryptapus has quit IRC
 707 2016-10-27T19:33:10  <wumpus> I mean introducing some union into CBlockHeader would mean there'd be a risk of regression even in the non-testing case
 708 2016-10-27T19:33:25  <petertodd> wumpus: ah, yes, good point
 709 2016-10-27T19:33:28  <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)
 710 2016-10-27T19:33:46  <petertodd> wumpus: I'm wrong - that is scary
 711 2016-10-27T19:33:52  <btcdrak> sipa: you have to thank harding! he wrote it all.
 712 2016-10-27T19:35:15  <kanzure> what is remaining re: final alert things?
 713 2016-10-27T19:35:24  <kanzure> was the page on one of the .org sites merged
 714 2016-10-27T19:35:55  <jtimon> topic suggestion: are we removing the use of checkpoints for progress estimation?
 715 2016-10-27T19:35:55  <gmaxwell> kanzure: we're not on that toopic now.
 716 2016-10-27T19:36:24  <gmaxwell> topic suggestion: My work removing checkpoints _completely_.
 717 2016-10-27T19:36:45  <wumpus> #topic removing checkpoints
 718 2016-10-27T19:37:24  <gmaxwell> I have a branch that is removing checkpoints. Haven't totally taken them out yet because I need to replace progress estimation.
 719 2016-10-27T19:37:46  <gmaxwell> It's not hard to do that, just takes a little twiddling.
 720 2016-10-27T19:37:50  <wumpus> that's good news - progress estimation is probably the least interesting use of them
 721 2016-10-27T19:38:00  <gmaxwell> https://github.com/gmaxwell/bitcoin/tree/remove_checkpoints
 722 2016-10-27T19:38:01  <wumpus> yea
 723 2016-10-27T19:38:11  <wumpus> #link https://github.com/gmaxwell/bitcoin/tree/remove_checkpoints
 724 2016-10-27T19:38:47  <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:
 725 2016-10-27T19:38:50  <wumpus> did you run into something difficult / uncertain?
 726 2016-10-27T19:39:42  <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.
 727 2016-10-27T19:39:43  <wumpus> what about the DoS protection?
 728 2016-10-27T19:40:07  <wumpus> consensus change, as in a softfork?
 729 2016-10-27T19:40:14  <morcos> do tell
 730 2016-10-27T19:40:20  <gmaxwell> not a softfork. I'm telling.
 731 2016-10-27T19:40:38  <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.
 732 2016-10-27T19:41:34  <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.
 733 2016-10-27T19:41:35  <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
 734 2016-10-27T19:41:49  <jtimon> isn't the minimum difficulty check a softfork?
 735 2016-10-27T19:42:06  <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. :)
 736 2016-10-27T19:42:10  <wumpus> petertodd: well it wouldn't lock in specific blocks as the checkpoints do
 737 2016-10-27T19:42:10  <petertodd> er, gregs #2 thing makes my statement invalid :)
 738 2016-10-27T19:42:40  <jtimon> gmaxwell: yeah, it's a softfork in the pedantic sense
 739 2016-10-27T19:42:42  <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
 740 2016-10-27T19:42:45  <gmaxwell> jtimon: in a sense, but an unobservable one. Yes.
 741 2016-10-27T19:42:45  <jeremyrubin> I don't think that's great...
 742 2016-10-27T19:43:03  <jeremyrubin> Can't difficulty fall that low under a soft fork to a different PoW?
 743 2016-10-27T19:43:16  <jeremyrubin> (not that that should happen)
 744 2016-10-27T19:43:19  <petertodd> jeremyrubin: yes, and at that point your idea of what bitcoin is is so insecure as to be useless
 745 2016-10-27T19:43:22  <gmaxwell> jeremyrubin: then you take out the rule.
 746 2016-10-27T19:43:30  <jtimon> like really imposing the 21 M limit, that was a softfork too, but no need to use bip9 to deploy I guess
 747 2016-10-27T19:43:40  <petertodd> jtimon: +1
 748 2016-10-27T19:43:43  <Chris_Stewart_5> wouldn't that be a hard fork to remove it if it was enforced?
 749 2016-10-27T19:43:53  <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.
 750 2016-10-27T19:44:11  <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
 751 2016-10-27T19:44:24  <gmaxwell> If someone worried that 16 million were too high, there is a pretty broad range that the number could reasonable be set in.
 752 2016-10-27T19:44:54  <petertodd> gmaxwell: honestly, I'd be inclined to go even higher - 10 machines is absolutely nothing
 753 2016-10-27T19:45:18  <gmaxwell> Anything over 100k would pretty much halt any real risk headerflooding, with current hardware. 16M adds a good amount of headroom.
 754 2016-10-27T19:45:22  *** gabridome has joined #bitcoin-core-dev
 755 2016-10-27T19:45:24  <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..
 756 2016-10-27T19:45:25  *** gabridome has quit IRC
 757 2016-10-27T19:45:36  <jeremyrubin> petertodd: I disagree, but that's more of a wizards topic
 758 2016-10-27T19:45:50  <jtimon> gmaxwell: are you sure you want to change CheckBlockHeader instead of CheckProofOfWork ?
 759 2016-10-27T19:45:53  <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?
 760 2016-10-27T19:45:57  <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
 761 2016-10-27T19:46:10  <jeremyrubin> petertodd: e.g., something like tadge's proof of idle
 762 2016-10-27T19:46:11  <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.
 763 2016-10-27T19:46:23  <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
 764 2016-10-27T19:46:25  <gmaxwell> morcos: it is preserved.
 765 2016-10-27T19:46:33  <gmaxwell> to the extent that it exists.
 766 2016-10-27T19:46:34  <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
 767 2016-10-27T19:46:46  <jtimon> Chris_Stewart_5: yeah if you want a different pow just hardfork
 768 2016-10-27T19:46:49  *** gabridome has joined #bitcoin-core-dev
 769 2016-10-27T19:46:58  <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.
 770 2016-10-27T19:47:01  <morcos> ok, i need to think about it more.. but i think we should analyze all those scenarios
 771 2016-10-27T19:47:21  <gmaxwell> morcos: but thats also why my figure is ~10 devices and not 10,000 devices. :)
 772 2016-10-27T19:47:43  <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.
 773 2016-10-27T19:47:48  <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. :)
 774 2016-10-27T19:47:51  <gmaxwell> But I expected thought and discussion on it.
 775 2016-10-27T19:48:12  <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
 776 2016-10-27T19:48:24  <petertodd> gmaxwell: if hardware improves, do we up the min diff again? IMO that'd be reasonable
 777 2016-10-27T19:48:31  <morcos> petertodd: not if you've softforked in other PoW requirements that the attackers don't have the hashing or whateve rto produce
 778 2016-10-27T19:48:42  <gmaxwell> BlueMatt: So hold up there.
 779 2016-10-27T19:49:01  <gmaxwell> BlueMatt: I think what I propos has _exactly_ as good protection for that as we currently have, if not somewhat better.
 780 2016-10-27T19:49:09  <Chris_Stewart_5> And this solves header flooding because it requires the attacker to provide headers with ATLEAST that much difficulty, correct?
 781 2016-10-27T19:49:18  <BlueMatt> gmaxwell: didnt disagree, only suggested that ideally we'd fix the issues we have now
 782 2016-10-27T19:49:18  <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
 783 2016-10-27T19:49:19  <gmaxwell> BlueMatt: right now we won't accept lower difficulty blocks after we've validated up to a paritcular checkpoint.
 784 2016-10-27T19:49:30  <gmaxwell> (okay I'll still explain as other people might miss this)
 785 2016-10-27T19:49:51  <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.
 786 2016-10-27T19:50:10  <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
 787 2016-10-27T19:50:11  <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)
 788 2016-10-27T19:50:33  <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
 789 2016-10-27T19:50:51  <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.
 790 2016-10-27T19:50:53  <BlueMatt> (under first-peer-is-evil attacks, but ok)
 791 2016-10-27T19:50:57  *** achow101_ has quit IRC
 792 2016-10-27T19:51:00  <gmaxwell> BlueMatt: but my proposal needs only headers.
 793 2016-10-27T19:51:16  <gmaxwell> oh under first peer is attacker
 794 2016-10-27T19:51:17  <petertodd> morcos: anyway, good to do up some deployment scenarios regardless to explain how that'd work
 795 2016-10-27T19:51:17  <BlueMatt> oh, i thought we applied checkpoints against headers now
 796 2016-10-27T19:51:18  <BlueMatt> nvm
 797 2016-10-27T19:51:49  <sipa> BlueMatt: we do; after passing a certain checkpoint, we don't accept headers that fork off before that checkpoint
 798 2016-10-27T19:52:06  <BlueMatt> ok, lets take this offline
 799 2016-10-27T19:52:11  <BlueMatt> suggested additional topics?
 800 2016-10-27T19:52:13  <gmaxwell> Okay, thats the overview.
 801 2016-10-27T19:52:42  <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?
 802 2016-10-27T19:53:38  <jtimon> mhmm, pindexBestHeader->nChainWork < UintToArith256(consensusParams.nMinimumChainWork) ? consensusParams.powLimit : consensusParams.powLimitLater
 803 2016-10-27T19:53:38  <jtimon> what about instead... block.nHeight < consensusParams.highPowLimitHeight ? consensusParams.powLimit : consensusParams.powLimitLater
 804 2016-10-27T19:53:39  <wumpus> #topic the final alert
 805 2016-10-27T19:53:53  <wumpus> no reason IMO
 806 2016-10-27T19:53:55  <btcdrak> gmaxwell: please get it over with.
 807 2016-10-27T19:54:39  <gmaxwell> Okay. will coordinate.
 808 2016-10-27T19:55:13  <gmaxwell> jtimon: that would make it trivial for an attacker to capture you on a fake chain.
 809 2016-10-27T19:55:38  <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.
 810 2016-10-27T19:56:48  <jtimon> gmaxwell: how am I prevented from handling reorgs in the same way as you?
 811 2016-10-27T19:57:14  <sipa> jtimon: creating many blocks is easy. creating much work is hard
 812 2016-10-27T19:57:43  <gmaxwell> anyting left in the meeting (I'll continue this convo after)
 813 2016-10-27T19:57:49  <jtimon> what I think it's add less risk since  consensusParams.highPowLimitHeight is fixed but nMinimumChainWork is expected to chain with each release, no?
 814 2016-10-27T19:58:24  <jtimon> I must be missing something, I don't see the vulnerability that my proposed change introduces
 815 2016-10-27T19:58:26  <wumpus> ok, that concludes the meeting I think
 816 2016-10-27T19:58:34  <wumpus> #endmeeting
 817 2016-10-27T19:58:34  <lightningbot> Meeting ended Thu Oct 27 19:58:34 2016 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
 818 2016-10-27T19:58:34  <lightningbot> Minutes:        http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-10-27-19.01.html
 819 2016-10-27T19:58:34  <lightningbot> Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-10-27-19.01.txt
 820 2016-10-27T19:58:34  <lightningbot> Log:            http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-10-27-19.01.log.html
 821 2016-10-27T19:59:07  <btcdrak> party time?
 822 2016-10-27T19:59:11  <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
 823 2016-10-27T19:59:16  <BlueMatt> but that shouldnt matter much
 824 2016-10-27T19:59:27  <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.
 825 2016-10-27T19:59:56  <jtimon> yes, how my proposed change makes your branch more vulnerable to that attack is what I don't see
 826 2016-10-27T20:00:17  <jtimon> why wouldn't I reorg to the most work change?
 827 2016-10-27T20:00:31  <gmaxwell> Because you won't even process the first block in that chain.
 828 2016-10-27T20:00:34  *** d_t has joined #bitcoin-core-dev
 829 2016-10-27T20:00:39  <sipa> jtimon: because you'll reject the low-difficulty headers from the real chain you get later
 830 2016-10-27T20:00:41  <jtimon> just like your branch without my proposed change, I think
 831 2016-10-27T20:00:58  *** murch has joined #bitcoin-core-dev
 832 2016-10-27T20:01:08  <jtimon> mhmm, no, say highPowLimitHeight is the current height whatever it is
 833 2016-10-27T20:01:15  <gmaxwell> No. My branch does not activate until you have enough work to be the real chain at the time of the release.
 834 2016-10-27T20:01:50  <gmaxwell> jtimon: yes, 436182.  Say it's that.
 835 2016-10-27T20:02:04  <gmaxwell> Attacker computes 500000 diff 1 headers, and gives you that.
 836 2016-10-27T20:02:08  <jtimon> right, and mine activates at a fixed height, say 436182
 837 2016-10-27T20:02:16  <gmaxwell> Under my code you would sitll reorg to the best chain.
 838 2016-10-27T20:02:19  <jtimon> ok, I accept that chain
 839 2016-10-27T20:02:29  <jtimon> then when I see the real one I reorg, no?
 840 2016-10-27T20:02:29  <gmaxwell> Under your code you would not reorg to the best chain.
 841 2016-10-27T20:02:33  <gmaxwell> No.
 842 2016-10-27T20:02:41  <jtimon> why not?
 843 2016-10-27T20:02:45  <sipa> jtimon: no, you'll reject the low-difficulty headers once you pass the watermark
 844 2016-10-27T20:02:56  <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.
 845 2016-10-27T20:03:01  <sipa> jtimon: because this is a fix to the otherwise existing DoS of being able to feed someone low-difficulty headers
 846 2016-10-27T20:03:11  <jtimon> oh, we have limits on reorg, right, sorry, I get it, thanks
 847 2016-10-27T20:03:19  <sipa> no, we don't have limits on reorg
 848 2016-10-27T20:03:20  <gmaxwell> We don't have limits on reorg.
 849 2016-10-27T20:03:28  <jtimon> mhm, let me read again
 850 2016-10-27T20:03:34  <sipa> we just reject headers that are too low difficulty once we know we're past that stafe
 851 2016-10-27T20:03:38  <sipa> *stage
 852 2016-10-27T20:04:08  <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
 853 2016-10-27T20:04:30  <gmaxwell> if you don't reject low diff headers someone can exaust your memory/disk with header flooding.
 854 2016-10-27T20:05:00  <gmaxwell> which the code you were quoting protect against but wouldn't if it were a height check.
 855 2016-10-27T20:06:42  <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
 856 2016-10-27T20:06:56  <jtimon> I don't get it but let's move on I will think more about it
 857 2016-10-27T20:07:16  *** waxwing has quit IRC
 858 2016-10-27T20:07:21  *** Guyver2 has joined #bitcoin-core-dev
 859 2016-10-27T20:07:50  <sipa> jtimon: being past 436182 does not mean you're on the right chain
 860 2016-10-27T20:07:50  <sipa> an attacker can veriy easily create such a long chain
 861 2016-10-27T20:08:08  *** Guyver2 has left #bitcoin-core-dev
 862 2016-10-27T20:08:15  <sipa> creating as much work of the real 43612 chain is nearly impossible
 863 2016-10-27T20:08:18  <jtimon> sipa: right it means the min diff is higher from now on
 864 2016-10-27T20:08:26  <jtimon> right
 865 2016-10-27T20:08:43  <sipa> jtimon: if yhe min difficulty is more than 1 you will reject the early part of the real chain!!!
 866 2016-10-27T20:09:04  <sipa> because the real chain has diff 1 in the beginning
 867 2016-10-27T20:09:05  <jtimon> and "my code" will always prefer the real chain because it's more work
 868 2016-10-27T20:09:05  <Chris_Stewart_5> Not sure if this this is a good question or not, but is this something deployed with BIP9?
 869 2016-10-27T20:09:24  <jtimon> sipa: no, the early part of the real chain is height < 436182 !
 870 2016-10-27T20:09:29  *** waxwing has joined #bitcoin-core-dev
 871 2016-10-27T20:10:02  <sipa> jtimon: we DO NOT want to accept just any header below height 436182
 872 2016-10-27T20:10:18  <sipa> jtimon: that is exactly the DoS attack this change is intended to fix
 873 2016-10-27T20:10:57  *** Guyver2 has joined #bitcoin-core-dev
 874 2016-10-27T20:11:07  <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
 875 2016-10-27T20:11:15  <sipa> even in an entirely unrelated chain
 876 2016-10-27T20:11:31  <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
 877 2016-10-27T20:11:31  <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()
 878 2016-10-27T20:11:46  <BlueMatt> does anyone object to me making it call BlockChecked for AcceptBlock failures?
 879 2016-10-27T20:11:53  *** achow101_ has joined #bitcoin-core-dev
 880 2016-10-27T20:11:55  <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
 881 2016-10-27T20:12:20  <BlueMatt> so then ProcessNewBlock would only use its CValidationState argument (which would then just be optional) in case of failures, not invalid blocks
 882 2016-10-27T20:12:34  <sipa> jtimon: it only protects us once we see the real chain
 883 2016-10-27T20:12:57  <sipa> jtimon: your proposal can trigger even if we don't have the real chain
 884 2016-10-27T20:14:50  <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
 885 2016-10-27T20:15:24  <sipa> so you haven't solved the issue
 886 2016-10-27T20:15:58  <jtimon> note I didn't say pindexBestHeader->nHeight but block.nHeight (that is, the header you are checking now)
 887 2016-10-27T20:16:38  <sipa> you're really doing somwthing completely different
 888 2016-10-27T20:16:58  <jtimon> well, that line is supposed to save us from min diff blocks in the future, no?
 889 2016-10-27T20:18:03  <sipa> your change does not prevent that
 890 2016-10-27T20:18:20  <sipa> someone can keep spamming low-height headers in your proposal
 891 2016-10-27T20:19:02  <jtimon> oh, and you won't ignore them if they're < 436182, sorry, I finally get it
 892 2016-10-27T20:19:05  <jtimon> thanks
 893 2016-10-27T20:20:03  <instagibbs> Congrats! Managed to sleep exactly through meeting time.
 894 2016-10-27T20:20:39  <BlueMatt> ok, I'm removing CValidationState from ProcessNewBlock
 895 2016-10-27T20:21:38  <jtimon> sorry BlueMatt wasn't listening
 896 2016-10-27T20:22:21  <btcdrak> sipa: remember to update your http://bitcoin.sipa.be/ver9-2k.png graphs :)
 897 2016-10-27T20:22:27  <sipa> instagibbs: and through the release
 898 2016-10-27T20:22:31  <sipa> btcdrak: indeed!
 899 2016-10-27T20:23:29  *** pedrobranco has joined #bitcoin-core-dev
 900 2016-10-27T20:23:32  <instagibbs> Yeah missed all the action.
 901 2016-10-27T20:24:33  *** achow101_ has quit IRC
 902 2016-10-27T20:25:35  <sipa> BlueMatt: iirc the only reason for CVS in PNB is to return system failure conditions
 903 2016-10-27T20:26:08  <BlueMatt> sipa: nope, its also used to return AcceptBlock errors
 904 2016-10-27T20:26:09  <BlueMatt> sipa: also, its never checked for system failure conditions
 905 2016-10-27T20:27:02  <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)
 906 2016-10-27T20:27:40  *** pedrobranco has quit IRC
 907 2016-10-27T20:33:20  <BlueMatt> jtimon: https://github.com/bitcoin/bitcoin/commit/a4f82de1bdde644e9bad4c524b638dd5bd4d69f7
 908 2016-10-27T20:33:43  <BlueMatt> also, the fact that you can access commits via that url when they arent in the bitcoin/bitcoin repo is freaky
 909 2016-10-27T20:35:25  <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
 910 2016-10-27T20:36:40  *** belcher has joined #bitcoin-core-dev
 911 2016-10-27T20:38:27  <BlueMatt> anyway, I'll pr it after https://github.com/bitcoin/bitcoin/pull/8969, I know suhas was waiting on it
 912 2016-10-27T20:38:28  <jtimon> BlueMatt: yeah, I definitely like that commit
 913 2016-10-27T20:38:57  *** skyraider has joined #bitcoin-core-dev
 914 2016-10-27T20:39:18  <jtimon> yeah I only briefly looked at that one, sorry
 915 2016-10-27T20:40:06  <murch> quick question: Does 0.13.1 already include functions for creation of SegWit transactions?
 916 2016-10-27T20:40:22  <BlueMatt> yes
 917 2016-10-27T20:40:29  <BlueMatt> so did 0.13.0
 918 2016-10-27T20:40:46  <BlueMatt> (its all gated on segwit being activated, so it works on testnet)
 919 2016-10-27T20:41:31  <murch> ah okay, thanks
 920 2016-10-27T20:56:06  *** Chris_Stewart_5 has quit IRC
 921 2016-10-27T21:09:55  *** Chris_Stewart_5 has joined #bitcoin-core-dev
 922 2016-10-27T21:11:53  *** Victor_sueca has joined #bitcoin-core-dev
 923 2016-10-27T21:13:34  *** jl2012 has quit IRC
 924 2016-10-27T21:14:04  *** Victorsueca has quit IRC
 925 2016-10-27T21:20:35  <BlueMatt> wait, did we un-support qt5?
 926 2016-10-27T21:20:42  <BlueMatt> wasnt there talk of deprecating it?
 927 2016-10-27T21:26:10  *** Guyver2 has quit IRC
 928 2016-10-27T21:35:24  *** wasi has quit IRC
 929 2016-10-27T21:45:58  <cfields_> BlueMatt: you mean qt4?
 930 2016-10-27T21:48:26  <BlueMatt> uhh, yes
 931 2016-10-27T21:49:45  <cfields_> BlueMatt: i'd say it's pretty well deprecated already. iirc the discussion was about completely dropping support
 932 2016-10-27T21:52:46  <BlueMatt> mmm, nvm, realized it only breaks precise, which was broken by c++11
 933 2016-10-27T21:56:19  <michagogo> Ack, missed another meeting :-/
 934 2016-10-27T21:56:34  <michagogo> Did it start late, or just late ping?
 935 2016-10-27T21:57:49  <luke-jr> I think at this point, once Qt4 becomes a burden we can probably drop it?
 936 2016-10-27T21:57:52  <luke-jr> BlueMatt: what breaks precise?
 937 2016-10-27T21:58:06  <BlueMatt> there is no qt4 on precise
 938 2016-10-27T21:58:18  <BlueMatt> also, the boost in precise doesnt compile in c++11 mode
 939 2016-10-27T21:58:55  <luke-jr> so don't build qt4?
 940 2016-10-27T21:59:14  <luke-jr> I thought we didn't use any boost that had ABI changes for C++11
 941 2016-10-27T21:59:41  <BlueMatt> luke-jr: https://svn.boost.org/trac/boost/ticket/6198
 942 2016-10-27T22:00:20  <luke-jr> compile with GCC?
 943 2016-10-27T22:00:40  *** kadoban has quit IRC
 944 2016-10-27T22:00:42  <BlueMatt> the gcc in precise does not support c++11
 945 2016-10-27T22:00:46  <luke-jr> ugh
 946 2016-10-27T22:01:06  *** kadoban has joined #bitcoin-core-dev
 947 2016-10-27T22:01:34  <BlueMatt> the ppa currently has an empty dummy package for precise
 948 2016-10-27T22:01:37  <BlueMatt> because fuck precise
 949 2016-10-27T22:01:44  <luke-jr> uh
 950 2016-10-27T22:01:49  <luke-jr> at least leave the old version?
 951 2016-10-27T22:02:02  <BlueMatt> no
 952 2016-10-27T22:02:06  <luke-jr> …
 953 2016-10-27T22:02:25  <luke-jr> patch the code to #define size size_arg? >_<
 954 2016-10-27T22:02:34  <BlueMatt> no
 955 2016-10-27T22:02:45  <BlueMatt> feel free to create the debian/ folder and send it to me and I'll upload
 956 2016-10-27T22:02:51  <BlueMatt> I'm not fighting with it to make precise work
 957 2016-10-27T22:02:54  <luke-jr> XD
 958 2016-10-27T22:03:11  <luke-jr> wait, to do the PPA you just upload the debian folder?
 959 2016-10-27T22:03:20  <BlueMatt> and the original source archive
 960 2016-10-27T22:03:25  <BlueMatt> (ie git archive)
 961 2016-10-27T22:04:00  <BlueMatt> and two other strange metadata files
 962 2016-10-27T22:09:22  <luke-jr> any reason we can't get gitian to produce the files needing to upload? <.<
 963 2016-10-27T22:09:41  <BlueMatt> gitian? they're all in the source tree
 964 2016-10-27T22:09:46  <BlueMatt> except signed by my pgp key
 965 2016-10-27T22:10:05  *** kadoban has quit IRC
 966 2016-10-27T22:10:11  <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)
 967 2016-10-27T22:10:14  <luke-jr> so we don't need to do https://help.launchpad.net/Packaging/PPA/BuildingASourcePackage ?
 968 2016-10-27T22:11:04  *** MarcoFalke has left #bitcoin-core-dev
 969 2016-10-27T22:11:54  <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
 970 2016-10-27T22:12:20  <BlueMatt> so, no, its really entirely useless to do anything in gitian for this
 971 2016-10-27T22:15:27  *** blkdb has quit IRC
 972 2016-10-27T22:16:05  *** blkdb has joined #bitcoin-core-dev
 973 2016-10-27T22:17:15  *** pedrobranco has joined #bitcoin-core-dev
 974 2016-10-27T22:20:09  *** cdecker has quit IRC
 975 2016-10-27T22:21:18  *** pedrobranco has quit IRC
 976 2016-10-27T22:33:11  *** lclc has quit IRC
 977 2016-10-27T22:36:22  <gmaxwell> when did we back off the checkblocks check? was that in 0.13.0 or 0.13.1?
 978 2016-10-27T22:59:50  <BlueMatt> heh, 66/130 connections segwit (with 52/8 blocked)
 979 2016-10-27T22:59:55  <BlueMatt> guess preferential peering works =D
 980 2016-10-27T23:15:32  <sipa> gmaxwell: 0
 981 2016-10-27T23:15:38  <sipa> gmaxwell: 0.13.1
 982 2016-10-27T23:15:58  *** dstadulis has joined #bitcoin-core-dev
 983 2016-10-27T23:16:11  <gmaxwell> sipa: explaines people saying it stats so much faster.
 984 2016-10-27T23:16:26  <sipa> ha
 985 2016-10-27T23:16:31  <gmaxwell> sipa: how many connections does your node have?
 986 2016-10-27T23:17:06  <gmaxwell> I am 124/124.
 987 2016-10-27T23:21:42  *** dstadulis has quit IRC
 988 2016-10-27T23:22:04  *** dstadulis has joined #bitcoin-core-dev
 989 2016-10-27T23:26:45  <sipa> compiling 0.13.1 now
 990 2016-10-27T23:27:11  <sipa> i was on 0.13.0 i think
 991 2016-10-27T23:29:49  <BlueMatt> ok, all ppas are built and published
 992 2016-10-27T23:34:34  *** echonaut has quit IRC
 993 2016-10-27T23:34:34  *** echonaut1 has joined #bitcoin-core-dev
 994 2016-10-27T23:38:31  <gmaxwell> BlueMatt: if the ppas are downloadable, go post on reddit?
 995 2016-10-27T23:43:42  *** d_t has quit IRC
 996 2016-10-27T23:43:48  *** dstadulis has quit IRC
 997 2016-10-27T23:49:15  *** justan0theruser has joined #bitcoin-core-dev
 998 2016-10-27T23:51:13  *** justanotheruser has quit IRC
 999 2016-10-27T23:51:51  <luke-jr> Why does bitcoincore announcements ML include tracking?
1000 2016-10-27T23:57:23  <sipa> ?
1001 2016-10-27T23:57:54  <luke-jr> there's an invisible <img> with a tracking id at the bottom
1002 2016-10-27T23:58:22  <luke-jr> it attempts to load the image from the internet, thus informing the webserver it was read