Abusive and broken bitcoin seeders
7 messages, 30 to 31 Jul 2014. Started by Jeff Garzik.
Jeff Garzik, Wladimir J. van der Laan, Pieter Wuille, Neil Fincham, Addy Yeow, Mike Hearn, Jameson Lopp
Seeing this on one of my public nodes: 2014-07-30 13:13:26 receive version message: /getaddr.bitnodes.io:0.1/: version 70001, blocks=313169, us=162.219.2.72:8333, peer=11847 2014-07-30 13:13:33 receive version message: /getaddr.bitnodes.io:0.1/: version 70001, blocks=290000, us=162.219.2.72:8333, peer=11848 2014-07-30 13:14:21 receive version message: /getaddr.bitnodes.io:0.1/: version 70001, blocks=313169, us=162.219.2.72:8333, peer=11849
That is abusive, taking up public slots. There is no reason to connect so rapidly to the same node.
Other seeders are also rapidly reconnect'ers, though the time window is slightly more wide: 2014-07-30 13:09:35 receive version message: /bitcoinseeder:0.01/: version 60000, blocks=230000, us=162.219.2.72:8333, peer=11843 2014-07-30 13:12:42 receive version message: /bitcoinseeder:0.01/: version 60000, blocks=230000, us=162.219.2.72:8333, peer=11846
The version message helpfully tells me my own IP address but not theirs ;p
Quoted text (1 line)
> The version message helpfully tells me my own IP address but not theirs ;p
Try -logips. Logging peer IPs was disabled by default after #3764.
BTW I'm seeing the same abusive behavior. Who is running these? Why do the requests need to be so frequent?
Wladimir
At least my crawler (bitcoin-seeder:0.01) software shouldn't reconnect more frequently than once every 15 minutes. But maybe the two connections you saw were instances?
On Wed, Jul 30, 2014 at 3:50 PM, Wladimir <laanwj@gmail•com> wrote:
Quoted text (19 lines)
>> The version message helpfully tells me my own IP address but not theirs ;p > > Try -logips. Logging peer IPs was disabled by default after #3764. > > BTW I'm seeing the same abusive behavior. Who is running these? Why do > the requests need to be so frequent? > > Wladimir > > ------------------------------------------------------------------------------ > Infragistics Professional > Build stunning WinForms apps today! > Reboot your WinForms applications with our WinForms controls. > Build a bridge from your legacy apps to the future. > http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists•sourceforge•net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
I am also seeing these quite bit on my p2pool box.
Right now it is just a bit of (mostly) harmless spam but in the future I can see this kind of thing being used in DDOS attacks and "deep scans" to gather information to be used to harm the bitcoin network. We could easily block them but then they would just start to spoof regular clients.
We cannot even authenticate them by asking something that only a full client would know because that would catch out clients sync'ing the blockchain and SPV clients.
I suspect it is something that is going to have to be dealt with in the future (I just don't know how yet). We could start by dropping connections that send incorrect information (IP addresses of 0.0.0.0 or our own IP).
Neil
On 31 July 2014 01:57, Pieter Wuille <pieter.wuille@gmail•com> wrote:
Quoted text (41 lines)
> At least my crawler (bitcoin-seeder:0.01) software shouldn't reconnect > more frequently than once every 15 minutes. But maybe the two > connections you saw were instances? > > On Wed, Jul 30, 2014 at 3:50 PM, Wladimir <laanwj@gmail•com> wrote: > >> The version message helpfully tells me my own IP address but not theirs > ;p > > > > Try -logips. Logging peer IPs was disabled by default after #3764. > > > > BTW I'm seeing the same abusive behavior. Who is running these? Why do > > the requests need to be so frequent? > > > > Wladimir > > > > > ------------------------------------------------------------------------------ > > Infragistics Professional > > Build stunning WinForms apps today! > > Reboot your WinForms applications with our WinForms controls. > > Build a bridge from your legacy apps to the future. > > > http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk > > _______________________________________________ > > Bitcoin-development mailing list > > Bitcoin-development@lists•sourceforge•net > > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > > > ------------------------------------------------------------------------------ > Infragistics Professional > Build stunning WinForms apps today! > Reboot your WinForms applications with our WinForms controls. > Build a bridge from your legacy apps to the future. > > http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists•sourceforge•net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development >
I believe the requests Jeff is seeing came from my crawler although anyone could be running it (https://github.com/ayeowch/bitnodes) since there is no IP address in the log to confirm the source of the requests.
This is a sample log of an actual request from my crawler at 148.251.238.178 : *2014-07-30 22:43:54 receive version message: /getaddr.bitnodes.io:0.1/: version 70001, blocks=313244, us=X.X.X.X:8333, them=0.0.0.0:0 <http://0.0.0.0:0>, peer=148.251.238.178:47635*
Currently, the crawler takes a full snapshot of the network of reachable nodes as soon as it is done with previous snapshot. I want to be able to diff between the snapshots to get the join and leave nodes periodically. Each full snapshot is taken on average between 3 to 4 minutes hence the requests that you see from the crawler every 3 to 4 minutes. I have a task in my schedule ( https://github.com/ayeowch/bitnodes/wiki/Schedule#crawlpypingpy) to improve upon this method by skipping a new connection with currently reachable nodes while still being able to perform the diff.
On Wed, Jul 30, 2014 at 11:22 PM, Jeff Garzik <jgarzik@bitpay•com> wrote:
Quoted text (28 lines)
> Seeing this on one of my public nodes: > 2014-07-30 13:13:26 receive version message: > /getaddr.bitnodes.io:0.1/: version 70001, blocks=313169, > us=162.219.2.72:8333, peer=11847 > 2014-07-30 13:13:33 receive version message: > /getaddr.bitnodes.io:0.1/: version 70001, blocks=290000, > us=162.219.2.72:8333, peer=11848 > 2014-07-30 13:14:21 receive version message: > /getaddr.bitnodes.io:0.1/: version 70001, blocks=313169, > us=162.219.2.72:8333, peer=11849 > > That is abusive, taking up public slots. There is no reason to > connect so rapidly to the same node. > > Other seeders are also rapidly reconnect'ers, though the time window > is slightly more wide: > 2014-07-30 13:09:35 receive version message: /bitcoinseeder:0.01/: > version 60000, blocks=230000, us=162.219.2.72:8333, peer=11843 > 2014-07-30 13:12:42 receive version message: /bitcoinseeder:0.01/: > version 60000, blocks=230000, us=162.219.2.72:8333, peer=11846 > > The version message helpfully tells me my own IP address but not theirs ;p > > -- > Jeff Garzik > Bitcoin core developer and open source evangelist > BitPay, Inc. https://bitpay.com/ >
Quoted text (4 lines)
> > I suspect it is something that is going to have to be dealt with in the > future (I just don't know how yet). >
The web has managed to survive despite constant fast crawls being the norm for the past 10 years or so. I wouldn't worry too much about this unless you can prove that a big chunk of your nodes resources are going to answering ver queries.
I may be able to provide some insight regarding request volume / abuse via my public node at http://statoshi.info
My node receives a 'getaddr' request about every 50 seconds: http://i.imgur.com/XEpnWfG.png
In terms of the 'addr' messages that it sends out, the volume is also low. This graph has 'inv' and 'tx' sent messages for comparison. http://i.imgur.com/keyitsS.png
Now, these are just message volume and not actual resource usage, but I have a feeling that 'getaddr' requests are not resource intensive since it shouldn't be reading from disk. I could look into adding timing metrics around these requests if you think it could be useful.
- - Jameson
On 07/31/2014 06:37 AM, Mike Hearn wrote:
Quoted text (26 lines)
>> >> I suspect it is something that is going to have to be dealt with in the >> future (I just don't know how yet). >> > > The web has managed to survive despite constant fast crawls being the norm > for the past 10 years or so. I wouldn't worry too much about this unless > you can prove that a big chunk of your nodes resources are going to > answering ver queries. > > > > ------------------------------------------------------------------------------ > Infragistics Professional > Build stunning WinForms apps today! > Reboot your WinForms applications with our WinForms controls. > Build a bridge from your legacy apps to the future. > http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk > > > > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists•sourceforge•net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development >