[Worker Proposal] BitShares Core Team Worker Proposal from Graphene Lab

[graphenelab]

Maybe it could be an idea to split the worker. Do one now for documentation, code audit and finish releasing version 4. That could be a good introduction of the team, how it operates, what the community can expect and get to know and see everything... Of course this is merely my personal opinion.
Let me know what you guys think, if it's worth spinning more ideas.

It's an interesting idea, at least about finishing releasing version 4. We'll consider it and share our thoughts here

We welcome other suggestions! Please share if you have them

[graphenelab]

This message and Stefan's reply above clearly show that your team doesn't know the platform well enough. Thus, IMHO, your team need someone who has more experience to guide/supervise the development which leads to higher management costs.

We believe we know the platform well enough. However, we'll be glad if someone more experienced joins us. For example, we would be happy to invite you. This way you'll be able to influence decisions and directions of the development

[sschiessl]

Maybe it could be an idea to split the worker. Do one now for documentation, code audit and finish releasing version 4. That could be a good introduction of the team, how it operates, what the community can expect and get to know and see everything... Of course this is merely my personal opinion.
Let me know what you guys think, if it's worth spinning more ideas.

[abit]

First of all, we would like to present you the page with the main points from our core worker proposal. It includes the roadmap with the list of tasks that we consider important (please note that their order does not represent their priority). https://worker.graphenelab.io/

I assume you refer to this list?

• AUDIT OF THE PLATFORM
• CHANGING THE FEE COLLECTION SYSTEM
• CUSTOM TAKER/MAKER FEES (BSIP81, BSIP85)
• FLEXIBLE SETTINGS OF TRADING ACCESS KEYS
• GOVERNANCE
• DOCUMENTATION FOR BUSINESSES WITH EXAMPLES
• MARGIN CALL FEE (BSIP74)
• LENDING OPTIONS
• NON-LTM REFERRAL & MEMBERSHIP

Could you please elaborate shortly on each of the items what the actions points / vision are?

Was also wondering in what way will review and payments of your deliveries be handled?

Audit of the platform
This task has become relevant after several cases of the blockhain shutdown. They were caused by mistakes that hasn't been discovered since the early days of the platform. We believe such mistakes still exist and this situation endangers the main features of the blockchain - its continuance and immutability. Even couple of hours of shutdown leads to financial losses (not to mention reputational cost). We will conduct audit along with development, but it will be our priority at first.

Changing the fee collection system
The most basic example will be the fee for cancelling of an order. If a user doesn't have enough funds, he cannot do this because the fee cannot be withheld from the order. We plan to fix this along with other issues that we will describe in a separate BSIP. Now we investigate how to implement this feature safely (e.g. there can be a situation when funds placed in the order are not sufficient to pay a fee - in that case it still won't be cancelled).

Documentation for businesses with examples
BitShares highly depends on businesses that invite users to the platform. We believe that clear and convenient documentation instead of the need to deeply investigate numerous nuances is crucial to attract them. BitShares has huge opportunities, but sometimes the scale of it is the exact same reason that repels potential businesses.

Flexible settings of trading access keys
The idea that was discussed for a long time. The BitShares is a trading platform in the first place. However, it lacks flexible settings of keys that allow to provide access to trading to a third-party, not exposing active keys at the same time. Of course, there can be duct tape solutions already, but we need something more solid.

Non-LTM referral & membership
Creation of the classic on-chain referral system. It will allow to invite new users without extra costs and unnecessary headache (unlike the implementation in the majority of other projects). What can be more useful than the growth of the user base?

Margin Call fee (BSIP74)

Custom taker/maker fees (BSIP81, BSIP85)

Lending options (BSIP70)

These points are thoroughly described in the corresponding BSIPs. It is possible that something will change while developing, but overall these concepts look very tempting, their implementation will be useful for the platform. By the way, we already had an experience implementing solution that resembles lending options (BSIP 70) while developing a credit contract in the other project (Karma).

At first we expect direct payments without an escrow. Later, when the BLCKCHND team will finish their escrow project (which will interact with a number of proxies and respected members of the community), we'll transfer keys from the worker's account to this escrow. This way all acceptance of work and inspections will be conducted through them.

