< 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>
#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
< 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
< 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