Seeing this is a key decision that will affect third parties (merchants, ..) etc. I suggest that you draft a BSIP for it. This was it becomes solidified by the community and also serves as a point of reference for outsiders.

I added my comments in the issue.

Just to note that bione.cc is going to list BTS and open the bitcny trading zone.

bione.cc is a new exchange but have top 20 trading volume, though some of the volume is not that reliable, but I feel like top 50 is their right place.

They ask for 7 ETH plus 300k BTS for listing fee and marketing.

How about pay 500K BTS in total for all cost including the compensation for lobbyists?

Do you have a link to them in CMC?

Added https://bitsharestalk.io/bitshares/@sschiessl/bitshares-ui-release-candidate-181121-20181114t161558963z-post

The manager feature allows that a user locks away funds and grants the manager control over it. The user can only withdraw with a delay, which in turn means that the manager has enough time to react to it and adjust the balance if needed.

This can for example be used as a deposit into a CEX. Locking away funds on the BitShares Blockchain represents a deposit into the CEX, which allows the user to trade on the CEX, while the CEX does not need to be the custodian of the funds. The CEX settles the trades of the user onto the Blockchain every X amount of time and recognizes when the user wants to withdraw. With the built-in delay the CEX has enough time to settle the user balance on the blockchain according to internal trades.

Other use cases are possible too, like a promotion programm within the BitShares Blockchain (lock away asset X and gain Y% every Z time period), and of course a savings account (lock away asset X, can only be accessed after waiting 3 days, no manager required)

Quote from: sschiessl on November 06, 2018, 10:32:34 am

Chance for speculator to exploit debt position owners is implicit arbitrage and will be healthy for the market. How can it be exploited? The Force Settlement Offset is 5%, which should make it hard enough. Please elaborate

Force settlement is a feature that must remain available IMO, it is a worst-case scenario measure. It will certainly never be used in a liquid market, the UI prominently shows the user if the market is the better choice.
But if there is any incident that the market crashes, the force settlement option must be available and I would not want to wait for anyone to activate it then.

I own a debt position with CR=3, now you force me to sell the collateral to you with a under market price, this is not exploiting, are you joking?

I simply haven't understood yet how the exploitation works.

Just to clarify for me, example from your picture:
latest price (LP) = 0.675035
settlement price (SP) = 0.670566
force settlement offset multiplier (FSOM) = 0.95
Now assume I hold 100 bitCNY

• I can sell on free market and get 100 * 1 / LP=148.14 BTS
• I can force settle, now assume it would happen instantly then I get 100 * 1 / SP=149.12*FSOM=141.67 BTS

As the holder of the bitCNY this only gives me profit if LP * FSOM > SP. But, as long as LP > SP, the holder of the margin position would have a loss compared to latest price, i.e. someone could pay to hurt you (unlikely to happen though). This does not take the force settle delay into account.

I think I understand the situation now, and I would agree this should be adressed. But not by disabling force settlement, but by ensuring that LP * FSOM <= SP is maintained.

Just in general: The flag "DISABLE FORCE SETTLING" should be able to do exactly that, maybe a core dev could confirm. Not that I advertise this solution.

price feeding become more critical after the BSIP42 implementation.

currently the feed price in CNY is 4.5% lower than the latest price, in the past several days the gap was even bigger.


according to the negative feedback logic, it's possible and acceptable that the feed price be lower than the latest price, but we still need to review whether there are some flaws here that may hurt the ecosystem.

there are always some price gap between DEX and CEX, if the gap is not big enough, we can not expect the gap be removed by arbitrage，if the CEX price keeps a little lower than DEX price, the negative feedback algorithm may respond and reduce the feed price, in some extreme situation the reducing feed price may trigger continuous margin call which is not so necessary.

while reducing feed price directly lead to margin call that force sell, increasing feed price do not lead to force buy, witnesses need to be more careful while reducing the feed price.

I suggest that we can introduce a "protect discount limit" in the price feeding algorithm, if the smartcoin discount is not bigger than this limit, algorithm does not start the negative feedback process.

that's why gdex-witness updated the algorithm as below:

Code: [Select]

Pdex：BTS price in DEX in smartcoin
Pf: current feed price
premium: current premium

scale=1;
get Pdex, Pf, premium;