Also, considering the open nature of the development, everyone will be able to inspect and test results of our work. Not to mention our internal testers thoroughly reviewing the code.

This message and Stefan's reply above clearly show that your team doesn't know the platform well enough. Thus, IMHO, your team need someone who has more experience to guide/supervise the development which leads to higher management costs.

[sschiessl]

Audit of the platform
This task has become relevant after several cases of the blockhain shutdown. They were caused by mistakes that hasn't been discovered since the early days of the platform. We believe such mistakes still exist and this situation endangers the main features of the blockchain - its continuance and immutability. Even couple of hours of shutdown leads to financial losses (not to mention reputational cost). We will conduct audit along with development, but it will be our priority at first.

Just FYI, this could go hand in hand with HackTheDex, and it would likely pay a much higher rate when you find actual bugs.

Changing the fee collection system
The most basic example will be the fee for cancelling of an order. If a user doesn't have enough funds, he cannot do this because the fee cannot be withheld from the order. We plan to fix this along with other issues that we will describe in a separate BSIP. Now we investigate how to implement this feature safely (e.g. there can be a situation when funds placed in the order are not sufficient to pay a fee - in that case it still won't be cancelled).

The main issue here is keeping the fee pool of a private asset funded. Any order can already be canceled if it contains enough to pay cancellation fee, because the user gets the balance from the order first, and then the fee is deducted. This only works e.g. with GATEWAY.BTC if the fee pool of the asset is funded. The only reason that you can't cancel orders in the BitShares UI without having the cancellation fee before is complicated frontend code, but no core issue.

Flexible settings of trading access keys
The idea that was discussed for a long time. The BitShares is a trading platform in the first place. However, it lacks flexible settings of keys that allow to provide access to trading to a third-party, not exposing active keys at the same time. Of course, there can be duct tape solutions already, but we need something more solid.

I assume you mean publishing release 4 to mainnet with BSIP-40 here (which provides that among many other use cases)? Or did you have something else in mind?

Non-LTM referral & membership
Creation of the classic on-chain referral system. It will allow to invite new users without extra costs and unnecessary headache (unlike the implementation in the majority of other projects). What can be more useful than the growth of the user base?

Can you elaborate what you mean with "the classic referral system"?

At first we expect direct payments without an escrow.

Will you denote your worker in some BitAsset, FIAT or BTS?

[graphenelab]

First of all, we would like to present you the page with the main points from our core worker proposal. It includes the roadmap with the list of tasks that we consider important (please note that their order does not represent their priority). https://worker.graphenelab.io/

I assume you refer to this list?

• AUDIT OF THE PLATFORM
• CHANGING THE FEE COLLECTION SYSTEM
• CUSTOM TAKER/MAKER FEES (BSIP81, BSIP85)
• FLEXIBLE SETTINGS OF TRADING ACCESS KEYS
• GOVERNANCE
• DOCUMENTATION FOR BUSINESSES WITH EXAMPLES
• MARGIN CALL FEE (BSIP74)
• LENDING OPTIONS
• NON-LTM REFERRAL & MEMBERSHIP

Could you please elaborate shortly on each of the items what the actions points / vision are?

Was also wondering in what way will review and payments of your deliveries be handled?

Audit of the platform
This task has become relevant after several cases of the blockhain shutdown. They were caused by mistakes that hasn't been discovered since the early days of the platform. We believe such mistakes still exist and this situation endangers the main features of the blockchain - its continuance and immutability. Even couple of hours of shutdown leads to financial losses (not to mention reputational cost). We will conduct audit along with development, but it will be our priority at first.

Changing the fee collection system
The most basic example will be the fee for cancelling of an order. If a user doesn't have enough funds, he cannot do this because the fee cannot be withheld from the order. We plan to fix this along with other issues that we will describe in a separate BSIP. Now we investigate how to implement this feature safely (e.g. there can be a situation when funds placed in the order are not sufficient to pay a fee - in that case it still won't be cancelled).

Documentation for businesses with examples
BitShares highly depends on businesses that invite users to the platform. We believe that clear and convenient documentation instead of the need to deeply investigate numerous nuances is crucial to attract them. BitShares has huge opportunities, but sometimes the scale of it is the exact same reason that repels potential businesses.

