< 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
< 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
< 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
< 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)
< 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
< 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>
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?