Quote from: abit on January 26, 2016, 11:21:24 am

Quote from: jakub on January 26, 2016, 10:07:30 am

Quote from: abit on January 25, 2016, 11:09:40 pm

One scenario need to be taken into consideration:
Since CERs of smart coins change frequently, there may be race conditions when a transfer operation and a price feed operation appear at a same block.
Usually a user need some seconds to confirm her transaction, or say, after the "Please confirm the transaction" page is shown, before the user clicks 'OK', if CER changed, the transaction would probably fail due to insufficient fee provided. It will cause negative user experience.

Imo this should be included in BSIP.

I have an idea to solve this issue (sure it will make the whole thing more complicated):
* For smart coins, show a message "you need to confirm in 60 seconds" on the "please confirm" page, if the user failed to confirm in 60 seconds, disable the "OK" button.
* Maintain the "worst" CERs of every smart coins in last 3 minutes somewhere in witness_node. The fee is only required to be not lower than the lowest one.

Thoughts?
@jakub @svk

@abit @svk

Maybe there is a third option:
In case CER changes before the user has a chance to confirm the transfer, just charge the user more (or less) than the amount displayed on the confirmation screen. This way it will only fail in one situation which is quite rare: if the user does not have sufficient funds in their account to cover the unexpected increase in the transfer fee.

This is obviously not perfect (as occasionally there will be a discrepancy between the transfer fee displayed on the confirmation screen and the actual fee charged) but I think it's the best solution available from the UX perspective.
I think people are usually not bothered much about the exact value of the transfer fee as long as it is within some acceptable limits.

Sorry, we're unable to do it. Fee is a field in the transaction/operation which is signed by the user. We can't modify it, nor deduct even one Satoshi more than the amount in the transaction/operation.

Another option would be deduct some fee from the fee pool, if the issuer approves. But it's hard to judge why the fee provided by the user is insufficient -- due to CER change or something else (maybe attack).

Aren't we talking about a scenario where the CER changes after the user initially submits the transaction, but BEFORE they confirm it?  If so, then can't we present them with a new confirmation which includes the updated fee and a message explaining why the fee is slightly higher than expected?

Even if the UI calculate fee again, it still has chance to fail (sure chance is lower).

I think we should consider it seriously. If we can't make it reliable enough, perhaps it's acceptable for a PC GUI user to try again, but it may be terrible for 3rd party applications which transfer tokens automatically, or for a mobile user with a slow internet connection that unable to try again very soon.

In short, try to solve the problem at the witness_node level if can't solve at protocol level.

Another thing, if the committee decided to apply percentage fee to smart coins and/or BTS, we need to notify our partners (for example exchanges) in advance, so that they have time to adjust their applications if the applications aren't compatible with percentage fee.

Good idea. I'd like to donate 300 bts for the contest.

What abit wants to say is that in the BTS/OL wallet you can flip any market by clicking the market in the top navigation bar or by searching for y:x instead of x:y market

Thanks for explanation.
But if OP wants to see something different on CryptoFresh, I have no idea..

In wallet, click on the "USD/BTS".

Quote from: abit on January 16, 2016, 04:46:34 am

@roadscape Is it ok to make a remark on the fee schedule page, so that people will know that canceling an order will get fully refund of fees for created the order?

Added this but forgot to update you.. looks alright? https://cryptofresh.com/fees

Yes I've noticed that. A bit inconspicuous imo.

Quote from: abit on January 20, 2016, 06:00:29 pm

Is it OK to list "standby" committee members and their opinions in the committee proposal page?
For example https://cryptofresh.com/p/1.10.63

Standby committee members can vote on proposals? I may be able to add this in, but would it help more than confuse the interface?

That's how the committee works..
Before the review period, both active committee members and standby committee members vote on a proposal;
during the review period, stake holders vote on the committee members.

Quote from: kenCode on January 23, 2016, 12:48:11 pm

on Cryptofresh, the "join committee" link is broken, it links to dead page: http://docs.bitshares.eu/user/Committee.html

Thanks Ken, anyone know where this page moved to? I can't seem to find it.

This http://docs.bitshares.eu/bitshares/user/committee.html ?
Maybe better to check other links on CryptoFresh as well.

Quote from: abit on January 24, 2016, 07:57:36 am

Does it make sense to add balance of committee-member account and fee pool balances of committee-member owned assets (bitUSD etc) into https://cryptofresh.com/reserve?

Yes.. I think this does make sense to add the committee-account balance to the graph.. I've added it to the list.

Quote from: abit on January 24, 2016, 07:57:36 am

Is there somewhere a chart of "current supply of BTS"?

There is currently no chart of current supply.. but I think it's generally just the inverse of the graph you see at https://cryptofresh.com/reserve. As reserve goes down, supply goes up. The only factor unaccounted for is burned BTS, but I think that's been pretty minimal thus far.

People may be lazy to calculate by themselves.. so it's best if we already have one.

Quote from: abit on January 24, 2016, 07:57:36 am

Is there a chart about network income(fees) and/or income structure?

The reserve chart shows network income minus expenditures. All collected fees go towards the reserve balance, and all worker/witness pay comes from the reserve balance iirc.

Imo an income chart is similar to the transaction/operation chart, data is classified by operations.

Thank you! 

这次发帖怎么不是逗号结尾了

Any update?