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

Pages: 1 ... 29 30 31 32 33 34 35 [36] 37 38 39 40 41 42 43 ... 69
526
Any updates or blog posts about this WP's re-organization? Waiting for bug report feedback 👍

527
Stakeholder Proposals / Re: Legal Council about BTS and No-action
« on: October 06, 2018, 01:08:04 am »
Any update on this worker proposal? Did Bittrex never respond? Users on Telegram are claiming that Bittrex is emailing them about BTS being fully delisted, not just disabled?  :-\

528
Stakeholder Proposals / Re: BSIP22
« on: October 05, 2018, 01:01:50 pm »
Supported on my side under following conditions.

1. Expiring proxy assignments (expiry period longer than proxy's decaying period)
2. Voting portal to counter voter apathy
3. Stateful notifications in UI or voting portal:
   a) Prompt user to check/refresh his voting slate (if sufficiently decayed)
   b) In case of user with proxy set, notifications when proxy modifies voting slate
Raised an UI issue for the 3rd item: https://github.com/bitshares/bitshares-ui/issues/1932

529
Stakeholder Proposals / Re: BSIP22
« on: September 29, 2018, 10:13:09 pm »
I still support the idea behind BSIP 22, albeit perhaps without the blacklist functionality.

530
Update:

Thanks to everyone + special thanks to whoever was yesterday deciding vote on worker to gets voted in.

We are creating today on github repository and team will start work/logging hours no more late than this Friday. Commits will be available only to the BitShares github team until admin decide/review what is for public release.

@abit

Pinged you on telegram - re Github Repository, Fabian is away, please check when you can.

How are things coming along? We were discussing this WP at the bitfest event last week, looking forwards to the developments.  :)

531
General Discussion / Re: Somebody might enlighten me why BSIP42 on BitUSD ?
« on: September 29, 2018, 05:22:31 pm »
If this is not stopped, this would prove that dpos is a fatally flawed system, which can be easily manipulated just like mtgox.

To be fair, you can avoid these committee issues by creating/using a 'privatized' MPA. Bonus points for transfering asset ownership to null-account for permanent configuration. Under such conditions DPOS has no influence and thus is not flawed.

532
The Whaleshares sharedrop has been extended - https://whaleshares.io/whaleshares/@whaleshares/whaleshares-sharedrop-claim-period-2-is-now-open-instructions-inside

Quote
This second claim period will run for 30 days and end on October 25 at 23:59:59 UTC. Claims will be subject to a 5% reduction during this second claim period. Example: If your original sharedrop was 100 WLS, you will now receive 95 WLS.

533
General Discussion / Re: On The Importance of Bit.GOLD
« on: September 28, 2018, 12:17:07 pm »
MCR is not the key point, how to solve the black swan is the main problem.

BSIP 18 can't solve the black swan,we need other good way to solve the black swan, let the black swan will never happen.
BSIP 18 does offer the ability to resolve global settlement aka 'black swan'. Just follow its steps and it'll reactivate.

534
General Discussion / Re: Somebody might enlighten me why BSIP42 on BitUSD ?
« on: September 28, 2018, 09:23:18 am »
If BSIP42 is implemented on bitUSD, then Hertz will probably need to change its USD:BTS price reference https://github.com/BTS-CM/scripts/issues/2

Does BSIP42 apply to all smartcoins?

