< bitcoin-git> [bitcoin] pinheadmz opened pull request #9571: RPC: getblockchaininfo returns BIP signaling statistics (master...master) https://github.com/bitcoin/bitcoin/pull/9571
< jonasschnelli> BlueMatt: I'm working on the fixes for #9461
< gribble> https://github.com/bitcoin/bitcoin/issues/9461 | [Qt] Improve progress display during headers-sync and peer-finding by jonasschnelli · Pull Request #9461 · bitcoin/bitcoin · GitHub
< bitcoin-git> [bitcoin] jl2012 opened pull request #9572: Skip witness sighash cache for non-segwit transactions (master...nocache) https://github.com/bitcoin/bitcoin/pull/9572
< bitcoin-git> [bitcoin] MarcoFalke pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/6696b4635ceb...b0b57a17306a
< bitcoin-git> bitcoin/master 95bab82 practicalswift: Remove unused Python imports
< bitcoin-git> bitcoin/master b0b57a1 MarcoFalke: Merge #9508: Remove unused Python imports...
< bitcoin-git> [bitcoin] MarcoFalke closed pull request #9508: Remove unused Python imports (master...remove-unused-python-import) https://github.com/bitcoin/bitcoin/pull/9508
< bitcoin-git> [bitcoin] fanquake opened pull request #9574: [depends] Fix QT build on OSX (master...fix-osx-depends-build) https://github.com/bitcoin/bitcoin/pull/9574
< BlueMatt> cfields: yo
< BlueMatt> where are we on #9212 and #9278? The fix for 9212 at https://github.com/bitcoinfibre/bitcoinfibre/commit/8e2c2cf418adb3dad1479c3f8890e0a2c8b6f709 has been in production for a while (albeit not on nodes with a ton of connection churn) so I'm reasonably confident in it, but iirc you were not a fan?
< gribble> https://github.com/bitcoin/bitcoin/issues/9212 | Assertion failed: (nSendVersion != 0), function GetSendVersion, file ./net.h, line 775. · Issue #9212 · bitcoin/bitcoin · GitHub
< gribble> https://github.com/bitcoin/bitcoin/issues/9278 | test_bitcoin fails valgrind · Issue #9278 · bitcoin/bitcoin · GitHub
< BlueMatt> for those bored, #9392 should be an easy fix
< gribble> https://github.com/bitcoin/bitcoin/issues/9392 | Wallet ancestor sanity-check ignores sigops · Issue #9392 · bitcoin/bitcoin · GitHub
< cfields> BlueMatt: I didn't like that change at the time because 1. We weren't always disconnecting (or checking fDisconnect) as necessary at the time, and 2. It changes the "you can only send 1 version message" semantics a bit. 1. should be fixed since fedea8a14. I think your change is probably ok, but I think we should think through 2 a little.
< BlueMatt> I know we also discussed moving off of the "nVersion is set means connected" to using the fSuccessfullyConnected flag again
< BlueMatt> they're kinda confused and redundant atm
< cfields> yea
< cfields> that would be my preference, only issue there is defining "successfully connected"
< cfields> BlueMatt: as a weird example, I think your change would allow for sending infinite version messages in which the addrMe portion fails to deserialize
< cfields> so a peer could change their nVersion a bunch of times before locking it in
< cfields> (i don't know what good that would do, but we certainly shouldn't be allowing that)
< BlueMatt> I'd file that under "undefined behavior" I believe in that case we may be required to make a best effort to eat the sender's cat
< BlueMatt> but short that, I'm not sure if we care that they can do that?
< BlueMatt> as long as we actually gate on fSuccessfullyConnected
< cfields> BlueMatt: right, that was my point. atm we don't in many places
< BlueMatt> cfields: do you have time to look at that, or should I just whip something up with fSuccessfullyConnected after I finish review of one or two others?
< BlueMatt> well atm we check nVersion != 0 pretty much everywhere, i think
< BlueMatt> as a proxy for connectedness
< cfields> BlueMatt: right, and in the above scenario, we don't consider them connected, but their nVersion is set.
< BlueMatt> ok, so replace nVersion != 0 with fSuccessfullyConnected everywhere, i guess?
< cfields> i think so.
< BlueMatt> k
< cfields> and at this point, we can remove the assert
< BlueMatt> I'll do it after lunch if you havent gotten to it
< BlueMatt> I'd prefer leaving it in?
< BlueMatt> afaict its super easy to fix
< BlueMatt> I'm incredibly confident in the above change
< BlueMatt> (as its equivalent to the change I've been running for months now)
< cfields> BlueMatt: point me at a node running it, let's see if i can bring it down :)
< BlueMatt> the fibre nodes
< BlueMatt> :p
< cfields> heh
< BlueMatt> I'll swap my public node to master soonish
< BlueMatt> it gets a shitload of connection churn
< BlueMatt> and fun spy nodes and shit which do batshit crazy things
< bitcoin-git> [bitcoin] practicalswift opened pull request #9575: [trivial] Add comment about unreachable code (master...never-executed-comment) https://github.com/bitcoin/bitcoin/pull/9575
< bitcoin-git> [bitcoin] practicalswift opened pull request #9576: [wallet] Remove redundant initialization (master...remove-redundant-initialization-ii) https://github.com/bitcoin/bitcoin/pull/9576
< cfields> BlueMatt: ok, whipping something up on top of yours. Think I've got a full picture of it all in my head.
< BlueMatt> cfields: ok, thanks, got distracted on other things
< BlueMatt> someone should tag #9569, #9371 and #9148 for 0.14 because they fix 0.14-tagged issues
< gribble> https://github.com/bitcoin/bitcoin/issues/9569 | Setting -blocksonly sets -maxmempool to zero. by jnewbery · Pull Request #9569 · bitcoin/bitcoin · GitHub
< gribble> https://github.com/bitcoin/bitcoin/issues/9371 | Notify on removal by morcos · Pull Request #9371 · bitcoin/bitcoin · GitHub
< gribble> https://github.com/bitcoin/bitcoin/issues/9148 | Wallet RPCs can return stale info due to ProcessNewBlock Race · Issue #9148 · bitcoin/bitcoin · GitHub
< BlueMatt> sorry, that last one should be #9570
< gribble> https://github.com/bitcoin/bitcoin/issues/9570 | Block Wallet RPCs until wallet is synced to our current chain by TheBlueMatt · Pull Request #9570 · bitcoin/bitcoin · GitHub
< bitcoin-git> [bitcoin] laanwj pushed 7 new commits to master: https://github.com/bitcoin/bitcoin/compare/b0b57a17306a...6012967c4746
< bitcoin-git> bitcoin/master 843c560 Pieter Wuille: Avoid unaligned access in crypto i/o
< bitcoin-git> bitcoin/master f94f3e0 Pieter Wuille: Avoid integer overflows in scriptnum tests
< bitcoin-git> bitcoin/master 6b03bfb Pieter Wuille: Fix memory leak in wallet tests
< bitcoin-git> [bitcoin] laanwj closed pull request #9512: Fix various things -fsanitize complains about (master...sanitize) https://github.com/bitcoin/bitcoin/pull/9512
< Chris_Stewart_5> Does some one mind merging in #9350? Pretty trivial, just fixing some documentation on tests
< gribble> https://github.com/bitcoin/bitcoin/issues/9350 | [Trivial] Adding label for amount inside of tx_valid/tx_invalid.json by Christewart · Pull Request #9350 · bitcoin/bitcoin · GitHub
< morcos> wumpus: sipa: I updated #9371 in a way that I think accomplish both of our goals
< gribble> https://github.com/bitcoin/bitcoin/issues/9371 | Notify on removal by morcos · Pull Request #9371 · bitcoin/bitcoin · GitHub
< * BlueMatt> likes it because I have future plans in the area...but will explain on the pr when I review in a minute :p
< cfields> BlueMatt: hmm, looks like that could make your recent-tx cache significantly smarter
< BlueMatt> yes, lots of ways it could be made smarter :)
< bitcoin-git> [bitcoin] jnewbery opened pull request #9577: Fix docstrings in qa tests (master...docstrings) https://github.com/bitcoin/bitcoin/pull/9577
< BlueMatt> sipa_/wumpus: so I think the only way to fix the regression introduced in #7946 without giving up the gains it gave us is to introduce a second cs_wallet - cs_wallet_locked_before_cs_main
< gribble> https://github.com/bitcoin/bitcoin/issues/7946 | Reduce cs_main locks during ConnectTip/SyncWithWallets by jonasschnelli · Pull Request #7946 · bitcoin/bitcoin · GitHub
< BlueMatt> please dont kill me
< cfields> morcos: ah, i missed your comment in the description. I guess i'm requesting choice #1 :)
< gribble> https://github.com/bitcoin/bitcoin/issues/1 | JSON-RPC support for mobile devices ("ultra-lightweight" clients) · Issue #1 · bitcoin/bitcoin · GitHub
< BlueMatt> I do remove the NOT_IN_BLOCK kludge ther
< BlueMatt> e
< BlueMatt> (but this introduces the need for a second wallet lock)
< morcos> cfields: I'm trying to do the minimal required in 9371 to fix the regression though.. as it needs to be merged for 0.14...
< cfields> morcos: ok, fair enough
< morcos> so i don't want to do a new signal now b/c it will require thinking carefully about what should subscribe to it
< morcos> but i'm fine dropping the SYNC_TRANASCTION_NOT_IN_BLOCK as BlueMatt did
< cfields> ok, will look over that one too
< sipa_> BlueMatt: i'm unclear about it... can you write a simple commit that does the cs_wallet_locked_before_cs_main ?
< BlueMatt> sipa_: I think we can push off to 0.15, but I will do that, yes, one sec
< luke-jr> done with reviews I think. ping me if there's anything needed priority on before 0.14 freeze.
< BlueMatt> specifically, this half-reverts #9570 to get to the behavior intended in #7946 without introducing the getbalance-etc-may-return-data-from-mid-block-processing regression
< gribble> https://github.com/bitcoin/bitcoin/issues/9570 | Block Wallet RPCs until wallet is synced to our current chain by TheBlueMatt · Pull Request #9570 · bitcoin/bitcoin · GitHub
< gribble> https://github.com/bitcoin/bitcoin/issues/7946 | Reduce cs_main locks during ConnectTip/SyncWithWallets by jonasschnelli · Pull Request #7946 · bitcoin/bitcoin · GitHub
< BlueMatt> someone wanna kick https://travis-ci.org/bitcoin/bitcoin/builds/193151086 ? looks like it failed due to travis timeout because it built dependancies and not because it failed
< BlueMatt> https://github.com/bitcoin/bitcoin/blob/master/src/txmempool.cpp#L555 <-- that is wrong...100 block reorg and it could blow up (with the checkmempool debug instrumentation enabled)
< bitcoin-git> [bitcoin] TheBlueMatt opened pull request #9578: Add missing mempool lock for CalculateMemPoolAncestors (master...2017-01-fix-missing-wallet-mempool-lock) https://github.com/bitcoin/bitcoin/pull/9578
< cfields> BlueMatt: ok, i've been staring at this for most of the day and i'm reasonably satisfied now. I'm good with your change with 2 tweaks
< cfields> 1. deserialize the whole thing locally. Same change you made for nVersion, let's go ahead and do that for everything. That way we don't end up in a weird state if something throws
< cfields> and 2. just a quick reordering that moves the assignment into CNode up a bit, and sets nVersion/fSuccessfullyConnected last.