12015-10-14T00:03:17  *** tripleslash has quit IRC
  22015-10-14T00:10:36  *** maaku has quit IRC
  32015-10-14T00:26:25  *** maaku_ has joined #bitcoin-core-dev
  42015-10-14T00:27:15  *** maaku_ is now known as maaku
  52015-10-14T00:31:57  *** molly has joined #bitcoin-core-dev
  62015-10-14T00:34:59  *** moli has quit IRC
  72015-10-14T00:44:14  *** Ylbam has quit IRC
  82015-10-14T01:01:47  *** d_t has quit IRC
  92015-10-14T01:09:13  *** moli has joined #bitcoin-core-dev
 102015-10-14T01:11:59  *** molly has quit IRC
 112015-10-14T01:15:13  *** molly has joined #bitcoin-core-dev
 122015-10-14T01:18:19  *** moli has quit IRC
 132015-10-14T01:40:30  *** belcher has quit IRC
 142015-10-14T01:41:48  *** d_t has joined #bitcoin-core-dev
 152015-10-14T02:12:31  *** maaku has quit IRC
 162015-10-14T02:16:11  *** maaku has joined #bitcoin-core-dev
 172015-10-14T02:16:35  *** maaku is now known as Guest88900
 182015-10-14T02:29:41  <gmaxwell> looks like github may be compromised or badly broken: https://github.com/bitcoin/bitcoin/commits/master?author=saracen
 192015-10-14T02:34:43  <midnightmagic> i thought that was an artifact of the conversion process
 202015-10-14T02:37:19  <phantomcircuit> gmaxwell, it's always been like that
 212015-10-14T02:37:25  <phantomcircuit> (i had the same thought to once)
 222015-10-14T02:38:41  <midnightmagic> it's consistent with my (extensive) experience with scm->scm conversion tools that were badly-written
 232015-10-14T02:39:08  <gmaxwell> hard to see how thats possible, since that account is much newer than the commits in question.
 242015-10-14T02:39:44  <phantomcircuit> gmaxwell, timestamps on commits are not verified by github
 252015-10-14T02:39:50  <CodeShark> the commits don't have to have the right time
 262015-10-14T02:39:59  <CodeShark> you can set your clock back a decade and commit
 272015-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. :)
 282015-10-14T02:40:40  <midnightmagic> argh does github order by date or by git log order..?
 292015-10-14T02:40:51  <CodeShark> by date - it sucks
 302015-10-14T02:43:05  <midnightmagic> whoah!!
 312015-10-14T02:43:53  <gmaxwell> yea, okay. I reproduced the stupidity.
 322015-10-14T02:45:56  <gmaxwell> https://github.com/bitcoin/bitcoin/commits/master?author=gmaxwell&page=6  < see bottom
 332015-10-14T02:46:03  <gmaxwell> first commit in bitcoin core repo is now from me.
 342015-10-14T03:13:15  *** moli has joined #bitcoin-core-dev
 352015-10-14T03:13:46  <Luke-Jr> [02:37:19] <phantomcircuit> gmaxwell, it's always been like that <-- +1
 362015-10-14T03:14:25  <gmaxwell> Thats not actually true.
 372015-10-14T03:14:45  <gmaxwell> Unless you think it was also always like this: https://github.com/bitcoin/bitcoin/commits/master?page=264
 382015-10-14T03:14:47  <Luke-Jr> I don't remember a time where the contributors page didn't bug that way
 392015-10-14T03:15:05  <Luke-Jr> gmaxwell: it was, but with a different user
 402015-10-14T03:15:46  <Luke-Jr> (disclaimer: I did not view that exact page before)
 412015-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.
 422015-10-14T03:16:19  *** molly has quit IRC
 432015-10-14T03:16:37  <Luke-Jr> do we have any recent like that?
 442015-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.
 452015-10-14T03:17:00  <gmaxwell> Thus my latest example, I just went and reproduced using sirius-m@1a98c847-1fd6-4fd8-948a-caf3550aa51b
 462015-10-14T03:17:09  <Luke-Jr> gmaxwell: sure, but that was a long time ago
 472015-10-14T03:17:13  <gmaxwell> oops I ment s_nakamoto@1a98c847-1fd6-4fd8-948a-caf3550aa51b in the penultimate case.
 482015-10-14T03:18:08  <Luke-Jr> I noticed it at least as early as when we were contacting devs to sign that joint letter
 492015-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.
 502015-10-14T03:18:18  <Luke-Jr> pretty sure I had seen it before then, though
 512015-10-14T03:18:33  <Luke-Jr> gmaxwell: ☹ now GitHub shows bogus stats for you
 522015-10-14T03:18:39  <Luke-Jr> at least ignoring saracen was easy
 532015-10-14T03:18:51  <gmaxwell> Luke-Jr: nah, it shows up as seperate users.
 542015-10-14T03:18:55  <Luke-Jr> O.o
 552015-10-14T03:19:30  <Luke-Jr> not on https://github.com/bitcoin/bitcoin/graphs/contributors AFAIK
 562015-10-14T03:28:26  *** CodeShark has quit IRC
 572015-10-14T03:51:12  *** Guest88900 has quit IRC
 582015-10-14T03:56:34  *** maaku has joined #bitcoin-core-dev
 592015-10-14T03:56:58  *** maaku is now known as Guest71817
 602015-10-14T03:57:20  *** Guest71817 is now known as maaku
 612015-10-14T03:57:50  *** ParadoxSpiral has joined #bitcoin-core-dev
 622015-10-14T03:58:23  *** Thireus has quit IRC
 632015-10-14T03:59:24  *** alpalp has quit IRC
 642015-10-14T05:02:12  *** phantomcircuit has quit IRC
 652015-10-14T05:03:27  *** phantomcircuit has joined #bitcoin-core-dev
 662015-10-14T05:03:48  *** phantomcircuit is now known as Guest96009
 672015-10-14T05:13:50  *** Guest96009 has quit IRC
 682015-10-14T05:14:03  *** phantomcircuit_ has joined #bitcoin-core-dev
 692015-10-14T05:20:26  *** Naphex has quit IRC
 702015-10-14T05:27:54  *** Naphex has joined #bitcoin-core-dev
 712015-10-14T05:29:06  *** phantomcircuit_ is now known as phantomcircuit
 722015-10-14T05:44:05  *** Thireus has joined #bitcoin-core-dev
 732015-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
 742015-10-14T06:00:07  <gmaxwell> None that I'm aware of.
 752015-10-14T06:11:36  *** tripleslash has joined #bitcoin-core-dev
 762015-10-14T06:30:03  *** Thireus has quit IRC
 772015-10-14T06:36:27  *** Ylbam has joined #bitcoin-core-dev
 782015-10-14T06:57:55  *** malte has quit IRC
 792015-10-14T07:03:52  *** Thireus has joined #bitcoin-core-dev
 802015-10-14T07:04:15  *** trippysalmon has joined #bitcoin-core-dev
 812015-10-14T07:14:45  *** paveljanik has quit IRC
 822015-10-14T07:15:10  *** malte has joined #bitcoin-core-dev
 832015-10-14T07:38:06  <Luke-Jr> wumpus: FWIW, going through master looking for bugfixes we failed to backport; will ping when done
 842015-10-14T07:39:29  <wumpus> it's too late for backporting anything now
 852015-10-14T07:39:36  *** ParadoxSpiral_ has joined #bitcoin-core-dev
 862015-10-14T07:39:44  <wumpus> we need a release out due to the upnp issue
 872015-10-14T07:40:05  <wumpus> after that we can continue backporting of course for the next minor release...
 882015-10-14T07:40:27  <Luke-Jr> that's fine, I don't expect to find anything important
 892015-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
 902015-10-14T07:42:20  *** ParadoxSpiral has quit IRC
 912015-10-14T07:48:07  <wumpus> adding it tothe list
 922015-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)
 932015-10-14T07:52:19  *** moli has quit IRC
 942015-10-14T07:56:33  <Luke-Jr> "the list"?
 952015-10-14T08:00:20  <wumpus> the list of things to backport (currently containing two items)
 962015-10-14T08:01:56  *** alpalp has joined #bitcoin-core-dev
 972015-10-14T08:04:10  * Luke-Jr ponders why midnightmagic just built v0.11.0rc1 O.o
 982015-10-14T08:04:10  <wumpus>  * [new tag]         v0.10.3 -> v0.10.3
 992015-10-14T08:04:50  <wumpus>  * [new tag]         v0.11.1 -> v0.11.1
