Quote from: DACSunlimited on August 20, 2014, 12:46:26 AM

Quote from: alt on August 18, 2014, 12:21:25 AM
except the average price.
I think the other important thing is about the method to create asset.

for safe reason, we have to set a maximum price limit for short.
for now, the short price means  two things:
1. how much XTS do you need to freeze , for  lend the assets from BTS bank.
2. how much XTS can you buy , with these assets you just lend out.

In fact , we only want to set a limit for the first thing, how much you can lend from the bank.
we don't need  set a limit for the second thing.

but now, we have limit both. so something maybe not work find. for example:
at the first day, delegate set a price about 0.1 bitgold/XTS. we have more than 25 assets, maybe nobody short bitgold success.no bitgold issued.
at the second day, the price of XTS is double.
what situation we will have to face? people want to sell/bid/short XTS at price 0.2biggod/XTS, but no bitgold issued, so nobody can bid. and nobody can short, from the  system limit of the price, you can only short at price 0.13bitgod/XTS. If the price never down, the trade maybe never active.

So I prefer to change the short  operation to only issue asset, without must bid XTS immediately. you can bid anytime.
and some other  advantages with this change.
for example, I think USD will up from GOLD. so I can lend bitGOLD, and use this bigGOLD to buy USD directly.

If the price of XTS double, I think the delegate's can update their feeds to start, maybe I did not get your idea?

once the feed price is success(maybe  50 delegate now?) input, the limit price will change to use the average price instead of feed price.

Quote from: bytemaster on August 20, 2014, 12:48:21 AM

QuoteI have some XTS, now I want to buy something with bitUSD, what should I do?
for now, I have to short first, than ask. I have to wait for a good price.
with the new rule, I just need to  lend bitUSD from system with my backup XTS, I don't need to trade to somebody else.
It will be very easy to use bitUSD.

Just sell your XTS for BitUSD... no need to short first.

no, I want to short bitUSD....
I don't want to buy it now....
If I can, I will always lend bitUSD from the system  ;D

QuoteI have some XTS, now I want to buy something with bitUSD, what should I do?
for now, I have to short first, than ask. I have to wait for a good price.
with the new rule, I just need to  lend bitUSD from system with my backup XTS, I don't need to trade to somebody else.
It will be very easy to use bitUSD.

Just sell your XTS for BitUSD... no need to short first.

Quote from: alt on August 18, 2014, 12:21:25 AM
except the average price.
I think the other important thing is about the method to create asset.

for safe reason, we have to set a maximum price limit for short.
for now, the short price means  two things:
1. how much XTS do you need to freeze , for  lend the assets from BTS bank.
2. how much XTS can you buy , with these assets you just lend out.

In fact , we only want to set a limit for the first thing, how much you can lend from the bank.
we don't need  set a limit for the second thing.

but now, we have limit both. so something maybe not work find. for example:
at the first day, delegate set a price about 0.1 bitgold/XTS. we have more than 25 assets, maybe nobody short bitgold success.no bitgold issued.
at the second day, the price of XTS is double.
what situation we will have to face? people want to sell/bid/short XTS at price 0.2biggod/XTS, but no bitgold issued, so nobody can bid. and nobody can short, from the  system limit of the price, you can only short at price 0.13bitgod/XTS. If the price never down, the trade maybe never active.

So I prefer to change the short  operation to only issue asset, without must bid XTS immediately. you can bid anytime.
and some other  advantages with this change.
for example, I think USD will up from GOLD. so I can lend bitGOLD, and use this bigGOLD to buy USD directly.

If the price of XTS double, I think the delegate's can update their feeds to start, maybe I did not get your idea?

Quote from: alt on August 19, 2014, 06:42:12 AM

Quote from: alt on August 18, 2014, 12:21:25 AM
except the average price.
I think the other important thing is about the method to create asset.

for safe reason, we have to set a maximum price limit for short.
for now, the short price means  two things:
1. how much XTS do you need to freeze , for  lend the assets from BTS bank.
2. how much XTS can you buy , with these assets you just lend out.

In fact , we only want to set a limit for the first thing, how much you can lend from the bank.
we don't need  set a limit for the second thing.

but now, we have limit both. so something maybe not work find. for example:
at the first day, delegate set a price about 0.1 bitgold/XTS. we have more than 25 assets, maybe nobody short bitgold success.no bitgold issued.
at the second day, the price of XTS is double.
what situation we will have to face? people want to sell/bid/short XTS at price 0.2biggod/XTS, but no bitgold issued, so nobody can bid. and nobody can short, from the  system limit of the price, you can only short at price 0.13bitgod/XTS. If the price never down, the trade maybe never active.

So I prefer to change the short  operation to only issue asset, without must bid XTS immediately. you can bid anytime.
and some other  advantages with this change.
for example, I think USD will up from GOLD. so I can lend bitGOLD, and use this bigGOLD to buy USD directly.

