< gmaxwell> phantomcircuit: I hate to expand your patch, but in net.h there is a comment about fRelay which you should probably revise slightly to make it sound like until a filter load isn't the only use.
< phantomcircuit> gmaxwell, oh the humanity!
< phantomcircuit> gmaxwell, ok comment changed
< phantomcircuit> gmaxwell, i couldn't figure out a sane way to use the constant (which is defined in main.h) in net.cpp
< sipa> phantomcircuit: pass that true/false based on blocksonly as a parameter to PushVersion
< phantomcircuit> sipa, PushVersion is called from the constructor of CNode::CNode
< phantomcircuit> er from...
< phantomcircuit> words
< sipa> aaargh
< phantomcircuit> lol yeah that's why i just gave up and left it as a constant constant
< sipa> can you ehm... add an Start method to CNode or so?
< gmaxwell> it what?
< phantomcircuit> sipa, the "clean" way is to add a fVersionSent flag and then check that in SendMessages
< phantomcircuit> you wont send anything until you get a verack anyways
< * phantomcircuit> lols at CNode flags
< dcousens> #d
< dcousens> nvm
< dcousens> anyone here use any blockchain analyser tools?
< dcousens> sorry, will go to bitcoin-dev
< petertodd> CodeShark: lol, and now you made me realise gmaxwell could equally be talking about my MMR ideas - the reinvention cycle just went meta full circle!
< jcorgan> /cl
< gmaxwell> is someone going to update univalue in master?
< * Luke-Jr> wonders if we should increase the number of blocks for Core wallet to consider transactions confirmed.
< gmaxwell> oh wow, intel mpx when used changes the ABI and makes all pointers bounds checked.
< Luke-Jr> gmaxwell: 128-bit wide?
< gmaxwell> no, it's done in an odd way that makes mixed systems possible.
< gmaxwell> basically there is a seperate bounds table. though dealing with it is still part of the abi.
< Luke-Jr> oh nice, compiling with MPX gracefully noops on old CPUs
< CodeShark> if I whitelist a node, other than network/transport issues or misbehaving, is there ever any conceivable situation where the node could get disconnected by bitcoin core
< CodeShark> ?
< CodeShark> actually, even in the event of misbehaving
< cfields> gitian-builders: 0.11.2 detached sigs are pushed
< cfields> 0.10.4 is waiting on one more match
< fanquake> WIll push up shortly
< fanquake> mich is the only one so far?
< cfields> his and mine
< cfields> er.. i forgot to push
< cfields> ok, done
< fanquake> ok, signed sigs PR'd
< fanquake> will build 0.10.4
< fanquake> hopefully for the last time..
< Luke-Jr> I wish gitian had a way to pull the yml from the git repo directly, so I didn't need to close out my main git working dir just to build..
< fanquake> cfields pushed 0.10.4 sigs
< cfields> fanquake: great, thanks! all matches. Pushing up the 10.4 detached sig now
< fanquake> cfields great. Sigs PR'd
< cfields> fanquake: thanks a bunch. Off to bed now
< sipa_> Luke-Jr: you can, i forget how
< Luke-Jr> !
< sipa_> i wrote a patch for that years ago, which i kept using, but it isn't necessary anymore
< gmaxwell> So sipa updated this PR https://github.com/bitcoin/bitcoin/pull/6983 but I can't figure out what changed
< sipa_> gmaxwell: i rebased it
< sipa_> it conflicted with the PIE change in Makefile.am
< sipa_> only the full validation pull conflicted, but Ibdidn't bother looking and rebased both
< BlueMatt> jonasschnelli's pgp key isnt signed at all :(
< wumpus> we should definitely change that
< BlueMatt> where in .ch is jonasschnelli anyway? could probably go meet up with sipa, if no one else
< CodeShark_> in europe, nothing is very far away (except russia) :p
< wumpus> he has met up with sipa a few times IIRC
< wumpus> and he was in Montreal. I can confirm jonasschnelli is a real person :p
< BlueMatt> wumpus: yes, he was around then
< sipa_> BlueMatt: not in Zurich
< CodeShark_> there are counties in california with a bigger area than switzerland :p
< CodeShark_> or at least one county
< CodeShark_> san bernadino county is larger than switzerland by area
< CodeShark_> incidentally, san francisco is the smallest county in california by area
< GitHub86> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/38ed190eefcc...24c4841d1686
< GitHub86> bitcoin/master 01afa80 Wladimir J. van der Laan: doc: Remove mention of pulltester from README.md...
< GitHub86> bitcoin/master 24c4841 Wladimir J. van der Laan: Merge pull request #6998...
< GitHub153> [bitcoin] laanwj closed pull request #6998: doc: Remove mention of pulltester from README.md (master...2015_11_readme_pull_pulltester) https://github.com/bitcoin/bitcoin/pull/6998
< GitHub28> [bitcoin] laanwj opened pull request #7003: doc: Add non-style-related development guidelines (master...2015_11_development_guidelines) https://github.com/bitcoin/bitcoin/pull/7003
< fanquake> Looking forward ot being able to attend one of the meetups some day
< wumpus> where are you based fanquake?
< fanquake> Western Australia
< fanquake> To far away from everywhere
< wumpus> whoa, you could say so :)
< wumpus> development is pretty distributed over the world as it is, that's nice
< fanquake> Yea, even inside West Aus, I used to live on a farm 100km from the nearest city.
< fanquake> So building precision agriculture software atm.
< fanquake> Only place we wouldn't have a developer might be in asia?
< jonasschnelli> BlueMatt: yes. I need to get my gpg key signed... will try to get some signatures within the next days.
< wumpus> cool. I think agriculture is one place where software can still change a lot
< wumpus> did you see my PM about gpg keys jonasschnelli?
< fanquake> absolutely, the adoption cycle is quite slow also, lots of oppoutunity for innovation.
< wumpus> no I don't think we have anyone in Asia, maybe some drive-by contributores but no one who stuck around
< GitHub106> [bitcoin] jonasschnelli opened pull request #7004: update jonasschnellis gpg key (master...2015/11/signing_key_jonasschnelli) https://github.com/bitcoin/bitcoin/pull/7004
< sdaftuar> \
< Luke-Jr> jonasschnelli: why a new key? :/
< michagogo> Hm, the signer failed on 0.11.2
< wumpus> michagogo: what error?
< michagogo> tar: signature/osx: Cannot read: Is a directory
< michagogo> Maybe it's because I just signed 0.10.4
< wumpus> weird - are you using the commands from the right build process, and descriptors from the right version?
< michagogo> I rm'd the flag file that tells my script it can reuse the existing target for the mac signer, rerunning now
< michagogo> I should be -- I have a script that does all that
< michagogo> (checks out the tag, etc)
< michagogo> And yeah, I have separate versions for 0.10 and 0.11
< Luke-Jr> sdaftuar: where is the debug file for the test?
< michagogo> (I probably could have made it one script, but I was lazy/in a hurry when I made it)
< michagogo> Anyway, it's running again now with a fresh vm
< wumpus> yes I have a series of scripts for those things too, lots of subtle differenes
< michagogo> Hm, wt
< michagogo> f
< michagogo> OH
< michagogo> wait
< * michagogo> check something
< michagogo> checks*
< * wumpus> blames his lack of ruby chops for, instead of attacking gitian directly, writing tons of wrapper scripts around it :-)
< michagogo> Dammit
< michagogo> The 0.10 build clobbered the 0.11 unsigned package
< michagogo> Got a copy? (don't worry, I'll check the hash)
< wumpus> hm not sure I don't have it anymore, which one do you need mac or win or both?
< michagogo> Mac
< michagogo> (we don't do detached win signing for 0.10, thankfully)
< michagogo> fanquake: around?
< michagogo> Do you have a copy of the 0.11.2 Mac unsigned tarball?
< michagogo> I wish the way gitian did inputs didn't force us to have unversioned filenames
< wumpus> agreed
< Luke-Jr> michagogo: eh, they're not unversioned
< wumpus> would be nice to fix some long-running complaints about how gitian handles things some time (also the "output files are nuked" on next run), if I wasn't already completely overloaded
< wumpus> Luke-Jr: not al, but the intermediate files for signing have to be
< michagogo> bitcoin-osx-unsigned.tar.gz
< Luke-Jr> the file gitian generates is bitcoin-0.11.2-osx-unsigned.tar.gz
< michagogo> The input is unversioned
< wumpus> Luke-Jr: you're right
< michagogo> Maybe I could move the unsigned bundle,
< wumpus> but to copy it into inputs, it needs to be made unversions
< michagogo> And then copy it to the generic name prebuild
< michagogo> That would probably work, actually
< wumpus> 0.11.2 binaries are live: https://bitcoin.org/bin/bitcoin-core-0.11.2/
< Luke-Jr> wumpus: ! but we don't have 3 sigs yet
< Luke-Jr> (on the signed bins, that is)
< wumpus> OK, won't do the official announcement (and merge it on the site) yet, then
< michagogo> Luke-Jr: we will momentarily
< michagogo> (Thanks, grabbed the unsigned bundle)
< michagogo> wumpus: you could kick off the Travis rebuild on the PR for the site
< wumpus> still have to fill in the torrent magnet link anyhow
< michagogo> wumpus: can do that after
< michagogo> Uh, wtf?
< michagogo> gzip: stdin: not in gzip formal
< michagogo> Format
< * michagogo> checks something
< michagogo> Hmm.
< michagogo> Oh, that was me being stupid
< * michagogo> sighs
< michagogo> I took the dmg instead of the tarvall
< midnightmagic> :-/
< midnightmagic> my gitian sigs aren't matching up anymore.
< midnightmagic> but I have to go to bed, so I'll debug it tomorrow.
< michagogo> Okay, THIS time it should work
< * michagogo> points at the PR page
< GitHub22> [bitcoin] laanwj pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/24c4841d1686...d2e987aa1929
< GitHub22> bitcoin/master b27e81f MarcoFalke: [net] Cleanup maxuploadtarget...
< GitHub22> bitcoin/master 9c3ee3b MarcoFalke: [doc] Add -maxuploadtarget release notes
< GitHub22> bitcoin/master d2e987a Wladimir J. van der Laan: Merge pull request #6958...
< GitHub8> [bitcoin] laanwj closed pull request #6958: [trivial] Cleanup maxuploadtarget (doc & log) (master...MarcoFalke-2015-maxupload) https://github.com/bitcoin/bitcoin/pull/6958
< michagogo> Merged \o/
< wumpus> yes, sent announcement mail
< michagogo> Erm, oops, forgot the website doesn't update in realtime
< wumpus> takes a few minutes at most
< wumpus> site is updated
< michagogo> Are you opped in #bitcoin?
< michagogo> (for the topic)
< michagogo> wumpus: hm, my torrent client is telling me the demonii tracker doesn't exist
< wumpus> "Seeding to 0 of 0 peers" hmm maybe the torrent tracker needs some time to spin up too
< wumpus> and all the trackers except tracker.coppersurfer.tk give me "Connection failed"
< fanquake> wumpus Who should be adding their key to trusted-keys?
< wumpus> fanquake: people that merge things
< fanquake> Is Jonass being given GH merge access?
< wumpus> yep
< jonasschnelli> [12:41:14] <Luke-Jr>jonasschnelli: why a new key? :/ <-- the new key is not really new, It's just the one that I use for bitcoin-dev posts, etc. The "old" key is used for non-bitcoin software-projects (and sadly, i have used it for gitian signatures)
< sdaftuar> Luke-Jr: around?
< GitHub147> [bitcoin] jgarzik opened pull request #7005: Add MAINTAINERS file, a user guide to code subsystems (master...2015_maintainer) https://github.com/bitcoin/bitcoin/pull/7005
< GitHub21> [bitcoin] jonasschnelli opened pull request #7006: [Qt] add startup option to reset Qt settings (master...2015/11/qt_resetsettings) https://github.com/bitcoin/bitcoin/pull/7006
< GitHub104> [bitcoin] sipa pushed 4 new commits to master: https://github.com/bitcoin/bitcoin/compare/d2e987aa1929...4f09b77c7fa5
< GitHub104> bitcoin/master 1d84107 Pieter Wuille: Squashed 'src/secp256k1/' changes from 22f60a6..2bfb82b...
< GitHub104> bitcoin/master 9e475d5 Pieter Wuille: Update libsecp256k1
< GitHub104> bitcoin/master 48edf57 Pieter Wuille: Update key.cpp to new secp256k1 API
< GitHub8> [bitcoin] sipa closed pull request #6983: Update libsecp256k1 (master...secp256k1new) https://github.com/bitcoin/bitcoin/pull/6983
< GitHub75> [bitcoin] morcos opened pull request #7007: Fix bug in unit mempool_tests unit test (master...unitTestBugFix) https://github.com/bitcoin/bitcoin/pull/7007
< GitHub121> [bitcoin] morcos opened pull request #7008: Lower bound priority (master...lowerBoundPriority) https://github.com/bitcoin/bitcoin/pull/7008
< morcos> Luke-Jr: When you get a chance, please see #7008. I think you had indicated that if at least originally in chain inputs age, that would be close enough. Upon further reflection, I think this is a much better compromise than trying to put through the full #6357 dynamic priority calculation. (it's basically a small subset)
< wumpus> jonasschnelli: you can set the 'GUI' label yourself now :) say on https://github.com/bitcoin/bitcoin/pull/7006
< jonasschnelli> wumpus: hah. Right. I missed that. Done!
< btcdrak> sipa: wonderful!
< GitHub165> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/4f09b77c7fa5...d3565604e3d9
< GitHub165> bitcoin/master a78e6ea Alex Morcos: Fix bug in mempool_tests unit test
< GitHub165> bitcoin/master d356560 Wladimir J. van der Laan: Merge pull request #7007...
< GitHub155> [bitcoin] laanwj closed pull request #7007: Fix bug in mempool_tests unit test (master...unitTestBugFix) https://github.com/bitcoin/bitcoin/pull/7007
< Luke-Jr> sdaftuar:
< sdaftuar> Luke-Jr: i wanted to follow up on the issue you reported with that bip65-cltv-p2p test this morning. i updated the issue with my observations
< Luke-Jr> k, catching up on emails now, so I haven't seen it yet
< Luke-Jr> sdaftuar: I don't have any env vars set related to Bitcoin
< sdaftuar> odd. any ideas why it's running the wrong binary?
< Luke-Jr> maybe because the build never puts bitcoind in the checkout dir..
< Luke-Jr> why is that the default?
< sdaftuar> er, i think i meant checkout-dir/src
< sdaftuar> anyway not sure, that's how all the rpc tests have ever worked as far as i know
< Luke-Jr> well, setting BITCOIND to $PWD/src/bitcoind fixes it
< sdaftuar> ok cool
< sdaftuar> oh -- i think you're supposed to run the rpc-tests from the rpc-tests directory. does that also fix it?
< * Luke-Jr> waits for his new build to finish to test that
< GitHub138> [bitcoin] gmaxwell pushed 1 new commit to master: https://github.com/bitcoin/bitcoin/commit/dbd2c135ddb96bdc3a4e870c2371cb1fac227135
< GitHub138> bitcoin/master dbd2c13 Gregory Maxwell: Merge pull request #6990...
< GitHub117> [bitcoin] gmaxwell closed pull request #6990: http: speed up shutdown (master...2015_11_threadexit) https://github.com/bitcoin/bitcoin/pull/6990
< gmaxwell> Is the torcontrol port password basically ever empty?
< morcos> I asked this in bitcion-mining but got no response. I'm 95% sure this couldn't have been caused by my changes to CreateNewBlock, but of the 20 testnet blocks I mined, one was invalid
< morcos> ERROR: CheckBlock(): hashMerkleRoot mismatch
< morcos> Anybody have any idea why that might have happened?
< morcos> It was invalid after being submitted by the miner, not in the TestBlockValidity from CreateNewBlock
< gmaxwell> eerk
< morcos> yeah thats kind of my response
< gmaxwell> Not a known behavior. Possibly that the transmission from the miner got truncated?
< gmaxwell> phantomcircuit: seen anything like that? ^
< GitHub157> [bitcoin] petertodd opened pull request #7010: Fix fundrawtransaction handling of includeWatching (master...2015-11-fix-fundrawtransaction-bugs) https://github.com/bitcoin/bitcoin/pull/7010
< phantomcircuit> morcos, what where you using to mine?
< morcos> phantomcircuit: antminer s7
< kanzure> BlueMatt: strange that fundrawtransaction with watchonlys/includewatching has been so difficult to get correct
< kanzure> BlueMatt: maybe we're trying to stuff too much into that function
< phantomcircuit> morcos, what stratum software?
< phantomcircuit> unless you were running bfgminer w/ getblocktemplate you need something else in the middle
< BlueMatt> kanzure: hmm? the latest bugs have been in the rpc wrapper for the function
< morcos> phantomcircuit: i was using the installed cgminer 4.8 to connect directly to bitcoind
< BlueMatt> kanzure: the actual function was rather doable
< kanzure> BlueMatt: well, ok. fair. comment rescinded.
< morcos> it seems to support getblocktemplate
< BlueMatt> kanzure: and, really, there's only been one actual bug? (the assume-if-argument-bool-is-true)
< phantomcircuit> morcos, i doubt very much that cgminer correctly implements getblocktemplate
< kanzure> BlueMatt: the previous implementation had some issues too. but your version fixed those.
< kanzure> BlueMatt: but yes your point about the rpc wrapper is sufficient to explain this.
< gmaxwell> phantomcircuit: would be useful to know how it doesn't assuming it doesn't.
< morcos> phantomcircuit: ok... maybe i'll stick some stratum software in the middle then and try that instead. what would you recommend
< gmaxwell> phantomcircuit: not just cgminer but whatever is on the miner, dunno about s7 but prior ones have all been really old versions.
< phantomcircuit> morcos, need a tcpdump of the rpc calls to diagnose
< phantomcircuit> morcos, eloipool
< BlueMatt> kanzure: yea, the previous version did, but thats what code review is for :) (it forces us to not implement hacky things and to do it The Right Way (tm) so that we fix subtle bugs)
< morcos> phantomcircuit: i was trying to play around with that, and the debugging from cgminer is either a flood or nothing useful. now i'm hacking up bitcoind to try to just dump any submitted blocks anyway, so if it happens again i can manually inspect the block
< morcos> for what its worth, it mostly seems to mine fine
< Luke-Jr> morcos: cgminer's GBT "support" is /probably/ broken
< gmaxwell> morcos: might be a worthwhile thing to just support as an option. savesubmitblocks=1
< Luke-Jr> morcos: I'd suggest BFGMiner over Eloipool FWIW
< phantomcircuit> morcos, to debug i'd also need the block templates though, so a tcpdump would be best
< morcos> gmaxwell: ha ha, well i'll let someone else write that, my version has already coredumped a few times
< morcos> phantomcircuit: ok, well its not happening often enough for that right now.. maybe i'll hack up something to decrease the difficulty or do somehting on regtest, but at this point its all going to have to wait for next week
< morcos> thanks for your help... i'll ping you when i have more info. also. stop orphaning my testnet blocks!
< phantomcircuit> morcos, ha
< phantomcircuit> an excellent demonstration of what low block intervals do to centralization :P
< GitHub38> [bitcoin] petertodd opened pull request #7011: Add mediantime to getblockchaininfo (master...2015-11-add-mediantime-to-getblockchaininfo) https://github.com/bitcoin/bitcoin/pull/7011
< morcos> Luke-Jr: any chance you got to look at 7008?
< morcos> I'm hoping you are ok with closing the dynamicPriority pull (6357) and focusing attention on something more likely to be ok with everyone
< Luke-Jr> morcos: not planning to, as I strongly prefer #6357
< phantomcircuit> CodeShark, can you comment on issue 7012 ?
< morcos> Luke-Jr: hmm, ok then maybe i misunderstood you the other day
< Luke-Jr> morcos: I may have said something suggesting this, before I understood 6357 to be inexpensive
< morcos> I thought you did not like using starting priority as an approximation, but that you thought priority where aging did happen but only affected originally confirmed inputs was ok
< Luke-Jr> morcos: it's okay, if the alternative is expensive.
< Luke-Jr> but if it's not expensive, there is no reason to cheat on it
< morcos> Luke-Jr: well fundamentally part of my problem is just merge conflicts
< morcos> I want to fix the issue you pointed out with sigops having a default value
< morcos> but both priority pulls and sdaftuars mempool reorg pull all change the signature of TxMemPoolEntry constructor
< Luke-Jr> morcos: my plan right now, is to deep-review 6357 and write tests (unless you get to that first)
< morcos> 6357 is tested by having the priority recalced in mempool.check
< morcos> but yes more tests couldn't hurt
< Luke-Jr> morcos: I mean unit tests
< Luke-Jr> something Travis will detect breaking
< morcos> If I rebased 6357 on top of 7008, would you be willing to get 7008 merged. its really a precursor anyway, and the change to the constructor is the same.
< morcos> i'm going away at the end of next week, and i need to get all these merge conflicts sorted so we can get the createnewblock pull merged
< morcos> i'm perfectly happy with 6357, but lets not let the perfect be the enemy of the good.. getting 7008 in at least lets us do everything else. if we also get 6357, then great. but we haven't held up progress
< GitHub74> [bitcoin] petertodd opened pull request #7013: Remove LOCK(cs_main) from decodescript (master...2015-11-remove-cs-main-from-decodescript) https://github.com/bitcoin/bitcoin/pull/7013
< Luke-Jr> morcos: I'm not willing to ACK the createnewblock pull until 6357 is merged, so I'm not sure what the point is.
< Luke-Jr> rebasing 6357 on top of 7008 may be better just structually though
< morcos> Luke-Jr: I'm not sure whether or not 6357 will get merged. If not, the original plan was to put createnewblock pull back to the way I first had it. so it still calls the CCoinsViewCache GetPriority function which is right but slow.
< morcos> this will preserve the ability to do old policy, but limit a significant part of the speed up to code that does not use that policy
< morcos> to be clear, i'm happy for you or anyone else to appropriate the pulls and do the right thing, but i won't be around to make the changes past the first 4 days of next week
< morcos> so i'd like to leave things in the most likely to be merged state before that point.
< Luke-Jr> morcos: maybe push branches for each possibility, and I'll do what I can to keep things moving?