讨论中很重要的一点，是参考纳斯达克的激励机制

为了改善内盘流动性不足、挂单差价大、体量小的状况，最近社区在讨论做市商激励机制。

本来是BM提出一个设想，在BTS里内置（核心开发）一个激励机制，规则是挂单时间超过10分钟后被吃掉有奖，所以可以刷单挖矿。

现在讨论变得更有趣了，最优价格挂单超过一定时间就有奖，并且不需要在BTS内部实现奖励分配（不需要核心开发），而是使用外部脚本来统计发奖 https://bitsharestalk.org/index.php/topic,21544.msg281415.html#msg281415

@alt 这方面你最擅长，不管是做市机器人，还是发奖脚本，都可以参与一下。当然前提是制定一个好规则。意下如何？

localhost sent 5,000,000 BTS to poloniexwallet
4 hours ago

Quote from: abit on February 23, 2016, 11:15:44 am

Current daily budget ~= 360K including witness pay. You should take a look on this https://github.com/cryptonomex/graphene/issues/569.

Ok, but how much of that ~360k daily budget is actually dilutive (i.e. not going back to the reserve pool)?  It looks like less than 200k (correct me if I'm wrong).  Again, that is a TINY number in terms of contribution to sell pressure in the grand scheme of things.   

Quote from: abit on February 23, 2016, 11:15:44 am

Hourly budget is a linear function of amount of remaining fund in reserve pool. So the more fund in reserve pool, the more fund can be used everyday.

hourly budget = (remaining funds in reserve pool) * 3600 * 17 / 2^32

You make it sound like the funds to be used can grow without limits.  No, the size of the reserve is limited to 1.2B, which means the MAXIMUM worker dilution numbers I gave are correct. 

Theoretically the limit of reserve pool is ~3.6B, if all stake holders "use up" their stakes (for example register lots of short asset names), all stakes will go back to reserve pool.

Indeed, it is not possible to spend more than 12M BTS per month, which equates to about $1700 per day (which we are currently spending less than half of).  Again, these amounts contribute only a TINY amount of sell pressure relative to merger shares vesting and, more significantly, general crypto market sentiment which has been bearish for most of the past 2 years. 

The point is, we have a vocal segment of the community that is woefully uneducated about these realities.  And it is hurting our ability to do the kind of investment required to gain traction in the market and remain relevant in the long term.  And again, if they cannot be educated, they need to be jettisoned or at least marginalized.

Current daily budget ~= 360K including witness pay. You should take a look on this https://github.com/cryptonomex/graphene/issues/569. Hourly budget is a linear function of amount of remaining fund in reserve pool. So the more fund in reserve pool, the more fund can be used everyday.

hourly budget = (remaining funds in reserve pool) * 3600 * 17 / 2^32

Quote from: svk on February 23, 2016, 06:17:06 am

Quote from: dannotestein on February 23, 2016, 04:17:16 am

Quote from: svk on February 23, 2016, 03:23:06 am

Quote from: dannotestein on February 22, 2016, 10:40:02 pm

Here's a list of issues handled by this worker to date. Most of these were done by theoretical, other than #251 and the ones related to Windows builds, since BlockTrades has been tied up with other work for most of the period.
https://github.com/cryptonomex/graphene/issues/251
https://github.com/cryptonomex/graphene/issues/514
https://github.com/cryptonomex/graphene/issues/516
https://github.com/cryptonomex/graphene/issues/542
https://github.com/cryptonomex/graphene/issues/549
https://github.com/cryptonomex/graphene/issues/550
https://github.com/cryptonomex/graphene/issues/553
https://github.com/cryptonomex/graphene/issues/555
https://github.com/cryptonomex/graphene/issues/556
https://github.com/cryptonomex/graphene/issues/559
https://github.com/cryptonomex/graphene/issues/562
https://github.com/cryptonomex/graphene/issues/566
https://github.com/cryptonomex/graphene/issues/572
https://github.com/cryptonomex/graphene/issues/586

So is theoretical part of Blocktrades now? Or is the way this worker will function that you pay whoever happens to fix bugs in the repo? Will you pay abit too then?

Seems like a bad deal for us for the $7-8000 a month you're being paid to be honest..

No, Theo's not a part of BlockTrades. As I posted originally,  the pay was for us and for subcontractors such as CNX: I tried to be very open about that. Sometimes it will be us, sometimes CNX, and yes, potentially others as well. BM asked me to help shoulder some of the load of responding to issues in GitHub related to the blockchain as CNX was tied up with confidential transactions and other projects and Theo was basically having to manage everything on his own. That was stressing him out, and I don't blame him.

Sure, but working on graphene is already his job and I assume he's being paid by CNX to do so, so it seems weird to me that you're claiming responsibility for stuff he would have done anyway.

The backlog of issues in the graphene repo is frustratingly long and I was hoping you would add some additional manpower to it because like you say theoretical does need help there. With the kind of worker pay you're asking I think we have a right to expect you to put serious resources into this.

CNX pays Theo, and CNX has to get money from somewhere to pay him.  You can't reasonably expect CNX to commit a programmer and a 1/2 to full time work on BitShares without any compensation (the 1/2 being limited support from other CNX folks such as BM/Valentine/etc). During this pay period, the larger portion will go to CNX and we'll take a much smaller proportion for the work we did. If the total charges from CNX and BT is less than the total paid during a pay period, I'll send it back to the reserve fund. BT didn't do a lot this period because higher priority things came up, but CNX did do a lot of work, so I think the full fee is justified. Next pay period, I hope it works out differently, but I can't say for sure yet.

I don't think it's a good way if you created a worker and then distribute most of payment to CNX, especially when the worker is voted in mainly with CNX's stakes.

By the way, I'm checking the list you posted above. By now, I found that at least IMO 516 is in the scope of STEALTH feature so it should not be paid by this worker.

//Update:
If you just list the issues which have been fixed, and distribute payments to the contributors, you should not do it selectively. Anyone who has worked for the issues should get a cut, the work should not be limited to coding but also contains documentation, analysis, testing and etc.

//Update2:
With the report, can you give us a plan of next items you'll work on, and the priorities of them?

Can you please work on high priority jobs first? I'd rather like to see what progress you've made on the API server spamming issue https://github.com/cryptonomex/graphene/issues/540 , which is one of the most important reasons why people voted for you. If you've found that you're unable to fix it, please tell us rather sooner than later, so others will probably spend more time/efforts on it.

Quote from: cass on February 21, 2016, 02:34:37 pm

Quote from: meda on February 21, 2016, 02:18:11 pm

Quote from: pc on February 21, 2016, 11:34:21 am

I suppose he's pissed (and rightfully so) because he was voted out.

This could be easily a warning example for others wishing to work for BitShares.

sure .. but it is a big warning ... as developers don't want  to have to fear each day on their paid salaries ..
Some people are not creating worker props. exactly due this causality …

 
I still support Cass' worker.  Downvote the refund workers to move the goalpost.

I'd like to recommend not downvote refund workers to too low, otherwise all funds in reserve poll will be in danger.

Quote

Nasdaq is incentivizing the display of orders for (a) 500 shares at the best bid and 500 shares at the best offer, 30% of the time, and (b) 2500 shares at no wider than 2% of the best bid and 2500 shares at no wider than 2% of the best offer, 90% of the time.  I don't think we need to specify a minimum number of shares or what % of the time they need to satisfy the above conditions, but perhaps we could simply make the reward proportional to the length of time MMs have orders on the books, the size of the orders, and the distance from the price feed.  And maybe we should require that orders be on the book for a minimum period of time, as some have already suggested. 

1.Min percent of the time, 2.having the best bid (or ask) 3.For reasonable amount of shares[ probably as % of average volume in our case]. 4. With max spread [or distance from the feed for our case]

Is a very good rule imho.
Points 1 and 2 are very key elements here. It eliminates my the main issue with volume only based distribution of reward. The aim is good prices most of the time not just 10-15 min a day.

@abit and BM - how computationally doable is the above rule for a blockchain?  Keep in mind that ".Min percent of the time" may (and usually will) include  multiple orders and their sum must > Min.

I think the reward program doesn't have to be built INTO the system. Since all trading data is on the chain, any asset issuer is able to analysis the data, then make their own decisions on HOW to reward market makers on her markets. Off-chain data analysis is usually better than on-chain analysis, more flexible, easier to adjust, more cheating resistant, more people are able to help, will never affect the stability of the network. Apply a worker, distribute the funds according to pre-defined rules (better if special scripts are made already), all these can be done by the committee.