another advantage is we don't need the init  feed price from delegate. wait all 101 delegates to input the feed price for all 25 assets is not an easy work.
we can just set a safe price(very low) limit at the source code.
because these price don't need very exactly. It  have no influence on the bid price, just reduce the issue speed at the first 360 blocks.

another advantage
I have some XTS, now I want to buy something with bitUSD, what should I do?
for now, I have to short first, than ask. I have to wait for a good price.
with the new rule, I just need to  lend bitUSD from system with my backup XTS, I don't need to trade to somebody else.
It will be very easy to use bitUSD.

Maybe we could think bitusd is important than btsx.
This is wrong. If USA begin monetary reform，then bitusd will reform again.
So btsx is important .
bitusd can be roll-back like nxt.

Quote from: alt on August 18, 2014, 12:21:25 AM
except the average price.
I think the other important thing is about the method to create asset.

for safe reason, we have to set a maximum price limit for short.
for now, the short price means  two things:
1. how much XTS do you need to freeze , for  lend the assets from BTS bank.
2. how much XTS can you buy , with these assets you just lend out.

In fact , we only want to set a limit for the first thing, how much you can lend from the bank.
we don't need  set a limit for the second thing.

but now, we have limit both. so something maybe not work find. for example:
at the first day, delegate set a price about 0.1 bitgold/XTS. we have more than 25 assets, maybe nobody short bitgold success.no bitgold issued.
at the second day, the price of XTS is double.
what situation we will have to face? people want to sell/bid/short XTS at price 0.2biggod/XTS, but no bitgold issued, so nobody can bid. and nobody can short, from the  system limit of the price, you can only short at price 0.13bitgod/XTS. If the price never down, the trade maybe never active.

So I prefer to change the short  operation to only issue asset, without must bid XTS immediately. you can bid anytime.
and some other  advantages with this change.
for example, I think USD will up from GOLD. so I can lend bitGOLD, and use this bigGOLD to buy USD directly.

another advantage is we don't need the init  feed price from delegate. wait all 101 delegates to input the feed price for all 25 assets is not an easy work.
we can just set a safe price(very low) limit at the source code.
because these price don't need very exactly. It  have no influence on the bid price, just reduce the issue speed at the first 360 blocks.

Quote from: vikram on August 19, 2014, 01:14:29 AM

Actually, this does make me aware of a potential bug. It may be the case that this line: https://github.com/BitShares/bitshares_toolkit/blob/03dbac9fd674aae29d50cdab2685318c47c89667/libraries/blockchain/market_engine.cpp#L324 should come AFTER this line: https://github.com/BitShares/bitshares_toolkit/blob/03dbac9fd674aae29d50cdab2685318c47c89667/libraries/blockchain/market_engine.cpp#L390

I will verify with bytemaster.

This doesn't look like a bug in code that will affect validation, though it may effect how price charts are rendered eventually.   I will refactor the code to correct our price histories, but it shouldn't result in a hard fork.

To have the highest bid be that high would be incredibly expensive for the attacker as he would have to pay that price for the entire depth of the market.   He would also have to use USD rather than shorting because you cannot create a short oder at prices that high.   

Quote from: alt on August 19, 2014, 01:16:00 AM

Quote from: vikram on August 19, 2014, 12:57:50 AM

Quote from: alt on August 19, 2014, 12:51:14 AM
I think the average price is still not hard to manipulate
current_bid->get_price() maybe very high

Code Select Expand


                // TODO: rename avg_price_24h to average_price_1h
                market_stat->avg_price_24h.ratio *= (BTS_BLOCKCHAIN_BLOCKS_PER_HOUR-1);

                // limit the maximum movement rate of the price.
                if( _current_bid->get_price() > min_cover_ask )
                   market_stat->avg_price_24h.ratio += _current_bid->get_price().ratio;
                else
                   market_stat->avg_price_24h.ratio += min_cover_ask.ratio;

                if( _current_ask->get_price() < max_short_bid )
                   market_stat->avg_price_24h.ratio += _current_ask->get_price().ratio;
                else
                   market_stat->avg_price_24h.ratio += max_short_bid.ratio;

                market_stat->avg_price_24h.ratio /= (BTS_BLOCKCHAIN_BLOCKS_PER_HOUR+1);


When this section of code is called, all matching orders should have been filled. So any high bids would have been filled, leaving current_bid at this point to be the highest bid which no longer matches any asks.

In other words, the average only counts the average of the spread on each block after filling all orders.

but when somebody is attack,  the high bid  maybe not been filled.  for example, the attacker maybe can  fill all ask order under price 100USD/XTS

This is a good point if you can completely control the order book you are right....  we need to guard it on both sides. 

Quote from: vikram on August 19, 2014, 12:57:50 AM

Quote from: alt on August 19, 2014, 12:51:14 AM
I think the average price is still not hard to manipulate
current_bid->get_price() maybe very high