Flexible settings of trading access keys
The idea that was discussed for a long time. The BitShares is a trading platform in the first place. However, it lacks flexible settings of keys that allow to provide access to trading to a third-party, not exposing active keys at the same time. Of course, there can be duct tape solutions already, but we need something more solid.

Non-LTM referral & membership
Creation of the classic on-chain referral system. It will allow to invite new users without extra costs and unnecessary headache (unlike the implementation in the majority of other projects). What can be more useful than the growth of the user base?

Margin Call fee (BSIP74)

Custom taker/maker fees (BSIP81, BSIP85)

Lending options (BSIP70)

These points are thoroughly described in the corresponding BSIPs. It is possible that something will change while developing, but overall these concepts look very tempting, their implementation will be useful for the platform. By the way, we already had an experience implementing solution that resembles lending options (BSIP 70) while developing a credit contract in the other project (Karma).

At first we expect direct payments without an escrow. Later, when the BLCKCHND team will finish their escrow project (which will interact with a number of proxies and respected members of the community), we'll transfer keys from the worker's account to this escrow. This way all acceptance of work and inspections will be conducted through them.

Also, considering the open nature of the development, everyone will be able to inspect and test results of our work. Not to mention our internal testers thoroughly reviewing the code.

[graphenelab]

First of all, we would like to present you the page with the main points from our core worker proposal. It includes the roadmap with the list of tasks that we consider important (please note that their order does not represent their priority). https://worker.graphenelab.io/

I assume you refer to this list?

• AUDIT OF THE PLATFORM
• CHANGING THE FEE COLLECTION SYSTEM
• CUSTOM TAKER/MAKER FEES (BSIP81, BSIP85)
• FLEXIBLE SETTINGS OF TRADING ACCESS KEYS
• GOVERNANCE
• DOCUMENTATION FOR BUSINESSES WITH EXAMPLES
• MARGIN CALL FEE (BSIP74)
• LENDING OPTIONS
• NON-LTM REFERRAL & MEMBERSHIP

Could you please elaborate shortly on each of the items what the actions points / vision are?

Was also wondering in what way will review and payments of your deliveries be handled?

That's right, the list is correct I will answer questions in a couple of hours
Also, small mistake crept in. This is the previous version, in the current one, we decided to abandon the work on the Governance, since this topic is too complex and controversial to be dealt with only by developers.

[graphenelab]

I invite anyone who doubts our competence and experience to take a look at our previous projects. Graphene Lab has worked for more than three years using the BitShares' code in our projects, including the change of consensus mechanism and adding new functionality (e.g. new referral system, rating system, credit contracts, etc).

Nice! What fork is that? Is it public?

Fork with another consensus not public, as far as I know, they abandoned the idea of ​​the project, but the idea was interesting. Dynamic emission depending on network activity, and the distribution is among the participants of the network that are beneficial (determined by a complex mathematical formula and took into account many factors). Accordingly, if the network did not grow, then the emission did not occur, and if it was actively developing, then active users received their bonuses

Fork with a referral and rating system - Karma. In it, we tied all the logic to loan contracts. Thus, the user, even without LTM, could invite people and receive income from them, but if the people they invited didn’t pay back loans, then the rating of the invitee fell https://github.com/GrapheneLab/karma-core

Unfortunately, most of our work is commercial in nature, which often leads to closed repositories, but you can look at our git and find enough sources to study

[sschiessl]

First of all, we would like to present you the page with the main points from our core worker proposal. It includes the roadmap with the list of tasks that we consider important (please note that their order does not represent their priority). https://worker.graphenelab.io/

I assume you refer to this list?

• AUDIT OF THE PLATFORM
• CHANGING THE FEE COLLECTION SYSTEM
• CUSTOM TAKER/MAKER FEES (BSIP81, BSIP85)
• FLEXIBLE SETTINGS OF TRADING ACCESS KEYS
• GOVERNANCE
• DOCUMENTATION FOR BUSINESSES WITH EXAMPLES
• MARGIN CALL FEE (BSIP74)
• LENDING OPTIONS
• NON-LTM REFERRAL & MEMBERSHIP

