< GitHub68>
[bitcoin] jameshilliard opened pull request #7167: Move TestBlockValidity into a background thread (master...TBVBackground) https://github.com/bitcoin/bitcoin/pull/7167
< phantomcircuit>
so we should probably reconsider a block that's marked invalid once for every valid header on top of it (since we cant tell if the blocks on top are invalid)
< phantomcircuit>
that might help with the "my system is shitty and randomly flips bits" people
< gmaxwell>
I'm not really comfortable with people running wallets on such systems; not at least until we add a fair bit more protection.
< tulip>
maybe just run CheckBlock in a loop until the bit happens to flip back.
< GitHub164>
bitcoin/master 6aadc75 Gregory Maxwell: Disconnect on mempool requests from peers when over the upload limit....
< GitHub164>
bitcoin/master 7922592 Wladimir J. van der Laan: Merge pull request #7166...
< GitHub147>
[bitcoin] laanwj closed pull request #7166: Disconnect on mempool requests from peers when over the upload limit. (master...mempool_p2p_when_overlimit) https://github.com/bitcoin/bitcoin/pull/7166
< GitHub63>
bitcoin/0.12 6ba25d2 Gregory Maxwell: Disconnect on mempool requests from peers when over the upload limit....
< jonasschnelli>
wumpus: the message header size is always 24 bytes, correct?
< wumpus>
jonasschnelli: I don't know the exact value by heart, let me see
< jonasschnelli>
hmm... another magic number.
< jonasschnelli>
i think i can use CMessageHeader::COMMAND_SIZE, etc.
< wumpus>
CMessageHeader::HEADER_SIZE
< jonasschnelli>
Right! Thanks
< wumpus>
and yes, should be 24
< wumpus>
jonasschnelli: did you forget it for mapSendBytesPerCmd[std::string(pszCommand)] += nSize; ?
< jonasschnelli>
wumpus: Thanks! right. there it's also required because of nSize = ssSend.size() - CMessageHeader::HEADER_SIZE
< jonasschnelli>
pushed
< jonasschnelli>
I'm also testing it now
< wumpus>
yeah that's where I noticed (verack is outgoing message)
< wumpus>
+also
< jonasschnelli>
Yes. Now it's correct. The bytesrecv/bytessent (totals per node) matches now the sum of the aggregated values.
< wumpus>
nice!
< wumpus>
maybe we want an 'other' catch-all for received commands that we don't recognize otherwise?
< wumpus>
(say someone is bombarding us with large packets that we don't recognize, right now it won't show up in bytesrecv_per_cmd) - of course we have the total already, so this may be unnecessary, I don't know
< jonasschnelli>
wumpus: hmm.. yes. Would be nice... and it would not introduce a mem DOS attack (if combined to one map key "other").
< wumpus>
right :)
< jonasschnelli>
others = total - <sum of aggregated>, ...
< jonasschnelli>
we could just render that in the rpc output.
< wumpus>
but it may be good to report, it's nice if numbers add up
< wumpus>
the problem is that any string up to 12(?) chars can be an actual command name
< jonasschnelli>
Yeah. Sure. Let me add it. I think this number is very helpful to detect strange nodes.
< wumpus>
so is this the command 'other' or ... an other command... lol ok that doesn't matter much I guess, as 'other' would, being an unknown command, also go into the category 'other' . Hmm.
< jonasschnelli>
use "*other*" instead of "other"? or to much magic?
< wumpus>
making it distinct makes sense yes
< wumpus>
I even mean even though *other* is strictly a valid command name, no one is ever actually going to agree on using that
< wumpus>
yes makes sense
< wumpus>
this is nice, it allows for doing a (simple kind of, better than looking at subvers) behavioral profiling of peers
< wumpus>
some peers do nothing except connect and ping! :o
< jonasschnelli>
Yes. I wrote this to analyze the traffic before I wrote maxuploadtarget PR.
< jonasschnelli>
And it would allow to do some clever throttling based on this data.
< wumpus>
jonasschnelli: would it be a reasonable compromise to have `logAllowIncomingCmds` available via RPC somewhere (say `getnetworkinfo`)? This avoids having to add empty rows to every peer.
< jonasschnelli>
wumpus: yes. That would be useful and reduce the whole rpc response size.
< jonasschnelli>
getpeerinfo looks after a command that is ideal to poll... so reducing size there is fine
< wumpus>
(and still accomplishes the same, the stats collector can know the total set of messages accepted by the peer)
< wumpus>
right - it makes sense to try to save space there
< wumpus>
jonasschnelli: then explicitly mapRecvBytesPerCmd[NET_COMMAND_OTHER] = 0; and use the constant in the other place too
< jonasschnelli>
Yeah. Better. Cleaner.
< wumpus>
jonasschnelli: given how critical it is that it exist, don't think adding it to logAllowIncomingCmds is a good idea, someone may just remove it and crash everything
< wumpus>
jonasschnelli: maybe add an assert(i != mapRecvBytesPerCmd.end()); before the increase just incase :p
< jonasschnelli>
Yeah. Good idea.
< wumpus>
(ideally we would have constants for all net commands and use those in the code instead of hardcoded strings, this avoids typos and such, but far out of scope of your pull)
< jonasschnelli>
Indeed
< jonasschnelli>
wumpus: Added a commit that hides the 0 entries... need to add the command list to getnetworkinfo.. will do soon.
< * wumpus>
must have the craziest multi-stage bitcoind launch command "nice -+19 screen -d -m gdb -x run.gdbscript -args ./bitcoind -datadir=/usb/bitcoin" (run.gdbscript is http://stackoverflow.com/a/5286038/216357 )
< jonasschnelli>
hah
< wumpus>
maybe I should propose it for #7111 "Recommend how to run bitcoind in a production environment"? *ducks*
< jonasschnelli>
you forgot the while 1 loop (in case it crashes)
< wumpus>
hahahhahaah
< jonasschnelli>
;-)
< wumpus>
jonasschnelli: hm I got a "bitcoind: net.cpp:703: bool CNode::ReceiveMsgBytes(const char*, unsigned int): Assertion `i != mapRecvBytesPerCmd.end()' failed."
< wumpus>
jonasschnelli: you're not prepopulating NET_COMMAND_OTHER, either need to re-add it to logAllowIncomingCmds, either add it or (I think preferably) add it explicilty with mapRecvBytesPerCmd[NET_COMMAND_OTHER] = 0
< GitHub73>
[bitcoin] laanwj opened pull request #7171: test: remove necessity to call create_callback_map (master...2015_12_p2p_test_no_cbmap) https://github.com/bitcoin/bitcoin/pull/7171
< wumpus>
jonasschnelli: great
< wumpus>
"bytesrecv_per_cmd": { "reject": 140788, } whoa some nodes send a lot of reject
< wumpus>
that's a lot for a message we don't use at all
< tulip>
are people setting the "reason" string?
< wumpus>
I don't know, going to log the contents
< afk11>
hmm, I am getting reject messages this morning using electrum
< afk11>
the one that comes with tails :/ not great.
< afk11>
"Your transaction was rejected by the network, please upgrade away to > electrum 2.6"
< wumpus>
at least that message is clear on what to do (but I don't believe it has to do with P2P network reject messages)
< tulip>
that's unrelated.
< tulip>
that'll be to do with low-s signatures, older versions of Electrum generate now-invalid signatures.
< wumpus>
we should have made reject messages optional, eg like announce headers, a 'enablerejects' message that has to be received before the node starts sending them
< GitHub93>
bitcoin/0.12 f31955d Gregory Maxwell: Replace setInventoryKnown with a rolling bloom filter....
< Thireus>
I received this a couple of hours ago: "WARNING: check your network connection, 5 blocks received in the last 4 hours (24 expected)" on my full nodes
< Thireus>
there seem to be some TX flood going on, has anyone else been impacted as well?
< tulip>
Thireus: that seems to be buggy. other people have encountered the same thing.
< Squidicuz>
I rebooted the services and it is okay for now :S
< Squidicuz>
what does that message mean though? I can't be blocks behind when minig O_o
< Squidicuz>
apologies if this is the wrong channel, i just realized where I is.
< tulip>
Squidicuz: it's probably on topic, if you aren't falling behind triggering that is definitely a bug. someone has encountered that before recently.
< Squidicuz>
the node did not seem behind when i checked on it. i restarted and havent gotten the messgae since. the logs shows that bitcoind timed out a few times prior.
< tulip>
timed out?
< Squidicuz>
yes. my connection to bitcoind timed out, I mean.