< NicolasDorier> sipa: in my case it is p2wsh, will take a look when I get my pc back
< NicolasDorier> Yes p2wsh without p2sh
< btcdrak> 4 blocks to go
< arubi> https://pastebin.com/raw/t0qiBaEW invalid block relayed
< arubi> error is ERROR: ConnectBlock(): inputs missing/spent
< gmaxwell> So a bit ago 1hash produced in invalid block
< gmaxwell> It has a transaction whos parent wasn't in the block.
< gmaxwell> They did also did this two weeks ago.
< gmaxwell> And when asked about it they reported that it was an error with automation.
< praxeology> "an error with automation" :)
< gmaxwell> This new block, like the prior invalid block, has exactly 256 transactions.
< gmaxwell> I'll leave it to others to form their own suspicions; but it seems pretty clear that this isn't a direct result of today's network fun.
< praxeology> 256 could be made into a very evenly filled tree, maybe they were swapping transactions... and they swapped out the wrong one?
< praxeology> swapping algorithm doesn't do a very good job checking for dependencies?
< BlueMatt> praxeology: that is one conclusion
< BlueMatt> and likely the most obvious
< gmaxwell> offtopic for here for now
< praxeology> I would guess that gmaxwell is suggesting that the purpose of the swapping might be to perform ASICB... oh offtopic
< gmaxwell> in any case, I just wanted to make it clear that this has happened before with this miner and isn't some BIP-91 thing.
< gmaxwell> {
< gmaxwell> "height": 477115,
< gmaxwell> "hash": "0000000000000000013ee4a86822d37a061732e04ee5f41fb77168f193363d1b",
< gmaxwell> "branchlen": 1,
< gmaxwell> "status": "invalid"
< gmaxwell> },
< gmaxwell> Active.
< btcdrak> 121 no forks detected yet
< 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.
< bitcoin-git> [bitcoin] tiagmoraismorgado opened pull request #10913: fixing a couple of typos (master...patch-2) https://github.com/bitcoin/bitcoin/pull/10913
< bitcoin-git> [bitcoin] fanquake closed pull request #10913: fixing a couple of typos (master...patch-2) https://github.com/bitcoin/bitcoin/pull/10913
< 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?
< arubi> what's the child's txid achow101 ?
< arubi> uhh, I'm getting much more than one
< arubi> I'm getting all of these (reversed bytes) grep-able in the hex block https://0bin.net/paste/X2984kGzXMzqfSVN#XdVdT8WRmJ0J733Y78ZxddH8ssahW212qTkVXaWytXr
< arubi> hm, maybe wrong :\
< arubi> ah no, that should be right, but some of the ordering might be correct. I didn't check
< 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?
< bitcoin-git> [bitcoin] benma opened pull request #10915: get rid of the fRelayTxes global (master...fRelayTxes) https://github.com/bitcoin/bitcoin/pull/10915
< 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.
< bitcoin-git> [bitcoin] benma opened pull request #10916: add missing lock to crypter GetKeys() (master...GetKeys) https://github.com/bitcoin/bitcoin/pull/10916
< BlueMatt> gmaxwell: E_CANT_REPRODUCE
< phantomcircuit> BlueMatt, i am le shocked
< sipa> xkcd 583...
< BlueMatt> gah, sipa you were correct
< BlueMatt> but then became un-correct
< 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.....
< sipa> agree.