1002015-10-14T08:06:51  *** randy-waterhouse has joined #bitcoin-core-dev
1012015-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
1022015-10-14T08:11:09  <midnightmagic> Luke-Jr: just trying to be complete. Is that a duplicate?
1032015-10-14T08:11:20  <Luke-Jr> midnightmagic: no, just stale :p
1042015-10-14T08:11:56  <midnightmagic> :-)
1052015-10-14T08:14:16  <midnightmagic> lot of tags I've been remiss on..
1062015-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
1072015-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
1082015-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
1092015-10-14T08:25:14  <wumpus> but first priority is getting 0.11.1 (and possibly 0.10.3) to people
1102015-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
1112015-10-14T08:41:19  *** d_t has quit IRC
1122015-10-14T08:53:40  *** alpalp has quit IRC
1132015-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.
1142015-10-14T09:06:50  <wumpus> midnightmagic: right, makes sense
1152015-10-14T09:13:07  *** jl2012_ has joined #bitcoin-core-dev
1162015-10-14T09:13:12  *** jl2012 has quit IRC
1172015-10-14T09:26:17  *** CodeShark has joined #bitcoin-core-dev
1182015-10-14T09:27:13  *** CodeShark has quit IRC
1192015-10-14T09:27:22  *** CodeShark has joined #bitcoin-core-dev
1202015-10-14T09:35:48  *** randy-waterhouse has quit IRC
1212015-10-14T09:39:04  *** randy-waterhouse has joined #bitcoin-core-dev
1222015-10-14T10:34:14  *** Guest58630 is now known as GAit
1232015-10-14T11:10:59  *** go1111111 has quit IRC
1242015-10-14T11:12:17  *** go1111111 has joined #bitcoin-core-dev
1252015-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
1262015-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
1272015-10-14T12:59:32  *** molly has joined #bitcoin-core-dev
1282015-10-14T13:24:45  *** stonecoldpat1 has left #bitcoin-core-dev
1292015-10-14T14:01:14  *** Thireus has quit IRC
1302015-10-14T14:25:30  *** Thireus has joined #bitcoin-core-dev
1312015-10-14T14:44:44  <cfields> gitian builders: 0.10.3 osx detached signature: https://bitcoincore.org/cfields/bitcoin-0.10.3/signature.tar.gz
1322015-10-14T14:50:45  <wumpus> github should be automatically reporting that, weird
1332015-10-14T14:51:46  <wumpus> (at least, pushes to master on the detached sigs repository should be reported)
1342015-10-14T14:53:11  <cfields> wumpus: 0.10.3 didn't use the repo, still have to manually fetch it
1352015-10-14T14:54:11  <wumpus> oh? I am, somehow, using the automatic fetching with 0.10.3
1362015-10-14T14:55:34  * wumpus must be doing something wrong, let me check
1372015-10-14T14:56:31  * cfields checks the releases rc2 dmg
1382015-10-14T14:57:01  <wumpus> ... ugh
1392015-10-14T15:01:35  <cfields> wumpus: yikes. mismatch on rc2 :\
1402015-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
1412015-10-14T15:03:38  <cfields> yea
1422015-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
1432015-10-14T15:04:29  <wumpus> yes
1442015-10-14T15:04:42  *** treehug88 has joined #bitcoin-core-dev
1452015-10-14T15:04:58  <wumpus> attaching the wrong signature should ideally fail :)
1462015-10-14T15:05:47  <cfields> yea
1472015-10-14T15:06:02  <cfields> for windows it does, that actually saved me on rc2
1482015-10-14T15:06:37  <cfields> i'll make it simulate that for osx via checksums. adding now.
1492015-10-14T15:07:38  *** d_t has joined #bitcoin-core-dev
1502015-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.
1512015-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
1522015-10-14T15:23:32  <wumpus> kanzure: see commit ddf98d1
1532015-10-14T15:31:21  <kanzure> why would getinfo timeout so quickly?
1542015-10-14T15:31:22  *** moli has joined #bitcoin-core-dev
1552015-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
1562015-10-14T15:33:13  <wumpus> but this only applies to master, which has http timeouts
1572015-10-14T15:34:19  *** molly has quit IRC
1582015-10-14T15:37:10  <wumpus> there may well be a different issue, but it may help troubleshooting
1592015-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?
1602015-10-14T15:41:49  <wumpus> yes - at least "-rpcservertimeout" seconds, and you must be using master
1612015-10-14T15:42:02  <kanzure> hmm maybe i'll go try -rpcservertimeout=0
1622015-10-14T15:42:11  <kanzure> yes this is on master (ish) (a week old maybe)
1632015-10-14T15:43:50  <morcos> cfields: any chance you want to think about nLastBlockFile for a sec?
1642015-10-14T15:44:14  <cfields> morcos: sure. give me 5 min to wrap something up?
1652015-10-14T15:44:18  <morcos> sure
1662015-10-14T15:53:26  *** Thireus has quit IRC
1672015-10-14T16:00:20  *** CodeShark has quit IRC
1682015-10-14T16:02:36  *** d_t has quit IRC
1692015-10-14T16:04:34  *** d_t has joined #bitcoin-core-dev
1702015-10-14T16:12:50  <cfields> morcos: what's up?
1712015-10-14T16:13:22  <cfields> wow, that took 30. felt like 5. sorry bout that :\
1722015-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
1732015-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
1742015-10-14T16:14:44  <morcos> so that needs to be fixed
1752015-10-14T16:15:05  <morcos> but in the course of trying to trace through all this stuff, nLastBlockFile is kind of confusing
1762015-10-14T16:15:13  <morcos> what is is really supposed to represent
1772015-10-14T16:15:20  <morcos> where you're going to write the next block to?
1782015-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?
1792015-10-14T16:16:16  <morcos> wouldn't it make sense if it was really your last block file?
1802015-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
1812015-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)
1822015-10-14T16:20:14  <morcos> i just dont understand why it ever needs to go backwards
1832015-10-14T16:21:58  *** jl2012 has joined #bitcoin-core-dev
1842015-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.
1852015-10-14T16:22:36  *** jl2012_ has quit IRC
1862015-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
1872015-10-14T16:24:38  <cfields> hmm yes, without max() that looks very strange
1882015-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
1892015-10-14T16:25:18  <cfields> still reading and re-remembering
1902015-10-14T16:25:19  <morcos> but its just kind of confusing
1912015-10-14T16:25:27  <cfields> right
1922015-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
1932015-10-14T16:28:38  *** Thireus has joined #bitcoin-core-dev
1942015-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
1952015-10-14T16:34:18  <cfields> still looking
1962015-10-14T16:37:04  *** AtashiCon has quit IRC
1972015-10-14T16:37:08  *** Arnavion3 has joined #bitcoin-core-dev
1982015-10-14T16:37:12  *** Arnavion3 is now known as AtashiCon
1992015-10-14T16:37:32  <michagogo> wumpus: I'd have caught the rc2 dmg thing if I were at my computer
2002015-10-14T16:37:47  <michagogo> But that unfortunately hasn't happened much at all lately
2012015-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 :-/
2022015-10-14T16:38:43  <michagogo> Doesn't leave me much leisure time.
2032015-10-14T16:44:02  <cfields> morcos: ok, i believe i remember the logic now
2042015-10-14T16:44:06  *** jcorgan_ has joined #bitcoin-core-dev
2052015-10-14T16:44:06  *** jcorgan_ has joined #bitcoin-core-dev
2062015-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
2072015-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.
2082015-10-14T16:46:52  <morcos> cfields: hmm..  i see
2092015-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
2102015-10-14T16:47:18  <morcos> but in the case you point out, there still coudl be valid blocks in say file 51
2112015-10-14T16:47:31  <morcos> that have height less than the block in file 50
2122015-10-14T16:47:37  *** Palaver has joined #bitcoin-core-dev
2132015-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
2142015-10-14T16:48:43  <morcos> so if we changed that line to max, wouldn't you still get the fast majority of that benefity
2152015-10-14T16:49:03  <morcos> vast
2162015-10-14T16:50:03  *** harding has quit IRC
2172015-10-14T16:50:12  *** jcorgan has quit IRC
2182015-10-14T16:50:13  *** Crypton has quit IRC
2192015-10-14T16:50:15  *** jl2012 has quit IRC
2202015-10-14T16:50:17  *** maaku has quit IRC
2212015-10-14T16:50:17  *** fkhan has quit IRC
2222015-10-14T16:50:20  *** goregrind has quit IRC
2232015-10-14T16:50:21  *** Guest4879 has quit IRC
2242015-10-14T16:51:16  *** Palaver has quit IRC
2252015-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
2262015-10-14T16:52:53  <morcos> move?
2272015-10-14T16:53:25  <morcos> what happens now is it stays in 51, and nLastBlockFile stays at 50
2282015-10-14T16:53:39  <morcos> even if we shutdown and restart (without reindex) thats the case
2292015-10-14T16:54:00  <morcos> luckily this extra searchign for vinfoBlockFiles in the database finds the information for 51, so you know about it
2302015-10-14T16:54:08  <cfields> mm nm, that's not right
2312015-10-14T16:55:28  <wumpus> michagogo: no problem - blame the (unavoidable) hurry around this release
2322015-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..
2332015-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
2342015-10-14T16:59:44  *** jl2012 has joined #bitcoin-core-dev
2352015-10-14T16:59:44  *** maaku has joined #bitcoin-core-dev
2362015-10-14T16:59:44  *** fkhan has joined #bitcoin-core-dev
2372015-10-14T16:59:44  *** goregrind has joined #bitcoin-core-dev
2382015-10-14T16:59:44  *** Guest4879 has joined #bitcoin-core-dev
2392015-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?
2402015-10-14T17:01:06  <morcos> did you mean !fKnown
2412015-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
2422015-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"
2432015-10-14T17:03:16  <cfields> no, if(fKnown). that's the reindex case.
2442015-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
2452015-10-14T17:04:19  <cfields> ugh, wait
2462015-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
2472015-10-14T17:05:09  <cfields> of course, brainfart
2482015-10-14T17:07:15  *** jl2012 has quit IRC
2492015-10-14T17:07:15  *** maaku has quit IRC
2502015-10-14T17:07:16  *** fkhan has quit IRC
2512015-10-14T17:07:17  *** goregrind has quit IRC
2522015-10-14T17:07:17  *** Guest4879 has quit IRC
2532015-10-14T17:07:40  *** harding has joined #bitcoin-core-dev
2542015-10-14T17:08:34  <cfields> morcos: ok. yes, i agree with max()
2552015-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
2562015-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
2572015-10-14T17:10:15  *** jl2012 has joined #bitcoin-core-dev
2582015-10-14T17:10:15  *** maaku has joined #bitcoin-core-dev
2592015-10-14T17:10:15  *** fkhan has joined #bitcoin-core-dev
2602015-10-14T17:10:15  *** goregrind has joined #bitcoin-core-dev
2612015-10-14T17:10:15  *** Guest4879 has joined #bitcoin-core-dev
2622015-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
2632015-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
2642015-10-14T17:11:29  <morcos> it doesn't update the state of the vinfoBlockfiles but its taking up room.
2652015-10-14T17:11:43  <cfields> if the order is completely correct, then i think the current code should work ok without max()?
2662015-10-14T17:12:17  <morcos> the current code does work, its just confusing
2672015-10-14T17:12:25  <cfields> morcos: aha, that makes sense
2682015-10-14T17:13:22  <morcos> i don't like the idea that nLastBlockFile can be smaller than your vinfoBlockFile.size()
2692015-10-14T17:13:40  <morcos> seems fragile or something
2702015-10-14T17:14:12  <cfields> morcos: maybe just delete the garbage files after reindex then?
2712015-10-14T17:14:34  <morcos> but what i'm saying is they are not necessarily garbage
2722015-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
2732015-10-14T17:15:19  <morcos> after a reindex
2742015-10-14T17:15:23  *** jl2012_ has joined #bitcoin-core-dev
2752015-10-14T17:16:00  <morcos> i would prefer nLastBlockFile to = 51 in that case
2762015-10-14T17:16:30  *** jl2012 has quit IRC
2772015-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
2782015-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?
2792015-10-14T17:20:46  <cfields> morcos: sure. but now after discussing, i'm left scratching my head about how things look after a reindex
2802015-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
2812015-10-14T17:22:12  <morcos> since blocks can be stored on disk out of order, that block can be back in block file 50.
2822015-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
2832015-10-14T17:23:10  *** jl2012_ has quit IRC
2842015-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
2852015-10-14T17:23:32  *** jl2012 has joined #bitcoin-core-dev
2862015-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?
2872015-10-14T17:29:15  <cfields> or maybe the out-of-order ones themselves aren't played back in-order ?
2882015-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
2892015-10-14T17:30:43  <morcos>  nFile = fKnown ? pos.nFile : nLastBlockFile;
2902015-10-14T17:31:36  <cfields> ok, i see
2912015-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 :)
2922015-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?
2932015-10-14T17:39:02  *** randy-waterhouse has quit IRC
2942015-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
2952015-10-14T17:39:33  <cfields> morcos: yes
2962015-10-14T17:41:29  <morcos> thx
2972015-10-14T17:52:25  *** challisto has joined #bitcoin-core-dev
2982015-10-14T17:58:43  *** Micha|iPhone has joined #bitcoin-core-dev
2992015-10-14T17:59:03  <Micha|iPhone> Hm, for some reason IRCCloud seems to not want to work
3002015-10-14T17:59:30  <Micha|iPhone> Maybe there was some big ddos or netsplit or something
3012015-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.
3022015-10-14T18:00:38  <Micha|iPhone> That should give you 3, I think?
3032015-10-14T18:01:02  <Micha|iPhone> 0.10.3 might have to wait until tomorrow
3042015-10-14T18:05:08  *** Micha|iPhone has quit IRC
3052015-10-14T18:19:03  <wumpus> yes, definitly do 0.11.1 first, we're waiting on signatures there
3062015-10-14T18:19:22  <michagogo> Booting VM now.
3072015-10-14T18:20:01  *** molly has joined #bitcoin-core-dev
3082015-10-14T18:22:59  *** moli has quit IRC
3092015-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?
3102015-10-14T18:41:39  <michagogo> &&s*
3112015-10-14T18:42:11  <michagogo> Erm
3122015-10-14T18:42:29  <michagogo> fatal: Couldn't find remote ref v0.11.1
3132015-10-14T18:42:36  <michagogo> On the sig fetching
3142015-10-14T18:42:40  <michagogo> cfields: ^
3152015-10-14T18:43:04  <cfields> michagogo: sig isn't pushed yet, need one more unsigned signer
3162015-10-14T18:43:11  <michagogo> Eh?
3172015-10-14T18:43:29  <michagogo> Luke committed his
3182015-10-14T18:43:51  <cfields> ah, i missed that
3192015-10-14T18:43:53  <cfields> verifying now
3202015-10-14T18:44:17  <michagogo> Good thing I made my script (IIRC) recheck after the build for signature availability
3212015-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
3222015-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
3232015-10-14T18:48:37  <cfields> michagogo: pushed.
3242015-10-14T18:50:05  <michagogo> Great. My script should (I think) automatically pick up on that, and pr the sigs including the signed.
3252015-10-14T18:50:34  <michagogo> And if I didn't mess up the && chain of commands, should even do 0.10.3 too
3262015-10-14T18:51:19  <michagogo> (Should almost definitely get the win, Linux, and OS X unsigned -- the question is the signing)
3272015-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
3282015-10-14T18:54:22  <michagogo> (Also, idk if I've ever seen a -n channel before)
3292015-10-14T19:14:13  *** paveljanik has joined #bitcoin-core-dev
3302015-10-14T19:14:31  *** moli has joined #bitcoin-core-dev
3312015-10-14T19:17:39  *** molly has quit IRC
3322015-10-14T19:33:02  *** Palaver_ has joined #bitcoin-core-dev
3332015-10-14T19:35:52  *** Palaver_ has quit IRC
3342015-10-14T19:41:32  *** molly has joined #bitcoin-core-dev
3352015-10-14T19:44:39  *** moli has quit IRC
3362015-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
3372015-10-14T20:26:00  *** belcher has joined #bitcoin-core-dev
3382015-10-14T20:30:28  *** treehug88 has quit IRC
3392015-10-14T20:32:22  <michagogo> wumpus: sigs PR'd
3402015-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
3412015-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
3422015-10-14T20:56:14  * michagogo preps the Reddit post
3432015-10-14T20:56:27  * michagogo checks if there's a release PR for bitcoin.org
3442015-10-14T20:56:54  <michagogo> Ah, indeed there is: https://github.com/bitcoin-dot-org/bitcoin.org/pull/1085
3452015-10-14T20:58:27  <michagogo> cfields: yeah, looks like the sigs did indeed get pulled
3462015-10-14T20:58:29  <michagogo> Thanks!
3472015-10-14T20:58:32  <michagogo> !m cfields
3482015-10-14T20:58:32  <[b__b]> You're doing good work, cfields!
3492015-10-14T20:58:32  <gribble> Error: "m" is not a valid command.
3502015-10-14T20:58:40  <michagogo> ...that's actually on, lol
3512015-10-14T20:58:43  <michagogo> [b__b]: help
3522015-10-14T20:58:43  <[b__b]> Available plugins: bangmotivate, help, last_seen, ping, logger (https://botbot.me/freenode/bitcoin-core-dev/help/)
3532015-10-14T21:00:41  <cfields> michagogo: great, matched. thanks
3542015-10-14T21:04:18  * michagogo wonders if wumpus is still here to push the button
3552015-10-14T21:15:27  *** paveljanik has quit IRC
3562015-10-14T21:17:04  *** PRab has quit IRC
3572015-10-14T21:18:56  *** d_t has quit IRC
3582015-10-14T21:23:23  *** d_t has joined #bitcoin-core-dev
3592015-10-14T21:35:25  <Luke-Jr> detached sigs for 0.10.3?
3602015-10-14T21:35:27  *** belcher has quit IRC
3612015-10-14T21:37:15  *** belcher has joined #bitcoin-core-dev
3622015-10-14T21:37:26  <cfields> Luke-Jr: https://bitcoincore.org/cfields/bitcoin-0.10.3/signature.tar.gz
3632015-10-14T21:37:56  <Luke-Jr> cfields: what happened with the git repo?
3642015-10-14T21:38:38  <cfields> Luke-Jr: that wasn't in for 0.10, only 0.11+
3652015-10-14T21:39:10  <cfields> historical ones are there, but they're not gzipped and ready for gitian
3662015-10-14T21:39:17  <Luke-Jr> can still download it from there :P
3672015-10-14T21:39:19  <Luke-Jr> i c
3682015-10-14T21:39:29  <cfields> (though i do need to push them there for 0.10, thanks for reminding me)
3692015-10-14T21:47:58  *** belcher has quit IRC
3702015-10-14T21:50:16  *** belcher has joined #bitcoin-core-dev
3712015-10-14T21:59:44  <Luke-Jr> ok, 0.10.3 has three sets of sigs if someone wants to publish
3722015-10-14T22:00:14  <Luke-Jr> should have 0.11.1 soon, but I accidentally the windows binaries
3732015-10-14T22:00:41  * Luke-Jr tempted to hack gitian to use build/out-pkgname/ :P
3742015-10-14T22:14:42  *** PRab has joined #bitcoin-core-dev
3752015-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
3762015-10-14T22:26:06  <Luke-Jr> ok, 0.11.1 has 3 sigs now too
3772015-10-14T22:26:21  <Luke-Jr> wumpus: thanks
3782015-10-14T22:57:57  *** d_t has quit IRC
3792015-10-14T22:59:06  *** d_t has joined #bitcoin-core-dev
3802015-10-14T23:15:11  *** lecusemb1e has quit IRC
3812015-10-14T23:17:49  *** lecusemble has joined #bitcoin-core-dev
3822015-10-14T23:42:57  *** alpalp has joined #bitcoin-core-dev
3832015-10-14T23:47:19  *** lecusemble has quit IRC
3842015-10-14T23:49:41  *** jgarzik has joined #bitcoin-core-dev
3852015-10-14T23:49:41  *** jgarzik has joined #bitcoin-core-dev
3862015-10-14T23:49:48  *** jgarzik has quit IRC
3872015-10-14T23:59:18  *** AtashiCon has quit IRC
3882015-10-14T23:59:22  *** Arnavion3 has joined #bitcoin-core-dev
3892015-10-14T23:59:26  *** Arnavion3 is now known as AtashiCon