--- Day changed Fri Feb 12 2016
00:00 -!- paveljanik [~paveljani@unaffiliated/paveljanik] has quit [Quit: Leaving]
00:04 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-htdsfbfrasriazqq] has joined #bitcoin-core-dev
00:09 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev
00:14 -!- Sparyx [~Sparyx@c-73-224-87-206.hsd1.fl.comcast.net] has joined #bitcoin-core-dev
00:22 -!- frankenmint [~frankenmi@174-25-38-39.ptld.qwest.net] has quit [Remote host closed the connection]
00:24 -!- davec [~davec@cpe-24-243-251-52.hot.res.rr.com] has quit [Read error: Connection reset by peer]
00:30 -!- zesi [c12f6823@gateway/web/freenode/ip.193.47.104.35] has joined #bitcoin-core-dev
00:30 -!- davec [~davec@cpe-24-243-251-52.hot.res.rr.com] has joined #bitcoin-core-dev
00:40 -!- JackH [~Jack@host-2-103-125-6.as13285.net] has joined #bitcoin-core-dev
00:42 -!- Evel-Knievel [~Evel-Knie@d5152f744.static.telenet.be] has quit [Ping timeout: 252 seconds]
00:45 -!- Evel-Knievel [~Evel-Knie@d5152f744.static.telenet.be] has joined #bitcoin-core-dev
00:49 -!- frankenmint [~frankenmi@174-25-38-39.ptld.qwest.net] has joined #bitcoin-core-dev
00:52 < GitHub170> [bitcoin] wodry opened pull request #7523: Fix of semantic failure "meet pay" (0.12...patch-1) https://github.com/bitcoin/bitcoin/pull/7523
00:56 -!- Sparyx [~Sparyx@c-73-224-87-206.hsd1.fl.comcast.net] has quit [Ping timeout: 250 seconds]
01:09 -!- zesi [c12f6823@gateway/web/freenode/ip.193.47.104.35] has quit [Quit: Page closed]
01:12 < GitHub88> [bitcoin] laanwj closed pull request #7523: Fix of semantic failure "meet pay" (0.12...patch-1) https://github.com/bitcoin/bitcoin/pull/7523
01:12 < GitHub26> [bitcoin] laanwj pushed 2 new commits to 0.12: https://github.com/bitcoin/bitcoin/compare/04503f78c750...02d707ff37a1
01:12 < GitHub26> bitcoin/0.12 e473c2d wodry: Fix of semantic failure "meet pay"...
01:12 < GitHub26> bitcoin/0.12 02d707f Wladimir J. van der Laan: Merge #7523: Fix of semantic failure "meet pay"...
01:15 -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has joined #bitcoin-core-dev
01:16 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-core-dev
01:16 -!- paveljanik [~paveljani@unaffiliated/paveljanik] has joined #bitcoin-core-dev
01:22 -!- Sparyx [~Sparyx@c-73-224-87-206.hsd1.fl.comcast.net] has joined #bitcoin-core-dev
02:02 -!- randy-waterhouse [~kiwigb@opentransactions/dev/randy-waterhouse] has quit [Quit: Leaving.]
02:13 -!- Sparyx [~Sparyx@c-73-224-87-206.hsd1.fl.comcast.net] has quit [Ping timeout: 245 seconds]
02:16 < wumpus> hm RPC/univalue seems to generate invalid json on special floating point values like NaN, -inf, +inf, not sure what should be generated in that case though (and luckily there is no place in the API where those are normally returned)
02:19 < gmaxwell> The hashrate estimate thing left me wondering if it could return a nan in some case.
02:19 < gmaxwell> but it didn't look like it.
02:20 < gmaxwell> The ping time might be another place.
02:20 < gmaxwell> hm guess we don't divide there at least.
02:20 -!- Sparyx [~Sparyx@c-73-224-87-206.hsd1.fl.comcast.net] has joined #bitcoin-core-dev
02:20 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has quit [Quit: :)]
02:20 < wumpus> difficulty for an all-zeros target ;)
02:21 < wumpus> in any case it should be fixed at some point, I'll report an issue, but doesn't look urgent.
02:23 -!- dgenr8 [~dgenr8@unaffiliated/dgenr8] has quit [Ping timeout: 252 seconds]
02:23 -!- dgenr8 [~dgenr8@unaffiliated/dgenr8] has joined #bitcoin-core-dev
02:24 -!- dgenr8 [~dgenr8@unaffiliated/dgenr8] has quit [Read error: Connection reset by peer]
02:24 -!- dgenr8 [~dgenr8@unaffiliated/dgenr8] has joined #bitcoin-core-dev
02:29 < wumpus> https://github.com/jgarzik/univalue/issues/19   
02:37 < wumpus> cfields: did you find a clue why your gitian output doesn't match?
02:40 < gmaxwell> wumpus: have you followed the discussion about wallet transaction rebroadcast?
02:41 < wumpus> yes
02:41 < wumpus> not going to hold up 0.12.0 for another wallet issue though
02:43 < wumpus> at some point we just need to make the cut
02:43 < wumpus> I hate having to say this every release
02:46 < wumpus> leave something to be fixed in 0.12.1
02:46 < wumpus> I'm sure more issues will come up
02:47 < gmaxwell> OK
02:47 < wumpus> this last-minute-based development is unduely stressful
02:48 < gmaxwell> well that was why I did hope that the fix for that could be made very small. but indeed.
02:49 < gmaxwell> but yes, I don't disagree at all.
02:51 < wumpus> a 'small' change still needs testing, especially if made in a hurry
02:52 < wumpus> in any case if it turn out we really do need another rc because cfields cannot build this one deterministically, then we can include it
03:07 -!- Sparyx [~Sparyx@c-73-224-87-206.hsd1.fl.comcast.net] has quit [Remote host closed the connection]
03:20 -!- laurentmt [~Thunderbi@128-79-141-196.hfc.dyn.abo.bbox.fr] has joined #bitcoin-core-dev
04:01 -!- frankenmint [~frankenmi@174-25-38-39.ptld.qwest.net] has quit [Remote host closed the connection]
04:07 < GitHub105> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/2f3f4af4cc2b...621940e04090
04:07 < GitHub105> bitcoin/master a0a17b3 Pavel Janík: LibreSSL doesn't define OPENSSL_VERSION, use LIBRESSL_VERSION_TEXT instead
04:07 < GitHub105> bitcoin/master 621940e Wladimir J. van der Laan: Merge #7520: LibreSSL doesn't define OPENSSL_VERSION, use LIBRESSL_VERSION_TEXT instead...
04:07 < GitHub160> [bitcoin] laanwj closed pull request #7520: LibreSSL doesn't define OPENSSL_VERSION, use LIBRESSL_VERSION_TEXT instead (master...20160211_LibreSSL_compile_fix) https://github.com/bitcoin/bitcoin/pull/7520
04:09 -!- frankenmint [~frankenmi@174-25-38-39.ptld.qwest.net] has joined #bitcoin-core-dev
04:17 -!- amiller [~socrates1@unaffiliated/socrates1024] has quit [Ping timeout: 256 seconds]
04:23 -!- Guest58194 [~socrates1@li175-104.members.linode.com] has joined #bitcoin-core-dev
05:04 < cfields> wumpus: finally gave up on poking at it and created a clean setup on my macbook, building now. i'll figure out my issue later
05:06 < wumpus> okay- there was no trivial difference, the executables were completely out of whack?
05:10 < cfields> yea
05:11 < cfields> i'll keep my build objects on the fresh builder for comparison. i'd still like to hunt it down, just to be aware of the variable
05:12 -!- drnet [~drnett@77.119.128.186.wireless.dyn.drei.com] has joined #bitcoin-core-dev
05:20 -!- Kexkey [~kexkey@192.99.233.162] has joined #bitcoin-core-dev
05:26 -!- drnet [~drnett@77.119.128.186.wireless.dyn.drei.com] has quit [Quit: Leaving]
05:26 -!- Kexkey [~kexkey@192.99.233.162] has quit []
05:44 -!- Thireus [~Thireus@vps-92.197.170.217.stwvps.net] has quit [Ping timeout: 250 seconds]
05:48 -!- zooko [~user@c-73-229-199-227.hsd1.co.comcast.net] has joined #bitcoin-core-dev
06:10 -!- Thireus [~Thireus@vps-92.197.170.217.stwvps.net] has joined #bitcoin-core-dev
07:09 -!- paveljanik [~paveljani@unaffiliated/paveljanik] has quit [Quit: Leaving]
07:26 -!- bityogi [~textual@208-104-143-200.brvd.dsl.dyn.comporium.net] has joined #bitcoin-core-dev
07:33 -!- Thireus1 [~Thireus@vps-92.197.170.217.stwvps.net] has joined #bitcoin-core-dev
07:34 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Remote host closed the connection]
07:36 -!- Thireus [~Thireus@vps-92.197.170.217.stwvps.net] has quit [Ping timeout: 252 seconds]
07:43 -!- Thireus1 [~Thireus@vps-92.197.170.217.stwvps.net] has quit [Quit: Leaving.]
07:43 -!- Thireus [~Thireus@vps-92.197.170.217.stwvps.net] has joined #bitcoin-core-dev
07:47 < wumpus> the only thing I can think of that can cause such large differences would be a gcc upgrade on the base image
07:47 < wumpus> if it's just some compiled-in variable it's usually just a few bytes difference
07:57 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev
07:59 -!- zooko [~user@c-73-229-199-227.hsd1.co.comcast.net] has quit [Ping timeout: 248 seconds]
08:01 -!- Guest58194 [~socrates1@li175-104.members.linode.com] has quit [Changing host]
08:01 -!- Guest58194 [~socrates1@unaffiliated/socrates1024] has joined #bitcoin-core-dev
08:01 -!- Guest58194 is now known as amiller
08:02 -!- skyraider_ [uid41097@gateway/web/irccloud.com/x-xonviuzbkgnvfxyu] has joined #bitcoin-core-dev
08:04 < GitHub174> [bitcoin] laanwj pushed 5 new commits to master: https://github.com/bitcoin/bitcoin/compare/621940e04090...80d1f2e48364
08:04 < GitHub174> bitcoin/master c6c2f0f Alex Morcos: Implement SequenceLocks functions...
08:04 < GitHub174> bitcoin/master da6ad5f Suhas Daftuar: Add RPC test exercising BIP68 (mempool only)
08:04 < GitHub174> bitcoin/master a51c79b Alex Morcos: Bug fix to RPC test
08:04 < GitHub95> [bitcoin] laanwj closed pull request #7184: Implement SequenceLocks functions for BIP 68 (master...alternate68) https://github.com/bitcoin/bitcoin/pull/7184
08:16 < btcdrak> OMG!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!1
08:16 < btcdrak> \o/
08:23 < wumpus> more gitian problems, this time building macosx. What is happening? https://github.com/bitcoin/gitian.sigs/pull/304
08:29 < JackH> this is huge, huge huge huge
08:30 < Ylbam> \o/
08:40 -!- ryitpm [~ryitpm@87.121.52.41] has joined #bitcoin-core-dev
08:44 -!- treehug88 [~textual@static-108-30-103-59.nycmny.fios.verizon.net] has joined #bitcoin-core-dev
08:45 < cfields> wumpus: sigh, another mismatch for me
08:46 < wumpus> cfields: strange
08:47 < wumpus> so this is with a new base image?
08:49 < wumpus> going to have a look at it
08:49 < cfields> newish, but i'll try again
08:50 < cfields> i think the deps are all equal, so should be much quicker
08:50 -!- treehug88 [~textual@static-108-30-103-59.nycmny.fios.verizon.net] has quit [Quit: Textual IRC Client: www.textualapp.com]
08:52 < wumpus> all the mingw .deb packages are equal between us
08:52 < wumpus> so that rules out the compiler or binutils
08:53 < wumpus> can you upload your win64 result please?
08:55 < cfields> yep, sec
09:01 -!- frankenmint [~frankenmi@174-25-38-39.ptld.qwest.net] has quit [Remote host closed the connection]
09:02 < cfields> wumpus: https://www.dropbox.com/s/nv27zxuit0202l9/bitcoin-0.12.0-win64.zip
09:04 < wumpus> got it
09:05 < cfields> actually, some deps don't match on this new build
09:05 < wumpus> cfields: so bench_bitcoin, bitcoin-cli, bitcoin-tx match - bitcoind, bitcoin-qt, test-bitcoin and test-bitcoin-qt differ
09:06 < wumpus> wild guess: openssl?
09:06 < cfields> wumpus: openssl dep matched yours, no?
09:06 < wumpus> I didn't check yet
09:07 < wumpus> but yes that kind of rules it out
09:07 -!- paveljanik [~paveljani@unaffiliated/paveljanik] has joined #bitcoin-core-dev
09:08 < wumpus> non-matching executables are the same size - this rules out serious code/version differences
09:10 < wumpus> what the hell.
09:10 < wumpus> no, I can't make sense of this either, looks like scattered random differences
09:10 < cfields> yea, it seems things are just rearranged
09:10 < cfields> the random differences are mostly 1/2 bytes, which are just jump offsets
09:11 < cfields> s/offsets/addresses/
09:11 < wumpus> some gcc random seed issue again?
09:11 < cfields> so my guess was that functions got rearranged
09:11 < wumpus> or maybe file ordering within .a
09:11 < cfields> wumpus: well the weird part is that everyone else matched
09:12 < wumpus> my bet would be file ordering, and you using another file system than us
09:12 < cfields> otherwise i'd agree. it still points to pebkac, i just can't figure out what's different
09:12 < cfields> hmm, could be
09:12 < wumpus> or a locale leaking in issue, but you're not in a strange part of the world :-)
09:13 < cfields> well i think i did build the day after you guys
09:13 < cfields> (and building a 3rd day today)
09:14 < wumpus> last time I had an issue like this I compared the linker maps
09:14 < wumpus> good point, I'll build mine again to see if it changed.
09:14 < cfields> great, thanks. i'll rebuild with a fresh image
09:15 < wumpus> are you using LXC or KVM?
09:15 < wumpus> (no, I don't think that's what makes the difference)
09:15 < cfields> kvm
09:15 < wumpus> me too.
09:15 < wumpus> but kvm has less chance of external things leaking in
09:16 < cfields> right. and i built before on my desktop as usual, today with debian->trusty on my macbook
09:16 < cfields> that one should be about as "pure" as it gets
09:29 < GitHub164> [bitcoin] btcdrak opened pull request #7524: BIP-112: Mempool-only CHECKSEQUENCEVERIFY (master...checksequenceverify) https://github.com/bitcoin/bitcoin/pull/7524
10:02 -!- frankenmint [~frankenmi@174-25-38-39.ptld.qwest.net] has joined #bitcoin-core-dev
10:07 -!- frankenmint [~frankenmi@174-25-38-39.ptld.qwest.net] has quit [Ping timeout: 276 seconds]
10:22 -!- degriff [~toutatis@rob76-4-82-238-176-192.fbx.proxad.net] has joined #bitcoin-core-dev
10:42 < GitHub81> [bitcoin] jloughry opened pull request #7526: fix spelling of advertise (shows up in the debug log) (master...advertize-advertise) https://github.com/bitcoin/bitcoin/pull/7526
10:42 < cfields> wumpus: got a match
10:44 -!- treehug88 [~textual@static-108-30-103-59.nycmny.fios.verizon.net] has joined #bitcoin-core-dev
10:46 < wumpus> cfields: awesome! so upgrading the base image did it?
10:47 < cfields> wumpus: i just made a completely fresh one from debian and moved it over
10:47 < wumpus> holy shit I built from scratch (without cache) get a different output now
10:48 < cfields> maybe it has something to do with the fact that mine was a much older trusty image, so packages got held back or something
10:48 < cfields> ...
10:48 < wumpus> -    b13f362e4efbcdcc539398010ef3b287209dc497a057f1f86805cc610c1e6796  bitcoin-0.12.0-win64.zip
10:48 < wumpus> +    b785149cc0cc56dfb1c28626300f85ff8ea1b9658f8016bd9b202e32180a2bd9  bitcoin-0.12.0-win64.zip
10:49 < wumpus> that's not your output either, it's a third different one?
10:49 < cfields> wait, i wonder if that matches my unmatched macbook build
10:49 < cfields> sec, let me see if i still have it
10:50 < cfields> b785149cc0cc56dfb1c28626300f85ff8ea1b9658f8016bd9b202e32180a2bd9
10:50 < cfields> 4098c47e08a882892b2a2b88761cf688ae11d6a5a1d02270a154d60c0393e7fb  bitcoin-0.12.0-win-unsigned.tar.gz
10:50 < cfields> ?
10:50 < wumpus> wrong file
10:51 < cfields> yes, my first file matched yours. was asking if the final result matched too :)
10:52 < wumpus> this looks like a different issue: bench, cli, bitcoind, -tx matches, -qt, test_* does not
10:53 < wumpus> 4098c47e08a882892b2a2b88761cf688ae11d6a5a1d02270a154d60c0393e7fb yes that's it
10:54 < cfields> ok, so there was definitely some recent update that broke us
10:55 < wumpus> a small segment of code looks different, no string changes
10:55 < wumpus> no jump table scatter either though
10:55 < wumpus> yep
10:56 < wumpus> -    3a23c66f383d6f26482333a963189f6aed948fc59b651daed3a7a57944d9ac44  i686-w64-mingw32/boost/boost-1_59_0-00e14fdbc48.tar.gz
10:56 < wumpus> +    92058863d4944dfb2d5fae3b46014e6121870cb9fc5a016b093afe3f0671fd81  i686-w64-mingw32/boost/boost-1_59_0-00e14fdbc48.tar.gz
10:56 < wumpus> -    158452df335b82928c16f70efd3753482c4a737ba0a1c13bb1fa444e1f32738a  x86_64-w64-mingw32/qt/qt-5.5.0-70c250502c5.tar.gz
10:56 < wumpus> +    98b13ab377646e3aaebfee54555233b876ecbcc56ac60df88529adfca072bfbb  x86_64-w64-mingw32/qt/qt-5.5.0-70c250502c5.tar.gz
10:56 < wumpus> ok ok almost every dependency is different
10:57 < wumpus> may be the dependencies were built with older .deb packages, I cannot verify that
10:57 < GitHub167> [bitcoin] instagibbs opened pull request #7527: [RPC] Fix and listreceivedbyX documentation (master...listfix) https://github.com/bitcoin/bitcoin/pull/7527
10:57 < wumpus> I don't have them anymore I deleted them instead of moving them :(
10:57 < cfields> i think i still have copies of everything
10:58 < wumpus> but it certainly looks like there are more toolchain versions in play, that's the only explanation I can think of
10:58 < cfields> yea. i've been poking for the last few hours on/off, while building. i don't see anything obvious that's updated since november
10:59 < Luke-Jr> bisect?
10:59 < wumpus> bisect ubuntu?
11:00 < Luke-Jr> oh, recent OS update
11:00 < cfields> wumpus: well, i'll fixup depends to make sure it detects any kind of system change
11:00 < cfields> wumpus: for now, want to just take that last result, since it's the result of a fresh/clean build?
11:01 < Luke-Jr> depends should work without determinism, right?
11:01 < wumpus> cfields: indeed, having some toolchain version info part of the cache hash would make sense
11:02 < wumpus> cfields: yes, I think so. We'll have to recommend everyone to update their base image and rebuild
11:03 < cfields> wumpus: yea, i was planning to add `$cc -v | sha256` to the hash, but now i'm thinking it might make sense to take an additional optional seed as well. in gitian's case, it'll be the result of `dpkg -l` or so
11:03 -!- frankenmint [~frankenmi@174-25-38-39.ptld.qwest.net] has joined #bitcoin-core-dev
11:03 < wumpus> I'm not sure any change in dpkg should cause a rebuild
11:03 < cfields> (without trying to add each tool by hand)
11:04 < wumpus> right...
11:04 < wumpus> we should at least log the tool versions though
11:04 < wumpus> (somewhere in the cache directory)
11:04 < cfields> well it should only be the toolchain, but i'm not sure we want to enumerate each binary that could change build output
11:04 < cfields> yes
11:05 < wumpus> I understand. Well maybe detection of every single tool change is too much work, but would be nice to have them somewhere to compare if something like this happens
11:05 < cfields> wumpus: did you have to update your base to change the result, or simply nuke the cache?
11:05 < wumpus> just the cache
11:06 < cfields> ok
11:06 < wumpus> the updates should happen automatically
11:06 < wumpus> (which can take a long time, especially with LXC, as it starts off with an image with ancient packages)
11:07 < wumpus> (but upgrades it before build every time)
11:08 -!- frankenmint [~frankenmi@174-25-38-39.ptld.qwest.net] has quit [Ping timeout: 272 seconds]
11:10 < cfields> right
11:11 < wumpus> so probably a *mingw* .deb upgrade happened in last week
11:12 < wumpus> probably yesterday
11:13 < wumpus> hm no we can't actually know for sure - I don't know when my last cache was built. But it can't be too long ago.
11:14 < wumpus> in any case: everyone should nuke cache and rebuild rc5
11:15 -!- Arnavion [arnavion@unaffiliated/arnavion] has quit [Quit: Arnavion]
11:15 < cfields> right
11:16 < cfields> i'll make the toolchain detection top priority. will try to pr something today, once i/we track down what actually changed
11:18 < wumpus> well top priority is getting rc5 out :) but yes would certainly be useful to have, even if it's just a dpkg -l >> $CACHEDIR   so that if something like this happens we can compare the package state under which the old and new cache was built
11:18 -!- Arnavion [arnavion@unaffiliated/arnavion] has joined #bitcoin-core-dev
11:19 < wumpus> because the caching right now  makes the list in the .assert only partially useful
11:20 < cfields> yes
11:20 < cfields> well
11:20 < cfields> i suppose we should rebuild everything, then. might not be mingw related
11:20 < cfields> doing osx now
11:21 < wumpus> ideally it would list the state under which the cache is built in the assert as well in a separate section, but that would require changes to gitian. In any case having these kind of things tracable would be great.
11:22 < wumpus> I don't see how it could be non mingw related
11:22 < wumpus> but sure, I'll try rebuilding linux and osx as well
11:24 < wumpus> if those differ it would make me even more interested in what changed
11:27 < cfields> wumpus: native_protobuf differs already for me. looks like it's system-wide
11:27  * wumpus gets his tinfoil hat
11:28 < cfields> haha
11:28 < wumpus> osx uses a compiler that isn't even part of an ubuntu package right?
11:29 < cfields> i had considered that, but dismissed it so far :)
11:29 < wumpus> I don't see how this is possible, I want to put 0.12.0 on hold until it is clear what causes this
11:29 < cfields> wumpus: yes, but it builds some native packages with the system toolchain first
11:30 < cfields> for ex: gcc builds protoc, which preprocesses, and apple-clang builds
11:30 < wumpus> but it build *our* protoc, it would be weird if the output of protoc changes based on what compiles it
11:30 < cfields> right
11:30 < wumpus> suspicious, even
11:30 < cfields> i only pointed out that native_protoc changed, not sure if it affects the end result
11:31 < cfields> (presumably that one wouldn't, as you said)
11:31 < wumpus> sure, let's hope for the best, I don't have build output either yet
11:31  * wumpus looking at asm difference 
11:32 < cfields> i can't really think of anything that would change the osx result, beyond a gcc change that would really be cause for alarm, enough to affect the behavior of the osx-binutils
11:33 < cfields> (cctools)
11:33 < cfields> brb
11:33 < wumpus> agreed. linux build difference could be explained by *both* a linux and mingw toolchain chainge, but macosx difference would be nearly impossible
11:34 < gmaxwell> lets hope the protobuff wasn't backdoored. :)
11:34 < wumpus> gmaxwell: in this case it would be the compiler that inserts a backdoor into protobuf </tinfoil hat mode> ;)
11:36 < wumpus> well the compiler would insert a backdoor into protoc, which generates C++ code with a backdoor, which gets compiled in. And it's sneaky enough to result in an executable of the same size with some bytes different. Nahh... ;)
11:44 < cfields> wumpus: the osx dmg result is the same, but the unsigned .tar.gz is different
11:44 < cfields> wumpus: notice also that the comparisontool is different, which is just one file stuffed into a tarball
11:45 < cfields> so i'm guessing it's either something related to file-ordering (no clue how), or something low-level like zlib
11:45 < wumpus> linux result stays the same for me *happy*
11:46 < wumpus> now building mac too, let's see if we at least get the same
11:46 < paveljanik> BTW - this week I have read something about ls changes - quoting of filenames with space, different ordering etc...
11:48 < wumpus> right, it wouldn't be impossible for a system tool like that to actually make a difference somewhere paveljanik
11:48 < cfields> crap, i've gtg. back in an hour or so
11:48 < cfields> wumpus: c427d4076e1827d5fd3d645d26f3e1504ffe8b53c33c559c5dc49605d0b10cbd  bitcoin-0.12.0-osx-unsigned.tar.gz
11:49 < wumpus> ok thanks, later
11:51 < paveljanik> wumpus, http://lists.gnu.org/archive/html/coreutils/2016-02/msg00000.html 
11:54 < paveljanik> ie. ls from coreutils 8.25. But I think this new version was not in your builds...
11:57 < wumpus> I doubt ubuntu stable will upgrade coreutils that soon, and AFAIK we don't use ls anywhere (at least directly), it's likely not that exact issue (but it could be a similar one)
12:01 -!- laurentmt [~Thunderbi@128-79-141-196.hfc.dyn.abo.bbox.fr] has quit [Quit: laurentmt]
12:01 < wumpus> f153f1555b60edd61fa57a9b2f6b43d8d6449fd5c0e6a4ef0f4ba745c6376566  bitcoin-0.12.0-osx-unsigned.tar.gz   didn't change for me cfields, osx output is the same
12:06 < wumpus> so that points at a mingw toolchain change, and only a mingw toolchain change only. Not sure what causes your .tar.gz difference, but if the dmg is the same at least the executable is the same.
12:13 < wumpus> from what I can see from the assembler difference it's exactly the same code, just using slightly different instructions to accomplish the same (e.g. mov shr and instead of testb setne). Typical of a compiler update.
12:14  * wumpus takes off his tinfoil hat and goes to bed
12:15  * Luke-Jr steals wumpus's tinfoil hat and runs away
12:16 < wumpus> hehe
12:27 < midnightmagic> yay other people having gitian problems besides me
12:27 < midnightmagic> I bet it's just because I do late gitian builds after you guys are all asleep
12:28 < midnightmagic> wumpus: but this sort of change makes it hard to reconstruct gitian sigs for earlier 0.12.0rc*
12:29 -!- treehug88 [~textual@static-108-30-103-59.nycmny.fios.verizon.net] has quit [Quit: Textual IRC Client: www.textualapp.com]
12:45 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-core-dev
12:47 < GitHub136> [bitcoin] knocte opened pull request #7528: autogen.sh: warn about needing autoconf if autoreconf is not found (master...warn-autoconf) https://github.com/bitcoin/bitcoin/pull/7528
12:51 < Luke-Jr> since when is ~/.bitcoin/testnet3/bitcoin.conf ignored and why?
12:52 < wumpus> midnightmagic: yes, the caching complicates that, as the package list in the assert is no longer that package state with which everything was built, that's why  isuggested above to also log that 
12:52 < wumpus> Luke-Jr: that's always been the case, there has never been support for per-chain config files
12:52 < Luke-Jr> also, is there any reason *not* to have regtest use non-testnet QSettings?
12:53 < Luke-Jr> (this means QApplication appname change)
12:53 < wumpus> I don't think regtest in the GUI is very well supported
12:53 < wumpus> it works, but probably there's some flukes here and there
12:53 < Luke-Jr> any complaint if I make it use its own appname/qsettings? :P
12:53 < wumpus> I don't really care, no
12:54 < wumpus> it's not something that affects end users
12:54 < wumpus> so if that makes testing easier why not
12:54 < Luke-Jr> well, IMO it's necessary for saving the network port number in QSettings
12:54 < Luke-Jr> (#7107)
12:54 -!- treehug88 [~textual@static-108-30-103-59.nycmny.fios.verizon.net] has joined #bitcoin-core-dev
12:54 < wumpus> just make sure it doesn't cause any other reversions, as we have hardly/none automatic tests for that stuff
12:55 -!- xabbix [~xabbix@unaffiliated/xabbix] has quit [Ping timeout: 260 seconds]
12:55 -!- treehug88 [~textual@static-108-30-103-59.nycmny.fios.verizon.net] has quit [Remote host closed the connection]
12:55 < Luke-Jr> does anything use appname besides qsettings?
12:55 -!- treehug88 [~textual@static-108-30-103-59.nycmny.fios.verizon.net] has joined #bitcoin-core-dev
12:56 < wumpus> I don't know by heart, I suppose qt docs can help you
12:56  * Luke-Jr shocked wumpus doesn't have the entire codebase memorised. :P jk
12:57 < wumpus> hey that's unfair it was a aquestion about upstream :P 
12:58 -!- xabbix [~xabbix@bzq-79-178-192-222.red.bezeqint.net] has joined #bitcoin-core-dev
12:58 -!- xabbix [~xabbix@bzq-79-178-192-222.red.bezeqint.net] has quit [Changing host]
12:58 -!- xabbix [~xabbix@unaffiliated/xabbix] has joined #bitcoin-core-dev
12:58 < midnightmagic> wumpus: apparently there is an effort in debianland to build an archival package-state database which can be used to sync to specific sets of packages.
12:58 < Luke-Jr> docs say it's just QSettings
12:58 < wumpus> I know most of the bitcoin core codebase in detail, though I sometimes get confused by the wallet and some of the mempool workings
12:58 < Luke-Jr> also, apparently it's read-only on Blackberry, but I don't know that we care
12:58 < wumpus> I doubt anyone cares about blackberry no :)
12:59 < wumpus> there's not even an android bitcoin core release, let alone blackberry
13:00 < Luke-Jr> wumpus: GreenBits apparently runs Bitcoin Core Daemon on Android these days
13:00 < Luke-Jr> (optionally)
13:00 < wumpus> nice. yeah it's certainly possible, I've heard people have done it before, though I don't think it's documented anywhere
13:01 < wumpus> probably overheats most phone CPUs, as well as wears out the flash tho :-)
13:24 -!- Nuief [~Nuief__@2001:1900:2104:2::86] has quit [Remote host closed the connection]
13:28 -!- Noice [~Noice__@2001:1900:2104:2::86] has joined #bitcoin-core-dev
13:31 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has quit [Ping timeout: 245 seconds]
13:37 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-core-dev
13:38 < warren> Luke-Jr: what?  full validation with pruning I'm guessig?
13:41 -!- paveljanik [~paveljani@unaffiliated/paveljanik] has quit [Quit: Leaving]
13:44 < morcos> So I've got a first pass at the feefilter idea coded up.  I was thinking I'd also write a BIP for it. But seems like there might be some discussion of the best way to implement the idea.
13:45 < morcos> Any suggestions as to whether I should just write the BIP and then have discussion, or show the code first or what?
13:45 -!- larsk [~l4rsk@50.248.81.65] has joined #bitcoin-core-dev
13:46 < Luke-Jr> warren: I assume
13:46 < Luke-Jr> morcos: ?
13:47 -!- Chris_Stewart_5 [~Chris_Ste@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has quit [Ping timeout: 272 seconds]
13:47 < morcos> Luke-Jr: The idea is that nodes can optionally broadcast a feefilter p2p message to let their peers know that their mempool is currently limited and they are not accepting txs below a certain feerate
13:48 < Luke-Jr> morcos: this idea that fees are the only relevant metric is troubling.
13:48 < morcos> This would save considerable network traffic in both invs that are never requested b/c they were previously rejected or requesting of txs that would fail due to insufficient fee
13:48 < Luke-Jr> "feerate" is not a well-defined term btw
13:48 < morcos> Well the idea I came up with is to make it optional
13:48 < Luke-Jr> Core uses a very subjective feerate that discounts part of the transaction, for example
13:49 < Luke-Jr> (ModSize)
13:49 < morcos> So that if you are a node that is implementing tx prioritization, then even if you have a limited mempool, you have to at least see the hash first b/c the feerate might get modified
13:49 < morcos> Luke-Jr: No, thats only for priority.  FeeRate uses actual tx size
13:49 < Luke-Jr> hm, it does?
13:49 < Luke-Jr> I wonder if it should
13:49 < morcos> It's a valid question
13:50 < morcos> Partialy answered by segwit
13:51 < Luke-Jr> anyway, it's something to consider in your idea
13:51 < morcos> The way I was looking at the feature is that if you are just a relay node and you're not doing anything special with regards to priority (which is probably a significant % of the nodes) then this will help cut down on bandwidth significantly
13:51 < morcos> If you are running different policy or are a miner and doing prioritization, then you just don't use it
13:52 < Luke-Jr> it may bias the network toward a specific policy, which would be bad
13:52 < morcos> If used properly it should basically have no effect other than cutting down on useless network traffic
13:53 < morcos> I don't see why it would bias the network more than already is the case.   
13:53 < Luke-Jr> hm, that's a point
13:53 < Luke-Jr> already there is lower bw use if you filter
13:54 < Luke-Jr> anyway, might make sense to abstract it a little at least
13:54 < Luke-Jr> eg, 1 byte for "feerate version" or smth
13:54 < Luke-Jr> (maybe varint)
13:55 < morcos> You mean have the p2p message be a bit more generic for future extension?
13:55 < Luke-Jr> perhaps some way to say "trickle non-matching transactions"?
13:55 < Luke-Jr> yes
13:55 < morcos> Sure seems reasonable
13:56 < morcos> Instead of FeeFilter 8byteFeeRate   It could be InvFilter 1byteType 8byteFeeRAte
13:56 < Luke-Jr> varints might be nicer for both fields.
13:57 < Luke-Jr> perhaps some way to say "trickle non-matching transactions"? <-- this would nicely fit in with rate-limited priority relaying
13:58 < Luke-Jr> (but perhaps not worth the implementation effort)
14:00 -!- gevs [~greg@unaffiliated/gevs] has quit [Ping timeout: 240 seconds]
14:01 < morcos> I'm not super familiar with the networking code, but seems like second data field type can depend on the content of the first data field.   But also its not clear that its worth the effort as opposed to just defining different message types for future filters
14:02 < morcos> Anyway, sounds like from you comments that perhaps a BIP would be a good next step
14:06 < Luke-Jr> morcos: well, I mean I expect the feerate to be small ;)
14:06 < Luke-Jr> no need to waste 8 bytes for 100000 when 2 is sufficient
14:06 < Luke-Jr> (or is it 3? not relevant) 
14:08 -!- treehug88 [~textual@static-108-30-103-59.nycmny.fios.verizon.net] has quit [Quit: Textual IRC Client: www.textualapp.com]
14:13 -!- gevs [~greg@unaffiliated/gevs] has joined #bitcoin-core-dev
14:16 < cfields> wumpus: https://lists.ubuntu.com/archives/trusty-changes/2016-February/021179.html
14:16 < cfields> got to be that
14:40 -!- skyraider_ [uid41097@gateway/web/irccloud.com/x-xonviuzbkgnvfxyu] has quit [Quit: Connection closed for inactivity]
15:01 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has quit [Quit: :)]
15:03 -!- frankenmint [~frankenmi@174-25-38-39.ptld.qwest.net] has joined #bitcoin-core-dev
15:09 -!- frankenmint [~frankenmi@174-25-38-39.ptld.qwest.net] has quit [Ping timeout: 264 seconds]
15:24 < degriff> QUIT
15:24 -!- degriff [~toutatis@rob76-4-82-238-176-192.fbx.proxad.net] has quit [Quit: degriff]
15:33 -!- adnn [~adnn@cpe-158-222-198-108.nyc.res.rr.com] has quit [Remote host closed the connection]
16:08 -!- bsm1175321 [~mcelrath@38.121.165.30] has quit [Ping timeout: 250 seconds]
16:34 -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has quit [Ping timeout: 250 seconds]
16:35 -!- gevs [~greg@unaffiliated/gevs] has quit [Remote host closed the connection]
16:38 -!- gevs [~greg@unaffiliated/gevs] has joined #bitcoin-core-dev
16:38 -!- bityogi [~textual@208-104-143-200.brvd.dsl.dyn.comporium.net] has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
16:42 -!- davec [~davec@cpe-24-243-251-52.hot.res.rr.com] has quit [Read error: Connection reset by peer]
16:43 -!- davec [~davec@cpe-24-243-251-52.hot.res.rr.com] has joined #bitcoin-core-dev
16:49 -!- gevs [~greg@unaffiliated/gevs] has quit [Remote host closed the connection]
16:50 -!- gevs [~greg@ip-62-235-46-198.dial.scarlet.be] has joined #bitcoin-core-dev
16:50 -!- gevs [~greg@ip-62-235-46-198.dial.scarlet.be] has quit [Changing host]
16:50 -!- gevs [~greg@unaffiliated/gevs] has joined #bitcoin-core-dev
17:03 -!- zooko [~user@2601:281:8001:26aa:ec69:bd00:eaae:53eb] has joined #bitcoin-core-dev
17:04 -!- lahwran is now known as lauren
17:10 -!- zooko [~user@2601:281:8001:26aa:ec69:bd00:eaae:53eb] has quit [Ping timeout: 240 seconds]
17:20 -!- Chris_Stewart_5 [~Chris_Ste@173-31-39-168.client.mchsi.com] has joined #bitcoin-core-dev
17:24 -!- raedah [~raedah@172.58.33.58] has joined #bitcoin-core-dev
17:30 -!- Chris_Stewart_5 [~Chris_Ste@173-31-39-168.client.mchsi.com] has quit [Ping timeout: 256 seconds]
17:48 -!- laurentmt [~Thunderbi@128-79-141-196.hfc.dyn.abo.bbox.fr] has joined #bitcoin-core-dev
17:52 -!- laurentmt [~Thunderbi@128-79-141-196.hfc.dyn.abo.bbox.fr] has quit [Client Quit]
17:58 < Luke-Jr> is it expected for valgrind to whine about libsecp256k1?
18:06 < gmaxwell> Luke-Jr: more details required?
18:07 < Luke-Jr> jumps based on uninit'd values
18:07 < gmaxwell> do you mean the tests? yes--- if it's compiled with openssl then openssl taints the whole thing with uninitilized random numbers.
18:07 < gmaxwell> Do you mean when compiled with clang?  yes-- clang violates the C-spec usage for libc and will generate memcpy calls on overlapping areas.
18:07 < gmaxwell> otherwise, no absolutely not.
18:09 < Luke-Jr> k
18:09 < Luke-Jr> (yes, it's with tests)
18:09 < gmaxwell> you can compile without openssl to make those go away.
18:09 < gmaxwell> I suppose I should make configure warn that this will happen.
18:09 < Luke-Jr> it wasn't enough to bother me, unless it was indicative of a problem
18:10 < gmaxwell> if you ever get code that has gone through my hands that emits valgrind warnings, please report.
18:11 < gmaxwell> as an aside, if you compile your openssl with -DPURIFY it will stop executing undefined behavior and causing spurrious valgrind warnings in callers.
18:38 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-htdsfbfrasriazqq] has quit [Quit: Connection closed for inactivity]
18:54 < Luke-Jr> ugh, why is descendantfees not called descendantmodfees? :/
18:54 < Luke-Jr> sdaftuar: ^
18:56 < sipa> gmaxwell: 
19:04 < GitHub67> [bitcoin] luke-jr opened pull request #7529: Bugfix: Rename descendantfees to descendantmodfees (master...bugfix_descendantfees) https://github.com/bitcoin/bitcoin/pull/7529
19:14 -!- frankenmint [~frankenmi@174-25-38-39.ptld.qwest.net] has joined #bitcoin-core-dev
19:20 -!- frankenmint [~frankenmi@174-25-38-39.ptld.qwest.net] has quit [Remote host closed the connection]
20:00 < gmaxwell> sipa: hm?
20:01 < sipa> gmaxwell: ?
20:01 < sipa> oh, i said something above
20:01 < sipa> crap, i don't even remember typing that
20:02 -!- jcorgan [~jcorgan@unaffiliated/jcorgan] has joined #bitcoin-core-dev
20:02 < Luke-Jr> lol
20:21 -!- frankenmint [~frankenmi@174-25-38-39.ptld.qwest.net] has joined #bitcoin-core-dev
20:27 -!- frankenmint [~frankenmi@174-25-38-39.ptld.qwest.net] has quit [Ping timeout: 252 seconds]
20:44 -!- p15x [~p15x@53.91.145.64.client.static.strong-tk2.bringover.net] has joined #bitcoin-core-dev
20:45 -!- brg444 [18257df2@gateway/web/freenode/ip.24.37.125.242] has joined #bitcoin-core-dev
21:07 -!- frankenmint [~frankenmi@174-25-38-39.ptld.qwest.net] has joined #bitcoin-core-dev
21:13 -!- binns_ [~wb@aura.trek.io] has joined #bitcoin-core-dev
21:13 -!- binns_ [~wb@aura.trek.io] has quit [Client Quit]
21:17 < warren> Anyone had trouble with gitian-builder precise amd64 recently?  It seems to install the VM just fine but it isn't bootable
21:17 -!- dermoth [~thomas@189-79.162.dsl.aei.ca] has quit [Ping timeout: 250 seconds]
21:28 -!- cj [~cjac@104.36.247.28] has joined #bitcoin-core-dev
21:34 -!- binns [~wb@21/bitcoin/binns] has quit [Ping timeout: 256 seconds]
21:41 -!- dermoth [~thomas@189-79.162.dsl.aei.ca] has joined #bitcoin-core-dev
21:46 -!- binns [~wb@21/bitcoin/binns] has joined #bitcoin-core-dev
21:52 < warren> hmm, seems to be an issuer with newer versions of gitian-builder.  older versions install a working VM but it gets stuck on ssh login due to some change elsewhere in the OS.  
21:52 < warren> "debug1: Skipping ssh-dss key ./var/id_dsa for not in PubkeyAcceptedKeyTypes"
22:02 -!- p15x [~p15x@53.91.145.64.client.static.strong-tk2.bringover.net] has quit [Ping timeout: 260 seconds]
22:05 < Luke-Jr> morcos: why does CTxMemPool::UpdateForDescendants seem to be backward? ie, it's updating fields that should be on ancestors..?
22:05 < Luke-Jr> warren: pseudo-fixed upstream, you need to redo the keying
22:06 < warren> Luke-Jr: yeah found that, using git bisect to figure out what else changed between March 2015 and December 2015 that broke the VM install
22:07  * Luke-Jr wonders why CTxMemPool code was rewritten obfuscated when there seems to be so many clearer possible ways to have done it :/
22:11 < phantomcircuit> Luke-Jr, because it's keeping track of the opposite thing from cpfp
22:11 < phantomcircuit> which ends up being weird
22:11 < Luke-Jr> phantomcircuit: yeah, but I mean it should be UpdateForAncestors?
22:11 < Luke-Jr> since it's updating the ancestor CTxMemPoolEntries
22:12 < Luke-Jr> this code is all so obfuscated, I'm about to just go back to writing less-than-optimal CPFP code
22:14 -!- zooko [~user@c-73-229-199-227.hsd1.co.comcast.net] has joined #bitcoin-core-dev
22:16 < Luke-Jr> or maybe I should just go update 0.11 :/
22:21 < warren> http://pastebin.com/eA2MmQ2j  Things break in the name of progress.
22:29 -!- adnn [~adnn@cpe-158-222-198-108.nyc.res.rr.com] has joined #bitcoin-core-dev
22:30 < Luke-Jr> warren: already PR'd a fix
22:38 -!- wallet42 [~wallet42@unaffiliated/wallet42] has joined #bitcoin-core-dev
22:45 -!- zooko [~user@c-73-229-199-227.hsd1.co.comcast.net] has quit [Ping timeout: 272 seconds]
23:37 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection]
23:38 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev
23:52 < wumpus> cfields: made a mistake yesterday in buildling linux and mac, did not properly wipe the cache. Trying again...
23:53 < cfields> wumpus: i just redid and got matches on both
23:53 < wumpus> good
23:53 < cfields> wumpus: if you don't match now, you're going to set my world on fire :p
23:53 < btcdrak> music!
23:56 < cfields> wumpus: ofc confirmation is most welcome. Still need another sig before signing though. After all that, I'm really not comfortable until we get 3rd party confirmation
23:56 < cfields> midnightmagic / michagogo / PRab:  ping ^^
23:57 < cfields> tl;dr: nuke cache, fresh base image, rebuild windows
23:57 < wumpus> cfields: yes, that must be it, and they upgraded the compiler for linux and mingw at the same time. I don't understand the macosx .tar.gz difference tho - does it contain a native executable somehow?
23:57 < wumpus> cfields: oh, you rebuilt linux and it still matched?
23:58 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-xwtfubermsxzlupv] has joined #bitcoin-core-dev
23:58 < cfields> wumpus: i must've not wiped properly
23:58 < wumpus> my build yesterday was done on the wrong circumstances so I can't confirm linux and macosx stay the same
23:58 < cfields> yikes, context needed there :)
23:58 < cfields> wumpus: 2 fresh builds tonight of osx/linux, and they matched
23:58 < wumpus> I apparently wiped the windows cache only :(
23:58 < wumpus> cfields: ok
23:59 < cfields> well, let's see how yours end up