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