Topic: Corrupt getheaders messages from /Satoshi:0.16.3/ (Read 281 times)
It is not the same chain, it maybe forked from that version but it is not the same chain and even if you dont block the node it won't affect your wallet
Nobody knows anything?
Hi,
this might be some Bitcoin cash clients.
this might be some Bitcoin cash clients.
Surprised there has been no response to this topic.
I would guess the client "should" be banning the peers if they are sending something malformed?
From the post above it seems they are pretty close in the IP ranges so I would guess they are being run by the same person.
I'm sure some core guru will be along with a more detailed answer but it is concerning if the number of these nodes continues to grow.
I would guess the client "should" be banning the peers if they are sending something malformed?
From the post above it seems they are pretty close in the IP ranges so I would guess they are being run by the same person.
I'm sure some core guru will be along with a more detailed answer but it is concerning if the number of these nodes continues to grow.
After further investigation, it seems like not only getheaders messages are affected in this way, but also others like:
sendheaders
sendcmpct
ping
feefilter
reject
pong
getdata
However, these message types seem to be coming with a proper payload:
version
verack
addr
inv
They don't seem to be a legit nodes as they do inv, but then don't answer getdata.
I would not be bothering with it, just assume someone playing with their... whatever it is.
If not for the fact that there are plenty of these nodes out there and it's been already happening for weeks.
sendheaders
sendcmpct
ping
feefilter
reject
pong
getdata
However, these message types seem to be coming with a proper payload:
version
verack
addr
inv
They don't seem to be a legit nodes as they do inv, but then don't answer getdata.
I would not be bothering with it, just assume someone playing with their... whatever it is.
If not for the fact that there are plenty of these nodes out there and it's been already happening for weeks.
I've been observing for some time already that there are multiple nodes who introduce themselves as /Satoshi:0.16.3/, but always send corrupt getheaders messages.
This is an example payload of the getheaders message that I'm getting from them (that's being at the block #561792):
Having analyzing this payload:
... it seems that there is an extra 24 bytes in front, with the actual (repeated) header of the message.
Then the bytes "7f110100" - of the protocol version (weird value, but should be fine)...
Then the rest seems to be a completely normal getheaders message, with protocol version 70015 followed by 31 locators and null hash stop.
I just have two questions for people more familiar with bitcoin core.
1. Is it possible that the actual bitcoin core 0.16.3 would send such a corrupt message, at some circumstances?
2. What does (the recent) bitcoin core do upon receiving such messages? How does it interpret it?
Because I'm just banning the node for sending me a corrupt message, but I'm not sure if that isn't too harsh.
Below some IP addresses of nodes sending such a corrupt messages.
I've never seen it being sent from any other node than one introducing itself as /Satoshi:0.16.3/
But there is many of them out there (the IP list above is just a fragment).
This is an example payload of the getheaders message that I'm getting from them (that's being at the block #561792):
Code:
f9beb4d967657468656164657273000005040000fa8a778d7f1101001f0619a95d2dae0ffd58bb144890bff7b11ae2060ceb631e0000000000000000005f30eb8f449c54d2022691d295742c7a87d375c7785d0100000000000000000091fd7a78b9f8e3c297cb7b61d5b7858c1aeacfeabdbc0200000000000000000018a797686e559c65db551c494781c9d3376dadea6c1215000000000000000000467bff2cae14e26f0b078c4de62267e661536fda610022000000000000000000e286fad54eeca7795bbbefca420c197dc1a55fff78951d0000000000000000001d86a184718fc6c966490445845997a385b42241ef790600000000000000000074b5a970607dfd7efda26bc617dc4c7f8192b57368980c000000000000000000d3ae6ba3fe0389bf3d0581e8ff1dcd6feb873e4d020a15000000000000000000090ba32482c702f23f7c50297d4ed6327fd43f1602a71c00000000000000000062d04bf3ab1ce424641873e380b434190e357b509e401b000000000000000000c49a24ba246faee1c3ce6fa40ff19122a77515e542f10d000000000000000000624a3e2b2846e2a48084e895fa467595c623a5504f2e12000000000000000000bf8acf2c829eb75740f32049b7fd66641cd142dbf19c1900000000000000000043706c6d5e64b257d99fd059983b8abc209463c8f2641c00000000000000000053933c66aaec90c89e61ce2e169194de8bcd0636cb0225000000000000000000319c87b73707566073624974cf0f11aa225c1685480a060000000000000000008a9f417e2c7362d63e95d6fad7526d1601e169a26bfa250000000000000000003febcb780928a8f35fb988f1defa9df77b7c0009069b030000000000000000000054121e0127fd334e1a9676801ecb8daa0c3cd811580e0000000000000000002e1f62d6f9d8ff43317101bf4929c7e166b5baa95cf22b000000000000000000ea8db7544b14d5693e322f666f0f0b19a939d319390124000000000000000000cfdaac005703ce932ca7d955e21abc46f1c56db952ed150000000000000000000df113f8149bfe143bbc66539bff96a3b27cd797503b12000000000000000000b057a4a803cb6b66a05fd6614b95d68b2b2bdb8aced2010000000000000000008914d8bf2aa7bafd50c42fa04bd216dfe8d570570eee34000000000000000000abc75fe8fb567c21a355bd0c485e0a76d9861812d16f8c0000000000000000001906619a74e24c827959f87d62a8e522b18104c0c6fe0d040000000000000000201565e26b08dcae15c6f615cb26d43fda8ec590cba76e480000000000000000c853c6362816edcb8ef553e3c69faa452eac54c5829245eb018b916a000000006fe28c0ab6f1b372c1a6a246ae63f74f931e8365e15a089c68d61900000000000000000000000000000000000000000000000000000000000000000000000000
Having analyzing this payload:
Code:
f9beb4d967657468656164657273000005040000fa8a778d
7f110100
1f
0619a95d2dae0ffd58bb144890bff7b11ae2060ceb631e000000000000000000
5f30eb8f449c54d2022691d295742c7a87d375c7785d01000000000000000000
91fd7a78b9f8e3c297cb7b61d5b7858c1aeacfeabdbc02000000000000000000
18a797686e559c65db551c494781c9d3376dadea6c1215000000000000000000
467bff2cae14e26f0b078c4de62267e661536fda610022000000000000000000
e286fad54eeca7795bbbefca420c197dc1a55fff78951d000000000000000000
1d86a184718fc6c966490445845997a385b42241ef7906000000000000000000
74b5a970607dfd7efda26bc617dc4c7f8192b57368980c000000000000000000
d3ae6ba3fe0389bf3d0581e8ff1dcd6feb873e4d020a15000000000000000000
090ba32482c702f23f7c50297d4ed6327fd43f1602a71c000000000000000000
62d04bf3ab1ce424641873e380b434190e357b509e401b000000000000000000
c49a24ba246faee1c3ce6fa40ff19122a77515e542f10d000000000000000000
624a3e2b2846e2a48084e895fa467595c623a5504f2e12000000000000000000
bf8acf2c829eb75740f32049b7fd66641cd142dbf19c19000000000000000000
43706c6d5e64b257d99fd059983b8abc209463c8f2641c000000000000000000
53933c66aaec90c89e61ce2e169194de8bcd0636cb0225000000000000000000
319c87b73707566073624974cf0f11aa225c1685480a06000000000000000000
8a9f417e2c7362d63e95d6fad7526d1601e169a26bfa25000000000000000000
3febcb780928a8f35fb988f1defa9df77b7c0009069b03000000000000000000
0054121e0127fd334e1a9676801ecb8daa0c3cd811580e000000000000000000
2e1f62d6f9d8ff43317101bf4929c7e166b5baa95cf22b000000000000000000
ea8db7544b14d5693e322f666f0f0b19a939d319390124000000000000000000
cfdaac005703ce932ca7d955e21abc46f1c56db952ed15000000000000000000
0df113f8149bfe143bbc66539bff96a3b27cd797503b12000000000000000000
b057a4a803cb6b66a05fd6614b95d68b2b2bdb8aced201000000000000000000
8914d8bf2aa7bafd50c42fa04bd216dfe8d570570eee34000000000000000000
abc75fe8fb567c21a355bd0c485e0a76d9861812d16f8c000000000000000000
1906619a74e24c827959f87d62a8e522b18104c0c6fe0d040000000000000000
201565e26b08dcae15c6f615cb26d43fda8ec590cba76e480000000000000000
c853c6362816edcb8ef553e3c69faa452eac54c5829245eb018b916a00000000
6fe28c0ab6f1b372c1a6a246ae63f74f931e8365e15a089c68d6190000000000
0000000000000000000000000000000000000000000000000000000000000000
... it seems that there is an extra 24 bytes in front, with the actual (repeated) header of the message.
Then the rest seems to be a completely normal getheaders message, with protocol version 70015 followed by 31 locators and null hash stop.
I just have two questions for people more familiar with bitcoin core.
1. Is it possible that the actual bitcoin core 0.16.3 would send such a corrupt message, at some circumstances?
2. What does (the recent) bitcoin core do upon receiving such messages? How does it interpret it?
Because I'm just banning the node for sending me a corrupt message, but I'm not sure if that isn't too harsh.
Below some IP addresses of nodes sending such a corrupt messages.
Code:
GetHeaders: error parsing payload from 88.99.175.119:8333 /Satoshi:0.16.3/ EOF
GetHeaders: error parsing payload from 35.187.212.60:8333 /Satoshi:0.16.3/ EOF
GetHeaders: error parsing payload from 88.198.205.197:8333 /Satoshi:0.16.3/ EOF
GetHeaders: error parsing payload from 104.199.236.232:8333 /Satoshi:0.16.3/ EOF
GetHeaders: error parsing payload from 104.199.166.252:8333 /Satoshi:0.16.3/ EOF
GetHeaders: error parsing payload from 104.199.196.186:8333 /Satoshi:0.16.3/ EOF
GetHeaders: error parsing payload from 35.185.166.87:8333 /Satoshi:0.16.3/ EOF
GetHeaders: error parsing payload from 104.199.205.132:8333 /Satoshi:0.16.3/ EOF
GetHeaders: error parsing payload from 104.155.233.13:8333 /Satoshi:0.16.3/ EOF
GetHeaders: error parsing payload from 88.99.184.194:8333 /Satoshi:0.16.3/ EOF
GetHeaders: error parsing payload from 88.99.173.75:8333 /Satoshi:0.16.3/ EOF
GetHeaders: error parsing payload from 104.199.255.13:8333 /Satoshi:0.16.3/ EOF
GetHeaders: error parsing payload from 88.99.190.220:8333 /Satoshi:0.16.3/ EOF
GetHeaders: error parsing payload from 88.99.185.58:8333 /Satoshi:0.16.3/ EOF
GetHeaders: error parsing payload from 104.199.166.145:8333 /Satoshi:0.16.3/ EOF
GetHeaders: error parsing payload from 104.198.89.77:8333 /Satoshi:0.16.3/ EOF
GetHeaders: error parsing payload from 35.185.137.128:8333 /Satoshi:0.16.3/ EOF
GetHeaders: error parsing payload from 88.99.184.176:8333 /Satoshi:0.16.3/ EOF
GetHeaders: error parsing payload from 88.99.184.67:8333 /Satoshi:0.16.3/ EOF
GetHeaders: error parsing payload from 88.99.190.68:8333 /Satoshi:0.16.3/ EOF
GetHeaders: error parsing payload from 104.198.125.19:8333 /Satoshi:0.16.3/ EOF
GetHeaders: error parsing payload from 88.99.168.195:8333 /Satoshi:0.16.3/ EOF
GetHeaders: error parsing payload from 88.99.186.9:8333 /Satoshi:0.16.3/ EOF
GetHeaders: error parsing payload from 104.199.236.232:8333 /Satoshi:0.16.3/ EOF
GetHeaders: error parsing payload from 88.99.168.212:8333 /Satoshi:0.16.3/ EOF
GetHeaders: error parsing payload from 88.99.169.225:8333 /Satoshi:0.16.3/ EOF
GetHeaders: error parsing payload from 35.185.143.8:8333 /Satoshi:0.16.3/ EOF
GetHeaders: error parsing payload from 35.187.209.186:8333 /Satoshi:0.16.3/ EOF
GetHeaders: error parsing payload from 35.187.205.4:8333 /Satoshi:0.16.3/ EOF
GetHeaders: error parsing payload from 88.99.191.228:8333 /Satoshi:0.16.3/ EOF
GetHeaders: error parsing payload from 104.198.94.212:8333 /Satoshi:0.16.3/ EOF
GetHeaders: error parsing payload from 88.99.189.17:8333 /Satoshi:0.16.3/ EOF
GetHeaders: error parsing payload from 104.199.253.135:8333 /Satoshi:0.16.3/ EOF
GetHeaders: error parsing payload from 104.198.116.195:8333 /Satoshi:0.16.3/ EOF
GetHeaders: error parsing payload from 104.199.172.60:8333 /Satoshi:0.16.3/ EOF
GetHeaders: error parsing payload from 104.155.233.13:8333 /Satoshi:0.16.3/ EOF
I've never seen it being sent from any other node than one introducing itself as /Satoshi:0.16.3/
But there is many of them out there (the IP list above is just a fragment).
Jump to: