SN-10095 附来源、原文与上下文。
谢谢，我看出发生什么了。因为第一个节点很慢，程序最后向其他所有人都请求区块，结果只是把一切都拖慢了。我能修复，只是需要花点时间想想正确的办法。
Thanks for that, I see what happened. Because the first one was slow, it ended up requesting the blocks from everybody else, which only bogged everything down. I can fix this, I just need to think a while about the right way.
有未确认内容时关闭程序没有风险。当你创建交易或新区块时，程序会立即将它广播到网络。之后不断增加的 #/已确认 数字只是在监测结果。在这段时间里，你的节点不会做任何促进接受的事情。
There's no risk in shutting down while there are unconfirmed. When you make a transaction or new block, it immediately 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.
现在想起来，关闭比特币时，主窗口会立即关闭，但程序还会在后台继续运行，完成有序的数据库写盘和关闭。在我实现这一点之前，总有个卡死、无响应的窗口挂在那里，很烦人。在后台完成有序关闭之前，端口会一直被占用，这是一项重要保护，确保另一个实例在完成之前不能接触数据库。我还没见过关闭过程超过几秒的情况。
Now that I think about it, when you close Bitcoin, it closes the main window immediately but in the background continues running to finish an orderly flush and shutdown of the database. Before I implemented that, it was annoying having a dead hung unresponsive window hanging around. Until it finishes the orderly shutdown in the background, the port would be locked, and this is an important protection to make sure another copy can't touch the database until it's done. I haven't seen the shutdown take more than a few seconds.
在 Wine 中，Windows 版本无法使用 SO_REUSEADDR，所以端口关闭后还会增加 60 秒的 TIME_WAIT（在我的系统上是这样）。
In Wine, there's no way for the Windows version to do SO_REUSEADDR, so that would add 60 seconds (on my system) of TIME_WAIT after the port is closed.
如果需要在两个实例之间转账，可以发送到另一个实例的比特币地址。接收的实例当时不必在线。
If you need to transfer between two copies, you could send it to the other's bitcoin address. The receiving copy doesn't have to be online at the time.
使用不同数据目录的命令行是 bitcoin -datadir=<directory>
The command line to use a different data directory is bitcoin -datadir=<directory>
例如，在 Linux 上，默认目录是（不要用 ~） bitcoin -datadir=/home/yourusername/.bitcoin
For example, on Linux, the default directory is (don't use ~) bitcoin -datadir=/home/yourusername/.bitcoin
通常应该完全不需要使用这个开关。它仍然不会让你同时运行两个实例。
You shouldn't normally have any need to use this switch. It still won't let you run two instances at once.
引用 New Liberty Standard 的文字New Liberty Standard来源 ↗引用中本聪此前的文字中本聪来源 ↗大约花了多久才开始？可能只是你碰巧请求的那个节点很慢。开始得慢，与下载速度慢的情况一致。
About how long did it take to start? It could be the node that you happened to request from is slow. The slow start is consistent with the slow download speed.
我想看看你现在的 debug.log 文件，试着弄清楚发生了什么。可能只是对方的连接非常慢，也可能哪里出错，失败后又重试。耗时太久可能会让其他用户困惑。
I'd like to look at your current debug.log file and try to understand what's going. It might just be a really slow connection on the other side, or maybe something's wrong and failed and retried. Taking too long could confuse other users.
Martti，你运行时，花了多久才开始下载区块，下载速度有多快？
Martti, how long did it take to start downloading blocks when you ran it, and how fast did it download?
它已经使用 SO_REUSEADDR，所以端口关闭后处于 TIME_WAIT 状态时，仍能绑定到该端口。只有程序真的已经在运行，才应该绑定失败。不能让两个比特币实例同时在一台机器上运行，这很重要，因为它们会同时修改数据库。 一台机器上从来都不需要运行两个实例，因为生成功能现在会自动使用多个处理器。
It already uses SO_REUSEADDR so it can bind to the port if it's in TIME_WAIT state after being closed. The only time it should fail to bind is when the program really is already running. It's important that two copies of Bitcoin not run on the same machine at once because they would be modifying the database at the same time. There is never any need to run two on one machine as coin generation will now use multiple processors automatically.
我不确定那些库错误是什么，我会搜索一下。
I'm not sure what those lib errors are, I'll do some searching.
引用 New Liberty Standard 的文字New Liberty Standard来源 ↗好，区块数现在开始增加了。它开始增加所需的时间肯定比 Windows 版更长。而且我觉得，增长速度可能也比 Windows 版慢。你发给我的 Linux 构建是不是开启了调试？区块数大约每秒增加 15 个（看着时钟目测的估计）。我没计时 Windows 版的增长速度，但感觉要快得多。
Ok, blocks have now started to increase. It definitely takes longer for them to start increasing than with the Windows version. Also, I think they might be increasing at a slower rate than in with the Windows version. Is there perhaps debugging enabled in the Linux build that you sent me? Block are increasing at about 15 blocks per second (eyeball estimate while looking at a clock). I didn't time how fast they increased in the Windows version, but it seems like it was much faster.
大约半小时后，它才开始快速增加。有意思的是，CPU 使用率在开始稳定增加前升高，等开始稳定增加后又降低了。不过这一次，区块数在最初几分钟内就增加到了 2。我还没有生成任何比特币。我会耐着性子等生成一个比特币，但如果耐心耗尽时还没有生成，我就会回到 wine 版本。
It took about a half hour for it to start incrementing quickly. Interestingly, the CPU usage increased before it started to increment steadily and then lowered when it started to increment steadily. Although this time the block incremented to 2 within the first few minutes. I have not yet generated any bitcoins. I'll wait for as long as I have patience to generate a bitcoin, but if none are created by the time I lose patience, I'm going to move back to the wine version.
已附上我现在的 debug.log。
I've included my current debug.log.
我启动 bitcoin 而 bitcoin 端口不可用时，命令行会出现以下消息。bitcoin 端口可用时，就没有这些消息。如果默认端口已被占用， bitcoin 能否选择另一个端口？我的 BitTorrent 客户端有时也会发生同样的事。重启时，原先开放的端口关闭了。我只需要改一下端口，它就又能工作。
When I launch bitcoin and the bitcoin port is not available, I get the following messages to the command line. I don't get those messages when the bitcoin port is available. Would it be possible for bitcoin to pick another port if the default port is taken? The same think sometimes happens to me with my BitTorrent client. When I restart it, my previously open port is closed. All I have to do is change the port and it starts working again.
/usr/lib/gio/modules/libgvfsdbus.so: wrong ELF class: ELFCLASS64 Failed to load module: /usr/lib/gio/modules/libgvfsdbus.so /usr/lib/gio/modules/libgioremote-volume-monitor.so: wrong ELF class: ELFCLASS64 Failed to load module: /usr/lib/gio/modules/libgioremote-volume-monitor.so /usr/lib/gio/modules/libgiogconf.so: wrong ELF class: ELFCLASS64 Failed to load module: /usr/lib/gio/modules/libgiogconf.so
/usr/lib/gio/modules/libgvfsdbus.so: wrong ELF class: ELFCLASS64 Failed to load module: /usr/lib/gio/modules/libgvfsdbus.so /usr/lib/gio/modules/libgioremote-volume-monitor.so: wrong ELF class: ELFCLASS64 Failed to load module: /usr/lib/gio/modules/libgioremote-volume-monitor.so /usr/lib/gio/modules/libgiogconf.so: wrong ELF class: ELFCLASS64 Failed to load module: /usr/lib/gio/modules/libgiogconf.so
我同时运行两个实例，是为了把比特币从一个实例转到另一个实例。它们当然需要访问不同的数据目录。也许可以通过命令行参数指定。目前我必须把比特币数据文件夹移到虚拟机上才能这么做。关闭比特币，再用不同的数据目录重启，是个糟糕的办法，因为有未确认比特币时关闭程序，会有丢失那些比特币的风险。
The reason I run two instances at the same time is to transfer bitcoins from one bitcoin instance to another. They of course would need to be accessing different data directories. Perhaps that could be specified as a command line argument. I currently have to move my bitcoin data folder to a virtual machine to do this. Shutting down bitcoin and restarting it with a different data directory is a poor solution because shutting down bitcoin while there are unconfirmed bitcoins risks losing those bitcoins.
我遇到端口忙错误时，比特币肯定没有在运行。按我的经验，进程总能迅速可靠地退出，但端口需要 30 秒到 3 分钟（凭记忆估计）才会重新可用。从 Wine 中的 bitcoin 0.1.5 切换到 Linux 构建时发生过，从 Linux 构建切回 Wine 中的 bitcoin 0.1.5 时又发生了一次。
Bitcoin was definitely not running when i get the busy port error. The process closes quickly and reliably from my experience, but it takes anywhere from 30 seconds to 3 minutes (estimation from memory) for the port to become available again. It occurred while switching from bitcoin 0.1.5 in Wine to the Linux build and again while switching from the Linux build to bitcoin 0.1.5 in Wine.
我还注意到，“关于”对话框的文字没有正确适配，而且不能调整大小。
Another thing that I noticed is that the about dialog text does not fit correctly and it cannot be resized.
