Bitcointalk

Proof-of-work difficulty increasing

中本聪 · 2010 年 2 月 17 日

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.

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

阅读字号

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