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.

you can use it for free and play with it as much as you want ..
hard forks need to be coordinated with me, but since witnesses are centralized, it shouldn't be much of an issuer

I think he wants to be a witness, is it possible in your testnet? Or we need another testnet for people who are willing to become witnesses (I think I've asked this question earlier)?

CCDK和Openleger交易平台发行了自己的代币。他虽然应用BTS的源代码，但完全抛开了BTS体系，当初按照BM的设想，凡是第三方DAC都要给BTS持有者分发股份。这个事情，坛子里的大侠们给解释一下好吗？俺不太懂！

Openleger是BTS的一个在线钱包。他们发行的代币都是在BTS系统里面运作的，不是所谓”抛开“，也不算是第三方DAC。每笔代币交易都会给BTS系统贡献手续费。

目前的reserve pool里的BTS，按每天消耗50W的话，应该还够烧5-6年（如果我没记错的话），此种情况下，根本不用过多考虑是否有收入，应该全力提升平台的使用价值。

看起来 Alt 的观点是不应该烧，应该先创造利润。
https://bitsharestalk.org/index.php/topic,21156.0.html

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!

Quote from: jakub on January 24, 2016, 04:24:03 pm

These are the next steps:
(1) Create a worker proposal for BSIP#10 - I'll do that this coming week (something like Monday or Tuesday).
And after it is accepted:
(2) Complete the coding and perform initial testing - this area belongs to abit.
(3) Review the code - this will be done by CNX.
(4) Test the implementation on the testnet.
(5) Write the documentation - I'll try to do it with abit's help.
(6) Deploy the implementation with a planned hard-fork (unless hard-fork is not necessary, I'm not sure).

And when the above is complete, we will need to:
(a) pass a committee proposal to establish the min, max & percentage values.
(b) pass another committee proposal which will switch committee-owned smart-coins to percentage-based fee scheme.

So it's quite a long way.

Sounds like a very reasonable approach ..
One advice regarding implementation though: could it be built such that people can
a) easily choose/change the fee model for their asset

GUI development is not included in the steps above. Maybe svk would help? @svk do we need to add budget for GUI development into the worker proposal? If yes, how much?

b) have an easy way of adding other fee modells as well from which issuers can choose?

I assume that you mean GUI as well? More modes would need more development work at least on the witness_node level. If GUI calculates fees independently (but not by querying witness_node), we may need more development work on GUI side.

The feature "easy to extend in the future" hasn't been added into current implementation yet, I'll add it.

c) please send a pull request to the bsip repo so that we can have it listed outside of 'issues'
d) drop me a line if you want the testnet upgraded i am looking forward zo figuring out how hard fork are actually done on a running network

How about the fund raising?

主贴已更新。原来关于refund400k的worker理解有误，已修正。感谢 @BTSdac