软件如何一步步做出来

Linux 版马上就到。Martti 的 Linux 移植已合并进主代码分支，New Liberty Standard 一直在测试。它会随下一个版本 0.2 一起发布。

命令行排在 0.2 之后的待办清单上。

对，SVN 上是接近候选版的 0.2 源码，也能在 Linux 上构建运行。FreeBSD 上还没测过。

其他参与者原话madhatter2December 11, 2009原帖 ↗

如果后端进程能跑在 FreeBSD 上，我可以运行全天候的种子节点。

那会帮大忙。TOR 用户不必再操心如何引导种子，我们也不必依赖 IRC。

如果你不介意桌面上有个最小化窗口，它可以按几种简单模式在无 UI 的情况下运行。（0.1.5 没有 -min 参数，所以会是一个打开着的窗口）

只做种子节点：

bitcoin -min -gen=0

你可以看着 debug.log 来监控它。要停止就 kill 进程，数据库不会介意。

要启动挖矿：

bitcoin -min -gen

要取出生成的比特币，得把 wallet.dat（0.2 版）复制到一台有 UI 的机器上，换入 wallet.dat，运行 bitcoin，再把比特币转到你的主账户。（0.1.5 版则要复制整个 "%appdata%/Bitcoin" 目录。）复制 wallet.dat 有一个注意事项：如果你恰好在程序挖矿或收到付款的那一瞬间杀掉了它，wallet.dat 可能单独用不了，得复制整个目录。

其他参与者原话madhatter2（续）原帖 ↗

我真心认为，下载包里带上每日种子快照，会改善引导过程。我在这里见过几次：全新安装的应用一直停在 0 连接 / 1 区块。查看 debug.log 才发现，IRC 服务器（应该是 freenode）说我已经连接着，拒绝让我为应用引导种子。（仅举例）

明白了。多个节点共用同一 NAT 或 VPN、或某个把所有人经少数代理服务器汇流的 ISP 时，就会出现这种情况。我刚为此向 SVN 提交了一个修复。如果收到 "433" 名称已被占用（是 433 错误吧？），就改用一个非地址形式的随机用户名重试。

其他参与者原话madhatter2（续）原帖 ↗

总之，我愿意帮忙。我有大把时间，这样的项目让人非常兴奋。

那太好了，任何帮助都由衷感谢！

其他参与者原话madhatter2December 12, 2009原帖 ↗

svn 0.2 在 Mac OS X 10.4.11/Intel 上就快编译过了（我这里还有一台 PPC970 的机器，PPC 构建也做得了）。窗口部分通过 wxwidgets 用上了原生 carbon！非常快！我不得不新建了一个 makefile（makefile.osx；当然基于 makefile.unix……考虑过用 autoconf 吗？），并在 header.h 里加了些 ifdef。我手上有补丁。我会继续捣鼓，接下来也许会在 FreeBSD 上试试。

有 Mac 支持是好事。wxWidgets 的跨平台能力物有所值。

请不要试 PPC。PPC 是大端序，Bitcoin 是小端序，会有没完没了的字节序 bug；一旦网络上存在一个可能交换字节的节点，我调试网络就更难了。反正 PPC 也在被淘汰。

考虑过 autoconf。对 makefile 已经变成泥潭的大型项目来说，autoconf 是必需品，但我们规模还小，不用它反而更优。我宁愿让 makefile 尽量保持简单。

其他参与者原话madhatter2（续）原帖 ↗

我认为把 bitcoin 拆成两个应用最理想：一个 wxwidgets 前端（功能基本都在了），加一个绑定控制 TCP 套接字的后端。我一直在读源码，估计拆分难度，应该相当简单。当然，还得开发一个 API。

光是想想，我头就大了。把整个 UI 后端都从 TCP 连接里过一遍，会让所有事情的难度翻倍。UI 与内部数据结构之间的带宽，实在太大了——listview 控件的工作方式，决定了要保持它更新，就得频繁通信。

我更想要命令行控制，那样能同时获得远程管理和批量自动化。

其他参与者原话madhatter2December 14, 2009原帖 ↗

有人能指点一下吗？

g++ -c -O0 -Wno-invalid-offsetof -Wformat -g -D__WXMAC__ -DNOPCH -DBUILD_MACOSX -I"/usr/include" -I"/usr/local/include/wx-2.8" -I"/usr/local/include" -I"/usr/local/boost_1_41_0" -I"/sw/include/db4" -I"/usr/local/ssl/include" -I"/usr/local/lib/wx/include/mac-ansi-release-2.8" -o headers.h.gch headers.h

...

ui.h:430: error: no matching function for call to 'wxTextCtrl::SetValue(const std::basic_string, std::allocator >&)'

/usr/local/include/wx-2.8/wx/textctrl.h:303: note: candidates are: virtual void wxTextCtrlBase::SetValue(const wxString&)

看起来 std::string 到 wxString 的隐式转换不工作。这转换到处都在用，必须能用。

wxString 情况复杂，因为要同时支持 win32 的 16 位 wchar 和 8 位 ansi 双编译。Windows 上如果用了 "unicode"（即 wchar）构建，wxString 是 wchar 而 std::string 是 char，就会出这个问题。

多半是某个 wxWidgets 编译宏或构建配置的问题。你用的 "configure" 选项是什么？

我不确定 __WXMAC__ 是不是正确的宏。也许是 Mac Classic 支持把 wxString 搞复杂了，而我们只要 OSX。试试 __WXOSX__（或见下文）

http://docs.wxwidgets.org/stable/wx_cppconst.html

"wxWidgets 有两个移植到 Mac OS 的版本。其中一个 wxMac 又分两个版本：Classic 和 Carbon。Classic 版是唯一能跑在 Mac OS 8 上的。Carbon 版既可构建为 CFM 也可构建为 Mach-O（二进制格式，类似 ELF），前者或许能在 OS 9 下运行，后者只能在 OS X 下运行。最后还有一个只能在 OS X 下使用的新 Cocoa 移植。总结一下：

* 如果要测试所有 Mac 平台（classic 和 OS X），应同时测试 __WXMAC__ 和 __WXCOCOA__。

* 如果要测试 OS X 下任何 GUI Mac 移植，用 __WXOSX__。

* 如果要测试 Mac OS X 下的任何移植（比如 wxGTK 以及 wxBase），用 __DARWIN__"

其他参与者原话madhatter2December 15, 2009原帖 ↗

最新版 Ubuntu Linux 上也报同样的 std::string 错误。

那一定是你在构建或配置 wxWidgets 时有什么地方做得不一样。

你给 wxWidgets 的 "configure" 脚本用了哪些选项？我用的选项写在 build-unix.txt 里。

其他参与者原话madhatter2（续）原帖 ↗

问一句：debug.log 怎么启用？我试过停掉 bitcoin、touch ~/.bitcoin/debug.log、再启动 bitcoin，但它从来不往文件里写。我是不是漏了什么？

从没听说过这种事。debug.log 里有东西吗？你既然 touch 过文件，听起来里面应该有内容。程序对这个文件有写权限吗？

那就好，在 FreeBSD 上跑得正常吗？

我把改动提交到 headers.h 了。为保持一致，我用的是 __BSD__。宏的完整列表在 http://docs.wxwidgets.org/stable/wx_cppconst.html

#ifdef __BSD__

#include

#endif

malloc.h 只在 windows 上需要，我会在它再惹麻烦之前把它挪进 __WXMSW__ 区段。

我还没试过编译 64 位。64 位不会更快，因为它只在少数几处用到 64 位数字，而且 SHA-256 是 32 位算法；不过对运行 64 位系统的人来说可能更方便。有时间我会试试 -m64，看看问题出在哪。

安装 ia32-libs 就能在 64 位 Linux 上运行 32 位版本。（sudo apt-get install ia32-libs）如果我们做 Debian 包，它可以自动把这个作为依赖拉进来。

我提交了 64 位编译的修复，以及一些支持 wxWidgets 2.9.0 的修复。

serialize.h 里有一个 min(sizeof()) 的编译错误，我为 64 位修掉了。其余 64 位编译错误都出在 wxWidgets 2.8.9 上，所以我开始做 wxWidgets 2.9.0 的支持。

wxWidgets 2.9.0 是 UTF-8 的。我们一直在用 ANSI 版的 wxWidgets 2.8.9，就是在等 wxWidgets 的 UTF-8 支持。

我在 64 位 Ubuntu 9.10 Karmic 上编译并运行成功。

我想剩下的唯一 bug 是状态数字显示混乱。原因不明，我怀疑与 UTF-8 有关，但想不出怎么会。还没深究。

build-unix.txt 已更新，SVN 上有两个 makefile：

makefile.unix.wx2.8

makefile.unix.wx2.9

遗憾的是，我们用的两个版本的 wxWidgets 都还没有 debian 包。系统里只有 wchar（"unicode"）版的 wxWidgets 2.8，那很麻烦，因为 wchar 版 wxString 无法转换为 std::string。我们要么用 ANSI 版 wxWidgets 2.8，要么用 wxWidgets 2.9。所以你还是得自己下载构建。

你只是想运行程序，还是真的需要编译？有一个 32 位 Linux 二进制，在 64 位 ubuntu 上运行只需 "sudo apt-get ia32-libs"。

http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.2.0-linux.tar.gz/download

我最近更新了 SVN，以支持在 64 位 Karmic 上用 wxWidgets 2.9.0 构建。这是 0.2.0 发布之后的事。0.2.0 发布时还不能在 64 位上构建。

遗憾的是，我们可用的两个版本的 wxWidgets 目前都没有 -dev deb 包。Karmic 上只有 UTF-16 版。我们需要 ANSI（libwxgtk2.8-ansi-dev）版或 UTF-8（wxWidgets 2.9.0）版。我们正在向 2.9.0 过渡。

我知道你说过不想用 VM，但实在不行的话——据我上次检查，Windows 版在 Wine 里跑得挺好。

其他参与者原话soultcerFebruary 12, 2010原帖 ↗

如果你愿意，我可以给你提供预编译的二进制。

我是不是漏了什么？bitcoin.org 上的 32 位 Linux 预编译二进制有什么问题吗？

发行版里的 bitcoin 二进制静态链接了 wxWidgets 库，其共享链接（openssl 和 GTK）Ubuntu 自带，故它不需要 .deb 来拉取依赖就能运行。

由于我们正在为 UTF-8 升级到 wxWidgets 2.9.0，而它还没有 DEB 包，我们仍需继续静态链接。

我在 Karmic 64 位上也没能把 wxWidgets 2.8.9 编译过去。

我一直在 Karmic 64 位上用 wxWidgets 2.9.0 编译最新的 SVN，它在 64 位上编译正常。读一下 build-unix.txt，对 wxWidgets 使用给定的 ../configure 参数，这样就能直接用现成的 makefile.unix.wx2.9。（--enable-debug --disable-shared --enable-monolithic）

2.9.0 还有一个外观 bug 要修：状态数字显示不知为何挤在一起。 —— 已修复

主页的下载链接指向 sourceforge 的 tar.gz 压缩包，里面有 32 位二进制和 0.2.0 源码，那时它们还不能在 64 位上构建。

SVN 第一次在 64 位上用 wx2.9.0 构建成功是 2010 年 1 月 28 日。

希望他们哪天能出 wxWidgets 2.9.0 的 debian 包。

其他参与者原话theymosFebruary 24, 2010原帖 ↗

这个依赖以后会去掉吗？我宁愿不跟 GTK 打交道。

GTK 实际需要多少"打交道"？不就是 "sudo apt-get install libgtk2.0-0" 装上、多几个闲置的库文件吗？GTK 什么都不用干，只要在 bitcoin 加载时供它链接、让 gtk-init-check 调用因无 GUI 而失败，就完事了。

这省得我们用 ifdef 把一切切得稀碎、再为 wxBase 单独编译一个二进制，只为绕开链接 GTK。

内存占用是什么时候、以多快的速度增长的？立刻、长时间缓慢、还是从某个后续事件开始？

