回复：Linux - linux-0.1.6-test2
首次公开证据
打开首次公开证据查看 1 个交叉存档
来源说明
Published on GitHub in February 2024 as part of Martti Malmi's testimony in the COPA v. Wright trial
我修复了几个发现的地方：套接字可能出错却没有断开连接。如果你的连接再次失效，它应该会断开并重新连接。我还实现了一个不活动超时，作为备用措施。
这还包括对初始区块下载速度缓慢问题的部分修复。
你应该使用“-debug”开关运行，这样我添加到 debug.log 中的额外调试信息就会记录下来；如果还有其他问题，这些信息会有所帮助。
linux-0.1.6-test2.tar.bz2 12,134,012 bytes
下载：
http://rapidshare.com/files/305231818/linux-0.1.6-test2.tar.bz2.html
我明白发生什么了。你的所有套接字不知怎么都失效了。你与网络没有通信，但因为有 8 个僵尸连接，它认为你仍然在线，并继续生成区块。当你的区块编号连续出现、中间没有插入其他人的区块时，就能看出这种情况，例如： 2/unconfirmed 3/unconfirmed 4/unconfirmed 5/unconfirmed 6 blocks 7 blocks
你不大可能像这样连续 6 个区块都是唯一找到区块的人。
你退出并重启后，它重新连接，并下载了网络在你不在时找到的 45 个区块。由于你的区块没有立即广播到网络，网络继续向前运行，没有它们。
听起来你在 Wine 上遇到的正是同一个问题。显然，Linux 上的套接字处理存在某种无论哪种运行方式都会造成影响的问题。
我会开始研究这个问题。最终，如果找不到根本原因，我就得建立某种机制，监视消息长时间缺失并断开连接。你现在唯一的临时办法，是更频繁地退出并重新启动。
除了一个节点连接外，其他连接都同时失效了，另一个也在稍后失效。IRC 仍然正常工作，所以不是你与互联网断开了。
我在想，区块的状态是不是应该一直显示“#/unconfirmed”直到成熟（119/unconfirmed，然后是 120 blocks）。对区块而言，这个数字的意义不像对交易那么明确。
我认为不把自己的区块计作确认会更好。缺点是，不同节点显示的状态数字会不一致。状态数字也不再与区块的成熟倒计时同步。更温和的方案是，仅在所有确认都来自你自己时采用特殊处理。
我刚刚损失了 6 组正在成熟的币！我原本有 10 组比特币正在成熟。最后一组大约在 0:22 生成。它到了 2/unconfirmed，随后 bitcoin 卡住了。10:10 时，0:22 生成的比特币仍然只有 2/unconfirmed。因为你告诉过我不会损失币，所以我关闭并重新启动了 bitcoin。好的一面是，它关闭和启动都非常顺利。但不幸的是，当区块更新后，我损失了 6 组比特币。四组仍未确认，但两组已经确认。现在它们没有留下任何痕迹。既然你现在有了“Show Generated Coins”选项，也许可以把失败的比特币生成重新放回来。我只是不喜欢那些比特币就这样凭空消失。我目前仍在运行 Linux 构建，但现在 Wine 版本突然显得更有吸引力了，因为过去 24 小时我生成的 10 组比特币中有 6 组刚刚消失。我附上了 debug.log。
周二，2009 年 11 月 10 日上午 1:45，Liberty Standard <newlibertystandard@gmail.com mailto:newlibertystandard@gmail.com> 写道：
Linux 构建在过去 20 小时内生成了相当数量的比特币，我相信你所说的数据库错误，所以一切迹象都表明我今后应该运行 Linux 构建。Linux 构建唯一有点烦人的地方，是我的电脑风扇从 50% 变成了 100%。:-P 我知道可以限制 CPU，所以如果它太让人烦、而且我能接受少生成一些比特币，也许我会这么做。或者我只是应该开始多听点音乐…………
在有未确认内容时关闭没有风险。 当你进行交易或创建新区块时，它会立即广播到网络。此后，逐渐增加的 #/confirmed 数字只是对结果的监控。 在那段时间里，你的节点不需要做任何事情来推动接受。
英文原文
展开英文原文
I fixed a few places I found where it was possible for a socket to get an error and not get disconnected. If your connections go dead again, it should disconnect and reconnect them. I also implemented an inactivity timeout as a fallback.
This also includes a partial fix for the slow initial block download.
You should run with the "-debug" switch to get some additional debug.log information I added that'll help if there are more problems.
linux-0.1.6-test2.tar.bz2 12,134,012 bytes
Download:
http://rapidshare.com/files/305231818/linux-0.1.6-test2.tar.bz2.html
I see what happened. All your sockets went dead somehow. You had no communication with the network, but because you had 8 zombie connections, it thought it was still online and kept generating blocks. You can tell this is happening when your blocks are numbered sequentially, without other people's blocks interspersed, like: 2/unconfirmed 3/unconfirmed 4/unconfirmed 5/unconfirmed 6 blocks 7 blocks
It's implausible that you would be the only one to find blocks for 6 blocks in a row like that.
When you exited and restarted, it connected and downloaded 45 blocks that the network found in your absence. Since your blocks were not broadcast to the network immediately, the network went on without them.
It sounds like you had exactly the same problem on Wine. There's clearly something about socket handling on Linux that's effecting it either way.
I'll start researching this. Ultimately if I can't find the root of the problem, I'll have to make some kind of mechanism to watch for an absence of messages and disconnect. The only workaround for you right now would be to exit and restart more often.
All but one of your node connections went dead at the same time, one shortly after. IRC was still working, so it wasn't that you were offline from the internet.
I wonder if the status of blocks should say "#/unconfirmed" all the way up to maturity (119/unconfirmed then 120 blocks) instead. The meaning of the number isn't as strong for blocks as for transactions.
I think it would be an improvement not to count one's own blocks as confirmations. A drawback would be that the status numbers shown by different nodes would not match. The status number would no longer be coordinated with the maturity countdown on blocks either. A lighter option would be a special case only if all confirmations are your own.
I just lost 6 sets of maturing coins! I had 10 sets of bitcoins maturing. The last set was generated at about 0:22. It got to 2/unconfirmed before bitcoin got stuck. At 10:10, the bitcoin which was generated at 0:22 was still only at 2/unconfirmed. Since you had told me that I wasn't going to lose coins, I shutdown and restarted bitcoin. On the bright side, it shutdown and started up very smoothly. But unfortunately, when the blocks updated, I lost 6 sets of bitcoins. Four sets were still unconfirmed, but two sets were confirmed. And there's no trace of them now. Perhaps now that you have the 'Show Generated Coins' option available, you can put back in failed bitcoin generations. I just don't like that those bitcoins just disappeared into thin air. I'm still running the Linux build at the moment, but the Wine version is suddenly looking much more attractive now that 6 out of the 10 sets of bitcoins I generated in the past 24 hours just vanished. I've included my debug.log.
On Tue, Nov 10, 2009 at 1:45 AM, Liberty Standard <newlibertystandard@gmail.com mailto:newlibertystandard@gmail.com> wrote:
The Linux build has generated a decent amount of bitcoins within the past 20 hours and I trust what you're telling me about database errors, so all signs point toward me running the Linux build from now on. The only half annoying thing about the Linux build is that my computer's fan has gone from 50% to 100%. :-P I know I can limit the CPU, so if it gets on my nerves too much and if I can live with less bitcoins being generated, perhaps I'll do that. Or maybe I just need to start listening to more music......
There's no risk in shutting down while there are unconfirmed. When you make a transaction or new block, itimmediately broadcasts it to the network. After that, the increasing #/confirmed number is just monitoring the outcome. There's nothing your node does during that time to promote the acceptance.