< praxeology>
Canoe was like the last significant hashpower miner hold out on signaling... so it might be a full day or more before someone makes a non-segwit signaling block
< achow101>
praxeology: their stratum had segwit this morning, but they were not mining segwit block for some reason.
< achow101>
we contacted them and it looks like they fixed it afterwards
< praxeology>
unless... someone does it on purpose to test it and potentially waste $39,000
< btcdrak>
I emailed Canoe and Connect this morning. Connect immediately updated their Stratum
< gmaxwell>
btcdrak: it's interesting that their public stratum was already okay.
< btcdrak>
gmaxwell: maybe they have a private mine, or VIP pool for special customers?
< gmaxwell>
ya, I'm sure it was something like that.
< praxeology>
maybe... their private server runs a different algorithm
< praxeology>
*private server farm
< BlueMatt>
praxeology: full day? prob closer to 2
< BlueMatt>
achow101: looks like they fixed it china-morning today
< BlueMatt>
gmaxwell: (almost all pools have "VIP" stratum endpoints they set up when asked if you have lots of hashrate, so thats not strange)
< achow101>
BlueMatt: I noticed
< gmaxwell>
btcdrak: I see miners still setting 4, this is going to cause segsignal and btc1 to throw warnings.
< achow101>
I just looked into the second 1hash invalid block and it looks like the transaction with missing inputs actually has its parent transaction farther down in the block
< praxeology>
achow101: oh really? as in maybe mid-tree nodes had been swapped?
< achow101>
arubi: 7a122ef22468e4af16b010d7acf7aa81e5af3636423c613fd98246c179d79800 is the child, parent is 9639dd073e67efc879abb1075fafa4fa23d5fa427c129b2b1dd4f5a5520b408d
< bitcoin-git>
[bitcoin] TheBlueMatt opened pull request #10914: Add missing lock in CScheduler::AreThreadsServicingQueue() (master...2017-04-fix-missing-scheduler-lock) https://github.com/bitcoin/bitcoin/pull/10914
< arubi>
thanks, looks like it's one of the catches alright
< arubi>
(parent)
< BlueMatt>
whats the expected outcome if a node that is reindexing connects to you?
< BluePills>
I have a wallet and it's saying locked amount. How to make it available?
< sipa>
do you use lockunspent and/or fundrawtransaction RapCs?
< sipa>
RPC?
< phantomcircuit>
the wallet backup functional test doesn't seem to ever work
< phantomcircuit>
BlueMatt, it *should* add any new blocks it sees to the headers list and then request those blocks once it's finished reindexing
< phantomcircuit>
not sure what actually happens
< BlueMatt>
phantomcircuit: dunno, got a guy I'm talking to claiming to run stock ppa 0.14.2 with a somewhat-reasonable bitcoin.conf and his node isnt sending any messages (not even veracks)
< phantomcircuit>
BlueMatt, that doesn't sound right
< BlueMatt>
phantomcircuit: it sends initial version message *if* its connecting outbound, though
< BlueMatt>
(ie his message handler thread is fucked)
< BlueMatt>
but i dont see a reasonable explination of how that could happen
< phantomcircuit>
BlueMatt, the reindex stuff could be holding locks for very very long times as a result of a failing hdd or something
< BlueMatt>
phantomcircuit: initial *outbound* version send takes cs_main, though
< BlueMatt>
so I dont get it
< BlueMatt>
like, what, its taking some node lock or smth? makes no sense
< phantomcircuit>
BlueMatt, sort of hard to say what's happening there without more information
< phantomcircuit>
kind of sounds like ShitsFucked(tm) though
< BlueMatt>
yea, thats my impression, I'm also not sure what else to ask the guy
< BlueMatt>
not much more information that woul be useful
< phantomcircuit>
can he attach gdb to it and get stack traces?
< BlueMatt>
his msghandler thread is using a small but non-0 cpu time implying its not proper-hung
< gmaxwell>
BlueMatt: its still reindexing however?
< gmaxwell>
if so, sounds like you should just attempt to reproduce.
< BlueMatt>
i believe so
< phantomcircuit>
i get the feeling reproducing is going to be hard
< BlueMatt>
yea, that
< gmaxwell>
how is it going to be hard. Reindex and see if the network is braindead.
< sipa>
BlueMatt: the weird thing i observed was that if you interrupt mid-reindex, and then restart it will first activate the reindexed-so-far part before continuing the reindex again
< sipa>
BlueMatt: however, the same turns out to be true in master
< BlueMatt>
wait, didnt you tell me that it was not the case later?
< BlueMatt>
ehh, whatever, its now fixed in the pr
< sipa>
i thought it was worth fixing, but wasn't a critical thing to have in 0.15, so i didn't want to burden you with fixing an extra pre-existing weirdness
< sipa>
if you've fixed it now, so much the better
< sipa>
i'll test it again
< BlueMatt>
sipa: it is a regression, I believe
< BlueMatt>
is it not also broken in 14?
< sipa>
BlueMatt: unsure
< BlueMatt>
ah, i fixed cause i assumed regression
< BlueMatt>
anyway, its clearly the intended behavior, so.....