工作量证明难度上升

中本聪SN-0192
其他参与者原话Sabunir原帖 ↗

. 也许与我连接的高延迟(平均 2000ms 以上)有关

. Perhaps it has to do with my connection's very high latency (2000ms or more on average)

中本聪回应

双向各 2 秒的延迟,对你的生成成功率的影响应该小于 1%。

2 seconds of latency in both directions should reduce your generation success by less than 1%.

其他参与者原话Sabunir原帖 ↗

和/或高丢包率(有时高达 10%)?

and/or my high packet loss (sometimes up to 10% loss)?

中本聪回应

大概没问题,但我不确定。协议设计为重新同步到下一条消息,消息会向你连接的所有其他节点重新请求,直到收到。如果错过一个区块,每当有新区块进来、它发现有空缺时,也会继续请求。在最初发布之前,我做过一个测试:在高负载下随机丢弃 1/4 的消息,直到能整夜运行、没有任何节点卡住。

Probably OK, but I'm not sure. The protocol is designed to resync to the next message, and messages get re-requested from all the other nodes you're connected to until received. If you miss a block, it'll also keep requesting it every time another blocks comes in and it sees there's a gap. Before the original release I did a test dropping 1 out of 4 random messages under heavy load until I could run it overnight without any nodes getting stuck.

译文校对、修订与纠错

当前版本尚未建立逐条校对状态记录。来源核验、历史审校与当前译文校对是不同事项。

查看历史审校与代表修订 →

译文内容版本:0fcf86a98498。用于比对文本,不代表校对等级或更新时间。

准备纠错说明

请填写对应原文、现译文、建议译法和理由。复制后通过你联系本站作者的渠道提交;此处不会自动发送。

来源
英文原标题

Proof-of-work difficulty increasing

Bitcointalk · 原始链接 ↗ 记录编号 SN-0192

阅读字号

选择适合你的字号,之后阅读会继续使用。