Currently only LTMs can refer new users and earn referral income, which set a high barrier for attracting new users, and lead to bad PR. Imo we need to break this barrier, let non-LTMs be able to refer new users, which will be better PR. In the mean while, if needed, we can set other limitations, for example only LTMs can claim referral income.

//Edit: an option could be non-LTMs get less cash-back from referred users than LTMs.

do any of you recall one time BM mentioning possibly being able to change it so that not just LTM can gain from refers but regular users also?

To implement this, technically we need to:
* add a special vesting object to every non-LTM account, and
* add an operation or change current withdraw_vesting_operation so that only LTM can claim from this vesting object, and
* modify the fee split implementation so non-LTM referral income goes to this special vesting object

Thoughts?

All seed nodes, witnesses please update.

git checkout bitshares
git pull
make witness_node

Or new clone:
git clone https://github.com/bitshares/bitshares-2.git
git submodule update --init --recursive
cmake .
make witness_node

=======original post==========
{
  head_block_num: 3,067,958
  head_block_age: 21 minutes ago
}


2016-01-28T23:15:09 th_a:invoke handle_block         handle_block ] Got block: #3067957 time: 2016-01-28T23:15:09 latency: 368 ms from
: delegate-1.lafona  irreversible: 3067935 (-22)                  application.cpp:496
2016-01-28T23:15:10 th_a:invoke handle_transaction   handle_transaction ] Got 1 transactions from network                       applic
ation.cpp:545
2016-01-28T23:15:12 th_a:Witness Block Production block_production_loo ] Generated block #3067958 with timestamp 2016-01-28T23:15:12 a
t time 2016-01-28T23:15:12                        witness.cpp:185

2016-01-28T23:16:27 th_a:Witness Block Production block_production_loo ] Got exception while generating block:
3030007 insufficient_fee: insufficient fee
Insufficient Fee Paid
    {"core_fee_paid":0,"required":10000}
    th_a  evaluator.hpp:230 evaluate

    {}
    th_a  evaluator.cpp:46 start_evaluate

    {}
    th_a  db_block.cpp:653 apply_operation

    {"next_block.block_num()":3067959}
    th_a  db_block.cpp:536 _apply_block


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


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比较反感。这样，如果“商业拓展”人员不能把自己发展成为“合作伙伴”，就会缺乏推广动力。

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

[DECLARATION]

The work for this implementation is not free. In order to have it applied on the live BitShares network, it needs to be funded in some way. Suggestions on how to fund it are appreciated. I ask for 10K$, or 3M BTS. Fair negotiations are acceptable.


[MAIN]

Here is the BSIP document: https://github.com/bitshares/bsips/issues/3 https://github.com/bitshares/bsips/blob/master/bsip-0010.md

Feature briefs:
1. Added 3 global parameters which can be adjusted by the committee
  * the percentage
  * a per-transfer upper limit
  * a per-transfer lower limit
2. For each asset, the issuer can choose between flat fee mode and percentage based fee mode
3. Changed fee split schema between network and referral program: if the asset is in percentage based fee mode, the network gets an amount equals to the lower limit, referral program gets the rest.
4. Fee calculation is based on "core_exchange_rate" of the asset:
    fee = min(max(amount * CER * percentage, lower_limit), upper_limit)

Here is source code: https://github.com/abitmore/bitshares-2/tree/test-transfer-fee https://github.com/abitmore/bitshares-2/tree/dev-transfer-fee

Future developments are planned. Schedule depends on funds.


[EXAMPLES]

Here listed some sample commands:

* To set an asset to charge percentage based transfer fees:
update_asset MYASSET null {"max_supply": "1000000000000000","market_fee_percent": 0,"max_market_fee": "1000000000000000","issuer_permissions": 79,"flags": 0,"core_exchange_rate": {  "base": {    "amount": 100000,    "asset_id": "1.3.0"  },  "quote": {    "amount": 10000,    "asset_id": "1.3.1"  }},"whitelist_authorities": [],"blacklist_authorities": [],"whitelist_markets": [],"blacklist_markets": [],"description": "","extensions": [[1,{"transfer_fee_mode":"asset_transfer_fee_mode_percentage_simple"}]]  } true

* To set an asset to charge flat transfer fees:
update_asset MYASSET null {"max_supply": "1000000000000000","market_fee_percent": 0,"max_market_fee": "1000000000000000","issuer_permissions": 79,"flags": 0,"core_exchange_rate": {  "base": {    "amount": 100000,    "asset_id": "1.3.0"  },  "quote": {    "amount": 10000,    "asset_id": "1.3.1"  }},"whitelist_authorities": [],"blacklist_authorities": [],"whitelist_markets": [],"blacklist_markets": [],"description": "","extensions": [[1,{"transfer_fee_mode":"asset_transfer_fee_mode_flat"}]]  } true

* To change global percentage fee parameters:
...
       ,[
          45,{
            "flat_fee": 2000000,
            "price_per_kbyte": 1000000,
            "percentage_min_fee": 600000,
            "percentage_max_fee": 30000000,
            "percentage": 100,
            "extensions": []
          }
        ]
