< phantomcircuit> im running master on an older slightly slower system
< phantomcircuit> it's got an ssd in it though
< phantomcircuit> and it's not running ar anywhere near 100% cu during ibd
< phantomcircuit> at block height 188k
< phantomcircuit> seems something is broken with ibd block downloads maybe?
< phantomcircuit> yeah i have one peer that is significantly slower than the others
< gmaxwell> it won't use much cpu before it starts verifying signatures.
< gmaxwell> early in the chain its latency bound because it only fetches 16 blocks at a time from each peer.
< gmaxwell> it doesn't make that much difference in the time for overall synchronization.
< phantomcircuit> gmaxwell, yeah i was only at ~3% cpu
< phantomcircuit> which is definitely not right
< phantomcircuit> i disconnected a peer and now im at 100%
< gmaxwell> well thats goofy.
< phantomcircuit> net thread is spinning doing deserialization
< gmaxwell> it'll disconnect a peer if they're stalling your download, and I know that works because it's a little twitchy about it.
< phantomcircuit> gmaxwell, doesn't seem to have worked here for whatever reason
< bitcoin-git> [bitcoin] rebroad closed pull request #9414: Skip processing of TXs that we already have. (master...DoNotProcessNewTxsMoreThanOnce) https://github.com/bitcoin/bitcoin/pull/9414
< rebroad> I have a question about mapAlreadyAskedFor - it seems that entries are erased from it only when a tx is received...
< rebroad> what is the maximum size it can reach? and why aren't tx hashes erased when a block arrives?
< rebroad> and what is to stop a node inventing random tx hashes and filling the map?
< rebroad> (which will never be erased as the txs don't exist)
< gmaxwell> rebroad: it is a limitedmap.
< rebroad_> gmaxwell, ah ok. so limited to 50,000 entries which is the most invs that any node can send in one go without misbehaving
< rebroad_> so i guess a node could send 50,000 and replace the map with useless entries, but the worst that would happen is that the node would then request every tx hash received rather than queue/delay them by 2 minute increments
< rebroad_> i would have thought the threshold for misbehaviour perhaps could be a fraction of MAX_INV_SZ rather than MAX_INV_SZ itself
< rebroad_> sorry, thinking aloud
< bitcoin-git> [bitcoin] rebroad opened pull request #9418: Exit when no direct fetch (master...ExitWhenNoDirectFetch) https://github.com/bitcoin/bitcoin/pull/9418
< rebroad> #9418 is a very minimal PR.. just adds a return and reduces the indentation accordingly - hopefully not treading on the toes of {m,}any other PRs
< gribble> https://github.com/bitcoin/bitcoin/issues/9418 | Exit when no direct fetch by rebroad · Pull Request #9418 · bitcoin/bitcoin · GitHub
< rebroad> (although it does tread on the toes of various other commits of mine, but I shall rebase them as need be)
< cfields> gmaxwell: heh, fixing this busted process loop has been my primary target for over a year now :)
< gmaxwell> cfields: ya. well I hope that a simple and expediant tweak isn't too distastful, I know you're working on big redesigns around it.
< cfields> no issues with quick changes if they help, but we're really close to having it fixed cleanly (imo)
< cfields> gmaxwell: my only request would be to base it on #9289, since that reworks all of that sleeping code
< gribble> https://github.com/bitcoin/bitcoin/issues/9289 | net: drop boost::thread_group by theuni · Pull Request #9289 · bitcoin/bitcoin · GitHub
< cfields> (no real logical changes there though)
< gmaxwell> I'd gladly do that.
< cfields> thanks :)
< cfields> BlueMatt and I have been squabbling over syntactic sugar on that one, but I think it's clear that it will go in in some form
< * luke-jr> wonders if we can get Transifex to run sanity checks and complain to translators directly
< luke-jr> oh well, fixed a bunch I could easily guess.
< luke-jr> hm
< luke-jr> it's actually possible to get a N-of-17 multisig P2SH
< jl2012> luke-jr: having more than 15 sigop is non standard, I think
< sipa> 2 subsequent OP_ROTs?
< sipa> ah, i confused it with OP_SWAP, nvm
< luke-jr> jl2012: well, it probably ought to be lifted if anyone wants to make use of this
< luke-jr> otoh, with segwit around the corner.. no real need?
< luke-jr> (reason for coming up with this script initially is that cannon-c wanted to multisig without revealing the pubkeys to participants)
< luke-jr> hmm, it seems like Transifex's translations of plurals has degraded. seeing a lot of "blok(ken)" where it used to be "blok" or "blokken" depending on the number :x
< BlueMatt> cfields/gmaxwell well I think you've got a version of #9289 that I'm happy with up now
< BlueMatt> :)
< gribble> https://github.com/bitcoin/bitcoin/issues/9289 | net: drop boost::thread_group by theuni · Pull Request #9289 · bitcoin/bitcoin · GitHub
< bitcoin-git> [bitcoin] TheBlueMatt opened pull request #9419: Stop Using cs_main for CNodeState/State() (master...2016-12-nodestate) https://github.com/bitcoin/bitcoin/pull/9419
< bitcoin-git> [bitcoin] rebroad reopened pull request #9402: Allow per network configuration file (master...PerNetworkConfig) https://github.com/bitcoin/bitcoin/pull/9402
< bitcoin-git> [bitcoin] droark opened pull request #9420: Fix linker error when configured with --enable-lcov (master...fixlcov) https://github.com/bitcoin/bitcoin/pull/9420