• Forum has been upgraded, all links, images, etc are as they were. Please see Official Announcements for more information

Pre-Proposal: Dash Bug Bounty Program by BugCrowd

Thanks for explaining. This is a lot of money though and, particularly given the nature of this proposal where you are to be trusted not only with the funds but with potentially critical vulnerability data, we feel it's very important to demonstrate your commitment to transparency and integrity of information before we can recommend this proposal.

I must ask you to please update your proposal and the first post in this thread with the following:

  • your own addendum of 2017/06/21 stating what will happen to leftover funds;
  • correct or explain the wording "best funded bug bounty program" because this does not equate to being the bounty program with the highest incentives;
  • the actual cost breakdown, including your fees, Bugbounty's fees and the value of the bounty offered (everybody here is familiar with the risks related to Dash/USD price fluctuations);
  • how the integrity of bug reports will be protected between Bugcrowd issuing them and Core developers receiving them. In other words, why the network should trust YOU to handle this, any potential risks you have anticipated in your handling of the data and steps you will take to mitigate those risks.

When you improve your proposal, please colour all new material in red and don’t delete any word/sentence, but use strike through. This will make it easier for the us to find changes when we re-evaluate your improved proposal.

Thank you.
This is less than we pay for our "Air Force".
I know "marketing" is our big buzz word this month, but let's try to keep our priorities in line.
Killing bugs is way more important!
Hi @Tallyho

I've added the following to the proposal to address your concern about communication with Core:

Added 2017/06/26 -- In response to a concern raised by the PEC, DashBudgetWatch and Jim Bursch will not be acting as an information escrow. The Core Team will have direct access to the BugCrowd platform and it is our goal to integrate BugCrowd with the Jira issue-tracking system utilized by the Core Team.

If this adequately addresses your concern, will you make the appropriate adjustment to the PEC rating?
Thank you Jim, we shall take this into account and post a revised report shortly. Are you able to elaborate on any of our other points?

Re: Cost breakdown -- I cannot post a detailed cost breakdown because a final agreement with BugCrowd has not been negotiated. However, if it will help, I am willing to share with you *privately* the quote that I received from BugCrowd, on the condition that it remain confidential. I will also share with you my negotiating goals and additional details that are factors in the final negotiation.

We are getting very close to the voting deadline for this proposal, so I would appreciate expediency in these matters.
Hi Jim,

It's really the MNOs that should have the opportunity to assess the costs, but in the interests of finalising your PEC report as quickly as possible, if you let me know the quote from Bugcrowd and any other details you think will help, I guarantee to treat it with the highest level of confidentiality. I can give you an email address if you prefer.
I don't seem to be able to start a conversation with you. Please email me at **removed**
Last edited:
Proposal Evaluation Committee

I have reviewed the details that Jim kindly provided me with, and consequently have asked him to make explicit some details that I believe the MNOs not only have a right to know but need to know in order to make an informed decision on how to vote. When Jim responds I will post my revised PEC report, hopefully later on today.
Proposal Evaluation Committee

We have revised our report in accordance with the new information. It is with deep regret that we feel it necessary to flag up certain issues on what is clearly a popular proposal, but since the mission of PEC is primarily to protect Dash we feel it is necessary to remind MNOs that they are not in possession of all the details pertinent to this proposal.

Edit: since posting this report, Jim has offered to share the numbers privately with anyone who asks, which is commendable. I would be interested to know from those people whether they share our concerns or feel the total amount of this proposal vs. bounty pool is actually reasonable.

Our main concern is what proportion of the proposal funds MNOs think will actually go to the bounty pool and how little they would consider reasonable. For example, would MNOs still support a proposal like this that pledged to use less than 13% of the total for the actual bounty??
170627 jimbursch Team1 R2.jpg
Last edited:
This is unfortunate.

I shared with @Tallyho a copy of the quote that was provided to me by BugCrowd, upon which I based my estimates for the budget proposal. The content of that quote is subject to a non-disclosure agreement that BugCrowd required me to sign. This is not unusual or nefarious. It is a standard business practice to enable parties to engage in negotiation involving sensitive information such as pricing and discounts.

I believe @Tallyho's main concern is the trade-offs that have to be made between defining the scope of the program and the size of the bounty pool.

Here is what I wrote to @Tallyho, with figures redacted because they are covered under the non-disclosure agreement with BugCrowd:

"When I started working on this project I envisioned a $100,000 bug bounty fund that would be trumpeted from the mountaintops. After researching top tier bug bounty programs, I quickly learned that the amount of the bounty fund is the least important factor. What's important is a relationship with thousands of hackers, hundreds of fully vetted expert researchers, a tested methodology for assigning priority and value to vulnerabilities, and systems in place to accomplish all of that efficiently, securely, and safely. I would be glad to put you in touch directly with the BugCrowd rep to explain in detail what their system entails.

"To be clear, <redacted> is what BugCrowd stated in their quote and is NOT what I have allocated for the bounty pool. As I have stated repeatedly, all these amounts are subject to negotiation, wherein I will be working to get the best deal for Dash.

"Perhaps it would help if I gave you some scenarios with specific numbers. For these scenarios I will not set aside a reserve to deal with USD/Dash price fluctuation. Instead, those funds will be included in the bounty fund and any price fluctuation will be absorbed there."

I then presented figures for 4 scenarios of exactly how the funding could be allocated, which included a scenario in which over $100,000 is allocated for the bounty fund, but only one application could be included in the scope of the program.

I concluded my email with @Tallyho with the following:

