Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - Come-from-Beyond

Pages: 1 2 3 [4] 5 6 7 8
46
General Discussion / Re: An attack on DevShares
« on: February 10, 2015, 03:33:47 pm »
Delegates can easily avoid this by using relays in such a way that the delegate is connected only to relays. Relays will not forward invalid or duplicate transactions.
Valid transactions are OK provided they have sufficient trx fee. It is OK to flood the network with transactions. You'll pay the price.

However your method will reliably filter out unprepared delegates. That is a good exercise I was meaning to do for a long time.

So my attack was deflected. Ok, the next one:

Attack scenario

I flood the network with sybil nodes and start monitoring transaction flow. Using the same trick as I used for detecting the delegates, can I find the origin of TITAN-related transactions?

47
General Discussion / Re: An attack on DevShares
« on: February 10, 2015, 03:09:24 pm »
I have disabled incoming connections for my delegate.  So cfb, you have one less avenue to attack.

I was planning to use Sybil attack as part of deanonymization attack on TITAN, so I wouldn't feel myself comfortable even with disabled connections...

48
General Discussion / Re: An attack on DevShares
« on: February 10, 2015, 03:06:51 pm »
Delegate nodes should not allow incoming connections.   There is a flag set to disable incoming connections just for this purpose.

Ok, then I'll flood the network with sybil identities and delegates will connect to my nodes in 9 of 10 cases.

49
General Discussion / Re: An attack on DevShares
« on: February 10, 2015, 12:39:40 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).

50
General Discussion / Re: An attack on DevShares
« on: February 10, 2015, 12:14:02 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.

51
General Discussion / Re: An attack on DevShares
« 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:

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?

52
General Discussion / Re: An attack on DevShares
« on: February 10, 2015, 10:05:52 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.

53
General Discussion / Re: An attack on DevShares
« on: February 10, 2015, 10:00:44 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.

54
General Discussion / Re: An attack on DevShares
« on: February 10, 2015, 08:24:29 am »
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)?

55
General Discussion / Re: An attack on DevShares
« on: February 10, 2015, 07:44:26 am »
you made me curious. care to explain more? please

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. :)

56
General Discussion / Re: An attack on DevShares
« on: February 09, 2015, 11:25:26 pm »
Come-from-Beyond, here's a nice honest way to approach this: discuss with the community what kind of attack you plan on doing before executing it, and then proceed with the attack only if the devs/community tell you that your particular attack will not work.

Good idea, will do it this way.

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

57
General Discussion / Re: An attack on DevShares
« on: February 09, 2015, 09:55:24 pm »
Other possibilities are that you end up burning many BTS permanently in order to create paid delegates.

I'll start from a cheap attack. A successful disrupting of networking should lead to price decline and allow me to buy cheap coins, by selling them after the price returns to the old levels I'll get free money for more sophisticated attacks.

58
General Discussion / Re: An attack on DevShares
« on: February 09, 2015, 08:04:03 pm »
I think the lack of real socio-economic incentives within DevShares will make this data not very useful. The will of shareholders is an essential piece to this puzzle; people just don't care enough about DevShares.

For this attack experiment to be useful, people have to start caring about the security of its network. There will be 'attackers', and 'defenders', each putting value into the shares for different reasons. The upper bound of the token value will then be defined kind of like an auction of the two sides; who is willing to pay more to control the network?

I think this should be a competition, with defined rules, and money put up by both sides. The pot is split up proportionately to the donations of the side that wins. This will double as a prediction market indicator of the success of the attack.

Are you an Attacker or a Defender of DevShares?

Valid point about DevShares not being protected enough. Maybe I should begin with the hardest target - BitShares. I hope the community doesn't mind?

59
General Discussion / Re: An attack on DevShares
« on: February 09, 2015, 07:58:03 pm »
CfB, I'll vote for you as a delegate. Bring some of those nice NXT folks over here, along with the ghost of BCNext, and you'll have enough power to get hired by the blockchain.

You won't miss the java. We have all you can drink.



My agenda is slightly different than you may guess. I'm going to probe BitShares a little to figure out what elements of the whole BitShares mechanism could be implemented in hardware. Nxt and Ethereum are in the list too.

60
General Discussion / Re: An attack on DevShares
« on: February 09, 2015, 07:30:45 pm »
Good news, now I need only the documentation that is confirmed to be up-to-date.

Pages: 1 2 3 [4] 5 6 7 8