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 - emski

Pages: 1 2 3 4 5 6 7 [8] 9 10 11 12 13 14 15 ... 86
106
General Discussion / Re: An attack on DevShares
« on: February 10, 2015, 03:38:31 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.

107
General Discussion / Re: An attack on DevShares
« on: February 10, 2015, 03:25:53 pm »
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.

108
Stakeholder Proposals / Re: xeroc's price feed broken
« on: February 10, 2015, 08:09:09 am »
It seems I messed this up from the beginning and no one noticed .. I wonder if a.delegate.charity every published a feed!?
Gonna add this to the README .. delegates need funds to publish slates ..

My version of the script is OK. My payaccount is empty though. Are you sure your environment is OK ?

109
General Discussion / Re: Volume And Peg Question
« on: February 05, 2015, 10:55:19 pm »
Just to be clear, do they account for 'volumes of each exchange' or do they account for 'volumes of each trade at an exchange'?  Because my feed script takes into account all trades and takes the average of a window of the last X amount of BTS traded.

My modification accounts for total volume of the exchange for each pair. It uses the volume of each exchange to weight the prices. It is good to have variety in calculations.

I wonder who will run all the scripts and compare the outputs. I'm curious if we have different feeds and how much they differ. However this is a discussion for another thread.

110
You would miss blocks until you are voted out if you take it offline. Doesn't this cause problems? Security, forking, transaction times... Etc.? If we had this happening frequently and with multiple delegates, this couldn't be a good thing, right?

After 0.6.x, active delegates can retract their accounts in order to instantly (at the start of the next round) be removed from the active 101.

Marvelous!

111
Stakeholder Proposals / Re: New Delegate Feed Script
« on: February 05, 2015, 10:14:09 pm »
I'd recommend against such frequent pooling of exchanges.
You might get a ban if you have so much requests.
You dont need to update the feeds that often anyway.

112
General Discussion / Re: Volume And Peg Question
« on: February 05, 2015, 10:11:46 pm »
I'm not 100% sure if this is relevant, but I took an initial stab at a feed script that factors in volume a couple months ago:

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

Contributions welcome.

As far as I know all scripts (alt's xeroc's and mine) account for volume of the exchanges. Though alt's script behaves a little differently.
Current discussion is for the question in OP on one hand.
And on the other: should we include internal (for bitshares blockchain) volume and price.

113
General Discussion / Re: Economics of subsidized mining pool
« on: February 05, 2015, 04:33:19 pm »
I think this is a great idea.
If it was for other cases it might be considered as "unfair".

114
General Discussion / Re: Volume And Peg Question
« on: February 05, 2015, 04:04:09 pm »
The idea of the peg is that it is attached to something (USD). If there is no USD then there will be no need for feeds for bitUSD.

115
Stakeholder Proposals / bitOil Suggestion
« on: February 05, 2015, 03:32:15 pm »
As there is some demand for bitOil as discussed here: https://bitsharestalk.org/index.php?topic=13992.0

I'd like to propose the following:
Quote
We could create multiple market issued assets like ( Crude Oil Mar 15 (CLH15.NYM) ) and publish feeds.
But the client should be modified so that:
1 All feeds are invalid 1 day before target date.
2 All positions are closed 1 day before target date.
[\quote]

116
[17:16:10] Emil Velichkov: there are multiple delegates running 2 instances
[17:16:10] Emil Velichkov: dev0.nikolai
[17:16:10] Emil Velichkov: delegate.rgcrypto
[17:16:10] Emil Velichkov: dev-trial.misc.nikolai
[17:16:10] Emil Velichkov: Why ?

117
General Discussion / Re: Volume And Peg Question
« on: February 05, 2015, 02:10:03 pm »
That's why price feeds should include internal market price of the asset weighted by volume. With growing relative volume of the internal market the external price becomes less relevant.

I'm not sure if current price feed scripts do this though.

In my example internal volume is irrelevant.
By definition the peg "links" the price of a bitAsset (bitA) to the price of an external asset (A). If we account the internal volume (of bitA) in the feeds then the bitA will not be pegged to A.

I disagree. Think of the original concept without feeds. The bitA will be pegged to A simply because market makers make profit by maintaining the peg. As long as the majority has enough faith in the peg it will stabilize itself.

Accounting the internal price would help to gradually switch (with growing volume) to a system without feeds.

Even if we could account for all trades worldwide (BTS <-> A) and devise "perfect" feed the question in OP will still be valid. Shorting bitA is not the same as selling A for BTS.

Lets look into the case where we account the internal volume into the feeds. Imagine the following:
We account for worldwide trade volume of A  - $1mil.
We have internal market volume of bitA of $10 mil
In the real world the price of A is X BTS.
In the internal exchange the price of A is X+Y BTS.
With current implementation feed price should be X. In your proposal to account for the internal volume feed should it be ~ X+Y  [ derived from (11X + 10Y)/11 ].
Which one looks better for you ?

118
General Discussion / Re: Volume And Peg Question
« on: February 05, 2015, 01:09:29 pm »
That's why price feeds should include internal market price of the asset weighted by volume. With growing relative volume of the internal market the external price becomes less relevant.

I'm not sure if current price feed scripts do this though.

In my example internal volume is irrelevant.
By definition the peg "links" the price of a bitAsset (bitA) to the price of an external asset (A). If we account the internal volume (of bitA) in the feeds then the bitA will not be pegged to A.

119
General Discussion / Volume And Peg Question
« on: February 05, 2015, 08:49:17 am »
Imagine the following situation:
We have a real-world market for the asset A. Total world trade volume of asset A is $1 mil.
Bitshares implements bitAsset for A (bitA) and it starts trading on the blockchain.
Lets say there are shorts for total of $100k .

The question is: When it would be profitable for an entity (mr. X) to manipulate real world price of A (buying selling on the real exchange) so that for any dollar spent on the real world exchange X gets at least $1 worth of value on the Bitshares blockchain.

120

In addition, I'm not comfortable giving a third-party script access to my delegate's private key.


I'm no genius in programming , but even I could spot a command that can get your private key if it's in the script .
It's really that simple .

Neither was I comfortable... That is why I reviewed and modified the script.

Pages: 1 2 3 4 5 6 7 [8] 9 10 11 12 13 14 15 ... 86