Quote from: Come-from-Beyond on February 10, 2015, 12:39:40 PM

Quote from: liondani on February 10, 2015, 12:20:23 PM
How much worth is it for you when some delegates like me change their ip address about 3 times per week?

And that is  a proposal/suggested defense for all delegates  :)
Change your ip address every now and then ....  ;)

If I'm connected to almost all nodes then I'll detect your new IP almost instantly with high probability if you change IP and reconnect right away. If you wait some period of time then I have to analyze block travel graphs again, but this time I can exclude 99% of the nodes because I already know that they are not you. So the time for re-detection is very small compared to the time required for the initial delegate IP detection (it heavily depends on the total number of the nodes).

We need a mechanism to defend against spam and ddos attacks. If the network can expand to delegates beyond the 101 ie (102th, 103th...) during a spam/ddos attack, it would make it more expensive to the attacker.

Quote from: Come-from-Beyond on February 10, 2015, 12:39:40 PM

Quote from: liondani on February 10, 2015, 12:20:23 PM
How much worth is it for you when some delegates like me change their ip address about 3 times per week?

And that is  a proposal/suggested defense for all delegates  :)
Change your ip address every now and then ....  ;)

If I'm connected to almost all nodes then I'll detect your new IP almost instantly with high probability if you change IP and reconnect right away. If you wait some period of time then I have to analyze block travel graphs again, but this time I can exclude 99% of the nodes because I already know that they are not you. So the time for re-detection is very small compared to the time required for the initial delegate IP detection (it heavily depends on the total number of the nodes).

possible countermeasure: http://digitalgaia.io/backbone.html

Quote from: liondani on February 10, 2015, 12:20:23 PM
How much worth is it for you when some delegates like me change their ip address about 3 times per week?

And that is  a proposal/suggested defense for all delegates  :)
Change your ip address every now and then ....  ;)

If I'm connected to almost all nodes then I'll detect your new IP almost instantly with high probability if you change IP and reconnect right away. If you wait some period of time then I have to analyze block travel graphs again, but this time I can exclude 99% of the nodes because I already know that they are not you. So the time for re-detection is very small compared to the time required for the initial delegate IP detection (it heavily depends on the total number of the nodes).

Quote from: Come-from-Beyond on February 10, 2015, 11:58:59 AM
Attack scenario
1st phase is to find IP addresses of the delegates if they are not known:

How much worth is it for you when some delegates like me change their ip address about 3 times per week?

And that is  a proposal/suggested defense for all delegates  :)
Change your ip address every now and then ....  ;)

Quote from: xeroc ¯\_(ツ)_/¯ on February 10, 2015, 12:04:01 PM
every TX you send to the network will have to validate .. especially concerning the min. relay fee ..
my guess would be that such an attack is "expensive" .. though probably no too expensive in devshares ..
this would also show an upper limit for TPS that can be handled by that particular delegate .. results would be very interesting

This is the point of the attack. If validation requires much more resources than to send a transaction then you get a big advantage. If the ratio is 100:1 then for every cent you spend the victim will spend one dollar.

every TX you send to the network will have to validate .. especially concerning the min. relay fee ..
my guess would be that such an attack is "expensive" .. though probably no too expensive in devshares ..
this would also show an upper limit for TPS that can be handled by that particular delegate .. results would be very interesting

Attack scenario

1st phase is to find IP addresses of the delegates if they are not known:

1. Connect to as many nodes as possible.
2. Memorize time moments when nodes share a new block.
3. Analyze block travel graph trying to find its origin.

2nd phase is to check if anti-spam is used:

1. Prepare a list of already confirmed transactions.
2. Feed our own node with as many transactions as possible measuring CPU usage (signature validation, double-spending prevention, etc. require a lot of CPU cycles).

3rd phase is to disrupt unconfirmed transactions processing (if there is no anti-spam):