...
Explanation of above parameters:
* 45 is for a new operation "transfer_v2_operation". The original "transfer_operation" is incompatible
* flat_fee: 2000000 means 20 BTS of transfer fee for assets which selected flat transfer fee mode
* price_per_kbyte: no explanation
* percentage_min_fee: 600000 means 6 BTS of minimum transfer fee for assets which selected percentage fee mode
* percentage_max_fee: 3000000 means 300 BTS
* percentage: 100 means 1%
* extensions: a field for future extensions, leave it empty right now


[API CHANGES]

* added a new database API: get_operation_fee, which will simply return minimum required fee for a given operation, and won't recursively calculate if the operation is a proposal (not like get_required_fees API)

* fee_schedule::set_fee() function is no longer compatible with transfer_operation, a new function set_fee_extended() is introduced. However, the new function is not designed to be used in client applications, it's recommended to use the new get_operation_fee API to get required fee, then set the fee to the operation.


[IMPACTS TO THIRD-PARTY APPLICATIONS]

If a 3rd-party application (for example apps of exchanges, bridges and etc) is monitoring activities of an account, when a transaction which contains transfer_v2_operation(id=45) arrives, it should be treated as same as transfer_operation(id=0).

(3rd-party applications should detect/handle "transfer_v2_operation" too if they detect/handle "transfer_operation".)


[KNOWN ISSUES/LIMITATIONS]
* Unable to apply percentage base fee mode to BTS


[MISC]
Due to lack of feedback from CNX, I don't know if it's the best way to implement BSIP10.
//Update:
2016-01-21 Got in touch with CNX. No much feedback so far.
2016-01-25 Add extensions to fee parameter
2016-01-26 Made some changes on asset_update_operation: new_options can now have no CER or have an empty CER, in this case CER of asset_to_update won't change. Examples:
update_asset MYASSET null {"max_supply": "1000000000000000","market_fee_percent": 0,"max_market_fee": "1000000000000000","issuer_permissions": 79,"flags": 0,"whitelist_authorities": [],"blacklist_authorities": [],"whitelist_markets": [],"blacklist_markets": [],"description": "","extensions": [[1,{"transfer_fee_mode":"asset_transfer_fee_mode_percentage_simple"}]]  } true
or
update_asset MYASSET null {"max_supply": "1000000000000000","market_fee_percent": 0,"max_market_fee": "1000000000000000","issuer_permissions": 79,"flags": 0,"core_exchange_rate":{},"whitelist_authorities": [],"blacklist_authorities": [],"whitelist_markets": [],"blacklist_markets": [],"description": "","extensions": [[1,{"transfer_fee_mode":"asset_transfer_fee_mode_percentage_simple"}]]  } true

2016-02-12 Implemented a new operation, so the committee can change some options of the core asset (BTS), including:
  * percentage market fee / market fee cap
  * transfer fee mode
Example:
add_operation_to_builder_transaction 0 [46,{"fee":{"amount":50000000,"asset_id":"1.3.0"},"new_options":{"max_supply":"100000","market_fee_percent":10,"max_market_fee":"1000000000000000","issuer_permissions":0,"flags":0,"core_exchange_rate":{},"extensions":[[1,{"transfer_fee_mode":"asset_transfer_fee_mode_percentage_simple"}]]}}]

2016-03-01
* Code is re-branched to be based on develop branch, operation_ids changed.
* Code is deeply refactored, parameter names of fee schedule changed.
* Links in this post updated.
* Added "API changes" section in this post
* Added "impacts to 3rd-party applicaitons" section in this post

On the main page, I can see the [new] icon beside name of a sub-forum if there are new posts, for example "Witnesses", but no [new] icon on the main boards, for example "BitShares 2.0" or "General Discussion". Why?

一些消息，比较八卦，供参考。

ccedk大概从下星期开始推广法币网关，包含各种主流币种，充提手续费2-3%
mindphlux认为这个手续费太高
（注：个人推测bts2的高费率是ccedk主导出来的）


ccedk的宣传文章的德语版和意大利语版是论坛的 Chris4210X 帮忙翻译的（收费10000bts），结果被发现是机器翻译的
https://bitsharestalk.org/index.php/topic,18623.msg239291.html#msg239291
（注： Chris4210X 就是现在正在推广 OPENPOS 和新版手机钱包的那位）

fav最近没有推广bts了，因为赚不到钱，统计数据显示每个被推荐人贡献了$0.5

Why do you still have bytemaster or angle as proxy?
Why are you still voting for STEALTH and/or voting against refund400k?
Why are you not voting?
You're helping BM with his dictatorship.

If you don't like what BM did in these days, please vote against STEALTH and vote for refund400k TODAY.

Now we only have the choice of STEALTH or NOTHING.
After STEALTH is approved, we'll have next choice of WHATEVER WE DON'T LIKE or NOTHING.

If you don't vote with your stake now, you'll have to vote with your feet some day.

@jakub BM/CNX has already showed that they wouldn't bring anything else for you to vote, why not present your opinion by voting against current choice?

@theredpill please don't only vote against STEALTH, please vote for refund400k as well.

@bitcrab @Harvey @ebit where are you?

@clayop I know you're busy these days, but please take a look here.