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 ... 43
UI team more like self oriented (Pay me and I fix any small random bugs and develop some new features from Core) and BTS++ team more focus on community need(Features that highly demanded now and Bugs that blocking users having good user experience). If UI team fail to learn from BTS++ team, then nothing will change.

The approach from BTS++ team and UI team was/is quite different. BTS++ does private discussions and management to define what they do next. Advantage is that they seek proactive feedback (and also get it because they are included in chinese community), disadvantage is that there is no transparency whatsoever to the outsider (not even I would know where to look).

The UI team has done everything managed publicly through the GitHub repository ( The advantage is full transparency and accountability, and also a public well-defined development cycle. The disadvantage is that it was expected that the community gives feedback by opening an issue in the repository (it was always open for all, anything that I have seen I have created an issue mostly myself).

In that sense, BTS++ collects private feedback proactively, and UI team collects public feedback passive (proactive for anything that I saw). So in that sense I strongly disagree with your statement I quoted above, especially since the current worker proposal addresses your concerns.

Any estimates how much it would cost to just get the most urgent done ?

Depends how you define urgent. Node connectivity seems to be a prominent issue.

The concern is UI team fail to identify what need to be done and how much the budget.

The Core worker have list down what need to be done and maximum hours for each BSIPs.

Quite different situation. Please read the UI worker proposal, intention is laid out there.

Core is following BSIPs, second step is to make UI compatible to the changes / new features of core 4.0

Any estimates how much it would cost to just get the most urgent done ?

Depends how you define urgent. Node connectivity seems to be a prominent issue.

The external exchange should have a withdraw BTS option, and hopefully documentation with it.

Normally, the process is: you First, if you don't have one, create your own BitShares account. Second, you withdraw using the account name as withdraw destination.

Technical Support / Re: Change fee schedule using wallet cli
« on: May 05, 2020, 03:58:20 am »
committee proposals have mandatory review period, thus this proposal will only execute at expiration date and if all approvals are peesent

General Discussion / Re: How to send blind transactions?
« on: April 27, 2020, 04:47:10 am »
Is there a way to send blind transactions?

Where is the implementation of TITAN?

With TITAN (Transfer Invisibly to Any Name) we have provided one layer of protection: generating a unique address for every transfer. Unlike Bitcoin, BitShares uses named accounts which makes it easier to remember and share your account name. TITAN only keeps your transaction history private, with no link to your account name, to 3rd parties. The parties to the transaction know the balance address and account name are linked. - Bytemaster's blog 12/23/2014

Blind transfers are possible, not implemented in UI. I think DEEX had an implementation.

Stakeholder Proposals / Re: Proxy:B-DEX
« on: April 07, 2020, 01:27:46 pm »
Discussion between another Dev and Abit about paying 2 times for the same audit on the core prelude worker
$75/h to abit and later for the same work 3% of all funding to bbf

You may call both "audit", but the actual tasks are fundamentally different. Happy to elaborate if interested.

Complaints on white screen issue seem to be increasing, tied to greater number of offline nodes.

Maintenance would be needed urgently

There are some, search in the repository a bit (maybe abit can comment I bet he remembers them). I had this one in my head

Thanks. We're starting off slowly, but I plan to put decent resources into this as time goes on. Some new API servers, adding liquidity, and more coins as well.


Can the elected spokesperson please mitigate the bitasset situation? Perhaps it's time to remove the 'bit' prefix to avoid users getting scammed?

There is no elected spokesperson anymore.

General Discussion / Re: Hello 👋
« on: March 14, 2020, 07:09:10 am »
How did BitShares handle the market crash?

Hi bytemaster,

my name is Stefan, I have been working closely with various workers in the past years and am currently one of the reviewers for BSIPs.

I'm gonna take a guess and assume that you are interested in how the BitAsset/SmartCoin mechanism handled the market crash. I'm gonna try to objectively give a historical overview, links to the respective BSIPs were posted before. The mechanisms work as intended as we have seen last year when bitUSD went into global settlement. It got revived again when MCR was reached and re-pegged beautifully. Still, the global settlement mechanism has flaws: Everyone gets globally settled even if its just one individual with a bad CR, instant force settlement keeps the price off peg, new debt positions cant be created and the revival process takes too long (reaching MCR instead of CR 1) which is a big hindrance for adoption and liquidity and allows individuals with deep knowledge to gain massive advantage of unbenownst everyday users.

The flaws led to (controversial) refinements of the mechanisms: Global settlement protection price. Since core changes are slow and take time and immediate action was deemed necessary, a proposal was done that witnesses should feed a price that avoids global settlement (i.e. allow intentional undercollaterization to avoid global settlement). Ontop of that, MSSR and FSO were adjusted in a way to strengthen the peg. The global settlement price caused bitCNY to not global settle when bitUSD did. Looking at the markets after this event, bitCNY did significantly better in terms of liquidity and peg. Still, intentional undercollaterization while protecting debt position holders at the cost of a manipulated feed price is no longterm solution as it lacks transparency in the DEX (the feed price does not reflect a realistic external BTS price anymore). Some ideas that came to mind: a) Implement a selective settlement mechanism that only affects positions with CR < 1 instead of all b) refined margin call mechanism where the margin call price depends on CR and MCR c) incentivize force settlement for debt positions that have CR < MCR. All of them need core change and would take significant time to implement and d) give debt position holders the ability to set a TCR > MCR (target collateral ratio), then margin calls are selling only as much to reach that TCR (is now implemented). The chosen solution of a global settlement protection price could be implemented swiftly. A BSIP was written afterwards to replace this mechanism in a more transparent way in the core, although it is not realized atm.

