个人一些想法，见这贴 https://bitsharestalk.org/index.php/topic,21142.0.html 。

算是给热心的朋友们一个答复。

别人不一定赞同，也没法让所有人都满意。

另：
任何人都可以发起理事会投票的，不是只有活动成员才可以。现在只能用命令行来做，还没有GUI。
对终身会员来说，发起一个投票手续费8bts。
理事会通过一个提案的成本是2BTS左右，但理事会否决一个投票的成本是10BTS起。
有心人可以利用一下这个“漏洞”，把理事会淹没在人民运动的汪洋大海中。

一些问题，思考了有一段时间，在这里写一下吧。写的不对的地方，欢迎指正。


1、屁股决定思维

* 满仓的人，自然是希望价格涨；空仓的人，不好说
* 作为用户，自然希望手续费越低越好；作为股东，自然希望公司赚钱越多越好；作为合作伙伴，那是又爱又恨


2、BTS价格/价值

除了投机因素之外，还有什么会影响BTS价格？如果把BitShares平台看成一个公司，BTS这个“币”可以看成是公司的股份。个人认为，BTS价值的基础，是公司盈利能力及分红，由于投机因素影响，价格会在价值附近波动（这个附近到底有多近？不好说。公司可能亏损，但股价没听说过有负的）。

那么，BitShares这个公司，现在到底有没有钱来分红？到底赚到钱没有？到底能不能赚钱？答案是没有、没有、还不知道。


3、系统收支分析

* 总收支

BitShares平台的收支，看这里 https://cryptofresh.com/reserve 。
第一个数字，也就是最大的数字，是“资金储备”，也就是系统一共还有多少资金用来“发工资”。现在是“收支一条线”，所有系统收到的手续费，都会归入这里，所有开支都从这里出，开支包括 witness 出块奖励和 worker 申请资金，目前每天开支上限是44.32万BTS，包括40万worker预算和4.32万witness预算。

可以看到总储备是一直在下降的。有人就会说了，每天增发了这么多？实际上，现在有个worker叫做 refund400K ，每天领出来的几十万BTS都烧掉了，并没有退回到储备池，导致总储备每天减少。这个worker其实是BM设错了。后来 xeroc 设了8个新的 worker ，其中4个refund100k，也就是每个worker领出来10万BTS退回储备池，4个burn100k也就是每个worker领出10万BTS来烧掉。个人倾向于支持新建的4个refund100k的worker。

所以这个图有点失真，看不出系统每天收入有多少，支出有多少。

//修正：refund400k的配置没有错误，每天收到的资金确实回到储备池了。总储备大约按每天12万BTS的速度下降，与witness工资+worker工资总和大致相符。

* 收入

真正的系统收入，要看这个图 https://cryptofresh.com/charts 。
这个是实实在在的，可以大概看出系统的收入点在哪里。目前最多的交易是成交和转账，平均每天交易量大约200和150，然后是调整仓位和新建账户，平均每天交易量40和20。还有一个高频交易是witness喂价，每天大约1万次。
但是这个图现在没有显示收了多少手续费。
根据现在的费率表：每次新建账户系统得19BTS，每笔转账系统得6BTS，每笔成交系统得2BTS，每次调整仓位系统得0.2BTS，每次喂价系统得0.02BTS，可以推算出现在每天系统收入大约1900 BTS

增加收入的几种方法：
- 适当推广，增加用户量/交易量
- 在用户可以忍受的前提下，适当增加手续费
- 适当降低手续费，刺激交易量提升，导致总收入提高
- 拓展其他交易的应用

所以，增加手续费还是降低手续费，主要是看能不能增加系统收入，可以进行各种尝试，但是需要根据尝试结果进行反馈调整。


如果系统每天收入能超过44.32万bts，就不用担心所谓通胀、增发问题了。



* 支出

支出包括每天40万worker预算和4.32万witness预算。除去refund worker，现在每天实际支出为12.8万BTS。

减少支出无非两种方法：
- 降低witness工资，比如降低每块奖励、延长出块间隔。需要权衡的是收入降低会不会影响到witness服务质量。
- 降低worker工资，比如减少开发工作量，降低工作单价。



* （负）利润

利润 = 收入 - 支出，目前系统每天利润是-12.6万BTS，也就是说现在BitShares系统每天亏损 12.6 万BTS。



* 其他