1. Feed the next delegate with as many transactions as possible.
2. Check if the generated block contains only a fraction of pending unconfirmed transactions.


This attack is easily counteracted with Hashcash-like spam prevention. If there is no anti-spam or it's not effective enough then the attack should be extended to DoS all delegates one by one.

So, what are odds that the attack will succeed to noticeable slow down inclusion of transactions into blocks?

Quote from: Come-from-Beyond on February 10, 2015, 10:00:44 AM

Quote from: pc on February 10, 2015, 08:53:39 AM
Many details about BitShares are still in flux, so I doubt there is up-to-date documentation on technical details. Have you checked these wikis:
https://github.com/BitShares/bitshares/wiki
http://wiki.bitshares.org/index.php/Main_Page

I didn't check them. After this case I don't trust documentation if it's not confirmed that it's actual.

You are right. I am afraid there is not much of an up-to-date technical documentation. But the two links below may be of help to you:

1) https://bitsharestalk.org/index.php?topic=5164.msg68160#msg68160
2) https://bitsharestalk.org/index.php?topic=4009.msg66308#msg66308

Quote from: bubble789 on February 10, 2015, 08:54:28 AM
So the newly designed processor which supports distrbited computing will be better? But in what sense? Efficiency, scalability or what?

How does studying dpos, nxt and ethereum help?

With the new processor computation and storage load could be split among several nodes simply by connecting them to each other. If Alice can't store the whole blockchain then she could ask Bob to help her. Everyone of them will be storing only half of the data.

The best way to study something is to try to break it. I used to use this method since early childhood. When I know more I'll be able to decide what is already provided in hardware and what should be added.

Quote from: pc on February 10, 2015, 08:53:39 AM
Many details about BitShares are still in flux, so I doubt there is up-to-date documentation on technical details. Have you checked these wikis:
https://github.com/BitShares/bitshares/wiki
http://wiki.bitshares.org/index.php/Main_Page

I didn't check them. After this case I don't trust documentation if it's not confirmed that it's actual.

So the newly designed processor which supports distrbited computing will be better? But in what sense? Efficiency, scalability or what?

How does studying dpos, nxt and ethereum help?

Quote from: Come-from-Beyond on February 09, 2015, 11:25:26 PM

0.6.0 is the latest version and https://github.com/BitShares/bitshares/archive/bts/0.6.0.zip is the source code, right?

Actually it's 0.6.1 now.

Quote from: Come-from-Beyond on February 10, 2015, 08:24:29 AM
Is BitShares code based on Bitcoin? If yes, is BitShares networking code based on Bitcoin?

No, BitShares is written from scratch. (Although it does borrow a few things from 3rd party code.)

Quote from: Come-from-Beyond on February 10, 2015, 08:24:29 AM
If no, is there a textual description of the peer communication protocol (reading code written in a language I'm not familiar with is not very easy)?

Many details about BitShares are still in flux, so I doubt there is up-to-date documentation on technical details. Have you checked these wikis:
https://github.com/BitShares/bitshares/wiki
http://wiki.bitshares.org/index.php/Main_Page

Is BitShares code based on Bitcoin? If yes, is BitShares networking code based on Bitcoin? If no, is there a textual description of the peer communication protocol (reading code written in a language I'm not familiar with is not very easy)?

I think it's an interesting approach. Let us know what you find. Nothing but good can come from this imo.

Quote from: bubble789 on February 10, 2015, 03:32:29 AM
you made me curious. care to explain more? please

Quote from: Troglodactyl on February 10, 2015, 04:31:56 AM
I appreciate Come-from-Beyond's efforts on this, and am also curious about his hardware angle.

We are developing a processor that will support distributed computing on hardware level. Here you can see what it will look like for a programmer - https://nxtforum.org/jinn/programming-model/. This implies that blockchain tech will be supported at the lowest possible level.

PS: No need to type my nickname completely, "cfb" is enough. :)