This year another incident happened when there were alleged shorting attacks on CEXes (i.e. influence the price feed) to cause margin calls and take advantage of debt position holders. This was possible due to many debt position holders margining to the max and keeping their CR as close to MCR as possible, with no reserves to replenish and with no proactive way to close their debt position. Debt position holders demanded swift action and since they hold significant voting weight and at that time were (still are) a big part of the BTS voting power, consequently another debt position holder protection was proposed and implemented through the price feed: namely the threshold price (highly controversial). Which really just means that, if price below threshold, then feed threshold instead. Ultimately that meant that we now had a margin call protection price as feed price and pretty much all debt position holders kept their CR exactly above that price. This threshold price is still in effect, thus the latest crash had no impact on the BitAsset mechanisms. If no price feed alterations were in effect the BitAssets would all have globally settled. So the current solution is the ultimate protection of debt position holders, which is not a surprise because they hold the largest voting weight. Now that margin calls are effectively rendered inactive some individuals shifted to massive force settlements when profit was possible. Some ideas that came to mind: a) give the debt position holders a way to manually trigger a margin call with a price they can choose (BSIP is voted in) b) refine force settlement mechanisms and give them a fee that goes to the asset owner (similar to the stability fee of DAI). The peg is of course not maintained with this measure, and has not been for a while.

There exist a multitude of other ideas for refinement of the BitAsset mechanism which are currently in drafting status but paused mostly due to the funding issues, which were also caused through the voting behavior. Essentially, majority of BTS voting power has blocked all proposals a couple months back.

I hope I could describe it properly (anyone please correct me :) ), and you also were interested in that subject. If not, and other aspects of BitShares progress interests you please let me know.

Best regards,
  Stefan (@sschiessl-bcp in GitHub, @sschiessl in Telegram)

I think it's too early to discuss the part 2 right now. Things can change a lot in 6 months. If part 1 worked well, we may start discussing part 2.

Got it.

Development for BSIP 64: Operational HTLC preimage length, HASH160 addition, and memo field (up to 12 hours)
Development for BSIP 69: Additional Assert Predicates (up to 25 hours)
Development for BSIP 74: Margin Call Fee Ratio (up to 60 hours)
Development for BSIP 77: Require Higher CR When Creating/Adjusting Debt Positions (up to 80 hours)
Development for BSIP 86: Share market fee to the network (up to 60 hours)

If we can make a small Mainnet Release for these BSIPs asap? in the next two months?
If to add features into 4.0.0 (and postpone the release date), I'd like to have "BSIP 85 Maker Order Creation Fee Discount" in it, since it's important to increase chain income.

Also "BSIP 87: Force Settlement Fee Ratio".

In addition, if to attract gateways building businesses on top of the chain, "BSIP 81 Simple Maker-Taker Market Fees" would be helpful.

Each of these changes is relatively small. However, more BSIPs means more development work and more time is needed.

First step would be to get them voted in. Please keep in mind that 1.14.158 - threshold-bsip is yet to be established, and at least I don't see it as the threshold for BSIPs as approved by BTS holders. If you do see it as the active threshold for BSIPs, please explain why.

Super, and thank you! The ElasticSearch databases are essential for proper statistic aggregation.

Both services (testing version) run on it:

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