[Worker Proposal] New BitShares Core Dev

[Chris4210]

  thanks for the updates. Keep up the good work Alfredo.

[oxarbitrage]

updates from last week in the bitshares core. the following are issues/pull request where i participated during last week:

https://github.com/bitshares/bitshares-core/issues/292

following the efforts to reduce memory usage in nodes while still be able to serve basic api usage @abitmore proposed a new feature in the form of command line to just get an X amounts of operations from each account significantly reducing the node memory usage.

details in pull request:

https://github.com/bitshares/bitshares-core/pull/297

i tested and it is working great, the pull request is about to be merged to master.

https://github.com/bitshares/bitshares-core/pull/296

i am after a few new api calls for the explorer to relate history that is right now not possible and needed for explorers and other apps. the pull still need some more work that it is in progress and requires first that pull #297 gets merged as it will use an index created in that code.
after #297 is merged i will upload new code in a new pull request with updated calls.

this new calls can be a generic way to solve:

https://github.com/bitshares/bitshares-core/issues/243

https://github.com/bitshares/bitshares-core/pull/288

reviewing pull request from @pmconrad. still in progress.

https://github.com/bitshares/bitshares-core/issues/195

making progress in this issue, awaiting further response to make a small code change to solve it.

[oxarbitrage]

almost forgot to place some updates here.

i started to code a bitshares blockchain explorer in this last week and i invested most of time on that. the details can be found in the bitshares explorer post at:

https://bitsharestalk.org/index.php/topic,24097.0.html

all updates in regards to the blockchain explorer will go in that thread.

as the community is really needing an opensource blockchain explorer i decided to take this past week to get the project started.  even that i was fully in the explorer there were a few core issues where i was involved:

https://github.com/bitshares/bitshares-core/issues/291
tested, closed, false alarm.

several issues related to the node memory were updated and discussed this last week as, the main memory discussion issue in github is at:
https://github.com/bitshares/bitshares-core/issues/192

