There is currently an attack that is possible on the BitShares network where an attacker could:
 - use timing of block propagations to discover which are the IP addresses of delegates
 - use a DDoS attack on those delegates to take them down

This has been described more in details in this thread

This can be easily thwarted by "hiding" the delegates and making sure that it is not possible to identify the source of a newly signed block. To this end, I propose the following solution:

http://digitalgaia.io/backbone.html

tl;dr: hide the delegates behind some public relay nodes. In this way, it looks like that all blocks originate from the backbone and it is not possible to know who signed them. At first I would like to have 2 nodes in the US, 2 in Europe and 2 in Asia.


How to make it happen?

Just vote for my delegate, btstools.digitalgaia (30% payrate), and as soon as it gets elected I will buy some VPS instances for the backbone nodes and start working on setting them up, as well as developing the software required to manage those nodes.

Note that I would also set up seed nodes / chain servers, which can make initial sync to the network faster, as well as allowing nodes to get on the correct chain in case of a fork (by syncing with a chain server that's on the main fork, you also get on the main fork).


Criticism

Although a good start, this is not a perfect solution (yet!):

- Whoever runs the backbone nodes can perform the same attack on the delegates (although it is now limited to the person running the backbone nodes, instead of basically anyone simply connected to the network).

- The backbone itself can be DDoS'ed. In this case:
 - if delegates are only connected to the backbone, and the entire backbone falls, then they don't have connections anymore to the network. This can be mitigated by delegates starting to connect to normal nodes when they see that the backbone starts falling.
 - the delegates can also maintain their own set of relays instead of trusting the backbone's operator. This is more work (and more money spent on VPS), but you don't need to trust anyone else than yourself. Being able to run the software developed for the backbone would be a great help here, so even though a delegate doesn't plan on using the backbone, he could still benefit from it being developed.


Why you should trust me

I already am the author of the bts_tools python package (GitHub, BitSharesTalk), which help delegates monitor their own running instance, and I'd like to expand the functionality of the tools so as to also be able to manage a group of nodes or specialized instances of nodes in the BitShares network. In particular, I'd like them to be able to manage a configuration of seed nodes + backbone nodes as described previously.


Is this going to be a cost for the blockchain forever?

For now, I request a 30% delegate, as this would cover the cost of the VPS instances and my time for developing the software and maintaining the backbone.

Assuming that the backbone is running and fully operational, the following can happen in the future:

 - I further investigate ways to make the backbone itself completely DDoS resistant, and/or try to make it autonomous and able to replace fallen nodes automatically with nodes provided by trusted members of the community. If this is achievable, and the backbone can self-sustain itself, then my delegate's position would not be required anymore.

 - Instead of being paid as a delegate, I can monetize the backbone service by asking delegates wanting to use it to pay me directly for the service, as well as other ways of securing a delegate that I might come up with. Initially, I think that making it available for everyone is beneficial for the entire network, though, hence the delegate's position.


Conclusion

I'd like to be elected as a 30% paid delegate to implement a solution for DDoS protection for delegates, and potentially investigate more avenues in order to enhance the security of the BitShares network.

I'd also be interested to hear feedback on whether people think that the backbone is an interesting and effective solution to the DDoS problem, and if not, what could be done instead.

same issue, but I'm stuck on 381464. Weird... What's even weirder is that delegate participation is shown at 1.4%, but it doesn't look like I'm on a fork because the hash of block 381464 is 296636ff24de0725a8efcd85a54330ee4896a505, which is the same as I the one I get from my delegate which is fully synchronized... I will try to resync the entire blockchain see if it helps.

 

I think this is very important, along with your tutorial for changing the signing key of delegates. I believe both of them should be put on the bitshares wiki to be accessible by everyone, not only people reading the forums, as it allows you to have and keep a much more secure account. This allows to keep your identity super-safe (your owner key, in cold storage) while using your active key or signing key in a more dangerous environment (on a VPS, etc.). If ever something happens to one of your keys, you can always revoke it using your owner key, which is very nice.

As for the tutorial, I could follow easily (already have my devshares delegates like that), but I'm used to using the command-line client. Ultimately, I think this should be integrated in the UI in an intuitive way, but I can see why it's not a priority for now (although having it for 1.0 would be nice)

Quote from: wackou on February 19, 2015, 11:54:22 am

Released 0.1.9, which fixes the following:

- allow to pass additional args to "bts run", eg: "bts run --rebuild-index"
- fixed feeds due to bter being down
- completed (for now) documentation and tutorial
- tools display their version in footer of web pages, or using "bts version"

The next thing that I'd like to work, apart from ongoing development and maintenance of the bts_tools, would be to setup some nodes such as what is described here: http://digitalgaia.io/backbone.html
This would allow all delegates (not just mine) to be able to thwart a DDoS attack such as what is described here: https://bitsharestalk.org/index.php?topic=14150.msg184358#msg184358

However, in order to do this, I will have to get a few more VPS instances, which I will be able to afford only if my delegate gets voted in first. Remember, it's only 30% 

I think your work is very valuable and I have already voted for you.

Can you please tell us how much a "few more VPS instances" would cost?

Thanks! I'd like to start with 6 nodes, and distribute them 2 in Europe, 2 in the US and 2 in Asia. The ones I have currently are ~35$/month, they are a bit on the expensive side, but quality is top notch. They also need 4G of RAM, which is expensive on VPSes and is the limiting resource of the BitShares client as of now, so I could probably get some cheaper, but not by much. In total, that would amount to ~200$/month.

Documentation and tutorial are now mostly complete, there are no missing sections and lots of quirks have been worked out (Thanks Thom for going through it and reporting the issues).

Writing documentation is of course a never-ending task, but I feel it is now good enough that people with no a priori knowledge of the BitShares ecosystem should be able to dive into it without too many issues.

Released 0.1.8 that fixes a few quirks and annoyances that happen when setting up a new delegate (thanks Thom for the beta-testing!) and refined documentation as well as tutorial to make things simpler and avoid confusion for people not familiar with python.

Released 0.1.7, which fixes the 0.1.6 release that was kinda messed up due to being released too hastily. It should now all be working!