< warren> I'm putting together a presentation, trying to find a recent performance optimization PR that had hundreds of comments, anyone know which it was?
< warren> Wow so many PR's merged. Clearly development is stagnant here.
< sipa> warren: eh
< sipa> could be many things
< gmaxwell> it's hard to tell how many comments there have been because github hides them
< arubi> can add comments:>100 to the search string
< warren> cool thanks
< gmaxwell> https://github.com/bitcoin/bitcoin/pull/10195 might be what you were looking for
< sipa> ah, yes
< warren> yes that's it!
< bitcoin-git> [bitcoin] visvirial opened pull request #10974: Fix typo in sendcoinsdialog. (master...fix-typo-in-sendcoindialog) https://github.com/bitcoin/bitcoin/pull/10974
< bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/f66c59650527...f0579bfea1db
< bitcoin-git> bitcoin/master 7f121a0 Masahiko Hyuga: Fix typo in sendcoinsdialog.
< bitcoin-git> bitcoin/master f0579bf Wladimir J. van der Laan: Merge #10974: Fix typo in sendcoinsdialog....
< bitcoin-git> [bitcoin] laanwj closed pull request #10974: Fix typo in sendcoinsdialog. (master...fix-typo-in-sendcoindialog) https://github.com/bitcoin/bitcoin/pull/10974
< bitcoin-git> [bitcoin] laanwj pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/f0579bfea1db...659c09613408
< bitcoin-git> bitcoin/master b13a68e Pieter Wuille: Squashed 'src/leveldb/' changes from 196962ff0..c521b3ac6...
< bitcoin-git> bitcoin/master 47f3e8c Pieter Wuille: Update LevelDB with latest Bitcoin-specific patches
< bitcoin-git> bitcoin/master 659c096 Wladimir J. van der Laan: Merge #10958: Update to latest Bitcoin patches for LevelDB...
< bitcoin-git> [bitcoin] laanwj closed pull request #10958: Update to latest Bitcoin patches for LevelDB (master...20170731_leveldb) https://github.com/bitcoin/bitcoin/pull/10958
< bitcoin-git> [bitcoin] practicalswift opened pull request #10975: [script] Return early if no valid opcodes found in CountWitnessSigOps(...) (master...return-early-in-CountWitnessSigOps) https://github.com/bitcoin/bitcoin/pull/10975
< jonasschnelli> Got a request from a miner: what is the best document to figure out how to create segwit coinbase transactions?
< bitcoin-git> [bitcoin] ryanofsky opened pull request #10976: [MOVEONLY] Move some static functions out of wallet.h/cpp (master...pr/wmove) https://github.com/bitcoin/bitcoin/pull/10976
< bitcoin-git> [bitcoin] practicalswift opened pull request #10977: [net] Fix use of uninitialized value in getnetworkinfo(const JSONRPCRequest& request) (master...valgrind-getnetworkinfo) https://github.com/bitcoin/bitcoin/pull/10977
< gmaxwell> jnewbery: https://twitter.com/jfnewbery/status/892856516985991170 I think this is misleading. Retarget modified the difficulty from the prior block, so it's likely to double apply a dip, not undo it.
< gmaxwell> Though it depends on when in the retarget window the crazy-change applies.
< gmaxwell> E.g. if 20 blocks before the retarget the 12h rule triggers, it will then drop the difficulty 73.7% (because when it triggers it triggers 6 times in a row...)
< gmaxwell> then you'll get to the retarget, and the code will go "oh wow, took longer than expected for the last 2016 blocks, better lower the difficulty".
< gmaxwell> E.g. the worst case is probably something like you run at 1/11th the hashrate for a whole retarget interval, then just before the end, hit the magic rule. This drops your difficulty by 3.8, then the retarget will apply and drop the diffuclty by a factor of 11, resuting in blocks being about 4x too fast.
< jnewbery> thanks gmaxwell. Yes, makes sense
< jnewbery> Having two difficulty readjustment algorithms is confusing :/
< jnewbery> I assumed that normal retarget was based on the previous retarget nBits, not pindexLast
< jnewbery> (which of course would be the same thing if you didn't change nBits within a retarget window)
< gmaxwell> jnewbery: yea, more or less an accident of software construction that it uses the last rather than the last retarget.
< gmaxwell> This actually creates a bug for testnet's diff1 rule, if it happens at the wrong block it'll warp testnet's difficulty back to 1.