--- Day changed Wed Oct 14 2015
00:03 -!- Thireus [~Thireus@icy.thireus.fr] has joined #bitcoin-core-dev
00:04 -!- trippysalmon [~Rob@ip4da81ded.direct-adsl.nl] has joined #bitcoin-core-dev
00:14 -!- paveljanik [~paveljani@unaffiliated/paveljanik] has quit [Quit: Leaving]
00:15 -!- malte [~malte@2a00:d0c0:200:0:b9:1a:9c2c:1] has joined #bitcoin-core-dev
00:38 < Luke-Jr> wumpus: FWIW, going through master looking for bugfixes we failed to backport; will ping when done
00:39 < wumpus> it's too late for backporting anything now
00:39 -!- ParadoxSpiral_ [~ParadoxSp@p508B86A4.dip0.t-ipconnect.de] has joined #bitcoin-core-dev
00:39 < wumpus> we need a release out due to the upnp issue
00:40 < wumpus> after that we can continue backporting of course for the next minor release...
00:40 < Luke-Jr> that's fine, I don't expect to find anything important
00:41 < Luke-Jr> most potentially-concerning so far is https://github.com/bitcoin/bitcoin/pull/6688 , but obviously things haven't broken terribly without it
00:42 -!- ParadoxSpiral [~ParadoxSp@p508B8A85.dip0.t-ipconnect.de] has quit [Ping timeout: 244 seconds]
00:48 < wumpus> adding it tothe list
00:50 < wumpus> petertodd noted that https://github.com/bitcoin/bitcoin/pull/6498 should have been backported too (but may be non-trivial)
00:52 -!- moli [~molly@unaffiliated/molly] has quit [Ping timeout: 240 seconds]
00:56 < Luke-Jr> "the list"?
01:00 < wumpus> the list of things to backport (currently containing two items)
01:01 -!- alpalp [6836eb1c@gateway/web/cgi-irc/kiwiirc.com/ip.104.54.235.28] has joined #bitcoin-core-dev
01:04  * Luke-Jr ponders why midnightmagic just built v0.11.0rc1 O.o
01:04 < wumpus>  * [new tag]         v0.10.3 -> v0.10.3
01:04 < wumpus>  * [new tag]         v0.11.1 -> v0.11.1
01:06 -!- randy-waterhouse [~kiwigb@opentransactions/dev/randy-waterhouse] has joined #bitcoin-core-dev
01:09 < Luke-Jr> is https://github.com/jtimon/bitcoin/commit/6a07eb676a020b0035173facb25f92f1ff6380f7 a bugfix hiding inside https://github.com/bitcoin/bitcoin/pull/6424 ? O.o
01:11 < midnightmagic> Luke-Jr: just trying to be complete. Is that a duplicate?
01:11 < Luke-Jr> midnightmagic: no, just stale :p
01:11 < midnightmagic> :-)
01:14 < midnightmagic> lot of tags I've been remiss on..
01:14 < wumpus> at this point I would not recommend building any 0.10 versions < 0.10.3 and 0.11 versions < 0.11.1 
01:15 < wumpus> __unless you somehow swap the miniupnpc version, but in that case it wouldn't match so what is the point
01:17 < 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
01:25 < wumpus> but first priority is getting 0.11.1 (and possibly 0.10.3) to people
01:25 < 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
01:41 -!- d_t [~textual@c-50-136-139-144.hsd1.ca.comcast.net] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
01:53 -!- alpalp [6836eb1c@gateway/web/cgi-irc/kiwiirc.com/ip.104.54.235.28] has quit [Quit: http://www.kiwiirc.com/ - A hand crafted IRC client]
02:01 < 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.
02:06 < wumpus> midnightmagic: right, makes sense
02:13 -!- jl2012_ [~jl2012@pn-206-89.itsc.cuhk.edu.hk] has joined #bitcoin-core-dev
02:13 -!- jl2012 [~jl2012@unaffiliated/jl2012] has quit [Ping timeout: 272 seconds]
02:26 -!- CodeShark [CodeShark@cpe-76-167-237-202.san.res.rr.com] has joined #bitcoin-core-dev
02:27 -!- CodeShark [CodeShark@cpe-76-167-237-202.san.res.rr.com] has quit [Client Quit]
02:27 -!- CodeShark [CodeShark@cpe-76-167-237-202.san.res.rr.com] has joined #bitcoin-core-dev
02:35 -!- randy-waterhouse [~kiwigb@opentransactions/dev/randy-waterhouse] has quit [Ping timeout: 272 seconds]
02:39 -!- randy-waterhouse [~kiwigb@opentransactions/dev/randy-waterhouse] has joined #bitcoin-core-dev
03:34 -!- Guest58630 is now known as GAit
04:10 -!- go1111111 [~go1111111@162.244.138.37] has quit [Ping timeout: 240 seconds]
04:12 -!- go1111111 [~go1111111@162.244.138.37] has joined #bitcoin-core-dev
04:29 < GitHub58> [bitcoin] MarcoFalke opened pull request #6827: [rpc-tests] Check return code (master...MarcoFalke-2015-rpcTestsReturnCode) https://github.com/bitcoin/bitcoin/pull/6827
05:33 < 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
05:59 -!- molly [~molly@unaffiliated/molly] has joined #bitcoin-core-dev
06:24 -!- stonecoldpat1 [~a9380004@janus-nat-128-240-225-56.ncl.ac.uk] has left #bitcoin-core-dev []
07:01 -!- Thireus [~Thireus@icy.thireus.fr] has quit [Quit: Leaving.]
07:25 -!- Thireus [~Thireus@icy.thireus.fr] has joined #bitcoin-core-dev
07:44 < cfields> gitian builders: 0.10.3 osx detached signature: https://bitcoincore.org/cfields/bitcoin-0.10.3/signature.tar.gz
07:50 < wumpus> github should be automatically reporting that, weird
07:51 < wumpus> (at least, pushes to master on the detached sigs repository should be reported)
07:53 < cfields> wumpus: 0.10.3 didn't use the repo, still have to manually fetch it
07:54 < wumpus> oh? I am, somehow, using the automatic fetching with 0.10.3
07:55  * wumpus must be doing something wrong, let me check
07:56  * cfields checks the releases rc2 dmg
07:57 < wumpus> ... ugh
08:01 < cfields> wumpus: yikes. mismatch on rc2 :\
08:02 < 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
08:03 < cfields> yea
08:04 < cfields> also points out that you were correct to suggest writing the checksum of the unsigned file into the sig payload a whlie back
08:04 < wumpus> yes
08:04 -!- treehug88 [~textual@static-108-30-103-59.nycmny.fios.verizon.net] has joined #bitcoin-core-dev
08:04 < wumpus> attaching the wrong signature should ideally fail :)
08:05 < cfields> yea
08:06 < cfields> for windows it does, that actually saved me on rc2
08:06 < cfields> i'll make it simulate that for osx via checksums. adding now.
08:07 -!- d_t [~textual@c-50-136-139-144.hsd1.ca.comcast.net] has joined #bitcoin-core-dev
08:17 < 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.
08:20 < wumpus> kanzure: that tends to happen when the http connection times out server-side, python is pretty bad at handling that
08:23 < wumpus> kanzure: see commit ddf98d1
08:31 < kanzure> why would getinfo timeout so quickly?
08:31 -!- moli [~molly@unaffiliated/molly] has joined #bitcoin-core-dev
08:32 < 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
08:33 < wumpus> but this only applies to master, which has http timeouts
08:34 -!- molly [~molly@unaffiliated/molly] has quit [Ping timeout: 240 seconds]
08:37 < wumpus> there may well be a different issue, but it may help troubleshooting
08:38 < kanzure> wumpus: for that to be the source of my problem, the connection must have been opened long before i made the getinfo call?
08:41 < wumpus> yes - at least "-rpcservertimeout" seconds, and you must be using master
08:42 < kanzure> hmm maybe i'll go try -rpcservertimeout=0
08:42 < kanzure> yes this is on master (ish) (a week old maybe)
08:43 < morcos> cfields: any chance you want to think about nLastBlockFile for a sec?
08:44 < cfields> morcos: sure. give me 5 min to wrap something up?
08:44 < morcos> sure
08:53 -!- Thireus [~Thireus@icy.thireus.fr] has quit [Quit: Leaving.]
09:00 -!- CodeShark [CodeShark@cpe-76-167-237-202.san.res.rr.com] has quit [Ping timeout: 250 seconds]
09:02 -!- d_t [~textual@c-50-136-139-144.hsd1.ca.comcast.net] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
09:04 -!- d_t [~textual@c-50-136-139-144.hsd1.ca.comcast.net] has joined #bitcoin-core-dev
09:12 < cfields> morcos: what's up?
09:13 < cfields> wow, that took 30. felt like 5. sorry bout that :\
09:13 < morcos> cfields: ok so i've been trying to make sure there isn't an issue with pruning accidentally deleting the wrong block files
09:14 < 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
09:14 < morcos> so that needs to be fixed
09:15 < morcos> but in the course of trying to trace through all this stuff, nLastBlockFile is kind of confusing
09:15 < morcos> what is is really supposed to represent
09:15 < morcos> where you're going to write the next block to?
09:15 < 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?
09:16 < morcos> wouldn't it make sense if it was really your last block file?
09:17 < 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
09:19 < morcos> ok, in particular i'm wondering whether it might make sense for line 2506 to read nLastBlockFile = max(nFile, nLastBlockFile)
09:20 < morcos> i just dont understand why it ever needs to go backwards
09:21 -!- jl2012 [~jl2012@unaffiliated/jl2012] has joined #bitcoin-core-dev
09:22 < 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.
09:22 -!- jl2012_ [~jl2012@pn-206-89.itsc.cuhk.edu.hk] has quit [Read error: Connection reset by peer]
09:23 < 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
09:24 < cfields> hmm yes, without max() that looks very strange
09:25 < 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
09:25 < cfields> still reading and re-remembering
09:25 < morcos> but its just kind of confusing
09:25 < cfields> right
09: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
09:28 -!- Thireus [~Thireus@icy.thireus.fr] has joined #bitcoin-core-dev
09:29 < 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
09:34 < cfields> still looking
09:37 -!- AtashiCon [arnavion@unaffiliated/arnavion] has quit [Disconnected by services]
09:37 -!- Arnavion3 [arnavion@unaffiliated/arnavion] has joined #bitcoin-core-dev
09:37 -!- Arnavion3 is now known as AtashiCon
09:37 < michagogo> wumpus: I'd have caught the rc2 dmg thing if I were at my computer
09:37 < michagogo> But that unfortunately hasn't happened much at all lately
09:38 < 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 :-/
09:38 < michagogo> Doesn't leave me much leisure time.
09:44 < cfields> morcos: ok, i believe i remember the logic now
09:44 -!- jcorgan_ [~jcorgan@ec2-54-67-38-167.us-west-1.compute.amazonaws.com] has joined #bitcoin-core-dev
09:44 -!- jcorgan_ [~jcorgan@ec2-54-67-38-167.us-west-1.compute.amazonaws.com] has quit [Changing host]
09:44 -!- jcorgan_ [~jcorgan@unaffiliated/jcorgan] has joined #bitcoin-core-dev
09:44 < 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
09:46 < 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.
09:46 < morcos> cfields: hmm..  i see
09:46 < cfields> so (as i read it) it can't actually go backwards, only start from the point where the reindex finished
09:47 < morcos> but in the case you point out, there still coudl be valid blocks in say file 51
09:47 < morcos> that have height less than the block in file 50
09:47 -!- Palaver [~Palaver@c-24-20-191-68.hsd1.or.comcast.net] has joined #bitcoin-core-dev
09:48 < 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
09:48 < morcos> so if we changed that line to max, wouldn't you still get the fast majority of that benefity
09:49 < morcos> vast
09:50 -!- Netsplit *.net <-> *.split quits: jl2012, Guest4879, Crypton, harding, jcorgan, maaku, fkhan, goregrind
09:51 -!- Palaver [~Palaver@c-24-20-191-68.hsd1.or.comcast.net] has quit [Remote host closed the connection]
09:52 < 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
09:52 < morcos> move?
09:53 < morcos> what happens now is it stays in 51, and nLastBlockFile stays at 50
09:53 < morcos> even if we shutdown and restart (without reindex) thats the case
09:54 < morcos> luckily this extra searchign for vinfoBlockFiles in the database finds the information for 51, so you know about it
09:54 < cfields> mm nm, that's not right
09:55 < wumpus> michagogo: no problem - blame the (unavoidable) hurry around this release
09:58 < cfields> morcos: i thought i remembered the index pos being updated, but that's not the case. looks like you're right.. 
09:59 < 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
09:59 -!- jl2012 [~jl2012@unaffiliated/jl2012] has joined #bitcoin-core-dev
09:59 -!- maaku [~quassel@botbot.xen.prgmr.com] has joined #bitcoin-core-dev
09:59 -!- fkhan [weechat@gateway/vpn/mullvad/x-axplirbccmseankd] has joined #bitcoin-core-dev
09:59 -!- goregrind [~goregrind@unaffiliated/goregrind] has joined #bitcoin-core-dev
09:59 -!- Guest4879 [~quassel@173-228-107-141.dsl.static.fusionbroadband.com] has joined #bitcoin-core-dev
10:00 < cfields> morcos: for the sake of clarity, i think it'd suffice to stick the "nLastBlockFile = nFile" in the if(fKnown) case?
10:01 < morcos> did you mean !fKnown
10:01 < morcos> that was my first inclination, but then it never gets updated if you do a reindex, hence my suggestion for max
10:02 < 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"
10:03 < cfields> no, if(fKnown). that's the reindex case.
10:03 < 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
10:04 < cfields> ugh, wait
10:04 < morcos> but in the !fKnown case it defintiely needs to happen, because nFile might get incremented if we move to a new file
10:05 < cfields> of course, brainfart
10:07 -!- Netsplit *.net <-> *.split quits: fkhan, jl2012, Guest4879, maaku, goregrind
10:07 -!- harding [~harding@mail.dtrt.org] has joined #bitcoin-core-dev
10:08 < cfields> morcos: ok. yes, i agree with max()
10:09 < 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
10:09 < 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
10:10 -!- jl2012 [~jl2012@unaffiliated/jl2012] has joined #bitcoin-core-dev
10:10 -!- maaku [~quassel@botbot.xen.prgmr.com] has joined #bitcoin-core-dev
10:10 -!- fkhan [weechat@gateway/vpn/mullvad/x-axplirbccmseankd] has joined #bitcoin-core-dev
10:10 -!- goregrind [~goregrind@unaffiliated/goregrind] has joined #bitcoin-core-dev
10:10 -!- Guest4879 [~quassel@173-228-107-141.dsl.static.fusionbroadband.com] has joined #bitcoin-core-dev
10:10 < 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
10:11 < 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
10:11 < morcos> it doesn't update the state of the vinfoBlockfiles but its taking up room.  
10:11 < cfields> if the order is completely correct, then i think the current code should work ok without max()?
10:12 < morcos> the current code does work, its just confusing
10:12 < cfields> morcos: aha, that makes sense
10:13 < morcos> i don't like the idea that nLastBlockFile can be smaller than your vinfoBlockFile.size() 
10:13 < morcos> seems fragile or something
10:14 < cfields> morcos: maybe just delete the garbage files after reindex then?
10:14 < morcos> but what i'm saying is they are not necessarily garbage
10:15 < morcos> blockfile 51 has vaild blocks part of chainactive in it.  but chainactive.tip is in block file 50.  then nLastBlockFile = 50
10:15 < morcos> after a reindex
10:15 -!- jl2012_ [~jl2012@119246245241.ctinets.com] has joined #bitcoin-core-dev
10:15 < morcos> i would prefer nLastBlockFile to = 51 in that case
10:16 -!- jl2012 [~jl2012@unaffiliated/jl2012] has quit [Ping timeout: 265 seconds]
10:19 < 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
10:20 < cfields> morcos: see above. reindexing attempts to process in-order, so tip should always be in 51. is that not the case?
10:20 < cfields> morcos: sure. but now after discussing, i'm left scratching my head about how things look after a reindex
10:21 < 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
10:22 < morcos> since blocks can be stored on disk out of order, that block can be back in block file 50.
10:22 < 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
10:23 -!- jl2012_ [~jl2012@119246245241.ctinets.com] has quit [Read error: Connection reset by peer]
10:23 < 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
10:23 -!- jl2012 [~jl2012@unaffiliated/jl2012] has joined #bitcoin-core-dev
10:29 < cfields> morcos: but because PNB isn't called until they can be connected, isn't the tip the last to be processed?
10:29 < cfields> or maybe the out-of-order ones themselves aren't played back in-order ?
10:30 < 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
10:30 < morcos>  nFile = fKnown ? pos.nFile : nLastBlockFile;
10:31 < cfields> ok, i see
10:35 < cfields> yep, ok. completely with you now. sorry for making you beat it into me. i agree with all of your conclusions :)
10:38 < 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?
10:39 -!- randy-waterhouse [~kiwigb@opentransactions/dev/randy-waterhouse] has quit [Ping timeout: 272 seconds]
10:39 < 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
10:39 < cfields> morcos: yes
10:41 < morcos> thx
10:52 -!- challisto [~challisto@unaffiliated/challisto] has joined #bitcoin-core-dev
10:58 -!- Micha|iPhone [~michagogo@wikia/Michagogo] has joined #bitcoin-core-dev
10:59 < Micha|iPhone> Hm, for some reason IRCCloud seems to not want to work
10:59 < Micha|iPhone> Maybe there was some big ddos or netsplit or something
11:00 < 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.
11:00 < Micha|iPhone> That should give you 3, I think?
11:01 < Micha|iPhone> 0.10.3 might have to wait until tomorrow
11:05 -!- Micha|iPhone [~michagogo@wikia/Michagogo] has quit [Quit: Colloquy for iPhone - http://colloquy.mobi]
11:19 < wumpus> yes, definitly do 0.11.1 first, we're waiting on signatures there
11:19 < michagogo> Booting VM now.
11:20 -!- molly [~molly@unaffiliated/molly] has joined #bitcoin-core-dev
11:22 -!- moli [~molly@unaffiliated/molly] has quit [Ping timeout: 240 seconds]
11:41 < michagogo> Okay, build running. BTW: does using relative paths work in a string of commands chained with &&I that includes cds?
11:41 < michagogo> &&s*
11:42 < michagogo> Erm
11:42 < michagogo> fatal: Couldn't find remote ref v0.11.1
11:42 < michagogo> On the sig fetching
11:42 < michagogo> cfields: ^
11:43 < cfields> michagogo: sig isn't pushed yet, need one more unsigned signer
11:43 < michagogo> Eh?
11:43 < michagogo> Luke committed his
11:43 < cfields> ah, i missed that
11:43 < cfields> verifying now
11:44 < michagogo> Good thing I made my script (IIRC) recheck after the build for signature availability
11:46 < 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
11:46 < GitHub93> [bitcoin] domob1812 opened pull request #6829: doc: add comment explaining initial header request (master...doc-getheaders) https://github.com/bitcoin/bitcoin/pull/6829
11:48 < cfields> michagogo: pushed.
11:50 < michagogo> Great. My script should (I think) automatically pick up on that, and pr the sigs including the signed.
11:50 < michagogo> And if I didn't mess up the && chain of commands, should even do 0.10.3 too
11:51 < michagogo> (Should almost definitely get the win, Linux, and OS X unsigned -- the question is the signing)
11:53 < michagogo> It would be nice to have this channel subscribed to the gitian.sigs repo the same way it is to bitcoin
11:54 < michagogo> (Also, idk if I've ever seen a -n channel before)
12:14 -!- paveljanik [~paveljani@unaffiliated/paveljanik] has joined #bitcoin-core-dev
12:14 -!- moli [~molly@unaffiliated/molly] has joined #bitcoin-core-dev
12:17 -!- molly [~molly@unaffiliated/molly] has quit [Ping timeout: 240 seconds]
12:33 -!- Palaver_ [~Palaver@172.56.38.172] has joined #bitcoin-core-dev
12:35 -!- Palaver_ [~Palaver@172.56.38.172] has quit [Remote host closed the connection]
12:41 -!- molly [~molly@unaffiliated/molly] has joined #bitcoin-core-dev
12:44 -!- moli [~molly@unaffiliated/molly] has quit [Ping timeout: 240 seconds]
13:13 < 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
13:26 -!- belcher [~user@unaffiliated/belcher] has joined #bitcoin-core-dev
13:30 -!- treehug88 [~textual@static-108-30-103-59.nycmny.fios.verizon.net] has quit [Quit: Textual IRC Client: www.textualapp.com]
13:32 < michagogo> wumpus: sigs PR'd
13:52 < 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
13: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
13:56  * michagogo preps the Reddit post
13:56  * michagogo checks if there's a release PR for bitcoin.org
13:56 < michagogo> Ah, indeed there is: https://github.com/bitcoin-dot-org/bitcoin.org/pull/1085
13:58 < michagogo> cfields: yeah, looks like the sigs did indeed get pulled
13:58 < michagogo> Thanks!
13:58 < michagogo> !m cfields 
13:58 < [b__b]> You're doing good work, cfields!
13:58 < gribble> Error: "m" is not a valid command.
13:58 < michagogo> ...that's actually on, lol
13:58 < michagogo> [b__b]: help
13:58 < [b__b]> Available plugins: bangmotivate, help, last_seen, ping, logger (https://botbot.me/freenode/bitcoin-core-dev/help/)
14:00 < cfields> michagogo: great, matched. thanks
14:04  * michagogo wonders if wumpus is still here to push the button
14:15 -!- paveljanik [~paveljani@unaffiliated/paveljanik] has quit [Quit: Leaving]
14:17 -!- PRab [~chatzilla@2601:40a:8000:8f9b:7023:f46d:1955:e417] has quit [Read error: Connection reset by peer]
14:18 -!- d_t [~textual@c-50-136-139-144.hsd1.ca.comcast.net] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
14:23 -!- d_t [~textual@c-50-136-139-144.hsd1.ca.comcast.net] has joined #bitcoin-core-dev
14:35 < Luke-Jr> detached sigs for 0.10.3?
14:35 -!- belcher [~user@unaffiliated/belcher] has quit [Read error: Connection reset by peer]
14:37 -!- belcher [~user@unaffiliated/belcher] has joined #bitcoin-core-dev
14:37 < cfields> Luke-Jr: https://bitcoincore.org/cfields/bitcoin-0.10.3/signature.tar.gz
14:37 < Luke-Jr> cfields: what happened with the git repo?
14:38 < cfields> Luke-Jr: that wasn't in for 0.10, only 0.11+
14:39 < cfields> historical ones are there, but they're not gzipped and ready for gitian
14:39 < Luke-Jr> can still download it from there :P
14:39 < Luke-Jr> i c
14:39 < cfields> (though i do need to push them there for 0.10, thanks for reminding me)
14:47 -!- belcher [~user@unaffiliated/belcher] has quit [Ping timeout: 260 seconds]
14:50 -!- belcher [~user@unaffiliated/belcher] has joined #bitcoin-core-dev
14:59 < Luke-Jr> ok, 0.10.3 has three sets of sigs if someone wants to publish
15:00 < Luke-Jr> should have 0.11.1 soon, but I accidentally the windows binaries
15:00  * Luke-Jr tempted to hack gitian to use build/out-pkgname/ :P
15:14 -!- PRab [~chatzilla@2601:40a:8000:8f9b:7023:f46d:1955:e417] has joined #bitcoin-core-dev
15:22 < 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
15:26 < Luke-Jr> ok, 0.11.1 has 3 sigs now too
15:26 < Luke-Jr> wumpus: thanks
15:57 -!- d_t [~textual@c-50-136-139-144.hsd1.ca.comcast.net] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
15:59 -!- d_t [~textual@c-50-136-139-144.hsd1.ca.comcast.net] has joined #bitcoin-core-dev
16:15 -!- lecusemb1e [~lecusembl@f9beb4d9.violates.me] has quit [Ping timeout: 264 seconds]
16:17 -!- lecusemble [~lecusembl@f9beb4d9.violates.me] has joined #bitcoin-core-dev
16:42 -!- alpalp [6836eb1c@gateway/web/cgi-irc/kiwiirc.com/ip.104.54.235.28] has joined #bitcoin-core-dev
16:47 -!- lecusemble [~lecusembl@f9beb4d9.violates.me] has quit [Ping timeout: 260 seconds]
16:49 -!- jgarzik [~jgarzik@29.sub-70-199-100.myvzw.com] has joined #bitcoin-core-dev
16:49 -!- jgarzik [~jgarzik@29.sub-70-199-100.myvzw.com] has quit [Changing host]
16:49 -!- jgarzik [~jgarzik@unaffiliated/jgarzik] has joined #bitcoin-core-dev
16:49 -!- jgarzik [~jgarzik@unaffiliated/jgarzik] has quit [Remote host closed the connection]
16:59 -!- AtashiCon [arnavion@unaffiliated/arnavion] has quit [Disconnected by services]
16:59 -!- Arnavion3 [arnavion@unaffiliated/arnavion] has joined #bitcoin-core-dev
16:59 -!- Arnavion3 is now known as AtashiCon
17:00 -!- PaulCapestany [~PaulCapes@204.28.124.82] has quit [Read error: Connection reset by peer]
17:00 -!- PaulCape_ [~PaulCapes@204.28.124.82] has joined #bitcoin-core-dev
17:02 -!- jcorgan_ is now known as jcorgan
17:16 -!- Thireus1 [~Thireus@icy.thireus.fr] has joined #bitcoin-core-dev
17:17 -!- Thireus [~Thireus@icy.thireus.fr] has quit [Ping timeout: 240 seconds]
17:17 -!- d_t [~textual@c-50-136-139-144.hsd1.ca.comcast.net] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
17:34 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-klojokmubmtcrosw] has quit [Quit: Connection closed for inactivity]
17:53 -!- CodeShark [~CodeShark@cpe-76-167-237-202.san.res.rr.com] has joined #bitcoin-core-dev
17:59 -!- moli [~molly@unaffiliated/molly] has joined #bitcoin-core-dev
18:01 -!- molly [~molly@unaffiliated/molly] has quit [Ping timeout: 240 seconds]
18:02 -!- molly [~molly@unaffiliated/molly] has joined #bitcoin-core-dev
18:04 -!- moli [~molly@unaffiliated/molly] has quit [Ping timeout: 240 seconds]
18:05 -!- Guest78786 is now known as pigeons
18:11 -!- belcher [~user@unaffiliated/belcher] has quit [Quit: Leaving]
18:24 -!- baldur [~baldur@pool-173-52-43-219.nycmny.fios.verizon.net] has quit [Read error: Connection reset by peer]
18:24 -!- baldur [~baldur@pool-173-52-43-219.nycmny.fios.verizon.net] has joined #bitcoin-core-dev
18:27 -!- trippysalmon [~Rob@ip4da81ded.direct-adsl.nl] has quit [Read error: Connection reset by peer]
18:30 < nanotube> https://bitcoin.org/en/download <- suggest that the "over 20GB" part toward the bottom should probably be updated to "over 50GB", or point to some resource that tracks blockchain size for future-proofness, to avoid giving misleading info.
18:33 < gmaxwell> hah. last time that got bumped I suggested removing the explicit size claim!
18:34 < Luke-Jr> I think there's an open issue for that since some weeks ago :/
18:36 < gmaxwell> I wonder if we shouldn't periodically write out a opaque file that gives a hash of a block 100 back or so, which acts like a persistant validation bypass, so that if you resync a pruned node it can skip the expense.
18:37 < gmaxwell> big problem with pruning right now is that the frequent leveldb corruption some users expirence make it quite a gamble.
19:04 < morcos> gmaxwell: can you elaborate on that?  what expense are you skipping?  validation?
19:06 < morcos> are you basically talking about your own private checkpoint?
19:17 -!- d_t [~textual@c-50-136-139-144.hsd1.ca.comcast.net] has joined #bitcoin-core-dev
19:40 -!- wumpus [~quassel@pdpc/supporter/professional/wumpus] has quit [Ping timeout: 240 seconds]
19:44 < Luke-Jr> local UTXO commitments for pruned bootstrapping would be handy, but dangerous
19:49  * Luke-Jr ponders that each release is 1 GB of hosted data for him XD
19:52 -!- moli [~molly@unaffiliated/molly] has joined #bitcoin-core-dev
19:55 -!- molly [~molly@unaffiliated/molly] has quit [Ping timeout: 240 seconds]
19:58 < Luke-Jr> there were no changes to bitcoin-cli in 0.11.1, right?
20:23 -!- petertodd [~pete@ec2-52-5-185-120.compute-1.amazonaws.com] has quit [Ping timeout: 244 seconds]
20:24 -!- petertodd [~pete@ec2-52-5-185-120.compute-1.amazonaws.com] has joined #bitcoin-core-dev
20:25 -!- petertodd is now known as Guest52664
20:30 < Luke-Jr> answer: OPENSSL_no_config :|
20:39 < cfields> Luke-Jr: that fixes possible crashes (or exit()s) due to faulty local openssl config
20:40 < Luke-Jr> right
20:40 < cfields> i don't think it should cause any abi issues?
20:54 < Luke-Jr> no, but it's a reason to bump -cli pkg to 0.11.1
21:06 < midnightmagic> btcdrak: is there some other place from the gitian sigs to find your pubkey? Or have other people in core signed it?
21:07 < btcdrak> petertodd signed it
21:07 < btcdrak> it's on the public keyservers
21:09 < midnightmagic> sometimes i think my comments are being filtered through some kind of cthulhu filter before they end up in front of everyone else's eyes.
21:13 < michagogo> midnightmagic: huh?
21:22 -!- lightningbot [lightningb@cerulean.erisian.com.au] has quit [Remote host closed the connection]
21:22 -!- lightningbot [supybot@2400:8900::f03c:91ff:fedf:3a06] has joined #bitcoin-core-dev
21:30 -!- PaulCape_ [~PaulCapes@204.28.124.82] has quit [Quit: .]
21:30 -!- PaulCapestany [~PaulCapes@204.28.124.82] has joined #bitcoin-core-dev
21:33 < nanotube> midnightmagic: how did you know about my cthulhu filter? i was told it was undetectable. >_____>
21:41 < midnightmagic> michagogo: eh. I had a big rant typed out but it doesn't matter. I just hate using public key servers. They're full of sigspam and the maintainers are too stubborn to stop using shortform keyids. Also, I am only okay with transitive trust sigs: via that, and places where btcdrak has direct control over, I triangulate key validity and mark local trust accordingly.
21:42 < btcdrak> midnightmagic: you sound eccentric :-P 
21:42 < midnightmagic> I fully expect virtually nobody here has actually verified anything about my keys except they're sitting there on pgp.mit.edu after someone who's not-me uploaded them there.
21:43 < midnightmagic> btcdrak: Well what's the point in using PGP keys at all if nobody does any verification on them right?
21:43 < btcdrak> midnightmagic: just teasing you :)
21:43 < midnightmagic> :-P
21:44 < midnightmagic> And thereby you point out my hypocrisy! lol I love it.
21:51 < jcorgan> meh, pgp web of trust is overrated
22:01 -!- CodeShark [~CodeShark@cpe-76-167-237-202.san.res.rr.com] has quit [Ping timeout: 265 seconds]
22:42 -!- da2ce7 [~da2ce7@opentransactions/dev/da2ce7] has quit [Quit: ZNC - http://znc.in]
22:42 -!- equil_ [~equil@bcdde34c.skybroadband.com] has joined #bitcoin-core-dev
22:45 -!- Thireus1 [~Thireus@icy.thireus.fr] has quit [Ping timeout: 240 seconds]
22:46 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-zzmchqgovcmoedgb] has joined #bitcoin-core-dev
22:46 -!- da2ce7 [~da2ce7@opentransactions/dev/da2ce7] has joined #bitcoin-core-dev
23:13 -!- Thireus [~Thireus@icy.thireus.fr] has joined #bitcoin-core-dev
23:29 -!- Thireus [~Thireus@icy.thireus.fr] has quit [Quit: Leaving.]
23:36 -!- Thireus [~Thireus@icy.thireus.fr] has joined #bitcoin-core-dev
23:43 -!- Thireus [~Thireus@icy.thireus.fr] has quit [Quit: Leaving.]
23:54 < da2ce7> hello, what happend to pr https://github.com/bitcoin/bitcoin/pull/6788
23:54 < da2ce7> the diff and history are insane.
23:54 < da2ce7> (or is it just a github bug?)
23:57 -!- Thireus [~Thireus@icy.thireus.fr] has joined #bitcoin-core-dev