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

Pages: [1] 2 3 4 5 6 7 8 ... 18
2
General Discussion / Re: suggest to disable forcesettlement for bitCNY
« on: November 12, 2018, 08:08:48 pm »
Alternatively, we can keep the 5% offset, but ask witnesses to set a % bottom (in comparison to trading price) when feeding BTS/bitCNY price.
Do you mean with a % bottom to aim for a constant but positive premium? Or what is the bottom?

3
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)

4
Technical Support / Re: NOBLE/BTS - There are issues here
« on: November 10, 2018, 11:10:52 pm »
It does show it on the exchange, but not prominently enough.

Go to https://wallet.bitshares.org/#/market/NOBLE_BTS and find the "Buy Noble" panel. There is a line with the market fee.

5
General Discussion / Re: suggest to disable forcesettlement for bitCNY
« on: November 07, 2018, 08:14:16 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:
Code: [Select]
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.

6
General Discussion / Re: suggest to disable forcesettlement for bitCNY
« 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.

7
General Discussion / Re: price feeding review
« on: November 06, 2018, 09:04:48 am »
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?

8
1) I apology that we haven't synced an ES node with full bitshares data, just built on our own private chain. I saw on the wiki (https://github.com/bitshares/bitshares-core/wiki/ElasticSearch-Plugin) that ES recommends at least 32G of memory based on the data amount three months ago. In the past three months, the number of BTS operations exploded. In contrast, https://bts.ai uses PostgreSQL to store hundreds of millions of data, including ROR's Web Server and Cache. The memory is not as higher than 4G. ES is a great solution, but it's really too heavy for us. We are going to run a ES full node to test the minimum requirements .

The indices of ES are all stored on the hard drive not in RAM. The 32G memory requirement is probably just a best guess and not thought through, the RAM maintains the general performance and some caching, but not the actual chain data. Servers with 64G RAM, 500G hard drive and 1 GBit connectivity are still below 70 USD in Europe, I don't think anyone thought too much of the different pricing in other regions there.

9
Sophisticated API calls for visualization would indeed be great!

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

Quote
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?

10
Bsip 42 has an adjusted definition of when it is considered active, please take a moment to read upon it.

11
Which is your most popular show so far?

12
Stakeholder Proposals / Re: [Witness Proposal] gdex-witnness
« on: October 31, 2018, 08:03:38 am »
What are your thoughts on enforcing not a 1:1 peg, but one with a constant premium? There have been discussions on it in telegram and I tend to agree that a small constant positive premium will behave more stable than 1:1.

In your algorithm that would correlate to something like

Code: [Select]
   ...
   target_premium = 0.5%; // arbitrary number, chosen here to reflect the lower bound of allowed premium to be 0

   get Pdex, Pf, premium;
   premium = premium - target_premium;
   ...

13
Another update folks!

The 4th invitation slot goes to MichaelX who will be joining us in Athens.

I think this will be a fairly good mix after all.

a committee member
a major proxy
the core team coordinator
and the voted spokesperson

I can confidently say we'll all do our best to represent BitShares and spread the word as much as we possibly can while there.

That is really an awesome group, thanks to all willing to participate and represent the community!

Do you know if they do recording of the talks?

14
Yes, marketing!

In the past OpenLedger has advertised with incorrect statements, I would like to propose some kind of review system for anything published. This review should not be about layouting or formatting, but merely about the content facts.

Pages: [1] 2 3 4 5 6 7 8 ... 18