回复：Linux 构建已准备好测试
首次公开证据
打开首次公开证据查看 1 个交叉存档
来源说明
Published on GitHub in February 2024 as part of Martti Malmi's testimony in the COPA v. Wright trial
你真的不该继续在 Wine 中运行了，你遇到了数据库错误（db.log）。你可能是为了应对数据库损坏，才形成了把数据转移到全新安装的习惯。如果存在丢失未确认区块的方式，那就只能是数据库错误。你在 Linux 构建中发现的任何问题都可以修复。Berkeley DB 深处的 Wine 不兼容问题无法修复。
我认为 Linux 构建中的 GCC 4.3.3 比 Windows 上旧的 GCC 3.4.5 更好地优化了 SHA-256 代码。我寻找最佳 SHA-256 代码时，有很多手工调优的高度优化 SHA1 代码可用，但当时 SHA-256 还没有那么多。我应该看看能否把 MinGW 升级到 4.3.x，让它们处于同一水平。
每个为制作这个 Linux 构建作出贡献的人都干得非常出色！感谢你们的辛苦工作。它已经开始有一些比特币成熟了，所以目前我会继续运行 Linux 客户端，直到确定它在生成新币方面是否至少和 Wine 中运行的 Windows 版本一样好，或者更好。
我还想同时运行多个实例的另一种情况，是我升级比特币的时候。我会取消勾选旧版比特币中的生成新币复选框，启动新版比特币，并使用单独的数据目录开始生成新币；然后等旧应用程序中的币成熟后，我会把它们发送到新应用程序，再关闭旧应用程序。我更喜欢全新安装，而不是在保留旧数据的情况下升级。
谢谢，我明白发生了什么。因为第一个节点很慢，它最终向其他所有人请求区块，这反过来拖慢了所有事情。我可以修复这个问题，只是需要想一会儿正确的做法。
在有未确认交易时关闭没有风险。当你创建交易或新区块时，它会立即向网络广播。之后，逐渐增加的“#/已确认”数字只是监控结果。在这段时间里，你的节点没有任何操作可以促进接受。
英文原文
展开英文原文
You really don't want to keep running in Wine, you're getting database errors (db.log). You probably developed these rituals of transferring to a fresh install to cope with database corruption. If there is a way to lose unconfirmed blocks, it would have to be the database errors. Any problems you find in the Linux build can be fixed. The Wine incompatibility deep inside Berkeley DB is unfixable.
I think GCC 4.3.3 on the Linux build optimized the SHA-256 code better than the old GCC 3.4.5 on Windows. When I was looking for the best SHA-256 code, there was a lot of hand tuned highly optimized SHA1 code available, but not so much for SHA-256 yet. I should see if I can upgrade MinGW to 4.3.x to get them on a level playing field.
Everyone that contributed to making this Linux build really did a great job! Thanks for the hard work. It has started maturing some bitcoins, so I'm going to continue to run the Linux client for the time being until I decide whether it's at least as good or better at generating coins than the Windows version running in Wine.
Another instance when I would like to run multiple instances is when I upgrade bitcoin. I will uncheck the generate coin check box in the outdated bitcoin, launch and start generating coins in the new bitcoin using a separate data directory, then when the old application's coins have matured I will send them to the new application and then close the old application. I prefer do do clean installs rather than upgrading while maintaining old data.
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.