Could you please elaborate shortly on each of the items what the actions points / vision are?

Was also wondering in what way will review and payments of your deliveries be handled?

[sschiessl]

I invite anyone who doubts our competence and experience to take a look at our previous projects. Graphene Lab has worked for more than three years using the BitShares' code in our projects, including the change of consensus mechanism and adding new functionality (e.g. new referral system, rating system, credit contracts, etc).

Nice! What fork is that? Is it public?

[graphenelab]

Greetings everyone. Thank you for your questions and support.

We do understand the worry of the part of the community. The BitShares platform deserves experienced developers with the clear understanding of what has to be done (and how that has to be done) to make things better. Therefore, we would like to clarify several points.

First of all, we would like to present you the page with the main points from our core worker proposal. It includes the roadmap with the list of tasks that we consider important (please note that their order does not represent their priority). https://worker.graphenelab.io/

Besides, I would like to address the offer to work on the BitShares outside of the worker proposal to earn reputation. I could have agreed with that if the matter was about hiring freelancers that develop out of curiosity in their free time (that often negatively affects the quality of the work). But the BitShares platform needs the team that has an extensive experience of the commercial development that values its reputation because it directly affects the success of its business. I would never risk the name of the company if I wasn't sure in our capability to improve the product and if I doubted the quality of our work. I invite anyone who doubts our competence and experience to take a look at our previous projects. Graphene Lab has worked for more than three years using the BitShares' code in our projects, including the change of consensus mechanism and adding new functionality (e.g. new referral system, rating system, credit contracts, etc).

Also I would like to mention that we are open for proposals from other developers (especially from the previous core team). Moreover, we are ready to propose them rates that are higher than ours. We'll leave free spots in our worker proposal and in case there will be unspent funds we will direct them for other needs of the platform by voting.

In any case, we will publish our core worker proposal on-chain tomorrow. After that it will be left for the community to decide, whether the platform needs the team of experienced developers or the current situation with uncertainty and enormous expenses satisfies everyone.

Thank you for the attention!

[bitcrab]

up to now it seems the community is not sufficiently convinced that Graphene Lab is qualified enough for the core work.

"The GrapheneLabs proposal is welcomed. Thus far, it lacks support from the Community. Cheaper developers “may” deliver better value to the DAC. However, I’ve not seen any contributions from the listed team members which indicate their ability to deliver solutions at an economical rate."

"It's a daunting job and poor code contributions leads to increased/unpleasant review time. for example, We found working with ********** difficult to impossible as their code quality was not accepted by the reviewers. The resulting costs were too high for their efforts."

I feel Graphene Lab need to provide more persuasive information to convince the community...

I would like to know to whom the second quote applies and whose phrase is this?

If this is about our team, then who said it and on what project, and if not about us, then why is it here?

As for the quality of work, our developers have extensive experience working both with the BitShares core and with other large developments.

Of course, in any code there may be errors, blockchain stops in 2018 and 2017 proves that even developers who constantly work with BitShares do not guarantee excellent quality of work.
That is why in the first stages of work we will devote a lot of time to code audit in order to minimize the probability of errors and even better study the core of the system

the words are not about anyone from Graphene Lab, I quoted it here to just emphasize "poor code contributions leads to increased/unpleasant review time",  I am sorry if it is misleading.

[pc]

No, it's not OL.
Not going to mention names here, but it wasn't anyone from the Graphene Lab team.

I know where the quoted sentences came from and who said it. The mentioned name was OL. That's why I added my comments above as I don't think OL's code is too low-quality, just to be fair.

Oh, ok, sorry. I agree with your comments about OL, that's why I was thinking of someone else.

[ljk424]

We know too little about Graphene Lab. Although the budget you reported looks appropriate, the community does not have the confidence to entrust you with core development work until you fully understand your identity, capabilities, and contributions.

[abit]

It's OpenLedger.

No, it's not OL.
Not going to mention names here, but it wasn't anyone from the Graphene Lab team.

I know where the quoted sentences came from and who said it. The mentioned name was OL. That's why I added my comments above as I don't think OL's code is too low-quality, just to be fair.