while True:
   
   get Pdex, Pf, premium;
   if 0.3%>premium>-0.5%: ##just adopt the current median if the absolute premium is low enough.
       feed price = Pf;
   else:
       feed price = Pf*(1+premium*scale);
   time.sleep(120); ##update every 2 minutes.
I also suggest that each witness publish the price feed algorithm, which can help proxies to review and evaluate the witness work.

The ''protect discount limit' is -0.5% is that algorithm?

Sophisticated API calls for visualization would indeed be great!

Quote from: pc on November 04, 2018, 12:41:25 pm

Quote

a. ElasticSearch Plugin
https://github.com/bitshares/bitshares-core/wiki/ElasticSearch-Plugin
ES has been a good plugin. It has provided a very comprehensive unstructured storage and an indexing of historical transactions and objects on BTS. By the way, ES gives us a lot of inspiration.
But there are some shortages,

1) Cumbersome. ES requires extremely high performance for the server;
2) The synchronization time is too long, lacking of a fast-built solution. Currently, as far as we know,  the usage of ES Plugin for data query or data analysis is limited.
3) Some content (such as related information of the transaction) is not structured. Indeed, ES stores them directly, which cannot satisfy some customized queries.

What makes you think that Postgresql will be better in that regard?
* ES scales easily and was designed for cluster installations, postgres wasn't.
* Synchronization time for Postgresql will most likely be even longer than for ES.
* Operation details will be structured in ES plugin in upcoming release.

1. ES is easy to scale, but the amount of BTS data may not be more than billion in short time. In addition, after optimization, Postgresql still has a good performance in the billion level. In order to facilitate data backup and quickly data recover, we hope to adopt a light database solution, so we use pg to solve problems.

2. Our plan is to develop Bishares' C++ Plugin for synchronizing data to PostgreSQL and also for batch submission. It should be similar with the current ES plugin speed.
However, based on the PostgreSQL solution, we can provide a faster recovery service. Users can download the compressed data package and import it directly. It does not need to synchronize from scratch. This is why it could reduce the synchronization time.

3. In our worker proposal, in addition to structuring, we prefer to optimize and customize APIs for specific analysis requests.

For solving query problems, it's not bad to finalize APIs in different way and let them provide various data, isn't it?

1. Both PostGre and ElasticSearch are suitable for storing that amount of data, whereas the most benefit of ElasticSearch is the built-in clustering, advanced text search capabilities (Lucene) and optimization for simultaneous queries. PostGre is an old horse which offers many synergies and pure SQL queries, which many devs are used to. I'd argue that to build a plugin that offers new API you could use either or.

2. ES allows snapshoting as well https://www.elastic.co/guide/en/elasticsearch/reference/current/modules-snapshots.html

3. Customized APIs for specific analysis requests can also query the ES database

We have analyzed the existing technical solutions in BTS community:

a. ElasticSearch Plugin
https://github.com/bitshares/bitshares-core/wiki/ElasticSearch-Plugin
ES has been a good plugin. It has provided a very comprehensive unstructured storage and an indexing of historical transactions and objects on BTS. By the way, ES gives us a lot of inspiration.
But there are some shortages,

1) Cumbersome. ES requires extremely high performance for the server;
2) The synchronization time is too long, lacking of a fast-built solution. Currently, as far as we know,  the usage of ES Plugin for data query or data analysis is limited.
3) Some content (such as related information of the transaction) is not structured. Indeed, ES stores them directly, which cannot satisfy some customized queries.

b. python wrapper
https://github.com/oxarbitrage/bitshares-explorer-api
Python wrapper has provided a good API, its backend relies on ElasticSearch and some self-built data. However, the data is imported in a timed manner, which means that data is not real-time (it updated every day). As the data increasing, each import will take more time. have been some very mature projects in the community that  provides us with valuable experience, but there are still a lot of problems  to be solved in the current programs.

My 2 cents to the above:

a.

• 1) What are the minimum requirements you found to run ES?
  
• 2) and 3) Snapshoting and new version of ES plugin solves those issues
  

b.

• The link you have provided is the open-explorer API, which uses PostGre as well in its backend. Here, data is periodically imported. This is planned to be switched to real-time with the finalization of the es_objects plugin
• The python wrapper you mention directly queries ES, which is built for real-time data. A deployed example can be found here
  

In general another solution to data storage can be interesting to explore. I think a lot of synergies can be created if an abstract RESTful API is defined (for example using Swagger). It would allow to be also included in the python wrapper, which would instantly create compatibilities. What are your thoughts on that?