Transcript for #bitcoin-dev 2017/05/12

00:02 RainMan28 achow101: that txn you helped with still hasn't confirmed. Maybe the 5000 sat/B fee wasn't that high after all :P
00:37 suryab for anyone, who remebers my problem from earlier today, whitelisting the node that is connecting to the node made an incremental step in the right direction, but the real errors that it revealed are:
00:37 suryab 2017-05-11 22:06:04 sending alert (168 bytes) peer=64
00:37 suryab 2017-05-11 22:07:04 received: addr (35 bytes) peer=64
00:37 suryab 2017-05-11 22:07:04 Misbehaving: peer=64 (0 -> 1)
00:37 suryab 2017-05-11 22:07:04 ProcessMessages(addr, 35 bytes) FAILED peer=64
00:37 suryab 2017-05-11 22:07:05 disconnecting peer=64
00:53 achow101 RainMan28: cpfp isn't all that reliable. I don't think many miners mine cpfp transactions, so this is kinda expected
00:53 suryab so it looks like i'm doing something wrong and it's incrementing the ban counter, but I thought that this could be avoided because i `-whitelist=<ip>` the address the connection is coming in from when I run the node
00:54 suryab i realize this looks like I just started talking in the middle of a conversation nobody is in on...
00:55 achow101 suryab: can you use something like wireshark to grab what the actual addr message it is sending? 35 bytes is definitely not the right size for that message
01:10 suryab quick question, would a node do the `send alert` thing if a node deviated from what it expected in the protocol?
01:10 suryab for example in the log, the node says it received a version from me, sent me the version, sent me the verack and underneath all that says it received version message and prints the version message
01:11 suryab is that a result of just the internal scheduling and when this infor was dumnped to the log or is that indicative of the order of operations (in which case a stray version message is being sent out)
01:12 suryab 2017-05-12 01:08:05 received: version (104 bytes) peer=11 2017-05-12 01:08:05 sending version (103 bytes) peer=11 2017-05-12 01:08:05 send version message: version 70015, blocks=463567, us=[::]:0, peer=11 2017-05-12 01:08:05 sending verack (0 bytes) peer=11 2017-05-12 01:08:05 receive version message: <subver>: version 70002, blocks=346110, us=, peer=11
01:12 suryab that's the sequence, says it received version above and underneath for some reason
01:14 achow101 no. the alert is an entirely different message that core 0.14.0+ sends to all old nodes
01:15 suryab oh okay so the alert is independent of whatever else is happening
01:16 achow101 yes. the log order is slightly different from the actual order of events. the received version message is logged after all version message stuff processing has been done, and that includes sending your version message and the verack
01:21 suryab if that's the case then based on the debug.log I'm seeing it would appear that the disconnect happens for no reason. Is there way to determine if the connection is terminated by the node or the incoming connection? Maybe because it says `disconnected peer=x` it means that the node is doing the disconnecting?
01:21 suryab sorry `disconnecting peer=x`
01:22 achow101 since you see "disconnecting peer" in your log, that means that that node is disconnecting from the other one
01:23 kallewoof It could be either or. You will see the same message for when the remote closes connection and for when local closes connection.
01:24 achow101 I'm looking through the code to see why it would disconnect
01:25 suryab i suppose the higher level question to ask is, bitcoin core from December 2016 works fine without issues when receiving connections the way I'm doing now, but the most up to date version disconnects. Has there been any major update to how connections are maintained (maybe new requirements of peers) since then?
01:28 kallewoof I suspect the peer is sending an addr message before it is fully connected. That would explain the Misbehaving 1 part, and the ProcessMessage FAILED
01:28 achow101 suryab: there are only three things that can cause that kind of disconnect (increments banscore by one then disconnects).
01:28 suryab oh okay
01:28 suryab i'll look into that
01:28 achow101 the node sent multiple version messages, did not send a verack before anything else, or did not send a version before anything else
01:29 achow101 can you post a link to your full debug.log?
01:29 suryab so there must have been something new in 0.14 version that classifies something I'm doing as misbahavior
01:29 suryab okay, give me a sec
01:29 achow101 which version node is receiving the connectiong, and which is making it?
01:29 kallewoof You may not handle the case where the remote sends you an alert after you send a VERSION message.
01:30 achow101 kallewoof: he's using core and the alert is sent after all of the handshake stuff
01:30 kallewoof Ah ok
01:31 suryab well, wait so the node making the connection is not a bitcoin node, but is another piece of software that works with previous versions of Bitcoin, it may be that I'm not handling alerts like i should be?
01:32 suryab the tools has worked with all previous versions of bitcon up to Dec 2016
01:32 suryab which is 0.13.x
01:32 kallewoof Sorry, no I was looking at it backwards. It may be that the REMOTE is not handling alerts correctly.
01:32 suryab i'm looking through release notes of 0.14 for notes on new p2p protocol things
01:32 achow101 I think the problem is with the addr message as that is where it is failing
01:32 suryab yeah the entity making the connections may not be acting in a way it's supposed to when it received an alert from this new bitcoin node
01:33 achow101 can we see the log so we can look at the progression of messages?
01:33 kallewoof I'll shut up and let achow101 help you though. Will say something if I'm sure it's useful. I feel like I'm spamming :)
01:33 suryab lol it's all good
01:36 suryab
01:38 achow101 do you know which peer number is your software making the connection?
01:41 ahf a/89
01:55 suryab had to go offline temporarily, change locations
01:58 suryab_ when does the channel log get updated? not sure if i missed something between posted the link to the debug log and coming back online
02:02 kallewoof <achow101> do you know which peer number is your software making the connection?
02:03 suryab_ peer=15
02:04 suryab_ even with just that info, there are approximately 5-6 lines of the log that actually have `peer=15` in them, and that's just the handshake and the alert message
02:06 suryab_ when i get back i'll try to replicate the case where there was a ProcessMessage failure on an addr message and the ban counter was actually incremented. That only happened on one occassion though
02:51 achow101 suryab_: is the IP of the peer in question and is it running Coinscope?
02:51 achow101 if it is, the problem is that it is not responding with a verack
16:53 suryab acho101: I can't believe it was such a simple problem. I went under the assumption that the handshake Coiscope was doing was correct because it's worked without problems on previous versions of Bitcoin.
16:53 suryab achow101^
16:54 suryab perhaps the rules for incrementing the ban counter have change since 0.13
16:59 suryab you there is the change in the release nodes: #9715 b08656e Disconnect peers which we do not receive VERACKs from within 60 sec (TheBlueMatt)
22:51 ginseng since wallet.dat files contain more than just the public/private pairs, i suppose you can't verify a backup with a simple diff, but instead have to load it into the blockchain and compare balance? is there any way to verify backup integrity but this?