Updates:
 - removed yunbi delegates
 - added minebitshares-reloaded: https://bitsharestalk.org/index.php?topic=14887.0

my devshares delegate (first screenshot of this thread, this post: https://bitsharestalk.org/index.php?topic=14852.msg192315#msg192315) is running 0.6.3 on debian jessie, 2-core xeon and 4G RAM.

the second and third screenshot are from my laptop which is a 2012 macbook pro, with osx 10.9, devshares 0.6.3 as well.

here's a new one from my laptop where I completely removed the devshares dir:



as you can see, it starts by synchronizing the blockchain and then the same pattern appears. Note that total average cpu usage is not really that high, it's more the pattern that bothers me (so for instance just checking your average daily usage of your server will not show any unusual cpu usage). I am pretty sure also that this appeared 3 days ago and wasn't present before.

Unrelated to this issue, but still worth noticing, is that my BitShares delegate has an extremely low cpu usage (uncannily low, actually), at the cost of a small memory leak (this appeared in bts 0.6.2, 0.6.1 had a more normal cpu usage and no mem leak). Here's a screenshot (specs are the same as my dvs delegate, 2-core xeon and 4G RAM)

yes, apart from that, everything is running smoothly, as usual. But given the looks of it, I doubt that it's a real attack, more like a bug that is somehow causing this.

Since yesterday morning, 2015-03-09 at about 07:40 UTC, my DVS delegate's CPU usage has been spiking, with a client that seems to be connecting / disconnecting a lot:



This is still going on as of today. This also happens when I run a DevShares client on my laptop, so is not restricted to my delegates. see the last 5 minutes on my laptop (no wallet open):



Is this an attack / spamming of the DevShares network? More likely, could it be some client on the network that is misbehaving (hinted at by the deconnection/reconnection)?

I have this IP that comes up in the client a lot:
Peer 46.10.205.0:32123 disconnected us: You offered us a block that we reject as invalid

Can anyone shed a light on what could be happening here?

In the meantime, people can already use the bts-proxy package I developed at the beginning of the year to achieve the same functionality:

https://bitsharestalk.org/index.php?topic=13143

It has of course a slight overhead, as it is a proxy and not integrated into the client, but it should be negligible.

I'd like to offer a 1000 BTS bounty for a member of the chinese community to translate this post in chinese and post it to the relevant subforum. I believe security is an important issue and would like to see if the chinese community thinks I should be voted as a delegate to work on those issues.

voted, it should now be active 

Btw, is Bitcoin susceptible to a similar attack?

bitcoin miners are not vulnerable, as they are not known in advance, so there's really no way to hit them. Mining pools on the other hand are vulnerable, and I remember last year that some pools used to go down every now and then due to DDoS attacks. This doesn't seem to occur so much anymore as pool operators now run them on top end hardware and/or DDoS protected VPS providers (not too sure how it works for them) although I can't say for sure, as I haven't been mining in a long time (thank god for DPoS! )