Code Select Expand


                // TODO: rename avg_price_24h to average_price_1h
                market_stat->avg_price_24h.ratio *= (BTS_BLOCKCHAIN_BLOCKS_PER_HOUR-1);

                // limit the maximum movement rate of the price.
                if( _current_bid->get_price() > min_cover_ask )
                   market_stat->avg_price_24h.ratio += _current_bid->get_price().ratio;
                else
                   market_stat->avg_price_24h.ratio += min_cover_ask.ratio;

                if( _current_ask->get_price() < max_short_bid )
                   market_stat->avg_price_24h.ratio += _current_ask->get_price().ratio;
                else
                   market_stat->avg_price_24h.ratio += max_short_bid.ratio;

                market_stat->avg_price_24h.ratio /= (BTS_BLOCKCHAIN_BLOCKS_PER_HOUR+1);


When this section of code is called, all matching orders should have been filled. So any high bids would have been filled, leaving current_bid at this point to be the highest bid which no longer matches any asks.

In other words, the average only counts the average of the spread on each block after filling all orders.

but when somebody is attack,  the high bid  maybe not been filled.  for example, the attacker maybe can  fill all ask order under price 100USD/XTS

Quote from: vikram on August 19, 2014, 12:57:50 AM

Quote from: alt on August 19, 2014, 12:51:14 AM
I think the average price is still not hard to manipulate
current_bid->get_price() maybe very high

Code Select Expand


                // TODO: rename avg_price_24h to average_price_1h
                market_stat->avg_price_24h.ratio *= (BTS_BLOCKCHAIN_BLOCKS_PER_HOUR-1);

                // limit the maximum movement rate of the price.
                if( _current_bid->get_price() > min_cover_ask )
                   market_stat->avg_price_24h.ratio += _current_bid->get_price().ratio;
                else
                   market_stat->avg_price_24h.ratio += min_cover_ask.ratio;

                if( _current_ask->get_price() < max_short_bid )
                   market_stat->avg_price_24h.ratio += _current_ask->get_price().ratio;
                else
                   market_stat->avg_price_24h.ratio += max_short_bid.ratio;

                market_stat->avg_price_24h.ratio /= (BTS_BLOCKCHAIN_BLOCKS_PER_HOUR+1);


When this section of code is called, all matching orders should have been filled. So any high bids would have been filled, leaving current_bid at this point to be the highest bid which no longer matches any asks.

In other words, the average only counts the average of the spread on each block after filling all orders.

Actually, this does make me aware of a potential bug. It may be the case that this line: https://github.com/BitShares/bitshares_toolkit/blob/03dbac9fd674aae29d50cdab2685318c47c89667/libraries/blockchain/market_engine.cpp#L324 should come AFTER this line: https://github.com/BitShares/bitshares_toolkit/blob/03dbac9fd674aae29d50cdab2685318c47c89667/libraries/blockchain/market_engine.cpp#L390

I will verify with bytemaster.

 +5%

Quote from: alt on August 19, 2014, 12:51:14 AM
I think the average price is still not hard to manipulate
current_bid->get_price() maybe very high

Code Select Expand


                // TODO: rename avg_price_24h to average_price_1h
                market_stat->avg_price_24h.ratio *= (BTS_BLOCKCHAIN_BLOCKS_PER_HOUR-1);

                // limit the maximum movement rate of the price.
                if( _current_bid->get_price() > min_cover_ask )
                   market_stat->avg_price_24h.ratio += _current_bid->get_price().ratio;
                else
                   market_stat->avg_price_24h.ratio += min_cover_ask.ratio;

                if( _current_ask->get_price() < max_short_bid )
                   market_stat->avg_price_24h.ratio += _current_ask->get_price().ratio;
                else
                   market_stat->avg_price_24h.ratio += max_short_bid.ratio;

                market_stat->avg_price_24h.ratio /= (BTS_BLOCKCHAIN_BLOCKS_PER_HOUR+1);


When this section of code is called, all matching orders should have been filled. So any high bids would have been filled, leaving current_bid at this point to be the highest bid which no longer matches any asks.

In other words, the average only counts the average of the spread on each block after filling all orders.

I think the average price is still not hard to manipulate
current_bid->get_price() maybe very high


                // TODO: rename avg_price_24h to average_price_1h
                market_stat->avg_price_24h.ratio *= (BTS_BLOCKCHAIN_BLOCKS_PER_HOUR-1);

                // limit the maximum movement rate of the price.
                if( _current_bid->get_price() > min_cover_ask )
                   market_stat->avg_price_24h.ratio += _current_bid->get_price().ratio;
                else
                   market_stat->avg_price_24h.ratio += min_cover_ask.ratio;

                if( _current_ask->get_price() < max_short_bid )
                   market_stat->avg_price_24h.ratio += _current_ask->get_price().ratio;
                else
                   market_stat->avg_price_24h.ratio += max_short_bid.ratio;

                market_stat->avg_price_24h.ratio /= (BTS_BLOCKCHAIN_BLOCKS_PER_HOUR+1);