"I am of the opinion that it is better for Dash to cover as many important applications as possible in the program and keep the bounty pool to a viable minimum. I also think it is unnecessary to ask the MNOs for more funding to increase the amount of the bounty pool.

"My negotiating position with BugCrowd is that we should receive substantial discounts because we are paying in cash up front for a 12-month program, and those discounts will be applied for additional applications to be included in the program".

If anyone would like to see the numbers, I will be happy to share them privately and confidentially, subject to the terms of the non-disclosure agreement that I am bound to uphold.
Thank you for making that offer Jim, that's a good idea.

I believe @Tallyho's main concern is the trade-offs that have to be made between defining the scope of the program and the size of the bounty pool.

My apologies, I thought I had made it clear that we recognise we don't have the knowledge to assess the costs for the Bugcrowd program. You have also said you are still negotiating these, which is understood.

Our concerns relate more specifically to the size of the bounty pool vs. the total amount requested, and the portion of the total funds that don't appear in the quote. I have edited my post above to better explain.
we feel it is necessary to remind MNOs that they are not in possession of all the details pertinent to this proposal

Why do you feel it is necessary to remind us that?
You are NOT here to think for MNOs - the only way to provide any value by your effort is to provide justified beliefs, arguments in order to get as close to facts and truth as possible.

While we cannot provide the details, we are deeply concerned ...
is the least justified argument possible, and using such against something or even someone is what trolls do.

Also please call yourself something else but "committee" - "group" or "gang" for instance, because "committee" is misleading since you were not appointed or elected by the community.

Three days ago, based on other reports before this one I wrote you:

"I appreciate the rigour of your PEC reports as well as the effort you put in it. Information it contains is sometimes very interesting.
However the form, the tone, and especially the extort of authority with which you present it is harmful for the ambience of dash network community, and for me personally hard to digest.

If you had the actual mandate to designate the metrics for sake of correlating proposal's acceptance / rejection, which essentially means having a voting power sufficient to decide about the acceptance / rejection (which I hope you do not have), ...
even then I would prefer that your actual, individual arguments would be possible to comment on the same way as we are used to on this forum or on the Dash Central's discussion."

You replied that you had noted it, but it feels more like the opposite.
Under the 4 scenarios that I gave to @Tallyho, the portions of the bounty pool are:

70% -- only 1 application included in the program
46% -- 4 applications included in the program
38% -- 5 applications included in the program
22% -- 7 applications included in the program

Under no scenario that I have presented does the bounty pool drop to 13% as @Tallyho claims. I believe she is misrepresenting the information that I have shared with her. If anyone would like to check my math, I am happy to share the numbers privately and confidentially as is required by the non-disclosure agreement.

I would also like to point out that I am making every effort to be as transparent and responsive as possible. To be accused of being disingenuous and deceptive is rather insulting.
THANK YOU! to the MNOs who supported this project. We won't let you down.

and THANK YOU! to the DashIncubator (formerly DashBudgetWatch) backers who supported this project. We couldn't have done it without you!
Under no scenario that I have presented does the bounty pool drop to 13% as @Tallyho claims.

Who is she @Tallyho? Here she is.

She introduced herself as a person who asks stupid questions, and now she changed her attitude and she gives stupid answers and stupid evaluations.

Who evaluated her to become an evaluator? Stupidity has it limits. Naming yourself an official evaluator and start judging people, this exceeds the limits of stupidity. For in the same way you judge others, you will be judged.
Last edited:
The proposal seems to pass so I want to submit the below bug in order to be evaluated. It is mainly a design bug, but on what it concerns randomness in mn payee section it is also an ordinary bug.
We are talking about money, so safety is the number one priority. Dash developers dont seem to care about language safety, they even use pure interpreted languages (like perl) . Perl is unsafe as long as it is not a compiled language, which means that an agent can change the libraries of the language (with the help of automatic updates e.t.c.) and thus change the behavior of the code in the runtime. And he can do this selectively, by targeting specific IPs. Everything depends on the trust you have in the core developers of the interpreted language, and this is also a blind trust as long as you are unable to prove to the others that your IP has been targeted by them, neither you can discover whether they have targeted another IP or not. Some of my questions regarding these and some relevant issues still remain unanswered by the core team.

And here is another question:

Who is about to judge whether something is a bug or not?
I personally trust @UdjinM6 to become a bug evaluator (but he has to stop being a Dash developper of course, because bug evaluator and developer roles contradict eachother). Is he an evaluator or not?

Who else is candidate to become a bug evaluator? Who is "Philip Da Silva" from BugCrowd and how comes he evaluates as a bug evaluator?

Being a bug evaluator is a personal quality, not a company quality. Especially as long as we dont know the names of the persons who are hiding behind the company, this turns the evaluation of the company questionable and even suspicious.

Bugcrowd has a lot of evaluators, so it is very important to know the (nick)names of the persons who are about to become Dash's Bug evaluators.
Last edited:
Last week I signed the customer agreement with BugCrowd and this week they are working on opening an exchange account so that they can accept payment in Dash. Once we have made the first payment, we will be set up on the BugCrowd platform and we will be writing a bounty brief that defines the scope of the program and the parameters of bounty payouts, along the lines of their taxonomy of vulnerability rating:


The program will be initially launched privately to an invitation-only group of BugCrowd's best, fully vetted researchers, and then opened to the public after the private trial run. When bugs/vulnerabilities are reported through the platform, the BugCrowd engineering team assesses the report to make sure it falls within the bounty brief and evaluates the priority level, which determines the amount of the bounty.

Throughout this process I will be consulting/coordinating with @flare on the Core Team. I would also love to get developers like @UdjinM6 involved with the program.