回复：Linux 构建已准备好测试
首次公开证据
打开首次公开证据查看 1 个交叉存档
来源说明
Published on GitHub in February 2024 as part of Martti Malmi's testimony in the COPA v. Wright trial
谢谢，我明白发生了什么。因为第一个很慢，它最后向其他所有人请求了区块，结果只把一切都拖慢了。我可以修复这个问题，只是需要花点时间想想正确的做法。
在有未确认交易时关闭没有风险。当你创建交易或新区块时，它会立即向网络广播。之后，逐渐增加的“#/已确认”数字只是监控结果。在这段时间里，你的节点没有任何操作可以促进接受。
现在想起来，关闭比特币时，它会立即关闭主窗口，但仍在后台继续运行，以完成数据库的有序刷写和关闭。在我实现这个功能之前，一个僵死、卡住、毫无响应的窗口一直挂在那里，挺烦人的。在后台完成有序关闭之前，端口会被锁定；这是一项重要的保护措施，确保在此之前另一个副本无法碰数据库。我还没见过关闭过程花费超过几秒钟。
在 Wine 中，Windows 版本无法执行 SO_REUSEADDR，因此端口关闭后会增加 60 秒（在我的系统上）的 TIME_WAIT。
如果你需要在两个副本之间转移，可以把它发送到另一个副本的比特币地址。接收副本当时不必在线。
使用不同数据目录的命令行是 bitcoin -datadir=<directory>
例如，在 Linux 上，默认目录是（不要使用 ~） bitcoin -datadir=/home/yourusername/.bitcoin
通常你不需要使用这个开关。它仍然不允许你同时运行两个实例。
开始需要多长时间？可能是你碰巧请求的节点很慢。启动慢与下载速度慢是一致的。
我想看看你当前的 debug.log 文件，试着弄清楚发生了什么。可能只是另一端的连接非常慢，也可能出了问题、失败后又重试了。耗时太长可能会让其他用户困惑。
Martti，你运行时开始下载区块花了多长时间，下载速度多快？
它已经使用 SO_REUSEADDR，因此端口关闭后处于 TIME_WAIT 状态时仍能绑定端口。唯一应该绑定失败的情况是程序确实已经在运行。重要的是同一台机器上不能运行两个比特币副本，因为它们会同时修改数据库。同一台机器上永远没有必要运行两个副本，因为现在生成新币会自动使用多个处理器。
我不确定那些 lib 错误是什么，我会查查。
好了，区块现在开始增加了。它们开始增加所需的时间明显比 Windows 版本长。另外，我觉得它们增加的速度可能也比 Windows 版本慢。你发给我的 Linux 构建中是否启用了调试？区块增加速度约为每秒 15 个区块（看着时钟估算）。我没有计算 Windows 版本增加得多快，但感觉它快得多。
它花了大约半小时才开始快速递增。有趣的是，CPU 使用率在它开始稳定递增之前就上升了，然后在它开始稳定递增时又降低了。不过这次前几分钟内区块就增加到了 2。我还没有生成任何比特币。我会尽可能耐心地等它生成一个比特币，但如果我失去耐心时还没有生成，我就要切回 Wine 版本了。
我附上了当前的 debug.log。
当我启动比特币而比特币端口不可用时，命令行会收到以下消息。比特币端口可用时不会收到这些消息。能否让比特币在默认端口被占用时选择另一个端口？我的 BitTorrent 客户端有时也会发生同样的事情。重新启动时，我之前打开的端口已经关闭。我只需更改端口，它就又开始工作了。
/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
我同时运行两个实例的原因是要把比特币从一个比特币实例转给另一个。当然，它们需要访问不同的数据目录。也许可以把它作为命令行参数指定。目前我必须把比特币数据文件夹移到虚拟机中才能做到这一点。在有未确认比特币时关闭比特币、再用不同的数据目录重启，是个糟糕的解决方案，因为这样做有丢失这些比特币的风险。
出现端口忙错误时，比特币肯定没有运行。根据我的经验，进程会快速且可靠地关闭，但端口再次可用要花 30 秒到 3 分钟不等（凭记忆估计）。我从 Wine 中的 bitcoin 0.1.5 切换到 Linux 构建时出现过一次，从 Linux 构建切回 Wine 中的 bitcoin 0.1.5 时又出现过一次。
我还注意到，关于对话框的文字无法正确容纳，而且不能调整大小。
英文原文
展开英文原文
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.
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.
The command line to use a different data directory is bitcoin -datadir=<directory>
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.
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.
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, how long did it take to start downloading blocks when you ran it, and how fast did it download?
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.
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.
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.
I've included my current debug.log.
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
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.
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.