1 2015-10-14T00:03:17  *** tripleslash has quit IRC
  2 2015-10-14T00:10:36  *** maaku has quit IRC
  3 2015-10-14T00:26:25  *** maaku_ has joined #bitcoin-core-dev
  4 2015-10-14T00:27:15  *** maaku_ is now known as maaku
  5 2015-10-14T00:31:57  *** molly has joined #bitcoin-core-dev
  6 2015-10-14T00:34:59  *** moli has quit IRC
  7 2015-10-14T00:44:14  *** Ylbam has quit IRC
  8 2015-10-14T01:01:47  *** d_t has quit IRC
  9 2015-10-14T01:09:13  *** moli has joined #bitcoin-core-dev
 10 2015-10-14T01:11:59  *** molly has quit IRC
 11 2015-10-14T01:15:13  *** molly has joined #bitcoin-core-dev
 12 2015-10-14T01:18:19  *** moli has quit IRC
 13 2015-10-14T01:40:30  *** belcher has quit IRC
 14 2015-10-14T01:41:48  *** d_t has joined #bitcoin-core-dev
 15 2015-10-14T02:12:31  *** maaku has quit IRC
 16 2015-10-14T02:16:11  *** maaku has joined #bitcoin-core-dev
 17 2015-10-14T02:16:35  *** maaku is now known as Guest88900
 18 2015-10-14T02:29:41  <gmaxwell> looks like github may be compromised or badly broken: https://github.com/bitcoin/bitcoin/commits/master?author=saracen
 19 2015-10-14T02:34:43  <midnightmagic> i thought that was an artifact of the conversion process
 20 2015-10-14T02:37:19  <phantomcircuit> gmaxwell, it's always been like that
 21 2015-10-14T02:37:25  <phantomcircuit> (i had the same thought to once)
 22 2015-10-14T02:38:41  <midnightmagic> it's consistent with my (extensive) experience with scm->scm conversion tools that were badly-written
 23 2015-10-14T02:39:08  <gmaxwell> hard to see how thats possible, since that account is much newer than the commits in question.
 24 2015-10-14T02:39:44  <phantomcircuit> gmaxwell, timestamps on commits are not verified by github
 25 2015-10-14T02:39:50  <CodeShark> the commits don't have to have the right time
 26 2015-10-14T02:39:59  <CodeShark> you can set your clock back a decade and commit
 27 2015-10-14T02:40:35  <gmaxwell> thats not my point. I mean it couldn't have _always_ been that way because that account didn't exist always. :)
 28 2015-10-14T02:40:40  <midnightmagic> argh does github order by date or by git log order..?
 29 2015-10-14T02:40:51  <CodeShark> by date - it sucks
 30 2015-10-14T02:43:05  <midnightmagic> whoah!!
 31 2015-10-14T02:43:53  <gmaxwell> yea, okay. I reproduced the stupidity.
 32 2015-10-14T02:45:56  <gmaxwell> https://github.com/bitcoin/bitcoin/commits/master?author=gmaxwell&page=6  < see bottom
 33 2015-10-14T02:46:03  <gmaxwell> first commit in bitcoin core repo is now from me.
 34 2015-10-14T03:13:15  *** moli has joined #bitcoin-core-dev
 35 2015-10-14T03:13:46  <Luke-Jr> [02:37:19] <phantomcircuit> gmaxwell, it's always been like that <-- +1
 36 2015-10-14T03:14:25  <gmaxwell> Thats not actually true.
 37 2015-10-14T03:14:45  <gmaxwell> Unless you think it was also always like this: https://github.com/bitcoin/bitcoin/commits/master?page=264
 38 2015-10-14T03:14:47  <Luke-Jr> I don't remember a time where the contributors page didn't bug that way
 39 2015-10-14T03:15:05  <Luke-Jr> gmaxwell: it was, but with a different user
 40 2015-10-14T03:15:46  <Luke-Jr> (disclaimer: I did not view that exact page before)
 41 2015-10-14T03:16:09  <gmaxwell> perhaps we should change the merge script to refuse to merge commits that don't have dots in their email addresses.
 42 2015-10-14T03:16:19  *** molly has quit IRC
 43 2015-10-14T03:16:37  <Luke-Jr> do we have any recent like that?
 44 2015-10-14T03:16:41  <gmaxwell> Luke-Jr: it was messed up like that from whatever moment saracen added sirius-m@1a98c847-1fd6-4fd8-948a-caf3550aa51b to their email list.
 45 2015-10-14T03:17:00  <gmaxwell> Thus my latest example, I just went and reproduced using sirius-m@1a98c847-1fd6-4fd8-948a-caf3550aa51b
 46 2015-10-14T03:17:09  <Luke-Jr> gmaxwell: sure, but that was a long time ago
 47 2015-10-14T03:17:13  <gmaxwell> oops I ment s_nakamoto@1a98c847-1fd6-4fd8-948a-caf3550aa51b in the penultimate case.
 48 2015-10-14T03:18:08  <Luke-Jr> I noticed it at least as early as when we were contacting devs to sign that joint letter
 49 2015-10-14T03:18:15  <gmaxwell> in any case, I went and reserved all the other dotless names in the history. .. looks like it only lets a single github user claim them, first come first serve.
 50 2015-10-14T03:18:18  <Luke-Jr> pretty sure I had seen it before then, though
 51 2015-10-14T03:18:33  <Luke-Jr> gmaxwell: ☹ now GitHub shows bogus stats for you
 52 2015-10-14T03:18:39  <Luke-Jr> at least ignoring saracen was easy
 53 2015-10-14T03:18:51  <gmaxwell> Luke-Jr: nah, it shows up as seperate users.
 54 2015-10-14T03:18:55  <Luke-Jr> O.o
 55 2015-10-14T03:19:30  <Luke-Jr> not on https://github.com/bitcoin/bitcoin/graphs/contributors AFAIK
 56 2015-10-14T03:28:26  *** CodeShark has quit IRC
 57 2015-10-14T03:51:12  *** Guest88900 has quit IRC
 58 2015-10-14T03:56:34  *** maaku has joined #bitcoin-core-dev
 59 2015-10-14T03:56:58  *** maaku is now known as Guest71817
 60 2015-10-14T03:57:20  *** Guest71817 is now known as maaku
 61 2015-10-14T03:57:50  *** ParadoxSpiral has joined #bitcoin-core-dev
 62 2015-10-14T03:58:23  *** Thireus has quit IRC
 63 2015-10-14T03:59:24  *** alpalp has quit IRC
 64 2015-10-14T05:02:12  *** phantomcircuit has quit IRC
 65 2015-10-14T05:03:27  *** phantomcircuit has joined #bitcoin-core-dev
 66 2015-10-14T05:03:48  *** phantomcircuit is now known as Guest96009
 67 2015-10-14T05:13:50  *** Guest96009 has quit IRC
 68 2015-10-14T05:14:03  *** phantomcircuit_ has joined #bitcoin-core-dev
 69 2015-10-14T05:20:26  *** Naphex has quit IRC
 70 2015-10-14T05:27:54  *** Naphex has joined #bitcoin-core-dev
 71 2015-10-14T05:29:06  *** phantomcircuit_ is now known as phantomcircuit
 72 2015-10-14T05:44:05  *** Thireus has joined #bitcoin-core-dev
 73 2015-10-14T05:59:50  <wumpus> have any problems with 0.11.1rc2 or 0.10.3rc2 been reported? if not, I'd like to make them final today
 74 2015-10-14T06:00:07  <gmaxwell> None that I'm aware of.
 75 2015-10-14T06:11:36  *** tripleslash has joined #bitcoin-core-dev
 76 2015-10-14T06:30:03  *** Thireus has quit IRC
 77 2015-10-14T06:36:27  *** Ylbam has joined #bitcoin-core-dev
 78 2015-10-14T06:57:55  *** malte has quit IRC
 79 2015-10-14T07:03:52  *** Thireus has joined #bitcoin-core-dev
 80 2015-10-14T07:04:15  *** trippysalmon has joined #bitcoin-core-dev
 81 2015-10-14T07:14:45  *** paveljanik has quit IRC
 82 2015-10-14T07:15:10  *** malte has joined #bitcoin-core-dev
 83 2015-10-14T07:38:06  <Luke-Jr> wumpus: FWIW, going through master looking for bugfixes we failed to backport; will ping when done
 84 2015-10-14T07:39:29  <wumpus> it's too late for backporting anything now
 85 2015-10-14T07:39:36  *** ParadoxSpiral_ has joined #bitcoin-core-dev
 86 2015-10-14T07:39:44  <wumpus> we need a release out due to the upnp issue
 87 2015-10-14T07:40:05  <wumpus> after that we can continue backporting of course for the next minor release...
 88 2015-10-14T07:40:27  <Luke-Jr> that's fine, I don't expect to find anything important
 89 2015-10-14T07:41:35  <Luke-Jr> most potentially-concerning so far is https://github.com/bitcoin/bitcoin/pull/6688 , but obviously things haven't broken terribly without it
 90 2015-10-14T07:42:20  *** ParadoxSpiral has quit IRC
 91 2015-10-14T07:48:07  <wumpus> adding it tothe list
 92 2015-10-14T07:50:25  <wumpus> petertodd noted that https://github.com/bitcoin/bitcoin/pull/6498 should have been backported too (but may be non-trivial)
 93 2015-10-14T07:52:19  *** moli has quit IRC
 94 2015-10-14T07:56:33  <Luke-Jr> "the list"?
 95 2015-10-14T08:00:20  <wumpus> the list of things to backport (currently containing two items)
 96 2015-10-14T08:01:56  *** alpalp has joined #bitcoin-core-dev
 97 2015-10-14T08:04:10  * Luke-Jr ponders why midnightmagic just built v0.11.0rc1 O.o
 98 2015-10-14T08:04:10  <wumpus>  * [new tag]         v0.10.3 -> v0.10.3
 99 2015-10-14T08:04:50  <wumpus>  * [new tag]         v0.11.1 -> v0.11.1