我在 ubuntu 9.10 64 位上跑着 -daemon，内存占用是稳定的。

一定是服务器上除了 64 位以外的某种差异。也许是缺少 GUI 引起的某种故障。内存泄漏调试工具能给点线索。

好，我做了一个构建目标 bitcoind，它只链接 wxBase、不链接 GTK。SVN 上的 0.2.7 版。

我把初始化和关闭的代码从 ui.cpp 拆到了 init.cpp，现在 ui.cpp 是纯 UI。ui.h 在 wxUSE_GUI=0 时提供内联桩。从节点到 UI 只有四个接口函数。bitcoind 构建里不链接 ui.o 和 uibase.o。

其他参与者原话sirius-mFebruary 25, 2010原帖 ↗

它是立刻开始增长的。我看看 valgrind 能不能帮上忙。

感觉很像是 wxWidgets 里有什么东西在无休止重试——某个 UI 东西失败或没正确初始化。我们那个"忽略初始化失败、照样运行"的 hack，意味着我们正走在无人涉足的地带。我们依赖的事实是：这种模式下我们几乎不用 wx。不过仍有少数东西在用，比如 wxGetTranslation 和 wxMutex。

另一种调试方法是放进 gdb 里运行，等一切安静、所有线程都该空闲时中断它，看看哪个线程在忙、在忙什么。

我猜 bitcoind 大概能正常工作，但还是希望你能把那个问题调试出来。

wx/clipbrd.h 并没有被用到，把它挪进 #if wxUSE_GUI 里面。

SVN 上的 headers.h 已更新。

抱歉，我链接的是 wxbase，但我电脑上装的是完整的 wxWidgets。

db.h:140 的 "class Db no member named 'exisits'" 更奇怪。pdb->get、pdb->put、pdb->del 在那之前都编译过了。你的 Berkeley DB 是 4.7.25 版吗？

Db::exists()

http://www.oracle.com/technology/documentation/berkeley-db/db/api_reference/CXX/frame_main.html

http://www.oracle.com/technology/documentation/berkeley-db/db/api_reference/CXX/dbexists.html

我猜 exists 是最近才加的，在那之前用的是 get。

你用的是 wxWidgets 2.9.0 吗？我建议除了 2.9.0 别用其他版本。

看起来是 wx 头文件（arrstr.h）里引用了 wxBase 之外的某个东西。

从 bitcoin 的 makefile 里去掉 -D__WXDEBUG__ 大概就能解决。

如果那样还不行、而你只求能跑起来，可以编辑 wxWidgets 的 include/wx/arrstr.h 第 167 行，把 wxASSERT_MSG 注释掉。

其他参与者原话CdeckerFebruary 27, 2010原帖 ↗

翻了 2.8.10 的源码，看起来那个版本也能做 unicode。

在 Windows 世界里，"unicode" 指的是 UTF-16（wchar）。

2.8 有两种构建变体：ANSI 和 UTF-16（unicode）。Debian 包里提供的 "unicode" 版就是 UTF-16 版。我认为论坛里描述的构建问题，其根源正是 2.8 及其被简单标注为 "unicode" 的 UTF-16 构建。我们此前用 2.8 ANSI，就是为了期待直达 UTF-8、避开 UTF-16 的地狱。我们无法用 UTF-16 编译。

2.9 只有一个版本，UTF-8。在 Windows 上我们把代码页设为 UTF-8，于是所有平台上我们的代码都是 UTF-8，wxWidgets 与我们的接口也是 UTF-8。在 Linux 上我猜代码页本来就是 UTF-8。统一到 2.9 就避开了 2.8 的多构建混乱，而且我们需要 2.9 来做 UTF-8 国际化。

务必读一下 build-unix.txt，用给出的 configure 参数来配置 wxWidgets。

好奇问一句：提供 wxWidgets 2.9.0 为什么会"极难"？如果你指的是对用户而言，这正是我们静态链接它的原因。

我们需要这么多大型依赖，确实遗憾，但缺一不可。至少在 Debian/Ubuntu 上，除 wxWidgets 外全都有包。他们最终会提供 2.9 包的。

其他参与者原话sirius-mFebruary 24, 2010原帖 ↗

这很奇怪……在我的 64 位 Linux 服务器上以守护进程方式启动 Bitcoin 时，它吃光了剩余的全部 250MB 内存、700MB 交换空间，最终崩溃。在我 32 位的 Ubuntu 桌面上却运行正常，内存占用稳定在 15MB。服务器上跑的是 64 位构建的 Bitcoin。也许构建本身出了什么问题。

sirius-m 调试了这个问题，是 64 位相关的。

修复已提交 SVN，文件 util.cpp。

回得有点晚，但万一别人也遇到同样的问题。编译输出有 2 条警告（各长达 20 行）和 2 个链接错误。错误是：

引用 · 发言者未注明

obj/nogui/init.o(.gnu.linkonce.t._ZNK13wxArrayString4ItemEm+0x13): In function `wxArrayString::Item(unsigned long) const':

/usr/local/include/wx-2.9/wx/buffer.h:42: undefined reference to `wxTheAssertHandler'

obj/nogui/init.o(.gnu.linkonce.t._ZNK13wxArrayString4ItemEm+0x45): In function `wxArrayString::Item(unsigned long) const':

/usr/src/bitcoin/trunk/uint256.h:526: undefined reference to `wxOnAssert(char const*, int, char const*, char const*, wchar_t const*)'

那多半是因为换用了 wxWidgets 的 release 构建而非 debug。他们正走向只保留 debug 构建、抛弃 release 构建，所以他们大概不在乎自己的 release 构建引用了不存在的断言东西而坏掉。debug 构建没什么可怕的，完全适合发布。

bitcoind 以守护进程方式运行，可以用命令行或 JSON-RPC 控制。

感谢 madhatter 和 generica 详细写出 freebsd 上的构建说明。

抱歉，最近几次修订我没在 linux 上测试编译。

makefile.unix 已回退。

"1.3 almost ready"主题串里的 Linux 候选版含有预编译好的 bitcoind。

它不能用于 wxWidgets 2.8，需要 wxWidgets 2.9。可惜还没有 wxWidgets 2.9 的 Debian 软件包。

我们甚至没有指定链接 glibcxx_3.4.11，所以 gcc 一定是在幕后自动链接了它。大概有个编译开关能让它静态链接。许可方面的问题我不确定。通常，编译器的东西都是完全可以再分发的。

请试试 0.3.1 候选版，至少应该解决 libcrypto 依赖问题：

http://bitcointalk.org/index.php?topic=383.0

告诉我行不行。

因为各系统缺的依赖五花八门。能静态链接的就静态链接，更省事。体积也不会大多少。

0.3.6 的 Linux 构建换回了老的 makefile.unix。它静态链接了 libjpeg，因此那不该是问题。

这样好使了吗？

如果你遇到了 22DbRunRecoveryException，而且之前用过别人编译的版本，你可能需要删除（或把文件移走）database/log.000000*

Windows 和 Linux 用户：如果你装的是 0.3.5，仍然需要升级到 0.3.6。

