0 Members and 1 Guest are viewing this topic.
Quote from: yvv on January 26, 2018, 12:37:19 pmQuote from: xeroc on January 26, 2018, 07:15:58 amQuote from: yvv on January 25, 2018, 11:36:59 pmThere is no need for short squeeze protection imo. When a margin call happens, the system should take all orders up to a limit defined by collateral.As the name implies, the short squeeze protection is to protect shorters for overpaying in low-liquidity markets.Why to do this? Shorters deposit collateral to protect bitAssets. If a shorter can't maintain his collateral, use it all to buy back his debt. What's a problem with this?Where you sit determines what you say.Where you stand depends on where you sit.
Quote from: xeroc on January 26, 2018, 07:15:58 amQuote from: yvv on January 25, 2018, 11:36:59 pmThere is no need for short squeeze protection imo. When a margin call happens, the system should take all orders up to a limit defined by collateral.As the name implies, the short squeeze protection is to protect shorters for overpaying in low-liquidity markets.Why to do this? Shorters deposit collateral to protect bitAssets. If a shorter can't maintain his collateral, use it all to buy back his debt. What's a problem with this?
Quote from: yvv on January 25, 2018, 11:36:59 pmThere is no need for short squeeze protection imo. When a margin call happens, the system should take all orders up to a limit defined by collateral.As the name implies, the short squeeze protection is to protect shorters for overpaying in low-liquidity markets.
There is no need for short squeeze protection imo. When a margin call happens, the system should take all orders up to a limit defined by collateral.
The root problem is not the feed price and the max short-squeeze ratio.The root problem is the DEX is very very friendly to the shorter, when someone was forced liquidation, the rest of BTS should be withdraw at least 60% as a punitive margin by the DEX.
Quote from: biophil on January 17, 2018, 03:33:41 pmQuote from: Customminer on January 17, 2018, 11:09:53 amWould it also not be worth increasing the max force settle volume per 24hrs? If it's set to 1% and someone has a margin call greater than 1%, perhaps the DEX couldn't clear the margin call fast enough?I agree that max force settle volume is WAY too low. But I sort of assumed it didn't affect margin calls.FWIW, the DEX doesn't clear margin calls -- the traders do. A possibly-bigger problem is the max short-squeeze ratio is only 110%, which means that margin calls are not very aggressive and traders don't have much incentive to buy into the margin call. I suppose USD will probably black-swan today because of it. A very serious problem is that Bitshares is too shorter-friendly, at the expense of people who hold the supposedly risk-free bitassets.What would the effect of changing the max short-squeeze ratio be specifically? Would you desire it increase of decreased? All committee controlled assets use 110%
Quote from: Customminer on January 17, 2018, 11:09:53 amWould it also not be worth increasing the max force settle volume per 24hrs? If it's set to 1% and someone has a margin call greater than 1%, perhaps the DEX couldn't clear the margin call fast enough?I agree that max force settle volume is WAY too low. But I sort of assumed it didn't affect margin calls.FWIW, the DEX doesn't clear margin calls -- the traders do. A possibly-bigger problem is the max short-squeeze ratio is only 110%, which means that margin calls are not very aggressive and traders don't have much incentive to buy into the margin call. I suppose USD will probably black-swan today because of it. A very serious problem is that Bitshares is too shorter-friendly, at the expense of people who hold the supposedly risk-free bitassets.
Would it also not be worth increasing the max force settle volume per 24hrs? If it's set to 1% and someone has a margin call greater than 1%, perhaps the DEX couldn't clear the margin call fast enough?
I have read through this and I agree. I have adjusted accordingly and sped up the price publishing to every 20 minutes. (This is of course the complete opposite of what bitcrab was asking for BitCNY).
if REAL_PRICE < MEDIAN and YOUR_PRICE > MEDIAN publish price
When attempting to write a market maker the slow movement of the feed can be difficult.I would recommend the following:if REAL_PRICE < MEDIAN and YOUR_PRICE > MEDIAN publish priceif REAL_PRICE > MEDIAN and abs( YOUR_PRICE - REAL_PRICE ) / REAL_PRICE > 0.005 publish priceThe goal is to force the price down rapidly and allow it to creep up slowly. By publishing prices more often it helps market makers maintain the peg and minimizes opportunity for shorts to sell USD below the peg that the market makers then have to absorb. If we can get updates flowing smoothly then we can gradually reduce the spread in the market maker bots. *note: all prices in USD per BTSX
You don't want to publish the average "error" because then that will motivate everyone using the same feed and updating at the same time. We want diversity of opinion, we just want it more frequently to adjust to changing market conditions.
Quote from: bytemaster on September 26, 2014, 03:19:31 pmQuote from: mf-tzo on September 26, 2014, 03:16:22 pmHow can I check which delegate is doing his job properly and who isn't? How do I check what feed every delegate publishes?Basically in simple terms and assuming GUI and windows how can I check the delegates?I hope BitShares Blocks can gather feed publishing statistics for all delegates including which feeds and frequency of update.I've added the frequency of feed updates to the delegates info, it's calculated as the average of the number of feed updates over the last 48 hours. Multiple feed update transactions in the same block are only counted once, but I do count updates that are separated by a block or more for now. I can probably get update frequency for each asset added to the delegate page as well, will check that tomorrow.I picked "updates/day" as the unit as it gives the "nicest" numbers, how many updates per day do you think is good enough?
Quote from: mf-tzo on September 26, 2014, 03:16:22 pmHow can I check which delegate is doing his job properly and who isn't? How do I check what feed every delegate publishes?Basically in simple terms and assuming GUI and windows how can I check the delegates?I hope BitShares Blocks can gather feed publishing statistics for all delegates including which feeds and frequency of update.
How can I check which delegate is doing his job properly and who isn't? How do I check what feed every delegate publishes?Basically in simple terms and assuming GUI and windows how can I check the delegates?
conclusion:MEDIAN = median over all other feeds .. aka. median as announced by the wallet's asset statusYOUR_PRICE = my price according to the external feedsREAL_PRICE = (price of top) bidthanks .. gonna continue coding my script now
Quote from: bytemaster on September 25, 2014, 08:17:54 pmif REAL_PRICE < MEDIAN and YOUR_PRICE > MEDIAN publish priceif you haven't published a price in the past 20 minutes if REAL_PRICE > MEDIAN and YOUR_PRICE < MEDIAN and abs( YOUR_PRICE - REAL_PRICE ) / REAL_PRICE > 0.005 publish priceOver here ... what is the REAL_PRICE? is it (ASK+BID)/2in alt's script this seems to be the median of all feeds .. doesn't feel right because that is the same value as MEDIAN .. isn't it?I am not so sure it is implemented correctly in alt's script .. could someone shed some light over here and elaborate the above conditions ELI5?IMHO:MEDIAN = median over all other feeds .. aka. median as announced by the wallet's asset statusYOUR_PRICE = my price according to the external feedsREAL_PRICE = (aks+bid)/2
if REAL_PRICE < MEDIAN and YOUR_PRICE > MEDIAN publish priceif you haven't published a price in the past 20 minutes if REAL_PRICE > MEDIAN and YOUR_PRICE < MEDIAN and abs( YOUR_PRICE - REAL_PRICE ) / REAL_PRICE > 0.005 publish price
In the meantime:http://coins.die-schuhs.de/feed-stats.txtupdates every 60 minutes
+-------+--------------+--------------+--------------+| asset | mean | std | median |+-------+--------------+--------------+--------------+| GLD | 0.0000270644 | 0.0000008777 | 0.0000270010 || BTC | 0.0000789535 | 0.0000061072 | 0.0000815500 || SLV | 0.0018470976 | 0.0000921094 | 0.0018818273 || LTC | 0.0071947760 | 0.0003331745 | 0.0073400000 || PTS | 0.0116354766 | 0.0005481988 | 0.0119000000 || GBP | 0.0200669214 | 0.0007995986 | 0.0203000000 || EUR | 0.0257811551 | 0.0011566114 | 0.0262000000 || CHF | 0.0309064409 | 0.0011705949 | 0.0313000000 || AUD | 0.0370756933 | 0.0013665439 | 0.0377000000 || CAD | 0.0363075220 | 0.0013889951 | 0.0368000000 || SGD | 0.0415377541 | 0.0015537817 | 0.0420000000 || NZD | 0.0410527425 | 0.0016140570 | 0.0419000000 || USD | 0.0328552978 | 0.0020171120 | 0.0328000000 || TRY | 0.0735809697 | 0.0027610574 | 0.0747000000 || PPC | 0.0291100338 | 0.0029922361 | 0.0305000000 || SEK | 0.2355237872 | 0.0091941246 | 0.2390000000 || HKD | 0.2538920723 | 0.0096765011 | 0.2570000000 || CNY | 0.2021336492 | 0.0110680912 | 0.2039750000 || MXN | 0.4366923106 | 0.0166829060 | 0.4430000000 || RUB | 1.2651815951 | 0.0489347657 | 1.2800000000 || JPY | 3.5583942107 | 0.1247830890 | 3.6100000000 |+-------+--------------+--------------+--------------++-----------------------------+-----+----------+---------------------------------+| delegate | top | numFeeds | asset |+-----------------------------+-----+----------+---------------------------------+| cny.bts500 | 1 | 3 | BTC, 0.00008155 (med +0.000%) || | | | CNY, 0.20625000 (med +1.115%) || | | | USD, 0.03362023 (med +2.501%) || bts.coin | 2 | 3 | BTC, 0.00007569 (med -7.186%) || | | | CNY, 0.21500000 (med +5.405%) || | | | USD, 0.03360000 (med +2.439%) || delegate.bitsuperlab | 3 | 3 | BTC, 0.00008268 (med +1.391%) || | | | CNY, 0.20497000 (med +0.488%) || | | | USD, 0.03343200 (med +1.927%) || google.helloworld | 4 | 2 | CNY, 0.20420000 (med +0.110%) || | | | USD, 0.03200000 (med -2.439%) || bimin.coin | 5 | 3 | BTC, 0.00007569 (med -7.186%) || | | | CNY, 0.21500000 (med +5.405%) || | | | USD, 0.03360000 (med +2.439%) || usd.bts500 | 6 | 3 | BTC, 0.00008155 (med +0.000%) |
If you define what do you mean by "delegate to do his job properly" I could give better answer.About the price feeds - they are visible on www.bitsharesblocks.com and as far as I know more statistics will be implemented very soon.
Once BitSharesX gains critical mass this shouldn't be an issue. We will be the market.
You could always put a configuration to the script that assigns weight on each exchange's feed.Each delegate might want to tweak the weights depending on his "believes"/policies or whatever.
Quotewww.bitsharesblocks.com is a good start. I'm not sure what is available through client GUI.I am aware of that. I found it very nice but it doen't tell me anything about who I should vote or unvote and why... Or does it?
www.bitsharesblocks.com is a good start. I'm not sure what is available through client GUI.
Quote from: alt on September 26, 2014, 12:48:21 amQuote from: bytemaster on September 25, 2014, 09:40:08 pmActually I think it may be beneficial to discount all feeds by 0.995 to give the market makers some breathing room and provide a buffer against down trends. maybe you should change this rule at the wallet? discount the short wall price to 0.995*median pricebecause we'll disable feed price in the future right?I would rather the delegates tweak this as necessary than introduce code changes with arbitrary numbers in it.
Quote from: bytemaster on September 25, 2014, 09:40:08 pmActually I think it may be beneficial to discount all feeds by 0.995 to give the market makers some breathing room and provide a buffer against down trends. maybe you should change this rule at the wallet? discount the short wall price to 0.995*median pricebecause we'll disable feed price in the future right?
Actually I think it may be beneficial to discount all feeds by 0.995 to give the market makers some breathing room and provide a buffer against down trends.
Quote from: ripplexiaoshan on September 26, 2014, 03:04:08 pmIt seems most of the delegates are using the auto script from the Bitsuperlab, because frequent updating is hard to be maintained by manually doing it. However it means most of the price feeds will be the same, then what's the point of publishing price feeds by delegates? Why we don't just integrate one price feed in wallet?Because the consensus logic needs the feed.... because single source is too much trust in one individual... because the plan is for delegates to have increasing variety of feed publishing policies.
It seems most of the delegates are using the auto script from the Bitsuperlab, because frequent updating is hard to be maintained by manually doing it. However it means most of the price feeds will be the same, then what's the point of publishing price feeds by delegates? Why we don't just integrate one price feed in wallet?
Quote from: emski on September 26, 2014, 07:28:09 amQuote from: xeroc on September 26, 2014, 07:24:51 amhttps://github.com/xeroc/pytshares/blob/master/LICENSEMIT is fine too?Yours is OK. I'm not sure for alt's . Can it be used/modified freely ?it's free, GPL is ok来自我的 HUAWEI P7-L00 上的 Tapatalk
Quote from: xeroc on September 26, 2014, 07:24:51 amhttps://github.com/xeroc/pytshares/blob/master/LICENSEMIT is fine too?Yours is OK. I'm not sure for alt's . Can it be used/modified freely ?
https://github.com/xeroc/pytshares/blob/master/LICENSEMIT is fine too?
If you don't mind ... can I borrow these lines from you ?! :-)
Where is the script, and is it easy to implement?
Quote from: bytemaster on September 25, 2014, 07:54:46 pmWhen attempting to write a market maker the slow movement of the feed can be difficult.I would recommend the following:if REAL_PRICE < MEDIAN and YOUR_PRICE > MEDIAN publish priceif you haven't published a price in the past 20 minutes if REAL_PRICE > MEDIAN and YOUR_PRICE < MEDIAN and abs( YOUR_PRICE - REAL_PRICE ) / REAL_PRICE > 0.005 publish priceThe goal is to force the price down rapidly and allow it to creep up slowly. By publishing prices more often it helps market makers maintain the peg and minimizes opportunity for shorts to sell USD below the peg that the market makers then have to absorb. If we can get updates flowing smoothly then we can gradually reduce the spread in the market maker bots. *note: all prices in USD per BTSXWhen the price is rising don't publish more often than every 20 minutes... I also reduced the publishing load if you are already above the median when the price is rising... republishing your price will not move the median so don't bother.
When attempting to write a market maker the slow movement of the feed can be difficult.I would recommend the following:if REAL_PRICE < MEDIAN and YOUR_PRICE > MEDIAN publish priceif you haven't published a price in the past 20 minutes if REAL_PRICE > MEDIAN and YOUR_PRICE < MEDIAN and abs( YOUR_PRICE - REAL_PRICE ) / REAL_PRICE > 0.005 publish priceThe goal is to force the price down rapidly and allow it to creep up slowly. By publishing prices more often it helps market makers maintain the peg and minimizes opportunity for shorts to sell USD below the peg that the market makers then have to absorb. If we can get updates flowing smoothly then we can gradually reduce the spread in the market maker bots. *note: all prices in USD per BTSX
Quote from: bytemaster on September 25, 2014, 07:54:46 pmThe goal is to force the price down rapidly and allow it to creep up slowly. If in future one bitAsset >Asset (bitUSD>USD)we would recommended to do the opposite, right?
The goal is to force the price down rapidly and allow it to creep up slowly.