535
General Discussion / Re: Economic Abstraction and Network Fees
« on: September 24, 2018, 09:44:28 pm »
The pegging thing can be solved with a program all committee members run that adjusts the fees daily to peg to USD/CNY. Obviously there's hassle in running that program and key safety is a concern as well
After BSIP 40 (https://github.com/bitshares/bsips/blob/master/bsip-0040.md) is implemented, the committee members could potentially create a key for this purpose so as to not risk the rest of their committee account's permissions/functionality.

Such a program wouldn't require a powerful VPS, and perhaps it could be run by one committee member to propose the variable change operation & be manually approved by the committee at their discretion? It'd at least take half the effort out of proposing new fees.

536
General Discussion / Re: Economic Abstraction and Network Fees
« on: September 24, 2018, 01:37:54 pm »
I think fees should still be paid in BTS, however the fees should peg against USD|CNY to be a fixed FIAT value instead of being detached from their intended value when BTS price is volatile (until the committee manually adjusts them). If the committee could set the fee values once then forget about them (until economic policy changes are proposed) that'd be great.

537
General Discussion / Re: Maker Taker Incentive/Fee parameter for Assets
« on: September 17, 2018, 02:50:07 pm »
If it was free to make and cancel market orders, then wouldn't that introduce DOS attack risk - see downloadbot spam a month or so ago for a more expensive stress test that was performed

538
In current situation, I concern more about forced settlements than black swan or global settlements. IMHO forced settlements are needed. For better user experience, perhaps we should match force-settle "orders" with limit orders when prices of limit orders are better than settlement price for the settler.

if then, why not disable force settlement and just let the users place buy orders in market if they want to convert bitCNY to BTS? what's the difference?
The difference is that without force settlement there might as well be no backing collateral, especially if nobody buys your sell order entirely within 24hrs of placing it at/around the settlement price.
It's also possible that the "if" will not happen. If the price of your order is competitive, IMHO it will be filled quite soon in a liquid market. Being able to buy a large amount without affecting the market trading price is a stupid design.

So if the 'if' will not happen, why disable forced settlement at all in the first place? Fractional reserves should not be encouraged due to shorters poor gambling choices - they should be globally settled upon rather than bailed out, as laid out in BSIP 18.

Quote
Alternative proposal - disable (permanently) the following centralized permissions in bitCNY/bitUSD:
White list
Override authority
Transfer restricted
Disable force settle
Disable confidential
This is off-topic.

I disagree, with these permissions available (including 'Disable force settle' as referenced in this topic) there is the risk of malicious actors attempting to abuse such centralized permissions.

539
In current situation, I concern more about forced settlements than black swan or global settlements. IMHO forced settlements are needed. For better user experience, perhaps we should match force-settle "orders" with limit orders when prices of limit orders are better than settlement price for the settler.

if then, why not disable force settlement and just let the users place buy orders in market if they want to convert bitCNY to BTS? what's the difference?
The difference is that without force settlement there might as well be no backing collateral, especially if nobody buys your sell order entirely within 24hrs of placing it at/around the settlement price.

Alternative proposal - disable (permanently) the following centralized permissions in bitCNY/bitUSD:
White list
Override authority
Transfer restricted
Disable force settle
Disable confidential

540
I wouldn't necessarily call this event a black swan anymore. In the past when a global settlement occurred there was no recovery mechanism for this state and thus a black swan scenario would last months. Since mid 2017 we've had BSIP 18 implemented which provides an automated global settlement recovery mechanism: https://github.com/bitshares/bsips/blob/master/bsip-0018.md

When a global settlement occurs you're unable to borrow new tokens (no issuance). You are however still able to trade it on the DEX, transfer it to anyone, settle your MPA for part of the BTS settlement pool, potentially even use it as backing collateral in an L2 MPA, so it's not completely useless in this state.

I would prefer this mechanism occurs than for force settlement to be disabled, heck I'd rather see MCR go to 101% before these centralized flags are triggered at 175%.

Quote
The proposed operation enables potential investors to "bid" additional collateral for taking over part of the debt (or all of it). When enough bids have been made to cover the full outstanding debt, and all of them are sufficiently collateralized (in terms of price feed and MCR), the settlement_fund and the bids are turned into call positions. Finally, the settlement_price is removed from the asset, which revives it.

If the available bids cover more than the outstanding debt, bids with a higher collateral/debt ratio are preferred over those with a lower ratio. The intent is to turn the competition among investors into better collateralized calls, which is in the interest of the MPA holders.

Perhaps we can incentivize investors to participate in the automated recovery mechanism somehow if you don't think it's sufficient in recovering bitCNY?

Pages: 1 ... 29 30 31 32 33 34 35 [36] 37 38 39 40 41 42 43 ... 69