< bitcoin-git> [bitcoin] achow101 opened pull request #9500: [Qt][RPC] Autocomplete commands for 'help' command in debug console (master...help-rpc-autocomplete) https://github.com/bitcoin/bitcoin/pull/9500
< Lightsword> what conditions would cause me to hit this inconclusive for submitblock? https://github.com/bitcoin/bitcoin/blob/0.13/src/rpc/mining.cpp#L776
< luke-jr> Lightsword: block submitted is not on the longest chain, and therefore was not fully verified
< luke-jr> eg, stale block
< Lightsword> luke-jr, so it’s possible to hit that when doing a duplicate submit right?
< luke-jr> shouldn't be. duplicate is explicitly detected
< Lightsword> luke-jr, that’s what I thought…but seems you can get that from a duplicate…probably timing dependent
< luke-jr> oh, maybe if the duplicate is of an inconclusive block?
< luke-jr> eg, the first submit was inconclusive
< Lightsword> actually in this case the block first came in over p2p and was then submitted over the RPC at almost the exact same time
< luke-jr> that doesn't change much
< Lightsword> hmm, looks like the block came in over p2p in the middle of submitblock actually
< phantomcircuit> Lightsword, duplicate-inconclusive is a thing
< Lightsword> phantomcircuit, well duplicate-inconclusive was not what submit block returned, it returned a plain “inconclusive”
< phantomcircuit> that means the block wasn't already seen was accepted but is not in the main chain
< Lightsword> phantomcircuit, so that response is given after being accepted but before updatetip?
< phantomcircuit> Lightsword, a block can be accepted even if it doesn't update the tip iirc
< profall> I have an issue where my bitcoin core daemon goes out of sync for no reason at all. Plenty of peers and in a proper datacenter. It's a server with an E3 processor and 16GB of Ram, not a resource isssue.
< profall> It'll run for 24 or 36 hours on the correct block if you compare it in real-time to blockchain.info or wherever, then randomly it'll just stop syncing.
< phantomcircuit> profall, what version?
< profall> bitcoin-0.13.2-x86_64-linux-gnu.tar.gz right off the website.
< profall> (obviously extracted it...)
< phantomcircuit> bitcoin-cli getinfo how many peers?
< profall> 69
< phantomcircuit> profall, how far behind?
< profall> It'll go 50 blocks behind sometimes until I manually intervene. I simply stop bitcoind and start it again.
< profall> It'll resync right away.
< phantomcircuit> hmm
< profall> I mean, maybe the datacenter is having connection issues? It's like the only thing I can think of I guess ill put in a ticket.
< profall> Everything else works fine though on that server, so I feel like it's not related to the internet connection.
< phantomcircuit> uh
< phantomcircuit> is this by chance in the bay area
< profall> No
< phantomcircuit> BlueMatt, ^
< phantomcircuit> profall, if you run getpeerinfo is there one peer with a bunch of blocks in flight?
< Lightsword> phantomcircuit, so I guess when parsing submitblock responses inconclusive can potentially mean duplicate and that the tip just hasn’t updated yet?
< gmaxwell> profall: that is very interesting and unusual. Can you check the time on that host (including timezone)? Do you have a debug log covering one of these events?
< bitcoin-git> [bitcoin] MarcoFalke pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/07fd147b9f12...98c80e374b84
< bitcoin-git> bitcoin/master 7df5e38 Pavel Janík: Rename lambda argument name to prevent shadowing.
< bitcoin-git> bitcoin/master 98c80e3 MarcoFalke: Merge #9496: Rename lambda argument name to prevent shadowing...
< bitcoin-git> [bitcoin] MarcoFalke closed pull request #9496: Rename lambda argument name to prevent shadowing (master...20170109_Wshadow_rpcconsole_lambda) https://github.com/bitcoin/bitcoin/pull/9496
< bitcoin-git> [bitcoin] laanwj pushed 1 new commit to master: https://github.com/bitcoin/bitcoin/commit/68eb56203be17066af4e37837703490af4d4f40c
< bitcoin-git> bitcoin/master 68eb562 Wladimir J. van der Laan: qt: periodic translations update
< bitcoin-git> [bitcoin] laanwj pushed 14 new commits to master: https://github.com/bitcoin/bitcoin/compare/68eb56203be1...5754e0341b7c
< bitcoin-git> bitcoin/master 5865d41 Wladimir J. van der Laan: authproxy: Add support for RPC named arguments
< bitcoin-git> bitcoin/master 6f1c76a Wladimir J. van der Laan: rpc: Support named arguments...
< bitcoin-git> bitcoin/master 495eb44 Wladimir J. van der Laan: rpc: Named arguments for blockchain calls
< jonasschnelli> instagibbs: can you help me parsing your comment... :)
< jonasschnelli> (or anyone)
< jonasschnelli> I don't understand it
< instagibbs> jonasschnelli, in one commit you go from 0 internal to 50/50 external/internal, to 100/20
< instagibbs> in the next
< instagibbs> I just find that a bit odd
< jonasschnelli> Ah. The commit order...
< jonasschnelli> Yes. I force pushed it in a confusing way.
< instagibbs> yeah, not blocking, I just got confused when reviewing commit by commit
< instagibbs> I think logically it's not broken at any point
< jonasschnelli> I think I squash the commits.
< jonasschnelli> It's one single change
< instagibbs> is #9400 reasonable for 0.14? It's gotten decent amount of review, and is a pretty small change
< gribble> https://github.com/bitcoin/bitcoin/issues/9400 | Set peers as HB peers upon full block validation by instagibbs · Pull Request #9400 · bitcoin/bitcoin · GitHub
< * jonasschnelli> invites instagibbs to re-review #9294 (thanks!)
< gribble> https://github.com/bitcoin/bitcoin/issues/9294 | Use internal HD chain for change outputs (hd split) by jonasschnelli · Pull Request #9294 · bitcoin/bitcoin · GitHub
< instagibbs> well since you asked nicely
< jonasschnelli> Thanks for the review instagibbs: I owe you a review now!
< xinxi> cfields: ping. I have a question about codesigning binaries using gitian.
< cfields> xinxi: hi, shoot
< xinxi> ./bin/gbuild -i --commit signature=master ../litecoin/contrib/gitian-descriptors/gitian-win-signer.yml
< xinxi> --- Building for trusty amd64 ---
< xinxi> Stopping target if it is up
< xinxi> Starting target
< xinxi> Checking if target is up..............................
< xinxi> sudo: unknown user: ubuntu
< xinxi> sudo: unable to initialize policy plugin
< xinxi> ./bin/gbuild:21:in `system!': failed to run on-target true (RuntimeError)
< xinxi> from ./bin/gbuild:73:in `build_one_configuration'
< xinxi> from ./bin/gbuild:285:in `block (2 levels) in <main>'
< xinxi> from ./bin/gbuild:280:in `each'
< xinxi> from ./bin/gbuild:280:in `block in <main>'
< xinxi> from ./bin/gbuild:278:in `each'
< xinxi> from ./bin/gbuild:278:in `<main>'
< xinxi> [11:43]
< xinxi> I changed ubuntu -> debian
< xinxi> I got the above error when I was compiling Litecoin.
< cfields> xinxi: ahh, paste somewhere please!
< xinxi> oops
< cfields> xinxi: need to look at the log, the above doesn't tell much
< xinxi> where is the log? no path is shown above.
< cfields> xinxi: ./var/build.log
< xinxi> there is only var/install.log
< xinxi> but it seems not relevant.
< achow101> that means that the build hasn't started yet and it was still updating stuff
< cfields> xinxi: wait, why did you change ubuntu -> debian?
< cfields> xinxi: unknown ubuntu user seems relevant in that case :)
< xinxi> I am compiling on debian.
< xinxi> let me change back.
< cfields> xinxi: doesn't matter, this is creating a vm for you
< xinxi> I just changed back and am compiling again. it seems a bit different now.
< btcdrak> xinxi: use pastebin/0bin please
< xinxi> yeah, just noticed it. sorry about that.
< xinxi> cfields: got a new error: http://pastebin.com/JA4rtscY
< cfields> xinxi: have you signed the binaries and created detached sigs?
< xinxi> yeah, I have.
< xinxi> I got the .assert and .assert.sig files.
< cfields> xinxi: since this isn't bitcoin related, let's go to pm
< instagibbs> 0.13.1 and other NODE_WITNESS only ask for txn from witness peers, right?
< sipa> instagibbs: i don't think so, but i forget
< phantomcircuit> cfields, on 9441 the indentation in ba4cae284f6acac4bbbfe08c89dcb8c2ace5da83 is screwed
< cfields> phantomcircuit: yea, i left the indentation alone, otherwise the diff would've been a bloodbath
< cfields> i'll do a whitespace follow-up
< phantomcircuit> cfields, also please use {} for all if statements
< phantomcircuit> kind of makes indentation issues less relevant
< phantomcircuit> the way it is now it looks like nothing will ever run because of the indentation
< cfields> phantomcircuit: fair enough. where in particular?
< phantomcircuit> the fDisconnect check mainly
< phantomcircuit> also probably swap the fDisconnect and !vRecvGetData.empty() checks since ProcessGetData can set fDisconnect
< phantomcircuit> (left these comments on github too)
< cfields> phantomcircuit: ah, they make more sense in context. thanks :)
< phantomcircuit> cfields, it seems like we should disconnect on checksum and header validation issues actually
< phantomcircuit> (we currently ignore them and go to the next message)
< cfields> phantomcircuit: there are several things that should change about the behavior there, but i tried to leave as much alone as i could for this PR
< phantomcircuit> alright
< phantomcircuit> i'll refrain
< cfields> phantomcircuit: agreed ofc, btw
< bitcoin-git> [bitcoin] jonasschnelli opened pull request #9502: [Qt] Add option to pause/resume block downloads (master...2017/01/autodownload) https://github.com/bitcoin/bitcoin/pull/9502
< instagibbs> sipa, oh right, definitely not the case since they wont relay non-std txns in general
< sipa> indeed
< jtimon> BlueMatt: it seems #9486 could use a better description, the description seems to only talk about the last commit, which seems trivial and overall unrelated to the rest, certainly I'm missing something
< gribble> https://github.com/bitcoin/bitcoin/issues/9486 | Make peer=%d log prints consistent by TheBlueMatt · Pull Request #9486 · bitcoin/bitcoin · GitHub
< sdaftuar> jtimon: see #9375
< gribble> https://github.com/bitcoin/bitcoin/issues/9375 | Relay compact block messages prior to full block connection by TheBlueMatt · Pull Request #9375 · bitcoin/bitcoin · GitHub
< sipa> jtimon: from the description "Based on #9375"
< gribble> https://github.com/bitcoin/bitcoin/issues/9375 | Relay compact block messages prior to full block connection by TheBlueMatt · Pull Request #9375 · bitcoin/bitcoin · GitHub
< sipa> ah, sdaftuar beat me
< jtimon> yeah, thanks, reading now, read that and then forgot and tried to exact the leitmotiv from looking at the commits
< jtimon> does https://github.com/bitcoin/bitcoin/pull/9486/commits/e6111b2398ca21f0e38333236abb0be7fa48c95f really need to be based on #9375 ? it seems it could be trivially merged independently
< gribble> https://github.com/bitcoin/bitcoin/issues/9375 | Relay compact block messages prior to full block connection by TheBlueMatt · Pull Request #9375 · bitcoin/bitcoin · GitHub
< bitcoin-git> [bitcoin] JeremyRubin opened pull request #9503: listreceivedbyaddress Filter Address (master...listreceivedbyaddress-filtered) https://github.com/bitcoin/bitcoin/pull/9503
< bitcoin-git> [bitcoin] achow101 opened pull request #9504: [RPC] dumpmasterprivkey command (master...dumpmasterprivkey) https://github.com/bitcoin/bitcoin/pull/9504
< BlueMatt> gmaxwell: heh, yea, so extra is worth it as-is, will push the use-less-memory thing for 0.15?
< gmaxwell> BlueMatt: seems like it.
< BlueMatt> cool
< bitcoin-git> [bitcoin] JeremyRubin opened pull request #9505: Prevector Quick Destruct (master...prevector-quick-destruct) https://github.com/bitcoin/bitcoin/pull/9505
< bitcoin-git> [bitcoin] sipa opened pull request #9506: RFC: Improve style for if indentation (master...newstyle) https://github.com/bitcoin/bitcoin/pull/9506
< bitcoin-git> [bitcoin] sdaftuar opened pull request #9507: Fix use-after-free in CTxMemPool::removeConflicts() (master...fix-mempool-useafterfree) https://github.com/bitcoin/bitcoin/pull/9507
< bitcoin-git> [bitcoin] practicalswift opened pull request #9508: [gardening] Remove unused Python imports (master...remove-unused-python-import) https://github.com/bitcoin/bitcoin/pull/9508
< bitcoin-git> [bitcoin] theuni opened pull request #9509: build: fix qt distdir builds (master...out-of-tree-build) https://github.com/bitcoin/bitcoin/pull/9509
< instagibbs> what's the functional/use difference between CCoinsViewCache::GetCoins and CCoinsViewCache::AccessCoins?
< sipa> the latter is much faster
< sipa> as it doesn't copy
< sipa> so why would you use the first? AccessCoins only exists in CCoinsViewCache, while GetCoins exists in every CCoins implementation
< sipa> *every CCoinsView
< instagibbs> thanks, let me see if that explains its various uses to me
< bitcoin-git> [bitcoin] practicalswift opened pull request #9510: [gardening] Fix typos in comments (master...fix-typos-in-comments) https://github.com/bitcoin/bitcoin/pull/9510
< bitcoin-git> [bitcoin] morcos opened pull request #9511: Don't overwrite validation state with corruption check (master...ATMPstate) https://github.com/bitcoin/bitcoin/pull/9511
< gmaxwell> sipa: BlueMatt has a nit on #9472
< gribble> https://github.com/bitcoin/bitcoin/issues/9472 | Disentangle progress estimation from checkpoints and update it by sipa · Pull Request #9472 · bitcoin/bitcoin · GitHub
< BlueMatt> are we gonna try to merge that for 14 too?
< gmaxwell> sure, it's done its ... has about zero potential to break anything.
< sipa> it would be nice to say that we're only using checkpoints for avoiding a memory-bloating low-difficulty header attack
< sipa> it would be even nicer to say we're not using them at all anymore
< gmaxwell> yes, well... we could have been there, but
< gmaxwell> I don't have a solution for that which doesn't need something which is technically a consensus rule change.
< gmaxwell> oops wrong commit
< bitcoin-git> [bitcoin] sipa opened pull request #9512: Fix various things -fsanitize complains about (master...sanitize) https://github.com/bitcoin/bitcoin/pull/9512
< dcousens> can prioritisetransaction work on txids that aren't yet in the mempool?
< dcousens> I assume no, in which case, it might an idea to allow that as an option or maybe allow sendrawtransaction to have a feedelta field?
< dcousens> (uh, a 'virtual fee' field)
< sipa> yes, it can
< dcousens> sipa: awesome :)
< gmaxwell> dcousens: it writes it into mapDeltas.