100 2015-10-14T08:06:51  *** randy-waterhouse has joined #bitcoin-core-dev
101 2015-10-14T08:09:20  <Luke-Jr> is https://github.com/jtimon/bitcoin/commit/6a07eb676a020b0035173facb25f92f1ff6380f7 a bugfix hiding inside https://github.com/bitcoin/bitcoin/pull/6424 ? O.o
102 2015-10-14T08:11:09  <midnightmagic> Luke-Jr: just trying to be complete. Is that a duplicate?
103 2015-10-14T08:11:20  <Luke-Jr> midnightmagic: no, just stale :p
104 2015-10-14T08:11:56  <midnightmagic> :-)
105 2015-10-14T08:14:16  <midnightmagic> lot of tags I've been remiss on..
106 2015-10-14T08:14:59  <wumpus> at this point I would not recommend building any 0.10 versions < 0.10.3 and 0.11 versions < 0.11.1
107 2015-10-14T08:15:30  <wumpus> __unless you somehow swap the miniupnpc version, but in that case it wouldn't match so what is the point
108 2015-10-14T08:17:53  <wumpus> may make sense to do a 0.9.6 with just miniupnpc upgraded, thoug most likely anyone still on 0.9.x will be running a self-built heavily patched version anyway, probably without upnp
109 2015-10-14T08:25:14  <wumpus> but first priority is getting 0.11.1 (and possibly 0.10.3) to people
110 2015-10-14T08:25:50  <GitHub172> [bitcoin] luke-jr opened pull request #6825: [WIP] Backport bugfixes to 0.11 (2015-10-14 / a1d623d) (0.11...backport-bugfixes-to-0.11-20151014) https://github.com/bitcoin/bitcoin/pull/6825
111 2015-10-14T08:41:19  *** d_t has quit IRC
112 2015-10-14T08:53:40  *** alpalp has quit IRC
113 2015-10-14T09:01:22  <midnightmagic> wumpus: I build only for end-binary verification and triangulation. All resulting artifacts are discarded. This is for gitian signature completion only. I explicitly build older builds to help triangulate continuing reproducibility.
114 2015-10-14T09:06:50  <wumpus> midnightmagic: right, makes sense
115 2015-10-14T09:13:07  *** jl2012_ has joined #bitcoin-core-dev
116 2015-10-14T09:13:12  *** jl2012 has quit IRC
117 2015-10-14T09:26:17  *** CodeShark has joined #bitcoin-core-dev
118 2015-10-14T09:27:13  *** CodeShark has quit IRC
119 2015-10-14T09:27:22  *** CodeShark has joined #bitcoin-core-dev
120 2015-10-14T09:35:48  *** randy-waterhouse has quit IRC
121 2015-10-14T09:39:04  *** randy-waterhouse has joined #bitcoin-core-dev
122 2015-10-14T10:34:14  *** Guest58630 is now known as GAit
123 2015-10-14T11:10:59  *** go1111111 has quit IRC
124 2015-10-14T11:12:17  *** go1111111 has joined #bitcoin-core-dev
125 2015-10-14T11:29:49  <GitHub58> [bitcoin] MarcoFalke opened pull request #6827: [rpc-tests] Check return code (master...MarcoFalke-2015-rpcTestsReturnCode) https://github.com/bitcoin/bitcoin/pull/6827
126 2015-10-14T12:33:47  <GitHub52> [bitcoin] MarcoFalke opened pull request #6828: [rpc-tests] fundrawtransaction: Update fee after minRelayTxFee increase (master...MarcoFalke-2015-fundrawtransactionTestFix) https://github.com/bitcoin/bitcoin/pull/6828
127 2015-10-14T12:59:32  *** molly has joined #bitcoin-core-dev
128 2015-10-14T13:24:45  *** stonecoldpat1 has left #bitcoin-core-dev
129 2015-10-14T14:01:14  *** Thireus has quit IRC
130 2015-10-14T14:25:30  *** Thireus has joined #bitcoin-core-dev
131 2015-10-14T14:44:44  <cfields> gitian builders: 0.10.3 osx detached signature: https://bitcoincore.org/cfields/bitcoin-0.10.3/signature.tar.gz
132 2015-10-14T14:50:45  <wumpus> github should be automatically reporting that, weird
133 2015-10-14T14:51:46  <wumpus> (at least, pushes to master on the detached sigs repository should be reported)
134 2015-10-14T14:53:11  <cfields> wumpus: 0.10.3 didn't use the repo, still have to manually fetch it
135 2015-10-14T14:54:11  <wumpus> oh? I am, somehow, using the automatic fetching with 0.10.3
136 2015-10-14T14:55:34  * wumpus must be doing something wrong, let me check
137 2015-10-14T14:56:31  * cfields checks the releases rc2 dmg
138 2015-10-14T14:57:01  <wumpus> ... ugh
139 2015-10-14T15:01:35  <cfields> wumpus: yikes. mismatch on rc2 :\
140 2015-10-14T15:02:49  <wumpus> it's interesting that no one reported the invalid signature, the only conclusion from that is that no one tried the osx dmg for 0.10.3rc2 - which I guess makes sense, 0.10.x is bound to have very few users
141 2015-10-14T15:03:38  <cfields> yea
142 2015-10-14T15:04:06  <cfields> also points out that you were correct to suggest writing the checksum of the unsigned file into the sig payload a whlie back
143 2015-10-14T15:04:29  <wumpus> yes
144 2015-10-14T15:04:42  *** treehug88 has joined #bitcoin-core-dev
145 2015-10-14T15:04:58  <wumpus> attaching the wrong signature should ideally fail :)
146 2015-10-14T15:05:47  <cfields> yea
147 2015-10-14T15:06:02  <cfields> for windows it does, that actually saved me on rc2
148 2015-10-14T15:06:37  <cfields> i'll make it simulate that for osx via checksums. adding now.
149 2015-10-14T15:07:38  *** d_t has joined #bitcoin-core-dev
150 2015-10-14T15:17:57  <kanzure> "Presumably, the server closed the connection before. sending a valid response." (http BadStatusLine error) when calling getinfo. any hints on replicating this? i am only seeing this intermittently on some remote testing server (in the middle of a bunch of other testing), so not sure how to isolate this particular problem.
151 2015-10-14T15:20:10  <wumpus> kanzure: that tends to happen when the http connection times out server-side, python is pretty bad at handling that
152 2015-10-14T15:23:32  <wumpus> kanzure: see commit ddf98d1
153 2015-10-14T15:31:21  <kanzure> why would getinfo timeout so quickly?
154 2015-10-14T15:31:22  *** moli has joined #bitcoin-core-dev
155 2015-10-14T15:32:59  <wumpus> the problem as I understand is it not that the call that times out, but the http connection you're sending it on may have timed out *before* you're even able to send it
156 2015-10-14T15:33:13  <wumpus> but this only applies to master, which has http timeouts
157 2015-10-14T15:34:19  *** molly has quit IRC
158 2015-10-14T15:37:10  <wumpus> there may well be a different issue, but it may help troubleshooting
159 2015-10-14T15:38:58  <kanzure> wumpus: for that to be the source of my problem, the connection must have been opened long before i made the getinfo call?
160 2015-10-14T15:41:49  <wumpus> yes - at least "-rpcservertimeout" seconds, and you must be using master
161 2015-10-14T15:42:02  <kanzure> hmm maybe i'll go try -rpcservertimeout=0
162 2015-10-14T15:42:11  <kanzure> yes this is on master (ish) (a week old maybe)
163 2015-10-14T15:43:50  <morcos> cfields: any chance you want to think about nLastBlockFile for a sec?
164 2015-10-14T15:44:14  <cfields> morcos: sure. give me 5 min to wrap something up?
165 2015-10-14T15:44:18  <morcos> sure
166 2015-10-14T15:53:26  *** Thireus has quit IRC
167 2015-10-14T16:00:20  *** CodeShark has quit IRC
168 2015-10-14T16:02:36  *** d_t has quit IRC
169 2015-10-14T16:04:34  *** d_t has joined #bitcoin-core-dev
170 2015-10-14T16:12:50  <cfields> morcos: what's up?
171 2015-10-14T16:13:22  <cfields> wow, that took 30. felt like 5. sorry bout that :\
172 2015-10-14T16:13:42  <morcos> cfields: ok so i've been trying to make sure there isn't an issue with pruning accidentally deleting the wrong block files
173 2015-10-14T16:14:29  <morcos> and there is a small issue in that during a reindex, the state of vinfoBlockFiles are still being updated, so if you submitblock you could munge a bunch of stuff or cause pruning and delete even worse stuff
174 2015-10-14T16:14:44  <morcos> so that needs to be fixed
175 2015-10-14T16:15:05  <morcos> but in the course of trying to trace through all this stuff, nLastBlockFile is kind of confusing
176 2015-10-14T16:15:13  <morcos> what is is really supposed to represent
177 2015-10-14T16:15:20  <morcos> where you're going to write the next block to?
178 2015-10-14T16:15:51  <morcos> why when you do a reindex does it follow along as you process blocks from your block files and possibly end up not in your latest block file?
179 2015-10-14T16:16:16  <morcos> wouldn't it make sense if it was really your last block file?
180 2015-10-14T16:17:20  <cfields> hmm, let me take a look. as i remembered, it meant "the file the next write should go to", but i don't remember the reorg specifics
181 2015-10-14T16:19:14  <morcos> ok, in particular i'm wondering whether it might make sense for line 2506 to read nLastBlockFile = max(nFile, nLastBlockFile)
182 2015-10-14T16:20:14  <morcos> i just dont understand why it ever needs to go backwards
183 2015-10-14T16:21:58  *** jl2012 has joined #bitcoin-core-dev
184 2015-10-14T16:22:09  <morcos> it turns out the belt and suspenders searching for additional contiguous vInfoBlockFiles in LoadBlockIndexDB is actually required, because after a reindex, nLastBlockFile can end up somewhere earlier.
185 2015-10-14T16:22:36  *** jl2012_ has quit IRC
186 2015-10-14T16:23:17  <morcos> interestingly pruning can cause gaps in blockfiles, but because you can't reindex after pruning, and pruning only searches up to nLastBlockFile, you can't end up with gaps after the position of nLastBlockFile
187 2015-10-14T16:24:38  <cfields> hmm yes, without max() that looks very strange
188 2015-10-14T16:25:11  <morcos> i mean it works, and you might actually end up writing new blocks in the spare space inside earlier blockfiles if they are small blocks
189 2015-10-14T16:25:18  <cfields> still reading and re-remembering
190 2015-10-14T16:25:19  <morcos> but its just kind of confusing
191 2015-10-14T16:25:27  <cfields> right
192 2015-10-14T16:28:28  <cfields> ah yes, that was the logic as i remembered it. It points to the first place where there's space to write a block, but not necessarily the last one
193 2015-10-14T16:28:38  *** Thireus has joined #bitcoin-core-dev
194 2015-10-14T16:29:26  <morcos> well after a reindex, it points to the last block that was processed.  irrelevant as to where there is space, but then when you go to write you move forward from there until you find space to write
195 2015-10-14T16:34:18  <cfields> still looking
196 2015-10-14T16:37:04  *** AtashiCon has quit IRC
197 2015-10-14T16:37:08  *** Arnavion3 has joined #bitcoin-core-dev
198 2015-10-14T16:37:12  *** Arnavion3 is now known as AtashiCon
199 2015-10-14T16:37:32  <michagogo> wumpus: I'd have caught the rc2 dmg thing if I were at my computer
200 2015-10-14T16:37:47  <michagogo> But that unfortunately hasn't happened much at all lately
201 2015-10-14T16:38:31  <michagogo> I've been doing something new these days (starting a couple months ago), 9-5, with a 2-3.5 hour commute each way :-/
202 2015-10-14T16:38:43  <michagogo> Doesn't leave me much leisure time.
203 2015-10-14T16:44:02  <cfields> morcos: ok, i believe i remember the logic now
204 2015-10-14T16:44:06  *** jcorgan_ has joined #bitcoin-core-dev
205 2015-10-14T16:44:06  *** jcorgan_ has joined #bitcoin-core-dev
206 2015-10-14T16:44:33  <morcos> cfields: sorry to make you page that all in, but i took so long tracing it out this morning, and i wanted to document or something for the future, so just making sure i have it right
207 2015-10-14T16:46:13  <cfields> morcos: fKnown is only (as far as i can see?) true in the case of a reindex. Imagine the typical reindex case. something has reported corruption, so you're scanning all blocks on disk blindly. There's a good chance that some are valid and some aren't. If you get through 100 blockfiles, and the last valid block was in file 50, it makes sense to resume writing at 50 rather than at 100.
208 2015-10-14T16:46:52  <morcos> cfields: hmm..  i see
209 2015-10-14T16:46:55  <cfields> so (as i read it) it can't actually go backwards, only start from the point where the reindex finished
210 2015-10-14T16:47:18  <morcos> but in the case you point out, there still coudl be valid blocks in say file 51
211 2015-10-14T16:47:31  <morcos> that have height less than the block in file 50
212 2015-10-14T16:47:37  *** Palaver has joined #bitcoin-core-dev
213 2015-10-14T16:48:09  <morcos> you'll still do the right thing, and i agree you can now reclaim all the space between 50-100 that doesn't contain valid blocks
214 2015-10-14T16:48:43  <morcos> so if we changed that line to max, wouldn't you still get the fast majority of that benefity
215 2015-10-14T16:49:03  <morcos> vast
216 2015-10-14T16:50:03  *** harding has quit IRC
217 2015-10-14T16:50:12  *** jcorgan has quit IRC
218 2015-10-14T16:50:13  *** Crypton has quit IRC
219 2015-10-14T16:50:15  *** jl2012 has quit IRC
220 2015-10-14T16:50:17  *** maaku has quit IRC
221 2015-10-14T16:50:17  *** fkhan has quit IRC
222 2015-10-14T16:50:20  *** goregrind has quit IRC
223 2015-10-14T16:50:21  *** Guest4879 has quit IRC
224 2015-10-14T16:51:16  *** Palaver has quit IRC
225 2015-10-14T16:52:28  <cfields> morcos: in the case where there's a valid block in 51, i believe the intention is to move it to 50 (since presumably the end of 50 is corrupt so it's been marked for writing), then set nLastBlockFile to 50. At that point, the block in 51 is a dupe and can be overwritten
226 2015-10-14T16:52:53  <morcos> move?
227 2015-10-14T16:53:25  <morcos> what happens now is it stays in 51, and nLastBlockFile stays at 50
228 2015-10-14T16:53:39  <morcos> even if we shutdown and restart (without reindex) thats the case
229 2015-10-14T16:54:00  <morcos> luckily this extra searchign for vinfoBlockFiles in the database finds the information for 51, so you know about it
230 2015-10-14T16:54:08  <cfields> mm nm, that's not right
231 2015-10-14T16:55:28  <wumpus> michagogo: no problem - blame the (unavoidable) hurry around this release
232 2015-10-14T16:58:24  <cfields> morcos: i thought i remembered the index pos being updated, but that's not the case. looks like you're right..
233 2015-10-14T16:59:05  <cfields> morcos: so yes, after a reindex, it'll point to the file with the last valid block, even if there are completely invalid files inbetween
234 2015-10-14T16:59:44  *** jl2012 has joined #bitcoin-core-dev
235 2015-10-14T16:59:44  *** maaku has joined #bitcoin-core-dev
236 2015-10-14T16:59:44  *** fkhan has joined #bitcoin-core-dev
237 2015-10-14T16:59:44  *** goregrind has joined #bitcoin-core-dev
238 2015-10-14T16:59:44  *** Guest4879 has joined #bitcoin-core-dev
239 2015-10-14T17:00:18  <cfields> morcos: for the sake of clarity, i think it'd suffice to stick the "nLastBlockFile = nFile" in the if(fKnown) case?
240 2015-10-14T17:01:06  <morcos> did you mean !fKnown
241 2015-10-14T17:01:26  <morcos> that was my first inclination, but then it never gets updated if you do a reindex, hence my suggestion for max
242 2015-10-14T17:02:12  <morcos> instead of it pointing at "the file with the last processed valid block", i think it should point at "the last file with processed valid block"
243 2015-10-14T17:03:16  <cfields> no, if(fKnown). that's the reindex case.
244 2015-10-14T17:03:20  <morcos> but reality i don't care so much about changing it as making all the logic clearer, which is confusing in my opinion, not sure how to clarify
245 2015-10-14T17:04:19  <cfields> ugh, wait
246 2015-10-14T17:04:25  <morcos> but in the !fKnown case it defintiely needs to happen, because nFile might get incremented if we move to a new file
247 2015-10-14T17:05:09  <cfields> of course, brainfart
248 2015-10-14T17:07:15  *** jl2012 has quit IRC
249 2015-10-14T17:07:15  *** maaku has quit IRC
250 2015-10-14T17:07:16  *** fkhan has quit IRC
251 2015-10-14T17:07:17  *** goregrind has quit IRC
252 2015-10-14T17:07:17  *** Guest4879 has quit IRC
253 2015-10-14T17:07:40  *** harding has joined #bitcoin-core-dev
254 2015-10-14T17:08:34  <cfields> morcos: ok. yes, i agree with max()
255 2015-10-14T17:09:14  <morcos> ok, i'll put it out there in a pull, i think its easier to reason about that way.   if people don't like it then i'll just try to comment the existing logic
256 2015-10-14T17:09:58  <morcos> btw, when you fixed the calculation of the size in vinfoBlockFiles, we had thought that was from garabage data, but it turns out that another way that can happen is if you have unconnected blocks
257 2015-10-14T17:10:15  *** jl2012 has joined #bitcoin-core-dev
258 2015-10-14T17:10:15  *** maaku has joined #bitcoin-core-dev
259 2015-10-14T17:10:15  *** fkhan has joined #bitcoin-core-dev
260 2015-10-14T17:10:15  *** goregrind has joined #bitcoin-core-dev
261 2015-10-14T17:10:15  *** Guest4879 has joined #bitcoin-core-dev
262 2015-10-14T17:10:56  <morcos> if you ever get a 2 block reorg announced to you that you don't accept, you'll have headers for both blocks in the fork and the block for only the tip.  if you then reindex, that block will not be processed, b/c it has an unknown parent, so its the same thing as having garbage data in your block file
263 2015-10-14T17:11:27  <cfields> morcos: the part i'm not sure about is whether blocks are always processed 100% in order when reindexing. obviously it tries, but when it stores out-of-order children, i'm not sure that it plays them back in order
264 2015-10-14T17:11:29  <morcos> it doesn't update the state of the vinfoBlockfiles but its taking up room.
265 2015-10-14T17:11:43  <cfields> if the order is completely correct, then i think the current code should work ok without max()?
266 2015-10-14T17:12:17  <morcos> the current code does work, its just confusing
267 2015-10-14T17:12:25  <cfields> morcos: aha, that makes sense
268 2015-10-14T17:13:22  <morcos> i don't like the idea that nLastBlockFile can be smaller than your vinfoBlockFile.size()
269 2015-10-14T17:13:40  <morcos> seems fragile or something
270 2015-10-14T17:14:12  <cfields> morcos: maybe just delete the garbage files after reindex then?
271 2015-10-14T17:14:34  <morcos> but what i'm saying is they are not necessarily garbage
272 2015-10-14T17:15:12  <morcos> blockfile 51 has vaild blocks part of chainactive in it.  but chainactive.tip is in block file 50.  then nLastBlockFile = 50
273 2015-10-14T17:15:19  <morcos> after a reindex
274 2015-10-14T17:15:23  *** jl2012_ has joined #bitcoin-core-dev
275 2015-10-14T17:16:00  <morcos> i would prefer nLastBlockFile to = 51 in that case
276 2015-10-14T17:16:30  *** jl2012 has quit IRC
277 2015-10-14T17:19:39  <morcos> cfields: lets not waste any more time on it i'd say.   i don't feel strongly about making the change, i just want to comment this so future me and yous don't have to spend so long trying to figure out what the idea is
278 2015-10-14T17:20:26  <cfields> morcos: see above. reindexing attempts to process in-order, so tip should always be in 51. is that not the case?
279 2015-10-14T17:20:46  <cfields> morcos: sure. but now after discussing, i'm left scratching my head about how things look after a reindex
280 2015-10-14T17:21:51  <morcos> cfields: reindex reads the block files in order, but doesn't call ProcessNewBlock until it can conenct them.  It's PNB through AcceptBlock which calls FindBlockPos and updates nLastBlockFile.  so the last block to have ProcessNewBlock called on it will be the the one whose file nLastBlockFile points to
281 2015-10-14T17:22:12  <morcos> since blocks can be stored on disk out of order, that block can be back in block file 50.
282 2015-10-14T17:22:38  <morcos> i hacked up a test to demonstrate this, because i thought there was a bug in that you wouldn't know about the blocks that were in files 51 and higher
283 2015-10-14T17:23:10  *** jl2012_ has quit IRC
284 2015-10-14T17:23:19  <morcos> but turns out in LoadBlockIndexDB, you keep searching for vinfoBlockFiles beyond nLastBlockFile so you do know about them, but nLastBlockFile still points at 50
285 2015-10-14T17:23:32  *** jl2012 has joined #bitcoin-core-dev
286 2015-10-14T17:29:00  <cfields> morcos: but because PNB isn't called until they can be connected, isn't the tip the last to be processed?
287 2015-10-14T17:29:15  <cfields> or maybe the out-of-order ones themselves aren't played back in-order ?
288 2015-10-14T17:30:26  <morcos> yes, the tip is the last to be processed, but this is reindex, and so if the tip is stored in block file 50, then your are passing in that block pos to FindBlockPos and we're in the fKnown case and its using the file where the tips is stored to set nLastBlockFile
289 2015-10-14T17:30:43  <morcos>  nFile = fKnown ? pos.nFile : nLastBlockFile;
290 2015-10-14T17:31:36  <cfields> ok, i see
291 2015-10-14T17:35:29  <cfields> yep, ok. completely with you now. sorry for making you beat it into me. i agree with all of your conclusions :)
292 2015-10-14T17:38:17  <morcos> cfields: i should apologize, i knew what a rats nest it was before i brought it up.  so you think max is cleaner then?
293 2015-10-14T17:39:02  *** randy-waterhouse has quit IRC
294 2015-10-14T17:39:30  <cfields> morcos: heh well i've been through it all before, i think i was a little overconfident in assuming i could catch back up quickly
295 2015-10-14T17:39:33  <cfields> morcos: yes
296 2015-10-14T17:41:29  <morcos> thx
297 2015-10-14T17:52:25  *** challisto has joined #bitcoin-core-dev
298 2015-10-14T17:58:43  *** Micha|iPhone has joined #bitcoin-core-dev
299 2015-10-14T17:59:03  <Micha|iPhone> Hm, for some reason IRCCloud seems to not want to work
300 2015-10-14T17:59:30  <Micha|iPhone> Maybe there was some big ddos or netsplit or something
301 2015-10-14T18:00:22  <Micha|iPhone> Anyway, I should be home in about 15-20 mins, and I'll be able to kick off the 0.11.1 build+sign.
302 2015-10-14T18:00:38  <Micha|iPhone> That should give you 3, I think?
303 2015-10-14T18:01:02  <Micha|iPhone> 0.10.3 might have to wait until tomorrow
304 2015-10-14T18:05:08  *** Micha|iPhone has quit IRC
305 2015-10-14T18:19:03  <wumpus> yes, definitly do 0.11.1 first, we're waiting on signatures there
306 2015-10-14T18:19:22  <michagogo> Booting VM now.
307 2015-10-14T18:20:01  *** molly has joined #bitcoin-core-dev
308 2015-10-14T18:22:59  *** moli has quit IRC
309 2015-10-14T18:41:26  <michagogo> Okay, build running. BTW: does using relative paths work in a string of commands chained with &&I that includes cds?
310 2015-10-14T18:41:39  <michagogo> &&s*
311 2015-10-14T18:42:11  <michagogo> Erm
312 2015-10-14T18:42:29  <michagogo> fatal: Couldn't find remote ref v0.11.1
313 2015-10-14T18:42:36  <michagogo> On the sig fetching
314 2015-10-14T18:42:40  <michagogo> cfields: ^
315 2015-10-14T18:43:04  <cfields> michagogo: sig isn't pushed yet, need one more unsigned signer
316 2015-10-14T18:43:11  <michagogo> Eh?
317 2015-10-14T18:43:29  <michagogo> Luke committed his
318 2015-10-14T18:43:51  <cfields> ah, i missed that
319 2015-10-14T18:43:53  <cfields> verifying now
320 2015-10-14T18:44:17  <michagogo> Good thing I made my script (IIRC) recheck after the build for signature availability
321 2015-10-14T18:46:04  <michagogo> I.e. It checks at the start and alerts if it can't fetch it, but then checks again when it's time to sign
322 2015-10-14T18:46:21  <GitHub93> [bitcoin] domob1812 opened pull request #6829: doc: add comment explaining initial header request (master...doc-getheaders) https://github.com/bitcoin/bitcoin/pull/6829
323 2015-10-14T18:48:37  <cfields> michagogo: pushed.
324 2015-10-14T18:50:05  <michagogo> Great. My script should (I think) automatically pick up on that, and pr the sigs including the signed.
325 2015-10-14T18:50:34  <michagogo> And if I didn't mess up the && chain of commands, should even do 0.10.3 too
326 2015-10-14T18:51:19  <michagogo> (Should almost definitely get the win, Linux, and OS X unsigned -- the question is the signing)
327 2015-10-14T18:53:55  <michagogo> It would be nice to have this channel subscribed to the gitian.sigs repo the same way it is to bitcoin
328 2015-10-14T18:54:22  <michagogo> (Also, idk if I've ever seen a -n channel before)
329 2015-10-14T19:14:13  *** paveljanik has joined #bitcoin-core-dev
330 2015-10-14T19:14:31  *** moli has joined #bitcoin-core-dev
331 2015-10-14T19:17:39  *** molly has quit IRC
332 2015-10-14T19:33:02  *** Palaver_ has joined #bitcoin-core-dev
333 2015-10-14T19:35:52  *** Palaver_ has quit IRC
334 2015-10-14T19:41:32  *** molly has joined #bitcoin-core-dev
335 2015-10-14T19:44:39  *** moli has quit IRC
336 2015-10-14T20:13:21  <GitHub90> [bitcoin] Michagogo opened pull request #6830: Add historical release notes for October 2015 bugfix releases (master...add-release-notes) https://github.com/bitcoin/bitcoin/pull/6830
337 2015-10-14T20:26:00  *** belcher has joined #bitcoin-core-dev
338 2015-10-14T20:30:28  *** treehug88 has quit IRC
339 2015-10-14T20:32:22  <michagogo> wumpus: sigs PR'd
340 2015-10-14T20:52:36  <GitHub66> [bitcoin] Michagogo opened pull request #6831: Bring historical release notes up to date (0.10...0.10-add-release-notes) https://github.com/bitcoin/bitcoin/pull/6831
341 2015-10-14T20:52:52  <GitHub36> [bitcoin] Michagogo opened pull request #6832: Bring historical release notes up to date (0.11...0.11-add-release-notes) https://github.com/bitcoin/bitcoin/pull/6832
342 2015-10-14T20:56:14  * michagogo preps the Reddit post
343 2015-10-14T20:56:27  * michagogo checks if there's a release PR for bitcoin.org
344 2015-10-14T20:56:54  <michagogo> Ah, indeed there is: https://github.com/bitcoin-dot-org/bitcoin.org/pull/1085
345 2015-10-14T20:58:27  <michagogo> cfields: yeah, looks like the sigs did indeed get pulled
346 2015-10-14T20:58:29  <michagogo> Thanks!
347 2015-10-14T20:58:32  <michagogo> !m cfields
348 2015-10-14T20:58:32  <[b__b]> You're doing good work, cfields!
349 2015-10-14T20:58:32  <gribble> Error: "m" is not a valid command.
350 2015-10-14T20:58:40  <michagogo> ...that's actually on, lol
351 2015-10-14T20:58:43  <michagogo> [b__b]: help
352 2015-10-14T20:58:43  <[b__b]> Available plugins: bangmotivate, help, last_seen, ping, logger (https://botbot.me/freenode/bitcoin-core-dev/help/)
353 2015-10-14T21:00:41  <cfields> michagogo: great, matched. thanks
354 2015-10-14T21:04:18  * michagogo wonders if wumpus is still here to push the button
355 2015-10-14T21:15:27  *** paveljanik has quit IRC
356 2015-10-14T21:17:04  *** PRab has quit IRC
357 2015-10-14T21:18:56  *** d_t has quit IRC
358 2015-10-14T21:23:23  *** d_t has joined #bitcoin-core-dev
359 2015-10-14T21:35:25  <Luke-Jr> detached sigs for 0.10.3?
360 2015-10-14T21:35:27  *** belcher has quit IRC
361 2015-10-14T21:37:15  *** belcher has joined #bitcoin-core-dev
362 2015-10-14T21:37:26  <cfields> Luke-Jr: https://bitcoincore.org/cfields/bitcoin-0.10.3/signature.tar.gz
363 2015-10-14T21:37:56  <Luke-Jr> cfields: what happened with the git repo?
364 2015-10-14T21:38:38  <cfields> Luke-Jr: that wasn't in for 0.10, only 0.11+
365 2015-10-14T21:39:10  <cfields> historical ones are there, but they're not gzipped and ready for gitian
366 2015-10-14T21:39:17  <Luke-Jr> can still download it from there :P
367 2015-10-14T21:39:19  <Luke-Jr> i c
368 2015-10-14T21:39:29  <cfields> (though i do need to push them there for 0.10, thanks for reminding me)
369 2015-10-14T21:47:58  *** belcher has quit IRC
370 2015-10-14T21:50:16  *** belcher has joined #bitcoin-core-dev
371 2015-10-14T21:59:44  <Luke-Jr> ok, 0.10.3 has three sets of sigs if someone wants to publish
372 2015-10-14T22:00:14  <Luke-Jr> should have 0.11.1 soon, but I accidentally the windows binaries
373 2015-10-14T22:00:41  * Luke-Jr tempted to hack gitian to use build/out-pkgname/ :P
374 2015-10-14T22:14:42  *** PRab has joined #bitcoin-core-dev
375 2015-10-14T22:22:51  <wumpus> uploaded the executables to https://bitcoin.org/bin/bitcoin-core-0.11.1/ and https://bitcoin.org/bin/bitcoin-core-0.10.3/, going to bed now, will do the announcements tomorrow
376 2015-10-14T22:26:06  <Luke-Jr> ok, 0.11.1 has 3 sigs now too
377 2015-10-14T22:26:21  <Luke-Jr> wumpus: thanks
378 2015-10-14T22:57:57  *** d_t has quit IRC
379 2015-10-14T22:59:06  *** d_t has joined #bitcoin-core-dev
380 2015-10-14T23:15:11  *** lecusemb1e has quit IRC
381 2015-10-14T23:17:49  *** lecusemble has joined #bitcoin-core-dev
382 2015-10-14T23:42:57  *** alpalp has joined #bitcoin-core-dev
383 2015-10-14T23:47:19  *** lecusemble has quit IRC
384 2015-10-14T23:49:41  *** jgarzik has joined #bitcoin-core-dev
385 2015-10-14T23:49:41  *** jgarzik has joined #bitcoin-core-dev
386 2015-10-14T23:49:48  *** jgarzik has quit IRC
387 2015-10-14T23:59:18  *** AtashiCon has quit IRC
388 2015-10-14T23:59:22  *** Arnavion3 has joined #bitcoin-core-dev
389 2015-10-14T23:59:26  *** Arnavion3 is now known as AtashiCon