""./bitcoin: /lib64/libc.so.6: version `GLIBC_2.11' not found (required by ./bitcoin)"" 不是 0.3.6 才冒出来的新问题吧？它和 0.3.0 是在同样的系统安装上编的。

不巧我在 0.3.0 之前就升到了 Ubuntu 10.04。我以后再也不升级了。不知道什么时候才有时间重装系统降级，但至少只要不再升级，问题会随着时间自行缓解。

是啊，我非常清楚当初该留在 9.04 或 9.10。降级比升级费劲多了，我又一直时间紧。Ubuntu 是最流行的发行版，因此我打算继续用它。

其他参与者原话lachesisJuly 29, 2010原帖 ↗

在 Debian testing 32 位上，我遇到几个编译错误，都类似这样：

script.cpp:114: error: ‘OP_NOP1’ was not declared in this scope

这些错误是在没先 "make clean" 或 "make" 的情况下直接 "make bitcoind" 时出现的。看起来 bitcoind 的构建说明没有先编译头文件，但也不删除 headers.h.gch，于是只要旧的在，就用旧的。

其他遇到这个错误的人，最简单的解决办法是 "make clean" 然后重新构建。

我们其实不需要预编译头。它只是让编译稍微快一点。我想干脆去掉它。即便这样，你还是得记得 "make -f makefile.unix clean" 或者再删一次 headers.h.gch，把残留文件清掉。

该死的 GLIBC_2.11。我明明一直小心没接受任何更新。

其他参与者原话knightmbJuly 30, 2010原帖 ↗

我只能想象你做出这些构建经历了怎样的痛苦，因为我正试着在一台 Ubuntu 9.04 的机器上编译这个程序，到现在为止不管装多少包、编多少源码，都凑不齐依赖，哈哈。

我不理解你怎么会这么痛苦。我就是照着 build-unix.txt 的说明做的。我为 Boost 1.37 做了两处小修正，下次更新 SVN 时会放上去，附在下面：

Dependencies

------------
sudo apt-get install build-essential
sudo apt-get install libgtk2.0-dev
sudo apt-get install libssl-dev
sudo apt-get install libdb4.7-dev
sudo apt-get install libdb4.7++-dev
sudo apt-get install libboost-all-dev (or libboost1.37-dev)
wxWidgets
---------
cd /usr/local
tar -xzvf wxWidgets-2.9.0.tar.gz
cd /usr/local/wxWidgets-2.9.0
mkdir buildgtk
cd buildgtk
../configure --with-gtk --enable-debug --disable-shared --enable-monolithic
make
sudo su
make install

ldconfig

在 makefile.unix 里加了一条注释：

# for boost 1.37, add -mt to the boost libraries

LIBS= \

-Wl,-Bstatic \

-l boost_system \

-l boost_filesystem \

-l boost_program_options \

-l boost_thread \

-l db_cxx \

-l crypto \

-Wl,-Bdynamic \

-l gthread-2.0

其他参与者原话knightmbJuly 30, 2010原帖 ↗

因此最后那条命令其实就是

sudo apt-get install libboost1.37-dev

问题是那对 boost 1.40+（Ubuntu 10.04 上）不管用，那时你得装 libboost-all-dev。

他们最近好像把 Boost 全改了个遍，"-mt" 什么的，搞得人头疼。

顺便说一句，我试过 Boost 1.34，但它没有 boost.interprocess 那些东西。

Mac OSX 版本现在有了。见 bitcoin.org 或 SourceForge 链接。

用 Boost 1.37 或更新版本都能构建。

其他参与者原话nimnulAugust 03, 2010原帖 ↗

satoshi 的 noWx 补丁进 0.3.7 了吗？在那之前 bitcoind 依赖 wx，而且我从没见 Satoshi 宣布它进了 trunk

是的，0.3.7 带了。它在 rev 112。

其他参与者原话sgtsteinAugust 03, 2010原帖 ↗

我用 4.8 成功构建了，4.7 从来编不过；但用 4.8 时，每当 bitcoind 把初始区块下载转储到磁盘就会锁死。

我劝你别用 BDB 4.8。要是有人用了你的构建之后又换回官方构建，database/log0000* 文件会不兼容。

有道理，我相信没有 SSE2 时你可以关掉生成来运行。

在 cryptopp/config.h 顶部加上怎么样：

#if !defined(_M_X64) && !defined(__x86_64__)
#define CRYPTOPP_DISABLE_SSE2  1
#endif

这会对 32 位构建禁用 SSE2。（至少在 GCC 或 MSVC 下）

SVN rev 128：在 32 位上禁用 SSE2。这可能只对 MSVC 和 GCC 生效。其他编译器可能有不同的 64 位 define。

已更新 SVN。谢谢。

指望将来不在这上面反复栽跟头，希望渺茫。它反正不影响我编译。

其他参与者原话dkaparisAugust 11, 2010原帖 ↗

headers.h 里有这样一段代码：

#ifdef __WXMAC_OSX__

#define __WXMAC__ 1

#define __WXOSX__ 1

#define __BSD__ 1

#endif

#endif

那段代码本来就是个馊主意，我要删了它。Mac 相关代码应该只用 __WXMAC_OSX__，不要用 __WXMAC__ 或 __WXOSX__，我们也该停用 __BSD__。

引用 · 发言者未注明

#if (defined(__unix__) || defined(unix)) && !defined(USG)

#include

#endif

这能保证 Mac 上 BSD 一定被定义吗？

这已进 SVN rev 130。检查一下能不能编译通过。

#if (defined(__unix__) || defined(unix)) && !defined(USG)
#include <sys/param.h>  // to get BSD define
#endif
#ifdef __WXMAC_OSX__
#ifndef BSD
#define BSD 1
#endif
#endif

其他参与者原话BioMikeAugust 19, 2010原帖 ↗

WxWidgets 本身不算问题。我的问题在于所用的版本（2.9），许多发行版打包者认为它不稳定（虽然 WxWidgets 开发者说不是）。另一方面，据我所知 WxWidgets 在 Linux 下用 gtk 画所有界面，这让 bitcoin 开发者很容易做到跨平台。

wxWidgets 2.9 是他们的第一个 UTF-8 版本。我们在所有平台（包括 Windows）上都用 UTF-8。

发行版的 2.8 包是 UTF-16 的，只会让人栽跟头。在大家统一到 2.9 之前，2.8 及其 wxString UTF-16/ANSI 条件编译选项让人有无穷无尽的构建问题。而且用 2.8 时我们走的是 ANSI，那只是 wxWidgets 支持 UTF-8 之前的临时权宜之计。

这个问题会自己解决。随着时间的推移，2.9 会成为更主线的版本。

这篇教程写得真不错。应该有人照着做一遍确认一下没踩坑。

试试 -datadir=

上次我试 $(shell /usr/bin/wx-config) 时，立刻有人为它引发的构建问题叫起来。当时没有时间调查。

$(shell /usr/bin/wx-config) 的一个问题是，它会抓到碰巧装在系统上的任何版本（wx 2.8）、任何配置（非 UTF-8）的 wxWidgets。-lwx_gtk2ud-2.9 只匹配正确的配置。如果 wxWidgets 是用错误配置构建的，它就会失败。

引用 · 发言者未注明

我记得在 freenode 的 #wxwidgets 聊天时，那边的开发者也搞不懂为什么要用它。

他们有说为什么搞不懂吗？

引用 · 发言者未注明

这是因为在我的系统上路径是 /usr/include/wx-2.9/wx/wx.h

为什么在那儿？是操作系统带的，还是你自己构建的？如果你构建的，我并不明白它为什么会把自己装到别的地方。

wxWidgets 2.9 最终有 Debian 包了吗？

也许我们该这样：

INCLUDEPATHS= \

-I"/usr/local/include/wx-2.9" \

-I"/usr/local/lib/wx/include/gtk2-unicode-debug-static-2.9" \

-I"/usr/include/wx-2.9" \

-I"/usr/lib/wx/include/gtk2-unicode-debug-static-2.9"

再说一遍，这些路径能确保只用 2.9，遇到 2.8 会失败。

wxWidgets 2.8 有 ANSI 和 UTF-16 两种，对我们都是错的。它相当诱人，因它作为包唾手可得；在我们开始把 2.9 硬编码进 makefile 之前，很多人都被它折磨过。

你能编译吗？

试着把 init.cpp 第 78 行从：

#ifdef __WXGTK__

改成：

#ifndef __WXMSW__

如果好用了，我就改源码。它应该能行。

它绊倒的那些行：

ERROR extern map<string, string> mapAddressBook;
ERROR extern CCriticalSection cs_mapAddressBook;
ERROR extern vector<unsigned char> vchDefaultKey;
OK extern bool fClient;
OK extern int nBestHeight;

OK extern unsigned int nWalletDBUpdated;
ERROR extern DbEnv dbenv;

因此它的表现就像什么都未定义，连 map 和 vector 都没有。

但 db.h 是被 headers.h 包含的（而且只在那里，别处都没有），而 headers.h 在 db.h 之前就包含了 vector、map、util.h 等等。

是不是 VC 在用预编译头并搞砸了？会不会是你目录里残留着以前失败尝试留下的预编译头文件，被它找到并使用了？

现在有一个安装包，让 MinGW 的安装变得相当简单。别用最新的 4.5.0，用往前几个版本，比如 4.4.1（1.908.0）或 1.812.0。安装程序会完整装好一切，不像以前那么难。我记得我唯一要做的是把 make*.exe 之类的名字改成 make.exe。

http://tdm-gcc.tdragon.net/

跑题说一句：要是有人能折腾出 tcatm 的 4 路 128 位 SSE2 代码在 Windows 上可用就好了。MinGW 的优化有些问题，我不确定，也许是栈上 16 字节对齐的问题，导致段错误。经过一番摆弄，我让他的代码在一个测试程序里跑起来了，但不知为何在 Bitcoin 本体里不行。

谢谢你把这套东西搭起来，Cdecker。

有没有办法让它也构建 GUI 版本？如果是 Ubuntu 的话，装上 wxWidgets 2.9.0 之后应该只要严格按 build-unix.txt 里的步骤来就行。这个环境能让你把 wxWidgets 构建一次后留在那里反复使用吗？

现在可以这样做：在选项里设置 "Minimize to the tray"，然后用 "bitcoin -min" 运行，启动即最小化。可见的只有托盘上一个小（20x20）图标，想用 UI 双击即可。注意：64 位 Karmic Koala 上托盘图标有时会消失，不确定是 64 位还是 Karmic 的问题，32 位 Jaunty 上没这毛病。

Linux 上"开机启动 Bitcoin"没来得及在 0.2 之前实现，所以是灰的。我想 Linux 用户反正不介意手动弄。他们大概需要知道 -min 开关才能弄对。

你可以用 "-datadir=" 开关把数据目录放到任何你想要的位置。我知道已经有人在这么干，把它放进 TrueCrypt 的 USB 盘。

状态栏里的 "# blocks" 我正改成 "# confirmations"。那样也许更清楚。

双击交易可以看到更多信息。

谢谢反馈。哪个版本的 Windows？

上传了一些 UI 改动到 SVN，作为 0.2.5 版。

以前是 View->Show Generated，现在是标签页：

• All Transactions
• Sent/Received
• Sent
• Received

切到 Received 查看收款方便多了。

把"你的地址"簿挪进了主地址簿。两本地址簿太容易搞混。

我发现 "From: unknown, To: (one of your bitcoin addresses)" 里的 "To:" 仍然令人困惑，所以改成了 "From: unknown, Received with:"。比特币地址做了缩写，这样你能看到在地址簿 Receiving 标签页里设置的标签。

修掉了升级到 wxWidgets 2.9.0 后的几处 UI 小毛病。

我没忘记你们这些想要无 UI 版本的人，只是在更多构建打磨之前得先干点有趣的事。

地址簿现在有 "Sending" 和 "Receiving" 两个标签页。你自己的地址称为"接收地址"。

madhatter 一直在 Mac 上构建。他遇到的错误可能是 UTF-16 版 wxWidgets 2.8 导致的。用 2.9.0 应该会顺利些。wxWidgets 2.9.0 是 UTF-8 的，不会有那个问题。

我记得他在 FreeBSD 上搞定了，但他想要的是无 UI 版本。

命令行和 JSON-RPC 守护进程版本现在能用了。一两天内提交到 SVN。

我在我的 Ubuntu 系统上禁用了 gdm，让它启动进命令行。希望之后能用 rcconf 把它再启用回来。

其他参与者原话XunieFebruary 23, 2010原帖 ↗

/etc/init.d/gdm start，gdm 就会启动！

啊对，这就好了，一切恢复正常。

ctrl+alt+F[1-8] 在这台电脑上从来不管用。屏幕直接乱成一团。

它为每个线程设置不同的优先级。生成线程以 PRIO_MIN 运行。其他线程几乎不占 CPU，以普通优先级运行。

#define THREAD_PRIORITY_LOWEST          PRIO_MIN
#define THREAD_PRIORITY_BELOW_NORMAL    2
#define THREAD_PRIORITY_NORMAL          0

由 Windows 优先级换算来的那些值，大概出自这样一张表：

"下表展示了 nice 值与 Win32 优先级之间的映射。Win32 优先级问题的更多信息参见 SetThreadPriority() 的 Win32 文档。

nice 值 Win32 优先级

-20 到 -16 THREAD_PRIORITY_HIGHEST

-15 到 -6 THREAD_PRIORITY_ABOVE_NORMAL

-5 到 +4 THREAD_PRIORITY_NORMAL

+5 到 +14 THREAD_PRIORITY_BELOW_NORMAL

+15 到 +19 THREAD_PRIORITY_LOWEST"

如果你有更好的取值，欢迎建议。

另外，网上有些建议说 Linux 上应该用 PRIO_PROCESS，因为线程即进程。如果这说法不成立，也许这就解释了为什么整个应用的优先级被意外设置。

// threads are processes on linux, so PRIO_PROCESS affects just the one thread

setpriority(PRIO_PROCESS, getpid(), nPriority);

是每次运行都发生，还是在某个随机时刻只发生过一次？

我以前从没见过它失败。那是一次对 OpenSSL 的调用，我以为它永远不会失败，但我还是在那里放了个错误检查以防万一。我想不出它会怎么失败。也许是内存耗尽。

代码是：

key.h:

EC_KEY* pkey;

pkey = EC_KEY_new_by_curve_name(NID_secp256k1);
        if (pkey == NULL)
            throw key_error("CKey::CKey() : EC_KEY_new_by_curve_name failed");

NID_secp256k1 是个常量。

在 SVN 版本里，如果一笔交易需要手续费，它会显示：

"这笔交易超过了尺寸限制。你仍可支付 # 的费用发送，

费用将付给处理你的交易的节点，有助于支持网络。

你愿意支付这笔费用吗？"

如果加上费用后你的钱不够，它会显示：

"计入 # 手续费后，总额超出你的余额 "

其他参与者原话NewLibertyStandardMay 23, 2010原帖 ↗

Bitcoin 在 Ubuntu 的新默认主题下很难看。似乎有一部分（但不是全部）主题设置被应用了。未选中的文件菜单应该是浅色文字配深色背景，但它错误地变成了浅色文字配浅色背景。两者太接近，在我的显示器上根本读不清。应该在下一个稳定版发布前修掉。

这在 SVN 版本里已经修了。

1) 菜单栏默认颜色。

2) 余额栏不再是另一种颜色。

3) 比特币地址和余额背后的背景现在与工具栏同色。

我检查了所有标准主题，在它们下看起来都正常。

Ubuntu 把最小化、最大化、关闭按钮移到右边：

gconf-editor

apps->metacity->general

button_layout=menu:minimize,maximize,close

考虑到 10 个用户里有 9 个都习惯按钮在右边，这个设置藏得也太深了。

我把哈希表（hashmeter）的设想集成进了 SVN 版本。它在状态栏左半区显示 khash/s。

新增两条日志消息：

21/06/2010 01:23 hashmeter 2 CPUs 799 khash/s

21/06/2010 01:23 generated 50.00

在 debug.log 里 grep "generated" 看你生成过什么，grep "hashmeter" 看性能。Windows 上用：

findstr "hashmeter generated" "%appdata%\bitcoin\debug.log"

我的 hashmeter 消息每小时一条。你觉得应该多久一次？

在 Ubuntu 10.04 上它无法干净地移除任务栏按钮，所以我让它把按钮留在那儿。

不过既然你提了，这个功能哪怕乱一点也比没有强——尽管任务栏按钮暂时还在、点击一下才消失，这可能会让一些人困惑。

SVN 已更新。

谢谢测试。

现在改 0.3 的功能已经太晚了，但我会把它加进 0.3 之后的待办清单。你不说我永远注意不到这点。

同意。这种小事当然不值得去搅扰用户的注意力。

我改成了每 30 分钟一次。

如果我加频到每 10 分钟一次，它在日志文件里的存在感也还是足够小。问题只在于 grep 时输出会不会比用户想要的多。

其他参与者原话davidonpdaJune 22, 2010原帖 ↗

EXCEPTION: 22DbRunRecoveryException

DBENv::open: DB_RUNRECOVERY: Fatal error, run database recovery

C:\Program Files\Bitcoin\bitcoin.exe in OnInit()

什么操作系统？

通常它这样做是因为数据目录该在的那个目录不存在。看看 "%appdata%" 目录是否存在。

0.2 也有这个错误吗？很难想象你在 0.3 上遇到它而在 0.2 上没有——这方面并没有什么不同。

davidonpda，你之前也是跑的 laszlo 构建吗？

检查 "%appdata%" 目录是否存在，以及 "%appdata%\bitcoin"

试试：

rename "%appdata%\bitcoin" bitcoin2

那样能行吗？

状态栏的第一格与菜单项的帮助说明共享：当你悬停在菜单项上时。因为我们所有菜单项的说明都是空白，所以悬停在菜单上时它就被替换成了空白。

感谢发现。我们在 0.2 版用的是 ANSI、0.3 版换成了 UTF-8，应该与此有关。

想确认一下：如果你用非拉丁字符的用户名登录、尚无 appdata/Bitcoin 目录，然后运行 Bitcoin 让它从零创建数据库，能不能正常工作？

我想我看出问题在哪了。巧合的是，我最近刚写了一个替代函数来替换出问题的这个，应该能修复。它还没启用，但在 SVN 版本里，它会在 debug.log 打印一条调试消息，显示新的目录值和旧值以便对比。

我用 XP 上的一个非小写 ASCII 账户名测试，确认了此 bug，然后测试了新的 GetDefaultDataDir 能修复它。此改动是 SVN 第 102 版。

所以就是它挡住了区块下载？

链接："Win32 CPU Cycles vs 'Live Protection' Engines"

对 BitcoinFX 来说，是实时防护阻止它获得挖矿所需的 CPU 时间。你说你朋友能跑到 1400–1600 khash/s，说明它其实拿到了 CPU 时间。我猜当时实时防护拦截的是程序的其他部分？

在 Windows 上，你在任务管理器里选中进程，右键，设置优先级。设为"低于标准"或"低"。不过这应该没有影响。

如果你关掉"挖矿"，CPU 占用会不会立刻平掉？那就能确认它占的 CPU 时间全是生成，而那本来就是空闲优先级。

也可能慢只是因为你同时运行的东西太多、内存耗尽开始用页面文件了。当你从一个程序切到另一个，就得从磁盘把它换页进来。

Laszlo 已修正此问题，可惜赶不上 0.3.0 了。不过应该很快会有 0.3.1。

问题在于我用的是 PRIO_MIN，最低优先级本该用 PRIO_MAX。操作系统本不该允许你调高优先级，所以用 PRIO_MIN 应该会让它停在优先级 0。

这已经是我第二次见到有人报告这个"Live Protection"问题了。

它一定是在阻断程序的网络通信。听起来它允许建立连接，所以显示了 10 条连接，却不允许在上面收发任何数据。

我们需要更好地弄清这个问题。

有没有人能在 wiki 上写点说明，讲讲如何关闭实时防护（或它完整正式的名称）或添加排除项。

你的电脑语言设置是什么？是德语、荷兰语还是意大利语？还是"nl-??"这类子语言？

它在尝试加载翻译但失败了。你可以删掉 bitcoin 自带的 locale 目录，让它不再尝试使用。

有人能在 Ubuntu 上把每种语言都测一遍，看看是只有一种有问题，还是三种都有吗？

在最初错误地尝试把自己设为最低优先级之后，生成线程只在找到区块时才临时再次调整优先级。找到区块时，你当然希望它赶紧在别人先找到一个、让你的作废之前尽快广播出去。生成线程只在每几天里以更高优先级运行不到一秒。

很快会有针对此问题的 0.3.1 发布。在发布之前，0.3.1 还有几个其他问题需要修复。

其他参与者原话knightmbJuly 12, 2010原帖 ↗

顺带一提，我追查到了另一个 GUI 问题。

"最小化到托盘而非任务栏"就是吃光我系统全部 CPU 的元凶。关掉这个选项之后，CPU 失控的问题就解决了。

似乎只有 64 位客户端受影响，我的 32 位客户端看起来都没这个问题。

我确实注意到 64 位客户端会不断生成多个"托盘"图标，直到 X 服务器最终垮掉，我想我应该把这个作为 bug 提交到什么地方？

有意思。我知道 Ubuntu 上的最小化到托盘非常笨拙，但不知道它还有 CPU 占满的问题。有人能复现这个问题吗？我们以前在 Linux 上禁用过这个功能，但后来觉得不完美的界面总比彻底失去这个功能好。我想我们应该在 Linux 上再次禁用它。

Microsoft Security Essentials 的实时防护（Live Protection）正在阻断你与网络的通信。你有连接，这让 Bitcoin 以为自己已联网，但连接是静默的，因为数据被拦截了。

你需要把 bitcoin.exe 加进实时防护的排除进程。

这正在变成一个常见问题。应该有人写一篇置顶帖说明。

"Warning: This block was not received by any other nodes"这条消息出现在 Bitcoin 广播了一个区块但没人确认收到时。这个警告正是为这种情况准备的：你出于某种原因有连接，但连接已经死了，没人听得到你。你的区块永远不会生效，因为没人收到它。

好，加了未写入文档的开关"-minimizetotray"来重新启用该选项。

我已把改动上传到 SVN。

更直接的，是这个：

http://bitcointalk.org/index.php?topic=246.0

我很快会发布包含此修复的 0.3.1 候选版。请试用，并告诉我问题是否解决。

那么这些 CPU 时间全是生成线程的，它肯定以可能的最低优先级——空闲优先级运行。CPU 表停在 100% 是正常的。既然是空闲优先级，即便 CPU 表是 100%，它实际上不会拖慢任何其他东西。

我不认为你有什么特别的问题。我觉得你的系统慢是因为同时运行的东西太多，内存满了开始用页面文件。你已经确认关掉生成后 CPU 掉到 0%，所以 CPU 占用肯定全是空闲优先级的。0.3.1 里没有任何会影响这些的改动。

其他参与者原话knightmbJuly 15, 2010原帖 ↗

在 Windows 上，挖矿的优先级仍相当于正常。如果你以挖矿模式运行 BitCoin，再运行一个吃光 CPU 的东西（比如 CPU hog：http://www.microtask.ca/cpuhog.html），你会看到 BitCoin 和 CPU hog 以 50/50 平分 CPU，而不是 CPU hog 独占、BitCoin 只在空闲/低优先级上运行。khash/s 也减半了，这进一步证明线程并非运行在低于正常的优先级。

我没能复现。我是双处理器，所以跑了两个内存吞噬程序。任务管理器显示 Bitcoin 的 CPU 是 0%。khash/秒的表针卡住不动，因为它一点 CPU 都分不到来刷新自己。

你是双处理器吗？你确定你跑的不是单处理器吞噬程序？

其他参与者原话dbJuly 15, 2010原帖 ↗

bincoind help 里 listreceivedbyaddress 和 getreceivedbyaddress 命令重复了。（0.3.0 也一样。）

是的，是个 bug。下个版本修。

挺意外，之前从没听人说起过。

也许你是第一个在 Vista 上跑它的人

我猜跟你的显示颜色深度设置有关。比如 8 位、16 位、24 位、32 位，你的是多少？你的显卡、显示配置很特别吗？是在平板、手机之类的设备上跑吗？

linux 上线程优先级的修复在 0.3.1 候选版里：

http://bitcointalk.org/index.php?topic=383.msg3198#msg3198

其他参与者原话RHorningJuly 15, 2010原帖 ↗

两种都没看到发生，虽然它确实进了「Startup」文件夹。这也太 Windows 95 了（开个玩笑……微软把这搞砸得都不好笑了）。出于好几个原因我推荐用注册表，包括大多数软件都把自启动放在那里，尽管我个人觉得启动文件夹更有好感，也是 Windows 上大多数软件本应有的行为。

两种做法各有道理。启动文件夹的好处是最终用户看得见，就算已经删掉了 Bitcoin 目录和它的卸载程序，也能用常规界面（不用 regedit）手动移除。如果你手动删掉它，Bitcoin 不会固执地一遍遍加回来。

OpenOffice 是另一个把链接放进启动文件夹的例子。

其他参与者原话bdonlanJuly 15, 2010原帖 ↗

是 120DPI 模式。

什么是「120DPI 模式」？这是某个实际存在的设置吗？听起来是个足够冷门的嫌疑对象。我猜它需要一个两倍分辨率的图标来填满左上角图标的大小，而我们只提供了一种尺寸。

用未写进文档的开关 -minimizetotray 运行，该选项就会出现在选项菜单里。

我不知道怎么修。问题出在 wxWidgets 或 GTK 或 Gnome 的深处。

那肯定就是它了。

它一定是在找一个更大的图标，比如 20x20，而我们没有。

其他参与者原话hugolpMay 08, 2010原帖 ↗

一跑 bitcoin 界面就变得非常迟钝，几乎没法用。停掉 bitcoin 一切恢复正常。系统是 Ubuntu desktop 10.04 amd64，用 ia32libs 和 bitcoin 0.20 tarball 里的二进制。

0.3.1 修复了这个问题，把生成线程设到了最低优先级。下载链接已挂在首页。

变更内容基本上就是首帖列的那些。为了重要的安全改进，所有人都应升级。

最小化到托盘在 Linux 上至少有 3 种不同的故障和 bug，包括崩溃，所以我再次禁用了它。你仍然可以用 "-minimizetotray" 重新启用该选项。这些 bug/故障藏在 wxWidgets 或 GTK 或 Gnome 的某处，我不知道怎么修。抱歉，我实在没别的办法，它毛病太多，当不了主线功能。

我复现了这个问题。数据库不喜欢相对路径。

"bitcoind -datadir=./subdir getinfo" 对着运行中的守护进程是好使的，但以 "bitcoind -datadir=./subdir" 启动守护进程就抛那个异常。

我看应该在传给数据库之前把路径解析成完整路径。

看来你是第一个用相对路径 -datadir 的人。

它往控制台打印什么了吗？你确定跑的不是 "bitcoind"？

不妨试试 0.3.7 版本。

「最小化到托盘而非任务栏」和「关闭时最小化到托盘」在 Mac 上想必还没实现。下个版本我们应该把它们置灰。

已在 SVN rev 130 修复。

我想把状态栏显示的区块数减 1。这样程序第一次加载时，会显示 0 个区块而非 1：

"0 connections 0 blocks 0 transactions"

它一直是 "nBestHeight + 1"，因为把创世区块也数了进去。严格来说，是的，创世区块是一个区块。它是你出发时就带着的硬编码区块。你不可能没有创世区块。也许可以把它想成一枚基准币，其他币都拿它来衡量。人们想看的区块数，其实是他们下载到的区块数量。

主要的好处是区块数会等于当前最佳区块的区块号。如果区块数是 10，那么你拥有的最高区块号就是 10。意味着你有 10 号区块，没有 11 号区块。

它能减少我们在这里遇到的困惑：

其他参与者原话kencauseyAugust 15, 2010原帖 ↗

我自己也在这上面犯过迷糊，后来在 #bitcoin-dev 问清楚了：

坏区块是 74638 号，最后一个好区块是 74637 号。编号从 0 开始，所以当你的客户端显示有 74638 个区块时，意味着你拥有到 74637 号为止的区块，也就是最后一个好区块。

已在 SVN rev 137 完成

确认你电脑的日期和时间设置正确。

我不知道该叫它什么，但我们可以发一个帖子，列出这些用户应该知道的事。谁有时间写的话，清单在这里：

• 确保你的时钟设置正确。

• Microsoft Security Essentials。这件事一直没被正经写下来。

• 警告：别乱动你的 wallet.dat 文件。它是个数据库文件，没有你想的那么简单。在这个 Beta 版里，我们还没来得及把它做得防手贱。如果你把它换来换去，它可能不像预期那样工作。

时钟部分会在下一个版本（0.3.11 或更高）里解决。SVN rev 141 会在你的时钟偏差太大时弹出消息框。

在 debug.log 里搜 "proof-of-work found"。如果搜到了，就检查紧接着的任何错误。

其他参与者原话davidonpdaAugust 19, 2010原帖 ↗

时间上允许多大的偏差才能正常工作？

容许偏差是 2 小时。

这个问题会在 SVN rev 141 和下一个版本（0.3.11+）里解决。如果你的时钟偏差超过一小时，它会弹出消息框提醒你。

你大概可以直接注释掉这一行

cryptopp/secblock.h:187

//assert(false);

好用了告诉我，并留意是否内存泄漏。

它看起来是一个模板类，用来确保派生类定义自己的 allocate 和 deallocate 版本。如果那真是问题所在、还一路带进了发布版，那就太怪了。大概是虚惊一场。

这条错误消息有没有更好的写法建议，让下一个人不那么容易困惑？

它想告诉用户时钟不对，需要校正。

它依赖三个时间来源：

1）系统时钟；

2）其他节点的时间，但只有在与系统时钟相差不超过一小时时才采用；

如果两者不一致，就使用第 3 种来源：

3）用户，也就是请用户修正系统时钟。

我考虑过 NTP，但这个方案更安全。

其他参与者原话InstiSeptember 06, 2010原帖 ↗

"请检查你电脑的日期和时间是否正确。如果你的时钟不对，Bitcoin 将无法正常工作。"

谢谢。

在 0 和 2 个连接之间来回跳，恐怕是它在连接自己。你用了 "-connect" 开关吗？

是你自己编译的还是发布版？什么版本？

我不确定 200Kb/sec 怎么来的，因连接尝试之间至少等半秒。它在 0 和 2 个连接之间闪多快？比每秒两次还快？

linux 上的等待函数是：

inline void Sleep(int64 n)

{

boost::thread::sleep(boost::get_system_time() + boost::posix_time::milliseconds(n));

}

如果这个等待函数没有正常工作，程序就可能以最快速度空转这个循环。

我并未搞懂，你是不是以为程序会设置系统时钟？它并不会。

其他参与者原话CdeckerSeptember 19, 2010原帖 ↗

我们已经有（近似）同步客户端的办法了，为什么不加以利用？

我们用一个基于其他节点时间中位数的内部偏移，但出于安全考虑，不允许它们把我们的偏移量带偏超过一小时。如果它们显示我们偏差超过一小时，我们就转为提醒用户去修自己的时钟。

其他参与者原话OdinOctober 22, 2010原帖 ↗

故障模块名称： mingwm10.dll

这是关键线索。我相信它的意思是崩溃发生在那里。也许有其他版本能试。mingwm10.dll 只是一个简单的占位物，满足多线程应用的某个回调要求。

尚有其他人能在 64 位 Windows 上正常跑吗？

我唯一能想到的，是看看能不能弄到其他版本的 mingwm10.dll。mingwm10.dll 是随 MinGW 编译器附带的一个小小的 DLL，多线程构建时需要它。我不确切知道它干什么，但它大概只是在对 Windows 说「好了好了，你看，我在一个 DLL 里，如你所愿」。

你 debug.log 文件的末尾可能会显示它崩溃前在做的最后一件事。

SVN 上的 0.2.6 版现在可以作为守护进程运行，并用命令行或 JSON-RPC 控制。

在 Linux 上需要装 libgtk2.0-0，但不需要运行 GUI。希望 gtk 能在没有窗口系统的情况下安装。

以守护进程方式启动的命令是：

bitcoin -daemon [switches...]

或者，既正常运行 UI、又能用命令行或 JSON-RPC 控制的话，用 "-server" 开关。

bitcoin -server [switches...]

无论哪个开关，它都会运行一个 HTTP JSON-RPC 服务器，接受 127.0.0.1:8332 上的本地套接字连接。端口绑定在回环上，只能从本机访问，但任何账户都可以，不限运行它的那个用户。

用命令行控制它的接口是：一个不带任何开关的命令名，后跟参数（如有）。

bitcoin [params...]

例如：

bitcoin getinfo

bitcoin getdifficulty

bitcoin setgenerate true

bitcoin stop

它是一个简单的 JSON-RPC 客户端，会打印 JSON 结果。命令列表见 rpc.cpp。

Web 应用或任何自动化程序一般直接用 JSON-RPC，不用命令行。主流语言都有 JSON-RPC 库。在 PHP、Python 这类脚本语言里，语法就像调用本地函数一样自然。

欢迎，Harry。

我还没想过不经过 bitcoin 直接从 bitcoind 上手。我想现阶段，这个主题串就当教程用吧。

bitcoind 目前的重点更多是网站的后端支持。也有人希望有一些便于管理无界面挖矿机的功能，比如 listgenerated。目前，你可以在 debug.log 里 grep "generated" 和 "hashmeter" 看些反馈。生成的区块大约要 24 小时才计入你的余额。

其他参与者原话lachesisJune 16, 2010原帖 ↗

我想你误解了这个问题。我的浏览器永远可以访问 127.0.0.1（除非奇怪的 IE 设置或病毒作祟）。无论在地址栏输入还是点击链接，都能正常工作。但 Javascript 无法完成跨域（或同域不同端口）的 POST 请求。

我也是这么想的。

其他参与者原话sirius-mJune 16, 2010原帖 ↗

对，我是想说跨域的 javascript 调用是被禁止的，所以不能从不位于 127.0.0.1 的 javascript 去调用 127.0.0.1。想想还挺有意思，如果浏览器允许恶意跨域 javascript 改别人的 Facebook 页面之类，那场面一定很欢乐。

现在有消息说，javascript 其实可以跨域对 127.0.0.1 发 POST 请求。不是对别的域，偏偏对这个就行。太好了……

如果确实这样，那就不要在上网用的机器上使用 -server 开关或 bitcoind。

我这就着手加密码字段。

我把给 JSON-RPC 加密码的修改传到 SVN 了。如果你搭好了编译环境，请帮忙测试。

-server 开关被 -rpcpw= 取代，bitcoind 也用它。

bitcoin -rpcpw= -- 带开放的 JSON-RPC 端口运行

bitcoind -rpcpw= -- 带密码的守护进程

如果你对开关的名字有更好的想法，告诉我，但请记住将来数据库加密也需要一个密码。我不确定，但我觉得两种密码他们可能会想用不同的。

不设密码的话会给出警告。

现在所有命令都要把密码作为第一个参数。运行 "bitcoind help" 会告诉你这一点。

核心代码：

// Check password

  if (params.size() < 1 || params[0].type() != str_type)
      throw runtime_error("First parameter must be the password.");
  if (params[0].get_str() != strRPCPassword)
  {
      if (strRPCPassword.size() < 15)
          Sleep(50);
      begin = strRequest.end();
      printf("ThreadRPCServer incorrect password attempt
");
      throw runtime_error("Incorrect password.");
  }

对这些决定有什么意见吗？

1) if (strRPCPassword.size() < 15) Sleep(50); -- 意思是密码短的话，每次尝试之后等 50ms。这可能被用来做 DoS 攻击，但我想如果密码短，更重要的是防暴力密码扫描。这可能让外人得知密码不足 15 个字符，但不足 15 也不算什么值得注意的信息，大多数密码都不到 15。如果你想封死 DoS 的可能，用 15 个字符或更长的密码就是。

2) begin = strRequest.end(); -- 如果是单个请求携带多个调用，只要有一个密码错误，我就把剩下的全部丢弃。这样就不能在一个包里塞进上百万次密码尝试。你们觉得这样做对吗？（多调用反正几乎从来没人用）

我还修了帮助里列出的两个重复命令：

getaddressesbylabel

getbalance

getblockcount

getblocknumber

getconnectioncount

getdifficulty

getgenerate

getinfo

getlabel

getnewaddress [label]

getreceivedbyaddress [minconf=1]

getreceivedbylabel [minconf=1]

help

listreceivedbyaddress [minconf=1] [includeempty=false]

listreceivedbylabel [minconf=1] [includeempty=false]

sendtoaddress [comment] [comment-to]

setgenerate [genproclimit]

setlabel

stop

对，那样确实好不少。

能给我举几个也这么做的别家例子吗？（命令行长什么样）

你在这里说的主要变化是：启动 bitcoind 时不用 -rpcpw=，而是用一个开关指定一个文本文件去那里读，对吧？（有没有想法该给开关起什么名？）

不要在上网用的机器上使用 -server 或 -daemon 开关、不要跑 bitcoind。它会在 127.0.0.1（本地回环地址）上打开 8332 端口，你可能以为 web 浏览器没法跨站访问它，但确实可以。

我们正在做一个很快发布的版本，给 JSON-RPC 接口加上密码，但在那之前，避免使用 -server 开关，也不要在跑 bitcoind 的同一台机器上上网。

更新：

0.3.3 的 JSON-RPC HTTP 认证功能解决了这个问题。

所以是把设置文件丢进 ~/.bitcoin 目录，这样听起来更好。「未设密码」的警告里可以告诉你文件在哪、该做什么。

最流行、最常见的设置文件格式是什么？

应该考虑 HTTP basic authentication。不过实际操作中，对 web 开发者来说，研究怎么通过 HTTP 或 JSON-RPC 包装层的某个额外参数指定密码，比直接在参数列表开头塞一个额外参数更费劲。你们怎么看？HTTP basic authentication 能给我们带来什么额外好处吗？把它挪出参数列表，结果还是要在一个更深奥的地方指定它，我不确定这是净收益。

其他参与者原话gavinandresenJuly 19, 2010原帖 ↗

我一度被绕晕了，因为密码在命令行上是最后给，在 JSON-RPC 参数列表里却是第一个。我同意从文件里读命令行密码会更方便、更安全。

你也把我绕晕了，什么意思？我做了什么 unintended 的事吗？

还是想知道 Linux 上最典型的设置文件格式。有标准扩展名吗？我从没见过用 JSON 的设置文件，而且所有东西都得加引号，看起来也不太人性化。我平时见到的多半类似：

# comment

setting=value

Boost 里有设置文件方面的东西吗？

用 bitcoind 从命令行当客户端发命令时，能不能也让它从设置文件读密码？

Gavin 指出我忘了在 CommandLineRPC 里给数字列做递增，所以现在的 -rpcpw= 实现在命令行上带非字符串参数时不能正常工作。（JSON-RPC 没问题）仍在建设中。

我调研了一圈配置文件格式，给你个对比。

YAML 太庞大了。我不确定有轻量易集成的库能进我们的项目。感觉杀鸡用牛刀。

JSON 很诱人，我也倾向喜欢它，但有两个主要痛点：

1) 不能写注释！一个配置文件居然不能注释掉一行来停用它？

2) 所有字符串都得「加引号」，连键也一样，还得记得行尾的逗号。

{

"key" : "value",

}

我想我们可以很容易地预处理 JSON：逐行读配置文件，在任何 # 字符处截断行（还有 "//"？），拼成一个字符串传给 JSON，于是可以写成：

# comment

"key" : "value", # 还得记得逗号

"key2" : "value", // 像这样注释，或两种都用

Boost 有 boost::program_options。

我们可以自己读行，喂进 map mapConfig。

while (!eof)

read line

if '#' found, truncate line

split line at first ':' -> key, value

mapConfig.insert(key, value)

如果我们用这样的语法：

# comment

key : value

……并且不允许键前面有空白缩进，我猜我们就是 YAML 的一个子集，将来需要更复杂的东西时可以切换到 YAML。

如果走自解析路线，也不妨碍按需对特定参数值用 JSON。某个选项需要列表或更结构化的数据时，它的值可以随时按 json 解析：

key : ["item1", "item2", "item3"]

只是那就必须全部写在一行上。

我想我倾向于自解析的 mapConfig：

# comment

key : value

其他参与者原话gavinandresenJuly 21, 2010原帖 ↗

我刚在我 debian 系统的 /etc 里快速扫了 20 个 .conf 文件，发现：

1 个文件用 "key value"

5 个用 "key=value"

谢谢这份调查！

我觉得 "key value" 有点不自然。键和值之间应该有一个更明确的、暗示赋值的分隔符。用空格的人，也许只是懒得用他们语言自带的 split 函数。

key=some full sentence with spaces in it. # 看起来比这样清晰

key some full sentence with spaces in it. #

那好，就用自解析的 mapConfig，语法：

# comment

key=value

扩展名 .conf。文件名叫什么？~/.bitcoin/settings.conf 还是 ~/.bitcoin/bitcoin.conf 还是别的？

我觉得最好把键和值开头结尾的空白都去掉。

# 喜欢列对齐的用户

k = value

key = value

longerkey = this sentence would be this # "this sentence would be this"

key = value # 猜这样也行

nextkey = value

right = justified

正常语法应该是 "key=value"，只不过偶尔有人写 "key = value" 也不能怪人家。

boost::program_options 就是同样的 "key=value" 格式。Gavin 指出，我们可以把它当作简单的解析器来用，不碰那些深奥的 c++ 语法（比如带类型的值提取）。以后想要更多功能再说。

咱们就用 HTTP basic authentication 吧，取代密码参数。

其他参与者原话gavinandresenJuly 22, 2010原帖 ↗

TODO：如果没设 rpc.user/rpc.password，弹对话框或在 debug.log 里警告，说明如何设置。

在 RPC 相关的很多场景里，可以这样用 fprintf(stdout, 打印到控制台：

#if defined(__WXMSW__) && wxUSE_GUI

MyMessageBox("Warning: rpc password is blank, use -rpcpw=

", "Bitcoin", wxOK | wxICON_EXCLAMATION);

#else

fprintf(stdout, "Warning: rpc password is blank, use -rpcpw=

");

#endif

其他参与者原话gavinandresenJuly 23, 2010原帖 ↗

问大家一个问题：我该不该在 wiki 页面加一节，详细讲怎么做 HTTP Basic authentication？PHP 和 Python 特别简单——用 http://user:pass@host:port/ URL 语法就行。

要，我觉得这非常好，省得每个开发者都自己摸索一遍。我们需要给 Python、PHP、Java 各配一个简单示例，导入 json-rpc 库并用它跑一个 getinfo 之类的调用，包括做 http 认证那部分。

Gavin 的修改看着不错。我认为一切都齐了。这是个测试版，请大家测试！

http://www.bitcoin.org/download/bitcoin-0.3.2.5-win32.zip

http://www.bitcoin.org/download/bitcoin-0.3.2.5-linux.tar.gz

如果我没记错，500 是 JSON-RPC 错误响应规定使用的状态码。回复的正文里仍有 JSON 响应，说明错误的具体原因，比如 {"result":"","error":"bitcoin address not found","id":"1"}。

我不认为在没有 conf 文件、或配置文件不含 "rpcpassword" 时就该默认禁用认证，但如果配置文件里写的是 "rpcpassword=" 呢？

两边的道理我都懂。

如果程序员搞不定用他们的语言（Fortran 之类）做 HTTP 认证，或者他们的 JSON-RPC 库压根不支持呢？应不应该允许他们显式关掉密码要求？

话又说回来，如果有个模板 conf 文件，里面是

rpcpassword= # 在这里填入密码

许多系统不允许无密码登录。比如这个论坛。Gavin 的观点看起来更有力。

顺便说一句，我没测过，但我希望 conf 文件里 rpcpassword=（空值）是合法的。只有用 -server 或 -daemon 或 bitcoind 时才该报错警告。如果不需要密码，就应该没事。是这样吗？

显然，重复头部是个 bug。

我当时是想遵循 1.0 规范：http://json-rpc.org/wiki/specification 它要求支持 multiple invocation。

我想他们的意思是下面这样，但不确定：

Post:

{"method": "postMessage", "params": ["Hello all!"], "id": 99}

{"method": "postMessage", "params": ["I have a question:"], "id": 101}

Reply:

{"result": 1, "error": null, "id": 99}

{"result": 1, "error": null, "id": 101}

我不记得在哪看到过错误回复应返回 HTTP 状态 500。如果回复里含多个响应且其中一个是错误，我猜整个的状态就是 500。也许应该一律返回 200。我记得有人说 500 可能导致了问题。

这个多半要等 0.3.3 之后修。在那之前，只用单调用。我不知道有没有哪个 JSON-RPC 包真的支持 multiple invocation，多半没有。

最好先弄清楚 multiple-invocation 到底应该怎么工作（如果真该支持的话），以及错误响应返回 HTTP 500 是否正确，再去修它。

有谁能确认，HTTP 上的 JSON-RPC 在错误回复时是否按规定该用状态 500？我记不清从哪看来的，也可能是错的。感觉 200 更合理，除非 HTTP 请求本身的机制出了问题。（也许原文只针对某种情况，我忘了，然后把 500 扩散到了所有错误响应）

0.3.3 的 JSON-RPC HTTP 认证功能解决了这个问题。

其他参与者原话lachesisJuly 25, 2010原帖 ↗

我发现了一个疑似 bug：当用户名和密码的组合够长时，bitcoind 的 base64 编码器生成的授权头看起来是这样的：

...
Authorization: Basic YWJiYWJiYWFiYmE6aGVsbG93b3JsZGhlbGxvd29ybGRoZWxsb3dvcmxkaGVsbG93
b3JsZGhlbGxvd29ybGRoZWxsb3dvcmxk

它每 64 个字符插入一个换行，这显然会破坏 Authorization 头，于是 "bitcoin getinfo" 这类命令失败。行为规范的客户端连服务器仍然一切正常。

解决办法是在 Base64Encode 函数末尾把 result 里的换行（也许还有 '

'）去掉：

result.erase(std::remove(result.begin(), result.end(), '
'), result.end());
result.erase(std::remove(result.begin(), result.end(), '
'), result.end());

给你 +1，密码长到能发现这个 bug。

已传到 SVN，rev 110。

其他参与者原话BitLexJuly 25, 2010原帖 ↗

我在用 PHP 跑这个的时候也遇到了问题。

到现在都没成功，wiki 示例（jsonRPCClient 试图 fopen(http://username:password@localhost:8332/)）和我的 curl 示例（用 setopt CURLOPT_HTTPAUTH, CURLAUTH_BASIC）看起来都不行。

这就怪了，不是刚有人说这样应该能行吗？（他用的什么库？）查出问题在哪就发上来。

我希望它不会跟所有 PHP 用户都这么较劲。

看来 Fortran 场景已经提前上演了。

其他参与者原话gavinandresenJuly 25, 2010原帖 ↗

漂亮的发现！更简单的修法是在 rpc.cpp/EncodeBase64 函数里指定 BIO_FLAGS_BASE64_NO_NL：

SVN rev 111

其他参与者原话gavinandresenAugust 03, 2010原帖 ↗

你能更具体地说说哪些 JSON 库不提供 Content-Length 吗？把这个记录下来会很有用。

我想我们应该试着支持没有 Content-Length 参数的情形。不过我不想推倒重来换掉流处理，哪怕得一个字符一个字符地读。

编辑：当然，前提是真的存在不支持 Content-Length 的库。

现在就开始为了向后兼容而不惜一切代价把 API 搞乱，太早了。

直接返回 "" 就好。

其他参与者原话jgarzikAugust 15, 2010原帖 ↗

扩展帮助可能源自我的想法，但代码写得有些不一样。

想法才是主要的部分。你把补丁发上来时，我意识到本来就该那么做，而非 "-?"。我对 "-?" 一直有顾虑：它侵占了可能的参数取值，而且帮助响应依据的是调用方版本而非服务器版本。

这在 SVN rev 147 里。

这样更标准。虽然 json-rpc 1.0 没有规定错误对象的格式，但它规定了错误务必是对象而不是字符串或其他值，因此我们得改过来才算正确。code/message 成员在后来的 json-rpc 规范里已经成为标准。

如果你有检查 error 并期望字符串的代码，你需要改它。出错时，error 成员现在是对象而不是字符串。

SVN rev 147 里尚有：

• 命令行 json-rpc 把错误码作为退出码返回。unix 上退出码只能是 0-255，因此是 abs(code)%256。
• 另一个帖子里讨论过的 "backupwallet " 命令。它会锁定钱包并拷贝，因此你能确定拿到的是正确的副本。

如果你在自己的局域网内使用，它能安全，比如你在一个场所有多台服务器互相通信。

0.3.13 RC1 的 Windows 版已可用：

http://www.bitcoin.org/download/bitcoin-0.3.13-rc1-win32-setup.exe

对外 API 的库代码里我喜欢注释头，但从代码你应该看得出来，内部函数我不是这种风格的拥趸。给每个函数都加一个必写的大注释头，会把代码撑开，让你在写一个小函数时犹豫不决——注释头比函数本身还大。它们对维护也是种麻烦，函数一改，注释头就得跟着改两遍。我喜欢把代码写紧凑些，好让一屏能看到更多代码。

事到如今再补的话，写出来的只会是看函数一眼就能明白的东西。

我们现有的对外 API 在 rpc.cpp，用法文档在帮助字符串里。

扫兴了，抱歉。

一定是 getinfo 转成浮点数返回 JSON-RPC 结果时的舍入误差。唯一用浮点数表示钱的地方就是返回 JSON-RPC 值。

1.139999999999 比 bitcoin 内部能表示的更长。

内部只可能是：

1.13999999 或

1.14000000

1.139999999999 离 1.14000000 比离 1.13999999 近得多，所以一定是 1.14000000。

代码是这样的：

(double)GetBalance() / (double)COIN.

（一时想不出简单的修法）

我没意识到你会把那些有意不写进文档的命令全都记录下来。它们不受支持，也不是给用户用的。

所有面向用户的命令都列在 -? 帮助里。

它们只打算给那些会去读源代码的无畏程序员用。

FLATDATA 是序列化定长字段数组的一个权宜办法。本来有一种更干净的方式让它直接懂得如何序列化数组，但 MSVC6 做不到，而我当时想保持对 MSVC6 的兼容。我们已经不再支持 MSVC6，因为用到的 Boost 里的某个东西不支持它。0.2.0 之后失去了它的支持。也许哪天我会换成那种干净的方式，不用包一层 FLATDATA 就知道怎么序列化定长数组。

我替换掉了 bitcoind 里最后几个 wxBase 依赖。

bitcoind 现在在 SVN rev 112 里不依赖 wxWidgets 或 wxBase 就能编译。

main(int argc, char* argv[]) 加进了 init.cpp。CMyApp 和启动文件夹的东西挪到了 ui.cpp。bitcoind 不链接 ui.cpp 和 uibase.cpp。

makefile 用 -DGUI 控制是否使用 GUI。

我测试编译了 MinGW、VC 和 Ubuntu。不知道有没有弄坏 Mac OSX 构建，需要有人检查一下。

我当初没用 protocol buffers 或 boost 序列化，是因为它们看起来太复杂，没法做到绝对滴水不漏、绝对安全。它们的代码量太大，读不完，也就无法确保不存在某种能触发意外行为的输入。

我讨厌重复造轮子，是不得已才自己写序列化例程的。我们现有的序列化格式尽可能简单、扁平。输入流的构成方式没有任何多余的自由度。每个时点，数据结构里的下一个字段都是预期中的。仅有的选择权就是接收方预期中的那些。有版本号，所以可以升级。

CAddress 差不多是唯一一个留有大量保留空间的对象。（约 7 字节用于标志，12 字节留给将来可能的 IPv6 扩展）

区块和交易这类较大的东西已经没法再为体积优化多少了。它们的主体数据是哈希、密钥和签名，不可压缩。序列化开销非常小，长度字段通常只占 1 字节。

关于 Gavin 说的现有的 P2P 广播基础设施，我怀疑那东西不存在。只需要广播的 P2P 系统很少。有些库（如 Chord）试图提供分布式哈希表基础设施，但那是个巨大而困难的问题，我们不需要也不想要。那些库装起来也比我们自己的难得多。

无符号 int 能撑到 2106 年。到那时网络肯定至少得彻底翻新一次。

不应该存在任何有符号 int。如果你在哪发现了有符号 int，请告诉我（请趁未来 25 年内），我会把它改成 unsigned int。

你能更详细说说移除 DB_PRIVATE 会带来什么吗？

我不记得当初用 DB_PRIVATE 是不是有特定理由，还是只是从示例代码里抄的标志。移除 DB_PRIVATE 能让其他进程安全地同时打开数据库吗？如果是副作用可接受，那可能是个改进。它会不会因为必须立刻写出每次改动或做其他协调而大幅降低性能？那时会有额外的锁定或协调文件吗？还有什么会变？你可以通过给初始区块下载计时来测试有无 DB_PRIVATE 的差别，最好用 -connect 连本机，排除网络因素。

显然，DB_PRIVATE 并没有做到你期望它做的事，也就是阻止其他进程打开数据库。它照样放行，只是别人真打开时会把事情搞砸。另一个选项，如果有什么办法的话，是让它锁定数据库文件，让其他进程无法访问。

如果你把它读进内存再写出去，在内存紧张的情况下可能会失败。

我在找类似 copyfile(const char* from, const char* to) 或 copyfile(path from, path to) 的东西，最好 Boost 里就有。如果你能帮我找到，我就更有可能动手实现它。

其他参与者原话neliskyAugust 26, 2010原帖 ↗

至于文件拷贝，为什么要加深 boost 依赖？我就希望核心库依赖越少越好。

我们需要 Boost 来做 JSON 和十来件原本依赖 wxWidgets 的事。Boost 是优秀的、可移植的库，我们不该躲着它。

我怀疑 Windows 上没有 mmap(2)。我宁可调用现成的文件拷贝函数，也不想自己写一个再测试。

其他参与者原话neliskyAugust 27, 2010原帖 ↗

但如果你已经在用 boost::filesystem 的功能，直接用它里面的 copy_file 就行。我只是觉得，如果不是为了别的用途已经引入了它，那有点杀鸡用牛刀。

谢谢。我原以为里面某处会有。

我们已经在十几个地方用了 boost::filesystem。这并非新增依赖。它给了我们大量可移植的东西，否则每个系统都得写 #ifdef，到处测试。

抱歉，我最近太忙，只能扫一眼消息，还跟不上。

我们要尽可能避免 Windows API 调用。它们通常要传 6-8 个参数、要大量测试才能用对，做件简单事得写一页代码。

我通常躲着 iostreams。似乎我太常撞上它的限制。他们 90 年代把 C++ 流标准搞得一团糟，真遗憾，用对了的话流可以相当强大有用。在 rpc.cpp 里用它最终恐也会被证明是个错误。

说到底，我宁可调用现成的文件拷贝函数，也不想自己写一个再测试。

这份代码从头到尾都假定小端序，写作时就打定主意永远不移植到大端平台。每一个经网络发送的整数都得做字节交换，代码里还有几十处其他地方要改。不值得为此让源码膨胀。

反正大端序也正在被淘汰。

其他参与者原话lachesisAugust 10, 2010原帖 ↗

另外，Bitcoin 是不是以独占方式打开 BerkeleyDB，从而不需要文件锁？不是——我自己测过了。

有没有办法以独占方式打开 BerkeleyDB？

DB_PRIVATE 是两头不讨好的东西。它并不独占，但一旦另一个进程试图同时访问，它就会把事情搞砸。

我在 rev 153 里去掉了 DB_PRIVATE 标志。

在 rev 153 里试着去掉了 DB_PRIVATE。我们得留意有什么不同。

至少在 Windows 上，它会创建 __db.001 到 __db.006 六个文件，大小从 24K 到 4MB。退出时不删除它们，就那么留在原地。

文档说它使用内存映射文件。我猜它们与数据库文件有同样的文件权限，所以同样的用户访问限制也适用。

Windows 私有局域网下载 78500 个区块的测试：

用 DB_PRIVATE 20 分 51 秒

不用 DB_PRIVATE 20 分 51 秒

我没料到两者会完全一样。

我们一直在为下一个版本努力改进。Martti（sirius-m）加入了一些不错的特性，让它更易用、更容易在后台运行：

• 最小化到系统托盘选项
• 开机自启选项，可以自动在后台保持运行
• 全新的选项对话框布局
• 除压缩包下载外，新增 Windows 安装 EXE

我则一直在打磨网络代码，并为后续功能打基础。0.2 版还将带来：

• 挖矿的多处理器支持
• 代理支持

Bitcoin 0.2 版来了！

下载链接：

http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.2.0-win32-setup.exe/download

http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.2.0-win32.zip/download

http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.2.0-linux.tar.gz/download

新特性

Martti Malmi

• 最小化到系统托盘选项
• 开机自启选项，可以自动在后台保持运行
• 面向未来扩展的全新选项对话框布局
• Windows 安装程序
• Linux 版（已在 Ubuntu 上测试）

Satoshi Nakamoto

• 挖矿的多处理器支持
• 配合 TOR 使用的代理支持
• 修复了初始区块下载的一些卡顿

特别感谢 Martti Malmi（sirius-m）的全部编码工作以及新网站和本论坛的托管，也感谢 New Liberty Standard 帮助测试 Linux 版。

我正在尽快把 0.3 版发出去。只剩最后几件事了。距 0.2 已经很久，我们需要一个带命令行和 JSON-RPC 的预编译 bitcoind。这次我们会同时提供 32 位和 64 位 linux 二进制，Laszlo 会构建 Mac OSX 版本。另外，我们会收录 DataWraith、Xunie 和 Joozero 的德语、荷兰语和意大利语翻译（谢谢几位！）。

我清单上为 0.3 版要做的全部事项都完成了。SVN 上的代码差不多可以发布了。

此刻的测试将不胜感激。

这是供测试的 windows 版 RC1：

（已移除，见下方 RC2）

请只在打算测试并回报一切是否正常时下载它。务必翻看 "c:\program files\bitcoin" 里的文件。

这是供测试的 linux 版 RC1：

（链接已移除，见下方）

它同时包含 32 位和 64 位二进制。

近期改动：

build-unix.txt:

• 增加了构建 wxBase 的说明，编译 bitcoind 需要它。
• libboost-dev 包不再安装任何东西，你需要改用 libboost-all-dev。
• 更新了版本号。

makefile.unix:

• libboost 库在 1.40 里从文件名中去掉了 "-mt"。如果你用 Boost 1.38 或更低版本编译，比如在 Ubuntu Karmic 上，你需要把它改回 boost_system-mt 和 boost_filesystem-mt。

是不是该到去掉 Beta 的时候了？我建议这个版本就叫 1.3。

版本号改为 1.3，去掉了"Beta"。

（链接已移除，见下）

使用 irc.lfnet.org。

但 1.0 听起来像首发版本。对有些东西来说新是优点，但对这类软件来说，成熟和稳定才重要。我不想把钱放进一个 1.0 的东西里。1.0 也许一时更有吸引力，但之后我们仍是 1.0，每个后来的人都以为我们才刚起步。这已经是第三个大版本，1.3 反映了这段开发历史。（0.1、0.2、1.3）

（已回退到 rc2）

链接已移除，0.3 现已发布，请到 http://www.bitcoin.org 下载。

好，那还是回到 0.3。

请尽快下载 RC4 并检查。我想尽快发布。

http://bitcointalk.org/index.php?topic=199.msg1927#msg1927

除了版本号改动（涉及 readme.txt 和 setup.nsi），我还把最大对外连接数从 15 降到 8，这样接受入站连接的节点不会收到太多连接。15 远超所需。8 作为冗余仍然绰绰有余。

Laszlo 的编译版将成为我们第一个 Mac 发行版，请大家测试！

Bitcoin 0.3 发布——一种 P2P 加密货币！Bitcoin 使用密码学和分布式网络，不再需要可信的中央服务器。由中央机构管理的货币可能被任意增发，Bitcoin 可以避开这种通胀风险。Bitcoin 的总发行量上限为 2100 万个。新币会根据节点贡献的 CPU 算力逐步分配给网络，因此贡献闲置 CPU 时间也能获得一份。

新特性：

• 命令行与 JSON-RPC 控制
• 附带无 GUI 的守护进程版
• 交易过滤标签页
• 哈希速度提升 20%
• Hashmeter 性能显示
• Mac OS X 版（感谢 Laszlo）
• 德语、荷兰语、意大利语翻译（感谢 DataWraith、Xunie 和 Joozero）

到 http://www.bitcoin.org 获取，或读论坛了解更多。

0.3 发布

http://bitcointalk.org/index.php?topic=238.msg2004#msg2004

这是一个 bug 修复维护版。现已上传到 SourceForge。Mac OS X 不需要任何修复，所以确实不用更新它，0.3.0 仍然可用。

下载链接在 bitcoin.org

更新内容：

• 新增 Tiago Faria 的葡萄牙语翻译

Windows

• 修复用户名含非 ASCII 字符时的 22DbRunRecoveryException

Linux

• Laszlo 修复了生成线程降到最低优先级的问题
• 修复 libcrypto 链接困难的问题
• Gavin Andresen 实现了"窗口系统启动时启动"选项

其他参与者原话knightmbJuly 15, 2010原帖 ↗

在 Linux 客户端（64 位）上，"关闭时最小化"仍会最小化到托盘（不久后因不断生成多个托盘图标导致 X 服务器挂起）。

我在首帖更新了 Linux rc2 的链接，包含此修复。请确认你的问题已解决。谢谢！

http://www.bitcoin.org/download/bitcoin-0.3.1.rc2-linux.tar.gz

我已把 windows 0.3.1 rc1 和 linux 0.3.1 rc2 传到 SourceForge，并更新了首页链接。

除非你遇到了首帖列出的问题之一，否则不需要升级到 0.3.1。如果 0.3.0 用得好好的，就留在 0.3.0。

请测试 0.3.2.5，为 0.3.3 发布做准备！这个构建状态良好，应该就是进 0.3.3 的那个。如果你在 Windows 或 Linux 上，我鼓励你现在就升级。

新功能：

• Gavin Andresen 的 HTTP 认证，保护 JSON-RPC
• 初始区块下载快 5 倍，30 分钟以内

在这里下载：

http://www.bitcoin.org/download/bitcoin-0.3.2.5-win32.zip

http://www.bitcoin.org/download/bitcoin-0.3.2.5-linux.tar.gz

谢谢！

请升级到 0.3.3！0.3.2 和 0.3.3 做了重要的安全改进。

新功能：

• Gavin Andresen 的 HTTP 认证，保护 JSON-RPC
• 初始区块下载快 5 倍，30 分钟以内

我猜 SourceForge 的镜像还没更新。文件在管理端已经在了，用户端还没有。不知道要多久。以前从来都是即时的。

编辑：SourceForge 现在更新了。

0.3.6 版本切换到 Crypto++ 5.6.0 SHA-256 时，Linux 64 位构建的生成功能坏了。0.3.8.1 已在 SourceForge 上，64 位二进制已更新。

下载：

http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.8/bitcoin-0.3.8.1-linux.tar.gz/download

0.3.8 之后的版本可能会要求 SSE2。有人还在用会遇到问题的 Pentium 3 或更老的机器吗？

rev 130 的杂项修复：

修复相对路径 -datadir

autostart 现在默认关闭（windows 除外）

修复用 msvc 编译时偶发的 "vector iterator not dereferencable" 断言

修复 linux 构建的 readlink 编译警告

用 sys/param.h 和 BSD define 替代 __BSD__

-paytxfee 开关，比如 -paytxfee=0.01

这是测试版构建，如果你想在 0.3.9 发布前帮忙测试的话可以用。

（或者你想现在就把升级做完、不想干等的话）

下载：（仅二进制包）

http://www.bitcoin.org/download/bitcoin-0.3.9.rc1-win32.zip

（http://www.bitcoin.org/download/bitcoin-0.3.9.rc1-linux.tar.gz）

SHA1 a36ea00cce27b4b083755df73a3d1e5e5729884e bitcoin-0.3.9.rc1-win32.zip

SHA1 bbb333b0ea57302740ad1bb9948520d00f884f9d bitcoin-0.3.9.rc1-linux.tar.gz

更新：

Linux 用户请改测 rc2。它增加了 tcatm 的 4 路 SSE2 的 -4way 开关。只面向 Linux：

http://www.bitcoin.org/download/bitcoin-0.3.9.rc2-linux.tar.gz

SHA1 47d9998f7d15fe81234a5c89a542da9d0664df40 bitcoin-0.3.9.rc2-linux.tar.gz

请把测试结果反馈到

http://bitcointalk.org/index.php?topic=820

0.3.11 版现已发布。

变更：

• 加载时对 blk*.dat 做了一些检查
• -4way 代码用 -march=amdfam10 编译，略微提速
• 时钟偏差太大时警告
• 警告/错误/警报现在也能在 getinfo 命令里看到
• 警报系统

警报系统能在状态栏显示通知，当你运行的版本需要为重要安全更新而升级时提醒你。

收到警报后，你的节点还可能进入安全模式，禁用以下 json-rpc 命令（自动化网站在用），在你有机会升级之前保护它不丢钱：

sendtoaddress

getbalance

getreceivedbyaddress

getreceivedbylabel

listreceivedbyaddress

listreceivedbylabel

如果你判定是虚惊一场、想赌一把，可以用 -disablesafemode 开关重新启用它们。

这是一项重要的安全改进。对很大一类可能的问题，它能在问题被发现时立即警告所有人，防止他们基于坏信息行动。

节点收到警报后继续运行、不会停止挖矿，因此旧版本可能仍会尝试分叉，但警报系统能确保用户被警告不要对分叉里的任何东西采取行动。

下载：

http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.11/

其他参与者原话torserversAugust 28, 2010原帖 ↗

「关于」对话框仍然显示 0.3.10.1 beta。

什么操作系统？我跑了 Windows 版和 64 位 Linux 版，检查了关于对话框。

Mac 版还是 0.3.10.1。

其他参与者原话paveloAugust 28, 2010原帖 ↗

我记得，可以用某个 gcc __attribute__ 按函数指定 -march。这样，只相关函数被优化，如果用户不指定 -4way，其他一切照旧。

我已更新首帖，说得更具体了。只 -4way 代码是这样编译的。

0.3.12 版现已发布。

特性：

• json-rpc 错误返回更标准的错误对象。（感谢 Gavin Andresen）
• json-rpc 命令行返回退出码。
• json-rpc "backupwallet" 命令。
• 如果收到的消息引发异常，会恢复并继续。其他节点本不该能引发异常，以前也从未发生过，但如果被发现某种引发异常的途径，这能防止它被用来搞停网络节点。

如果你的 json-rpc 代码检查错误字符串的内容，你需要改成期望 {"code":,"message":} 形式的错误对象，这是标准。见这个帖子：

http://bitcointalk.org/index.php?topic=969.0

下载：

http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.12/

在下一个版本（0.3.13）里，我打算把内部版本号整数的格式从 313 改成 31300，比如 31305 = 0.3.13.5。最后一个数字代表发布之间的 SVN 变更，应该在版本号里得到恰当体现。否则，万一我们在某个子版本里犯了错、需要绕过去，那会相当痛苦。

我并不认为这会给版本比较带来任何问题。31300 > 312。

0.3.13 候选发布版，请测试：

http://www.bitcoin.org/download/bitcoin-0.3.13-rc1-win32-setup.exe

0.3.13 候选发布版即将发布，请测试：

http://www.bitcoin.org/download/bitcoin-0.3.13-rc1-win32-setup.exe

• 交易没有 1 个确认前不计数、不可花费

http://bitcointalk.org/index.php?topic=1306.0

• 内部版本号从 312 改为 31300
• 仅在指定 -allowreceivebyip 时接受按 IP 地址发送的交易
• 去掉 DB_PRIVATE Berkeley DB 标志
• 修复发送最后一分钱时低于一分找零的问题
• 在 Linux 上自动检测是否使用 128 位 4 路 SSE2

Gavin Andresen：

• 新增 -rpcallowip= 选项，接受来自其他机器的 json-rpc 连接
• Linux 上收到 SIGTERM 时干净关机

对 0.3.13 来说太晚了，但我会尽量找时间把它加进下一个版本。

0.3.13 版现已发布。你应该升级，以预防 0/unconfirmed 交易的潜在问题。注意：0.3.13 能在你尚未花掉 0/unconfirmed 交易的情况下防止问题，但如果已经发生了，你需要 0.3.13.2。

变更：

• 交易没有 1 个确认前不计数、不可花费。
• 内部版本号从 312 改为 31300。
• 仅在指定 -allowreceivebyip 时接受按 IP 地址发送的交易。
• 去掉 DB_PRIVATE Berkeley DB 标志。
• 修复发送最后一分钱时低于一分找零的问题。
• 在 Linux 上自动检测是否使用 128 位 4 路 SSE2。

Gavin Andresen：

• 新增 -rpcallowip= 选项，接受来自其他机器的 json-rpc 连接。
• Linux 上收到 SIGTERM 时干净关机。

下载：

http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.13/

（感谢 Laszlo 提供 Mac OSX 构建！）

注意：

Linux 64 位版里的 SSE2 自动检测在 AMD 的 64 位模式下不起作用。请试试这个，并告诉我它是否判断正确：

http://www.bitcoin.org/download/bitcoin-0.3.13.1-specialbuild-linux64.tar.gz

你仍然能用 -4way 和 -4way=0 手动控制 SSE2。

0.3.13.2 版（SVN rev 161）针对「你已有 0/unconfirmed 交易且可能已花掉」的情况做了改进。它的 Windows 构建在这里：

http://www.bitcoin.org/download/bitcoin-0.3.13.2-win32-setup.exe

diff -u old\main.cpp new\main.cpp
--- old\main.cpp Sun Oct 03 20:57:20 2010
+++ new\main.cpp Sun Oct 03 20:57:54 2010
@@ -2831,6 +2831,10 @@
     bool fUseSSE2 = ((fIntel && nFamily * 10000 + nModel >=  60026) ||
                      (fAMD   && nFamily * 10000 + nModel >= 160010));

+    // AMD reports a lower model number in 64-bit mode
+    if (fAMD && sizeof(void*) > 4 && nFamily * 10000 + nModel >= 160004)
+        fUseSSE2 = true;
+
     static bool fPrinted;
     if (!fPrinted)
     {
@@ -2989,6 +2993,17 @@

                     // Transaction fee based on block size
                     int64 nMinFee = tx.GetMinFee(nBlockSize);
+                    //////// temporary code
+                    if (nBlockSize < MAX_BLOCK_SIZE_GEN / 10 && GetWarnings("statusbar") == "")
+                    {
+                        if (nBestHeight < 91000)
+                            nMinFee = 0;
+                        if (nBestHeight < 100000 && nTxSize < 2000)
+                            nMinFee = 0;
+                        if (nBestHeight < 110000 && nBestHeight % 10 == 0)
+                            nMinFee = 0;
+                    }
+                    //////// temporary code

                     map<uint256, CTxIndex> mapTestPoolTmp(mapTestPool);
                     if (!tx.ConnectInputs(txdb, mapTestPoolTmp, CDiskTxPos(1,1,1), pindexPrev, nFees, false, true, nMinFee))
diff -u old\serialize.h new\serialize.h
--- old\serialize.h Sun Oct 03 20:57:45 2010
+++ new\serialize.h Sun Oct 03 20:57:54 2010
@@ -22,8 +22,8 @@
 class CAutoFile;
 static const unsigned int MAX_SIZE = 0x02000000;

-static const int VERSION = 31300;
-static const char* pszSubVer = "";
+static const int VERSION = 31301;
+static const char* pszSubVer = " test1";

0.3.14 版现已发布

http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.14/

变更：

• 密钥池功能，更安全的钱包备份

Gavin Andresen：

• 用 -testnet 开关进入 TEST 测试网模式
• unix/osx 上可选用 SSL 进行 JSON-RPC 连接
• validateaddress RPC 命令

eurekafag：

• 俄语翻译

0.3.15 版现已发布。

变更：

• paytxfee 开关现在按 KB 计，因此会给大额交易加上正确的手续费
• 发送时尽可能避免使用确认数少于 6 的币
• BitcoinMiner 按依赖交易年龄的优先级顺序处理交易
• 确保区块 74000 下载完成之前不启动挖矿
• Dean Gores 的若干错误修复
• getinfo 新增 testnet、keypoololdest 和 paytxfee

0.3.17 版现已发布。

变更：

• 新的 getwork，感谢 m0mchil
• UI 选项菜单中新增交易手续费设置
• 免费交易限额
• sendtoaddress 返回交易 ID 而不是 "sent"
• getaccountaddress

UI 里的交易手续费设置很容易，因它从 0.1.5 起就留在那里，我只需重新启用。

基于账户的命令：move、sendfrom 和 getbalance 将在下一版发布。在那之前我们还有一些改动要做。

下载：

http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.17/

是 Laszlo 在做，但我有一阵子没让他做了，因为没有重大更新。这一版我会让他做。

变更：

• 修复了从 0.3.17 降级后再次升级时的 wallet.dat 兼容性问题
• 增加 IsStandard() 检查，区块中只接受已知交易类型
• Jgarzik 的优化，略微加快初始区块下载

本版的主要新增是 Gavin 一直在做的基于账户的 JSON-RPC 命令（详情见 http://bitcointalk.org/index.php?topic=1886.0）。

• getaccountaddress
• sendfrom
• move
• getbalance
• listtransactions

下载：

http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.18/

我会开始考虑怎么做。

目前，你多少可以用 -connect。可以用 -connect 让它连接你局域网里的本地计算机，比如 -connect=192.168.0.100。如果你从空白开始、不让它连主网络，难度仍停留在最初的低难度。不过如果你做了端口转发，外部节点仍可能向内连到你。

用 -connect 时它仍然走 IRC，你觉得当它被指示只用 -connect 连接特定节点时就不该上 IRC 吗？-connect 的主要场景是你有一组服务器农场，两台连着网络，其余的连到前两台。那种情况下，你不会想让 -connect 的机器上 IRC。

void ThreadIRCSeed(void* parg)
{
    if (mapArgs.count("-connect"))
        return;

那是在测试网上做的吗？

http://bitcointalk.org/index.php?topic=363.0

请把这类测试放到测试网上做。它就是干这个用的。谢谢。

那些 bug 追踪系统我一个都不了解。如果要有一个，我们务必做一个经过充分调研的选择。

只用论坛我们管得相当好。我更容易看到论坛里发的 bug，而且我觉得其他用户在这里（而不是在 bug 追踪系统里）更愿意帮忙解决、追问后续。关键一步是其他用户帮忙解决那些其实不是 bug、只是误解或困惑的简单问题。

我维护着一份论坛上见过的所有未解决 bug 的清单。有些情况我还在琢磨修复的最佳设计。我们这种软件并不该留这么多未解决 bug，多到需要一个追踪系统。

如果是 GPL 的东西，我就得避免使用。对 GPL 本身没有意见，但 Bitcoin 是 MIT 许可的项目。凡是 GPL 的内容，请明确标注出来。

如果唯一的库是闭源的，那就立个项目做一个开源的。

如果唯一的库是 GPL 的，那就立个项目做一个非 GPL 的。

如果最好的库是 MIT、Boost、new-BSD 或公有领域的，那我们就不用重写了。

我不怀疑 GPL 对操作系统是个好许可证，尤其因非 GPL 代码被允许与操作系统对接。对较小的项目，我认为对闭源接管的恐惧被夸大了。