另外还可以看看 committee-account 这个账户的余额 https://cryptofresh.com/u/committee-account ，以及bitCNY等锚定资产的 fee pool 余额、积累手续费，比如 https://cryptofresh.com/a/CNY 。这些都属于系统资产。不过这个对于收支分析来说意义不大，因为每次积累手续费增加，fee pool会相应减少并纳入总储备；fee pool 不够时可以用 worker 方式从总储备池申请资金补充资产 fee pool ，或者理事会把积累手续费提取出来，到市场上换成BTS补充到fee pool，这是一个循环。


为了使当前的系统收支表更好看，还可以考虑的方式有：融资、借贷、打白条。



4、销售激励

目前BitShares平台对于销售的激励方式主要是推荐人制度。这个制度主要的受益者是终端销售以及合作伙伴，但是缺少对“商业拓展”的激励。

就好比一个公司又做批发又做零售，负责零售业务的销售有提成，批发业务的客户也就是零售商有提成，但是负责批发业务的销售没有提成或者只有一次性的少量提成。这就可能会导致批发业务开展不顺。

所以我认为这是导致BitShares一直缺少合作伙伴的一个原因。目前对于商业拓展的激励只有通过worker来实施，但是大众持股人对于非开发类worker比较反感。这样，如果“商业拓展”人员不能把自己发展成为“合作伙伴”，就会缺乏推广动力。

先写到这里吧，其他的以后再慢慢补充。

3. You stated $10K before, so will this raise your price to 12K or even 14K??

Depends on the complexity. I'm unable to make an estimation so far.

4. Not me. I'd rather let the code handle these intricacies. Don't sign yourself up for that job if you don't have to. I could see that becoming a real pain in yer arse after awhile. Just let the code manage it.

Adjusting of parameters will be done by the committee. With well defined rules/guidelines, it's not a hard job. Defining the rules/guidelines is a hard job though, it's what we're currently trying to do.

By the way, in regards to the parameters, I think 0.05%/1/250 is fine for me with current rate of BTS, which means 0.02 CNY of fee if value of transfer is lower than 2000 BTS or 40 CNY, and 5 CNY of fee if value of transfer is greater than 10000 CNY.

We really should be going this route with the %-based fees worker proposal. @abit, are you able to do this?

1. Nothing is impossible.
2. All my implementation is based on BSIP (feature definition). If you want me to change the behavior of my implementation, you need to change the BSIP first.
3. Your proposal will increase complexity, thus will increase time and cost for implementing/testing, and probably increase possibilities of introducing bugs into the system.
4. Manually adjusting the parameters on a monthly basis is acceptable for me.

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.

Quote from: abit on January 20, 2016, 02:11:10 pm

The 3M BTS I proposed is for "my work", which includes coding of "witness_node" and "cli_wallet", as well as "my" testing in one or more private networks and/or public networks.
...

Could you please include 'documentation for developer' into your proposal?  This is much needed if we need another developer to take over and maintain or expand the developed codes.

The word "documentation" is unbounded. My in-code document level would be no less than what we already have right now. To be honest I'm not good at writing documents, sorry. If the one who wants to "take over and maintain or expand" the codes is willing to write a document, I'm more than glad to help.

Quote from: abit on January 22, 2016, 12:20:08 am

Quote from: jakub on January 21, 2016, 10:29:47 pm

Quote from: abit on January 21, 2016, 07:58:48 pm

To whom it may concern:
It's unable to apply percentage based fee mode to BTS with my implementation. To get this feature, perhaps we need a new API. I'll dive deeper into the code..

I think we could leave BTS on the flat rate scheme and possibly lower the flat transfer fee to something like 10 BTS.
(So that we can satisfy those who say we should stay competitive with other crypto)

The crucial thing is to get the smart-coins onto the percentage-based scheme.

I confirm that percentage based fee mode can be applied to smart-coins via committee proposals. Tested.

However it's not perfect, we have to manually set core_exchange_rate in the proposal. During the proposal voting and review period, actual core_exchange_rate of proposed smart coin may have changed. When the proposal executes, core_exchange_rate in the proposal will take effect, and it's probably inaccurate.

I wonder if it's possible to set core_exchange_rate as an optional change for update_asset operation.

then the issuer can define the scheme for privatized smartcoin?

This is the specification in the BSIP (issuer can define fee_mode and core_exchange_rate but not other parameters):

global parameters which can be adjusted by the committee
  * the percentage
  * a per-transfer upper limit
  * a per-transfer lower limit
For each asset, the issuer can choose between flat fee mode and percentage based fee mode

fba方式好  基于bts系统 盈利  盈利分成 开发者拿大头即可

@sudo J神，你把钱打给我，我把代码改成手续费全归你，怎么样？

没人愿意出钱的话，只能申请worker了。