Qtum量子链漏洞赏金计划正式开启

本次Qtum量子链赏金计划为了更好的借助社区的力量参与到QTUM主网及周边应用的开发建设中，让QTUM持续地保持安全、高效的运行，同时能知足更多用户的需求。

Bug分级与奖励体系

一、若是已经有相似的Issue或者Qtum团队已经知道并在解决该问题的状况将不适用于该赏金计划。

二、若是在解决前将问题公开，并形成危害的将不会得到赏金。

三、修复时，请fork代码到本身的仓库中进行修复，而后提交pull request在Qtum成员review以后正式合入主干。

四、Qtum团队成员是受雇于Qtum基金会，Qtum成员直接或间接的参与Bug修复的状况将不会得到赏金。

五、赏金计划以解决Qtum核心产品的技术，提高产品健壮性，Qtum网站、论坛、组织架构等不在赏金计划之列。

六、赏金计划的奖金与众多因素有关、工做量、影响范围、严重程度等，赏金计划的具体赏金数额以QTUM安全团队的结论为准且对于赏金计划QTUM安全团队有最终解释权。

范围

请在如下Github开源项目中查找漏洞：https://github.com/qtumproject/qtum

这里的范围只是咱们如今关注的重点产品，若是有未被列在上面，可是一样是被验证的软件漏洞，咱们也欢迎经过漏洞上报的方式进行上报和赏金申请，Qtum团队将会对此做出评定并及时给予反馈。

这些漏洞可能会形成如下问题：

• 损失、盗取用户资产

• 拒绝服务攻击

• 引发共识机制的失败

• 没法控制的通货膨胀

• 容许未经受权的访问

漏洞等级分类

漏洞的等级与分类咱们会参照OWASP 模型，咱们将漏洞氛围严重、高危、中危、低危、改进，具体定义方法请参考：http://www.owasp.org.cn/owasp-project/fengxian

须要注意的是：

一、 对于在比特币、以太坊等网络上已上报的问题，赏金会相应的折算。

二、 以上奖励数额为该级别漏洞的最高奖励数额，具体的奖励发放数额会由QTUM安全团队决定。

对于奖励的发放咱们还会参照其中几项来进行评审，如仅上报漏洞者，只须要关注上报材料一项。

上报材料（15%）：完整填写上报材料，具体请参考申报模板link，全部上报材料均为英文版本。

代码修复（40%）：完成代码修复，并不引入新的问题，若是有新的问题被引入，须要在同一次提交中解决该问题。

自动化测试脚本覆盖或手动测试方法说明（15%）：自动化测试脚本对代码的持续集成、快速迭代下的质量控制有极其重要的做用，因此自动测试脚本的完善会做为一项重要的考核指标：

提供自动化测试脚本

100%

提供手动测试说明

60%

修复时间与效率（20%）：修复时间指Issue上报被确认后到修复代码被review事后合到代码库间的时间，该时间会在Issue上报后QTUM安全团队确认漏洞的反馈邮件中明确指望修复时间，该时间会与开发者协商。

该部分奖励说明：

指望时间内完成

100%

超过时望时间50%内70%

70%

超过时望时间50%外

50%

修复思路及方法介绍与文档完善（15%）：对于修复完的漏洞，但愿完成技术材料的整理与文档的提交，具体请参见：Bug修复后提交材料模板

漏洞的上报与修复流程

报告阶段

报告者访问「Bug上报」页面(URL：https://qtum.org/zh/developer/long-term/bugs) 提交漏洞详情(状态：待审核)

处理阶段

1.一个工做日内，QTUM安全团队会确认收到的漏洞报告并跟进开始评估问题， 同时将情报反馈给上报者(状态：审核中)

2. 三个工做日内，QTUM技术团队处理问题、给出结论与指望完成时间(状态：已确认/已忽略)。必要时会与报告者沟通确认，请报告者予以协助，评估完成后会将评估结果告知开发者。

修复阶段

1. 提交者着手修复该安全漏洞(状态：修复中)

2. 对于修复完成的问题，提交者能够将状态改成（状态：待复查）修复时间根据问题的严重程度及修复难度而定，通常来讲，严重和高危问题 24 小时内，中危问题七个工做日内，低危问题十五个工做日内。客户端安全问题受版本发布限制，修复时间根据实际状况肯定

3. QTUM安全团队对问题进行复查，确认修复后会告知提交者结论和漏洞得分(状态：已复查/复查异议)

材料整理阶段

根据要求完成测试脚本、手动测试说明、修复思路与文档完善等信息

赏金发放阶段

QTUM安全团队对提交人的材料完整性和修复完成度进行审核并发布奖励(状态：已结束)

Bug上报模板

<!--- Remove sections that do not apply -->

This issue tracker is only for technical issues related to Qtum.

### Describe the issue

### Can you reliably reproduce the issue?

#### If so, please list the steps to reproduce below:

1.

2.

### Expected behavior

Tell us what should happen

### Actual behavior

Tell us what happens instead

### Screenshots.

If the issue is related to the GUI, screenshots can be added to this issue via drag & drop.

### What version of Qtum are you using?

List the version number/commit ID

### Machine specs:

- OS:

- CPU:

- RAM:

- Disk size:

### Any extra information that might be useful in the debugging process.

This is normally the contents of a `debug.log` or `config.log` file. Raw text or a link to a pastebin type site are preferred.

模板举例

Title: DoS of stakers possible by sending a large transaction.

Description

An attacker can publish a very big transaction. This transaction will be accepted into the mempool, however, upon attempting to include that transaction in a block stakers will produce an invalid block that is not accepted by its peers.

Impact

It is possible for an attacker to cause a denial of service attack against all stakers on the network, effectively bringing block production to a halt.

Affected software

The core qtumd client.

Reproduction

• Start qtumd in regtest mode on a clean chain in staking mode: qtumd -regtest -staking=1

• Get some mature coins to enable staking: qtum-cli -regtest generate 600

• Publish a really big transaction: qtum-cli -regtest sendtocontract ...

• Wait for a minute while the staker loop runs.

• Inspect the debug log

Expected result

The tx should have been rejected by AcceptToMemoryPoolWorker in step 3.

Actual result

• The transaction is accepted into the mempool.

• The debug.log has several entries of a block being rejected at each 16 second interval due to it including a transaction that exceeds the maximum transaction size.

Fix

Make sure that no transactions exceeding the maximum size are allowed into the mempool. This check should be implemented in AcceptToMemoryPoolWorker.

Files

Full debug.log

Bug修复后提交材料模板

###Fault cause

###Solution

###Resulting changes

###Resulting Document change

###Verify method

# Backwords compatible: (yes /no)

#Planned for version : (which version to deliver)

#New test case update/add/Manual testing:

References

• https://docs.qtum.site

• https://github.com/qtumproject