Quote from: svk on January 25, 2016, 10:59:40 am

Quote from: abit on January 25, 2016, 09:00:48 am

Quote from: svk on January 25, 2016, 07:42:23 am

I don't foresee this needing a lot of GUI work, a day at most (a day being 8 hours). As long as there's a flag on the asset that says what type of fee to use, and only transfers are affected, it should be trivial to add a switch to whichever transfer operation type that asset uses.

Fees need a little bit of work but not a whole lot, assuming the percent fee structure is easily available either in the asset object or in global parameters. We estimate fees using the global parameters and the operation type, so that would need to be extended to handle percent fees but that's not hard. And final operation fees are fetched from the witness node so that should not require any work on the GUI.

@svk Imo here is a list of work to be done in GUI:
* add an selection box on the "create asset" page and "update asset" page, so the issuer can set fee mode easily
* show transfer fee mode on asset details page, and maybe somewhere related
* use new operation to do all transfers (although the original operation can still be used on assets with flat mode)
* extend fee estimation to handle percent fees.
* the fee schedule page

Did I miss something?

I think Jakub will provide a document about data structure changes and API changes. Or you can dig into my code (after CNX reviewed)

Thanks for support!

OK.

How is the fee mode switched? Does it use the existing flags and permissions structure?

A new field in "extensions". Please check the examples in OP for reference (haven't been reviewed so far, so don't rely on it right now).
No permission involved so far.
Please let me know if I missed something. Thanks.

IMO the CER is a broken idea - having to specify a value for your asset when there is already a market for it is a bit mad. If there are no bids/asks, the system should just apply the base transaction fee in BTS.

Letting the fee pool run out is a better idea than raising the fee on cancels because you'll price liquidity out of the system like that.

Quote from: abit on January 23, 2016, 11:01:01 am

Quote from: jakub on January 22, 2016, 08:47:03 pm

Quote from: abit on January 22, 2016, 06:00:05 pm

According to the code, CER is a member variable of asset_update_operation, so it's required when creating such operation. For whatever reason, it has to be valid. And the asset will be updated according to the operation when the operation executes. It's current behavior/feature.

Maybe we can change the logic here:
* don't force CER to be valid when updating an asset
* if it's valid, change CER of the asset as the operation requested
* if it's invalid, don't change CER of the asset

I'll check the code to figure out whether it's possible to make it this way. Or maybe need input from CNX about why it's designed like this and whether it's proper to change the behavior.

If it's OK to change the behavior, since it's not included in BSIP10, we may need to add it. Wish it's not too complex so that I needn't to charge more for developing this feature.

I understand the above but still I don't see the reason why you need to store the CER value in the committee proposal instead of retrieving its current value directly from the asset whenever it's needed to calculate a transfer fee.

In other words, why the algorithm cannot work like this?
(1) A new transfer for asset X is about to be sent,
(2) Retrieve from the blockchain the current value of CER for asset X,
(3) Use this value to calculate the transfer fee,
(4) Charge the sender with this fee.

Is there some ambiguity about what the value of CER for asset X is at any given point in time?

Well, the committee proposal is to "enable percentage based fee" for a committee-owned asset for example bitUSD. The real operation in the committee proposal is "asset_update_operation". CER is REQUIRED to be included in "asset_update_operation", which is current feature/behavior/limitation. In short, you have to manually set/change CER to enable percentage based fee. I proposed to change this behavior in last post, but I won't make this change unless it's included in BSIP.

Once percentage based fee is enabled for bitUSD, when a transfer is requested by a user, the fee would be calculated according to the algorithm you write above.

Anyway, after manually set CER with asset_update_operation, CER would be corrected maybe after one price feed, so perhaps it's not a big deal to leave the feature unchanged.

OK, I agree that it's not a big deal at this stage.
If it becomes problematic, we can address it in the future.

Quote from: kenCode on January 26, 2016, 01:28:01 pm

Quote from: roadscape on January 26, 2016, 06:24:04 am

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.

Not sure, paging @xeroc - thanx guys

Quote from: xeroc on January 26, 2016, 02:22:52 pm

I am moving over to low-letter page names .. that's why Committee.html has changed to committee.html ... some very few pages are still left .. will make it more consistent over time ..

@roadscape - please change the big C to a little c and all is well with your links to bitshares.eu, thanx guys

@abit same results after the last instruction - rescan blockchain and all