Quote from: emski on February 10, 2015, 04:49:37 PM
It would be difficult (or restrictive for end users) to implement such solution for bitshares.

This world is not ideal, it's full of trade-offs...

Right. Can you give an example?

EDIT: Reminds me when you look up 'beautiful' and the definition is 'full of beauty'

Quote from: fluxer555 on February 10, 2015, 04:36:24 PM
What is an "anti-sybil solution"? I know what sybil attacks are.

Anti-sybil solution is something that mitigates sybil attacks.

Quote from: fluxer555 on February 10, 2015, 04:36:24 PM
What is an "anti-sybil solution"? I know what sybil attacks are.

It would be difficult (or restrictive for end users) to implement such solution for bitshares.
I'm not sure if there are plans for such anti-sybil solution. I cant remember it being discussed at all.

What is an "anti-sybil solution"? I know what sybil attacks are.

Quote from: emski on February 10, 2015, 03:38:31 PM
Similar method to your next attack scenario is used to identify TOR nodes. It might work provided you have enough nodes and/or the "victim" is connected to one of them.

Ok, but it's easily fixable with an anti-Sybil solution. Just add it to the schedule if TITAN is vulnerable to such kind of attack.

Edit: Actually anti-Sybil protects against a lot of attacks, I need some time to devise something that doesn't use a Sybil attack as an opening move.

Quote from: Come-from-Beyond on February 10, 2015, 03:33:47 PM

Quote from: emski on February 10, 2015, 03:25:53 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?

Dont be so quick to mark the attack as deflected. I think 80%+ of the delegates will fall for it. It should be attempted. It might show flaws that we've never thought about.

Similar method to your next attack scenario is used to identify TOR nodes. It might work provided you have enough nodes and/or the "victim" is connected to one of them.

Quote from: emski on February 10, 2015, 03:25:53 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?

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:

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?

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.

Quote from: cube on February 10, 2015, 03:06:57 PM
I have disabled incoming connections for my delegate.  So cfb, you have one less avenue to attack.

Count me in ..

DDOSing seesnodes will just prevent new clients from finding seeds .. everyone can go on P2P style :)

Quote from: cube on February 10, 2015, 03:06:57 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...

I have disabled incoming connections for my delegate.  So cfb, you have one less avenue to attack.

Quote from: bytemaster on February 10, 2015, 02:39:39 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.

Quote from: bytemaster on February 10, 2015, 02:39:39 PM

Quote from: liondani on February 10, 2015, 12:20:23 PM

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:

Delegate nodes should not allow incoming connections.   There is a flag set to disable incoming connections just for this purpose.

then I must make a proposal ...
when a delegate runs the command:
"wallet_delegate_set_block_production "
and he change it to "true"...
the client could show a message that suggest the delegate to make exactly what you described... I assume the majority have not disabled incoming connections yet  :-[


PS
"Easily Configure a Host-Based Firewall on Ubuntu to Block Incoming Connections"
http://blog.nowherelan.com/2014/01/14/easily-configure-a-host-based-firewall-on-ubuntu-to-block-incoming-connections/

PSS what happens if somebody tries to attack all seed-nodes at once? (incoming connections must be enabled
for them)

Quote from: liondani on February 10, 2015, 12:20:23 PM

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:

Delegate nodes should not allow incoming connections.   There is a flag set to disable incoming connections just for this purpose.