1 2017-05-12 00:02:30 <RainMan28> achow101: that txn you helped with still hasn't confirmed. Maybe the 5000 sat/B fee wasn't that high after all :P
 2 2017-05-12 00:37:28 <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:
 3 2017-05-12 00:37:35 <suryab> 2017-05-11 22:06:04 sending alert (168 bytes) peer=64
 4 2017-05-12 00:37:37 <suryab> 2017-05-11 22:07:04 received: addr (35 bytes) peer=64
 5 2017-05-12 00:37:47 <suryab> 2017-05-11 22:07:04 Misbehaving: 172.17.0.1:39104 peer=64 (0 -> 1)
 6 2017-05-12 00:37:51 <suryab> 2017-05-11 22:07:04 ProcessMessages(addr, 35 bytes) FAILED peer=64
 7 2017-05-12 00:37:54 <suryab> 2017-05-11 22:07:05 disconnecting peer=64
 8 2017-05-12 00:53:38 <achow101> RainMan28: cpfp isn't all that reliable. I don't think many miners mine cpfp transactions, so this is kinda expected
 9 2017-05-12 00:53:39 <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
10 2017-05-12 00:54:20 <suryab> i realize this looks like I just started talking in the middle of a conversation nobody is in on...
11 2017-05-12 00:55:25 <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
12 2017-05-12 01:10:04 <suryab> quick question, would a node do the `send alert` thing if a node deviated from what it expected in the protocol?
13 2017-05-12 01:10:51 <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
14 2017-05-12 01:11:27 <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)
15 2017-05-12 01:12:05 <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=72.36.89.11:8880, peer=11
16 2017-05-12 01:12:20 <suryab> that's the sequence, says it received version above and underneath for some reason
17 2017-05-12 01:14:07 <achow101> no. the alert is an entirely different message that core 0.14.0+ sends to all old nodes
18 2017-05-12 01:15:29 <suryab> oh okay so the alert is independent of whatever else is happening
19 2017-05-12 01:16:59 <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
20 2017-05-12 01:21:38 <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?
21 2017-05-12 01:21:51 <suryab> sorry `disconnecting peer=x`
22 2017-05-12 01:22:35 <achow101> since you see "disconnecting peer" in your log, that means that that node is disconnecting from the other one
23 2017-05-12 01:23:54 <kallewoof> It could be either or. You will see the same message for when the remote closes connection and for when local closes connection.
24 2017-05-12 01:24:08 <achow101> I'm looking through the code to see why it would disconnect
25 2017-05-12 01:25:14 <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?
26 2017-05-12 01:28:16 <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
27 2017-05-12 01:28:21 <achow101> suryab: there are only three things that can cause that kind of disconnect (increments banscore by one then disconnects).
28 2017-05-12 01:28:42 <suryab> oh okay
29 2017-05-12 01:28:45 <suryab> i'll look into that
30 2017-05-12 01:28:53 <achow101> the node sent multiple version messages, did not send a verack before anything else, or did not send a version before anything else
31 2017-05-12 01:29:05 <achow101> can you post a link to your full debug.log?
32 2017-05-12 01:29:12 <suryab> so there must have been something new in 0.14 version that classifies something I'm doing as misbahavior
33 2017-05-12 01:29:30 <suryab> okay, give me a sec
34 2017-05-12 01:29:37 <achow101> which version node is receiving the connectiong, and which is making it?
35 2017-05-12 01:29:46 <kallewoof> You may not handle the case where the remote sends you an alert after you send a VERSION message.
36 2017-05-12 01:30:35 <achow101> kallewoof: he's using core and the alert is sent after all of the handshake stuff
37 2017-05-12 01:30:49 <kallewoof> Ah ok
38 2017-05-12 01:31:49 <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?
39 2017-05-12 01:32:12 <suryab> the tools has worked with all previous versions of bitcon up to Dec 2016
40 2017-05-12 01:32:15 <suryab> which is 0.13.x
41 2017-05-12 01:32:31 <kallewoof> Sorry, no I was looking at it backwards. It may be that the REMOTE is not handling alerts correctly.
42 2017-05-12 01:32:40 <suryab> i'm looking through release notes of 0.14 for notes on new p2p protocol things
43 2017-05-12 01:32:47 <achow101> I think the problem is with the addr message as that is where it is failing
44 2017-05-12 01:32:57 <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
45 2017-05-12 01:33:30 <achow101> can we see the log so we can look at the progression of messages?
46 2017-05-12 01:33:32 <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 :)
47 2017-05-12 01:33:43 <suryab> lol it's all good
48 2017-05-12 01:36:49 <suryab> http://s000.tinyupload.com/download.php?file_id=90540237565949739165&t=9054023756594973916596920
49 2017-05-12 01:38:40 <achow101> do you know which peer number is your software making the connection?
50 2017-05-12 01:41:17 <ahf> a/89
51 2017-05-12 01:55:03 <suryab> had to go offline temporarily, change locations
52 2017-05-12 01:58:20 <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
53 2017-05-12 02:02:06 <kallewoof> <achow101> do you know which peer number is your software making the connection?
54 2017-05-12 02:03:52 <suryab_> peer=15
55 2017-05-12 02:04:41 <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
56 2017-05-12 02:06:46 <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
57 2017-05-12 02:51:24 <achow101> suryab_: is 172.17.0.1 the IP of the peer in question and is it running Coinscope?
58 2017-05-12 02:51:59 <achow101> if it is, the problem is that it is not responding with a verack
59 2017-05-12 16:53:39 <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.
60 2017-05-12 16:53:46 <suryab> achow101^
61 2017-05-12 16:54:28 <suryab> perhaps the rules for incrementing the ban counter have change since 0.13
62 2017-05-12 16:59:35 <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)
63 2017-05-12 22:51:05 <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?