@pmconrad made a pull request to add partial operations support to the node(https://github.com/bitshares/bitshares-core/pull/289).
@abitmore is propossing a node setup where only the last X transactions or blocks from an account may be returned.
@ElMato and I were discussing in telegram alternatives to export the history data to some kind of database. this will also release the nodes from memory usage.

https://github.com/bitshares/bitshares-core/pull/288
this is a great addition by @pmconrad that allows to disable/enable plugins from the command line. please note that in order to leave the history plugins our of a node and reduce memory the nodemaster need to edit code main.cpp witness_node file and comment them out, compile and run again.
the pr will allow to do this from command line, i am in the process of reviewing it for merging.


So this starting week i am getting back fully to the core issues and try to make some more significant advances.

[oxarbitrage]

Hi guys, here some updates of the last week of work, no new code was merged to the core this time but advance as always was done.

////////////////////////////
https://github.com/bitshares/bitshares-core/issues/201

research on this issue revealed that the fix was already commited to master. @vikram closed.

////////////////////////////
https://github.com/bitshares/bitshares-core/issues/162

@pmconrad suggest to make the fees fully work in the  cashback_test, if the hardest option of the 3 presented last week. working on it.

////////////////////////////
https://github.com/bitshares/bitshares-core/issues/177

significant amount of time of the week was invested in this issue: alternatives to dropping connections(witness shutdown). discussions were done in telegram. expect alternative is good enough for this purposes except that it can't retain command history, waiting for an issue close.

////////////////////////////

The following issues are in folder and they will be probably have answer in the next few days leading to possible closes and pull requests:

https://github.com/bitshares/bitshares-core/issues/71
https://github.com/bitshares/bitshares-core/issues/25
https://github.com/bitshares/bitshares-core/issues/136

////////////////////////////

[Permie]

I like how this sounds @Yao

...but I need reminding what the vote threshold is for a worker proposal to get filled?

There must be a minimum amount of votes required to pass a worker?
Does this minimum amount of votes set a floor price of worker funding, according to your model?

D Task: 0.025%, means bounty amount = 93,750 BTS

i.e if a Class D task is up for vote, the minimum amount of bts this worker could get paid (and yet still get funded) would be
FUNDING,F = (F = 0,) or F > [minimum number of votes required to pass worker] * [93,750bts]

?

[Yao]

In my opinion the worker proposal system is fine the way it is... It is similar to the way many companies compensate their employees, via stock options.  It provides incentive for the developers to do good work and promote the ecosystem.

Startups provide stock based compensation because it works.  It brings in the best talent, because it promotes greed.  Also, it's not like this recent price pump didn't factor in the worker proposal system.  The market knew that the dev's would get a dramatic bump in salary but bought anyway.

Agree. The limited shares in the reserve pool (reserve balance is less than 1 billion now ) should not be measured in Fait ( USD, CNY or others ), BTS should be distributed in the manner of startups' stock.

Here are some views:

A normal flow of bounty is:
Shareholders feedback the demand firstly, then the committee is responsible for summarizing these demands and organizing voting to create bounty, then waiting for people to submit their work, then shareholders decide whether the work is qualified for bounty or not.

刚想到一个 bounty 金额由投票决定的思路：

首先，根据 bounty 任务的难度和工作量进行分级，给定不同的赏金系数。


任务等级分类参考（从高到低）：

SS级：也是最高级，在不同地方用法不同，但通常在关乎生死存亡阶段使用。属于只许成功不许失败的任务。
S级：此类任务通常不被使用，这类任务一般是关乎上级或者公司的直接利益的任务。
A级：使用较为频繁，通常是于珍贵物品或上级人物直接或间接挂钩。
B级：使用最为频繁的一类任务。也是最常见的一类任务。
C级：较为简单的任务。也是除了SS级最少发的任务。
D级：作为最简单的任务，这类人物属于刚加入的新手。也被叫做休闲任务。

以当前的“预算项目（worker）”投票情况来说，#1 worker 获得 375,721,810 BTS支持。我们可以以此为基础来确定每一个任务的 bounty 赏金系数。例如：

SS 级任务：1%，意味着 bounty 金额为：375w BTS
S 级任务：0.5%，意味着 bounty 金额为：187.5w BTS
A 级任务：0.25%，意味着 bounty 金额为：93.75w BTS
B 级任务：0.1%，意味着 bounty 金额为：37.5w BTS
C 级任务：0.05%，意味着 bounty 金额为：18.75w BTS
D 级任务：0.025%，意味着 bounty 金额为：9.375w BTS


其次，有两种方案来投票确定每一个任务的 bounty 赏金额度：

方案一：股东投票决定奖金额度

创建一个预算项目（worker），根据任务等级描述 bounty 系数，系数乘以支持该任务的总票数等于完成任务后可领取的 BTS 数量。


方案二：基础悬赏金额 + 额外奖励

由理事会根据任务难度议定 bounty 基础金额（在比特股这家公司里面，理事会成员的责任感更强，要么是大股东，要么看好公司前景，理事会来商定 bounty 的基础金额是有说服力的）。

额外的奖赏额度则由全体股东投票，同样采用方案一的方式，但 bounty 系数要降低到大约 1/10，系数乘以支持该任务的票数等于额外奖赏。在任务进行中，领取任务者随时公布动态，股东根据情况予以投票支持（类似打赏），额外的奖赏代表股东对该任务完成度的认可度！


在上面的两个方案中，BTS 股东支持这个项目就投票，投票就代表愿意稀释（从储备资金池支取 BTS），每一票（每一股 BTS）都代表要花钱，每一票都代表股东的意愿。至于手里总共有 100w 票但只想出 30w 票权重的投票支持，那就自己单独把 300w 票现转到自己的小账号里去投票支持对应的 bounty 项目。

以上想法，仅供交流讨论！


I've just had a great idea that could determine the amount of bounty for each task by the VOTE of  BTS holders:

First of all, according to the classification of bounty task difficulty and workload, given different reward coefficient.

Task level from high to low like this:

SS: Highest tasks, is of vital importance must not fail.
S: Super tasks, related to the vital interests of the company.
A: Major tasks.
B: Frequent tasks.
C: Relatively simple tasks.
D: The simplest tasks, leisure tasks.

In the current project proposal vote situation, #1 worker got 375,721,810 BTS support, we can use this result as a base to determine the bounty coefficient for each task.

For EXAMPLE:

SS Task: 1%, means bounty amount = 3,750,000 BTS
S Task: 0.5%, means bounty amount = 1,875,000 BTS
A Task: 0.25%, means bounty amount = 937,500 BTS
B Task: 0.1%, means bounty amount = 375,000 BTS
C Task: 0.05%, means bounty amount = 187,500 BTS
D Task: 0.025%, means bounty amount = 93,750 BTS


Then, voting to determine the amount of bounty for each task in two ways:

Plan A: only BTS holders vote to determine the amount

Creat a project proposal(worker), describe the task level and the bounty coefficient,
[total number of votes]*[bounty coefficient]=[the amount of BTS for bounty].


Plan B: Basic task reward + Extra bonus

Committee discuss to determine the basic reward according to the difficulty of the task
( in the Company, BitShares DAC, committee members are more responsible, because they are either major shareholders, or is extremely optimistic about the prospects of BitShares, they discuss the amount of the decision is convincing).

Extra bonus can refer to Plan A to creat a project proposal(worker), but need to reduce the coefficient to about 1/10,
[basic task reward]+[total number of votes]*[bounty coefficient]=[the amount of BTS for bounty].
In the task, at any time to publish the dynamic, BTS holders to vote according to the circumstances, extra bonus on behalf of shareholders to the task completion degree of recognition.

In Plan A and B, BTS holders who support the bounty task, vote it. Vote for it means they they are willing to accept dilution ( agree to withdraw BTS from reserve pool), 1 BTS 1 vote, each BTS vote represents the wishes of shareholders. If I have 1,000,000 BTS in my account A, but I only want to vote it 300,000 BTS, I can transfer 300,000 BTS to account B then vote it.

Above is my idea for exchange discussion.

[lil_jay890]

In my opinion the worker proposal system is fine the way it is... It is similar to the way many companies compensate their employees, via stock options.  It provides incentive for the developers to do good work and promote the ecosystem.

Startups provide stock based compensation because it works.  It brings in the best talent, because it promotes greed.  Also, it's not like this recent price pump didn't factor in the worker proposal system.  The market knew that the dev's would get a dramatic bump in salary but bought anyway. 

[Pheonike]

I have no problem with the deal in its terms. I just want know if Munich paid their half in bts. Since it was a 50/50 contract. If Munich paid less then we should be returned the difference.

Sent from my SM-N920T using Tapatalk

[oxarbitrage]

when i started to work in here by @kenCode i saw the worker proposal for me, i had no idea of what it was, and it was going to be impossible for me to discuss the terms or setup one and get it voted in at that moment. Bitshares Munich did it.
Not much time later i realized that the idea was awesome, i saw other worker proposals like @sivek and @xeroc and i wanted to be like them in the future, have a worker proposal for good money that will keep me busy and stable for months while doing what i do best and what i enjoy more: hard coding work.
i agree in what it was stated before by @Geneko , if a developer is speculating and winning like it is my case now then everything will be great, if a developer is speculating and losing he will probably need to move on. speculation is for people who haves money, that is why i think now that the worker proposal in bitusd could be a good option to consider specially for new developers trying to get in. but i do think that now, not when i started as i didn't even know what bitusd was at that point.

bitshares speculation for a developer is not pure speculation as you are an insider, you know whats going on and you have some idea that prices may go higher, yuou are actually helping to get the prices higher. for some developers that already know how bitshares works being in this kind of speculation may be very good, for someone outside the community it may be safer to have usd.  i personally believe in bitshares and for prices to keep raising.

anyways, it is a complex subject, i can help with my view but not much more than that.

[Permie]

i agree that future worker proposals by me or actually by anyone should be in usd. i never had the intention to speculate here, the fact is i found at with all this by pure luck. i have no problem on closing current proposal now and go with a new one if needed. in the other hand the extra compensation will be used to bring more value to the community by working more, much more happy. it is hard to quantify  this additional value in money but you can be sure i will be always grateful with this community and be forever loyal.

this is a new milestone in my life and my professional career that will definitely want to develop here, not only for the payment of the current worker, i made a commitment with myself pretty much since i started, i want to be here.

will i make the same work for less money ? a reasonable hourly rate ? probably. but living with a rope in the neck every month is hard and stressfull, the worker money at current bts prices will remove big pressure i have over my shoulders while at the same time finish my new office and buy new equipment. this will bring value, i am not going to be needing to make extra businesses for extra money, fully dedicated to bitshares with everything i have.

will i enjoy my new computer equipment to lets say watch a movie ? of course i will, but the important is that i will use it for work in bitshares, will improve productivity.

i don't want to spend more of your time on why i will like to leave the worker proposal as it is, it is obvious that i need/want the money but the decision is yours and whatever you decide i will agree with it.

I think Alfredo's perspective is worthy of consideration.
Thank you for articulating it Alfredo

Is now a good time for BitShares to be nailing down the bottom line?
Or should bts be bootstrapping the community with loyal talent while BTS is still in the startup phase?
I would like to see early wealth created by BitShares to go to passionate members of the community.
But I would not like to economically hinder the project for some feel good fuzzies.
Conundrum.

How Alfredo's compensation continues from here is very much up for debate but I would not like to see any ill feeling towards a dedicated contributor to the project.
1.1Million BTS sounds like a whole lot, but at the same time sweat-equity from talented, skilled people is also essential for the project to succeed.

I can't code, I could learn, but I would not learn for a low payrate.
Perhaps Alfredo is one of the very few people who is an enthusiast, who can ALSO do technical work to make the theoretical possibilities of BitShares a reality.
But if BTS wants to attract talent, otherwise uninterested workers would be drawn to find out more about the project. Would they bring their family and friends with them?
What is the value of BitShares having a reputation for generosity?
Vs Having a reputation for being hard-nosed (justified or not).
Public perception is important.

Had this rally waited an extra month to get going, Alfredo would have been paid $4800 worth of bts (or would it be $9600 worth of bts?).
Should the timing of the rally make such a difference?
If you (impersonal) think the contract should originally have been paid in bitUSD, then at the time did you lobby for the contract to be changed or not approved?
If so, the shareholders voted against your advice.

If there is fault with the contract it is between BitShares 2.0 shareholders and BitShares Munich, and not Alfredo.

One way to view the Reserve pool is to view it through a monetary-inflation lens. That the shareholders are willing to expend 0.xxxx% of BitShares' wealth on ensuring that the ecosystem is maintained and grows to meet the needs of the BitShares customers.

Worker proposals paid in bts vs worker proposals paid in bitUSD.
One side wants price stability... the other wants to monetize their labour to invest/speculate on the price of bts.
I see no way it could be done, but this scenario does sound a lot like the market for shorts vs longs CfD for the creation of bitUSD. How perfect would it be if the market created a CfD that fascilitated worker payment in bitUSD.
I.e without the need for a multisig account

[oxarbitrage]

Every week, i will post the most relevant tasks i worked on in the last 7 days. A few considerations:

- chats in the developer channels, dramas and such will not be reported unless an issue in github is opened or some big time consuming event is happening.
- working in the bitshares core is a challenge for me, all the testing needed after every change, all the research, takes an enormous amount of time even when the final result may be change 1 line of code or even none.
- issues in general end up being resolved in waves, it could be a week when not much more issues are actually closed or code merged, this issues can be all resolved in the next one with much more reports. Whatever is the case, with issues closed or not closed i will always post on what issues i am working on.
 
////////////////////////////

https://github.com/bitshares/bitshares-core/issues/92

This issue was already replied but was rebumped by the following issue:

https://github.com/bitshares/bitshares-core/issues/276

Working with @abitmore we created a new function for the cli wallet to get the relative history. This ended up with a pull request that was merged to the master here:

https://github.com/bitshares/bitshares-core/pull/277

While doing this we found that the node call for get_relative_history was buggy, this was fixed in this pull request, also merged:

https://github.com/bitshares/bitshares-core/pull/280

and https://github.com/bitshares/bitshares-core/pull/281

This function is of big importance for client side applications.

////////////////////////////

In another issue: https://github.com/bitshares/bitshares-core/issues/243

This was already researched also by me and replied to initial question but @xeroc asked if a result could be added to the operations that have missing results. A proof of concept was added here:

https://github.com/bitshares/bitshares-core/pull/275

that proof of concept modifies the node get_block function to add a history object in the results of a transfer operation. This will be reviewed by @xerox when he gets the time. The pull request will not be merged as it is but it is the only way i have to show code changes to others.

////////////////////////////

https://github.com/bitshares/bitshares-core/issues/162

A research in the cashback_test fee tests was done to be able to reply to that issue. 3 options were proposed to the developer community on how to proceed with the findings. This was a good issue to introduce myself into the bitshares test units.
I don't fully know all the core yet and the issues help to move over different parts and functionality.

[oxarbitrage]

i agree that future worker proposals by me or actually by anyone should be in usd. i never had the intention to speculate here, the fact is i found at with all this by pure luck. i have no problem on closing current proposal now and go with a new one if needed. in the other hand the extra compensation will be used to bring more value to the community by working more, much more happy. it is hard to quantify  this additional value in money but you can be sure i will be always grateful with this community and be forever loyal.

this is a new milestone in my life and my professional career that will definitely want to develop here, not only for the payment of the current worker, i made a commitment with myself pretty much since i started, i want to be here.

will i make the same work for less money ? a reasonable hourly rate ? probably. but living with a rope in the neck every month is hard and stressfull, the worker money at current bts prices will remove big pressure i have over my shoulders while at the same time finish my new office and buy new equipment. this will bring value, i am not going to be needing to make extra businesses for extra money, fully dedicated to bitshares with everything i have.

will i enjoy my new computer equipment to lets say watch a movie ? of course i will, but the important is that i will use it for work in bitshares, will improve productivity.

i don't want to spend more of your time on why i will like to leave the worker proposal as it is, it is obvious that i need/want the money but the decision is yours and whatever you decide i will agree with it.

[vegolino]

@fav, Please see the initial proposal. The worker is quoted in BTS, not in USD.

quoting again for visibility.

This Proposed 6-month Worker will cost Bitshares 1,630,835 BTS (~4800 USD)
*BitShares Munich will pay the other half, ~4800 USD

using the logic "quoted in BTS" - I'm still missing a second 1100000 BTS transaction from @Chris4210 since they agreed on paying the other half.

I agree with fav,  if we are paying  Alfredo in BTS so should Bitshares Munich.

[Geneko]

If BitShares Munich had not been involved, and the contract was between Alfredo himself and BitShares 2.0 shareholders, then the terms would be simple.
"Complete work to the subjective satisfaction of the BitShares shareholders and you will receive x bts per month."
Then after a huge price rise, shareholders may find it prudent to renegotiate the employment contracts it holds with employees.

Should this worker proposal, employing Alfredo, be voted out?
The Shareholders could then wait patiently for a new proposal with payment in bitUSD to be submitted by Alfredo.
Depending on his demands for compensation I am sure the shareholders will be pleased to re-hire a talented BitShares literate core dev.

I think same is related to Bitshares Munich Worker proposal. If someone thought it is overpriced it might be voted out. I don't see a problem here?

Main point here with BTS denominated payouts is price risks. The one who accepts the price risk, rips rewards and losses. At least in theory. There are many problems mixing payment for work and price risks. They are two different kinds, one is work another is speculation. If worker suddenly finds out he is payed less then normal (price depreciation) he stops work. The opposite is not the case. Why? Because of flaw in Bitshares worker model.

We need to separate those and that is why we need payment for workers and witnesses denominated in bitUSD.

[Permie]

I think they made the dill with Alfredo in USD and accepted the risk of BTS fluctuations. Otherwise worker would be payed to Alfredo's account. They probably made new arrangement with Alfredo since BTS has appreciated. Alfredo probably accepted that generous offer. Who wouldn't?
 
As far as Bitshares concern the dill is clear. Same is related for all payments from Bitshares blockchain. Regarding management of Bitshares company, it is bad dill. That is why we spend so many discussions regarding witness and workers pay denominated in bitUSD.
Next time pay closer attention to those discussions and act accordingly.

From another thread:

@xeroc is paid with bitUSD.
https://bitsharestalk.org/index.php/topic,23770.0.html
http://cryptofresh.com/u/multisig-worker-2017-01

BTW Just noticed that escrow account has set its own proxy which perhaps shouldn't be: that BTS doesn't belong to them.

    Every thing that is not paid out after the end of the worker will be settled and returned to the reserve fund

BTS 2.0 shareholders need to be sure that the worker-proposal-contract is rock-solid leak proof before signing/voting for it.
There is a need for some 'BitShares lawyers' (the proxies?) to make sure the terms of the worker proposal are clear to the shareholders.
The issue is that BitShares Munich made a gentleman's agreement with the BTS 2.0 shareholders.
The shareholders have no means of enforcing that section of the contract. The terms written by Chris in the proposal are indeed ambiguous, and perhaps should never have passed the vote.
If BTS had a team of lawyers advising the shareholders, I don't think they would have reccomeneded signing it in it's presented form.
BTS shareholders are likely to be majority-bullish on the price of bts.
Surely this exact scenario should have been forseen?

At the time of the original worker proposal, Chris should have been lobbied to state the intention/soft-obligation of BitShares Munich on how to compensate Alfredo in co-operation with BTS reserve fund.
Were BitShares Munich committing to paying $4800 per month? Or were they committing to match the financial contribution made by BitShares 2.0 shareholders?
These terms were not present or explained thoroughly in the contract.
Legal contracts and paperwork are tediously comprehensive, long and boring to read for a reason.

If BitShares Munich had not been involved, and the contract was between Alfredo himself and BitShares 2.0 shareholders, then the terms would be simple.
"Complete work to the subjective satisfaction of the BitShares shareholders and you will receive x bts per month."
Then after a huge price rise, shareholders may find it prudent to renegotiate the employment contracts it holds with employees.

Should this worker proposal, employing Alfredo, be voted out?
The Shareholders could then wait patiently for a new proposal with payment in bitUSD to be submitted by Alfredo.
Depending on his demands for compensation I am sure the shareholders will be pleased to re-hire a talented BitShares literate core dev.